It has been known for a while that a Firewire port can own memory, but it is getting new traction now with the “cold boot”/”memory remanence” attack on laptop FDE. Adam “Metlstorm” Boileau has released his python script that can unlock a Windows box through the Firewire port. Keep in mind this accesses memory (RAM!) to do its dirty work. I’ve seen announcements to this here and here and many more places.

I can’t confirm this, but I think this attack requires connecting a Linux box to a Windows PC via Firewire (you can just do this directly), running a tool (tar.gz) to gain DMA access (Direct Memory Access), and running the python script on the Linux box. The script can cause all passwords to succeed on a locked system, can just unlock a system, or pop up a shell at the winlogon prompt (basically get into the system without logging in). I’ve not tried this, but I think this is as simple as it gets.

The mitigation to date is to turn off your firewire ports when they are not in use or not allow anyone else physical access to them.

Boileau has released it on his own site (scroll to the bottom) and there is also a mirror up. His presentation (pdf) is still available on the topic as well.

More information about dumping memory via firewire (pdf). Some likely outdated info on connecting 2 PCs (Windows) together using only Firewire.

I would expect the gentlemen at Hak5.org to demonstrate this on a future episode. 🙂 Hell, if someone is looking to get some hits, whip up a video of this in action, demonstrating in a how-to format.

Hoff pointed over to James McGovern who posted a list of 10 mistakes the CIOs consistently make that weaken enterprise security. I want to highlight a couple things. Take your time reading McGovern’s post, since it does seem a little muddled and sometimes packs 2 distant points into one bullet item (see: ostrich principle). In fact, I don’t necessarily agree with a few of these, as worded.

Use process as a substitute for competence – I see this in IT as well as security, and sadly, it is a natural business reaction to any little thing that goes wrong that costs the company more than $5. Someone put a can in the paper recycle bin on accident! We must investigate, formulate a new process, and ensure that this never happens again! Right… I am fine with improvement, but business too often gets ridiculous about this, covering up incompetence with processes. Carry this on for a few years, and you have lots of fluff and frustration and few real answers. Some would call this a “bigness mentality.”

A trend I see in McGovern’s post covers the superficiality of many security endeavors. Rather than actually making a difference or tackling root problems, many points he brings up deal with avoiding the problems, or implementing shallow fixes which aren’t fixes at all. Some people purposely do these things, but I feel that most of these are a symptom of a lack of empowerment and competence. Business must empower security professionals, but they must also get and train up competent professionals. Taking either leg away can result in the things McGovern is pointing out.

And some things I think could be better worded.

Putting network engineers in charge of security – This is pretty general, as I’m sure there are plenty of network engineers would could excel when managing more security than just the network. An inference from what McGovern has said is security practioners need to know everything. I think what McGovern is really trying to say is to make sure the people most qualified to secure XYZ are the people who know the most about XYZ. Network engineers can secure the network; application developers can secure applications. But finding someone to do them all is like trying to find that silver bullet box that will provide everything. Ok, so there are some all-stars out there who can get their hands in it all, but waiting to find them is not a practical expectation. Here’s a question, though: Let’s say you have a kickass, security-aware network engineer. If you put him in charge of security, what risk are you still leaving open? If your application gets pwned, can he still detect it, monitor it, maybe even limit the exposure? Perhaps. Will he be able to fix the application? Most likely not, but he can certainly be a huge part of the security team.

Hoff throws a few nuggets in as well.

Security is top secret, we can’t talk about what we do – This is natural to us security guys. We don’t like to tell people about our measures because then people can avoid them. If we utilize hidden cameras but talk about them, then an insider can just hide their face at the appropriate times to thwart identification. Likewise, we tend to think like attackers, which means talking about our security measures is something done from the negative side: by talking about ways to get around our security measures. It’s like defining brightness as the absence of dark properties; the strength of our security by how easy someone could cover the security camera. But that’s not how we really should be when asked twice about security. We should make our jobs transparent as much as security allows. A lot of our need to “align with business” is simply being transparent with our controls.

I’ve finished up my part in the 2008 Winter Scripting Games. I pretty much stuck to PowerShell Advanced and also some of the Sudden Death events due to time constraints. I skipped anything not specifically code-related. I’m happy with the events, and very happy that I was able to complete all the Advanced events in only about 3 days of effort. Other than last year where I actually didn’t finish one event, I expect a perfect this year.

My submissions are compiled on the wiki page.