I achieved my first goal right out of college and basically due to sheer luck.  The company I was hired with decided to expand a security team and I was in the right place at the right time.  My second goal was a little harder to fulfill.  It has taken me eight years, five different jobs, collaboration with many outstanding security and IT professionals, countless hours of extra work, and the will to try and turn bad situations into mutually beneficial experiences for all involved.  It has been a long row to hoe but I have finally achieve the second goal.  At the beginning of this month I became a new member of InGuardians, Inc.

For the past two weeks I have been transitioning from the world of Incident Response back into the world of penetration testing, research and development, and security architecture.  I have been exposed to the world of Smart Grids, hardware hacking, and software evaluation.  To say the very least I have been thrust from the frying pan and into the fire.  The world does not stop spinning because of personal transition and I am experiencing this first hand right now.  But, it is exciting and educational.  My eyes have already opened to a new realm of possibilities and I intend to use that knowledge to ensure our team is a pivotal part of security developments and implementation in the years to come.

I would like to thank all of the member of InGuardians, Inc for their confidence in me and bringing me on-board.  I would also like to thank everybody out there who has helped me get to this point.  There are too many of you to do this individually, but I think you can all agree that I can show my thanks my continuing with my open education stance and providing you with an insight as to what I am experiencing and how I think it affects individuals as well as the industry.

Go forth and do good things,

Don C. Weber

Sure enough altas emailed me several days later. We quickly agreed to an interview but because of constant battles with SPAM filtering, multiple projects on both sides, and several conference presentations by atlas, we just did not get it completed until a few days ago. During one of the emails I asked atlas to mention some of the things that he was working on to help me write some pointed questions directed towards his interests. He mentioned a few:

I have been doing some fun stuff with 16-bit real mode, kernel module play in
Linux, BIOS hacking, and of course disassembly and programmatic debugging.

My first thought was “Uh, oh.” Sure, I have heard of all of this but if you followed my failings with writing exploits for a simple buffer overflow you know that I am not going to be able to dig very deeply into these topics. I did some quick research on the topics. Then I reviewed his latest posts on his toolkit, atlasutils and reviewed his presentation on Vulncatcher. I started to get a little frustrated. After all, I did not want to waste the excellent opportunity just because I do not have a grasp of the integrate details of complex software and hardware relationships. Ahhh, bingo. I hit the nail on the head. Looking over everything that I can find on altas I realized that he has one of those special eyes for detail. He can see the integrate relationships within complex systems and understand how to research them. Or, at least, he understands it enough to try and manipulate the relationship. Hacking at its finest, its very core. Excellent. I might not be able to delve deeply into his research, but I can at least find out his opinions on this complexity.

First, a little Bio on altas stolen from his ShmooCon 2008 introduction.

atlas is an average joe who spends his time learning new ways to make computer systems dance. When he’s not slicing and dicing windows and unix binaries, he’s writing tools to make vulnerability research simpler and more enjoyable. His hobbies include deadlisting (opcode disassembly), vulnerability research, and lately he’s been working on processor emulation and kernel-mode internals. atlas leads the capture-the-flag team, 1@stplace, who recently won back-to-back victories at defcon, which he blames on his teammates. “I surround myself with brilliant people,” he quips.

So, without further ado, atlas.

DefCon CTF

1. You have lead your team to two straight victories in the DefCon CTF.
Has this part of your life run its course or is it still challenging enough
to give it another run?

Wow… it’s still challenging! Each year we have been extremely challenged by
amazing talent. There is still immense question of how well we will place
this year, with the outstanding talent the Naval Postgrad School puts forth
each year, Vigna’s team has provided some serious domination in the past, we
have several international teams which are doing very well, and other talent
not yet “displayed” at defcon. We have to go in each year focused on doing
our best, regardless of who and what challenges we face. How many more years
I have left to give is another question. It’s a very consuming weekend, and
quals weekend, even though we don’t currently have to qualify, is challenging
as well.

