Monday, September 8, 2014

VMware / VirtualBox Kernel Headers for Kali

In /etc/apt/sources.list:

deb kali main non-free contrib
deb-src kali main non-free contrib
deb kali/updates main contrib non-free

apt-get update && apt-get install build-essential linux-headers-$(uname -r)

Saturday, November 23, 2013

Oracle Listener Information Disclosure

The other day I noticed a strange response I hadn't seen before when running a VERSION command against an Listener:

It seemed as though the Listener was leaking memory.

I was able to reproduce this issue across other nodes in the RACs I had access to. Instead of the standard 348 byte TNS VERSION response

I was getting a 2011 byte TNS response:

I was also able to reproduce the result by running the VERSION command locally using the lsnrctl utility.

With a bit of digging it seems as though Listeners with CPU April 2012 (patchset 13621679) are vulnerable to a memory leak issue. Most likely due to a buffer not being terminated/copied correctly.

This flaw could potentially come in handy during a pentest when trying to enumerate SIDs/Service names:

I was unable to reproduce this flaw on Listeners patched with CPU July 2012 (patchset  13923474) -- meaning Oracle are most likely wise to the issue...

Note: I was able to notice this issue as I was using Metasploit's tnscmd module. Unlike the tnsversion module, tnscmd outputs the full TNS conversation and not just the 348 bytes of the version string.

Saturday, June 15, 2013

S/MIME: Bucking the phishing trend

In recent years, phishing has become an increasingly profitable attack vector for online scammers. According to RSA’s The Year in Phishing (2013) report, the total number of phishing attacks in 2012 increased by 59% and resulted in global losses of $USD 1.5 billion. With this upward trend in online fraud predicted to continue, it’s pertinent to take a look at how these attacks are so successful and what can be done to buck the increasing trend of online fraud.

Phishing is the process whereby someone (malicious) masquerades as a trusted entity to solicit information. Relying on the art of deception, these attacks fair particularly well online as people are less likely to pick up on the fraud cues. Phishers frequently target email as their preferred attack medium due to its lack of security controls – in particular, the absence of authentication.

The critical issue surrounding email is trust. That is, how can we trust an email has come from who it purports to come from? If we look at how this problem was solved on the World Wide Web, we find SSL was the answer. Through the use of certificates, users are able to establish a level of trust online by validating the identity of the website. As it turns out, this method of trust establishment through a certificate can also be used for email and it’s called S/MIME.

S/MIME, or Secure MIME, has been around since the early 2000’s and uses public key encryption to digitally sign an email message. Recipients of an S/MIME email can verify the authenticity of the email by simply checking the attached certificate. If the certificate has been issued to (and by) someone they trust, then they can be assured the email is authentic.

So if S/MIME has this capacity to solve the online trust issue with email, thereby putting an end to the effectiveness of phishing attacks, the question must be asked: why is it so seldom used? In this author’s opinion, vendors of email clients have done a poor job at both promoting and implementing this technology. To provide some perspective on some of the shortcomings of S/MIME implementations, I would first like to take a look at one of the ways trust has been improved on the Web.

Over the last few years, browser vendors have made significant inroads into making it easier for non-technical people to make informed decisions regarding website trust. They've done this through the use of visual identifiers. If we look at the three main browsers in use today (Internet Explorer, Firefox and Chrome), we see that that they all utilise a key visual (the colour green) in the address bar to indicate a trusted website.

If we now compare this to how three of the most popular email clients (Outlook, Mac Mail and Thunderbird) deal with a digitally signed S/MIME email, we see a stark difference. There are no real obvious key visual indicators to emphasize the email is trusted.



Mac Mail

Another example where browsers have improved on trust is where certificate violations are concerned. As an example, if we were to visit a website where the Common Name (CN) on the certificate did not match the URL, we would receive the following message:

These messages are important as they indicate to the user a clear violation in trust. If the CN did not have to match the URL, anyone could purchase a certificate with a bogus CN and apply it to any website. This would defeat the purpose of the certificate trust model.

To see how the three email clients would fair against a similar test, I put together a digitally signed email where the email’s From address does not match the Email Address attribute on the X.509 certificate. From this, we get some interesting results:

Mac Mail

First off, we see Mac Mail does the best job at warning the user of a trust violation. Thunderbird also has an (albeit discrete) identifier to indicate there was a problem. But more interestingly, Outlook does not flag this as a violation and provides no warnings at all. Going unfixed, this loss of integrity issue has the potential to cause problems.

Let’s say, for example, Company X implemented full PKI and employees knew only to trust emails that had been digitally signed. To get around this defence, a scammer could exploit Outlook’s loss of S/MIME integrity by purchasing a certificate. They could then digitally sign their phishing scam and send it with a spoofed From address of a Company X employee (remembering the Email Address on the certificate doesn’t have to match the From address). Company X employees would be none the wiser this email was not authentic, subsequently leading to compromise and thus defeating the purpose of deploying S/MIME in the first place.

