The big news of the week, emanating from Toorcon 12, is the release of Firesheep. This tool makes SideJacking – that is, “hijacking an engaged Web session with a remote service by intercepting and using the credentials that identified the user/victim to that specific server” – painfully simple for anybody to use. How easy? Well, let’s see… you download and install Firefox… and then you download and install the Firesheep extension to Firefox… and then you restart Firefox and run the tool to start hijacking sessions… that’s it! Simple enough for ya?

SideJacking is not a new concept, nor is the existence of tools. Robert Graham of Errata Security made a bit of a splash with his tool Hamster back at Black Hat 2007 (also see “Wi-Fi SideJacking opens eyes at BlackHat“). And, really, the concept of intercepting and hijacking sessions is even older than that. Poor session management continues to be on the OWASP Top 10 list, as does the lack of adequate transport layer protection (that is, SSL/TLS for web sites).

(more…)

Pen-testing as a job is quite boring compared to learning it or doing it for fun. Why is that? You have to be meticulous about logging every packet that goes between your machine and your client’s. You have to keep logs of everything you’ve tried and what worked and what didn’t. So, when the client comes back and says you crashed their servers, you can show them why/how you crashed them, or you can show that you weren’t doing anything that should have crashed their servers (aka, their servers are broke). You can also use those logs to find things that didn’t stick out at you initially. When you’re doing it for fun, you don’t have to worry about this kind of stuff – and it certainly adds to the time it takes to do things.

There are many tools you can use to get these logs. Almost all pen-testing tools have such logging built in, because the developers knew you’d need that functionality. If the tool doesn’t have logging built in, you can use a few command line tools (for command line testing tools) to record everything. ttyrecord and date are two of my favorites. ttyrecord records (like a video) in binary format all typing, commands, and responses that you type into a tty (aka terminal). It covers anytime you’ve logged in remotely to another system as well. It comes with ttyplay to play that information back and to make it human readable again. Typing date before and after any commands also shows your system’s clock so you can precisely time what you did when.

On GUI systems, the easiest is screencasting software, even if it’s large and uses way too much space. On Windows – screenshots are about the only option you’ve got as an alternative to screencasting, but then you have to remember to take screenshots, then order/reorder them according to what you did and what time it was.

Any other tools that you can use to capture these kinds of logs?

OAuth is a protocol that lets applications request data or privileges you have on a remote service without you having to provide your credentials for that service. A classic use case for this “valet key” system is contact import – you can let a site load your address book from Gmail without giving that site your actual Gmail password. Twitter recently required that any third-party applications using their API must authenticate using OAuth.

Twitter’s implementation is based on OAuth 1.0, which was finalized in April but has been in development for several years and is already widely supported. But work on a new version is now under way, and Facebook has already implemented one variety of the draft specification for applications that connect to their service. OAuth 2.0 currently defines specific flows, or client profiles, for handling authentication: Web Server, User-Agent, Native Application, and Autonomous. The first two are most commonly used for web applications, and implementations of the third may end up being quite similar.

The process for most clients involves three broad parts. (Note that “client” in this context refers to the application seeking access, not the person using the application.) The first involves user authentication. For a web-based service, this will often mean ensuring the identified user is currently logged in and then asking for their permission to enable access if they have not previously granted it. Second, the client has to authenticate. In other words, the client making the request has to prove it is the same application that the user granted permissions to in the first step. If both of these steps complete without error, the client is given means to access the protected resources, typically with a temporary code known as an access token.

The specific details of how these steps happen depend on the client profile used. Facebook’s standard Graph API authentication is an example of the Web Server flow. When first requiring access to private user data, a third-party application will forward the user’s browser to Facebook’s authorization server. The request includes a public code identifying the application and a URI under the application’s control. Facebook prompts the user for the permissions and (if they are granted) redirects the browser to the provided URI, along with an authorization code. The client then makes a request directly to Facebook which includes this authorization code and a secret code identifying the client. Facebook then sends back an access token, which is used to authenticate specific access requests for the duration of the session.

The User-Agent profile differs in that it relies on a user-agent’s same-origin policy rather than a client secret for authenticating the client. This process provides OAuth capabilities for JavaScript-based applications that do not have a server-side component and thus cannot ensure identifying codes are kept secret.

Simplicity was a major factor in creating OAuth 2.0, and thus several parts of OAuth 1.0, such as signatures and nonces, no longer apply. However, OAuth 2.0 requires transport-layer security of TLS 1.2 at minimum (as of draft 7) for the interface used to request and receive access tokens. The spec also recommends that secure channels be used for other parts of the process. In Facebook’s implementation, all server interfaces are accessed via HTTPS addresses.