2. Your team is obviously very skilled but the types of personalities I
imagine that are involved are use to individual performance and behavior.
Was it a challenge to lead them and keep them focused on goals that
benefitted the group as a whole? I.E. tracking down a problem that might
be too difficult for the competition or not worth the effort.

If I’ve done anything really well in CTF it is selecting amazing people. They
have always been an honor to lead, and have actually helped me lead them in
more ways than I can count.

3. Have you or your team members seen benefits develop from the amount of
time and effort you have placed in getting ready for DefCon CTF?

Oh totally. A few of my guys, myself included, have changed career paths
based largely on how well they’ve proven themselves at ctf. I can’t speak
for the others, but I’m quite happy with the results. I think we’ve all seen
improvements in our daily tasks and our abilities to achieve our goals.
We’ve built strong friendships within the team which has been very good.
Management also responds well to our wins, as they are more likely to think
we know what the heck we’re talking about.

4. Are you personally going to give it another run? Will l@stplace return
as the same team or will you select different members to keep the blood
fresh and challenge high?

We’ll return the same team we left. I’ve been fortunate to find such amazing
guys, hand-selected them based on their talent, skill and personality, and
formed lasting friendships that transcend defcon. I’m confident from our
talks offline that we will all be returning this year, Lord willing.

5. Do you believe that there are real world teams, criminal or govenment,
performing detailed and near real-time application analysis to penetrate
businesses and government systems, much in the same manner that the teams
in the last DefCon CTF were doing?

Certainly. Absolutely. No Comment.

Program Research and Exploit Writing

6. What was your background before you started really moving into program
and architecture research?

I had been a coder since I was young, but got a career in sys-admin work, then
moved into data-telecom where I was responsible for many security-related
services, then got drafted into security.

7. To me some of the concepts are difficult to grasp and implement when
there are resources. What did you do to help you get over the hump and
begin to fully understand the intricacies of low level programming and
analysis?

Gave up. Then I redoubled back. I was freaked out at the possibility I’d
fail. So I decided that I couldn’t do it. Once I had finished freaking out
I decided to work it and grow. Some people could and were doing this stuff,
what’s the cost of throwing myself into the learning curve and seeing where
it lead?

8. Your toolset, atlasutils, is a combination of python programs and
script that include a disassembler and other tools that help located and
provide information to exploit vulnerabilities. I have noticed that Dave
Aitel likes to talk about writing his own debuggers as well. Is this
because the tools that are out there are not useful, you have different
ideas that did not go into the usual debugger, or that you just need
something to help fit a specific niche? Or, it is just fun to write your
down debugger?

To quote a very good friend of mine, I write code because I’m lazy. Truth
is, using others’ tools is tiring, since I have to learn to think like
them… Writing my own forces to me to learn how to think about the things
I’m trying to do, then write tools that help me next time I have to do them.
I hope people find my tools useful, but they’re really for my benefit. I
often write my own tools because I’m forced to learn the details better…
and then I can add my own whizbang fun new stuff on from there. For
instance, I’m rewriting disass, because there was an upper-limit in binary
size, above which it simply took forever to process because of inefficient
use of memory. It was also very “dogmatic”, and not agile. Some code I want
to disassemble is packed/encrypted and wrapped with an unpacker/decryptor.
That means the data/code actually changes post-loading. Disassemblers have
to account for that, which means they have to be “agile”, or able to adjust
how they view the memory setup of a binary. I’m also working parts of the
remake of disass into an emulator (no, not complete emulation) which will
allow me to better address certain laborious tasks.

9. When you are developing these tools, how do you pick a program to
analyze? Do you generate your own vulnerable code or find something with
known vulnerabilities to analyze?

When developing tools I try to use them on anything I want to analyze, just to
see them break (and wow they break). Sometimes it’s code I’ve snagged from
ctf, sometimes it’s my own code, sometimes it’s POSIX code or Win32 code, or
<insert-your-fav-commercial-app> code.

