Ever read a security article that makes you hurt with every sentence written? Yeah, not too often, but this article in The Register about a data breach nine months ago at the Pentagon that had “an amazing amount of data” stolen, offers up a lot of hurt. I can’t even quote the bad parts since the whole thing is an escalation (or downward spiral!) into needing a few stiff drinks before lunch.

And sometimes, just sometimes, sentences offer up Hurt Combos, like this one:

It took three weeks and $4m to clean up the mess.

Ok, that shows off how bad this issue was, but it also hurts to remind us just what it takes to spend money to get shit done. We (the US) spent $4m in 3 weeks…can’t we do that to prevent the amazing number of issues packed into this little article/incident? This article absolutely begs disclosure on what the hell happened.

Ask.com has been an also-ran search engine for some time, and is going through some changes. I think part of their problem is their name: Ask.com. Ever try talking to someone about Ask.com? Say it out loud a few times conversationally. Yup, it sounds like you’re talking about Ass.com. That just can’t be good.

Then again I thought HD-DVD would beat Blu-ray because my mom knows what HD-DVD means, but has no clue about Blu-ray. HD + DVD? Must be better DVD! I guess I didn’t take into account the pockets Sony had…

This is an amusing story. Supposedly a hacker has broken into a new site and has been posting plagiarized news posts to discredit the company…for the past 2 years?? No one noticed until last month. What an amusing, devious hacker! I’m surprised more people don’t blame the nebulous, mysterious, all-powerful hacker for lots of things going wrong. Global warming? Hackers! Hell, it was hackers that made Doom and all these demon-devil killer games popular! Hackers play D&D, create bombs out of computers, and torture squirrels!

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.

Think someone is using Wireshark to listen to your network? Why not throw out traffic meant to crash Wireshark? Looks like a few have been reported recently.

Well, it has started. Nice to see!

As mentioned by Nate Lawson and illustrated by fellow Security Catalyst Didier Stevens, the cold boot attack against FDE applications is not limited to just FDE, but any program that stores keys in memory.

This is a much bigger problem than just an FDE problem, but it is still far outside the vision and concern of regular users, at least today and likely this year. Didier’s approach to grabbing information out of memory while logged in should be of more concern than a cold boot attack.

So before your auditors require you to put the question, “How do you manage keys in memory?” to your FDE vendor questionaires, make them apply it against every application your organization makes use of or creates.

The recent “cold boot” or “memory remanence” attack against keys stored in RAM (particularly against FDE vendors) has gotten good publicity, including mainstream media. I passed along information to my team, which then got up all the way through the top of my organization partially because we’re just about to roll out an FDE product. What did I recommend or say?

I quickly (2 paragraphs) and in mostly non-technical terms described the attack. Then, in a small FAQ-style section, explained that we are not at much risk of this attack. Memory dumping is not new, nor is memory dumping from recently powered-off memory. Can Joe down the street do it? No. Would Jess after lifting your laptop from the airport queue line crouch in a corner to start freezing your memory? No. Even if tools became available to boot a laptop to USB and quickly dump memory for offline scraping/cracking, this is still not a huge problem.

Bottom line: Is this something that an average computer (laptop) user or average corporate user care about? Seriously, no.

This sort of attack would be of interest to government units, defense contractors, and others who might be subjected to targeted, highly motivated, and decently funded attackers. National or major corporation espionage comes to mind. This attack is also of interest to us security geeks. Not only is it cool, but it keeps us thinking outside the box. It also keeps vendors honest and working towards better security.

What mitigations are there?

Reduce laptop theft risk.
Power off the laptop when it is not in use.
Don’t keep valuable data on mobile devices.
Use advanced multi-factor authentication.
Enforce proper password complexity and age requirements.
Limit booting from removable devices or use a BIOS password.

None of these steps should be very new to organizations, and certainly not to any organization that should care about the cold boot attack. All of the above steps should take much higher priority to all of us.

I don’t follow Bruce Schneier as much as I used to, but I do believe he has a good point when he talks about how badly humans evaluate and react to risk. We see risk and get all dramatic when it comes to low probability but exotic issues, yet ignore common issues that wouldn’t make a Hollywood movie script. This attack is exotic and not common.

I was browsing around somewhat randomly and came across this little list of challenges for people looking to get into security. Kind of a cheesy thought, but then I started reading the tasks and really liked them. Some get old school, but damned if security pros really should be exposed to some old school things like IRC or email via telnet.

If you know someone who is looking to get into security a bit more, these are very basic and useful tasks to give them. Even a tech geek that hasn’t had an interest in security should find some of these tasks horizon-expanding.

Snagged from beginningtoseethelight.org.

It’s been about 5 years since I built my gaming machine. Yup, it’s about time to build a new one and I thought I would share some specs. This system is not built yet, but I am already starting to get pieces in. The total cost minus the toys and monitor will be slightly over $1,000. I will buy almost every piece from NewEgg.

The system I want should stand up to about 3+ years of upgrading. For now, I skimp on some parts that are easily upgradable, and splurge on things that are not. I stick to a nice motherboard that no doubt has at least 2-3 good years of high/middle-end gaming in it. It will support most any Intel dual or quad core CPU that will be on the market this year. I can go up to 8GB DDR2-1200 RAM and plop in 2 ATI Radeons in Crossfire mode (basically use dual graphics cards instead of 1). I doubt I will ever do dual graphics or that much RAM, but the options exists! I like a decent case that I can show off, so I don’t go cheap there either.

I normally would not have gotten a high-end PSU like I have listed below, but I picked up the Antec 850Watt PSU from a closing CompUSA for under $100. I couldn’t pass that up.