From a security perspective, OAuth is a good step in that it discourages the anti-pattern of one application requesting a user password for another application. It can also protect users in other ways; for instance, if someone intercepted the authorization code for a Facebook application, they would not be able to use it for data access without also obtaining the application’s client secret. However, OAuth only addresses particular issues with third-party access and should not be considered a silver bullet for security. As an example, access by Facebook applications vulnerable to cross-site scripting may still be hijacked once the application has been authorized.

While OAuth 2.0 is still in draft status, Facebook’s deployment makes it in wide use already, and we’ll likely see many more implementations in the months to come. The description above should help you understand the basics of how OAuth 2.0 works, but if you’re interested in further details, check out the full spec and Facebook’s specific authentication guide.

There has been much criticism of risk assessment and analysis over the past few years that amount to much ado about nothing. Why is it much ado about nothing? Well, because, quite simply, people oftentimes don’t understand what it is they’re criticizing, especially in the case of quantified risk analysis methods.

Before we get into risk measurement, let’s first make one thing clear: risk analysis is nothing more than a decision-analysis (or decision-support) tool. It helps provide reasonably accurate data points that decision-makers can use when make decisions. It is not a panacea for all things risk or infosec, nor is it some sort of special magic-sauce voodoo with no grounding in reality (at least not in terms of well-considered quant methods). Clear? Crystal, I’m sure.

When performing a risk analysis, we need to start with the basics. Here at Gemini we subscribe to the Factor Analysis of Information Risk (FAIR) methodology for performing quantified risk analysis. FAIR defines risk as “the probable frequency and probable magnitude of future loss.” What this means in real terms is that FAIR reduces “risk” into two main components: Loss Event Frequency and Loss Magnitude. Both are estimates that are created using Douglas Hubbard’s calibration technique, as advocated in his book How to Measure Anything.

(more…)

Recently, Vinay Deolalikar self-published a proof that P is not equal to NP. So what does that mean exactly?

P is short for Polynomial, and NP is short for Non-deterministic Polynomial. To understand the exact difference requires you to understand Turing machines (usually a senior level CS class). P is the class of problems that can be solved in polynomial time on a deterministic Turing machine in polynomial time, and NP is the class that can be solved on a non-deterministic Turing machine in polynomial time. Here’s the catch: so far, no non-deterministic Turing machines exist. There’s speculation that quantum computers are non-deterministic Turing machines, but not a proof that I know of.

Another way of thinking about P and NP problems is how long it takes for a computer to solve the problems – is it “easy” (P) or “hard” (NP). Most classic computer science problems are NP – the traveling salesman, factoring integers… The computer can verify the answer in P time, so the current approach is to make a best guess, verify it, then make another guess.

What does this mean for most people? Most people have never heard of P or NP – heck, a lot of computer/IT people probably haven’t unless they’ve studied theoretical computer science – and even most of us who’ve heard of it would rather forget it. But it really does matter for security. One of the NP problems is factoring integers – what public key cryptography is based on. There is an assumption – based on years of practice, but no proofs – that NP is not equal to P. If NP were ever shown to be equivalent to P, then our current asymmetric cryptography solutions would be blown out of the water and we’d all have to find new algorithms to use. If NP were proved to be not equal to P, we’ve got some more time

So far, the reviews I’ve heard of Deolalikar’s paper is that it’s a great start, but it has a few flaws, so we still don’t know if P is or is not equal to NP.

Due to the way Android requires SD cards to be formatted in VFAT, it leaves a bit of a hole when it comes to security for files stored here. VFAT is an old standard that doesn’t support the access controls of Linux, so data stored here is unprotected.  Because of this, all storage here is shared with all programs on the device.  So storing sensitive information here isn’t going to be the best thing to do. With some devices having limited internal storage though, this might be your only option, or depending on what the data is, you may require large amounts of storage space.

One way around this is to simply encrypt the data from within your application. This can be achieved via the ‘javax.crypto’ library.

(more…)

Last year I discovered an unusual but useful method for writing web application code: non-alphanumeric JavaScript. This technique has been pioneered by several script ninjas on the hackers forum sla.ckers.org and lets you write scripts without directly using letters or numbers. Application filters or sandboxes may catch typical attacks by monitoring for requests such as “document.cookie,” but they may let non-alphanumeric code slip through.

