SDL & MS08-078

I really enjoyed this article by the Microsoft Security Development Lifecycle team about how the SDL affected (or more importantly didn't affect) the recent IE 0-Day that gave a lot of people some sleepless nights recently. I may be becoming a Microsoft Security fanboy, even if I don't really like their OS. Their williness to be open, and being honest about their failures and how to correct them makes me feel far better than Apple's continuous "nope, we're still perfect" mentality, undeserved as it is.

That said, HD Moores use of the techniques develped by Alex Sotirov and Mark Dowd to render most of Microsoft's protections useless was scary to see released. I'm not ready, with todays level of attackers, to go back to a Win2k level of (in)security. Or maybe I am....

How to rescue orcs and spaceships

Hello, my name is Scott, and I'm a gamer. Sometimes it keeps me up way too late at night, but I care about my pretend space ships and the billions of Interstellar Kredits I've earned with them, and I'd be pissed if something happened to them.

A bit nerdy I realize, even for an information security blog, but it's true. There's no way to deny it, I do enjoy my online games. The fact is though I'm far from alone. Millions of people have been getting into one of the many massive multiplayer online games, from World of Warcraft to Second Life, from Lord of the Rings to EVE Online. Millions of people have invested incredible (some would probably say insane) numbers of hours to their wizards, pod pilots, hobbits, and a variety of other characters, constituting a huge investment of both time and money ($15 dollars a month adds up). This has become my motivation as I decided to get my GIAC Certified Incident Handler Gold certification as the focus of my practical.

I've been fascinated by the numerous security exploits in various online games. From EVE Online's database hack to Charlie Miller & Dino Dai Zovi's Second Life exploit it's interesting the unique factors that go into handling attacks in multiplayer online games. On one hand it's very much like a real economy, characters have assets, experience; money of some kind, and yet very much different (you can't exactly roll back a week of financial transactions in the real world).

As a result I've chosen to make my practical for getting my GCIH Gold certificate a study on Incident Handling in online games focused on case studies of actual handling by various game operations teams. Here's my abstract:

While generalized incident handling practices are essential to any system or network they do not always meet the needs of specialized systems. These systems have needs that go above and beyond the usual, and must be handled with unique attention to specific hosts, their functions, interactions, and overall system architecture. However in these specialized systems with similar functions there may be a way to generalize even the specialized requirements.

As massive multiplayer online gaming (MMORPG) continue to grow, through games like World of Warcraft, Second Life, and EVE Online, the amount of money being funneled into them grows as well. Where the money goes so do the criminals and as such online games are increasingly coming to light as targets for malicious attackers. Whether attacking for financial gain or to simply gain the upper hand in gameplay more and more vulnerabilities are being discovered and and exploited in online games.

MMORPGs are unique environments; worlds with their own economies and populations, players with their own experiences and assets, all of which are unique and important to the users who have invested hours upon hours into their virtual personas. This combination and complexity leads to creating vibrant and unique environments that make these games interesting to play, but also create a nightmare tradeoffs in the event that an incident handler must respond to in the event of a compromise.

This leads to a need for unique handling of incidents and thus a unique set of processes to be followed. This does not supersede the generalized handling guidelines, nor could it be completed comprehensive, but there can be a generalized incident handling guidelines for online games, a superset of generalized incident handling guidelines, such as those taught in the SANS 504 course.

To this end I would like to research and develop such a set of specialized handling guidelines, based on the proven general handling techniques from SANS, for consideration of incident handlers working on massive multiplayer online games. These will focus on the unique challenges and options available to handlers in online games, and will be based in large part from case studies of how such incidents have already been handled in current online games. Additionally it will include a survey of major online games, trying to gain as much insight as possible into how they currently structure their handling, in order to add as much real world experience into this effort as possible.

Even though it results in writing a paper and being uber-whitehat I'm kind of excited about writing this paper. Looking at attacking/defending online games is just beginning to get attention. That is somewhat surprising in itself since the online gaming industry is already doing billions in dollars yearly and continues growing. Nothing is quite as much fun as breaking new ground.

