Immunity Certified Network Offense Professional

[Dave Aitel]

Immunity is proud to announce the launch of our new certification, the
Network Offense Professional (NOP) at Defcon. NOP will allow prospective
employers to know that you have the capabilities needed to understand
the complex issues at the heart of information security.

Specifically, to obtain the certification you will need to write a
buffer overflow from scratch within a certain time period. You will
first find the buffer overflow by reverse engineering a target program,
and then obtain a shell from it or execute a command. This is a hands-on
certification, not a paper test. Immunity Debugger, Immunity CANVAS, and
VisualSploit will be available to you during the certification process
to enable you to write the exploit quickly. The target process will be
running on a Windows 2000 SP4 machine.

Successfully completing the challenge will allow you to use the NOP
signifier after your name and will potentially allow you to obtain
discounts of Immunity products.

Taking the NOP certification is on a first come first serve basis. Come
to the Immunity Defcon booth and try your hand.

Any inquiries can be sent to ***@immunityinc.com.

Thanks,
Dave Aitel
VP Media Relations
Immunity, Inc.

[Blue Boar]

Post by Dave Aitel
Specifically, to obtain the certification you will need to write a
buffer overflow from scratch within a certain time period. You will
first find the buffer overflow by reverse engineering a target program,
and then obtain a shell from it or execute a command. This is a hands-on
certification, not a paper test.

Sounds like potentially a meaningful, if narrow, test.

Post by Dave Aitel
Immunity Debugger, Immunity CANVAS, and
VisualSploit will be available to you during the certification process
to enable you to write the exploit quickly.

ONLY those? If so, that would make yours a cert that is potentially
somewhat interesting, but still is designed to promote a particular
vendor's tools.

I'm pretty lost doing RE work without IDA Pro. Probably wouldn't make
much difference in my case regardless. I can write you a simple stack
overflow exploit given enough time, but probably not with a time limit.
Especially not with an unfamiliar environment. And Halle Berry giving me
a handjob. But I'm probably not the target audience?

Post by Dave Aitel
Successfully completing the challenge will allow you to use the NOP
signifier after your name and will potentially allow you to obtain
discounts of Immunity products.

I like the name, though.

BB

[Thomas Ptacek]

Post by Blue Boar

Post by Dave Aitel
Specifically, to obtain the certification you will need to write a
buffer overflow from scratch within a certain time period. You will
first find the buffer overflow by reverse engineering a target program,
and then obtain a shell from it or execute a command. This is a hands-on
certification, not a paper test.

Sounds like potentially a meaningful, if narrow, test.

Some of the most effective pentesters I've met would not be able to
pass this. This is the problem with all certifications.

I get the "joke" here, so don't take that as a criticism. Although you
should have made an acronym for MOV AX, AX work instead.

[Alexander Sotirov]

Post by Thomas Ptacek
I get the "joke" here, so don't take that as a criticism. Although you
should have made an acronym for MOV AX, AX work instead.

What is this, 1992? It's MOV EAX, EAX now, get on with the times!

Alex

[Rodney Thayer]

Yeah, yeah, and we can all share stories about the old timers
working for Novell who, when overworked and travelling through the Salt
Lake City airport, started to see the gate numbers as op codes.

This being back when Novell wrote x86 code anyone cared about. Before
we all realized SMB was the answer to all the world's problems.

