Archive for July, 2010

11
Jul

419 SPAM From a Texas Hospital

By hinkydink 3 Comments
Categories: Uncategorized

I have a lot of security delicacies “on my plate” but SPAM isn’t one of them.  Back at the salt mines, that’s someone else’s problem.  Suffice to say I’ve ignored the subject for years, considering it’s fairly well handled by all the Web mail accounts I have floating around (Yahoo, Hotmail, Gmail, et cetera).

I never even look at the stuff.

However, there is this woman – let’s call her “Helen Dink” – who is no relation to me but by some strange quirk of fate we share the same ISP.  She believes her e-mail address is hdink@myisp.com, but it’s not.  That’s my email address.  I’ve had that address for almost ten years now, but whenever she goes to fill out Web forms online she plugs in my email address!

So I get a lot of her email.

This has been going on for at least five years.  I know more about this woman than I want to (yes, she’s a Facebook user).  Her friends constantly send me email about a variety of crap, from Girl Scout meeting notices to recipes and the like.  It’s incredibly annoying and for the past few years I’ve been writing them back and letting them know, in no uncertain terms that I am not “Helen Dink” and to please remove my email address from their “Contacts” folder.

So today I got an email from “Andrea Wilson”, a normal-sounding American name.  Thinking it’s one of Helen’s buddies I open it up in order to send my standard reply to these things.

But it’s not.  It’s a 419 scam email…

I am Golan Bradley a staff of Natwest Bank ,I am pleased to pass across to you a very urgent and profitable business proposal which I believe will profit the both of us after completion.I will await to receive a positive response from you to enable me give more details Please send your confidential telephone and fax number in your reply to: golan.bradley@removed.com Golan Bradley(Mr.)

The security wonk inside me kicks in and I decide to look at the SMTP headers, thinking I’d be able to track it back to Nigeria or Cameroon (hi, fellas!).

But the headers were extremely legit.  The email went through 2 Exchange servers, a Symantec Brightmail Gateway (an anti-SPAM device), and a ZIX encryption device before ending up at my ISP.

“Andrea Wilson” turns out to be a Real Person™  who works at a hospital in Texas.  And, not surprisingly, she’s an active Facebook user.  Obviously her workstation or laptop or whatever had been summarily pwn3d and was being used to deliver 419 SPAM for person or persons unknown.

Well, that’s her problem.

I briefly toyed with the idea of writing her back and suggesting she have the IT department check out her box, but that’s a notoriously bad idea and generally frowned upon (this comes from the heyday of email viruses, when sending a “HEY ASSHOLE YOUR COMPUTER HAS A VIRUS” email only served to exacerbate the problem).

Maybe I’ve been away from SPAM for too long, but it seems unusual to see legitimate SMTP headers from an obviously corporate environment, considering that lately the vast majority of SPAM comes from Yahoo, Gmail, Hotmail, et cetera.

Everything old is new again.

01
Jul

Fucking Snort… 64bit Edition

By hinkydink 0 Comments
Categories: Uncategorized

I built 64bit snort (x86-64) on my old friend, Debian 4 (“etch”) and had lots of fun doing it.

It wasn’t quite as hard as I thought it would be, but there were a number of stumbling blocks, so I thought I’d post them here if anyone runs across the same issues.

First, our old pal Libnet1.02a is so fucking ancient it predates the AMD64 processor.  The Makefile simply barfs with an “unknown platform” error.  This was easy enough to fix.  First, locate line #172, which should be a comment starting with  ”Recognize the basic CPU types” (duh).  Right under that line should be a line starting with “vax-*”.  Edit that line to include “| x86_64-* |”.  No quotes, as usual.  Run configure, make, make install and that issue is over and done with.

Libdnet was the next big issue, and it was a problem on my 32bit Deb4 system as well.  Normally I hack shit together in /usr/local/src and libs fall into /usr/local/lib.  Unfortunately, libdnet doesn’t like living there and you can run ldconfig all day long and snort will still bitch about not being able to find it.

So start with “./configure –prefix=/usr” and that problem goes away.

