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

In celebration of Facebook’s recent privacy control revamp, I present a very informative tutorial video from the Electronic Frontier Foundation that gives a brief rundown of the changes, the highs, and the lows. This might also be something beneficial to share with friends or relatives on Facebook who may not be in-the-know about the increased focus on privacy control in social networking and social media.

Enjoy:

PDF files have become commonplace on the Internet and in the business world, but they have also become favorite tools for attackers to deliver malicious payloads. While some problems may be mitigated by using an alternative PDF reader, many people have little choice but to use the standard Adobe Reader. In that situation, you can help protect yourself from many PDF-based attacks by following a few basic steps.

1. Make sure you have an up-to-date anti-malware program installed and running with automatic download of new virus definitions. Older tools may not scan for recent PDF-based threats.
2. Make sure you have the latest version of Adobe Reader. Enable automatic updates by opening Reader and choosing Edit > Preferences > Updater. Adobe regularly issues patches against new vulnerabilities.
3. Disable JavaScript in PDF files. This may affect certain features at times, such as PDF-based forms, but it’s better to enable JavaScript only when needed. In Reader, click Edit > Preferences > JavaScript and uncheck the box for “Enable Acrobat JavaScript.”
4. Disable Flash and multimedia in PDF files. Once again, this may prevent a few documents from loading some content, but embedded Flash is a common tool for exploiting Reader. Go to Edit > Preferences > Multimedia Trust (legacy) and either uncheck “Allow multimedia operations” or change the permissions on each listed player to “Prompt.” Be sure to check the settings for both trusted documents and other documents by changing the “Display Permissions for” option.
5. Disable attachments. Earlier this year, security researcher Didier Stevens uncovered a PDF behavior that could be used to launch commands outside of Reader. To avoid this problem, open Edit > Preferences > Trust Manager and uncheck the box marked “Allow opening of non-PDF file attachments with external applications.”
6. Configure your browser to show a download prompt for PDF files. The exact settings for this step will depend on your browser. Remove any plug-ins or add-ons for Adobe Reader, and check the settings for how your browser handles various file formats to check the behavior for PDF files. If you allow PDF files to open in the browser or open in Reader automatically, you may accidentally open a malicious file without realizing it.

These precautions are only a small part of keeping your computer protected against attack, but they will go a long way to help you avoid many threats involving PDF files.

Browser security is a topic that spans a wide range of subjects. This isn’t surprising given the number of exploit techniques that rely on webpages as a primary delivery channel in their attacks. Successful XSS, CSRF, SQL injection (via web app), and plug-in-based attacks all take advantage of the environment provided by the web browser.

Despite the importance of the browser in the chain of security, information on exactly how it goes about managing javascript across domains and determining when to show the “save as” download dialog can be overlooked. However, this is an area where attackers may concentrate their efforts to hedge out new exploits based on a weakness in browser security.

The Browser Security Handbook, released in 2008, is a frequently-updated information repository for all things dealing with modern browser security. It includes the methods presently employed by various browser vendors to improve the security on the application end, as well as some experimental techniques.

It’s certainly worth adding to your collection of security-related links.

http://code.google.com/p/browsersec/wiki/Main