To be clear, I didn’t write the entire thing myself, I had a ton of help. Many Immunity folks contributed to this class in their spare time while also doing consulting or other work. So high fives to the following hombres in alpha order: Admin Team (Carissa and Vanessa), Chris, Dami, Dave, Justin, Leonardo, Matias, Mark, Miguel and Nico

Word Count: ~2000

How the class worked:
WebHacking was a three day course, days one and two were lecture and exercises while day three was practical. During days one and two we tried to have as many exercises as we could, we wanted students to keep their fingers on the keyboards as much as possible. Our goal was something like 5 slides of content to every exercise. When completing most exercises students would receive a token which they could redeem for points. On day three we had challenges/puzzles that covered the content from days one and two, when completed students would also receive a token.

Dami, our Django sensei, implemented a web application scoring server. The scoring server handled cryptographically “secure” token generation via a key that only lived on the scoring server. Students would also submit their tokens to the server which would then track scores and provide fancy graphing. The server itself had a good bit of functionality, including the ability for students to submit links for us to click on. As you can probably already guess that setup produced some unintended lulz.

We kept the attitude that if the students were able to break something in a way we had not intended then that was awesome.

Terminology:
CTF/WarGame both imply some type of defense when in this situation there was none. However, security people seem to be really keen on these terms and they’re universally understood as roughly describing what we did on day three. I’ll use challenge and puzzle interchangeably to describe day three activities as I think they are more fitting terms.

Rules:
1) I had all the students agree that they wouldn’t tamper with the challenges in a meaningful way, if they wanted to tag their name on a page that was fine, but all challenges had to remain solvable. Breaking an exercise meant a deduction in points.

2) No network level attacks, no physical attacks on devices or people, no attacking the scoring server or the resource server (hosting files for download), no attacking VM hosts, no DoS.

3) Outside tools were allowed within reason, I think our general rule was they had to be open source.

Lessons Learned

Marketing:
This would work better as two separate courses, an introduction and an intermediate level. A lion’s share of the current content probably fits the introductory level. Which I’m ok with, but we want to facilitate students being matched with the class that best suits their skillset. That said going from an introduction to XSS to padding oracle was kind of jarring.

Format:
You’ll note there’s no mention of Ajax, JSON or SOAP or framework specific issues (i.e. JSP, .NET). I’m not sure where that would all fit in while keeping the class a manageable length. That content is super important but I don’t want to get stuck out in the weeds. This is the general direction I’d like the class to evolve:

The introductory class should be 4 days:
[Optional] Day 1 – Python Introduction, Linux fundamentals, Web fundamentals
[Required] Day 2 – OSIG, versioning, light auditing, XSS/XSRF, RFI/LFI, Intro to SQLi
[Required] Day 3 – Scripting up repetitive tasks, SQLi, light privilege escalation
[Required] Day 4 – Review, Puzzles/Challenges

The intermediate class should also be 4 days:
[Required] Day 1 – Practical JavaScript, auditing RegEx
[Required] Day 2 – SQLi (Optimizing blind SQLi, NLTK, Unicode)
[Required] Day 3 – Padding Oracle, in depth privilege escalation, anti-forensics
[Required] Day 4 – Review, Puzzles/Challenges

Hackers can be very competitive:
I’m not particularly competitive by nature so in retrospect I severely underestimated how much student’s scores would matter to them. Students took their scores very seriously and I had multiple folks approach me during the class to be sure they had completed every possible points scoring exercise. I wish we had paid more attention to the number of points we assigned to each puzzle and made the point information available to the students. For a while it was looking like we were going to have a tie and we hadn’t planned on that, so a more clearly defined rule set around how different scoring scenarios would be handled would have been good.

We assigned points to challenges roughly based on how long we thought it would take us to beat the challenge if we’d never seen it before. Challenges that would take us an hour were hard, challenges that would take us 15 minutes were easy and scored as such. I think we should have weighed how things were scored a bit more, including the discretionary tokens we gave out when a student was especially clever. If anything scores were a little low, hard exercises should have been ~20 points and discretionary tokens should have been capped at 5 points. We also needed enough exercises such that a student who hadn’t gotten discretionary tokens could come back from that disadvantage.

