The blogosuare is atwitter with news of an unfixable Windows 7 Hack being shown off at Hack in the Box by Vipin and Nitin Kumar. The exploit, VBootkit 2.0, sequal to VBootkit 1.0, is reasonably sophisticated. It boots off of removable media, reads the MBR, and then loads the OS, compromising OS files in memory to do all sorts of nefarious stuff. I haven’t found the whitepaper to 2.0 yet, but you can read the whitepaper to 1.0 here. 1.0 essentially targetted Vista, while 2.0 goes after Windows 7.

Now this is a pretty clever little exploit, but it isn’t an OS exploit. It targets one of the great maxims of computer security- if the system is compromised before your code runs, you cannot definitively restore integrity, or put another way, he whose code runs first wins. Windows code does not have an exploitable vulnerability, other than the assumption that the system booted securely, an assumption that *has* to be made. The Kumars deserve recognition for very effectively exploiting this assumption, but their actual attack vector is nothing novel.

We can continue to increase the pre-boot integrity controls and increase the sophistication necessary to access the machine, but physical access is still one of the easier ways to gain access to a box. That isn’t going to be a problem solved soon.

~ Joshbw

RSnake has a post on Google’s new image orientation test to detect humans (or computers, depending on your point of view), and quite correctly he points out that it is simply a probability game to break it. When it comes down to it, I don’t think we can definitively tell a computer and human apart with a specific cognition test, as it is just a matter of time before computational power and algorithmic cleverness solve that cognitive test. However I also believe we are thinking about CAPTCHAs the wrong way- we shouldn’t try to identify an automated script but rather we should make it too expensive for the script to be practical. Encryption can be broken with sufficient time, it is technically possible to just brute force AES 256, but this doesn’t deter its use. We know its problem space and work factor are sufficiently large to make brute forcing computationally impractical even if technically possible. The same principles should apply to the design of a CAPTCHA test, though it has many more constraining factors (it must be complex and hard for a computer, but easy for a human, and take into account human disabilities, etc).

So when new CAPTCHA techniques come out we shouldn’t immediately lambast them simply because they don’t provide the definitive test to distinguish a computer adversary, but whether they sufficiently increase the work factor. If they do, the spammers and other folks are going to opt to exploit a competing service with a lower work factor, because it will increase their throughput and arguably make them more money. In the specific instance of Google’s new proposal it would seem to reduce the work factor if one was simply guessing, since the chances of guessing the image orientation is much higher than a random 8 digit alphanumeric string, however with the advances in OCR techniques most alphanumeric CAPTCHAs are being analyzed rather than guessed (the success rate seems to change daily, so I don’t know how that compares to guessing the image). The real question is whether it is easier, faster, and more reliable to analyze the images and determine which way is upright, and I think that is entirely dependent on the images chosen as well as whether a correctly oriented comparison image can be obtained (which would make the analysis pretty easy) or if it had to be algorithmically determined without comparison (which may be hard). In the examples given, I think the gum ball machine and guitar are poor choices for images, since there is an easy linear line that can be used to determine orientation, probably with slightly better than 25% accuracy, since the line will either point up, down, left, or right, and the “weight” or proportions would allow for an educated guess on whether vertical or horizontal orientation is more likely. The more complex the picture, with less clues towards orientation, the better.

Personally, though, I like the MSR pet finder CAPTCHA. It may be easier to break, but I think it serves a noble secondary purpose.

~ Joshbw

I was paying my cell phone bill on the carrier’s website because I was lazy and waited until the last minute- in the process it occured to me, why do I have to fill out all of this credit card information again?  The short answer for this particular site was that I had recently moved and not updated my information with them, but in broader terms, why do I have to do that for every freaking website?  Why are companies so quick to want to handle payment information themselves?  The transaction charges may be a bit cheaper per transaction, but I cannot in any way imagine that dealing with the PCI DSS every year really makes the net process noticeably cheaper, at least if they are honest in their approach to the process.

At some point in the distant past I was paranoid about who I gave my card to, and was horribly discerning.  This site looks sketchy, or this site has a retarded security seal so is obviously not secure, or whatever, so they don’t get my business.  Despite this paranoia, I have had my card information stolen and used (or at least attempted to be used) three times.  In two of the instances my scary good at profiling my behavior fraud protection kicked in and charges never even posted to my account (there is something truly to be paranoid about- whatever profiling algorithms they use, they are horribly accurate about knowing your behavior), the third a handful of small charges hit my account in $20-$40 increments.  The thief was using the card information sparringly to sign up for membership websites, I believe, in order to steal contact lists to use for spam.  I reported the charges to my bank and they went away.  At some point I realized that it was impossible for me to control my card data, it was just as possible for a waiter to skim the information when they took my card as it was for someone to compromise a website and take it.  I can’t feasibly protect that asset, and banks know that, which is why consumers essentially have zero liability.  At the end of the day the banks want me to spend with the card, so they will do what the need to, accept some risk, in order to keep me spending.  I don’t worry about financial loss when my card gets stolen, I worry about the inconvinience in not having it for 10 days as my bank issues me a new one.