10. As I look at the types of research you are performing I start to
wonder if computers are just too complex. Or if the higher level
programming languages that we have just cannot securely support all of the
low level functionality. Then I start thinking about the interactions and
complexity added by software and hardware interaction, BIOS, and firmware
and my head really starts to spin. What are your thoughts on this
complexity and how it is affecting the security of technology as a whole?

Well, you’ve really nailed it. Computers have become very complex indeed…
and continue to do so. In many layers of “synthesis” the computer industry
has striven to group low-level functions into simple-to-use functionality;
for the developers and ultimately the end users.
Each iteration of simplification masks many details from the users/developers,
and with the disappearance of those details comes many assumptions.
Assumptions are inevitable in our industry because you can’t teach *every*
administrator and developer *every* detail about the computer. Some in the
security field have attained a great deal of understanding those details…
and we tend to hail them as deities.
False assumptions and the state of mind induced by details-overload work
together to provide vulnerabilities for attackers to leverage. Sometimes
those vulnerabilities highlight a loss of communication, laziness, lack of
understanding, or simply mistakes.

This dilemma is not going away. We continue to see layered-development and a
push for ease-of-use at every level. Ease-of-use tends to be directly
counter to security, in that we enable users and developers to do mighty
things without realizing the truth of what they are doing. For example,
without proper education and focus on security, thousands of SQL-Servers were
put on the Internet with a blank SA password (the default).

Security must become a baked-in part of the development culture. Developers
need to be screened for how seriously they take security, and continually
trained and updated on new security problems, such as format-string bugs and
buffer overflows in the 90s. When the next new common programming flaw is
identified, those mistakes must be put in front of developers to warn them
and instruct what the computer is actually doing, or how attackers are
leveraging the flaws to do evil things. Each development team needs to have
someone who understands how to think like an evil d00d. I venture to say
that every developer should become that person.

This complexity provides plenty of playground for attackers, but hackers are
rising to the occasion, finding enjoyment in understanding systems better
sometimes than their creators. We insert stop-gap protections like ASLR and
anti-corruption techniques and hackers find ways around them. Worse than the
time lost in the creation and adoption of those protections is the
complacency they allow developers, who wrongfully think they are protected.
With all the complexity of just learning someone else’s API and interacting
with third-party products, as well as designing corporate-wide API’s that
hundreds of developers may use, they are happy to think on the good sides to
such protections, without being able to understand the details or
limitations. Even if they have the base-knowledge to understand, they simply
are seldom given the time.

11. With this complexity, how can developers fix it? I mean, programmers
just do not have the time and resources to think of every little piece of
the puzzle. We cannot expect them to. So, how do developers protect their
projects? Do we just need to realize that we are in a constant state of
possible exploitation and accept that very expensive systems will get
exploited and we better have a good incident response team?

See above… Good incident handling teams are invaluable for an organization.
Teams who understand proactive security and the patching process are equally
important. Consider them “stoppers” and “sweepers” if you like futbol.

In the end, the ball is the developer’s court. Each person who writes code
needs to learn the details of what they are doing, and accept responsibility
for the security of their work. If format-string bugs seem impossible to
exploit, that developer needs training (SANS SEC504 is generally very good
for that). If XSS doesn’t seem to be a big deal, training is necessary.
Aside from great training, that SANS course will likely provide networking
opportunities with people who think evil all day every day. BlackHat and
defcon are also good venues, but likely less substantive. We need to stop
training our developers only about how to enable things… because that only
enables exploits.

12. Along the lines of complexity, most of the technologies that are put
out there, operating systems and applications, automatically have these
complexities built into them as features. The Center of Internet Security
has long benchmarks to help guide administrators through steps that help
them limit their exposure to some of these complexities, but with each new
release of a product the administrator has to be worried about what is new
or what was modified that exposes the environment to additional risk. What
recommendations can you make to these administrators as they are taking
these complexities into consideration?