(Gate C3 == SJC flights and that's what, a short jump in x86?)

Post by Alexander Sotirov

Post by Thomas Ptacek
I get the "joke" here, so don't take that as a criticism. Although you
should have made an acronym for MOV AX, AX work instead.

What is this, 1992? It's MOV EAX, EAX now, get on with the times!

[root]

Post by Thomas Ptacek

Post by Blue Boar

Post by Dave Aitel
Specifically, to obtain the certification you will need to write a
buffer overflow from scratch within a certain time period. You will
first find the buffer overflow by reverse engineering a target program,
and then obtain a shell from it or execute a command. This is a hands-on
certification, not a paper test.

Sounds like potentially a meaningful, if narrow, test.

Some of the most effective pentesters I've met would not be able to
pass this. This is the problem with all certifications.

I think that exploit writing is a very different activity than pen testing.
And even if a pen-tester get that certification, he would be writing an
exploit for a platform 8 years old, without any modern BOF protection. I
wonder what is the point.

[Dave Aitel]

Thomas Ptacek wrote:
|> > Specifically, to obtain the certification you will need to write a
|> > buffer overflow from scratch within a certain time period. You will
|> > first find the buffer overflow by reverse engineering a target
program,
|> > and then obtain a shell from it or execute a command. This is a
hands-on
|> > certification, not a paper test.
|> Sounds like potentially a meaningful, if narrow, test.
|
| Some of the most effective pentesters I've met would not be able to
| pass this. This is the problem with all certifications.
Then they'd fail. There's no excuse for not being able to write a simple
Windows stack overflow in this day and age. I don't see this part as a
problem. Even web attackers need to know how to do that.

It is hard, of course, to isolate a hands on test from the tools you
have to use to do that test. VisualSploit and Immunity Debugger are
really easy to use, but if you are only capable of using WinDBG then you
might fail as well. In that case, you'd need to learn how to pick up new
tools faster. We'll have an instruction book available at the table. :>

- -dave

[Thomas Ptacek]

Post by Dave Aitel
Then they'd fail. There's no excuse for not being able to write a simple
Windows stack overflow in this day and age. I don't see this part as a
problem. Even web attackers need to know how to do that.

Web attackers do not need to know how to write stack overflows, Dave.
If you can code, you don't even need to know how to write stack
overflows to pen-test shrink wrap software.

Two observations, which I can make because our team can obviously
throw down the archaic exploit writing skills:

- In the commercial market, the ability to find vulnerabilities
commands a far higher price than the ability to write exploits. This
isn't opinion; it's simply empirical. People who actually write
exploits all day tend to work for vendors. A majority of consultants
can't.

- Most of the game-over vulnerabilities we find aren't code injection
anymore. You're proposing a metric that could fail someone who can do
DH parameter tampering, because they don't know the X86 Windows system
call gate.

Post by Dave Aitel
It is hard, of course, to isolate a hands on test from the tools you
have to use to do that test. VisualSploit and Immunity Debugger are
really easy to use, but if you are only capable of using WinDBG then you
might fail as well. In that case, you'd need to learn how to pick up new
tools faster. We'll have an instruction book available at the table. :>
- -dave
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIeQZjtehAhL0gheoRAvtcAKCGJUNoPLtsEEyKio9y5jOnuYBM2wCfQY3k
CtWVHv6SwDthKJorIEWlwg8=
=O5qQ
-----END PGP SIGNATURE-----
_______________________________________________
Dailydave mailing list
http://lists.immunitysec.com/mailman/listinfo/dailydave

[Pusscat]

The problem I see with this is that people that can't write a simple
exploit also cannot to other very important tasks such as:

- Decide if a crash is exploitable at all
- Make a judgement about the reliability of any exploits written
- Debug the crash to see what input caused the crash in a reasonable time limit
- Discuss possible fixes intellegently
- Apply knowledge of the crash to other areas of the program to ensure
that the bug isn't repeated and that the fix is in fact complete

Exploitation of a simple vuln requires only simple knowledge of how
x86 systems and the windows OS works, and some experience makimaking
effective use of your tools work in a timely fashion. In my oppinion
Dave's cert is just an effective test of basic knowledge and skills in
one tiny package.

- Lurene

Post by Thomas Ptacek

Post by Dave Aitel
Then they'd fail. There's no excuse for not being able to write a simple
Windows stack overflow in this day and age. I don't see this part as a
problem. Even web attackers need to know how to do that.

Web attackers do not need to know how to write stack overflows, Dave.
If you can code, you don't even need to know how to write stack
overflows to pen-test shrink wrap software.
Two observations, which I can make because our team can obviously
- In the commercial market, the ability to find vulnerabilities
commands a far higher price than the ability to write exploits. This
isn't opinion; it's simply empirical. People who actually write
exploits all day tend to work for vendors. A majority of consultants
can't.
- Most of the game-over vulnerabilities we find aren't code injection
anymore. You're proposing a metric that could fail someone who can do
DH parameter tampering, because they don't know the X86 Windows system
call gate.

Post by Dave Aitel
It is hard, of course, to isolate a hands on test from the tools you
have to use to do that test. VisualSploit and Immunity Debugger are
really easy to use, but if you are only capable of using WinDBG then you
might fail as well. In that case, you'd need to learn how to pick up new
tools faster. We'll have an instruction book available at the table. :>
- -dave
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIeQZjtehAhL0gheoRAvtcAKCGJUNoPLtsEEyKio9y5jOnuYBM2wCfQY3k
CtWVHv6SwDthKJorIEWlwg8=
=O5qQ
-----END PGP SIGNATURE-----
_______________________________________________
Dailydave mailing list
http://lists.immunitysec.com/mailman/listinfo/dailydave

--
---
Thomas H. Ptacek // matasano security
read us on the web: http://www.matasano.com/log
_______________________________________________
Dailydave mailing list
http://lists.immunitysec.com/mailman/listinfo/dailydave

[Thomas Ptacek]

Post by Pusscat
The problem I see with this is that people that can't write a simple
- Decide if a crash is exploitable at all

Plenty of people who can't write X86 assembly can discern whether a
flaw allowed them to corrupt memory. Plenty of people who can write
X86 assembly, like myself, are content to leave it at that: memory
corruption bad. MUSTFIX.

Post by Pusscat
- Make a judgement about the reliability of any exploits written

This is circular. Sure, if you write exploits, knowing how to do so
reliably will in fact improve the quality of the checks you write for
your company's scanner.

Post by Pusscat
- Debug the crash to see what input caused the crash in a reasonable time limit

This isn't true. Basic investigative skills, of the sort possessed by
many 2nd tier call center operators, coupled with the ability to
generate malicious outputs, and you've got this one nailed. I agree
it's important, so test for it.

Post by Pusscat
- Discuss possible fixes intellegently

What does ret-to-libc have to do with knowing how to manage sign bits,
check multiplications, or bound copies?

Post by Pusscat
- Apply knowledge of the crash to other areas of the program to ensure
that the bug isn't repeated and that the fix is in fact complete

It really sounds like you want to test people's ability to write
fuzzers. Amen to that. I'm not sure where the shellcode comes in to
it, though.

[matthew wollenweber]

I'd like to add two points to this discussion. First is that a key value I
try to present to clients is that pen testing shows business impact. It lets
a manager understand why security is important to the business. A list of
vulnerabilities for IPs doesn't demonstrate quite the same impact as
controlling some core business system. So successfully exploiting vulns is
important to me.

Second, I see terribly insecure apps across enterprises all the time.
They're niche products or internally developed that often sit on key
systems. They usually don't have public vulns because they're internal or
niche but if you sit down with them they're generally easy enough to break.
So doing so is reasonable way to get into a fully patched system. It also
makes you look good and reinforces security best practices like
compartmentalization, defense in depth, etc.

So while I agree pen testers don't need to be exploit developers and it
isn't a skill that's always needed, I'd add that it is one that can really
turn a vanilla assessment into cool work.

Post by Thomas Ptacek

Post by Pusscat
The problem I see with this is that people that can't write a simple
- Decide if a crash is exploitable at all

Plenty of people who can't write X86 assembly can discern whether a
flaw allowed them to corrupt memory. Plenty of people who can write
X86 assembly, like myself, are content to leave it at that: memory
corruption bad. MUSTFIX.

Post by Pusscat
- Make a judgement about the reliability of any exploits written

This is circular. Sure, if you write exploits, knowing how to do so
reliably will in fact improve the quality of the checks you write for
your company's scanner.

Post by Pusscat
- Debug the crash to see what input caused the crash in a reasonable

time limit
This isn't true. Basic investigative skills, of the sort possessed by
many 2nd tier call center operators, coupled with the ability to
generate malicious outputs, and you've got this one nailed. I agree
it's important, so test for it.

Post by Pusscat
- Discuss possible fixes intellegently

What does ret-to-libc have to do with knowing how to manage sign bits,
check multiplications, or bound copies?

Post by Pusscat
- Apply knowledge of the crash to other areas of the program to ensure
that the bug isn't repeated and that the fix is in fact complete

It really sounds like you want to test people's ability to write
fuzzers. Amen to that. I'm not sure where the shellcode comes in to
it, though.
--
---
Thomas H. Ptacek // matasano security
read us on the web: http://www.matasano.com/log
_______________________________________________
Dailydave mailing list
http://lists.immunitysec.com/mailman/listinfo/dailydave

[Thomas Ptacek]

NB: I'm not talking because I think Dave is evil. I already knew Dave
was evil. I'm talking because this is an interesting topic.

I agree: being able to bust into enterprise applications is a great
way to ace an internal pentest. But even then, the best findings are
often not memory corruption vulnerabilities. When we talk about the
terribly insecure apps across enterprises, we should be thinking about
shell metacharacters.

Post by matthew wollenweber
Second, I see terribly insecure apps across enterprises all the time.
They're niche products or internally developed that often sit on key
systems. They usually don't have public vulns because they're internal or
niche but if you sit down with them they're generally easy enough to break.
So doing so is reasonable way to get into a fully patched system. It also
makes you look good and reinforces security best practices like
compartmentalization, defense in depth, etc.

[val smith]

So I spend a chunk of of my time breaking into computers using old
fashioned techniques (see Tactical Exploitation last years BH
shameless plug) or via web apps. Another chunk of my time reversing
malware in Olly, IDA (starting to look at Immunity Debugger). I
wouldn't call myself an expert exploit developer at the level of some
of the people on this list but I realized a few years ago that being
able to write simple buffer overflows would greatly help me to
understand what all was going on when I broke into a computer.

The skills I gained writing some overflows; like how to use gdb,
windbg, watch network traffic to see what was getting sent, looking at
memory to find my AAAAA's or shellcode, were invaluable in just
getting a feel for how computers and bugs work in general.

Many times I'll download an exploit and find out that it doesn't work,
or isn't reliable and have to port it to metasploit for use on a pen
test. If I didn't have some skills to do this my pen test would be
less successful.

I guess the point of all this rambling is that while not being an
expert in exploit dev, the more you know in general about diverse
subjects in security, the more effective you'll be at your infosec
job, whatever it may be. Like I suspect a lot of people on here, I
don't really have much respect for certifications, but Dave's new
thing might at least spice things up a bit and provide some fun. I
might need a blond, some tequila and a gun to my head to succeed, then
maybe I'll play too :)

V.

Post by Thomas Ptacek

Post by Pusscat
The problem I see with this is that people that can't write a simple
- Decide if a crash is exploitable at all

Plenty of people who can't write X86 assembly can discern whether a
flaw allowed them to corrupt memory. Plenty of people who can write
X86 assembly, like myself, are content to leave it at that: memory
corruption bad. MUSTFIX.

Post by Pusscat
- Make a judgement about the reliability of any exploits written

This is circular. Sure, if you write exploits, knowing how to do so
reliably will in fact improve the quality of the checks you write for
your company's scanner.

Post by Pusscat
- Debug the crash to see what input caused the crash in a reasonable time limit

This isn't true. Basic investigative skills, of the sort possessed by
many 2nd tier call center operators, coupled with the ability to
generate malicious outputs, and you've got this one nailed. I agree
it's important, so test for it.

Post by Pusscat
- Discuss possible fixes intellegently

What does ret-to-libc have to do with knowing how to manage sign bits,
check multiplications, or bound copies?

Post by Pusscat
- Apply knowledge of the crash to other areas of the program to ensure
that the bug isn't repeated and that the fix is in fact complete

It really sounds like you want to test people's ability to write
fuzzers. Amen to that. I'm not sure where the shellcode comes in to
it, though.
--
---
Thomas H. Ptacek // matasano security
read us on the web: http://www.matasano.com/log
_______________________________________________
Dailydave mailing list
http://lists.immunitysec.com/mailman/listinfo/dailydave

[Paul Melson]

Post by Pusscat
- Decide if a crash is exploitable at all
- Make a judgement about the reliability of any exploits written
- Debug the crash to see what input caused the crash in a reasonable time limit
- Discuss possible fixes intellegently
- Apply knowledge of the crash to other areas of the program to ensure
that the bug isn't repeated and that the fix is in fact complete

All of the above can be done without any shellcode, just your favorite
compiler/interpreter and a debugger. And with commonly available
tools like Metasploit's shellcode generator, it's trivial to weaponize
your overflow, especially on Win2K. All of this adds up to a
successful penetration test, providing value to the client. But it
wouldn't get you a NOP cert. Who cares? If you're doing this in the
field already, who's asking you for a cert? Are there pen-testing
firms that are A) any good at it and B) clamoring for their staff to
have certifications? Just folks dealing with the 8570.1M mandate,
right?

