Most of the BlackHat 2010 talks aren’t off the ground yet and already this week has been busy for news and announcements. We already noted the DMCA updates earlier this week (which have been grossly over-hyped – see why that is here). Now on to the bigger story. No, it’s not Apple’s mouse-killer, nor is it the plethora of next-gen batteries that are now available (Apple, Toshiba (for cars), etc.). Nor is it the BlackHat talk about intercepting GSM-based mobile communication, nor is it the availability of cloud-based WPA/WPA2 cracking services, nor is it the publication of a 2.8GB database of information collected from public Facebook pages (see Joey’s commentary for more).

In my mind, the biggest, most important news this week is the release of the 2010 Verizon Business Data Breach Investigations Report (DBIR), which includes data from Secret Service investigations. It’s too lengthy to provide a reasonable summary here and now, but I wanted to bring this to your attention. If you read only one data breach report this year, then it should be the Verizon DBIR 2010.

Incidentally, if you’re looking for another data breach report to read, check out the one also released recently from the Digital Forensics Association “The Leaking Vault – Five Years of Data Breaches.” It does not present any new data, but it rather provides a fresh and interesting analysis of a compilation of existing data breach repositories (primarily DatalossDB.org).

A colleague lent me his most recent copy of IEEE’s Computer magazine.  Inside was an article entitled A Web 2.0 Model for Patient-Centered Health Informatics Applications (IEEE membership required to read).  Some possible benefits of their proposed approach were listed, including:

• Run deeper analytics across physicians groups and facilities, which can include relevant patient data…
• Provide a wide community of health professionals with feedback on the use and effectiveness of protocols…
• Share similar and alternative protocols and their analyses across many medical facilities and individual providers…

Anyone want to guess what’s completely missing from their approach?  You guessed it, any mention of security.  The commonly misunderstood (and frequently misspelled) HIPAA makes it pretty clear that the privacy and confidentiality of personal health information must be protected.  Even without HIPAA, it would just make good sense to be extra careful when sharing information and running data mining and analytics across large sets of health information.

The only mention of keeping information safe in the article is the fact that there is a division of data between the protocol, protocol modifications, and actual patient data – but it is very difficult to draw such bright, clear lines considering medical records and information.  How can you be sure the protocol modification a doctor submits won’t include information on the patient he tried it on?  Without even mentioning or considering the need for the protection of privacy, confidentiality, and data integrity within such a system, the authors of this article have done themselves and the software community a disservice.  Security requirements and threats must be considered at every phase of the life cycle, especially during the architecture phase.  As Kenneth Van Wyck and Mark Graff put it in their book Secure Coding: Principles and Practices,

As a general rule, the hardest vulnerabilities to fix are those resulting from architectural or design decisions. You may be surprised at how many of the vulnerabilities you have heard of we ascribe to errors at “pure think” time.

By developing an 8 page article published in a respected technical journal without any mention of the need for security controls in such a system, the authors of this article have once again helped me with my job security.  It is still difficult for me to foresee the day where security and risk management training programs won’t be necessary, and we won’t need an information security industry.

People are relieved. In what has quickly become one of the mainstream tech media’s darling stories of the day, the U.S. Library of Congress has apparently woken up to find itself a decade into the 21st century and has released an updated list of allowed circumventions that do not qualify for punishment under the Digital Millennium Copyright Act’s (DMCA) anti-circumvention clause. In a nutshell, you can rip (DeCSS) movie clips for fair use, you can jailbreak your iPhone (whether it be to install software or to hop providers), you can hack video games (for “good faith” security purposes, mind you, and consoles seem to be excluded), you can bypass hardware dongles that have become obsolete (fairly narrow ruling here), and you can enable read-aloud for ebooks, even if the publisher is still living in the Dark Ages and has flipped a bit to disable it.

In a little more detail, the 6 new rules are:

1. You can circumvent CSS in order to digitize short clips of movies IFF you have an educational use, are making a documentary, or are making a noncommercial video. Nothing is said about archival purposes, and they explicitly cite DVD, but it’s believed that archival is already covered under DMCA, and that Blu-Ray would be covered by logical extension.
2. You can circumvent wireless telephone access controls (“root” or “jailbreak” them) in order to install other software. This finding seems to directly target Apple (and maybe Google), who doesn’t like it when people jailbreak the phone. Mind you, there’s nothing here that would prevent them from bricking your jailbroken phone in an upgrade… they just can’t sue you about it under DMCA (makes reading contracts all that much more important).
3. You can install an alternative image (firmware or software) on wireless telephones to enable them to connect to a provider. It’s not completely clear what this is about, but it seems that it could address a couple different scenarios. First, it may be talking about unlocking a phone to allow it to be used on an alternative carrier’s network. Or, second, it may be talking about installing an alternative OS on the device (such as replacing Windows Mobile with Android).
4. Circumventing access controls (e.g. DRM) for security testing of locally installed video games is permitted, assuming the testing is performed in good faith. The wording would seem to exclude gaming consoles, and may also exclude network-based testing of gaming sites.
5. Hardware dongles can be circumvented IFF the dongles are obsolete (pertains to: “Court Backs Dismissal of Digital Copyright Claim“) This would not, however, seem to allow one to bypass dongles for products like EnCase when the product still exists and can be upgraded accordingly (i.e. if you can replace the dongle, then you must do that rather than circumvent the control).
6. Circumvention of access controls is permitted with ebooks in order to enable read-aloud functions or using screen readers to put the text into an alternative format.

