Security Ripcord

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 Intelguardians 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. 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.

@

---

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, Intelguardians, skoudis, Security Ripcord, atlas wandering, l@astplace

One of the best parts of wandering around DefCon was periodically sliding through the Capture the Flag room. As I stated in my original Defcon 15 post, Invisigoth of Kenshoto was kind enough to field a few questions and shed a little light on what was happening.

When I first walked into the room it was a bustle of activity. Teams were setting up their systems and their networks. Their equipment hosted a wide variety of computer systems. As I looked around at the different systems the teams were running I could see Windows, Linux, OS X (and possibly BSD but I couldn’t be certain) running on all different types of hardware: Dell, Apple, Alienware, IBM (Levono), HP, Sony, and more. It was already late in the morning so I had wandered in right at the end of their allotted setup time. Invisigoth made an announcement that the teams would be limited to eight team members working at one time and then, a few minutes later, announced the commencement.

Although the scoreboard was running at this point there had not been a lot of noise in the room up until the beginning. With the announcement of the start of the contest I was looking up at a projection of the scoreboard on one of the walls of the room. It showed each team, the number of overwrites, steals, and breakthroughs, and the level of service operation. This screen also flashed through several other statistic screens that compared the teams according to each category. A scrolling text area across the bottom of the screen also provided update information, in this case, the beginning of the competition. What happened next, however, got me to laugh out loud. With the start of the competition the technomusic started and two additional video screens lighted up. Comics, music videos, and other very distracting videos began to entertain the crowd as it filtered through the room and added its own noise contributed via talking, laughing, and applause.

After the start of the competition I asked Invisigoth a little bit about the teams. He was very proud of the fact that approximately 160 teams participated in the pre-qualification round and from that field the eight teams that came out on top provided representation from around the world. Although I did not get a complete breakdown I do know that team “Song of Freedom” were from Korea and team “Osu, Tatakae, Sexy Pandas!” were from Spain. It was about this time, 20 to 25 minutes in, that “Osu, Tatakae, Sexy Panda!” drew first blood. They scored the first breakthrough and quickly followed it with several steals and overwrites. When this happened I looked over at the area where last years winners “l@stplace” were located to see their reaction. I don’t even think that any of them looked up at the score board. Looking around the room I was very impress to see that no more than one or two of the other team’s members were looking up at the board either. In a room full of noise and disruption these teams were hard at work attempting to crush the other teams while keeping their services up and running.

April Dudash of The Independent Florida Alligator described the team objectives in her article “the H@cker Elite: UF engineers compete in Vegas“.

Teams were awarded points for service level, steals, overwrites and breakthroughs, or being one of the first three teams to exploit a particular service. Penalties were given if teams tried anything inappropriate, like illegal-hacking moves or real-life physical violence.

Basically, Kenshoto gave each team a server with twenty services running on them. They used the information they had from these servers to compromise the servers owned by their opponents while at the same time protected the availability of their own services. Uptime played a critical role in the outcome of the game. To better understand the objective, however, here is some of the information provided in a competition flier distributed by Kenshoto.

STEAL - Breaking into a service and getting read access to a secret token. Submit your steal for a point.
OVERWRITE - Breaking in with write access and overwriting the target’s key with yours. Each overwrite will trigger a point.
BREAKTHRU - First team to expliot a new vuln gets mad bonus (auto-scored and scaled for difficulty). Later teams get points, but the value drops exponentially.
SLA - Percentage of time that your services have been up (we have a polling monkey that checks every few minutes). This scales your final score.
PENALTIES - Seriously? You’re reading the definition for ‘penalty’?!?! While you’re at it: there is no Santa Claus.