Good luck? The truth is that CIS spits out some outstanding documents to help
us get a certain level of security with the least outlay of effort. It’s a
bang-for-your-buck arrangement. Unfortunately no benchmark or security guide
is going to take the place of a solid understanding of the technologies one
is using. Best case, CIS guides serve as a litmus test and a guide to
someone who already has a great understanding and the curiosity to know their
playground well. Someone who knows enough to know how much they don’t know
so they welcome the help, but someone who plays with their tech and groks
it… because they want to. This is the part where I get to piss a lot of
people off… if you don’t love security or IT or IS… get out. There are
many professions where you may be happier and more successful. Computers
have become the next “Doctor” or “Lawyer” profession, where people flood
Computer college programs in hopes of a mighty paycheck. Those people
everyone views as gods in this industry are people who would tinker anyway,
even if they were janitors during the day. And if you *do* tinker and wind
up in the industry… get yourself some security understanding. Learn to
think as your opponent… think about how someone who hates your guts and
your programs would mess with them. Get the training, from an organization
or a friend if you cannot afford formalized training.
And remember, patching is a vital, ongoing process organization-wide.

@

Go forth and do good things,
Don C. Weber

atlas, exploits, vulnerabilities, defcon, ctf, atlasutils, vulncatcher, InGuardians, skoudis, Security Ripcord, atlas wandering, l@astplace

If you would like more information about this check out the letter Jay Beale wrote to the users of Bastille. It does seem that he will be able to get the site back through his lawyers. I am not sure if Bastille is trademarked and therefore might not fall under the Anticybersquatting Consumer Protection Act but I assume that he should, at least, have some copyright precedence to fall back on. He also points out that although the new site currently points to the actual Bastille download site he is worried about the potential for this site to distribute hacked versions of the software. To protect against this possibility he will be using his PGP key to create a signature for legitimate releases that users can use to verify the versions they obtain.

This whole thing really ticks me off. I agree that purchasing an original domain name (not a product name that has been trademarked), and selling it to somebody when they find the need for it, is perfectly legitimate. But I do not like the idea of people waiting around for a site’s domain registrations to expire, snatch them up before the original owner or organization can update the account, and then attempt to sell it back to the original owner for a large fee. One simple act by an outside individual could cost a company a lot of money either in the repurchase of the domain name or the re-branding of an entire product or line. Although for big business this might not be a problem, I can see a real impact to open source projects and small businesses.

I wish Jay the best of luck with this whole incident.

Go forth and do good things,
Cutaway

Bastille-Linux, Bastille-Unix, Linux, CISecurity, Security Ripcord, Jay Beale, domain squatter

Security professionals who are responsible for maintaining a security posture within their organization should, however, listen to the podcast whether they employ virtual environments or not.  There are two reasons for this.  First, if you don’t deploy virtual hosts then it is very likely that somebody will either ask you to investigate the technology or they will tell you to deploy it.  Second, because this interview gives a great insight to the methodologies used by people who are trying find attack vectors.

Let me elaborate on the second topic a little more.  The days of hacking for fun are over.  I think it is safe to say that nearly everybody has come to that realization (there may be a few holdouts in upper management but they will not last long).  This means that the stakes are higher for the good guys and the bad guys.  The interview with InGuardians shows us how a group of skilled and seasoned professionals attack a problem.  If you think that the bad guys cannot get this organized then you are kidding yourself.  Certainly there is always going to be the individual rouge element which, because of the focus a single person can apply, is dangerous.  But when you get people operating together they become more efficient and effective.  Sure, it took InGuardians two years to get a piece of software to function in a way that it was not intended and, now that their funding is over, they will not be focusing on this area.  This is how the good guys act.  They find and validate a threat vector, disclose it responsibly, and either keep working on the issue or move on to the next issue depending on funding.  Do you think the bad guys would stop here?  Do you think they would be satisfied with a proof of concept?  Do you think their funding would dry up at this point?  I do not.  There is a reason the term “weaponized exploit” has been coined.  If you still feel that the bad guys cannot get this organized just ask Germany how they feel about their recent encounter with the Chinese.  If you think one or two people were capable of this type of penetration then you are sadly mistaken.  This was an organized, focused, and methodical attack.  Does it matter whether it was a criminal organization or government funded group?  In the case of this point, no.  In the case of broader ramifications, yes.  But that is another topic for another day.