Post by Pusscat
Exploitation of a simple vuln requires only simple knowledge of how
x86 systems and the windows OS works, and some experience makimaking
effective use of your tools work in a timely fashion. In my oppinion
Dave's cert is just an effective test of basic knowledge and skills in
one tiny package.

No, Immunity's cert is a test of how good you are at it using
Immunity's products. Which is fine, every vendor with a cert does
exactly this. Let's not make it something it's not.

PaulM

[drraid]

Post by Thomas Ptacek

Post by Dave Aitel
Then they'd fail. There's no excuse for not being able to write a simple
Windows stack overflow in this day and age. I don't see this part as a
problem. Even web attackers need to know how to do that.

Web attackers do not need to know how to write stack overflows, Dave.
If you can code, you don't even need to know how to write stack
overflows to pen-test shrink wrap software.
Two observations, which I can make because our team can obviously
- In the commercial market, the ability to find vulnerabilities
commands a far higher price than the ability to write exploits. This
isn't opinion; it's simply empirical. People who actually write
exploits all day tend to work for vendors. A majority of consultants
can't.
- Most of the game-over vulnerabilities we find aren't code injection
anymore. You're proposing a metric that could fail someone who can do
DH parameter tampering, because they don't know the X86 Windows system
call gate.

Many consultants can't actually exploit buffer overflows, but almost all of
them can describe the process to do it. It seems that these people are more
fit to consult on how these vulnerabilities work instead of if something is
actually vulnerable. This could be one of the big problems with the industry.