So now for you, my readers, I have a request: What are your thoughts and insights, on my abstract for my paper and on the topic in general. I'm very eager to hear what you have to say. Feel free to leave comments, send email (scott.roberts[at]vulnerableminds[dot]com), send a carrier pidgion, I'm interested to hear what you have to say.

Congratulations

Shmoocon IV was a good time for all. A few good talks, lots of good times meeting up with people, and for Alice, Mike, Sean, and Tim it was good old fashioned hacker fun as all of them played in Shmoocon's annual "Hack or Halo" competition. Now Mike was last years champion, and tied for first, but it was Tim who came in with the fastest time, and was this year's Hack or Halo winner.

Congratulations to Tim and everyone who participated.

CTF is coming & VM is recruiting

It may be a couple months away but Vulnerable Minds is getting read for one of the best parts of the year. No, not Christmas, Defcon. Say what you want about the Rivera, but Defcon is definitely one of the biggest events in the hacking community. Last year Vulnerable Minds competed for the first time in the Defcon qualifier, hoping to earn a spot to play CTF in Vegas.

Vulnerable Minds put in a good effort and did well for our first attempt. Out of 170 teams participating we ended up placing 30th, besting a number of very talented teams.

So now it's time to turn our thoughts towards this years competition. Vulnerable Minds is looking to build off last years strong showing and do even better this year. To that end we are looking for talented hackers interested in playing CTF, qualifying, and going to DefCon to play. Reversers, sploit coders, forensics gurus, even defensive specialists. DC area is preferred.

Not sure if this is your cup of tea? Check out information about qualification and CTF from the past two years from the L@stplace team (Winners the past two years at Defcon).

Interested? Fill out this handy contact form and we'll get in touch with you.

Nasty Idea of the Night: Bittorrent "Worm"

It's been awhile, but then again, it's always been awhile, but I digress.

So a nasty idea popped into my head tonight. Imagine attacking a BitTorrent by finding a buffer overflow in the client software and each host compromised checks it's peer list and compromises all those as well? Add extra nasty and have the payload also check for other torrents and send the exploit payload to those as well.

Interesting points:

• Could move incredibly fast.
• Complicated issues with client vulnerabilities vs protocol vulnerabilities. Unlikely to write an attack that works universally. 
• Price the RIAA would pay for such a thing? *What's the keystroke for infinity*
• Tracker vulnerabilities.

Just a random thought. More to come.

Introducing Pulse

Well if you've been doing DNS zone transfers on VulnerableMinds.com then you know, but for the rest of you Pulse has been a mystery. Begun as Project Tango Pulse was meant to do one thing; give you a summarized, quick, complete look at the status of the information security threat landscape. It's a simple concept, but a lacking resource on the Internet.

Pulse came out of my own needs as a threat analyst. Work leaves me with no shortage of projects, research, emails, meetings, and yet the imperative need to have a complete view of what vulnerabilities, exploits, and malcode affecting all platforms. RSS feeds were a good start, but I quickly found myself reading dozens of feeds a day, many filled with useless information. Many I was able to replace or weed out, making it easy to get general news and the opinions, but I still needed more. I still needed information about threats, vulnerabilities and the code to exploit them, but struggled with so many feeds, and I still spent a huge amount of time reading unimportant information.

To this end I decided I needed a tool of my own, something to bring together all these feeds that bring into one place and yet eliminate the chaff, the low threat, the endless mailing list responses; the unnecessary.

The result is Pulse.

Now Pulse is a huge part of my daily workflow. I start my day with it, along with SANS Internet Storm Center and Arbor Networks Atlas portal. I feel that this combination gives me all the information I need to know to be on the "pulse" of the infosec threat landscape. 

I'll quit waxing philosophical about the why's and hows. It's straightforward, but I feel like it meets a need that isn't easily being filled by other services available on the Internet. So take a look, use it, enjoy, and feel free to send me feedback. Pulse isn't done, it's not finished, it's just beginning. To find out more:

• Introduction to Pulse - Presentation
  
• Project Tango Specification - Document

Took long enough...

No, I'm not talking about how long it's been since our last blog post, I'm talking about the iPhone.

I can't say I'm really surprised, except that maybe it took so long, but the iPhone hacking teams have announced a major remote exploit for the iPhone/iTouch. A file parsing exploit, the way we many of us expected it would happen, this is remotely exploitable via a malicious .tiff file. It appears that this was created to make it possible to remotely unlock iPhones (a dubious prospect at best).

