One of the hottest topics among the members of web and security communities is HTML5. Lately, we've been getting a lot of requests from our customers regarding the ability to scan HTML5 applications with our static analysis products. Everyone wants to say that they've done something to secure their HTML5 apps, but few know what that actually means. I think the problem stems from the fact that HTML5 spec is not even complete, and yet the browsers already provide implementations for the proposed features. Plus, HTML5 isn't a completely new language – it's a collection of new features that present themselves through new HTML tags and attributes, JavaScript APIs, and HTTP headers.

In this post I won't go into detailed analysis of HTML5 security, but I would like to say that in my opinion the most sensitive areas of this new technology are going to be Cross-Origin Resource Sharing (CORS) policy that allows for communication between scripts running on different domains and client-side storage. We've already seen evidence that this can be abused in two alarming ways: storing sensitive information insecurely and storing code that gets eval'ed without proper sanitization. The latter is especially problematic when an application also contains a vulnerability that allows an attacker to inject malicious code into the client-side storage.

There are a number of other HTML5 features that I think will have a lot of security ramifications, such as cross-origin messaging, web sockets, file system APIs, as well as various others. However, I do not know whether anyone is using these primitives right now. What I do know is that the two features I mentioned above are already being used and abused. As it was pointed out here, there are already several cases of applications using local storage code caching with one of the scripts vulnerable to reflected XSS seen in the wild. On the other hand, according to the HP ESP’s 2011 Top Cyber Security Risks Report, 5% of sampled applications are CORS-enabled, and 75% of them allow any domain to be able to communicate to scripts running on their domains.

Going back to the question of statically scanning HTML5 applications for security vulnerabilities, I'd like to point out that it's not trivial. Mostly due to the dynamic nature of JavaScript: doing dataflow analysis on callbacks and anonymous functions is a challenge. Nevertheless, we have begun to address some of the relevant features in one of our older releases, and our next rulepack update will contain support for CORS and client-side storage, and potentially others. So, stay tuned.

HP Fortify RTA is very similar to a WAF, but it has one big advantage: Where a WAF protects outside of the perimeter, RTA protects from within the application. As always, we recommend to fix the known problems in code first, but when that’s not immediately possible, an RTA tool can help you out. On top of that, RTA can also be seen as an additional layer of protection.

In this blog post, I would like to show you an example of customization. More specific, let’s show an example how to protect by means of white-listing against command injection. Let’s say our customer has a web application which executes a couple of OS and other application commands where each command takes exactly one argument from the user. Taking data from the user, database, WS call or any other input and bluntly adding it to the command line will expose the application to command injection of course.

By default, RTA protects against Command Injection by parsing the command and validating it. However, as this default mechanisms does not take the entire context of the application in to consideration, it may be a good idea to add a white-listing rule to tighten the security. Assume that all commands executed in your application look like:

• backup.exe user_provided_backup_file.backup
• ping user_provided_host_or_ip_address
• whois user_provided user_provided_domain_name
• …

Then, the following rule can be inserted:

<Rule>
   <RuleID>RULE_ID_CUSTOM1</RuleID>
    <ProgramPoints>
       <SetReference id="CommandInjection"/>
    </ProgramPoints>
    <Monitors>
       <MonitorSpec class="com.fortify.runtime.monitor.Guard" monitorID="MONITOR_ID_CUSTOM1">
          <Attributes>
             <Attribute name="category">Command Injection</Attribute>
          </Attributes>
          <Predicate>
             not input matches /(backup\.exe|whois|ping) [^a-zA-Z0-9_\.\/\-]/
          </Predicate>
          <Configuration>
             <Property name="TriggerPicture">
                <Value>The executed command %{input} did not match the predefined white-list</Value>
             </Property>
          </Configuration>
          <Bindings>
             <Binding name="input" capture-ref="execute"/>
          </Bindings>
       </MonitorSpec>
    </Monitors>
</Rule>

