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.