Information Security News
Google developers have confirmed a cryptographic vulnerability in the Android operating system that researchers say could generate serious security glitches on hundreds of thousands of end user apps, many of them used to make Bitcoin transactions.
This weakness in Android's Java Cryptography Architecture is the root cause of a Bitcoin transaction that reportedly was exploited to pilfer about $5,720 worth of bitcoins out of a digital wallet last week. The disclosure, included in a blog post published Wednesday by Google security engineer Alex Klyubin, was the first official confirmation of the Android vulnerability since Ars and others reported the incident last weekend. Klyubin warned that other apps might also be compromised unless developers change the way they access so-called PRNGs, short for pseudo random number generators.
"We have now determined that applications which use the Java Cryptography Architecture (JCA) for key generation, signing, or random number generation may not receive cryptographically strong values on Android devices due to improper initialization of the underlying PRNG," he wrote. "Applications that directly invoke the system-provided OpenSSL PRNG without explicit initialization on Android are also affected." Apps that establish encrypted connections using the HttpClient and java.net classes aren't vulnerable.
Think tank wants dedicated infosec minister, 'modern' data retention
The Australian Strategic Policy Institute (ASPI) has issued an “Agenda for Change” (PDF) that suggests data retention is a necessary centrepiece of Australia's future homeland security needs. The document's introduction, penned by ASPI Chair Stephen ...
In a pattern that has played out repeatedly over the past year or two, researchers in the past two days have reported a string of ongoing attacks that take control of Web servers by exploiting critical vulnerabilities in Apache software, Joomla, and other applications used to deliver content and programs online.
The vulnerabilities in both the Apache Struts framework and the Joomla content management system have been fixed recently, but attackers continue to exploit the flaws on servers that have yet to install the updates, according to research published in the past two days. The attacks can have severe consequences for the websites that use the older versions, since the exploits make it possible to execute malicious code that can pilfer confidential customer data, mount malware attacks on visitors, and install applications that give attackers persistent backdoor access to some of a server's most sensitive resources.
One recent avenue for gaining backdoor access is an automated tool that exploits recently patched versions of Struts, an Apache framework for developing Java applications. The hacking tool, which researchers discovered three days after Apache's July 16 security advisory was issued, takes away much of the difficulty of manually injecting commands needed to extract sensitive information from vulnerable servers.
The primary reason your security program is struggling is not your lack of funding. You must find a better excuse than not having the budget you are convinced you need in order for your security program to succeed. Do not blame poor security on poor funding. Blame bad security on the REAL reason you have bad security. I hope to encourage you to take a new look at what you are doing and determine if it is working. If not, I encourage you to make a change by using the tools and capabilities you currently have to help tell an accurate story of your security program - with much needed and overdue metrics.
Every person can improve their overall security posture by clearly articulating the current state of their security program. Think creatively and start somewhere. Do not just sit by and wish for a bucket of money to magically appear. It will not. What can you do today to make your world better without spending any money? With some thoughtful effort, you can begin to measure and monitor key metrics that will help articulate your story and highlight the needs that exist in your security program.
When you do start recording and distributing your metrics, make sure they are delivered on a consistent schedule. Consider tracking it yourself for several weeks to make sure trends can be identified before it is distributed to others. Consider what this metric will demonstrate not only now, but also three months from now. You do not want to be stuck with something that does not resonate with your audience or even worse, provides no value at all.
Do not hide behind the security details of your message. Ask yourself why would someone who is not the CISO care about what is being communicated? How would you expect them to use this information? Start planning now for your response ahead of being asked. Think about what you want the recipient to do with this information and be prepared with some scenarios of how you will respond they ask for your plan. Never brief an executive without a plan.
Develop and rehearse your message in advance. Look for opportunities to share your message with others during the course of your day. Every day. Practice delivering your "elevator pitch" to make sure you are comfortable with the delivery and timing of the content. Ask your non security friends if your message is clear and can be easily understood. Often those who are not as close to the message can provide much more objective feedback. Resist the urge to tell every single thing you know at your first meeting. Give enough compelling facts that the recipient wants to know more, in a manner in which they can understand (without having to be a security professional).
I recognize this behavior every time I see it because I used to be guilty of the very same thing. I am certain that I was the worst offender. It takes no effort to sit by and complain. That only serves to make things worse. It takes commitment to conquer the problem. Unfortunately, only a few do that very well. Change your paradigm from why will no one listen to me to what is my plan to communicate the current situation in an effective manner. Have you found yourself guilty of admiring the problem? Do you stop working on problems when you realize that it is going to be simply too hard? Think beyond the current state and look to how things could be with focused effort.
Do not ask for everything at once. Seek an initial investment in your security program and demonstrate with metrics the value of that investment. Show how you have been a good steward with the initial investment and can be trusted with incremental investments. Be open, honest and transparent about the use of the resources. Pay particular attention to schedule, scope and budget. The people you are asking for financial support sure will.
The primary reason your security program is failing is not your lack of funding. Start developing your plan today. Maybe the executives say that they think there must not be a problem, since they are not hearing from you. By using the data you already have, start to use it to tell your story about the current state of your security program. This information, properly communicated can become the catalyst for increased awareness and funding.
Here are a few ideas to get you started:
What metrics have you found to be useful when communicating the needs and the effectiveness of your security program?
Update: looks like this has been fixed now. Of course bad cached data may cause this issue to persist for a while.
Currently, many users are reporting that .gov domain names (e.g. fbi.gov) will not resolve. The problem appears to be related to an error in the DNSSEC configuration of the .gov zone.
According to a quick check with dnsviz.net, it appears that there is no DS record for the current .gov KSK deposited with the root zone.
(excerpt from: http://dnsviz.net/d/fbi.gov/dnssec/)
DNSSEC relies on two types of keys each zone uses:
- A "key signing key" (KSK) and
- A "zone signing key" (ZSK)
The KSK is usually long and its hash is deposited with the parent zone as a "DS" (Digital Signing) record. This KSK is then used to sign shorter ZSKs which are then used to sign the actual records in the zone file. This way, the long key signing key doesn't have to be changed too often, and the DS record with the parent zone doesn't require too frequent updates. On the other hand, most of the "crypto work" is done using shorter ZSKs, which in turns improves DNSSEC performance.
I am guessing that the .gov zone recently rotated it's KSK, but didn't update the corresponding DS record witht he root zone.
This will affect pretty much all .gov domains as .gov domains have to be signed using DNSSEC. You will only experience problems if your name server (or your ISP's name server) verifies DNSSEC signatures.
Zombie PCs are for crimelord chumps: Fear clusters, says infosec ace
It may be possible for a "single dedicated attacker" to run an internet "carpet-bombing" attack by applying Big Data and distributed computing technologies, security researcher Alejandro Caceres warns. The traditional botnet, or network of hijacked ...
Posted by InfoSec News on Aug 14http://www.healthcareitnews.com/news/site-flaw-puts-patient-data-google
Posted by InfoSec News on Aug 14http://www.cnbc.com/id/100959481
Posted by InfoSec News on Aug 14http://www.bankinfosecurity.com/whatever-happened-to-ddos-phase-4-a-5986
Posted by InfoSec News on Aug 14http://english.chosun.com/site/data/html_dir/2013/08/13/2013081300891.html
Posted by InfoSec News on Aug 14http://thehill.com/blogs/hillicon-valley/technology/316611-former-dhs-deputy-secretary-launches-cybersecurity-council