Simply put, this rule will look at all the API’s that can lead to a Command Injection (like java.lang.runtime.Exec(), … ) and check if the executed command matches the predefined white-list ((backup\.exe|whois|ping) [^a-zA-Z0-9_\.\/\-]). If it does not match, the command will not be executed and an event will be generated which states that “The executed command %{input} did not match the predefined white-list”.

Simply put, WebSocket (RFC6455) is Raw Socket over HTTP (Web). It allows real-time (e.g. push) and bidirectional communication between the web client and the web application. Consider if you want to write a stock ticker application, instead of periodically polls the server for updates, you can use WebSocket to create an (almost) raw socket to the server and do whatever you want. WebSocket runs over HTTP, therefore, access control rules on existing firewalls will simply work without any modifications. And as of this writing, 3 out of 4 browsers installed on my laptop support WebSocket already (the only exception is IE).

WebSocket doesn't prescribe any particular way to handle authentication, you can authenticate using Session cookie when your first initiate your WebSocket over HTTP, or you can authenticate right after the WebSocket is established (similar to how you handle authentication in FTP). WebSocket supports cross domain communications by mandating the ORIGIN header (but is only available if the client is a browser). Web applications should check the ORIGIN header and refuse the connection if it is originated from an untrusted 3rd party website.

In 2010, Huang et al. reported a vulnerability that can trick a vulnerable proxy server to incorrectly redirect WebSocket connections from a Java Applet or a Flash to arbitrary host (IP hijacking) and hence allowing unauthorized cross domain connections, or can poison the proxy server cache (Cache Poisoning). After that, WebSocket adopted Huang's recommendation and requires XOR on packet payloads with a random key to avoid proxy servers that don't understand WebSocket to incorrectly pick up counterfeit HTTP requests embedded in the raw socket.

The current WebSocket protocol represents a low-level communication channel only, the protocol merely defines how to switch an existing HTTP connection into a low level socket connection without much other add-on features. Furthermore, the protocol itself is not stable and server side API is not standardized yet (Java will support WebSocket in Servlet 3.1). However, with the growing demand on real-time and bidirectional communications in Web 2.0 era, I can foresee many frameworks will build around it and make it a more secure and useable protocol in the future.

Reference:
WebSocket Echo Demo http://websocket.org/echo.html (requires a WebSocket compliant browser)

Technorati Tags: "mass assignment" model objects Rails Grails Struts2 Spring MVC request binding bound

Last couple of years, I've seen various mobile talks which always attracted a lot of people and the mobile talks at Blackhat Europe weren't any different. Actually, the mobile talks at Blackhat were different in another aspect. While most mobile talks have something interesting to say, they can only fascinate me for a portion of the talk. The content presented during the talks "The Mobile Exploit Intelligence Project" by Dan Guido and Mike Arpaia and "The Heavy Metal That Poisoned the Droid" by Tyrone Erasmus fascinated me from start to finish. While the first one determines in an intelligent way what attackers focus on, the latter gives you a collection of tools to gather runtime information from your Android. In two talks, you'll first of all understand from a high level what platform and information is most useful to an attacker and what kind of attacks are really out there. Second, you'll get an overview and demo on how secure the information is kept on one specific platform, the Android (which turns out to be the most likely attack platform for an attacker).

Last but not least, I enjoyed the workshop Samurai WTF given by Justin Searle. Where distributions like Backtrack focus on network security, the Samurai WTF focuses on application security. While I've literally spend days finding out which free tools and Firefox plugins I could use to make my life easier and get my work done, the Samurai WTF distribution simply gives you a liveCD with the free tools and even the plugins installed in Firefox ready to use. So even if you think you're using the best free tools and plugins available right now, check out Samurai WTF and be surprised.

I attended three sessions at RSA in San Francisco last week. I started the day with an interesting presentation on embedded systems titled "Hacking Exposed: The Dark World of Tiny Systems and Big Hacks" by Stuart McClure, CTO of McAfee. He shared real life examples of how vulnerable embedded systems can be and how far reaching the security breaches on these systems can be with our current day dependence on these tiny devices that are present everywhere around us.

