Archive for December, 2005
Thomas Ptacek | December 31st, 2005 | Filed Under: Disclosure, New Findings
Window, what does this quote from the Microsoft WMF Advisory mean?
Windows Metafile (WMF) images can be embedded in other files such
as Word documents. Am I vulnerable to an attack from this
vector?
No. While we are investigating the public postings which seek to
utilize specially crafted WMF files through IE, we are looking
thoroughly at all instances of WMF handling as part of our
investigation. While we’re not aware of any attempts to embed
specially crafted WMF files in, for example Microsoft Word
documents, our advice is to accept files only from trusted source
would apply to any such attempts.
WMF is the standard image format for PowerPoint. Does PowerPoint use a
different WMF engine from IE and Outlook? One that doesn’t honor SETABORTPROC?
This seems like a pretty important detail to get right in the advisory. I
doubt the answer “no” is correct here.
For those (like me) who haven’t followed the discussion on this vulnerability
carefully, and are therefore wondering why the XP SP2 Protections didn’t
stop it: the vulnerability is that WMF has a printing escape sequence that
literally allows the file to specify code to run (ostensibly to handle printing
failures).
1 Comment
Jeremy Rauch | December 30th, 2005 | Filed Under: Matasano
New Linux friendly blackbag-0.4.1.tar.gz. Tested on Mac OS X, SuSE 9.x and FC3. Let me know how it works out on the myriad of other Linux distro’s out there…
4 Comments
Jeremy Rauch | December 28th, 2005 | Filed Under: Matasano
It seems in our haste to make tools available to the public, we left some dependencies intact that would really preclude anyone from compiling or using them. Sucks. So I wrote an INSTALL file that details building, removed some hardcoded dependencies, and hopefully made it so people can compile the tools provided without too much difficulty. Let me know if you still have problems with blackbag-0.4.tar.gz.
7 Comments
Dave G. | December 28th, 2005 | Filed Under: Defenses, Industry Punditry
There is was a time when Linux had a crappy security reputation (and with good reason). Same with Sendmail, bind, what have you. I think there is a security puberty that popular software products go through. Pimples. Wedgies. Getting picked on.
I think Microsoft is (still) going through this. I am not going to speculate too much on where it is, but its definitely heading towards adulthood. And since no one likes the popular kid (especially the wealthy one that drives a porsche to work), they will continue to have a rough time.
Things do get better as software is forced to mature. I think we are seeing that with Microsoft, and I suspect we will start seeing it with other vendors begin this awkward rite of adulthood. And to the next generation of kids, I hope you are studying!
To answer the question, it looks like any bar mitzvah. Clumsy with a dash of embarrassing. Dated even while it is happening.
4 Comments
Thomas Ptacek | December 28th, 2005 | Filed Under: Matasano
Bumped toolkit to 0.3, on wings of dezip. Dezip is like deezee,
which is now conveniently part of the toolkit. Both programs scan large
binaries looking for compressed segments. The differences:
dezip handles PKZip, which is not one of the world’s great file formats.
dezip doesn’t actually uncompress the files for you, for two reasons:
Sometimes you don’t want me uncompressing your archives, like, when
it’s a Java JAR file and you want “jar xf” to unpack it. It’s a
minimal inconvenience in the common case but saves a nightmare
in several uncommon cases.
I’m lazy.
Dezip makes a “zips” subdirectory under cwd (or dies trying) and fills it with
numbered ZIP files.
Did I mention that sometimes PKZip archives embedded in big binaries are,
in fact, Java JARs? In those cases, dezip wins you a conversion!
A handy usage note for both dezip and deezee: neither programs “recurse”,
which is to say neither will scan their unpacked output looking for further
embedded segments. But those do occur and are often worth looking for.
No Comments
Thomas Ptacek | December 28th, 2005 | Filed Under: Reversing
Because this needed a name: the phenomenon of taking part of a closed
application and turning it directly into source code.
You’ve won a Conversion when, after slogging through 10 megabytes of
assembly code, you discover that, say, the RIP routing code is
straight NetBSD routed(8). You match a version of routed from 1997 to
the IDA disassembly; then you test routed(8) instead of the binary.
Another Conversion: you found the management console embedded in a
binary as a Java JAR. Because jad does such an excellent job,
Java apps are almost Conversions by default.
It doesn’t just happen in binary rev-eng work. For example: a web app
pen-test where you find out that the tool that generates custom images
can be used to read any file on the server. 10 minutes of Python,
you’ve downloaded all the ASP files, total Conversion. In two senses
of the word: you’ve converted the app into source code, and the
pen-test into a code audit. Also you get the secret debug passwords.
It happens a lot. It’s such a happy thing that it’s silly that we
don’t have a good word for it. I’m happy to help.
3 Comments
Dave G. | December 27th, 2005 | Filed Under: Disclosure
After reflecting on 2005’s great security PR blunders, I am humbly offering the following advice to organizations that find themselves in such unfortunate circumstances.
*) Have a PR plan. The one thing you don’t want to be doing when dealing with a PR nightmare is to be strategizing while putting out the fire. You increase the likelihood that this happens. Your one goal should be: Make the story end quickly. Don’t have one and already in the thick of it? Proceed to the next bullet!
*) Hire a PR firm that specializes in Crisis Management. They exist. They have been through it before. They have probably helped people who have been in more hot water than you can imagine. Exxon’s negligence killed cute baby animals. You got depantsed by a 20 year old with a disassembler. I think they can handle it. They can also help with the first bullet.
*) React, don’t overreact. Don’t immediately get litigious on their ass. I understand your righteousness. This isn’t about right or wrong. This is about perception. Perception in this case is that the young security researcher is a whistle blower, or the reincarnation of Paul Revere. And if he is a patriot, guess what that makes you?
For example:
Don’t go to a security conference and start ripping sections out of the materials. Fahrenheit 451, anyone?
I don’t care if your stock symbol is GOOG, as soon as corporate weight is thrown around; you are evil.
*) Know the facts. Investigate internally and externally. Here is a wonderful place to bring in those legal folks that are no longer writing cease and desist letters. Make sure that you haven’t broken any laws or violated licensing agreements. Because it’s going to come out. Especially, convenient borrowing of GPL’d software. It’s easy to find and people who don’t like you are going to look. This might save you some embarrassing moments.
*) Inspire trust, not class action lawsuits. Fess up. Seriously. The story ends faster if you admit that a mistake was made. If you can’t do that (lawsuits et. al.), how about, don’t be smug. Here is an example of a poor response (from BetaNews):
Sony BMG’s Global Digital Business President Thomas Hesse downplayed the recent DRM fiasco saying he objected to terms such as malware, spyware and rootkit. “Most people, I think, don’t even know what a rootkit is, so why should they care about it?” he said.
The worst Security PR Nightmares of 2005 were:
1) Sony DRM Rootkit. Had it all. Music Industry. Rootkit with hacker like behavior. GPL’d code. A fix that made things worse. Unapologetic media company. Hurt the already suffering DRM reputation something awful.
Outcome: TBD. Lots and lots of lawsuits. By far, the worst handling of
2) Ciscogate. Has the term ‘gate’ in it. Video footage of materials getting ripped (why not burn them at that point?). One whistle-blower/researcher against two large corporations. Federal authorities involved.
Outcome: Settled after weeks of bad press. Could have done this quietly.
3) CardSystems. 40 Million credit cards/identities leaked. Amazingly, much less press than the first two. I think its because CardSystems was perceived as a victim. Cisco and Sony weren’t perceived that way.
Outcome: Visa stopped doing business with CardSystems due to this incident. CardSystems assets were liquidated, erm I mean, acquired. Being a victim doesn’t mean that everything will be ok.
No Comments
Thomas Ptacek | December 27th, 2005 | Filed Under: Reversing
I’m probably the last person to learn this, but Ilfak Guilfanov,
the dev lead on IDA Pro, has an IDA Pro Blog. It’s useful!
1 Comment
Thomas Ptacek | December 26th, 2005 | Filed Under: Uncategorized
Bumped toolkit to 0.2, with the addition of two little pcap utilities:
pstrip: Strip packets out of a pcap file; most importantly, by
default, strip non-full-snapshot packets out of a pcap file. Two
guesses why I wound up writing this. Expected usage:
> pstrip dump.pcap
21.12k packets read, 8.59k written (40.7%), or 38.3% of 1.38M total bytes
tcbs: “Don’t make me think”. Given a pcap file and no arguments,
print a numbered list of the TCP connections inside. With the
“-s #” argument, generate the pcap filter describing that
connection. Like all pcap programs, takes a tcpdump-style
filter as its remaining arguments. Expected usage:
> tcbs dump.pcap
/* 0 */ 84.158.240.240:1940 -> 199.79.133.16:80 /* 0.0% */
/* 1 */ 172.177.135.94:1983 -> 199.79.133.20:80 /* 0.0% */
/* 2 */ 155.70.39.45:53472 -> 192.148.252.238:80 /* 0.4% */
/* 3 */ 193.109.50.206:51422 -> 199.79.133.16:80 /* 0.1% */
/* 4 */ 12.160.191.209:1525 -> 199.79.133.16:80 /* 0.3% */
/* 5 */ 80.203.209.110:59128 -> 192.148.252.238:80 /* 0.0% */
... more connections ..
> tcpdump -nr dump.pcap `tcbs -s 2 dump.pcap`
... packets for connection #2 ...
Very small, very dumb, yes, could even be done in awk, yes, editcap
(I would rather eat a bug than try to build Ethereal on my PowerBook).
(PS: to Mike Lynn: TCB means “TCP Control Block”, and, as you’ve guessed, it’s
BSD-kernel-ese for “TCP Socket”; the state needed to track one connection).
9 Comments
Thomas Ptacek | December 22nd, 2005 | Filed Under: Uncategorized
A confession: despite being a Mac person for going on 5 years now, I’ve yet to
write more than 4 lines of PowerPC assembly code. No shell code, unlike
Dino —- who, for reasons passing understanding, is taking the Amtrak
train from NYC to New Mexico, and had a convenient stop-over today; in exchange
for lunch, I got 5 minutes of PowerPC help, which was pretty much all I needed.
Two great things about PowerPC assembly that I learned today:
Apple documents it, and Apple’s documentation rocks. Long story
short: return values in %r3, function arguments in %r3 and above,
test-for-zero is mov. %gpr %gpr ; bne cr1 address.
PPCExplain ships with the developer tools; from the command line,
given an instruction mnemonic, it gives the description.
PowerPC is, of course, a load-store architecture, which I think makes the
assembly code much easier to read than X86; memory access always involves an
“l…” instruction or an “s…” instruction. IDA feature request that won’t get
read because I’m too lazy to write it up and send it: have a mode that
highlights instructions in the same class as the one I’m over now, rather
than just literally the same instruction. Highlight all branches, or all
stores, or whatever.
Finally, a stocking stuffer for our network programmer audience: I got tired
of translating C header files into TCP/IP field offsets; I almost wrote a
“offsetexplain” function, but came up with something simpler:
Matasano’s Periodic Table Of The Offsets, from the base of the
Ethernet header, IP header, or UDP/TCP header.
5 Comments