"Web attackers" is too vague here -- if you're talking about owning something
named /cgi-bin/custom_request.exe, then yes, being that this is an archaic web
application, you probably do need archaic memory corruption
exploitation skills.
Obviously the SQL injection, RFI/LFI, XSS/CSRF doesn't require this.

I would generally agree that anyone selling themselves as a pen-tester should
be able to pass this -- but not at the exclusion of also being able to identify
poor use of crypto, architectural failures or web application
vulnerabilities. Maybe
the dispute here is in understanding what the purpose of this certification is.

[Thomas Ptacek]

Post by drraid
I would generally agree that anyone selling themselves as a pen-tester should
be able to pass this -- but not at the exclusion of also being able to identify
poor use of crypto, architectural failures or web application
vulnerabilities. Maybe
the dispute here is in understanding what the purpose of this certification is.

No, see, I'm saying something different --- I'm saying that people who
sell themselves as pen-testers DO NOT need the skills this test looks
for. Ability to FIND overflows is more valuable than the ability to
EXPLOIT them.

[root]

In my short experience finding bugs and exploiting them, i have found
that the task of writing a reliable exploit is *orders of magnitude*
more complex and require much more experience than the required to only
find a bug.
Anyone can fire a fuzer, find a bug and tell their client about how
exploitable it is.
People then will talk about ret-to-libc and malloc tricks that really
don't work anymore in modern systems.
IMHO, only somebody with the technical expertise to write the actual
exploit can know the real extent of the vulnerability.

Sorry the rant, is late here :)

Post by Thomas Ptacek

Post by drraid
I would generally agree that anyone selling themselves as a pen-tester should
be able to pass this -- but not at the exclusion of also being able to identify
poor use of crypto, architectural failures or web application
vulnerabilities. Maybe
the dispute here is in understanding what the purpose of this certification is.

No, see, I'm saying something different --- I'm saying that people who
sell themselves as pen-testers DO NOT need the skills this test looks
for. Ability to FIND overflows is more valuable than the ability to
EXPLOIT them.

[Thomas Ptacek]

Post by root
Anyone can fire a fuzer, find a bug and tell their client about how
exploitable it is.
People then will talk about ret-to-libc and malloc tricks that really
don't work anymore in modern systems.

This is NO DOUBT true. It is obviously much HARDER to exploit modern
memory corruption flaws than it is to find them. Respect, yo. S'all
love in here.

The problem is, it is not MORE VALUABLE to exploit memory corruption
flaws than it is to find them. Consider two scenarios:

(1) A shrink-wrap software pen test, for a vendor or a customer ---
the target is one application. You have 5 days. Unless you think you
can sweep 500,000 lines of C code clean of vulnerabilities in 40
hours, an hour spent on exploit dev is an hour not spent finding
vulnerabilities.

(2) A network penetration test. You have 5 days. Unless you have found
the zero enterprises in the world where access to their network
doesn't immediately offer up 30 different mass casualty scenarios, an
hour spent on exploit dev is an hour not spent breaking into systems.

We could go back and forth on (2) --- no doubt there are NPT's where
being able to bust CreateProcess in some sleazy Windows backup
software is going to win the game for you (there are also NPTs where
the client says, "tell me about the zero-day mass casualty exploits
you could have run, but don't stop testing until you get in without
cheating").

And another thing: we all know about the "fuzz kiddies", but that
doesn't make all vulnerability research a matter of aiming /dev/random
at a socket and writing an advisory on the xor ebx,ebx; mov eax, [ebx]
findings. Plenty of people cheat at writing exploits too.

[Paul Melson]

Post by Thomas Ptacek
The problem is, it is not MORE VALUABLE to exploit memory corruption
(1) A shrink-wrap software pen test, for a vendor or a customer ---
the target is one application. You have 5 days. Unless you think you
can sweep 500,000 lines of C code clean of vulnerabilities in 40
hours, an hour spent on exploit dev is an hour not spent finding
vulnerabilities.

The thing about exploits in pen-testing is that they're not really
necessary for the client or the client's code. They're more for the
vendor of the shrink-wrap software that you're testing. A client
smart enough to pay for a pen-test (as opposed to a vulnerability
assessment) will also be able to understand they should fix their code
when you show them a screenshot of gdb showing EIP = 0x41414141. But
vendors are another story - you've gotta have a highly reliable PoC
exploit before they do anything at all for your client in terms of a
fix. (This is why billing T&M for a pen-test is convenient - you
don't have to ask your client to sign another contract to code the PoC
and sit through the conference calls with the vendor.)

Post by Thomas Ptacek
Plenty of people cheat at writing exploits too.

Cheating at exploit writing is like cheating at running. Except when
you're in competition, nobody cares if you drove a car, so long as you
arrived at the correct destination.

PaulM

[val smith]

I'm going to have to award the point to Thomas here. The scenarios he
presented are very often what I get myself. Super compressed time
frame, unlikely to achieve goal so any time I spend developing tools
or exploits is time I lose achieving the goal.

I've also recently had an app test where I had something like 6 hours.
There was no way (for me cause I suck) to come up with working exploit
in that time, but I was able to find half a dozen bugs and report
them. In this case knowing how to write an exploit wouldn't do me much
good.

However I'll have to say i've run into maybe 1 place in the world
where getting access to 1 host didn't get me much. (mac locking on
ports, 1 time passwords everywhere, no shared admin accounts, or admin
from console only, lots of vlanning, etc.)