RTFM
We made use of an open source Python implementation of a diff utility provided by Google. When we intended the students to RTFM (i.e. to explore a new API), we should have made that intention way more clear. We had more than a few quizzical looks and questions about why the relevant API documentation wasn’t laid out in the slides. RTFM is one of those things you have to get used to in this industry but people don’t expect it in a class. Our fault on that one.

PHP is a great language to write this stuff in:
PHP is very useful because the level of knowledge you need to get a page up and running quickly is low. It’s also useful in our scenario because it’s awesomely easy to write vulnerable apps. Which is to say it’s easy to fuck up PHP. Meaning, I get excited when I see a PHP app on a gig. Therefore, please write more PHP.

Number of exercises/challenges is key:
If you’re running challenges/puzzles for people who have had hands on penetration testing experience, you need a lot of content. Take how many challenges you think you’ll need, now double it and add 10 to that number. All of our students were smart, most had some offense experience, a few were studs. The gentleman who ended up winning had about 30 minutes of time left after completing all our challenges minus one. Ideally I would have preferred he had several more exercises to choose from to keep him occupied. Counting the exercises from lecture, I think we had around 50 total exercises/challenges/puzzles for students to complete.

In our Introduction to Python section we had the students create a basic brute force script as the culminating exercise. As a bonus exercise those students who were comfortable enough with Python to skip our review had the option of solving additional problems to incorporate more features into their script.

Exercises/challenges should be functional apps whenever possible:
I created a small web application for the course that functioned as a simple RFC lookup app. You could give it an RFC number and it would spit out the corresponding RFC text. It’s simple enough to illustrate the bug we wanted without forcing the students to bug hunt too long, but it had enough functionality to give the impression that you might find it on a gig. Your application has to do something more than just be vulnerable. The attention to little details like using free templates, customizing CSS, etc give the class a more polished and satisfying feeling.

Holy VMs Batman:
We made the decision early on that the VMs would be instructor controlled and the students would receive plain Linux laptops. I think at final count we had over 20 VMs that powered the entire class. On our next class iteration we’ll undoubtedly have 10-15 more VMs. We had five instructor laptops running the class at the start and we ended up with one more when Matias rotated in. Things got a bit crowded on our table and we were always tripping over each other to get to the VM we needed. A minirack may be the way to go next year, the White Wolf Security guys have used this setup to good success. Talking with our IT guys it seems like we can put together a portable 14U rack with networking, power and three servers for under $10k.

Make a standard VM:
Most of our VMs were a Ubuntu 11.10 server based LAMP stack, all the exercises were written to run on that platform (with few exceptions) so if one VM died we could take 10 minutes and port an exercise over to another laptop or VM if needed. Don’t forget to change the VM’s MAC in VMWare if you’re just doing a straight copy. Daily snapshots are another good step towards winning.

Have detailed install instructions:
I had a bunch of folks helping out by writing exercises. One of my rules from the get-go was that I had to be able to install your exercise in under 5 minutes. If your exercise required a DB, you needed to provide me either a SQL dump or a .py to populate the DB. I needed complete set up instructions including all the package names for your dependencies and anything that had to be compiled from source. We definitely had a few things die on us during or before class, so having this information handy let us manage that crisis pretty readily. Solutions in the form of Python scripts (where appropriate) were also required so we could easily test and spot problems in the installed exercise.

Don’t use Wireless:
It is a ridiculous pain in the ass to fix and debug. Especially if your channel space is really crowded. If you’re using Linux laptops the wireless drivers, utilities and options are confusing for mere mortals. Bring two thick rolls of gaff tape, enough CAT5 to rig Carnegie Hall, a switch, and call it done. We also learned the hard way that you need to contract the hotel’s IT to have your port live, labeled and configured to your spec two days before your class starts.

Stuck on creating exercises?
Writing apps around a particular vulnerability class can be tough, afterall there are only so many ways to write up command injection. No problemo! Head on over to exploit-db, install an appropriately licensed vulnerable application but tweak it enough such that the exploit doesn’t work out of the box. This can be as simple as adjusting the install path, mangling the version string, tweaking the app so that whatever sanity checks the exploit does will fail, or in some cases removing a dependency to break the app somewhat.