This brings us back around to the concerns about virtual machine escape.  I very much like how Ed and crew have kept their message on target.  The proof of concept exploit that they demoed at SANS Fire 2007 is important because of the fact that it is just that, a Proof Of Concept.  Is it possible that they have a “weaponized exploit” that goes above and beyond what they demoed?  Yes.  But the fact remains, and they repeat this at the end of the podcast, the protections are merely taking the possibility of this threat into consideration during your design, deployment, monitoring, and maintenance of your virtual environments.  They have established a new threat vector and if organizations, especially the vendors of virtual environments, do not take it into consideration then, sometime in the future, you or somebody like you will get p0wned. 

If you do get p0wned, don’t forget to call InGuardians to handle the incident response.  I hear they have a lot of experience in this area and, since they are professionals, I doubt they will say they told you so.

Go forth and do good things,
Cutaway

P.S. All of this reminds me.  Don’t forget Paul and Larry’s book on Linksys WRT54G Ultimate Hacking.

Technorati Tags: Security Ripcord, InGuardians, PDC, Ed Skoudis, Tom Liston, Matt Carpenter, Paul Asadoorian, Larry Pesce, VMEscape, VMWare, virtual guest, virtual machine

Powered by ScribeFire.

I hope that you have been designing your implementation of virtual environments properly. It has been no secret that the crew of InGuardians has been feverishly working on a method to escape from a virtual guest and gain control of the host operating system. Well, according to a recent post by my good friend, Monty McDougal, who attended a presentation on the subject at SANFire 2007 they might have accomplished it. Although Monty describes some of the interesting applications they have developed such as VMchat, VMcat, VMdrag-n-hack, VMdrag-n-sploit, and VMftp, it is the demonstration of an “unnamed” application that has Monty saying,

Additionally, another “un-named” application was run on the client OS. This ran for quite a while and eventually produced a crash of the client OS. While not immediately visible this had the effect of killing the client OS, but in doing so they were able to execute arbitrary code on the host OS thus providing a full escape of the virtualization that did not rely on the path traversal flaw above. The details of how this worked was not disclosed and I would not speculate as to how it was done, but I would call this VMowned and say it is GAME OVER.

Could it be true? I guess we will find out soon enough. Either way, if you are currently deploying virtual environments or just considering it, I would be sure to evaluate your method of deployments and updating procedures. Also, as Monty suggested, watch the Center for Internet Security as they will soon add a guideline for virtual environments to their list. I have helped with this document a little bit and a version for ESX should be released in the next couple of months. If you would like to help with the development of the ESX document or the other virtual technologies then check out how you can get involved at the CIS website.

I also highly recommend that you add Monty’s blog to your RSS feeds. Monty is very smart and I often look to him for guidance and leadership. We can all expect some very interesting insight and, if I know Monty, some very good technical posts.

BTW, Monty, you do need to turn on comments.

Go forth and do good things,
Cutaway

InGuardians, ESX, CIS, VMware, SANSFire2007, VMchat, VMcat, VMftp, VMdrag-n-hack, VMdrag-n-sploit, Security Ripcord, Monty McDougal, VM Escape

When an organization decides to designate a person to handle security for their information resources the first thing that individual is going to realize is that they to not have a procedure to use when if there is a security incident. Whether the incident is a virus infection or an unauthorized disclosure of information the organization needs a method to respond so that there is a risk assessment, incident management, and follow-up that considers security as well as business continuity. Although seemingly easy it quickly becomes a large task to spin up brand new incident response procedures from scratch. Luckily there are many resources out there to assist security professionals creating an incident response plan for their organization.

The following are what I consider to be good information resources to get started on an incident response plan:

1. Read a book titled, “Incident Response & Computer Forensics, Second Edition” (ISBN: 007222696X) by Kevin Mandia, Chris Prosise, Matt Pepe, and Scott Larson. This book will familiarize you with the basic steps, terminology, and tools utilized when responding to an incident. This is a great resource for anybody who has not been exposed to incident response.
2. For more detail on setting up an incident response plan take a look at the SANS book store (http://store.sans.org) for the “Computer Security Incident Handling Step-By-Step.” You can see a brief excerpt from the book at https://store.sans.org/samples/incidenthandling_sample.pdf.
3. As you are creating your response plan you will find that there is a lot of documentation involved. Instead of starting from scratch you can use the SANS incident handling forms located at http://www.sans.org/score/incidentforms/index.php?portal=327e9b8f50ffeb4c9d90867b082d6d05.
4. With a basic incident response plan in place you are going to need to understand the “enemy” better and prepare defenses within your environment. Although I have not had a chance to read this book yet I have purchased it because of the great reviews it has received. It is titled “Counter Hack Reloaded: A Step-by-Step Guide to Computer Attacks and Effective Defenses” (ISBN: 0131481045) and it is written by two well known and respected security instructors Edward Skoudis and Tom Liston. You can check out the website for this book and other resources by these and other security instructors at http://www.counterhack.net/Counter%20Hack/Welcome.html
5. Lastly, you should check out the comments to this article to see if anybody has posted references to other helpful resources. If you have one, POST IT.

Okay, enough with resources. What should you do “right now” if you have an incident and do not have a incident response plan ready to implement? Well, here are a few steps to get you moving down the right path.

1. Remain calm and do not make assumptions. There may be a perfectly logical explanation once you have gathered all of the information available and have had a chance review everything in a less stressful environment.
2. Do a quick risk assessment to help determine the level of response:
• can anybody be hurt by what is happening?
• do the systems involved contain sensitive information?
• will what is happening affect the rest of the environment or other networks outside of our environment?
• should the systems be shutdown or should they be left running and just unplug the network card?
3. Decide who is in charge and the other people who are going to need to be initially involved. Examples:
• Team leader
• System/network administrators
• Legal counsel
4. Get one team member to start thinking about and working with other administrators to get everything back up and running. The ultimate goal of an incident response is to help maintain business continuity. Do not, however, begin implementing any steps that might affect the information on the systems involved prior to deciding if they need to be forensically copied in their current state.
5. Determine if this is going to be an incident that involves a crime. If so, notify the proper authorities immediately as they will have methods and means to handle the incident. If you do not know who to call, contact your local police department and they will be able to point you in the right direction.
6. Start documenting everything. Even if you do not have an official form create a new notebook and designate a person to maintain the “case notes.”
1. How the incident was detected.
2. Any actions taken in response to the incident.
3. Any conversation you have with somebody outside of the organization.
4. Any interviews with persons involved.
5. Get a camera and start taking pictures of the systems involved before any change is made. Examples:
• Front and back of system(s)
• Cables
• Serial numbers
• Hard drive lights
• Server heads-up displays
• System and bios time
7. Create a “chain of custody” form for controlling anything that may be perceived as “evidence.”
• As the evidence is controlled by a new individual document it on this form.
• Try to contain “evidence” in a secure location with at least two methods of physical access control.
8. Start gathering and centralizing log files from firewalls, routers, IDS, switches, etc.
9. Determine if you are going to need to bring in a third party to assist with the incident response and/or computer forensics.
• A good state by state list is located at the “Computer Forensics Companies” web site: http://www.computerforensicscompanies.com/statelist.html.
10. Take your time and relax. It is okay to make mistakes or to not know an answer. If you have gotten this far you are doing great.
11. Once you have finished sit down with the team and go over the lessons learned. Use this experience to create a more detailed incident response plan as you will, probably, now have more managerial buy-in to allocate time to this project.

Okay, eleven steps are more than a few. Hopefully these will get you over the hump of the first incident response and moving forward towards creating a detailed plan for future incidents.

Go forth and do good things.
Cutaway

Security Ripcord, Incident Response, The Security Catalyst Community