Cheating is what its all about. I have this think I call the cooking
show hack. You know in a cooking show how they make the food and put
it in the oven then pull one out already cooked and try it. Same thing
but with rootshell :)

Fuzzy kiddies just sounds wrong man, just wrong.

V.

Post by Thomas Ptacek

Post by root
Anyone can fire a fuzer, find a bug and tell their client about how
exploitable it is.
People then will talk about ret-to-libc and malloc tricks that really
don't work anymore in modern systems.

This is NO DOUBT true. It is obviously much HARDER to exploit modern
memory corruption flaws than it is to find them. Respect, yo. S'all
love in here.
The problem is, it is not MORE VALUABLE to exploit memory corruption
(1) A shrink-wrap software pen test, for a vendor or a customer ---
the target is one application. You have 5 days. Unless you think you
can sweep 500,000 lines of C code clean of vulnerabilities in 40
hours, an hour spent on exploit dev is an hour not spent finding
vulnerabilities.
(2) A network penetration test. You have 5 days. Unless you have found
the zero enterprises in the world where access to their network
doesn't immediately offer up 30 different mass casualty scenarios, an
hour spent on exploit dev is an hour not spent breaking into systems.
We could go back and forth on (2) --- no doubt there are NPT's where
being able to bust CreateProcess in some sleazy Windows backup
software is going to win the game for you (there are also NPTs where
the client says, "tell me about the zero-day mass casualty exploits
you could have run, but don't stop testing until you get in without
cheating").
And another thing: we all know about the "fuzz kiddies", but that
doesn't make all vulnerability research a matter of aiming /dev/random
at a socket and writing an advisory on the xor ebx,ebx; mov eax, [ebx]
findings. Plenty of people cheat at writing exploits too.
_______________________________________________
Dailydave mailing list
http://lists.immunitysec.com/mailman/listinfo/dailydave

[Dino A. Dai Zovi]

Believe it or not, there are still operations people in this world who
will not properly prioritize a security vulnerability unless they are
properly shown its ramifications. Telling someone that a three tier
architecture with the web tier on the DMZ and the application tier on
the internal network is risky may not be enough to drive the point
home.

Finding and exploiting an 0day vuln in the app server and being able
to call the admin up and tell him that you have a remote SYSTEM shell
on it from the Internet makes the point much better. After they pick
the phone back up, they usually start doing whatever it takes to fix
the problem as soon as possible.

Without vulnerability exploitation skills, effecting that change would
have required a political battle and I'm distinctly better at
exploitation than politics.

-Dino

On Tue, Jul 15, 2008 at 2:38 PM, val smith

Post by val smith
I'm going to have to award the point to Thomas here. The scenarios he
presented are very often what I get myself. Super compressed time
frame, unlikely to achieve goal so any time I spend developing tools
or exploits is time I lose achieving the goal.
I've also recently had an app test where I had something like 6 hours.
There was no way (for me cause I suck) to come up with working exploit
in that time, but I was able to find half a dozen bugs and report
them. In this case knowing how to write an exploit wouldn't do me much
good.
However I'll have to say i've run into maybe 1 place in the world
where getting access to 1 host didn't get me much. (mac locking on
ports, 1 time passwords everywhere, no shared admin accounts, or admin
from console only, lots of vlanning, etc.)
Cheating is what its all about. I have this think I call the cooking
show hack. You know in a cooking show how they make the food and put
it in the oven then pull one out already cooked and try it. Same thing
but with rootshell :)
Fuzzy kiddies just sounds wrong man, just wrong.
V.

Post by Thomas Ptacek

Post by root
Anyone can fire a fuzer, find a bug and tell their client about how
exploitable it is.
People then will talk about ret-to-libc and malloc tricks that really
don't work anymore in modern systems.