Nerds love nerdy culture references:
This is always a big hit. A little laughter in unexpected places can relieve stress for students, the key is balancing your use of that device such that it doesn’t turn into a VH1 nostalgia marathon. Over all our content I think we referenced: Muppets, Futurama, Ghost in the Shell, Seasame Street, number theory multiple times, Jurassic Park, The Matrix, lolcats (sparingly), 90s era rap, Batman, Monty Python and a few more that I’m obviously forgetting. Security can be a humorless industry (have you read a NIST document?) so having a bit of fanservice and giggles will make your class all the better.

Kit Bag:
Some things to bring with you: spare gaff tape, duct tape, multi-tool, scissors, box cutter, cross over cable, electronics screw drivers, CAT5 crimp tool, Aspirin, Advil, Immodium AD, band-aids, fat sharpie, 2-3 screw drivers with multiple head attachments, $10 in quarters for caffeine, label maker, Cyanide capsules in case of capture.

This post was brought to you in part by: Mazzy Star – Fade Into You

Word Count: ~670

If you’ve ever read a successful pen-test report for a gig you weren’t on and found it both satisfying and fascinating, this book will give you that same experience. Mr. Klein does not set out to write a book which is a tutorial or an exhaustive manual on the processes of finding security bugs in software. He does not spend much time talking about all the code he read that was secure and chasing intuitions that proved to be wrong, which is part and parcel of being a bug hunter. What he does do, and does very well, is draw a straight line from source or assembly to the beginning stages of a viable exploit. It is a very satisfying book to read and there are great bits of knowledge to be had.

In the introduction the author makes clear that in Germany publishing exploit code (even for dead bugs) is illegal, so we can not fault him for not including any. What is included at the end of each section is just enough code to gain control of EIP or its equivalent. While control of EIP is necessary and in modern exploit development it’s still one of the first milestones towards a shell but there can now be so many steps afterwards too. I would have enjoyed the complete path from bug to shell; it’s unfortunate that the laws are what they are.

If you view exploit development as a puzzle to be solved then the tidy solutions in this book are pretty cool. And if you have any interest in hands on bug hunting the author’s experiences and methods will probably help inform your practice. I don’t spend all my time in a debugger or disassembler but I’m familiar enough to know what options they come with and what they allow you to do. Mr. Klein included just enough detail to let the reader know how he was using those tools but didn’t dwell on explanations from the ground up. This same economy of detail applies to memory management mechanics as well.

All in all I thought the author’s choice of bugs was good, from the very straight forward VLC .ty overflow through some of the work in kernel land. They all provided good case examples and demonstrated that there are still bugs of all levels of difficulty out there. Even implementing a dumb fuzzer (for the iPhone exploit) can find serious bugs. You don’t have to be Charlie Miller or Ben Nagy to get good results from fuzzing.

One of the most intriguing things for me was looking at his timelines for finding a bug, reporting it and when a patch is issued. Particularly the Solaris local (CVE-2008-0568) which he had for 471 days prior to Sun releasing a patch, over one and a quarter years. There were a lot of vendors/teams who released patches quickly CVE-2009-0385 was patched by the FFmpeg team in 2 hours. But the long lasting bugs, the operating system bugs, those are good food for thought. Who else had this? Where would they have likely used it? Where would I have used it?

In summary, the book is good. The author’s experiences are enjoyable, the technical detail clear, the tools and methods explained in enough depth. It’s good reading and a good addition to a technical library. The price is a little steep for a brief book but that’s balanced somewhat by the density of the content. If you’re on the fence about the price, browse this book at your local brick and mortar before committing to a purchase.

Full Disclosure: I received a review copy of this book from the publisher via my employer. I have no financial interest in the book and no personal ties to the author. Though he does seem like a swell guy.

This review brought to you by: The fine folks at No Starch Press in partnership with Hank III – Shades of Black

Word Count: ~1000

The first plot device used is a conversation between the characters Peter and Wallace which starts on page 73. Peter is selling Wallace a database of credit card information he obtained via his experiences in his side job as an above board penetration tester. He claims to have used a SQL Injection bug in a website which allowed him to install a rootkit and thus maintain access to the server. Though he discovered this flaw on a legitimate gig, he used the knowledge to exploit other websites designed by the same 3rd party in the same way.

