Hinky’s Proxy Obsession

The other day I was on a support call with a techie from a vendor that will remain nameless (go ahead… guess!).  We were watching some HTTP packets fly by with tcpdump when he suddenly said, “WTF is that?”

“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.

When I released PoTTy into the wild, I noted that I didn’t plan on supporting or improving 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.

If you’ve been poking around the Brazilian proxies that have showed up in the past couple of days, you’re probably familiar with the Via header above.

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.

Recently, a sharp-eyed reader noted that proxies on TCP port 9415 suck ass, and suggested they might be Koobface proxies.  So this morning I did a little reality check and found:

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

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?