For all the interest that the information security community had in the iPhone before it came out I've been shocked at how little has come out of our community. It's shocking how the majority of the "exploit" activity on the iPhone has been the traditional hackers, those who just seek to expand functionality. These "hacks" have been created to compensate for the lacking API, not those attempting to compromise this information rich device. Maybe good is stronger than awesome.

More info here and the actual malicious tiff here.

Love, as they say, is dangerous.

As mentioned previously (and in a Defcon debriefing post that I have yet to actually publish), I've been looking into malware analysis and reverse engineering lately. There is still so much to learn, but what humble little I have learned has whetted my appetite for something more hands-on.

By the way, I have finally discovered and fallen in love with Eldad Eilam's book, Reversing: Secrets of Reverse Engineering. Its collective 624 pages has a good balance of breadth and depth, and though I haven't finished it from cover-to-cover yet, I am already jumping the gun and recommending it to anyone interested in reversing. As the book has a good amount of assembly code, some background knowledge is advised, unless you're the type who likes to be inundated with information about things you can just barely understand, like doing 0 to 60 in 3 seconds flat.

At any rate, in my quest to look for something to analyze, I discovered that one easily accessible treasure trove of malware and fishy (phishy! sorry, that was punny) sites is my spam folder... which is where I found this one:



"I`m in hurry, but i still love you...?" Aw, I feel the warm fuzzies! Especially when said ecard (which has javascript code running in the background, so I don't recommend you going to this link unless you know what you're doing) looks something like this...



Humor aside, I am somewhat surprised by the sloppy effort of the attempt, especially when simple copy-pasting could have made it somewhat more convincing. This was obviously not a particularly brilliant example of social engineering technique, but it was entertaining nevertheless.

Since Defcon...

Sorry for the complete lack of updates from me since Defcon. I've had plenty to write up, share, and rant about (as is my want), but I'm in somewhat of a tenuious circumstance regarding my blogging, so I figure better safe than sorry, and thus I'm keeping my comments to a minimum. Hopefully some of the other Minds will pick up the slack. We shall see.

BLACK HAT field report #2: Don't tell Joanna the virtualization rootkit's dead

Thomas Ptacek & Nate Lawson talk about Hypervisor rootkits work and why they are detectable, maybe even more so then Kernel rootkits.
Thomas and Nate created a hypervisor rootkit called 'Vitriol' for OSx (Very similar to 'BluePill' for Vista) to test their virtualization rootkit detection methods. This all stems from a debate between them and Joanna Rutkowska that's been going on for a year. Ultimately she didn't give them permission to try to detect 'BluePill' on stage, so here we find ourselves.
'Vitriol' is similar but not identical to 'BluePill', it's less weaponized and more of a proof of concept. 'BluePill' was made for the AMD architecture. 'Vitriol' doesn't hook the network, and has a less stealthy loader.
After a 'Vitriol' vs. 'BluePill' comparison there was a discussion on the detection of virtualization in general, behavior or state changes introduced by hypervisors, also timing variations introduced by a hypervisor. Virtualized malware can be detected by examining the cross section of the hyhpervisor vs. the OS and how much the hypervisor needs to exactly emulate the OS to remain undetected.

Detection:
Strategy One - Side channel Attacks
VM overhead creates detectable 'trails' through microarchitecture that are hard to conceal.

Strategy Two - Vantage point Attacks
VM cross-section forces it to recognize and emulate the OS/hardware.
problem: Talk directly to the hardware(which will betray you), or emulate the hardware, with perfect fidelity.
Performance Event Counters: instructions retries, cache misses, branches, etc.
HPET counters, ACPI timers, and MSR's would all need to agree for attackers to win.

Strategy Three - Vulnerability attack
Finding Hypervisor Bugs


Conclusions: how to make it harder for attackers
Introduce data-dependence (many heuristics)
Force to emulate microarchitecture (branch buffers, etc)
Force them to Emulate Obscure Features (HPET, PerfCounters, AGP GART)
Tie them to a single architecture (intel VT, Op Roms, etc.)

www.matasano.com/log