Let me stress he is not a scumbag.  At least I don’t think he is.  He might be, but I don’t know him personally.  I assume he’s a legitimate security professional—I’ve subscribed to his mailing list for years—but some of his Usenet posts from the 90s make me wonder.  Those are going to haunt you for years, Dave.

A couple of his tweets that popped up today left me scratching my head.

One of them (and this is where the real scumbag enters the page) was for an SQL injection tool called BlindCAT that pointed to a site called PenTestIT.com, which I refuse to link to.  The download link for BlindCAT went through a service called LinkBucks.com, which was bad enough, but after that it pointed to an Indian (.in) domain.

I passed on that.  Get serious.  A Windows executable from India via a linkbait site?  uh-uh.  Not gonna happen.

I went back and started poking around PenTestIT and noticed that just about all their articles bounce through LinkBucks and none of  their content is original.  The real BlindCAT author’s page appears to be here, but I can’t vouch for it.  The PentestIT site has the top search result (search: blindcat sql, no quotes), which is probably just SEO.

LinkBucks (“LinkBucks allows you to make cash from the links your users post, from the links you place on your website, or from the posts you make in a forum”) pops up a window with crappy links to articles about Paris Hilton, Justin Beiber, and Lindsay Lohan, people who I could care less about.

Tila Tequila, maybe, but Paris Hilton?  Lilo?  Jeeez.

All in all it was a very well done link trap site (WordPress).  If it weren’t for the ads, you’d think it was a legit security blog.

That, my friends, is pure scumbaggery.

The next tweet that came out of Aitel’s account was in Chinese and pointed to baidu.com, which is China’s Google.  And just now another Chinese tweet came out of his account.  Translation: “So incredible is that I can read Chinese?”

So Dave, what’s the deal?  Did someone hack your Twitter account or have you started shilling with tweets?

“That” was along the lines of this:

http://72.246.30.118/idle/Ga0mdz02wSLOaQ5Q/250
http://72.246.30.118/idle/Gx0mdz02xSLWq-NW/44
http://72.246.30.118/idle/Gx0mdz02xSLWq-NW/121
http://72.246.30.118/idle/Gx0mdz02xSLWq-NW/200
http://72.246.30.118/idle/Gx0mdz02xSLWq-NW/251
http://72.246.30.118/idle/Gx0mdz02xSLWq-NW/310
http://72.246.30.118/idle/Gx0mdz02xSLWq-NW/359
http://72.246.30.118/idle/Gx0mdz02xSLWq-NW/422
http://72.246.30.118/idle/Gx0mdz02xSLWq-NW/481

More or less.  Lots of these suckers.  I see millions of them in my proxy logs every day.

This fellow had never seen these URLs before.  Odd because his company deals with URLs every day.  I just told him to add “not host 72.246.30.118″ to his tcpdump command line and that got rid of it.

Well, the support call eventually ended.  Nothing was resolved, as usual.  But this article is not about him anyway.

That crap is Flash.  The URL never has a hostname.  It’s always an IP address and that address usually belongs to a CDN (Content Distribution Network).  The address above belongs to Akamai.  The second part of the URL is one of open/send/idle.  The third is some sort of content or user or session identifier.  The last part is obviously a sequence number.

If you frequent some sort of Internet Radio station while you’re at work and you play it all day and you leave work with your browser open to that site, you will generate tens of thousands of these URLs.  I’ve seen a single user drop a half a million of these a day.

Now, all you blackhat spooks out there listen up, because this is important.  If you don’t get it already, I’m going to spell it out.

This is a perfect covert channel.

Just faking these URLs offers excellent cover.  The “idle” URLs are all http POSTs.    You can send data out without raising red flags as long as you keep the packet size down.  A single /idle/ URL packs about 215 bytes, but the user will hit a single /idle/ URL 600-700 times, for a total of ~150K.  In the logs, looking for that kind of crap in a multi-user environment boils down to the “needle in a needlestack” problem.

You get the picture.

It gets better if you can do it over a CDN.  This is what I like to call “The Chinese Radio Station Problem”.  It’s a deep pockets hack, because you have to control the server.  The CDN serves to mask the real destination. In my small little mind I see it as something an adversarial government has the resources to do.  Hence, Chinese.

Think about it.  It’s Flash, so there are plenty of known, unknown, and, shall we say,  ”private label” vectors that can be leveraged to add a little some-some to an end-user’s PC.

What that some-some is, is up to you.  You are only limited by your imagination.

If you control the server, the user can still listen to Internet Radio while he sends you his company’s intellectual property.  Logged or not, it still looks like streaming media.

I would conjecture that most companies that block streaming media leave it open for CxOs, which is even better because they get the juiciest details on intellectual property.  You just need to know what kind of media they like.