This is NO DOUBT true. It is obviously much HARDER to exploit modern
memory corruption flaws than it is to find them. Respect, yo. S'all
love in here.
The problem is, it is not MORE VALUABLE to exploit memory corruption
(1) A shrink-wrap software pen test, for a vendor or a customer ---
the target is one application. You have 5 days. Unless you think you
can sweep 500,000 lines of C code clean of vulnerabilities in 40
hours, an hour spent on exploit dev is an hour not spent finding
vulnerabilities.
(2) A network penetration test. You have 5 days. Unless you have found
the zero enterprises in the world where access to their network
doesn't immediately offer up 30 different mass casualty scenarios, an
hour spent on exploit dev is an hour not spent breaking into systems.
We could go back and forth on (2) --- no doubt there are NPT's where
being able to bust CreateProcess in some sleazy Windows backup
software is going to win the game for you (there are also NPTs where
the client says, "tell me about the zero-day mass casualty exploits
you could have run, but don't stop testing until you get in without
cheating").
And another thing: we all know about the "fuzz kiddies", but that
doesn't make all vulnerability research a matter of aiming /dev/random
at a socket and writing an advisory on the xor ebx,ebx; mov eax, [ebx]
findings. Plenty of people cheat at writing exploits too.
_______________________________________________
Dailydave mailing list
http://lists.immunitysec.com/mailman/listinfo/dailydave

--
******************************************
* Val Smith
* CTO Offensive Computing, LLC
* http://www.offensivecomputing.net
*******************************************
_______________________________________________
Dailydave mailing list
http://lists.immunitysec.com/mailman/listinfo/dailydave

[val smith]

Amen on exploitation vs politics. Must devise some sort of political
0day. I gotta be honest though, many places don't even do much if you
show them you have a remote SYSTEM shell. A lot of times I'll come
back a year later to a place and get in with the same bugs, even find
my same backdoor accounts (which they were aware of and promised to
remove) still there. Makes the pentest alot quicker / easier though.

They will rationalize their lack of fixing things one way or another,
whether it be resources, time, what the fix might break, etc. I've
also hears "well of course you got in, your GOOD, not like the real
attackers", or worse "well you got in because you know about stuff
here, no one else will figure that out".

I'm not sure any certification, even Dave's, will make these kinda
places more likely to listen. (Since we started on the subject of the
cert :)

V.

ps I realize I am much too fond of parenthesis in my posts, sorry.

Post by Dino A. Dai Zovi
Believe it or not, there are still operations people in this world who
will not properly prioritize a security vulnerability unless they are
properly shown its ramifications. Telling someone that a three tier
architecture with the web tier on the DMZ and the application tier on
the internal network is risky may not be enough to drive the point
home.
Finding and exploiting an 0day vuln in the app server and being able
to call the admin up and tell him that you have a remote SYSTEM shell
on it from the Internet makes the point much better. After they pick
the phone back up, they usually start doing whatever it takes to fix
the problem as soon as possible.
Without vulnerability exploitation skills, effecting that change would
have required a political battle and I'm distinctly better at
exploitation than politics.
-Dino
On Tue, Jul 15, 2008 at 2:38 PM, val smith

Post by val smith
I'm going to have to award the point to Thomas here. The scenarios he
presented are very often what I get myself. Super compressed time
frame, unlikely to achieve goal so any time I spend developing tools
or exploits is time I lose achieving the goal.
I've also recently had an app test where I had something like 6 hours.
There was no way (for me cause I suck) to come up with working exploit
in that time, but I was able to find half a dozen bugs and report
them. In this case knowing how to write an exploit wouldn't do me much
good.
However I'll have to say i've run into maybe 1 place in the world
where getting access to 1 host didn't get me much. (mac locking on
ports, 1 time passwords everywhere, no shared admin accounts, or admin
from console only, lots of vlanning, etc.)
Cheating is what its all about. I have this think I call the cooking
show hack. You know in a cooking show how they make the food and put
it in the oven then pull one out already cooked and try it. Same thing
but with rootshell :)
Fuzzy kiddies just sounds wrong man, just wrong.
V.

Post by Thomas Ptacek

Post by root
Anyone can fire a fuzer, find a bug and tell their client about how
exploitable it is.
People then will talk about ret-to-libc and malloc tricks that really
don't work anymore in modern systems.

This is NO DOUBT true. It is obviously much HARDER to exploit modern
memory corruption flaws than it is to find them. Respect, yo. S'all
love in here.
The problem is, it is not MORE VALUABLE to exploit memory corruption
(1) A shrink-wrap software pen test, for a vendor or a customer ---
the target is one application. You have 5 days. Unless you think you
can sweep 500,000 lines of C code clean of vulnerabilities in 40
hours, an hour spent on exploit dev is an hour not spent finding
vulnerabilities.
(2) A network penetration test. You have 5 days. Unless you have found
the zero enterprises in the world where access to their network
doesn't immediately offer up 30 different mass casualty scenarios, an
hour spent on exploit dev is an hour not spent breaking into systems.
We could go back and forth on (2) --- no doubt there are NPT's where
being able to bust CreateProcess in some sleazy Windows backup
software is going to win the game for you (there are also NPTs where
the client says, "tell me about the zero-day mass casualty exploits
you could have run, but don't stop testing until you get in without
cheating").
And another thing: we all know about the "fuzz kiddies", but that
doesn't make all vulnerability research a matter of aiming /dev/random
at a socket and writing an advisory on the xor ebx,ebx; mov eax, [ebx]
findings. Plenty of people cheat at writing exploits too.
_______________________________________________
Dailydave mailing list
http://lists.immunitysec.com/mailman/listinfo/dailydave

--
******************************************
* Val Smith
* CTO Offensive Computing, LLC
* http://www.offensivecomputing.net
*******************************************
_______________________________________________
Dailydave mailing list
http://lists.immunitysec.com/mailman/listinfo/dailydave

[Pete Herzog]

Makes me wonder what kind of work other people are doing! Wherever I've
worked, security consulting followed penetration testing and in that
consultancy we advised the client. We had little time to test the security
let alone actually exploit anything so that if we couldn't provide a trophy
from some major bump and jump we could still report effectively on how
exposed they were to business losses caused by competitive intelligence, HR
leaks, client leaks, and of course poor use of system controls. The root
shell was nice to have if we could get it but it was not our priority and
it definitely was not what we needed to inform the client of their
problems. And if they chose not to fix them then that is their choice on
how to manage risk. I've seen pen-testers flip out because the client's
tech staff chose not to stop using email address names for extra-net
logins. They felt the risk wasn't there. That's actually their decision to
make because I don't see their balance sheets and I don't know their
business strategy and in the end it's their gamble to make. They have my
report and my notes and my tests. I can't do more.

Isn't our top job to thoroughly audit the security and safety of assets and
properly report. Properly protected infrastructures do not require
patching to maintain security. Therefore we shouldn't do free (for the
development company) Q&A on shrink-wrapped software as part of the job. We
should always assume that shrink-wrapped software, even up to the latest
patch level, will still have holes so we need to make sure that even if
exploited, proper controls assure nothing is lost.

I like the idea of a certification on writing exploit code. I think
there's a lot of q&A jobs where that would be a good fit, even on a
pen-testing team. You should team up with the OSVDB guys to offer
something less vendor-centric though. Of course you could always work with
ISECOM too....