He discussed real life examples like a simple hijacking of a Red Cross donation poster by replacing a chip using NFC (Near Field Communication) Technology and a sophisticated trojan mouse (the pointing device, not the animal) which could serve malicious websites and inject malware updates to the host. But the two examples I related to the most involved consumer devices that all of us carry around (Android and iOS devices). First, the demonstration of a seemingly harmless Android application requiring zero permissions from the user, opening up a Linux zero shell to acquire enhanced permission without the user knowledge or consent. And second, the demonstration of how easily user data could be compromised on the iPad over a WiFi connection, due to an underlying vulnerability on the device. The session concluded with McClure showing how medical devices, such as an insulin pump, can be remotely controlled to take cyber crimes to another level.

The second session by Tom Teller of Check Point Software Technologies, demonstrated a network application, called Protoleak, that used man-in-the-middle attacks on SSL to collect information leaked by everyday applications such as Facebook, LinkedIn and Gmail. It was fascinating to see how, within minutes, the tool was able to successfully harvest and correlate the collected data to create what he called "technical profiles" of users on the network.

It struck me as I watched these two presentations that while we worry and hear a lot about security at the web and application level, this may not be sufficient. To successfully tackle security challenges in the future, we need to address end to end security for the system as a whole: device, network and application.

Continuing with our series on RSA 2012, I had the opportunity to attend the final two days of the conference. I ended up staying for the closing keynote by Tony Blair, which was a real treat in itself, though his speech (unsurprisingly) only marginally touched upon security at all. However, his speech was widely covered and I will instead focus on the talks that I sat in on.

I took this as an opportunity to branch out and opted for talks that focused on areas other than application security. My most memorable talk on Thursday was a rather amusing one, titled Offensive Countermeasures: Making Attackers Lives Miserable. What I found particularly interesting was that many of the methods in the presentation describe ways to exploit the attackers' psyche, often using their very own methods against them. For instance, one countermeasure involved planting a deliberately malicious Java applet—anything from a rootkit to something that helps identify who they are—tucked away somewhere on a non-production server. As it turns out, computer illiterate users aren't the only ones who blindly click on "Run" on unknown Java applets. Many hackers are so curious to probe out the internals of a network that they are willing to run anything, even if a browser pops up a warning about any unsigned Java applets. Talk about giving attackers a taste of their own medicine!

My favorite talk on Friday described many of the issues with SSL, titled SSL and Browsers: The Pillars of Broken Security. It was the last session slot on the last day of the conference and packed to the brim. It certainly deserved the audience, as I felt it was very well-presented, organized, and informative. The crux of the issue is that SSL depends on several different entities working together, from the protocol designers themselves, to the vendors (both server and browser), to the CAs, to the sysadmins. Therefore, the protocol relies on each party to do its part correctly—as the saying goes, the chain is as strong as the weakest link. The presenters then went on and described past failures in each part of the chain. It was certainly an eye-opening and alarming revelation how deep-seated the issues are, and I highly recommend checking this one out. If you're interested, one of the presenters, Ivan Ristić, also did a more detailed webcast at last year's RSA on this topic.

In all, I had a great time at RSA, with quite fascinating speakers and panels. For someone as fresh out of university as myself, it was a great way to see all the different areas that security encompasses.

The time an application in production is secure can be very short! Check us out at Black Hat Europe, Thursday March 15 at 5pm where I'll be talking about Denial-of-Service attacks, gray box analysis and how it affects the security of a popular open source application called Apache OFBiz.

The group from CrowdStrike, headed up by Dmitri Alperovitch and George Kurtz, gave a great presentation on Remote Access Toolkits (RAT) relating to mobile platforms at RSA last week. Underlying the “Hacking Exposed: Mobile RAT Edition” presentation was the deeply rooted issue of software vulnerabilities existing in software running on mobile platforms. Specifically, CrowdStrike purchased 20 WebKit 1/2 day vulnerabilities, combined the browser attack with an existing root vulnerability exploit, used an APK ‘repurposed’ RAT, and some good old-fashioned hard work to make the RAT attack succeed. When the presentation concluded with the communication of a mobile phone being monitored by a third party, without the knowledge of the phone's owner, there was little doubt in the room that the game had been taken to the next level.

