Archive for October, 2006
Dave G. | October 31st, 2006 | Filed Under: Industry Punditry
Got an email the other day about the release of another web application debug proxy (ala SpikeProxy/WebProxy/WebScarab). This one is called Pantera. It’s 100% python (last weeks Ruby, or so I hear), and built on top of SpikeProxy.
Pros
A modern looking UI. This is the most noticable thing about using Pantera, as compared to all of the other debug proxies. It is reasonably intuitive for this type of tool. Also, it’s brand new, so I suspect it will improve over time.
Session Support. Another feature that is indispensible for web app pen testing. You can create a session to store all of the results of an assessment. Also, storing everything to a database will make it easy to building a better reporting system than other tools out there.
Passive Analysis. While the analysis isn’t all that sophisticated yet, it is a nifty idea. You can flag pages or request that meet certain parameters. For example, flag pages that allow file uploads, have hidden parameters, or if cookies have the secure flag set.
Not written in Java. People are more likely to extend it.
Two Heavy Metal Bands in One Product Name. W.A.S.P. and Pantera.
Cons
Installing it is a little bit of a pain, as it requires some python dependencies, and MySQL 5.x using the old style authentication. This would be less painful if #2 also wasn’t a problem.
Documentation still needs a lot of work. Unless the installation goes flawlessly the first time, you are likely to have a hard time figuring out why things aren’t working. The error output isn’t very useful.
No fuzzing yet. I don’t know why this always ends up late on the laundry list of things to be implemented for a debug proxy. It is one of the few things that really makes life easier. It’s generally weak on features right now.
If they can keep momentum going, this will be an invaluable tool for people doing web app assessment work.
12 Comments
Dave G. | October 30th, 2006 | Filed Under: Industry Punditry
So while googling for some current events stories, one of the top hits directed me to a website called soloops.com. A seemingly innocent website supposedly dedicated to “Advice, resources and support forums for military wives.”. Either military wives are attacking random internet users, or random internet users are attacking military wives.
Alas, it appears that someone is abusing their forums to direct people to “fdghewrtewrtyrew.biz” and “zdgbrowfaa.biz”, which proceed to attack the browsers of military wives and other casual websurfers with .biziness end of a number of (old) browser attacks (I counted 4 before I got bored).
That is when I googled for soloops.com. On the first results page, I see a SiteAdvisor link and think to myself, “Aha! There we go. I’m just a moron.”. Here is what the site has to say:
Notice the “We tested this site and didn’t find any significant problems.” and then further below the “We have not tested any downloads on this site.”. What tests do they actually perform? If it involved a web browser, and was performed regularly, they might have noticed xpl.wmf being downloaded.
Thanks SiteAdvisor!
ps: The Cardinals won the world series in St. Louis,a city that just won the prestigious award of “Most Dangerous US City To Live In”. In related news, “Web 2.0” is built on top of the web browser/web server security architectures.
3 Comments
Thomas Ptacek | October 28th, 2006 | Filed Under: Uncategorized
More here. Seems appropriate for today’s IDS debate, too.
6 Comments
Thomas Ptacek | October 28th, 2006 | Filed Under: Industry Punditry, Uncategorized
Richard Bejtlich pulls another DailyDave thread into his blog,
irritated by the security community’s dismissal of intrusion
detection. Couple things.
We Get To Talk About IDS, Richard
Richard Bejtlich does not get to dismiss Dave Aitel and Halvar
Flake as “offensive computing” experts who don’t understand
IDS, and, personally, if he calls me an “offensive computing”
person again I’m going to ask for an apology. Richard, these
people are your peers, and you read DailyDave for the same
reason I do: it’s an excellent list.
It’s Not About Signatures
The IDS/IPS problem, which is now a decade old, is that lots
of smart people in operations, research, and development are
skeptical that it works at all. You cannot bait your way out
of this problem by saying “that’s just signature IDS”. Sorry,
Richard, I know how Bro works and I’m pretty familiar with
anomaly detection. These ideas have, if anything, amplified
the fundamental signal/noise problem “attack detection”
creates.
Does Anyone Actually Rely on IPS?
On DailyDave, I asked the same simple question I always ask about
IPS:
“I am waiting for someone to tell me the story about how
an IDS saved their bacon. I’m not interested in the story
about how it found the guy with the spyware infection or the
bot installation; secops teams find those things all the time
in their firewall logs and they don’t freak out about it when
they do.”
Richard says, “it saved my bacon all the time at Ball
Aerospace”. Alright, Richard, now tell us a story. And if the
story ends in “so I scrubbed the infection off the desktop and
nobody ever had to think about it again”, please find another
story.
What Are These “Great Ideas” In IDS People Talk About?
I made a somewhat inflammatory point:
“Intrusion detection has been an active field of research for
over 15 years now and apart from Tripwire I can’t point to
anything operationally valuable it has produced.”
This should be an easy one to knock down. But all
you say is, “this sounds like the ‘Snort is worthless’
argument”. You’re a smart guy who thinks about this stuff
all the time, Richard. Can you actually address the argument
I really made? I know a whole bunch of my readers can (and
probably will, with expletives).
Firewalls and IDS Are Not Comparable
IDS is not “pigeonholed the same way firewalls are”. There’s
a difference: firewalls are hugely successful, perhaps the
single most important piece of security technology enterprises
buy. It is absolutely unimaginable for a large company to be
connected to the Internet without them. You cannot say the
same thing about IDS/IPS; lots of enterprises don’t use it,
and they aren’t suffering.
ps: the stuff about tape drive speed? that was a joke. about tape drives.
10/28: NB: We have lots of very talented friends who are real believers in monitoring and even IDS; some of them are talking here, some of them on DailyDave, and doubtless some are just reading and shaking their heads. I don’t think any less of any of these people, including Richard, because they buy the IPS story and I don’t. But I have an opinion and intend to be ruthless about transmitting it.
22 Comments
Dave G. | October 27th, 2006 | Filed Under: Apple
Tom’s recent post on filesystem fuzzing. Mentions Apple filesystems being downloaded and mountable. I wanted to spend a little more time talking about DMGs. DMGs are Apple’s version of a filesystem contained in a file. They are useful for a number of things, but OS X users probably see them most often as a way of downloading and installing software. What is interesting about DMGs is that they allow non-privileged users to mount a filesystem. This poses a number of unique threats to OS X.
The first one is getting a lot of discussion right now. DMGs opens up an attack vector into the kernel that is far less common in other operating systems. Eventually, when a user mounts a DMG (typically done by just double clicking on it), the kernel will be involved in interacting with the filesystem. Since this filesystem can be created by an attacker and delivered remotely (via a web browser download) or created by a local non-privileged user, attackers have the ability to find kernel based vulnerabilities through filesystem code paths inside of the kernel. While I am oversimplifying this a little, the end result is that it may be possible for an attacker to remotely exploit a kernel buffer overflow in the filesystem code (should it exist). DMGs support the following filesystem types: HFS+, HFS+J, HFSX, HFS, MS-DOS, or UFS. Thats a pretty large attack surface.
A second issue that arrises from user control of the mounting of user defined filesystems (just typing that made me twitch) is that the security model of filesystems can be drastically different. For example, while HFS+ has something called ‘file permissions’, MS-DOS does not. And even if that werent the case, all of the files written to a DMG mounted filesystem ultimately end up inside of a file that an attacker will be able to read from. This opens up some unique exploitation techniques for Mac OS X local file vulnerabilities. I actually talked about this in 2003. Essentiallly, anytime you can coax a file containing sensitive information to be written to your filesystem, it is yours, regardless of file permissions/ownership. While there have always been techniques to do this (e.g. FIFOs), this makes it even easier.
6 Comments
Thomas Ptacek | October 27th, 2006 | Filed Under: Development, Uncategorized
A comment from last night:
I have no freakin’ idea what you are talking about […] Can you
write a post explaining NTFS fuzzing in little better […]? What do
you mean by a malicious NTFS image?
Sure, I’ll take a shot. Thanks for asking. Skip to whatever part
answers questions for you.
1.
Fuzzing is slang for fault injection via random inputs. The goal is to
find bugs in software without reading code or designing detailed test
cases. You can fuzz test anything that takes an input, including:
File formats, by generating random (or randomly corrupted)
files; for instance, attacking a browser by feeding it corrupt
image files.
Protocols, by generating randomly corrupted messages; for
instance, attacking a web server by feeding it corrupt TLS
records.
API’s, by generating random (or randomly corrupted) function
call arguments; for instance, attacking the OS X kernel by
generating random system calls.
2.
Filesystem fuzzers fuzz filesystems. Particularly on Unix systems,
filesystems are themselves just big interesting files; you can get to
a “live” filesystem by reading and writing “/dev/rdisk*”, and you
can create and modify test filesystems by loopback-mounting files and
disk images.
An NTFS filesystem fuzzer is going to semi-randomly corrupt the
filesystem metadata (the file tables, attributes, indices, etc) of an
NTFS image. The goal is that when the image is loaded into a target
system (say, because it resides on a USB thumb drive you just plugged
in to the target), the kernel of the target system is going to read
the corrupt filesystem, trigger a bug, and fail.
Filesystems are an interesting target for a couple reasons:
They’re complicated. Filesystems aren’t the easiest pieces of
system code to write. Complicated code is buggy code and buggy
code is insecure code.
They’re in the kernel. Ring zero exploits are terribly powerful;
for example, if you can access privileged instructions on AMD
and modern Intel, you can virtualize the running operating
system under a hypervisor (think VMWare) and control the
entire universe as the kernel sees it. (There are even worse
things you can do than that with a ring zero exploit on some
platforms with flash-programmable firmware).
They’re not well-tested, in part because of reasons 1 and 2
(making them a bit intimidating) and partly because people
don’t see them as a viable attack vector, bringing us to:
They’re a deceptively viable attack vector on modern
computers. You don’t need access to the PCI bus or root
privs to force an OS to read a corrupted filesystem:
Your OS will read a variety of filesystems off any
USB drive you plug in
SAN storage feeds blocks, not files, over the network,
meaning the filesystem metadata is in transit over
the network and exposed to attack
Macs will read filesystems out of images downloaded
off the Internet. This was not a great design decision.
3.
Consider a hypothetical NTFS vulnerability. Say, if the NTFS file
record at the offset where the MFT lives has a “File Name” record that
starts with “$MFT” but continues on with at least 2048 bytes, it
overflows a kernel pool allocated buffer and corrupts the
allocator. This is not a real vulnerability.
(The MFT is the Master File Table; think of it as the “root file
record” in NTFS, which isn’t accurate but close enough).
In this parallel universe in which filesystems are vulnerable to
attacks, and particularly the one I just mentioned, a “malicious NTFS
image” is one with a pathological $MFT that corrupts the kernel
allocator so that the next free() call the kernel does overwrites the
stack and transfers code into kernel shellcode also resident in the
NTFS image.
That’s what we’re looking for with a filesystem fuzzer.
4.
Again, the advantage of fuzzing is that you don’t have to think too
much to create pathological test cases that find real bugs. Because of
this, fuzzing tools exist on a spectrum of “format-awareness”. The
more “format-aware” your tools are, the more well-formed your test
messages are going to be, which has advantages and disadvantages:
On the plus side, “better-formed” messages can do deeper
testing. If the code you’re testing validates message length
fields, or checksums, blindly splattering random bytes over
messages will cause messages that could have scored a hit
to be rejected.
On the minus side, the big advantage of fuzzing is that by
letting the computer do the work instead of your brain, you
score hits you wouldn’t have thought of swinging for.
The spectrum looks like this:
At the simplest end, you have tools like “mangle.c”, which
“fsfuzzer” uses; “mangle” doesn’t know anything about the
file formats it’s attacking (except that high-ASCII bytes
are “more important”) —- it just sprays random bytes.
In the middle of the spectrum you have framework tools like
“spike”, which aren’t aware of any specific protocols or
file formats, but provide functions for generating well-formed
messages. The big problem most of these things solve is
getting length fields right, so you can stuff 10 megs of crap
into a message that is supposed to be 40 bytes long and not
have to manually compute a 32 bit little endian word-counted
length field.
At the sophisticated end of the spectrum you have things like
PROTOS, which are fully aware of the protocols they target and
measure themselves by how many individual, protocol-specific
test cases they have.
5.
The way I’m using the word “fuzzing”, which is incorrect, is “any
security testing you do by generating pathological inputs conducted
without understanding the code in the target”. I think my dirty secret
is, I don’t “fuzz” anything; I just try to understand 10% of a
protocol, API, or file format and then generate lots of thoughtless
test cases.
If you just want to find crashers in your OS, download fsfuzzer and
mount up filesystems it creates for you. You won’t need to think, and
you will probably find bugs. Fsfuzzer is the simplest thing that can
possibly works, and that’s clever, and I salute it.
1 Comment
Thomas Ptacek | October 26th, 2006 | Filed Under: Development, Uncategorized
Here’s a trivial (kinda broken) shell pipeline that turns “sub” into a struct
generator, a la SPIKE or CASL (but simpler):
sed 's/(.*\:.*)/\$\{\1\}/g | sed 's/^ +//g' | tr '\n' '&' | sed 's/&//g'
Yes, using “sed” is technically cheating.
Now instead of ${n8:0x45}${n8:0}${len16}, etc, you can just do:
n8: 0x45
n8: 0
len16: -n 4 <<EOP
n16: 0
n16: 0
n8: 255
str: rest of the packet
EOP
Preprocess that with “sed”, pass it through “sub”, and it’ll generate
the binary representation (n16, “network byte order, 16 bits”, len16,
“everything up to EOP, with length prepended in NBO 16 bits, with the
length counter incremented by 4).
A problem I don’t have a good answer to, else I’d just give you a full
IP/TCP packet: how to do the checksums, particularly the TCP checksum,
in a shell pipeline.
Meanwhile, as silly as this stuff looks, I promise it’s faster to whip out than C or Ruby.
3 Comments
Thomas Ptacek | October 26th, 2006 | Filed Under: Development, Uncategorized
For what it’s worth, here’s what I started doing with NTFS this week
(before NTFS went out-of-scope on my project). I’m attacking a Win32
tool, and my toolchain is all Unix, so I use a thumb drive to run
experiments:
Format the drive NTFS on Windows.
Stick it in my Mac
‘dd’ off the filesystem image (to “ntfs.raw”).
Find the $MFT offset and extract the $MFT. Now I have
something like this: 
Start working out fields in the hex editor (I’m still
using HexFiend) and replace them with “sub” macros: 
Run the resulting file through sub and ‘dd’ it back
into place on the thumb drive.
Rinse, repeat until something breaks.
Yeah, this is slow compared to “fsfuzzer”; is what I’m doing
technically “fuzzing”? On the one hand, I’m format-aware; on the other
hand, I have no idea whether the code I’m attacking is
vulnerable. Mostly though I just want a template to make it easy to
generate malicious NTFS images; I think mission accomplished.
I’m building up a bunch of little macros for NTFS; for instance,
${dosf:HSA} sets hidden, system, and archive for the file; ${frsz}
reads until “EOF” and writes a properly length-delimited file
record. My “macro” facility is still really ugly, but it works well in
practice. Acid test: did I need a line of new C code to start messing with
NTFS? Nope. Though, I guess neither did LMH.
1 Comment
Thomas Ptacek | October 26th, 2006 | Filed Under: Development, Disclosure, Uncategorized
From DailyDave this week, a discussion about “fsfuzz”, a filesystem
fuzzer ostensibly for Linux, supporting most of the major
filesystems. I was working on an NTFS fuzzer this week. You care about
filesystem fuzzing:
So someone did the work for me. Nice! Let’s check it out.
Hmm. Um. It’s a shell script around mkfs and a C program. The C program
doesn’t look big enough to know how to encode NTFS attributes. There
must be a pony in here somewhere. No; now I’m confused. All this thing
does is spray random bytes over arbitrary files. This works?!
Apparently so. From the comment, it broke:
- libmagic
- OS X Preview.app
- xpdf (hang)
- Mach-O loading (“osX 10.3.7, seems to be fixed later”)
- QNX’s ELF loader (“panics almost instantly, yikes!”)
- FreeBSD’s ELF loader
- OpenOffice
- amp
- OS X DMG loader
- binutils libbfd (so, objdump, nm, and gdb)
- libtiff (used tiff2pdf)
- xine (division by 0, took 20 minutes of fuzzing)
- OpenBSD’s ELF loader
- Unixware’s ELF loader
- DragonFlyBSD’s ELF loader
- Solaris 10’s ELF loader
- cistron-radiusd
- linux ext2fs (2.4.29) (“division by 0”)
- linux reiserfs (2.4.29) (“instant panic!!!”)
- linux jfs (2.4.29) (“long (uninteruptable) loop, 2 oopses”)
- linux xfs (2.4.29) (“instant panic”)
- Win32 Flash .SWF
- Quicktime 7.0.1
- totem
- gnumeric
- VLC
- MPlayer
- Python’s bytecode interpreter [!]
- RealPlayer Gold 10.0.6.776
- dvips
So, uh, excuse my language but how fucked up is _this_?
Don’t get me wrong; I’m not criticizing LMH (who wrote fsfuzzer) or
Ilja van Sprundel (who wrote mangle, the small C program —- though I
am giggling that he opens “urandom” just to generate random fuzzer
bytes). The fact that I wasted an afternoon making my tools grok the
NTFS MFT means the joke here is very definitely on me. (And yes, the
irony of mocking someone for writing shell script instead of C, not
lost on me).
No, the problem here is that in 2006 you can apparently rip a large,
ugly gash through the whole industry with nothing more than a blind
random number generator.
There needs to be a word for this. Our field needs a lot of new words,
but we need to start here. What do you call a piece of code that falls
to “mangle.c”? Dave says it should be German, proposes
“poopensoft”. Dave, that’s not German. “Scheissekraft” captures the
spirit, and I feel harsh, but let’s be politic and call it
“gruenewerk”. Green. Not ready. Vendors, developers, can you please
run the random number generator on your code _before_ you ship?
LMH is going to try to run the “Month of Kernel Bugs” (ala
HDM’s MOBB —- GPG key evidently forthcoming). Unfortunately, I think
it’s going to be a success for him. Nicely done, LMH. But I feel a bit
sick.
14 Comments
Thomas Ptacek | October 26th, 2006 | Filed Under: Uncategorized
Are you in Chicago? Got nothing hugely important going on later in the afternoon? Great! Get over to Loyola’s downtown campus and see me and Cory talk about vulnerability research. We’re giving the “State of the Union” talk, in one hour, playing tag with (we think) the big issues of the day: ethics, markets, reversing, web security, and the real-world impact of vulnerability research.
We welcome hecklers!
The talk is open to the public. It starts at 3:15PM, at the Rubloff Auditorium (room 110) at 25 E. Pearson.
1 Comment
