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

SILICA
First was the Nokia N800 running SILICA. This penetration testing device is going for a cool $3600 and Immunity is selling it directly on their website. According to Immunity:

Immunity SILICA is a hand-held penetration testing product that leverages Immunity CANVAS to provide a unique testing tool for networks. Currently it supports 802.11 (Wi-Fi) and Bluetooth, and Ethernet via USB is planned for the near future.

Its slim, PDA-like profile allows the penetration tester to perform testing while behaving innocuously.

Very interesting. I would love to get my hands on one but cannot afford the sticker price. Of course, it would be even more interesting to see if there is enough memory to also include Ruby and Metasploit as David Maynor has done. How could it hurt to have both of these tools at your PDA fingertips?

Immunity Debugger
After looking these over Dave pointed me to Immunity’s latest release, the Immunity Debugger. According to Immunity:

Immunity Debugger is a powerful new way to write exploits, analyze malware, and reverse engineer binary files. It builds on a solid user interface with function graphing, the industry’s first heap analysis tool built specifically for heap creation, and a large and well supported Python API for easy extensibility.

• A debugger with functionality designed specifically for the security industry
• Cuts exploit development time by 50%
• Simple, understandable interfaces
• Robust and powerful scripting language for automating intelligent debugging
• Lightweight and fast debugging to prevent corruption during complex analysis
• Connectivity to fuzzers and exploit development tools

Although I have very limited experience with debuggers Immunity seems to have put together a package that is very user friendly. Hopping between analyzing source code and GUI based flow charts seemed very helpful and I could easily understand how a vulnerability in one section of code affected and was accessible from throughout the whole program. One interesting aspect of the Immunity Debugger has nothing to do with actually analyzing code. Rather, it has to do with companies advertising for programmers and researchers right through the tool. As Immunity Debugger is free for download one way that Immunity has decided to support the product is to allow employers to insert advertisements for job openings. Now companies can have a direct link to the individuals they would like to locate, specifically, persons who are familiar with debugging programs. A unique and interesting approach. Although some companies would probably like to turn this feature off, this is just the cost of a free tool. I am willing to bet that Immunity would be willing to do it for a small fee, or perhaps there is a module that can be excluded when compiling the tool. That would also depend, however, on Immunity releasing the source code for this debugger and I am not sure if that is the case.

UPDATE: I just discovered something that was worth an update. I downloaded the Immunity Debugger. First it required a simple registration and then I received the Windows Installation file: ImmunityDebugger_setup.exe. Yes, Windows Installation Executable file. I would think that if this is written in Python that I would be able to run it in Linux at least. Big deal? No. But I was surprised.

Immplant
After reviewing the Immunity Debugger, Dave handed me a little piece of paper. It contained information about a future Immunity product that they are trying to drum up interest in. The product will be called Immplant. Here is what the paper said about the product.

A penetration tester often finds themselves in the position where they have access to a physical host for a short time, but they do not have a user name or password on that host. Immplant is revolutionary technology from Immunity, makers of the market leading CANVAS penetration testing software that allows penetration testers to leverage temporary physical access into permanent remote control.

Immplant is deployed as a PCI card, which can be quickly and easily installed on typical desktop machines. This card then wakes up when the machine is booted, and injects code into the operating system which causes it to call out to your listening post securely. Because Immplant is hardware based, software protections such as anti-virus cannot prevent it from operating and it leaves no traces on the hard drive to be analyzed.

Immplant, not being resident on the hard disk, ignores full-disk encryption, patches, and many kinds of OS upgrades and reconfigurations.

Basically, this is a hardware device that will pump a shell back to a remote computer. I guess this is the same premise as subverting video cards or other hardware devices. But I am a little concerned about the statement “it leaves no traces on the hard drive to be analyzed.” Certainly, this type of device will not require software written to the hard drive but there is still the issue of memory. Unless the device can insure that all of its activity is restricted to RAM then I guess it would be very difficult to detect during analysis. But if any of the information gets written to the page file or swap space then I imagine that there would be something to analyze. Even if it is not immediately obvious there should be a way to identify and correlate information with this device. After all, that is why we have forensic analysis. When I queried Dave about this he did not have the answer and the person who did was attending one of the sessions at that time. The next thing that interested me was the communications protocol. I assume that they will be tunneling the communications over HTTP or HTTPS. Dave also did not have a response to this question but this time I felt it was more due to the fact that they were still working out different methods for communications or, very possibly, he didn’t want to give out that information.

Personally, I don’t think organizations who are doing proper security will have a problem with these devices. Unfortunately, the average home user will not have the protections in place to prevent the installation and activity of this type of device making this a interesting tool for a private investigators, parents, or even the system administrators that want to maintain a guaranteed connection with a computer. This could have a positive impact on locating and controlling stolen computers. But, could you imagine if a small mom-n-pop computer service business started implanting these as a “service” to their customers? And, hopefully, Immunity has the common sense not to let the GeekSquad get a hold of any of these.

Go forth and do good things,
Cutaway

Immunity, SILICA, Security Ripcord, Immunity Debugger, Immunity Immplant, Nokia N800 DefCon15 Metasploit, Dave Aitel, David Maynor

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