Additional coverage:

• The DMCA vs “Reverse Engineering” Software
• TechCrunch: Now Legal In The U.S.: Jailbreaking Your iPhone, Ripping A DVD For Educational Purposes
• EFF Wins New Legal Protections for Video Artists, Cell Phone Jailbreakers, and Unlockers

Due to the way Android requires SD cards to be formatted in VFAT, it leaves a bit of a hole when it comes to security for files stored here. VFAT is an old standard that doesn’t support the access controls of Linux, so data stored here is unprotected.  Because of this, all storage here is shared with all programs on the device.  So storing sensitive information here isn’t going to be the best thing to do. With some devices having limited internal storage though, this might be your only option, or depending on what the data is, you may require large amounts of storage space.

One way around this is to simply encrypt the data from within your application. This can be achieved via the ‘javax.crypto’ library.

Read the rest of this entry »

HOPE was this weekend at the Hotel Penn in New York City. Except for the choice of venues, it’s a pretty nice (and cheap) conference to get to. I went to several of the talks, although, not all of them would be interesting to purely security people – like cooking for geeks… The talks I did attend were interesting, if not ground breaking. HOPE isn’t generally where people release new code, tools or exploits – that’s Black Hat and Defcon in two weeks, but there tend to be more talks about hacker culture and privacy. The one talk I skipped that I would have liked to go to was the Social Engineering talk – at 9pm on a Saturday (I was already half asleep). I heard that they tried to social engineer a BP gas station, with some success.

I also hit up the talk on the American Bombe – yes, we had a few – a well researched and interesting discussion on how the US got started on that project and some of the stumbling blocks along the way. I also went to the HTTPS discussion, but it rehashed old SSL vulnerabilities and issues with the default CAs trusted in the browsers. One of the better talks I went to was the Locational Privacy and Wholesale Surveillance via Photo services talk by Ben Jackson. He discussed using the EXIF GPS data to stalk people. I promptly told my iPhone that the Camera app was not allowed to use location services.

For me, HOPE is more about the hallway track and meeting people and learning new things on the mezzanine level. This year, the lockpick village was so small that no one could fit in, so I didn’t stop by there – even if I did take my picks. There were more vendors on the M level as well, mostly books, with very little electronics as there have been in years past.

This year, I borrowed a friend’s ham radio and used my license for the first time in 10 years to get an N2H QSL card – along with my friend and several others. Just listening to the hams talk from N2H was interesting as well.

Details of this month’s Patch Tuesday updates here:  http://www.microsoft.com/technet/security/bulletin/ms10-jul.mspx