• SQLi bugs are ridiculously common by almost any measure, so that’s a perfectly appropriate attack.
• To install a rootkit though, you typically need some kind of shell access. Depending on the flavor of the underlying SQL DB this can be relatively straight forward or impossible. So shell access is typically another step which would net you a shell with the privileges of either the SQL DB or the webserver.
• The other piece required to install a rootkit is as the name implies, root. Typically SQL and httpd do not run as root and any privileges you inherited from those services would be insufficient for this attack. You would therefore need to run a local privilege escalation attack.

Ifs and butts: The scenario is perfectly reasonable, I have used an SQLi bug as the first step in a path to root a webserver numerous times. There are a ton of wonky webserver configurations out there so it’s possible you may be able to leverage SQLi to drop instantly to a root shell, but that is not typical. My issue is that he left out a few steps.

                                  ------

The second plot device used is a description of the reamde virus itself, which starts on page 119. In briefing Ivanov, Zula discloses that the virus leverages a buffer overflow in Outlook to run code on the target system and achieve root level access.

• Outlook is very common, it has had buffer overflows in the past, no stretch in the imagination here.
• Again, typically you cannot transition from the user running Outlook directly to Local/System without some kind of additional step.
1. I will grant that most users would be running their primary account as the machine’s administrator
2. In Windows XP and 2k it was possible to install a service as an administrator automagically which you could then use to inherit Local/System.
3. Given the description of the game and its performance (specifically in contrast to WoW), I would argue that the hardware requirements alone would mean that Vista/Win7 era machines would be required. And high ones as that. The security measures in place, even as an administrator prevent you from easily transitioning into running code as Local/System, you need a privilege escalation attack.
• Zula mentions that the virus is able to abuse vulnerability in Outlook by virtue of an addon bridge between T’Rain and the Outlook calendar to manage in game events. I’m not entirely clear on what the infection vector would be, it seems reasonable that in order to get the kind of infection numbers they talk about the vulnerability would have to be in the functionality related to this Outlook checking for a conflicting appointment. So you’d get something like:
1. Some kind of mass invite procedure is available
2. You go to some populated area with a bot and start inviting everyone you see
3. The invite contains some string which is passed to Outlook, which then checks if you’re free and in the process of doing so the string triggers the vulnerability
4. Therefore the vulnerability would have to be reachable pre-acceptance

Ifs and Buts: Again this scenario is perfectly reasonable but a step is missing. While they specifically mention this vulnerability in Outlook was previously known and patched, I think a more interesting target would be whatever fictional software T’Rain used to manage the addons in use by the users (analogous to the Curse updater for WoW). But this is neither here nor there really.

                                  ------

Finally, when arriving in China Zula, Sokolov and Csongor convince Ivanov the best way to find the location of virus writer is by driving around Xiamen and taking a survey if IP addresses. IP addresses in close proximity (i.e. netblock) to the IP of the virus writer should correspond to the physical proximity of the computer with the IP they’re after.

• First and foremost, don’t want to get your door kicked in by Russian Blackwater? Two words: anonymous proxy
• I’ll admit my experience with ISP style networking is fairly limited but I don’t think their assumption that geographic area and IP proximity is going to work with the precision they’re thinking.
• Talk about labor intensive, you’re assuming there’ll be a ton of open APs using the same ISP, those that aren’t open you’d have to see if you can buy access to (i.e. internet cafe)

Ifs and Buts: I recognize that this activity was central to the plot as it gave Sokolov a chance to reconnoiter the area, introduces the Yuxia character and eventually introduces us to Marlon. But given the amount of money Ivanov is willing to throw at this problem, it seems much easier to just find an engineer at the ISP and buy the answer. Or just have Peter and Csongor hack into the ISP and steal the answer.

                                  ------

Coming soonish: at least one more review

This post brought to you by: Lyrics Born – Bad Dreams

Words: 486

