Black Hat – Las Vegas 2011: Report #3
”Next-Gen Web” Track
After Cofer’s talk, I settled into the “Next-Gen Web” track, which was smaller than the “threat intel” and “bit flow” tracks that drew big crowds. The first topic was on a new web protocol being developed by Google called SPDY (pronounced “speedy”). While interesting, the talk had little to do with security. The speaker was a young German who is heavily involved in the security sector, but his talk simply explained the protocol. I honestly could have gathered most of what he spoke about by reading the documentation and playing with some examples. I was not terribly impressed.
Hacking Google Chrome OS
The second talk was called “Hacking Google Chrome OS,” which should have been titled “Hacking Google Chrome Extensions.” It was simultaneously outstanding and shocking. Having developed a number of Chrome extensions myself, and being technically aware of the potential security issues, I quickly grasped the technical details. The speakers were a couple of guys from White Hat Security who were engaging and held solid grasps on web-based penetration testing. It’s possible that Google contracted White Hat to do the penetration testing of Chrome OS. Google has gone to extreme measures to ensure that both Chrome the web browser, and Chrome the OS are less susceptible to common attack vectors through their use of sandboxing, tab/process isolation and more. The presenters first showed an example of an extension written by Google and pre-installed it on all Chrome OS notebooks. It was simply a notepad that syncs with a user’s Google Docs account. They found that by using JavaScript in the title of a document, the scratchpad extension would execute it (a traditional cross-site-scripting, or XSS, attack). However, their discovery pushed XSS to a whole new level. Scratchpad needs permission to access docs.google.com and google.com. This makes perfect sense. However, once arbitrary JavaScript is executed by the extension, it can be used to retrieve things like Google session id’s from Google cookies. It can also be used to retrieve a user’s Google contact information.
What makes the attack more severe is that Google allows users to share directories with other users without notifying either end that the actual directory-sharing is in effect. This directory can be picked up by the scratchpad extension, after which, can spawn a web-based XSS worm capable of propagating to all Google contacts and spreading further to users with the scratchpad extension installed. This extension had a simple XSS vulnerability and only required permissions to access Google sites. Google corrected this issue in the extension, however and in all cases, protecting users will be up to the third-party developers. It’s common for such developers to misunderstand XSS, or why it is important to limit the permissions of their extensions. Many extensions are allowed (by their developer) to access every site on the internet. If there is any XSS vulnerability in an extension, then it can be exploited to inject arbitrary code into any web page users visit and can be opportunistic about which sites it wants to attack. It can wait until users go to sites “of interest” (Google, PayPal, Facebook, personal banking websites, etc.) before running key loggers, snatching usernames/passwords, and even worse, snatching crypto key for a user’s LastPass account, an online password management system, thereby gaining access to every website linked to the service. It should be noted that the presenters did advocate the security of LastPass despite this issue, being that it is not a LastPass vulnerability.
They further demonstrated a malicious extension they wrote that could execute “behind the firewall” port scans (using Ajax), send text messages and place calls (using Google voice), and more. They even stressed that because the Android Market can allow the installation of apps onto a phone, vulnerabilities in the Android OS could be exploited to propagate deep into the mobile space. They also mentioned that in the black market, mobile exploits sell for a 30% premium over desktop ones. They did offer suggestions to mitigate these issues. For example, Google will be simplifying permission models for common use cases. Regardless, this still depends heavily on the third-party developers in using permissions properly. Overall, this was a very exciting and eye-opening talk.
Adobe Talks About Server-Side JavaScript Injections
After lunch, I attended a talk by an Adobe employee, Bryan Sullivan, about server-side JavaScript injections using node.js and nosql databases. His charisma and knowledge charged the room. I was shocked that all the presenters (aka security professionals deeply involved in penetration testing) used Windows for their presentations and seemingly on their personal machines. I expected most to be OSX and a few Linux, but Windows?
I was already aware of the possibility of server-side JavaScript injections with node.js, yet he delivered stellar demonstrations about what can be accomplished with XSS vulnerabilities in node. His finale consisted of sending a base-64 encoded request payload written to a server’s local file system and then executing it. It turned out to be Windows Media Player, but it was still exciting to see it in practice. The ramifications of such issues are FAR greater than those of “traditional” XSS issues.
Afterwards, Bryan demonstrated exploits with PHP and mongo (a nosql database), and concluded that a database could be completely dumped from behind a firewall. Another major possibility is that “persistent” XSS could be stored in the database and then executed/injected whenever any data is queried from that database. Most nosql databases encourage use without authentication. Some don’t even offer authentication as a possibility and those that do, lack strong protection. In other words, access to any part of a nosql database generally means the whole system is compromised. For mitigation, he suggested that the nosql database vendors change this policy.
Bryan also gave examples of why JSONP is a bad idea. JSONP is a way around the “same origin policy” that browsers incorporate to limit XSS attacks. For mitigation of node.js XSS injection, he suggested the use of the VM module, and recommended that database inputs be sanitized/validated as any exploits that store data persistently in the database cause it to be an untrusted input as well. He also spoke of more common approaches, like using JSON.parse over ‘eval’ to parse JSON. Overall, Bryan was another outstanding talk. Read more about Bryan’s work on his blog: http://blogs.adobe.com/asset/.
Attacking HTML 5, Flash and Silverlight
The next talk was about attacking HTML5, Flash and Silverlight. The presenter was mildly difficult to understand due to his accent. Furthermore, his delivery was monotonous and gave zero live demonstrations, only pre-recorded screencasts. This was by far the least interesting talk of the day and I really don’t have much more to say about it.
Reception
After the aforementioned lack-luster talk, a reception ensued in the show room. I mingled with vendors and other like-minded professionals. Black Hat, once again, demonstrated its prestige (likely to justify the cost of attending) with an open bar and an amazing and colorful assortment of food.
PWNY Awards
Following the reception, I attended the pwny awards, which was extremely amusing! Stuxnet won the “epic 0wnage” award for its extensive efforts in destroying the Iranian nuclear program. Sony won the “Epic Fail” award (in 5 different categories). A number of the most influential security researchers were also present. Much of their work was, rightly, recognized.
So far, Black Hat has lived up to all its hype, and considering this is Vegas, what better way to cap an eventful day than with a David Copperfield magic show. David was extremely entertaining and obviously VERY good at his job.
