So apart from asking the business what they believe these impacts are what other ways can be used to gather this information? Well, if you’re fortunate enough you might be able to gather this information from other sources, such as from those fantastic people whose job it is to manage and deliver services to the business. Those same people who’s responsibility it is to monitor SLAs. If these people are monitoring service levels closely (such as transactions within a commerce application) then they will probably have metrics such as, this application performs x number of transactions per day (month, year, whatever).

All of a sudden a loss of availability isn’t just a loss of service, but a quantifiable value. If this application server goes down then you are losing x transactions per day. If each transaction provides on average $y profit then it gets even better. You get the picture. But not only do you get the picture, now your stakeholders can be given a fairly clear indication of what a loss of availability will cost them on a specific time period.

While this scenario is great for looking at the cost of impacts against availability, what does it do for loss of confidentiality or integrity? Not a lot unfortunately. I just felt like giving big-ups to those people at my work who have been doing a great job at compiling more metrics about all of our applications than I can point a finger at!

The concern is of course that people are slowly coming to understand and accept a lot of the principles around applications served up by the web such as Gmail, and slowly it appears as if people and corporations are starting to grow more at ease with Google and their techniques of encapsulation or “clouding”. I don’t think this principle applies to thick-client apps like Chrome. If Google are going to patch a number of undisclosed vulnerabilities in an open source app then I have concerns. (Is chrome open source? someone correct me if I’m wrong).

In fact, I think companies like Google would benefit from disclosing the inner workings of the cloud. Sure, a number of people don’t want or need to know what goes on, but I know that there are probably enough people out there that would want to know. I think as long as people don’t have to “worry” about what goes on in the cloud is more important than trying their hardest to leave everyone in the dark. I mean, sure, when I open up the bonnet of my car I have no idea what I’m looking at, but I would be much more concerned if there was no way for me to open the bonnet. Just imagine having no clue what was under the hood, is it full of elastic bands and plastic, or bees, or is it an empty cavity?

In a previous role I spent the majority of my time configuring and working on electronic access control systems, so I’m aware of how much physical and logical security have meshed together. Our security posture was fairly straight, we followed a number of principles such as defense in depth, secure defaults etc. One of the overriding principles we had was that of the air gap. That is, the system that controls those doors, does not come in contact with the Internet or any other networks that pose significant risk. So it doesn’t fill me with comfort when I read about new products like this.

Schlage LiNK deadbolts operate using keyless entry with four-digital access codes on an 11-digit keypad. The LiNK deadbolts can also be operated using Schlage’s LiNK Web portal, which employs Secure Sockets Layer (SSL) protection.

Schlage LiNK deadbolts leverage Z-Wave, a wireless home automation technology that helps to unify home electronics into a single integrated wireless network using Z-Wave accessory modules — everything from lighting to temperature control, pool systems and more.

Personally I would have some concerns about linking my front door to the Internet or a wireless network, but that’s probably just me and the security/risk hat I wear. What concerns me is the people doing the sales pitch for these sorts of devices would not be ensuring that the consumer is doing a risk assessment against their use, the only assessment the consumer has to do is “can I afford it?” or “how cool will I look when I can unlock my door from work for the plumber”.

Would the consumer be enquiring into the level of diligence that the producer had applied to ensuring the security of their locks and their web portal? Probably not. The sales pitch would probably go something like “Yes of course we are protected over the Internet, we utilise Secure Sockets. Yes their secure, those same sockets are the same that get used by your bank”.

For all the bleeding-edge customers of these locks their fortunate because the probability that someone wanting to get in their house without authorisation knows about the technology is low, so contact with an external threat source is also low. On the other hand, the probability that people with malicious intent will want to break into the web portal is probably quite high, not strictly because they want to break into the house, just because the portal is a juicy target. The impact of this event is potentially much larger though, because if the vulnerability of the portal is such that you can enumerate doors, it means you may be able to unlock a large number of doors. This isn’t taking into account how easy it is to phish users of their passwords and simply log into the portal as them, maybe it utilises some form of two-factor? In which case you may as well just give them a key.

• 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”.

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..

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

And uncanny how much that reminds me of my work!

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.

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?

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.

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.