This post isn’t going to address what kind of knowledge one needs to succeed in this field, that’s largely determined by who you’re working for and what you’re doing for them. The offense oriented security industry is becoming increasingly specialized as the tools to build (and break) software become more complex and interconnected. Acquiring domain specific knowledge is straight forward compared to altering some of the key pieces of what makes you, you. Therefore I think it’s important to consider more about a person than just their knowledge of the field.

Ultimately I decided on two main traits:

Curiosity is so important because it can be a powerful motivator. Curiosity often compels discovery; discovery of the unknown is the fundamental goal of any penetration test. The uncovered issue may even be known to the client but rarely are all the implications. Curiosity is the catalyst for the breakthrough ‘what if?’

Persistence is the other side of this coin. When viewed beside curiosity, persistence is the enabler of continued curiosity. Finding esoteric bugs is often monotonous work, persistence enables curiosity to remain even after you’ve explored 90% of the seemingly identical paths available to you. It is difficult trait to cultivate and that makes the people who have it very valuable, but only in conjunction with curiosity can you harness it effectively. Computers are very good at being persistent, less so at curious and imaginative.

Back in my heady undergraduate days I had a research professor who stated that “obsession is not a character flaw in a scientist”. I think that statement is largely true and even somewhat applicable to penetration testing, this industry obviously makes very good use of the scientific method and logic.

The problem with obsession and where it crosses from character flaw into illness is when you can’t turn it off. Using obsession to fuel persistence can be dangerous. I have to think many of us have ridden that wave until the small hours of the night or across days chasing and finally hitting the crest only to be followed by a sort of post partum depression. This pattern is addictive, such is the nature of obsession. So much of offense work has to be done on a very strict time budget that being able to disengage and look for something new is absolutely essential, obsession makes that difficult.

Each team has different members that play different roles, similar traits may drive two people towards two different roles. Certainly there are many possible combinations of players on a winning team. I think curiosity paired with persistence are general enough yet simultaneously central enough to, what I consider, the proper mindset of a good player. Food for thought next time you’re involved in an interview.

This post is brought to you by: White Zombie – Blood, Milk and Sky

Topic: Information Disclosure
Goal of this post: Something to ponder, hopefully a recurring series
Word Count: 392

Scenario:
You’re on a social engineering gig and your goal is to get an employee’s password reset to your client’s mail server. In order to get a password reset you have to provide some personal details about the employee while you’re impersonating them to the help desk: social security number, emergency contact, etc. You’ve decided to focus on one specific employee, Bill, as some of his information has been easy to find. After a few hours of progress you’re unable to find the final piece, his social security number. During your investigation you did find who his emergency contact is, his partner Jeffery. You are also aware that Bill isn’t out to his office ¹.

Based on the information you WERE able to find you could get a password reset for his personal gmail account, within you are confident you will find tax returns or other data likely to contain his social security number. The scope of your gig does not specifically cover this type of action but because you’ve worked with this customer so many times in the past you’re sure they won’t be upset.

The client wants a dossier on each employee you decided to impersonate. Bill is not evil or a danger to anyone in any way.

Questions:
1) Do you specify the relationship Bill has with his emergency contact in the dossier?
2a) Do you break into Bill’s personal email?
2b) What if you could MITM his login credentials and he’d never know?
3) Assume you were able to get the SSN in another way, do you include the full number in the report? Your client has no reason to know this number as they are not the HR department.
4) Do any of your answers change if you are working for your government?
5) What is the lowest amount of money required for you to answer yes to questions 1 and 2; assuming you do not have Bill’s consent.

Answers:
I’d prefer if you kept them to yourself or at any rate not post them as comments. Clarifying questions are welcome.

This post brought to you by: Hugo – 99 Problems

[1] If the gay part influences your decision, just substitute Jeffery with Jennifer. She and Bill are coworkers and are having a relationship. Romantic relationships between coworkers are frowned upon by management.

Word Count: 544

When I interviewed for my current gig I was told “we don’t give a shit about your certifications, we care about what your abilities are.” And that’s a pretty good tl;dr summary of how I feel. The formula for a good certification is simple: hands on skill tests. We do that with the NOP Cert and it is a surprisingly good bullshit detection mechanism. If a cert isn’t mostly a hands-on exercise I’m not going to pay it much mind.