And for employers who don’t block streaming media, there’s people like Shirley in Accounts Payable, who has all the bank passwords and likes to listen to Christian music all day long.  Double cover.  Anything with “Christian” in it is above suspicion, right?

And what about that Asian dude in Engineering, Tony Lee?  What is he listening to?

Endless opportunity.

I have taken the time to spiff things up a bit.  I have added flags that were missing for one reason or another, including Greece (how did that get missed?), Hong Kong, some tiny island near Finland I forgot the name of, and “APAC”, short for “Asia/PACific” and a peculiarity of the Maxmind geoip database.  I had been using the flag of the Earth for missing flags, but I was tired of looking at it.

Here and there a few duplicate proxies have popped up in the List.  I scour the master database every day for dupes but some have escaped into the gold database.  Fixing that will only take a few minutes when I decide to get around to it.

However, this DLL hijack hack for PuTTy also works against PoTTy.  I suppose that’s expected, since they use the same code.

So… I’d like to fix it.  The problem is, I’m not sure how to go about doing that, but I am currently looking at this MSDN article and scratching my head.

There are other motivations for hacking PoTTy as well.

My Via Bypass Redux hack will come in handy for a few months.  Long ago I considered building that functionality (adding arbitrary headers when connecting via proxy) into PoTTy, so I may be adding that in the future as well.

Still, I’m basically a lazy programmer.  But I am looking into the DLL fix now.

According to this article the widget is dropping a Koobface variant primarily on Chinese browsers.

One potentially limiting factor in this attack was that it seemed to target Chinese Web surfers. The malicious widget caused a fake message box to pop up, similar to a message prompt generated by the instant messaging client Tencent QQ. While this chat client is by far the most popular in China, it is probably unknown to most Westerners.

It doesn’t take a genius to connect the dots on that one.

All of these proxies point to the same upstream server, which identifies itself as, you guessed it, “Thunder”.  And all appear to be running the same version of Mikrotik routerOS, judging by the presence of other open ports on the IP addresses.

Yes, it’s yet another flawed device roll-out.

This fine learning establishment is planting all these boxes as a part of their distance learning program.  So, in a sense it’s a “Back to School Special”, Brazilian style!

Here‘s one of their network techs!

I don’t expect these to be around for long (next Monday at the latest), but they do work.  The fact they’re all transparent proxies and all bounce to the same downstream IP severely limits their usefulness, but there they are.

Consider the following stupidity (click for a larger view):

This is silly on a number of levels.

First, anyone remotely concerned about online security (there’s a couple of us) has JavaSHIT disabled 24×7 and the last place they’d want to enable it would be on a freakin’ proxy list site.

Second, that “eval(unescape(…” bullshit screams “HAXX!!!”

Third, this code simply unescapes to the html that would have been displayed had they not obfuscated it in the first place.  What is the point?

And since it’s JavaSHIT, it’s easy to pull off the page and de-obfuscate.

I bring this up because I have been throwing out the unproductive sites I’ve been pulling data from.  Some have disappeared, including my very last, solid gold Russian proxy site.

Those are some big shoes to fill, so to replace it I Googled “proxy list” to see who’s getting all the hits these days.  For the most part it was the usual suspects, but there were a few new names so I looked into them.

And sure enough, most of them were using JavaSHIT obfuscation.  Even some of the old standby sites have been re-written to leverage JavaSHIT.

And I was surprised to find that I could actually get some good proxies from these sites.  THAT in itself is very unusual.  Typically you go through the hassle of unobfuscating this crap and it’s seldom worth the effort.

As usual, you’re the WINNER!

• They do suck ass
• They share some aspects of last year’s Koobface spread

I did a special resurrection on every dead port 9415 proxy in the Gold Database (proxies verified at one time or another) and did some manual spot-checking.  In all, out of 5766 dead proxies I found fifteen live ones.  Most were located in China, Hong Kong, or Taiwan.  One was in Alberta, Canada.

The first one I found, in China, gave me two pages before it started resetting connections.

The Canadian proxy – apparently a Shaw Cable residential account – was fine.  It was perky and never refused a request.

However, I just now re-checked it and it’s timing out.

Several of the others simply returned the text string “error” to the browser.

Some took forever and never returned anything.

This report from Japan offers some interesting insights:

As for 9415/tcp, access from multiple sources in overseas (mainly China) observed at multiple monitoring points … has been on the rise since March.

When I look at the Big Database (all proxies scraped but not verified) I see approximately the same results just eyeballing the data, but I see the activity starting way back in August 2009.

It really takes off by the middle of May 2010.  A quick query shows that 60% of all 9415 proxies were discovered after May 15th.

In all there are over 170,000 port 9415 proxies in the database, which would make a decent botnet.

Coincidentally, Koobface “bloomed” in May of 2009.

I’ve always said this was a seasonal business.

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.

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:

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):

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:

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:

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?