Although I have never met atlas personally, I was originally made aware of him at RSA 2007 while speaking with Ed Skoudis. I was talking to Ed about my interest in the DefCon CTF and he mentioned that his company InGuardians was working with altas on several projects because, among other reasons, of his outstanding performances at DefCon. The next time I heard about atlas was during last year’s DefCon CTF 2007 when invisigoth mention how impressed he was with altas’ leadership qualities during the intense competition as he lead his team, l@stplace, to a second, consecutive, victory. All of this peeked my interested and I was very keen on getting an interview to augment my post on last years DefCon CTF, DefCon 15 CTF – WarGamez, but time quickly passed and I went ahead with the post without the interview as I was not aware at the time of altas‘ blog, atlas wandering. After the post I mentioned my disappointment to my good friend Lara and she said, “Oh, he’s a great guy. I’ll drop him a note tomorrow.” For those of you who know Lara, she always comes through.
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.
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.@
Of course you have to love any question that ends in “No Comment.” The Mission Impossible music always seems to kick in at those moments.
I hope all of you enjoyed this as much I as did. Thank you to altas for being so patient and generous with his time.
Of course, thank you to Lara who always pulls through for me and my family.
Go forth and do good things,
Don C. Weber
atlas, exploits, vulnerabilities, defcon, ctf, atlasutils, vulncatcher, InGuardians, skoudis, Security Ripcord, atlas wandering, l@astplace 