Certifications are not without their place, though. If you get assigned to manage a technical team of geeks and don’t have a security background then getting a certification is not a bad idea. It will at the very least give you the vocabulary to communicate with the team on some level. If you want to be part of that technical team, your time is very likely better spent elsewhere. The same generally holds true for employers. If you’re building a pen-testing team and are exclusively certification focused it’s a warning sign for me that: you don’t know what you’re doing and/or you’re looking to suckle at the .gov teet. Which isn’t always bad but keeping in mind that anything that’s legit cool for .gov/.mil you’ll never hear about anyway.

Enough time and effort is spent by the security community on defining the mythology of your hat color that you’d think we were an extension of the Catholic church¹. There’s been some discussion recently about how some security companies are becoming indistinct from blackhats. I think a good security company, especially a consultancy, should have the ability to operate as much like a blackhat as the customer requires. I’ll leave the particular ethical considerations up to the reader to ponder. If we’re all whores: everyone has a line and everyone has a price to cross it. Ask me for my reasonable rates on child murder!

The distinction between hat colors is difficult to define and probably doesn’t have a real clear shared meaning outside the nerd pack you drink beer with on Thursdays (trivia night). If we’re all a shade of grey, what’s the point? Here are the 2.5 questions I care about:

1) Are you mostly offense or defense oriented?
2) Are you engaging in any ongoing illegal activity?
a) If so, specify.

I’d wager that if you asked the people in the security industry who have an impressive skillset if they’ve ever broken a computer crime law (minus file sharing) most of them would raise their hands. Your definition and my definition of ‘impressive’ may differ but regardless it will be a non-trivial portion.

Fun followup: I saw a disclosure recently where someone said (paraphrasing) “I’m a white hat so I didn’t fuck with him”. Actually what you meant to say is “I’m not a dickhead.” If I use an XSS to set a buddy’s profile to “I eat a bowl of dicks before bed time” that doesn’t have anything to do with hats; unless you’re wearing a strap-on.

This post has been brought to you by: Dubstep – woobwobobWOOOBWOBOBOBOB zzzkzktktk WOOBWOOBWOOB and the Mann co. hat store

[1] – Though not without its flaws I do admire the absurdity of an organization with hierarchical headgear.

Word Count: ~500

Penetration Testing Theory 101: Regardless of you opinion on the value and efficacy of defense products (AV, IDS/IPS, etc), the one trump card that defense always holds is full content packet captures. A lot of solutions are being brought to bare that make this much more scalable and easy to implement. You don’t want to be in a position where your target calls in someone who knows what the fuck they’re doing to pour over their logs, but that may inevitable. From an attacker perspective the answer is simple: make your important exploits count and use them as infrequently as possible. Give your adversary as little to go on as you can, make their jobs as difficult as you can.

Documentation speaks directly to the above. If you’re playing this game for high stakes you need to be aware of all the methods, details and potential consequences of an exploit before you use it. Documentation informs your decision on when to use the exploit.

All exploits:

• Exploit type
• When was this written?
• If there’s a patch, when was it released?
• What platforms/versions have been tested?
• Is this localization dependent? If so what languages have been tested?
• Is this one shot or is it repeatable?
• What’s the success/failure ratio?
• What happens in a crash scenario?
• Is anything touched on disk? If so where and what?
• What if any logs are generated by the service/application?
• Does this trigger any of the major AV products? Heuristics?
• What if any alerts are generated by the major IDS players?
• What does this look like on the wire?
• Is obfuscation possible? ¹ Is it implemented?
• Is encryption possible? Is it implemented?
• What debugging and troubleshooting options do I have?
• How well is the exploit code documented?
• All the boring CVE, reference, CVSS, OSVDB reference data if it applies
• Are there any “gotchas” with this exploit?

0day specific considerations:

• Who else knows about this?
• Are we reusing any code?
• Are we using a method only we know about?
• How was this bug found? ²
• Did we buy this? Or find it ourselves?
• Do we know of anyone else doing research in this direction?

This kind of data is a pain in the ass to track but it makes your exploit so much more valuable. It will limit how extensively I have to test it and it gives me a clear picture of where I can use it. Hopefully this gives you something interesting to ponder on your drive home from work.

