 |
| Gray Hat Python: Python Programming for Hackers and Reverse Engineers |
FOREWORD
The phrase most often heard at Immunity is probably,
“Is it done yet?” Common parlance usually goes something
like this: “I’m starting work on the new ELF
importer for Immunity Debugger.” Slight pause. “Is it
done yet?” or “I just found a bug in Internet Explorer!”
And then, “Is the exploit done yet?” It’s this rapid pace of development, modification,
and creation that makes Python the perfect choice for your next
security project, be it building a special decompiler or an entire debugger.
I find it dizzying sometimes to walk into Ace Hardware here in South
Beach and walk down the hammer aisle. There are around 50 different kinds
on display, arranged in neat rows in the tiny store. Each one has some minor
but extremely important difference from the next. I’m not enough of a handyman
to know what the ideal use for each device is, but the same principle holds
when creating security tools. Especially when working on web or custom-built
apps, each assessment is going to require some kind of specialized “hammer.”
Being able to throw together something that hooks the SQL API has saved an
Immunity team on more than one occasion. But of course, this doesn’t just
xiv Foreword
apply to assessments. Once you can hook the SQL API, you can easily write a
tool to do anomaly detection against SQL queries, providing your organization
with a quick fix against a persistent attacker.
Everyone knows that it’s pretty hard to get your security researchers to
work as part of a team. Most security researchers, when faced with any sort of
problem, would like to first rebuild the library they are going to use to attack
the problem. Let’s say it’s a vulnerability in an SSL daemon of some kind. It’s
very likely that your researcher is going to want to start by building an SSL
client, from scratch, because “the SSL library I found was ugly.”
You need to avoid this at all costs. The reality is that the SSL library is
not ugly—it just wasn’t written in that particular researcher’s particular style.
Being able to dive into a big block of code, find a problem, and fix it is the
key to having a working SSL library in time for you to write an exploit while
it still has some meaning. And being able to have your security researchers
work as a team is the key to making the kinds of progress you require. One
Python-enabled security researcher is a powerful thing, much as one Rubyenabled
one is. The difference is the ability of the Pythonistas to work
together, use old source code without rewriting it, and otherwise operate
as a functioning superorganism. That ant colony in your kitchen has about
the same mass as an octopus, but it’s much more annoying to try to kill!
And here, of course, is where this book helps you. You probably already
have tools to do some of what you want to do. You say, “I’ve got Visual Studio.
It has a debugger. I don’t need to write my own specialized debugger.” Or,
“Doesn’t WinDbg have a plug-in interface?” And the answer is yes, of course
WinDbg has a plug-in interface, and you can use that API to slowly put
together something useful. But then one day you’ll say, “Heck, this would
be a lot better if I could connect it to 5,000 other people using WinDbg and
we could correlate our results.” And if you’re using Python, it takes about
100 lines of code for both an XML-RPC client and a server, and now everyone
is synchronized and working off the same page.
Link download ↧↧
Download here
No comments:
Post a Comment