The following two fundamental questions need to be asked as we deal with the hot topics of the year (obviously including Mobile and Cloud):
(1) Can software or hardware vulnerabilities exist without an exploit?
(2) Can software or hardware exploits exist without underlying vulnerabilities?

Since vulnerabilities can easily exist in systems, known or unknown at the present time, exploits simply may not have been created yet to take advantage of the underlying vulnerabilities. These previously unknown vulnerabilities are the basis of 0-day, 1/2-day, and 1-day vulnerabilities. Exploits, however, cannot be created without the necessary precondition of vulnerabilities existing in order for an exploit to be written. The enabling factor of the RAT exploit that was demonstrated at RSA was a vulnerability existing in the software running on the mobile phone. Without the vulnerability, the attack would not have been possible and the exploit therefore would not exist.

In summary, exploits rely on the existence of vulnerabilities in target systems. As the landscape shifts to target Cloud and Mobile technology our focus on detecting, verifying, and removing exploitable vulnerabilities through tools and techniques built into a secure development lifecycle continues to be of critical importance.

I spent Tuesday of this week at RSA Conference 2012 in San Francisco. Somehow, I ended up going to three panel discussions rather than actual talks. The most entertaining, in my opinion, was the Cryptographers' Panel. To begin with, it had an outstanding list of panelists none of which require any special introductions: Whitfield Diffie (most know for Diffie-Hellman key exchange), Ron Rivest (the "R" co-author of RSA), Adi Shamir (the "S" co-author of RSA), and Stefan Savage (most known for his work on network worms, malware propagation, and distributed denial of service attacks).

The discussion started with dissection of a paper titled, appropriately for this panel, "Ron was wrong, Whit is right". The main idea behind the paper is to check how secure keys found in the wild are. Turns out that unlike keys that are used in Diffie-Hellman based algorithms, RSA keys available on the internet are less secure: two out of about one thousand public keys share common factors, probably due to insecure random number generators used for their creation. Another point raised during this discussion was the fact that there are no studies of malicious pseudo-random number generators, and that in general, traditional cryptography is based on the assumption that the keys are secure and are kept secure, which is clearly not the case. Defining a model for cryptanalysis in which this assumption does not hold is one of Shamir's latest research areas.

A number of other interesting questions were brought up. Savage and Shamir disagreed on whether it's harder to keep secrets now, with Stefan saying "no", and Adi saying "yes". However, all agreed that while cybersecurity will never become a science, security practitioners should apply scientific methods, such as rigorous gathering of experimental data, to many more scenarios than we do now.

The panelists also highlighted several major achievements that have occurred in the world of theoretical cryptography recently. The list is topped by the first key recovery attack on the full AES-128, which you can read about here. This is huge, even though it is not practically possible! The next one is the fact that ГОСТ – the Russian alternative to triple DES and AES-256 -- has also been theoretically broken in May 2011 after being thought secure for the past 20 years. Finally, SHA-3 competition is down to 5 finalists, and the winner should be announced later this year.

In the closing remarks, Rivest and Shamir touched upon more down to earth topics. Being one of the biggest names behind research in electronic voting, Rivest emphasized once again that online voting is a bad idea, and that we are simply not ready for it. And Shamir ridiculed Iranian government for shutting down internet access to its citizens.

All in all, it was a great discussion, which led me to the following thought: even though the number of security breaches rises with every year, none of these breaches have anything to do with breaking cryptographic algorithms. Even though, both AES-128 and ГОСТ have been broken, it’s nothing to lose your sleep over because the attacks are not possible in practice. This means that we're doing well on the crypto side. This is an incredible achievement! Of course, the other side of the coin is less bright – application-level flaws are still a problem and are usually the causes of these breaches. Which is why we are still here, doing our job at HP Fortify.