This post is brought to you by: Skinny Puppy – Worlock

[1] Fortunately, most forensics teams have a finite amount of time to dissect what you did, drag that out as far as you can. Just because they figured out what you did (two weeks later) doesn’t mean they win.
[2] This may seem an odd one but it can speak to how long your 0day may remain unfound.

Word Count: 488

I expect a fair amount of the people who write their own exploits are going to look askance at my opinion. It’s hard to argue with 100 lines of self written Python that let you topple a 2k8 server. Minimalism is a good thing, you don’t want to over engineer your tool. But commercial exploits need to be more robust than what lives in your ~/secret/0days/ directory.

One of the realities of the commercial exploit game (from where I sit) is that you’re typically not selling to other people who love nothing more than kernel reversing. They exist but are atypical. When you sell a functional exploit the less customization and configuration for your customer, the better. Otherwise they have to spend their time (money) on getting the bloody thing to work. Its been my experience that most people who wield commercial exploits professionally (and legally) never look at the source. Here are some capabilities to consider:

Target Coverage: The exploit should work against the maximum number of OS, language¹ and vulnerable software version combinations with the minimum number of distinct payloads. When I go to use your exploit I want simple targeting. Example: The Windows version will work against WinXP -> Win7 without any additional configuration required. I recognize this isn’t always possible but it’s something to strive towards.

Modularity: Sometimes you worry about what your ‘signature on the wire is’. If you complete a task in the same way enough times it starts looking familiar to observers. Have a favorite ROP chain that you haven’t seen anywhere else? Be careful of over use. Using your IRC nickname to construct your padding? Probably a bad idea.

Easily swapping parts of the exploit in and out when possible is a nice feature to have. If you can get 9/10 with the pray after free technique it might make sense to have that as an option in addition to doing it The Right Way ^TM. Further, having an easy ability to swap in callback techniques and automate post exploit actions (like disable AV) is also a significant boon.

Sometimes looking like the Chinese government works in your favor. This is applicable certainly if you’re trying to evade IDS (or to trigger it explicitly). If you’re playing big league ball not giving forensics teams a smoking gun, ‘X is the only person who exploits this bug this way’, is a concern.

Documentation: This has enough meat for a whole separate post. SPOILER: It’s important.

Integration into a Framework: Again enough meat for another post, I’m trying to focus on what’s in the actual exploit executable (or script) rather than capabilities of a framework.

This post brought to you by: Mos Def and Diverse – Wylin’ Out (Kutmasta Kurt rmx)

[1] Explanation of MS11-056, only able to be triggered on Chinese-Japanese-Korean Windows http://j00ru.vexillium.org/?p=932

Word Count: 283

So this has generated a fair amount of feedback and interest on the twitters and internets. I’ve got some more comments to sift through but unfortunately I’m teaching all day today so I won’t be back until early evening EST. I’ve seen some discussion crop up in various places (hello /r/netsec <3, my new reddit account is: alemcg). Let me just give some additional comments.

1) I have done pen-testing work in hospitals before but nothing against embedded devices. I can't talk about what else I did which is why I haven't expanded on this post, it could be much longer with a ton more examples. I will say this: given my personal and professional experience looking at the computer security around hospitals I am not impressed.

2) My goal with this blog in general is to get people to think about security, kind of like the discussion you'd have in a bar. Think of this blog as having a permanent preface of "Have you ever considered…?" I may be wrong, you may be wrong, but it is food for thought.

3) I don't like FUD, I agree that it's bad marketing juju. But talking openly about attacks, even theoretical ones I think is good. Where it turns into FUD is if I reference it for marketing purposes. It will take all of 2 seconds and google to figure out who I work for and what some of my roles are there. My job informs my view of these subjects and thus we're a package deal, that being the case I will do my level best not to make this a marketing effort.

Word Count: ~890

Please see the correction to this article at the bottom of the page

Citing prior work is important so let me be clear in stating this idea (killing someone via an exploit) isn’t mine nor is it particularly new. The first time I saw a realistic example of how hacking could be used to kill someone was in one of those Syngress Stealing the Network: * books where a character changed someone’s blood type in a hospital record. I doubt the idea started there either. That being said, what follows are my experiences and observations.

