 Link LoggerPremium,MVM
join:2001-03-29
Calgary, AB
kudos:3
 ·Shaw
| Port 137 Scans or 'Intro to Basic Forensics' Blake's quickie lesson to NetBIOS port 137 traffic, or more specifically what the heck is all this UDP port 137 traffic I'm seeing, or more formally, 'A Brief Introduction to Basic Network Forensics'.
Currently the most common worm on the Internet is Opaserv or BugBear which both scan the Internet for systems with open shares to infect (you wouldn't believe how many systems out there have WIDE OPEN C: drives). The method they use to find exploitable systems is to do a NBTSTAT -A type scan to locate systems with open shares and then they try to execute the infection via a connection to the file share (port 139, note there are a couple of vuls which can be used to enhance this infection process). The initial recon scan goes to your UDP port 137, but there is other traffic that goes to this port as well which isn't a worm (but block it all anyways). How do you tell a BAD port 137 probe from an EVIL port 137 probe? The easiest way is to look at the source port. Since NetBIOS is 'root' function within Windows it uses a port in the 0-1023 range, or more specifically UDP port 137 in this case. Ports above this range are used by 'applications' or in this case 'worms'. For example:
Feb 14, 2003 21:07:26.548 UTC - (UDP) Y.Y.Y.Y : 137 >>> X.X.X.X : 137
Is possibly a legitimate a NetBIOS hostname request (relatively harmless but still should be blocked as no one needs this information anyways). Note the source port of 137 that would indicate that something called the OS and requested it make the call (not the most efficient call if you wanted to write a worm which would crush the internet and support your claim as Master all worm authors and King and Owner of the internet).
Whereas
Feb 14, 2003 17:20:35.967 UTC - (UDP) X.X.X.X : 1024 >>> Y.Y.Y.Y : 137
Tends to indicate that some application is making a custom NetBIOS call to your system, which tends currently to indicate the Opaserv or BugBear worms. Typically most of the Opaserv or BugBear infected systems use source ports in the 1024-1033 range, but certainly higher ports are also used.
What about?
Feb 14, 2003 16:32:18.000 UTC - (UDP) X.X.X.X : 64779 >>> Y.Y.Y.Y : 137
This tends to indicate that the infected system is hiding behind a firewall as ports in this upper range are usually due to firewall port mapping. Since the infected system is hiding behind a firewall it is likely infected with something like BugBear which is also a mass mailer worm so it would be more likely to infected systems behind a firewall then Opaserv (Opaserv still could infect systems behind a firewall if someone was 'bright' enough to connect an infected laptop to the protected network for example).
The really big down side of Opaserv and BugBear is that hackers no long have to work or scan/recruit for their zombie armies. Hackers don't scan the Internet anymore; they don't have to as everyday hundreds/thousands of easily compromised systems present themselves to them, just begging to be 0wn3d and willing to do their 'evil' bidding as their physical owners are likely totally oblivious to security issues otherwise they wouldn't have open shares on the internet (this is covered in about the first minute of Security 101).
Hopefully this helps people to understand a little bit more about the traffic they are likely seeing and a bit about easy network forensics. Any questions, comments or general abuse?
Thanks
Blake McNeill
»www.LinkLogger.com
»www.SonicLogger.com |
|
Reviews:
·Shaw
| said by linklogger:
This tends to indicate that the infected system is hiding behind a firewall as ports in this upper range are usually due to firewall port mapping.
Thanks for the information. Apart from the usual and daily UDP probes to port 137, coming from the source ports in the 1024-1034 range, I would occasionally see them from the high end ports and wondered what that was about. Now I know, someone has just advertised that there firewalled system is compromised and open for business. |
|
| reply to Link Logger
said by Link Logger:
Whereas
Feb 14, 2003 17:20:35.967 UTC - (UDP) X.X.X.X : 1024 >>> Y.Y.Y.Y : 137
Tends to indicate that some application is making a custom NetBIOS call to your system, which tends currently to indicate the Opaserv or BugBear worms. Typically most of the Opaserv or BugBear infected systems use source ports in the 1024-1033 range, but certainly higher ports are also used.
What about?
Feb 14, 2003 16:32:18.000 UTC - (UDP) X.X.X.X : 64779 >>> Y.Y.Y.Y : 137
This tends to indicate that the infected system is hiding behind a firewall as ports in this upper range are usually due to firewall port mapping.
Yeah, I have a question. It is not clear to me if this example is explicitly for the port 137/139 issues or if it was used more as an example for a general rule. I would guess the latter (excluding the references to BugBear, etc.). Where in most cases, if the attempt to connect to a port on your system was a "non-malicious" attempt, the source port would most likely be in the 1024 and below range, and the higher ports would likely suggest malicious activity. Would this be accurate to apply as a general rule of thumb?
--
What can possibly go wrong? |
|
Link LoggerPremium,MVM
join:2001-03-29
Calgary, AB
kudos:3 Reviews:
·Shaw
| reply to mens rea
The firewall usually isn't compromised, just a system or systems behind the firewall have been infected. What it tell you is that either they don't have a security guy, virus scanners, etc and that no one is bothering to look at their firewall traffic as this type of infection is easily discovered in the firewall logs (you have a system(s) with tons of outbound UDP port 137 traffic).
Firewalls are usually a good idea for a couple of reasons. First they are not easily compromised meaning its unlikely your Zywall/SonicWall/Cisco/GNAT/etc is going to be shutdown or disabled by a worm (note I didn't include personal firewalls as another advantage that a firewall has is it is independent of any other system and is designed and built purely as a security devices and as such is likely to have far fewer holes. Typically if something like ZoneAlarm is dropped its because you did something that let the bad guy in the backdoor and it dropped ZoneAlarm to open the front door). Next the password for the firewall is not likely to be common knowledge nor hopefully is it going to be the default password (smack to the head with a large blunt object if it is). Not to say that it hasn't happened before that someone had their firewall shutdown or opened up or whatever, but it is rare.
Blake
»www.SonicLogger.com
»www.LinkLogger.com
[text was edited by author 2003-02-15 00:01:00] |
|
 phriday613Your Avatar Is Nice... For Me To Poop OnPremium
join:2002-02-06
Eastchester, NY | thanks for the bit of useful info about how it works!!
its always awesome to get detailed information on how a worm or virus works and propogates!!!
thanks again!!
--
Help find a cure for Cancer - Join Team Discovery! |
|
|
|
Link LoggerPremium,MVM
join:2001-03-29
Calgary, AB
kudos:3 Reviews:
·Shaw
| reply to Komputerguy
The rule is ports 0 - 1023 are reserved for root or privileged users only (one of the reasons why on a Unix box why root is the target for hackers, as it gives you control over everything and you can appear to be anything). Whereas ports above are pretty well fair game for any application (meaning ports > 1023). The fileshare connection is made via a destination TCP port 139 or 445 in the case of Win2k or XP, but the source port doesn't apply in this case. For example a fileshare connection to a Win98 box might look like:
Feb 13, 2003 16:16:34.710 UTC - (TCP) X.X.X.X : 4486 >>> Y.Y.Y.Y : 139
or to a XP system as
Feb 14, 2003 14:27:21.150 UTC - (TCP) X.X.X.X : 4994 >>> Y.Y.Y.Y : 445
So the source port isn't a lot of help here as the port is dynamically allocated by the OS (usually less then 5000 and always greater then 1023). So I would suspect that this attempt is coming from behind a firewall and trying to connect to a Win2k or XP box via a fileshare.
Feb 01, 2003 07:12:25.744 UTC - (TCP) X.X.X.X : 63894 >>> Y.Y.Y.Y : 445
Blake
»www.SonicLogger.com
»www.LinkLogger.com |
|
| said by Link Logger:
The rule is ports 0 - 1023 are reserved for root or privileged users only (one of the reasons why on a Unix box why root is the target for hackers, as it gives you control over everything and you can appear to be anything). Whereas ports above are pretty well fair game for any application (meaning ports > 1023). The fileshare connection is made via a destination TCP port 139 or 445 in the case of Win2k or XP, but the source port doesn't apply in this case. For example a fileshare connection to a Win98 box might look like:
Feb 13, 2003 16:16:34.710 UTC - (TCP) X.X.X.X : 4486 >>> Y.Y.Y.Y : 139
or to a XP system as
Feb 14, 2003 14:27:21.150 UTC - (TCP) X.X.X.X : 4994 >>> Y.Y.Y.Y : 445
So the source port isn't a lot of help here as the port is dynamically allocated by the OS (usually less then 5000 and always greater then 1023).
Looks like to me if the source port is below 1024 then you could make an educated guess that the connection attempt is being controlled by a root privileged user or a service/malware running as root. I don't see where you would have any idea if it is a non-malicious connection attempt or some hacker that has obtained root (or a worm running in the context of root) that is trying to connect.
The higher numbers seem to be even less definitive.
--
What can possibly go wrong? |
|
Link LoggerPremium,MVM
join:2001-03-29
Calgary, AB
kudos:3 Reviews:
·Shaw
| The point of this is bad vs evil and how can tell the two apart, or at least have an idea which is which.
All inbound NetBIOS traffic should be by default blocked. There are a couple of commands which by default use source UDP port 137 that I will use some examples to further explain what I mean.
**** Before we go any further let me post a disclaimer here. Scanning the Internet, be it a single system or full netblock it still may be in violation of your ISP's Acceptable Use Policy and use of any or some of the examples listed below might be considered 'scanning' by your ISP and subject whatever action your ISP determines, so please be warned ****
The first of which is a hostname request. Lets try 'ping –a' which returns the hostname, but select an IP address that doesn't have a reversible DNS entry so that Windows will then attempt a NetBIOS hostname request (hint most Korean or Chinese ISPs don't enable DNS hostnames, for extra flavor I selected one in Europe).
Ping –a x.x.x.x
Results in:
Feb 15, 2003 08:55:55.513 UTC - (UDP) a.a.a.a : 3768 >>> y.y.y.y : 53
Feb 15, 2003 08:56:09.523 UTC - (UDP) a.a.a.a : 137 >>> x.x.x.x : 137
Feb 15, 2003 08:56:11.516 UTC - (ICMP) <8:512> 192.168.168.2 >>> x.x.x.x
a.a.a.a is my IP address
y.y.y.y is my DNS server
x.x.x.x is the target system
So we see a request to UDP port 53, which is the DNS request, but since we picked an address that doesn't have a hostname entry in the DNS, then Windows by default resorts to a NetBIOS hostname lookup, which you see as UDP port 137 traffic to x.x.x.x. Note the source port is port 137 which indicates that something told Windows to use its 'root/system' NetBIOS service and hence port < 1024, or in this case exactly UDP port 137. So this is an example of a NetBIOS Hostname request, not really a biggie in terms of hacker information, except it tells them that you have NetBIOS enabled, which in itself can be rather significant (if a hostname is returned).
Next lets look at what Opaserv, Bugbear, etc are doing when they initially probe your system. Again we are going to use a command prompt and enter 'nbtstat –A' (Note long ago I posted an article on DSLReport on nbtstat so it might still be kicking around).
Nbtstat –A x.x.x.x
Results in:
Feb 15, 2003 09:03:34.583 UTC - (UDP) a.a.a.a : 137 >>> x.x.x.x : 137
Note the results displayed on your screen however:
Local Area Connection:
Node IpAddress: [a.a.a.a] Scope Id: []
NetBIOS Remote Machine Name Table
Name Type Status
---------------------------------------------
XXX <00> UNIQUE Registered
XXX <03> UNIQUE Registered
XXX <20> UNIQUE Registered
..__MSBROWSE__.<01> GROUP Registered
WORKGROUP <00> GROUP Registered
WORKGROUP <1D> UNIQUE Registered
WORKGROUP <1E> GROUP Registered
MAC Address = xx-xx-xx-xx-xx-xx
This is a Status request of a NetBIOS table and the component of interest here is the '<20>' that indicates that the system has potential shares available, hence Opaserv, Bugbear, etc zero in on a potential victim. NOTE this is a bad call as it surrenders valuable information about your system.
Note however for our example the network traffic seen was:
Feb 15, 2003 09:03:34.583 UTC - (UDP) a.a.a.a : 137 >>> x.x.x.x : 137
Again UDP traffic to port 137, but again the source port is 137, indicating that something instructed Windows to use its NetBIOS process.
This is different then the original scan from this Opaserv infected system (complete with an open C: drive) of
Feb 15, 2003 07:46:48.169 UTC - (UDP) x.x.x.x : 1025 >>> a.a.a.a : 137
So whatever scanned my system didn't use the 'native' NetBIOS process on UDP port 137 as it was using a custom NetBIOS call (really just a standard UDP connection with a 'netbios request' string) from a separate application (in this case the Opaserv worm) and hence using a port above 1023. You used to be able to tell a scripted attack as it used source port 137, but now we have Opaserv and BugBear which are executable programs and don't use source port 137 as they use their own UDP connections for the Netbios probes.
Hopefully this explains a little better, a little more or little differently the topic area.
Blake
»www.SonicLogger.com
»www.LinkLogger.com
[text was edited by author 2003-02-15 05:06:41] |
|
Link LoggerPremium,MVM
join:2001-03-29
Calgary, AB
kudos:3 Reviews:
·Shaw
| I have seen over a thousand Opaserv/BugBear scans a day here, but now we are down to about 325 a day. A year ago a couple of UDP port 137 probes per day would have been lots.
Blake
»www.SonicLogger.com
»www.LinkLogger.com |
|
| reply to Link Logger
I still don't see where this gives you that much confidence in making a general conclusion. In summary what I see you saying is if the source port was 137 it could be non-maliciously using the native NetBIOS process or it could be malicious. If the source port is something other than that, it could be a non-malicious attempt or a malicious attempt...
--
What can possibly go wrong? |
|
Link LoggerPremium,MVM
join:2001-03-29
Calgary, AB
kudos:3 Reviews:
·Shaw
| All port 137 traffic should be considered malicious, have I given an impression otherwise?
What I am trying to show is here what might be the source of the 137 traffic. If its source port 137 then its using a native Netbios API call (and hence wouldn't be Opaserv or Bugbear as they don't use API calls to Netbios for the 137 probe), or if the source port is greater then 1023 then its an application and given currently active worms on the internet likely Opaserv or Bugbear. Also given that Windows doesn't normally dynamically assign ports in the higher ranges (xx,xxx for example) then you can feel fairly confident that the infected or attacking system is behind a firewall as firewalls do map ports into the higher ranges. Of course there is nothing cut into stone here but this can give you a reasonable confidence as to what is happening.
Could you give me an example of what you are thinking and perhaps it would help me understand where you are coming from and perhaps we can expand out the topic a bit to cover that.
Blake |
|
| said by Link Logger:
All port 137 traffic should be considered malicious, have I given an impression otherwise?
From my interpretation (which certainly is susceptible to frequent lapses ), Yes.
said by Link Logger:
Could you give me an example of what you are thinking and perhaps it would help me understand where you are coming from and perhaps we can expand out the topic a bit to cover that.
Fair enough. First, one of your examples is that of ping. I would not personally consider that inherently malicious. It may be malicious, it may not be. In some cases it depends on the context of your network if ping is considered malicious or undesirable. Another specific example would be any Windows software which was coded to use the gethostbyaddr will attempt to resolve the name of a given API. If that fails, it will do just what you described in that it will then attempt to get a NetBIOS name resolution using port 137. The software does NOT have to be malicious for this to happen. In fact, until a newer API came out called getnameinfo, the getnamebyaddr API was very commonly used and still is, actually.
A specific example is WallWatcher, a Linksys router log application. Up until recently it was using getnamebyaddr which occasionally might cause the NetBIOS 137 connections. This was recognized as being undesirable by the author and users, but programmatically there was few alternatives to resolving the name of a system. On a recent version, this functonality was changed to use getnameinfo which resolves the issue. But this API is not fully supported by all platforms so some OS's still may end up using the older getnamebyaddr API. This software is far from being malicious as is the connection attempt on port 137.
And undesirable != malicious in all cases. Also IMO, systems that are attempting connections due to being poorly configured systems are not malicious. Annoying and undesirable, yes, but not malicious.
Second, is it not true that if a system is "poorly configured" for Windows sharing, it will attempt to browse, and thus possibly making connection attempts in these port ranges? I think this is common for broadband configurations that may have your entire neighborhood on the same shared channel. If true, I wouldn't call that malicious, either. Annoying and undesirable, maybe, but not necessarily malicious.
--
What can possibly go wrong? |
|
Reviews:
·Shaw
| reply to Link Logger
Link Logger I apologize my question is a little late in the thread, but the majority of information on opaserv for example, from various antivirus sites, tend to describe what it does and not how it does it. In other words it is a worm that spreads via network shares, creates certain files in the windows folder,makes certain registry entries and then scans a range of IP addresses for the local area network searching for computers with an open C: share and NETBIOS enabled over TCP/IP, etc. Given what you describe above in your ping -a example, exactly how does opaserv perform its scan as described? Is it as something as simple as an nbtstat -A request? I'm not particularly computer literate, and describing what it does leaves me very curious as to the how, which in turn would help my understanding of your example. Regards |
|
Link LoggerPremium,MVM
join:2001-03-29
Calgary, AB
kudos:3 Reviews:
·Shaw
| The ping -A example given above were an example of how Windows uses the 'root/system' netbios process to send out a hostname request via source port 137.
Basically how Opaserv works is it uses a nbtstat -A like command send using dynamically allocated UDP port to see if any shares are available. It then attempts to connect to those shares in order to copy its payload onto the victim's system and update their registry such that the payload will be run on next boot up. There are some other enhancements that it uses to connect, for example it can get around fileshare passwords on unpatched Windows 98 systems due to a vul in its fileshare security.
Blake |
|