One of the times that I spoke with Invisigoth I asked him about the services. At first he just smiled at me. The sort of, “Well, kid, get a team and get to the finals and you’ll find out” kind of smile. Relenting only a little, he told me that there were three levels of services: Easy, Hard, and (of course) Kenshoto. The pinnacle process, meaning the one they deemed the most difficult, was named “Manshetwa.” As he described it to me I was quickly confused. So, if I completely botch this description I hope that they forgive me or, at least, correct me in the comments. Manshetwa was a binary program within a program. Actually it was three programs running inside of a parent program that acted like a custom virtual machine. (BTW, all of the services are custom for this contest.) The parent program monitored the three processes and also attached to each of them as a debugger so that no team could attached another debugger to any of the programs. The programs acted, in conjunction, as a service. One of the programs accepted input from the network on a specific port. After accepting the information this program decrypted the input and sent the information to the second program. The second program used this input to generate some custom assembly code which it passed to the third process. After accepting the assembly code the third process ran the code. A little fuzzy? It is to me as well. I don’t have any more answers than that because Invisigoth had other duties as required and to this point I had taken enough of his time. I can only assume that if the third program runs the correct code the team sending the information accomplished a Breakthru. Of course, this service was designed to be almost impossible to exploit. In fact, Invisigoth looked at this service as a time killer. Any team who assigned an individual to work on this service in order to benefit from the massive amounts of points associated with it were merely wasting man power. He mentioned how @tlas, the team leader for l@stplace, had specifically forbade his binary analysis expert from even looking at the service for this very reason.

In the end, out of eight teams from around the world, team l@stplace repeated their victory. The whole team was awarded another DefCon Black Badge and Leather Jacket. You can read what @tlas had to say about it in his post “Play it again, Sam.” He also links to several of his team member sites so you should check out their comments as well.

When it was all said and done I was very happy I spent a little extra time in the CTF area. Invisigoth was more than helpful basically because the competition ran fairly smoothly and because he appeared to be having a great time. I also enjoyed watching the professionalism and drive of all of the teams involved and it made me long for working with a team of elite and dedicated individuals again. I am hoping that I can get a few of the Security Catalyst Community interested in the CTF next year. After our success with the Mystery Box challenge I don’t think that will be very hard. The hardest part will be getting them to pick between the two.

Go forth and do good things,
Cutaway

DefCon15, @tlas, l@stplace, Kenshoto, CTF, WarGamez, Invisigoth, Security Ripcord

Plenty of people have already blogged on the DefCon 15 badge. Joe “Kingpin” Grand did an outstanding job so I thought I would give everybody a taste of each badge running around during the conference.

Lets go in a sort of unofficial rank order from lowest to highest.

1. Press Badge

2. Human Badge

3. Speaker Badge

3. Goon Badge with Ninja Party Invitation

4. Black Badge

Unfortunately I did not get a picture of Kingpin’s badge as I didn’t think about doing this until the last few minutes of the conference. Special thanks to James Costello for the Human badge, Arthur from Emergent Chaos for the Speaker badge, Grifter for the Goon badge with Ninja Party invite, and Priest for allowing me to photo the table full of Black badges. Yes, the Press badge is mine.

Go forth and do good things,
Cutaway

DefCon15, Kingpin, badge, Grifter, Priest, Arthur, Security Ripcord, Joe Grand

Now that I am back from my very first DefCon experience I have two questions. “Why did I miss the previous 15? What was I thinking?”

From the very start the whole trip seemed like it was on a slow and deadly spiral downhill. I got packing late and had to rush. I couldn’t get the Sprint EVDO card running under BackTrack 2.0 installed on a Dell D600. I suddenly had to do actual work while I was on the trip so I had to take my Mac Book Pro but couldn’t get the Verison EDVO card for it because it was locked away in a file cabinet (now that I know a bit about lock picking I could have gotten it). Then, when I finally got to Las Vegas I realized that I had never been here and I had no idea about how to get to the Riviera.

Once I got to the Riviera things started to pick up a bit. I met up with Mike Henry who graciously let me sleep in his room with he and Martin McKeay. We soon met up with Larry Pesce and Jon Squire and we all loaded into a cab for the Accuvant party at Mandalay Bay. This turned out to be a great move because of the open liquor and sushi bar. I also got a chance to met with several of the Accuvant attendees and they were all very knowledgeable and friendly. I can definitely see why Michael Farnum (who did not attend DefCon) likes his job so much. After the party it was back to the hotel for my last real nights sleep for the next couple of days.