Which comes back to the point with my cell phone carrier- it was inconvinient for me to change my information on their site, and amazon, and netflix, and threadless, and thinkgeek, etc.  I would rather they simply all allowed PayPal as that way I only have to change my information once.  Moreover, I am more confident that one site that specializes in payment transactions will be able to save me the inconvinience of having a new card issued because they leaked the information than I am that a whole host of sites that accept payment as a small subset of their business.  In general I am not a fan of single sign on, but that is because it allows one point of failure to compromise multiple assets. With payment it is different, as it allows multiple points of failure to compromise a single asset unless you centralize it.

Using a centralized payment service isn’t just about saving me inconvinience though.  To tie back into the first paragraph, handling payment yourself is a pain in the ass.  Complying with PCI is non-trivial, and even if you think you are doing everything right, a QSA checking over your system may not agree.  On top of that, PCI is absolutely no guarantee that you are actually protecting card information, simply that you are in compliance, as Heartland (PCI gold member for the win) demonstrated.  You still have liability if you do have a breach of payment information.  With PayPal a third party is handling all of that headache- they are responsible for conforming to PCI, you have no payment information to leak, and the customer doesn’t have as much headache managing payment information.

There are drawbacks.  There is a danger of one or a few handful of payment systems like PayPal essentially becoming a payment monopoly (or duopoly) if everyone switched to centralized payment, which would effect prices.  The per transaction cost is higher, and a new login is introduced into the process flow on the website.  It also doesn’t work well for companies that may not know the exact charge up front, for example FedEx which gives you an estimated shipping cost but won’t apply the real cost until they actually weigh the package in their facility, and apply initial and revised charges to a card.  Finally, for those subscription based services, PayPal makes it really easy to centrally manage, which means they make it really easy to cancel.  Especially in this economy I doubt companies with reoccurring charges really want consumers to be able to look at all of their reoccurring charges in one place- they might realize where all of their money is going.

Still, I think being able to transfer the risk to someone else is a pretty compelling argument.

~ Joshbw

From XKCD:

Yesterday my debit card was deactivated. After calling my bank it turns out that a retailer I had shopped at (whom my bank very annoyingly refuses to disclose) had their card database ripped off, so my bank pro-actively canceled my card. I am a bit annoyed that my notification of this was my card being killed, and that I am now without a debit card for a week until the new one arrives (considering there isn’t a branch of my bank within 2000 miles of me, this is a bit more than an inconvenience), but I can’t be too pissed about the bank being so proactive about this.

There are also a couple of lessons that are apparent. First, the retailer seems to have been able to suppress the data breach. I am sure there is some agreement where they opt to notify banks but only if the banks keep mum about the breach. Second, I personally have no real risk associated with my card being compromised- it is annoying but I am not liable for any fraudulent charges and my bank seems very proactive about even preventing fraudulent charges to begin with. Third, the response seems entirely mundane. There is no big how-to-do. Data breaches have become so common place it is like finding out a politician is crooked. I think we are at the point where we assume a “when” rather than “if” mentality towards our cards being compromised, which is sad as it reduces the urgency towards security.

Furthermore, over the holidays (note to Bill O’Reilly, who according to twitter’s lack of login attempt monitoring, is apparently gay now [now I know why Colbert calls you Papa *Bear*], there are many holidays at the end of December, hence plurally referring to them as holidays rather than Christmas) I caught up with several family members, and it came out that most were not even aware of the TJX data breach, and even finding out, don’t care. We in the security community love to throw that around as the big example, but I don’t think we realize that it is an example pretty contrary to our message. Here is the largest credit card compromise ever, and most of their customers don’t even know, and those that do don’t really care. They suffered a pittance of expense as a result of the breach. The real lesson is that most people don’t care about credit card theft, it isn’t really a big deal, and successful handling of the media response can largely mitigate a breach. All of that sucks for our message to improve security.

But really, isn’t all of that true? To customers a credit card theft means worst case having to sit on the phone with your bank and go without your card for a while. Credit card theft is a regulatory head ache, but the real pain comes from true identity theft. This is where the title of this post comes in. Thinking about this I started hypothesizing where there is the risk of true identity theft. The places that have all of the information to steal id is a much smaller population, but many of them have really crappy security. Banks and financial institutions are an obvious choice, but they actually are usually pretty on top of things (relative to IT systems as a whole). However any place that accepts your credit information for financing are also likely targets- places like card dealerships, jewelry stores, furniture stores, and any other place that sells something expensive. Many of these places have very shoddy IT systems, pieced together by small local vendor shops who have no clue about security. As an example, my coworker went to buy a car from a local used car dealership that accepts credit applications over the web, password protected, however the forgot password functionality simply accepted the email address and echoed the password to the screen. Worse, if one entered the email address of a sales person (conveniently on their business cards they hand EVERYONE), you get an admin password, able to view all credit applications and results. So a would be attacker gets both absolutely everything they need to steal someone’s identity AND how much that identity is actually worth.

