BIOS Attacks and Quasi-FUD

Per @mhandelman's request I am responding to a recent write-up of Core Security's BIOS rootkit attack presented at CanSecWest.

Some topical, albeit not significant issues I had with their write-up was the misspelling of CanSecWest as ConSecWest. Minor issue, but it reminds me of the Obama / Osama screw-ups that say more than they mean to. Also, Ars doesn't even link to the PDF at Core's site; that could have been just bad timing, but at least let Core see who is interested in the PDF...

Anywho, on to substantive ranting...

From the article, last paragraph:

This is not the sort of exploit that anyone bothers with on a grand scale. Not only is it highly impractical, it's also pointless—why go to so much trouble to infect a PC running at a Ma and Pa store if you can spend a hundredth of a cent and send them an infected e-mail they'll open and run?

"This is not the sort of exploit that anyone bothers with on a grand scale":
Orly? While I'm against FUDcasting, it's also disturbing to see a widely-read technical column wholeheartedly discount a new, and in my opinion, attractive attack vector. Do they know that people are now not viewing this as a new attack vector? Have they sent out surveys to malware authors asking them from 1 to 5, if they would consider this vector? I don't know the answer, so I am not going to discount right out of the gate an attack vector. Time will tell. But my guess is that Ars did not do any homework to back up their claim.

"Not only is it highly impractical [...]":

Hmm, also from the article:

"I haven't seen the full text of their presentation [...]".

K., if you're going to say something is impractical but you haven't seen the presentation, then, really? You're gonna say it's impractical? I haven't read the notes either, nor was I at the presentation. I did read this in the PDF from Core:

Real hardware demo

• We infected an Phoenix-Award BIOS

• Extensively used BIOS

• Using the VGA ROM signature as ready-signal.

• No debug allowed here, all was done by Reverse-Engineering and

• later, Int 10h (Not even printf!)

• Injector tool is a 100-line python script!

So, they're able to inject into an extensively used BIOS with an 100-line python script. And, that's impractical? I would at least ask for clarification from Core before stating without any other reason something is impractical. To me, just from the same source, I see that being very practical. Getting root / Administrator on a machine is not impractical, especially if the target is a single-user computer where the user has granted him/herself Administrative rights.


"[...] it's also pointless—why go to so much trouble [...]":
Orly? If I was a malware writer, I would really like the idea that, regardless of someone reinstalling Windows on their PC, I would be able to reclaim control. So, instead of the lather-rinse-repeat cycle of current vulnerabilities, exploits, and targets, I now have command and control of a device ad infinitum, or at least until the BIOS is re-flashed.

While I generally, and subjectively, agree that complex attacks to me do not seem attractive, I also do not discount them. Let the numbers speak. Wander over to Dan Kaminsky's blog at Doxpara and read up on infrastructure attacks, discussed by ZDNet. Whilst not getting bogged down on defining a complex attack, the psyb0t worm seems pretty complex to me. I am not siding one way or another that injecting nastiness at the BIOS level is going to happen or not. And, in that breadth, again, I am not discounting it.

The author seems to discount, without objective reasons, an attack vector that has the potential to be nasty in the future. I just don't know why. It's not FUD. Hmm, I'll call if FID: forget, ignore, discount. So, to me, Ars is promoting FID. That's my beef.

Jon

Too Much Information

I have Pete Lindstrom's blog, Spire Security, in my RSS feed. I first met Pete at Metricon 2.0, with Gunnar Petereson's introduction. My first impressions were he liked to talk and he wouldn't let other people get a word in edgewise (unless you were rude by Midwestern standards). But, reading Pete's blog and writings have been rewarding because Pete has good, logical points.

I recently commented on The Disclosure Race Condition posting Pete wrote. I was unclear on some of his argument points and assumed he was taking a stance he wasn't:

It is clear from this case that many large security companies already had the information (they already had samples), so the added benefit to the "good guy" community must be adjusted with that information in mind.

I assumed that Pete was stating the vendor provided samples to the many large security companies. This was a red herring that I continued into my second comment. If I can finally paraphrase Pete's argument, it's that the detailed information released by Sourcefire et al. mostly aids evil doers and does little to aid the good guys.

After reading the post a couple more times (yeah, I'm that daft sometimes), I tend to agree with him. The information released is very technical in nature and in my opinion can only help the good guy community if it highlights hitherto unknown bad programming design patterns. Those that need to know, i.e., IDS vendors or the vendor in question, can get the information they need through their own efforts. I also do not think it puts the vendor under more leverage to release the patch sooner, either, because of a lack of empirical data and also intuition (this was not brought up by Pete). I can definitely see information sharing that Shadowserver.org provides a benefit, though. They acted as an information broken which allowed Sourcefire to protect their customers in a timely manner. So, to abuse Kevin Soo Hoo's Stanford masterpiece, how much is enough (or too much?)

To go into more detail, I accept the idea that the existence of N sources of some vulnerability information increases the possibility of M sources, where M < N. This would, in Pete's argument, affect the cost-benefit analysis of the attacker to obtain information on how to exploit some vulnerability. Lowering the attacker's cost compared against whatever return or penalties would only aid in enticing the attacker to perform the attacker. I get that. And Pete did qualify the magnitude of the effect of reducing N sources as possibly being slight in his comments. But, this would be scoped for only the vulnerability/ies in question. That is, it would only reduce the risk to whatever assets for those specific vulnerabilities whose detailed information was not released.

Of course, if this was done broadly, then in general vulnerability information would be more constricted and probably raise the cost-benefit equation of the adversary. I dunno though if this overall would actually reduce the risk. It's hard to say. We're smarter than we were in the early 90's, but that doesn't mean we're better. Would we have 16 year olds writing worms that impact Fortune 500 networks? Probably not. But, again, that's not the only threat we face or risks that are present. It also still emotionally feels dirty that the censoring of information somehow reduces risk... Dunno why, but it does.

Talk amongst yourselves...