-pete.

Post by Dino A. Dai Zovi
Believe it or not, there are still operations people in this world who
will not properly prioritize a security vulnerability unless they are
properly shown its ramifications. Telling someone that a three tier
architecture with the web tier on the DMZ and the application tier on
the internal network is risky may not be enough to drive the point
home.
Finding and exploiting an 0day vuln in the app server and being able
to call the admin up and tell him that you have a remote SYSTEM shell
on it from the Internet makes the point much better. After they pick
the phone back up, they usually start doing whatever it takes to fix
the problem as soon as possible.
Without vulnerability exploitation skills, effecting that change would
have required a political battle and I'm distinctly better at
exploitation than politics.
-Dino
On Tue, Jul 15, 2008 at 2:38 PM, val smith

Post by val smith
I'm going to have to award the point to Thomas here. The scenarios he
presented are very often what I get myself. Super compressed time
frame, unlikely to achieve goal so any time I spend developing tools
or exploits is time I lose achieving the goal.
I've also recently had an app test where I had something like 6 hours.
There was no way (for me cause I suck) to come up with working exploit
in that time, but I was able to find half a dozen bugs and report
them. In this case knowing how to write an exploit wouldn't do me much
good.
However I'll have to say i've run into maybe 1 place in the world
where getting access to 1 host didn't get me much. (mac locking on
ports, 1 time passwords everywhere, no shared admin accounts, or admin
from console only, lots of vlanning, etc.)
Cheating is what its all about. I have this think I call the cooking
show hack. You know in a cooking show how they make the food and put
it in the oven then pull one out already cooked and try it. Same thing
but with rootshell :)
Fuzzy kiddies just sounds wrong man, just wrong.
V.

Post by Thomas Ptacek

Post by root
Anyone can fire a fuzer, find a bug and tell their client about how
exploitable it is.
People then will talk about ret-to-libc and malloc tricks that really
don't work anymore in modern systems.

This is NO DOUBT true. It is obviously much HARDER to exploit modern
memory corruption flaws than it is to find them. Respect, yo. S'all
love in here.
The problem is, it is not MORE VALUABLE to exploit memory corruption
(1) A shrink-wrap software pen test, for a vendor or a customer ---
the target is one application. You have 5 days. Unless you think you
can sweep 500,000 lines of C code clean of vulnerabilities in 40
hours, an hour spent on exploit dev is an hour not spent finding
vulnerabilities.
(2) A network penetration test. You have 5 days. Unless you have found
the zero enterprises in the world where access to their network
doesn't immediately offer up 30 different mass casualty scenarios, an
hour spent on exploit dev is an hour not spent breaking into systems.
We could go back and forth on (2) --- no doubt there are NPT's where
being able to bust CreateProcess in some sleazy Windows backup
software is going to win the game for you (there are also NPTs where
the client says, "tell me about the zero-day mass casualty exploits
you could have run, but don't stop testing until you get in without
cheating").
And another thing: we all know about the "fuzz kiddies", but that
doesn't make all vulnerability research a matter of aiming /dev/random
at a socket and writing an advisory on the xor ebx,ebx; mov eax, [ebx]
findings. Plenty of people cheat at writing exploits too.
_______________________________________________
Dailydave mailing list
http://lists.immunitysec.com/mailman/listinfo/dailydave

--
******************************************
* Val Smith
* CTO Offensive Computing, LLC
* http://www.offensivecomputing.net
*******************************************
_______________________________________________
Dailydave mailing list
http://lists.immunitysec.com/mailman/listinfo/dailydave

_______________________________________________
Dailydave mailing list
http://lists.immunitysec.com/mailman/listinfo/dailydave

[Adam Shostack]

On Wed, Jul 16, 2008 at 12:48:46AM -0400, Dino A. Dai Zovi wrote:
...
| Finding and exploiting an 0day vuln in the app server and being able
| to call the admin up and tell him that you have a remote SYSTEM shell
| on it from the Internet makes the point much better. After they pick
| the phone back up, they usually start doing whatever it takes to fix
| the problem as soon as possible.
|
| Without vulnerability exploitation skills, effecting that change would
| have required a political battle and I'm distinctly better at
| exploitation than politics.

Is the person paying your salary better at exploits than getting
things done in an org? Are they better at creating crisis than
creating culture change?

Both problems are common, and I think it's helpful of Dino to point
them out. At the same time, I think we need more security people who
can get fixes prioritized without the sploit.

Adam
(Speaking for your employer, not mine. ;)

| On Tue, Jul 15, 2008 at 2:38 PM, val smith
| <***@offensivecomputing.net> wrote:
| > I'm going to have to award the point to Thomas here. The scenarios he
| > presented are very often what I get myself. Super compressed time
| > frame, unlikely to achieve goal so any time I spend developing tools
| > or exploits is time I lose achieving the goal.
| >
| > I've also recently had an app test where I had something like 6 hours.
| > There was no way (for me cause I suck) to come up with working exploit
| > in that time, but I was able to find half a dozen bugs and report
| > them. In this case knowing how to write an exploit wouldn't do me much
| > good.
| >
| > However I'll have to say i've run into maybe 1 place in the world
| > where getting access to 1 host didn't get me much. (mac locking on
| > ports, 1 time passwords everywhere, no shared admin accounts, or admin
| > from console only, lots of vlanning, etc.)
| >
| > Cheating is what its all about. I have this think I call the cooking
| > show hack. You know in a cooking show how they make the food and put
| > it in the oven then pull one out already cooked and try it. Same thing
| > but with rootshell :)
| >
| > Fuzzy kiddies just sounds wrong man, just wrong.
| >
| > V.
| >
| > On Mon, Jul 14, 2008 at 6:18 AM, Thomas Ptacek <***@matasano.com> wrote:
| >>> Anyone can fire a fuzer, find a bug and tell their client about how
| >>> exploitable it is.
| >>> People then will talk about ret-to-libc and malloc tricks that really
| >>> don't work anymore in modern systems.
| >>
| >> This is NO DOUBT true. It is obviously much HARDER to exploit modern
| >> memory corruption flaws than it is to find them. Respect, yo. S'all
| >> love in here.
| >>
| >> The problem is, it is not MORE VALUABLE to exploit memory corruption
| >> flaws than it is to find them. Consider two scenarios:
| >>
| >> (1) A shrink-wrap software pen test, for a vendor or a customer ---
| >> the target is one application. You have 5 days. Unless you think you
| >> can sweep 500,000 lines of C code clean of vulnerabilities in 40
| >> hours, an hour spent on exploit dev is an hour not spent finding
| >> vulnerabilities.
| >>
| >> (2) A network penetration test. You have 5 days. Unless you have found
| >> the zero enterprises in the world where access to their network
| >> doesn't immediately offer up 30 different mass casualty scenarios, an
| >> hour spent on exploit dev is an hour not spent breaking into systems.
| >>
| >> We could go back and forth on (2) --- no doubt there are NPT's where
| >> being able to bust CreateProcess in some sleazy Windows backup
| >> software is going to win the game for you (there are also NPTs where
| >> the client says, "tell me about the zero-day mass casualty exploits
| >> you could have run, but don't stop testing until you get in without
| >> cheating").
| >>
| >> And another thing: we all know about the "fuzz kiddies", but that
| >> doesn't make all vulnerability research a matter of aiming /dev/random
| >> at a socket and writing an advisory on the xor ebx,ebx; mov eax, [ebx]
| >> findings. Plenty of people cheat at writing exploits too.
| >> _______________________________________________
| >> Dailydave mailing list
| >> ***@lists.immunitysec.com
| >> http://lists.immunitysec.com/mailman/listinfo/dailydave
| >>
| >
| >
| >
| > --
| > ******************************************
| > * Val Smith
| > * CTO Offensive Computing, LLC
| > * http://www.offensivecomputing.net
| > *******************************************
| > _______________________________________________
| > Dailydave mailing list
| > ***@lists.immunitysec.com
| > http://lists.immunitysec.com/mailman/listinfo/dailydave
| >
| _______________________________________________
| Dailydave mailing list
| ***@lists.immunitysec.com
| http://lists.immunitysec.com/mailman/listinfo/dailydave

[Joanna Rutkowska]

Maybe the problem is in agreeing to do the pentesing/security consulting
work of an app in just 6 hours? Maybe people should realize that security
consulting is a bit different then working in a factory?

I know, I know, now I'm gonna hear all the complains of how the market
demands the above and how we all can't do anything about it. The usual
excuse, which I personally don't buy.

Ok, gonna take my afternoon nap now :)

