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 1 Comment » 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