I feel the threat posed by current phishing trends is significant. My hope is this post facilitates some discussion within the security community around the issue of email trust and reenforces the importance of email security and S/MIME.

Saturday, June 16, 2012

Password Hashing: Best Practice

Last week I read a post on Brian Krebs’ blog where security researcher Thomas Ptacek was interviewed about his thoughts on the current landscape of password hashing. I found Thomas’ insights into this topic quite pertinent and would like to reiterate his sentiments by talking a little about the importance of choosing the right password hashing scheme.

The idea of storing passwords in a “secret” form (as opposed to plain-text) is no new notion. In 1976 the Unix operating system would store password hash representations using the crypt one-way cryptographic hashing function.  As one can imagine, the processing power back then was significantly less than that of current day standards. With crypt only being able to hash fewer than 4 passwords per second on 1976 hardware, the designers of the Unix operating system decided there was no need to protect the password file as any attack would, by enlarge, be computationally infeasible. Whilst this assertion was certainly true in 1976, an important oversight was made when implementing this design decision: Moore’s Law.

Moore’s Law states that computing power will double approximately every two years. To date, this notion has held true since it was first coined by Gordon Moore in 1965. Because of this law, we find that password hashing functions (such as crypt) do not withstand the test of time as they have no way of compensating for the continual increase in computing power. The problem we find with cryptographic hashing functions is that whilst computing power continually increases over time, password entropy (or randomness) does not.

If we fast-forward to the current day environment we see that not much has changed since the early implementations of password hashing.  One-way cryptographic hashing functions are still in widespread use today, with SHA-1, SHA-256, SHA-512, MD5 and MD4 all commonly used algorithms. Like crypt on the old Unix platform, these functions have no way of compensating for an increase in computing power and therefore will become increasingly vulnerable to password-guessing attacks in the future.

Fortunately, this problem was solved in 1999 by two researches working on the OpenBSD Project, Niels Provos and David Mazieres. In their paper, entitled ‘A Furture-Adaptable Password Scheme’, Provos and Mazieres describe a cost-adaptable algorithm that adjusts to hardware improvements and preservers password security well into the future.

Based on Bruce Shneier’s blowfish algorithm, EksBlowfish (or expensive key scheduling blowfish), is a cost-parameterizable and salted block cipher which takes a user-chosen password and key and can resist attacks on those keys. This algorithm was implemented in a password hashing scheme called bcrypt.

Provos and Mazieres identified that in order for their bcrypt password scheme to be hardened against password guessing, it would need the following design criteria:
  1. Finding partial information about the password is as hard as guessing the password itself. This is accomplished by using a random salt.
  2. The algorithm should guarantee collision resistance.
  3. Password should not be hashed by a single function with a fixed computational cost, but rather by of a family of functions with arbitrarily high cost.
The first two points here are fairly standard among password hashing algorithms. The last point, however, is somewhat of a different concept to what we are used to seeing.

If we think about cryptographic hashing functions in use today - be it MD5, SHA-1, or MD4 - we notice they all have one thing in common: speed. Each of these algorithms is incredibly quick at computing its respective output. As hardware gets better, so too does the speed at which these algorithms can operate. Whilst this may potentially be seen as a positive thing where usability is concerned, it is certainly an undesirable trait from a security standpoint. The quicker these algorithms are able to compute their output, the less time it takes for the passwords to be cracked.

Provos and Mazieres were able to solve this problem by deliberately designing bcrypt to be computationally expensive. In addition, they introduced a tunable cost parameter which is able to increase the algorithm’s completion time by a factor of 2 each time it is incremented(effectively doubling the time it takes to compute the result). This means that bcrypt can be tuned (i.e. incremented every 2 years) to keep up with Moore’s Law.

Let’s have a quick look at how bcrypt compares against other hashing algorithms. Let’s say we have a list of 1000 salted SHA-1 hashes that we wish to crack. Because they are salted, we can’t use a pre-computed list of hashes against this list. We can, however, crack the hashes one by one. Let’s say on modern hardware it takes a microsecond (000000.1 seconds) to make a guess at the password. This means that per second we could generate 1 million password guesses per hash.

In contrast, say we have the same list but instead of SHA-1 the hashes have been derived using bcrypt. If the hashes were say computed with a cost of 12, we are able to compute a password guess roughly every 500 milliseconds. That is, we can only guess 2 passwords a second. Now if you think we have 1000 password hashes, we can only generate 7,200 guesses per hour. As it would be more efficient targeting all 1000 hashes (as opposed to just one), we would be limited to approximately 7 guesses per hash.

Below is the output of a quick program I created to display the time it takes to compute a bcrypt comparison as the cost value is incremented. The test was conducted on a RHEL system running a Xeon X5670 @ 2.9Ghz with 1024MB of memory.

The source code for this program can be found here.

The bcrypt password hashing scheme is currently available in many languages including Java, C#, Objective-C, perl, python, and Javascript among others.

I hope this post highlights the importance of using stronger password hashing schemes for modern day applications.