In the morning it was on. I had already picked up my Press badge (Thank you very much, Nico!!) so I filtered into one of the sessions. Sean M. Bodmer, the Director of Federal and Military Programs at Savid Technologies, gave a talk on how it is important to extend your incident response plan to include “attack characterization” in order to understand why you are being attacked and by whom. After the presentation I asked him a few quick questions about how much extra time this would cost an incident response team, if he had a common framework the community could leverage, and if there was a central repository so that people could look for similar attack methodologies to help them identify attackers. He told me that once an organization had a framework in place it only takes about 6 to 8 extra hours to detail the attack methodologies and familiarize the rest of the team with the results. The framework that as been developed by Savid is not public as they have not been approached to make it available to anybody else. Same goes for the database of attackers. Although I like his idea I very much doubt that a small or even mid-sized business has the extra funds and manpower to devote to this extra work (I’m not saying it wouldn’t be helpful information, just that it will be hard to promote). Large business including the government, however, could definitely benefit from this type of information. Also, I am surprised that he did not offer a common framework to this approach. Obviously he and his team are very knowledgeable about how to profile attacks and attribute them to specific individuals. I would have like to have seen them take this next step especially since they were presenting this at DefCon.

After this first presentation I decided to wander around a bit. It only took me a few minutes to end up in the WarGamez Capture the Flag room where eight teams from around the world were diligently setting up their systems and preparing for the competition. A few minutes of looking around showed me that Kenshoto was running this event so I quickly cornered one of their members to get a quick introduction and ask him if he was open to answering questions periodically during the con. This person turn out to be “invisigoth” and he was more than happy to help while he was not assisting the competitors. There will be more about his competition in the near future.

By the time I finished up in the CTF room and wondering through the vendor area, it was time to start the Mystery Box Challenge. Volunteering to be a member on the Security Catalyst team was definitely the best move that I could have made. Firstly, the contest is an embodiment of everything that DefCon represents. Break in anyway that you can using any resource that is necessary. Secondly, I couldn’t have been a part of a better team. Although none of us were particularly strong in all aspects necessary to complete the challenge, each one of us brought a necessary skill level. Together we knew how to get it done or somebody who could help us do it. Although we did not win I am very proud of the fact that we kept the amount of outside influence to a bare minimum (basically, we need a lock picker). Although I could write up exactly how we did everything I would rather point you to James Costello post titled “Back from DefCon” which sums it up very nicely.

After 36 hours with 2 hours of sleep I was dead beat. I tried to wander around some of the parties but my body was not up to it. Everybody I talked to told me not to sleep at DefCon but I just couldn’t help myself.

After such a positive and involving experience of the Mystery Box the rest of DefCon was a bit uneventful. The TCP/IP Drinking Game and Hacker Jeopardy were fun (Winn Schwartau is hilarious BTW) but I didn’t get the same sense as trying break into something. As this was my first DefCon, however, I felt it was important to experience some of the things that make it DefCon.

The next day however, it was back to trying to learn new tips and tricks. I spent the day floating in and out of the Lockpick Village, the Wireless Village, the CTF competition area, and one or two talks. The only other talk that I was impressed by was the one given by Marc Weber Tobias and Matt Fiddler titled “High Insecurity: Locks, Lies, and Liability”. They had a very informative presentation that points out some of the inconsistencies of physical security. Oh, yeah, I just remembered Matt Richard and Fred Doyle also gave an interesting talk titled “Beyond Vulnerability Scanning - Extrusion and Exploitability Scanning”. Basically they have created a set of tools that can test an organization’s outbound countermeasures.

Wow, I just realized how long this post has turned out to be. I guess I can really sum up DefCon as a great opportunity to meet new people and participate in competitions that stretch your imagination and skill sets. What more could you as for beside “how do I do this year around”?

Will I return to DefCon next year? I have already started working on the very topic and hopefully my wife and I can negotiate a sufficient exchange of personal vacation time to get me out to DefCon 16.

One thing of interest that I did take way from DefCon was the emphasis to physical security. What I mean is that the Lockpick Village was completely pack from the moment it opened to the moment they closed down the area and asked everybody to leave. What does this mean to your organization? Well, if hackers are looking into this then maybe you should start considering what you are doing and where the weaknesses might manifest themselves within your environment. You might have the best OS hardening skills in the business. But if you cannot limit and protect the physical access to your systems and other resources then you are going to be in serious trouble.

Go forth and do good things,
Cutaway

DefCon15, Kenshoto, invisigoth, CTF, GenesysWave, Security Ripcord, Mystery Box Challenge, James Costello