Genuine port 0 activity

Usually, when someone posts a message about "port 0" traffic or alerts, it is little more than an artifact of some monitoring devices inability to correctly report fragments. Not this time, and I'm still scratching my head over it.


I run several different loggers, parsers, etc. on my networks, and since I love to give the bad guys every opportunity to feel good about themselves, I throw a few honeypots in there for good measure. Better chances to succeed and give me better insight into their intentions, and all that. One of the tricks I use is to redirect everything, all unused ports, all unused addresses, etc., into a set of Perl scripts that I call Tiny Honeypot (thp). As lame as it is, the results are sometimes rather surprising. Take this one, for example:

0000000: e34c 0000 0001 105e 47e3 01cf 0e98 0d1d  ãL.....^Gã.Ï....

0000010: ac6f 0055 b36f 0bd5 ba2f 5436 1204 0000  .o.U.o.Õº/T6....

0000020: 0002 0100 0107 0065 5365 7276 6572 0301  .......eServer..

0000030: 0011 3c00 0000 0301 00fb 00ef 0600 0201  ..<......û.ï....

0000040: 0055 0700 6573 6572 7665 7200 0000 0000  .U..eserver.....

0000050: 00                                       .

That was the payload delivered, not once, but 24 times (with slight variation) in a one hour period from seven different hosts, scattered across the globe. What's really interesting is that they were all looking for a "service" listening on port 0. Either that or they're looking for me and my silly Perl scripts. Of course I don't have a listener on port 0, but thp uses the netfilter "REDIRECT" target to DNAT everything, including traffic to absurd ports, to the location of the thp responders.



Why port 0? A couple of possibilities:


1. Broken tool - all too often I've beat my head against the wall trying to figger out why I see wierd traffic and it turns out to be a "misfire"


2. Probe - Looking for hosts, routers, firewalls, etc. The prober doesn't care about a tcp service's response, often it is the ICMP (or other) messages that are most valuable.


3. Looking for a broken service - Maybe, just maybe, there is a legitimate service, with an undisclodes vuln, that accidentally listens on port 0 as well as its intended port. I'm leaning towards this, because of the payload that was delivered AFTER a successful three-way-handshake. Hmmmmm.



I'm going to hold off for a bit on posting the source addresses, until I can get a response from their admins. Although it happened a few days ago, I haven't been able to locate any other similar activity on any of the networks I monitor.


While a few attack tools will use "0" as the src port, by default, this was directed to destination port 0. Do me a favor, If anyone has seen legitimate tcp dest port 0 activity, could you please send us as much detail as possible? I saw it in the wee hours of June 1.

Osama is still at large, and delivering malware to a PC near you

As I'm certain many of you have seen or read by now, attackers actually prey on users's curiosity and gullibility. No, really, they do! The recent "Osama Bin Laden has been captured" emails direct the recipients to....you guessed it, open a zip file containing a downloader. This beastie then pulls down what Norton calls "Backdoor.Nibu.D", a keylogger/bank info scarfer/clipboard sniffer/all-around bad guy.

Update A/V, don't open email attachments you aren't expecting, don't believe everything you read, get plenty of sleep, floss. If you absolutely, positively must see what this thing looks like, .

RBOT varients getting even MORE talented

Thanks to Robert Tabin for alerting us to new RBOT propagation methods - now they incorporate a MSSQL buffer overflow (MS02-061) exploit in the growing cocktail. See http://www.trendmicro.com/vinfo/virusencyclo/default5.asp?VName=WORM%5FRBOT%2EBJF and http://www.trendmicro.com/vinfo/virusencyclo/default5.asp?VName=WORM%5FRBOT%2EBJI



On a similar note, we've had one report of what looks to be like another RBOT vector, this time SMB over HTTP. An IIS server will accept multiple forms of authentication, including (non-IIS folks cover your eyes, this will hurt) NTLM via base64 encoding. You looked....I warned you! Look for:

GET / HTTP/1.0

Host: xxx.xxx.xxx.xxx

Authorization: Negotiate

YIIQegYGKwYBBQUCoIIQbjCCEGqhghBmI4IQYgOCBAEAQUFBQUFBQUFBQUFBQUFBQ.....

All that gibberish can be decoded with good ol' "mimencode -u" to reveal an RBOT tftp download command. The long and short of it is POLP - Principle of Least Privilege. Disable any authentication methods that are unnecessary, especially on your big-bad-world-facing servers. Me, I don't trust anyone to play nicely, inside or out.




Cheers!


g