This month, we get a fairly light load of patches for Windows and Office, but there are a few remote code execution vulnerabilities that are addressed.  So, if you run Windows and/or Office, apply these patches as soon as possible. If you’re running Windows XP or Windows Server 2003, you should address these patches post haste, as there is a code execution vulnerability affecting the Microsoft Help and Support Center that is currently being exploited in the wild. (http://www.microsoft.com/technet/security/bulletin/ms10-jul.mspx)

Also, don’t forget to restart your system when the updates are finished installing – don’t be lazy like me and hit “postpone” too much!

Web application hacking is big business. Even the traditionalist network penetration testers are crossing over to the new security rock and roll scene. The average individual doesn’t know what DNS does, and if I said, “I knocked over the internet by attacking BGP,” at a cocktail party, guests would probably suspect I just said something vulgar. On the other hand, “You are a hacker? Can you get credit card numbers off websites?” is a common reaction from even the computer unsavvy. My answer, “Yes, most websites suck.”

So how do you make your websites not suck? My colleague recently posted about OWASP’s ESAPI. Additionally, OWASP developed Webgoat, arguably the go-to training tool for web application hacking n00bs to cut their teeth. On top of giving hackers a chance to bring down websites in more than a dozen ways, several Webgoat lessons include a lab section. These labs include not only hacking the website, but also delving into the code to find the flaw that causes the vulnerability, fixing it, and testing the attack again. Getting down and dirty with the actual code is instructive for penetration testers and coders alike.

Webgoat labs should be mandatory for all website coders. Please start writing code that doesn’t suck so the web application hackers will stop getting so much attention and people will start paying attention to my mediocre attempts at hacking the infrastructure. Let’s call it the “Georgia for infosec prom queen” project shall we?

Last year I discovered an unusual but useful method for writing web application code: non-alphanumeric JavaScript. This technique has been pioneered by several script ninjas on the hackers forum sla.ckers.org and lets you write scripts without directly using letters or numbers. Application filters or sandboxes may catch typical attacks by monitoring for requests such as “document.cookie,” but they may let non-alphanumeric code slip through.

How does it work? First, you can use blank objects or arrays to generate basic values. For instance, +[] evaluates to the number zero, while !{} returns the boolean value false. You can also combine these simple results to create strings, such as [!{}]+[+[]] == "false0". By treating these strings as arrays, we can grab individual letters. From our previous example, "false0"[0] == "f", so we can use ([!{}]+[+[]])[+[]] == "f" instead.

Once we have enough of the alphabet available as strings, we can start combining letters to reference more useful objects and functions, thanks to JavaScript’s flexibility. For instance, if you wanted to load the sort function for an array, you’d probably use a [].sort() syntax. But []['sort'] works equally well, and even []['s'+'o'+'r'+'t'] loads fine.

In fact, if we set _=[]['sort'] (variable names need not require letters and numbers either!) and call _() in Firefox, we’ll get back the window object, opening up many more possibilities. Accessing this object also means we don’t have to write all of our code without the benefit alphanumeric characters, since we can load data from window.name or window.location. For instance, if we load http://server/page.html#alert(document.cookie), the hash is only seen by the client (and our script), not the server.

This means that if a server is vulnerable to cross-site scripting and doesn’t filter our non-alphanumeric script, we can execute arbitrary JavaScript even though we only send non-alphanumeric code to the server.

If you’re interested in more details, check out the sla.ckers.org threads on optimizing code, cheat sheets, and the Great JS Wall (researchers have found that you couldn’t load arbitrary scripts if you draw from a set of less than six characters). Also, several of the people who contributed to those threads are releasing a book on this method and other attack strategies later this year, entitled Web Application Obfuscation.

For authentication, newer versions of Oracle (11g+) use a session agreement and key exchange scheme known as O5Logon. It has some of the same weaknesses of authentication as the O3Logon used in previous versions of Oracle.

An example transcript of the default auth process:
1) Client connects to Server:
2) Client sends Username to Server
3) Server generates a ServerSessionID and encrypts it with AES. The key is the PasswordHash. It sends this encrypted ServerSessionID and the PasswordSalt to the Client
4) Client tries to generate a password hash using the PasswordSalt and the provided password. It decrypts the ServerSessionID using this ClientPasswordHash
5) Client generates a ClientSessionID and encrypts it with AES. The key is the ClientPasswordHash. It combines ServerSessionID and ClientSessionID to make another key which it uses to directly encrypt the provided password. It sends this encrypted password and encrypted ClientSessionID to the Server.

A more in-depth breakdown of the steps involved can be found here.

So, although there is a lot going on, the password itself is never really sent in clear text. This scheme also prevents against replay attacks, since the session IDs are different each time. The drawback is the fact that capturing all of the transmissions can allow an attacker to brute force the password in an offline environment. This is possible because guessing the hash will allow an attacker to simply decrypt the password sent from the client by sniffing the transmissions and comparing them later.

I think it’s possible to gain the same reply protection without exposing the password like that, but it would almost certainly take more steps. This scheme was probably designed to be very fast while providing protection against the most common attack scenarios. In comparison, TLS-based authentication is an alternative to O5Logon for Oracle, and does all sorts of cert. exchanging and flippidy floppidy. It provides better protection, but at the potential expense of being overkill if you just want decently secure authentication, and I think that’s one reason it’s an option instead of the default. In general, O5Logon is fine if the user chooses a strong password. As usual, the most critical link in the security chain is the individual.

Each Thursday, Security Musings features a security-related technology or tool. Featured items do not imply a recommendation by Gemini Security Solutions. For more information about how Gemini Security Solutions can help you solve your security issues, contact us!

My article, “Maddening Methods: Fundamentals of Risk Assessment and Analysis,” was published in the July 2010 edition of The ISSA Journal. It covers some of the key concerns around risk assessment today, including addressing common arguments posited against risk assessments and risk management. From the abstract:

Considerable confusion exists in the security industry around the effectiveness of risk assessment and analysis methodologies. Points of contention often focus on specific attributes of a given method, such as data quality, statistical analysis, or a qualitative versus quantitative approach. There are reasonable, viable answers to these points of contention that resolve most of these concerns.

I hope that you’ll find this piece informative and enjoyable.