Also on the list of potential targets to get ID information are universities. The schools have all of a student’s demographic and personal information, often including bank account numbers for the deposit/withdrawal of money, but certainly SSN and birthdate (some schools even use SSN as the student number), maintain these systems well after graduation, and update them with information about alumni (where they live, work, etc). They are also renown for terrible security and are a perfect target for ID thieves.

So while all of the other voices are calling this the year of webappsec and such, I am in disagreement. I think we will see some big pushes at big companies, but we will also continue to see big blunders at big companies. I further think it will be years before general webappsec knowledge is prevalent enough to protect places like local car dealership websites, and university IT systems, and as the big boys get locked down we will increasingly see attacks against these smaller, and in some ways more lucrative resources (blackhats get fewer but more valuable records with less effort). This may be the point we get enough momentum to start moving security, but it will be a long time before this momentum has an effect on the average consumer.

~ Joshbw

In a recent conversation with a colleague on SSL and how it worked, it occurred to me that I really had no idea what extended verification certificates actually did, other than turn the address bar green and display the company name. What was the “extended verification” that made EV certs better than normal certs? In a normal SSL connection the client can do a reverse lookup based off of the cert to verify the host, but DNS poisoning would obviously render this worthless. Do EV Certs have some magic in their “extended verification” that addresses this shortcoming?

In a word, no. There is no technical advancement in the EV cert. There is no technology that makes the EV certificate a better option than a normal cert, that works around the weakness of the regular cert in verifying hosts. What the EV means is that the cert authority no longer does a half-assed job verifying that they are issuing a certificate for a particular company to that company. They do a bit more background checking so that they can attest that the company listed in the cert is really the same company requesting it. It is brilliant marketing, as you are paying double to three times the cost of a normal cert just to turn the address bar green and to get the CA to actually do some checking on who requests a cert.

The thing is, despite the fact that there is no technological benefit of this, and the fact that current cert prices should have already included verifying the requester, that stupid green address bar is probably worth the money just to increase customer confidence. But go ahead and be bitter about it, since that shade of green is going to cost you another grand for each certificate. Man is Verisign brilliantly evil in their product ideas, right up there with the guy who conned children into buying pet rocks.

~ Joshbw

Well, you announce that you are going to post a whole bunch of information, including technical details, in a whitepaper through I Hack Charities so that a whole slew of AppSec folks and web hackers go register. Then you notice that the registration is page is in the clear.

Now granted, the whole payment solution is through paypal, so other than your credentials there isn’t much to steal, but seriously Johnny, couldn’t you get Verisign to donate SSL certs for charity?

~ Joshbw

A blacklist file was found by an iPhone hacker and the internet is all abuzz over the possibility that Apple has a kill switch for applications. Well of course they do- Apple clearly shows by their insistance on the App store that they will control what gets run on the device- but I don’t think the blacklist file mentioned is that mechanism. Showing up in the location cache is a really sketchy area to put a file that blacklists applications, unless it is an exceptionally stupid instance of security through obscurity, so I think people misunderstand what it is for.

Now if I were Apple and I wanted complete control over what ran on the device I would only allow the device to run signed applications so that both the identity of the app author can be checked and the integrity of the binary can be scrutinized. I would insist on being the only CA, which I could do because all apps have to go through my store *anyway*, so why not include issueing certificates in the whole deal. I would then publish a certificate revocation list via SMS at regular intervals so that the user has no control of when an app gets blacklisted and I can count on it being pushed to the device.

This isn’t a foolproof design but it does provide pretty decent control over the platform. In essence it isn’t really any different from what console manufacturers do. People seem willing to accept that they don’t actually have control over the device the bought, and have certainly been willing to deal with the draconian oversight of cell carriers for years, so they would very likely accept this from Apple. So what if they suddenly lost they ability to use an application that they ultimately purchased from Apple?

Is this what Apple is doing? I don’t know. But given their aims it seems the best way to do it. I hate touch screen interfaces no matter how slick they are done, so I won’t be investigating myself.

~ Joshbw

It is now Joshbw, CISSP. I don’t think the cert says a great deal specifically about my App Security knowledge, that being a ten mile wide, inch deep sort of certification. The test wasn’t any less a pain because of it though, and at least it says I have the fortitude to make it through the long nights studying the optimal height and candle power of external lighting, how far away backup facilities should be, 8 million different security models, and what the initialization vector length of each encryption algorithm happens to be.

~ Joshbw, CISSP