How does it work? First, you can use blank objects or arrays to generate basic values. For instance, +[] evaluates to the number zero, while !{} returns the boolean value false. You can also combine these simple results to create strings, such as [!{}]+[+[]] == "false0". By treating these strings as arrays, we can grab individual letters. From our previous example, "false0"[0] == "f", so we can use ([!{}]+[+[]])[+[]] == "f" instead.

Once we have enough of the alphabet available as strings, we can start combining letters to reference more useful objects and functions, thanks to JavaScript’s flexibility. For instance, if you wanted to load the sort function for an array, you’d probably use a [].sort() syntax. But []['sort'] works equally well, and even []['s'+'o'+'r'+'t'] loads fine.

In fact, if we set _=[]['sort'] (variable names need not require letters and numbers either!) and call _() in Firefox, we’ll get back the window object, opening up many more possibilities. Accessing this object also means we don’t have to write all of our code without the benefit alphanumeric characters, since we can load data from window.name or window.location. For instance, if we load http://server/page.html#alert(document.cookie), the hash is only seen by the client (and our script), not the server.

This means that if a server is vulnerable to cross-site scripting and doesn’t filter our non-alphanumeric script, we can execute arbitrary JavaScript even though we only send non-alphanumeric code to the server.

If you’re interested in more details, check out the sla.ckers.org threads on optimizing code, cheat sheets, and the Great JS Wall (researchers have found that you couldn’t load arbitrary scripts if you draw from a set of less than six characters). Also, several of the people who contributed to those threads are releasing a book on this method and other attack strategies later this year, entitled Web Application Obfuscation.

My article, “Maddening Methods: Fundamentals of Risk Assessment and Analysis,” was published in the July 2010 edition of The ISSA Journal. It covers some of the key concerns around risk assessment today, including addressing common arguments posited against risk assessments and risk management. From the abstract:

Considerable confusion exists in the security industry around the effectiveness of risk assessment and analysis methodologies. Points of contention often focus on specific attributes of a given method, such as data quality, statistical analysis, or a qualitative versus quantitative approach. There are reasonable, viable answers to these points of contention that resolve most of these concerns.

I hope that you’ll find this piece informative and enjoyable.

I don’t know if it’s PCI compliance fever season or what, but I’ve been asked a lot about “weak SSL ciphers” lately. Mostly, having to do with “what the heck are those anyway?” If you don’t have a decent grasp of SSL, start with my previous article on SSL. If you think you do, stay with me for a bit

Let’s start with what ciphers are. Ciphers are the algorithms used to do some kind of cryptography – either encryption or hashing. Well known ciphers you’ve probably heard of are RSA, 3DES, AES, Blowfish, and SHA1. SSL Ciphers are the set of ciphers that are used for all parts of the SSL negotiation – and remember there are several used in one SSL session: both asymmetric and symmetric, and hashing. If you have OpenSSL installed, you can see all of the Ciphers that OpenSSL supports by typing openssl ciphers -v (the -v gives you details that are helpful). You’ll get back a list that looks something like this (except a lot longer):
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1

What each of those lines tells you is what the name of the cipher is (according to OpenSSL), the SSL version that it exists in, the Key Exchange algorithm (Kx), the Authentication (Au) algorithm, the Encryption (Enc) algorithm, and the Hash (Mac) being used. You can see where the cipher naming scheme comes in…

You don’t want any of these ciphers to be “weak”. So you’re really looking at 4 ciphers at a time to determine if the cipher is “weak”. What makes a cipher “weak”? Any algorithm (or key length) that has been determined to be easily breakable through either a flaw or brute force. Examples of weak ciphers would be: EDH-RSA-DES-CBC-SHA which uses 56-bit DES for encryption. Some people claim that MD5 is now a weak cipher. Either way, your organization probably has a list of approved and non-approved algorithms, and you’ll want to compare that list to what SSL supports.

You can use openssl s_client to see what algorithms your server is supporting (rather than just what openssl supports).

In the future, how to configure various web servers to support only the ciphers you want.

Applications, specifically web applications, often rely on e-mail to send out error reports to administrators and developers.  While e-mail can be somewhat unreliable in terms of delivering messages in a timely fashion, it is also insecure.  If your application’s error reports contain identifying information about users or sensitive details about your code and what made it break, you should be delivering these messages using encrypted S/MIME e-mail.

This tutorial will show how to send an encrypted message from a .NET application. (more…)