This will all be cooled with a water cooling system I’ll build. I’ll most likely get all of the water cooling parts from PetrasTechShop or maybe a few from FrozenCPU.com. I’ve used FrozenCPU for my last system, but I’ve not tried Petras yet. The parts are individually listed below. I choose water cooling because it keeps the system far quieter than if I relied entirely on air cooling. That and it looks cool!

Logitech G15 keyboard
Antec TPQ-850 850watt PSU
LG L226WTY-BF Black 22″ 2ms DVI Widescreen LCD Monitor x2
Lian-Li PC-60BPLUSII W Black Aluminum ATX Mid Tower
Asus P5E LGA 775 Intel X38 ATX Intel Motherboard – up to DDR2-1200 1333/1600 FSB
Intel Core 2 Duo E6550 Conroe 2.33GHz 1333 FSB
Corsair XMS2 2GB (2 x 1GB) 240-Pin DDR2 SDRAM DDR2 800 – 4s cas latency
Diamond Viper 3870PE4512SB Radeon HD 3870 512MB PCI-E 2.0
Western Digital Caviar SE16 WD5000AAKS 500GB 7200 RPM 16MB Cache SATA-300 Hard Drive
Lite-On Black SATA DVD Burner with LightScribe
Creative Sound Blaster SB0570 Audigy SE 7.1
AeroCool FP-01 55-in-1 Card Reader w/Flip-up LCD Screen
Okgear 18″ SATA II data and power combo cable-UV blue model OK105
some cable coils just to make the cables pretty?
dual 12″ cold-cathode tube UV lights from petrastechshop

water cooling parts
D-TEK Fuzion universal waterblock
Swiftech MCR-320 resevoir
Swiftech MCP635 pump (aka Laing 55 Inline 12V pump)
Swiftech MCRES-micro resevoir
Arctic Cooling MX-2 thermal
some 7/16 tubing, clear
some 120mm fans (x4?)
some coolant/dye additive

Some business mag articles are insightful; others are as wasteful a time as listening to a broken record. Today for lunch I was at my second-closest Barnes & Noble Starbucks waiting to try out the new honey latte when I spied an IT article in the Harvard Business Review: Radically Simple IT (requires $$). “Oh neat.”

(Of note, I can pick up a copy and read the articles for free at the store, but I can’t get them online…meh.)

I skim the article and while I would love to read specifics on what Shinsei Bank did to be radically simple in their path-based approach to IT projects, I instead was bored to tears reading business cliche after business cliche after vague generalization (yes even generalizations can be vague) after fluff after fluff… It uses a lot of words and pages to esssentially say: “Be smarter about IT projects. Do better, more intensity, more cowbell!”

The mashed synopsis can be found online; I suggest reading it and wondering if that says anything new. I’ll answer that and say, “Nope, nothing new.”

Shinsei Bank, from the sound of the article, was in an enviable position from the eyes of us IT guys. They got to spend $55 million in a year to replace an antiquated IT infrastructure with a new enterprise system (whatever the hell that means) Well, I think many people would love to have the opportunity to flush it all away and start their operations anew. How often does that happen? Not often enough!

Fine, the article does have some good points later on when it talks about how to build IT. Things like minimal standards, simple architecture, and listening to users. But that’s pretty common sense, if you ask me. Anyone who has planned a system of any type, and had to live with the results knows these things (sorry consultants, sometimes your ideas suck when you live with them for years!).

The nonsense about “forging with business” instead of “aligning with business” basically makes me want to drown a kitten with my honey latte…stop reinventing terms for vague crap. Just say, “align with business with more intensity!” Or better yet, just stick to “align with business.”

Trying to move a project ahead with less requirements is simply asking for future finger-pointing from just about everyone. The reason we have so many damned requirements is due to the blame game that ensues after an IT project finishes and it’s not perfect for everyone everywhere for the unforeseeable future. But that’s really a corporate culture or management personality thing.

That’s my rant for this week; surprising since it’s been a relatively low-key week in which I’m beginning to build my next gaming machine…

CanSecWest will give round 2 of their PWN 2 OWN contest. If you can hack a box, you keep the box. This year they will offer up patched versions of Windows Vista, Mac OS X, and Ubuntu. They will also allow browser, email, and IM application attacks. I understand an out-of-the-box, fully-patched attack, but I guess one can argue “typical configuration” of those apps. So, thinking inside the box, I would expect the challenges to be centered on privilege escalation, finding something running as root level, hijacking something root-executable due to poor file access security.

Anyone ready to start a pool on which order and how these boxes will be pwned?

Order of pwnage
1. Ubuntu Linux – Ubuntu, the bloated desktop OS for Linux, is really not what you want representing Linux, but it matches the desktop use of the other two entries. Unfortunately, I think Ubuntu is the least vetted when it comes to security, and will be the first to fall. I wouldn’t be surprised to hear about poor file system permissions that lets userland replace something normally invoked by root. Or maybe an outdate package of something or other.

2. Mac OS X – I think everyone will still love to pwn the Mac and keep it in its place, making it a prime target. I suspect inherent flaws in the apps used will cause this breakdown, much like QuickTime last year.

3. Windows Vista – This might depend on the timing of patches, but I think Vista combined with IE7 will prove somewhat formidible, especially if the user is not an admin.

Most common attack vector
Web browsing – Browse to my site and get pwned! I think this will be, far and away, the most common attack vector and likely the approach used by the successful attacks. This might not result in attacking a flaw in the browser itself, but will involve the browser in some way.

Over on the Windows IR blog, Harlan has posted a most excellent list of tools and resources for someone getting started in forensics without busting the piggy bank open.