night. This can possibly be a very bad thing but not in the way that
the mainstream media is twitching about it. While a worm is possible,
I don't think it's likely to be all that effective.
it. The vectors aren't really right. Normally a worm exploits an
already running service. This exploit is part of a graphics
library which means a graphics-based program must run. Unless it's
combined with (or used to amplify) another exploit, we're not going to
see another Nimda.
What's more likely to happen is that this (version,
at least) will deepen the relationship between the hackers and the
spammers (if there's a difference nowadays). The spammers can deliver
corrupt graphics via browser pop-ups and spam which can cause the victim
machines to offer up reverse shells on just about any port.
for the theoretical part. What was demo'd last night was the reverse
shell version. It wouldn't work under IE (patched possibly?) but it did
work locally via the file browser. What's worse was the XP
automatically generated a preview of the JPG so that as soon as you
opened the folder, the local machine provided a shell prompt to the
instructor's machine, running netcat.
But wait! There's more!
Remember that you can configure XP to open the folder when a thumb drive
is inserted? Yep, it does. And let's not forget autorun! This makes
it a very nasty insider tool.
To give proper credit, very little of
the above my own thought train. Most of it belongs to Rob and Ian. The
rest was observed and conjectured during the demo.
countermeasures, it's probably going to be more economical to configure
IDS systems to detect the exploit rather than the exploitation, due to
the lack of default port, IP or even graphic. Since remote delivery
vehicles will probably be limited to SMTP, HTTP, and the various
graphics-capable IM programs, it will probably be easier to watch for
the shell code coming in than the reverse shell going out. That and not
all of the exploits involve reverse shells. Hopefully we'll shortly see
both types of BleedingEdge signatures.
Let add my own two cents to the
SANS vs. MS detector argument. Yes, the SANS detector triggers on a lot
more files than the MS version does but you should read the text that
comes with the SANS detector. The MS one is built for MS purposes. The
additional DLL's detected can be either additional ones that link to
non-MS programs that you've installed or they can be backups of upgraded
libraries. It's worthwhile to check what programs access those
libraries (Foundstone has some of the tools needed for this) and, if
possible, upgrade or disable the programs.
Oh, and one last thing:
"Good luck! You're on your own!"
Post a Comment