I had to build a few things from scratch because Georgia Tech (gtlib.gatech.edu), my favorite apt repository (they seem to be the fastest around),  apparently stopped mirroring 64bit Deb4 and I was too lazy to look for a working repository.  You shouldn’t have this problem.  I had to build libpcap, flex, and bison from source but there were zero issues with any of those.

It took a while to come up with a decent config for snort but what I finally used was this:

./configure –prefix=/usr \
–sysconfdir=/ \
–localstatedir=/ \
–enable-react –enable-flexresp2 \
–enable-build-dynamic-examples –with-zlib \
–with-libnet-includes=/usr/include \
–with-libnet-libraries=/usr/lib \
–enable-decoder-preprocessor-rules \
–enable-targetbased –enable-64bit-gcc

Some of that may be unnecessary.  The dynamic examples are buggy and you’ll end up deleting them anyway (you’ll figure it out – trust me).

Once building snort64 was out of the way, I downloaded the rule set and tried out the different pre-compiled “so” (Shared Object) rules.

None of them worked.

That is of course my problem for using an ancient (2006) version of 64bit Debian.  There are a limited number of pre-compiled preprocessors for x86_64 and none are compatible with Deb4 (they all want ‘GLIBC_2.4′, which Debian 4.0 doesn’t have).

This is not going to be a problem for you folks on the cutting edge of Linux.  If I was running Lenny (I hate Lenny with a passion) I’m sure I could have used one of the 64bit pre-compiled preprocessors for Ubuntu.

But I’m not, so I had to roll my own.  And that’s when it got ugly.

Due to “contractual obligations” (NDAs no doubt), snort/SourceFire is only allowed to distribute certain rules in binary format.  They include the source for the non-NDA rules, but how to actually compile them is a trip into Undocumented Territory (“here be monsters”).

Sure, there’s a README file but all it does is explain their legal obligations and reassure you that one of the the pre-compiled preprocessors should work.  That’s it.  That’s all it says.

Thanks, Marty.

But there is a Makefile, so you’re halfway there.  I had to do the following to build the so preprocessors.

First, copy all the files in the src folder (that came with your VRT rules) into the folder where your snort source lives.  I called the folder “so_rules”.  Then fix the locations in the Makefile, like so (assuming you installed the snort source in /usr/src):

BASEDIR=/usr/local/src/snort-2.8.6
ENGINEDIR=$(BASEDIR)/src/dynamic-plugins/sf_engine
PLUGINDIR=$(BASEDIR)/src/dynamic-plugins
ENGINE=$(BASEDIR)/src/dynamic-plugins/sf_engine/.libs/libsf_engine.so
SNORT=$(BASEDIR)/src/snort

Note the variable $SNORT assumes snort is already built and living in your source folder.

Then, comment out the line that begins with “PATH” because I absolutely guarantee you don’t have an Intel compiler.

Now, find the line that start with “libs :=” and remove the following:

pop3
web-activex
web-iis
icmp
sql

These must be the NDA-disqualified shared objects because there is no source to build them from.

Next, just for fun, find and comment out this line:

MYCFLAGS+= -DMISSING_DELETED=1

Why?  Check out the “deleted.rules” file that came with your VRT rules.  There is a lot of old crap you may never see again, but you never know.

Save the Makefile and type “make” inside the so_rules folder (not the toplevel make).  If all goes well, move the *.so files you just built to a folder under /etc/snort (I used “so_64″) and edit your snort.conf file to point to them (the very last line in the “Step 4″ part of snort.conf).

Finally, test your new config out and see what happens. You should see “166 preprocessor rules” intead of “0 preprocessor rules” now and 13 new “Rules Object” entires (I’m using the May 2010 VRT set, so YMMV).

Again, you shouldn’t have to go through this crap if you have a relatively modern 64bit distro of Linux (newer than 2006 I’d say) since the distributed shared objects should run just fine.

What do Windows users do about the lack of shared object rules?  Suffer, I guess, since there are no pre-compiled binaries, 32 or 64bit.

Hopefully, SourceFire will fix that soon.

Are you listening, Marty?