Back in 2005 Dad had his first CABG to do a quad bypass. Every year thereafter until his death in 2009 he would have cardiac incidents that would require an angiogram or angioplasty. In that procedure essentially doctors snake a thin cable with various attachments through the femoral artery in your upper inner thigh up to your heart. From there they can take pictures from the inside of various structures or using different attachments put in stents, laser out plaque, write their initials, etc. To me that kind of technology is amazing and medical science is one of the things I always wish I knew more about.

At the time of this procedure everyone was finding out that the Acrobat implementation of Javascript had more lulz per line than the script for Blazing Saddles. After the operation the doctor brought us in to the operating suite to see the results. (patients aren’t typically unconscious for this procedure, nor is the room surgical sterile)

The machine that was controlling the wire being used for the angioplasty was being controlled in turn by a Windows XP desktop. While the doctor was going over the results I noticed the Adobe Acrobat icon in the systems tray. When the doctor was done I asked if I could take a closer look at the results, “help yourself just don’t touch anything”. So I looked at the version of Acrobat and saw it was something in the 7.x series. Sorry doc I couldn’t help myself.

The doctor and I then had this exchange (I’m paraphrasing):

Me: “So I see you’ve got Acrobat on here, do you use this to view patient data?”

Doctor: “Oh yeah, if a case gets referred to us the common practice is that the patient will come with a CD on which there are test results we look at during the procedure.”

Me: “And this machine also controls the catheter?”

Doctor: “To a degree yes”

Me: “Tolerances here being very important?”

Doctor: “Yes, very.”

I had packed my CANVAS development laptop. Having something to distract you (and a mild sedative) while waiting for loved ones to get out of surgery is a plan I can’t endorse enough. We had a very reliable exploit for CVE-2007-5659 which I had previously tested to work for the exact version of Acrobat they were using.

With a bit of custom development work, here is your attack scenario:

1) Weaponize a legitimate PDF, repair memory such that Acrobat doesn’t crash out or reexec Acrobat on a benign PDF.

2) Escalate your way to Local System

3) Surgeons depend on the information provided to them by this machine to be exceedingly accurate, I could distort this data (how they are oriented in space for example) or just add a delay to the displayed image. Direct manipulation of the wire may have been possible.

I am very confident that this would lead to an accident involving a laser drill and the inside of your heart. Which is to say, a bad accident. Here are some other fun things I learned on that visit:

1) Some brands of portable vitals monitors have embedded webservers

2) To reduce potential tripping hazards, some medical gear uses wireless but only supports things like WEP and WPA1, it is a pain in the ass to type in complex keys on these devices

3) There are multiple LAN drops near every patient bed for the plugging in of the aforementioned devices

4) Automated pill dispensers are also typically networked (In my limited experience I have never seen one that wasn’t)

5) VNC is heavily used in a lot of hospitals

This is the result of what I saw with my eyes and some internet research, not any probing of the hospital network.

So for an investment of say, $250,000 in equipment and maybe $250,000 in exploit development costs (5 devs, 4 months, $50k per) you could have yourself an arsenal of reliable exploits that would allow you to do whatever you wanted on these machines. Your exploits would go a long way: hospitals don’t replace most equipment that often, there is a lot of common equipment between hospitals, I don’t know of any forensics firm that specializes in medical equipment though they may exist.

For half a million dollars you can buy yourself a infinitely reusable weapons system that’s hard to detect, hard to defend against, and allows for you to not even be in the same room as your target. People are right to worry about SCADA hacking causing industrial accidents but those sorts of things are always so, messy. Neat to think about.

In closing I’m going to recognize and dedicate this post and this blog to my Dad, who encouraged and helped me become the curious, sneaky and devious character I am today.

Correction: Friendly redditor sqrt7744 pointed out here that my initial idea of an attack vector was probably not viable. I maintain that putting a malicious PDF on a patient’s record CD that’s viewed in the OR is a bad thing, but the vector from PDF -> Death is not as clean cut (if it even exists) as I originally thought, though surely worth looking into. Also, sqrt7744 pointed out that the Syngress plot device about changing a blood type as also not likely viable, I can’t speak to hospital procedures so I don’t know how accurate that is.