joanna.

ps. anybody has any experience with using cscout?

val smith wrote:
| I'm going to have to award the point to Thomas here. The scenarios he
| presented are very often what I get myself. Super compressed time
| frame, unlikely to achieve goal so any time I spend developing tools
| or exploits is time I lose achieving the goal.
|
| I've also recently had an app test where I had something like 6 hours.
| There was no way (for me cause I suck) to come up with working exploit
| in that time, but I was able to find half a dozen bugs and report
| them. In this case knowing how to write an exploit wouldn't do me much
| good.
|
| However I'll have to say i've run into maybe 1 place in the world
| where getting access to 1 host didn't get me much. (mac locking on
| ports, 1 time passwords everywhere, no shared admin accounts, or admin
| from console only, lots of vlanning, etc.)
|
| Cheating is what its all about. I have this think I call the cooking
| show hack. You know in a cooking show how they make the food and put
| it in the oven then pull one out already cooked and try it. Same thing
| but with rootshell :)
|
| Fuzzy kiddies just sounds wrong man, just wrong.
|
| V.
|
| On Mon, Jul 14, 2008 at 6:18 AM, Thomas Ptacek <***@matasano.com> wrote:
|>> Anyone can fire a fuzer, find a bug and tell their client about how
|>> exploitable it is.
|>> People then will talk about ret-to-libc and malloc tricks that really
|>> don't work anymore in modern systems.
|> This is NO DOUBT true. It is obviously much HARDER to exploit modern
|> memory corruption flaws than it is to find them. Respect, yo. S'all
|> love in here.
|>
|> The problem is, it is not MORE VALUABLE to exploit memory corruption
|> flaws than it is to find them. Consider two scenarios:
|>
|> (1) A shrink-wrap software pen test, for a vendor or a customer ---
|> the target is one application. You have 5 days. Unless you think you
|> can sweep 500,000 lines of C code clean of vulnerabilities in 40
|> hours, an hour spent on exploit dev is an hour not spent finding
|> vulnerabilities.
|>
|> (2) A network penetration test. You have 5 days. Unless you have found
|> the zero enterprises in the world where access to their network
|> doesn't immediately offer up 30 different mass casualty scenarios, an
|> hour spent on exploit dev is an hour not spent breaking into systems.
|>
|> We could go back and forth on (2) --- no doubt there are NPT's where
|> being able to bust CreateProcess in some sleazy Windows backup
|> software is going to win the game for you (there are also NPTs where
|> the client says, "tell me about the zero-day mass casualty exploits
|> you could have run, but don't stop testing until you get in without
|> cheating").
|>
|> And another thing: we all know about the "fuzz kiddies", but that
|> doesn't make all vulnerability research a matter of aiming /dev/random
|> at a socket and writing an advisory on the xor ebx,ebx; mov eax, [ebx]
|> findings. Plenty of people cheat at writing exploits too.
|> _______________________________________________
|> Dailydave mailing list
|> ***@lists.immunitysec.com
|> http://lists.immunitysec.com/mailman/listinfo/dailydave
|>
|
|
|