3 Days left to Save $400 on SANS DFIR Summit

Intrusion Detection FAQ: Port 1600 Scan

Originally submitted as part of a GIAC Practical Analysis For IDIC Certification
Eric Gallagher

From local tcpdump:

21:57:18.468912 MY.NET.2.4.4277 > MY.NET.1.0.1600: udp 46
21:59:18.478004 MY.NET.2.4.4278 > MY.NET.1.0.1600: udp 46
22:01:18.487730 MY.NET.2.4.4279 > MY.NET.1.0.1600: udp 46
22:03:18.498327 MY.NET.2.4.4280 > MY.NET.1.0.1600: udp 46
22:05:18.507726 MY.NET.2.4.4281 > MY.NET.1.0.1600: udp 46
22:07:18.517192 MY.NET.2.4.4282 > MY.NET.1.0.1600: udp 46
22:09:18.527483 MY.NET.2.4.4283 > MY.NET.1.0.1600: udp 46
22:11:18.536690 MY.NET.2.4.4284 > MY.NET.1.0.1600: udp 46
22:13:18.546665 MY.NET.2.4.4285 > MY.NET.1.0.1600: udp 46

This scan repeated itself any number of times on my networks. The source machine ran through its ports in order, always broadcasting (in the older, BSD-style way, at the network address) to destination port 1600. Since I am fairly new to this particular job and therefore unfamiliar with these networks, I didn't recognize the source machine address offhand, although I discovered it was a legitimate node on my network. It is an older medical imaging device manufactured by General Electric. Recently, it has been moved to a new room and turned back on after a long period of downtime.

Targeting: This much is obvious, since the source machine is sending to the network address of the entire MY.NET.1 segment. The nature of the response expected is a mystery but the scan is targeted to my networks, albeit in a primitive way.

Intent: A scan for port 1600 looks suspicious for a couple of reasons. First, there is a trojan called Shivka-Burka that uses this UDP port. I'm seeing only the broadcast traffic on our network (because we're switched) but this could be one side of a two-way communication with a Shivka-Burka trojan. Of course, this is such a loud, obvious scan that the Shivka-Burka scenario seems unlikely but it can't be ruled out. The second point of suspicion is the ISSD service that's registered as the legitimate service user of port 1600. If MY.NET.2.4 is a compromised machine, the cracker could have set up a scan for this service in order to exploit a weakness in it.

Techniques: A typical broadcast mapping attempt, albeit on an unusual port.

History: The network mapping restarted every time this particular medical console was turned back on. Unfortunately, none of the GE technicians had any idea why the machine was doing this. Some of the more experienced medical/technical workers felt that we were seeing a hostile signature. Certainly the machine had been around long enough to get cracked (nine years).

When I came to this department, four Solaris machines had been lost to successful cracks and more were under attack. However, no other old SunOS system had not been cracked during the months of network break-ins and it seemed likely that a network hacker/cracker smart enough to get into one would have reached some of the others, as well. Since the MY.NET.2.4 machine was based on SunOS, it seemed, due to our local, historical reasons, more safe than a Solaris or IRIX based station.

I took a look, via nmap, at the interesting ports left open on MY.NET.2.4. Among them were:

Port State Service
104/tcp    open    acr-nema
655/tcp    open    unknown
658/tcp    open    unknown
670/tcp    open    unknown
723/tcp    open    unknown
725/tcp    open    unknown
727/tcp    open    unknown
728/tcp    open    unknown
733/tcp    open    unknown
736/tcp    open    unknown
1024/tcp   open    unknown

So the nmap tool did not detect an open port 1600 on the MY.NET.2.4 machine itself. This was not what I expected and increased my concern, since I felt that this medical console would be configured like all others from GE and would therefore have a service open on port 1600 if it was a legitimate destination port. The port 104 is a medical standard for DICOM data transfer, so that was expected. The unknown ports seem to be specific to this older generation of GE equipment, so they were not a serious cause for alarm. At this point, however, I had to step up my severity estimate.

Severity: Moderate. To understand why, you have to know the full history. Although I did not see any crack attempt (no lethality) and I felt the crude nature of the scan revealed its innocence, I had to increase my judgement of the scan's severity the longer this activity remained unsolved. GE's apparent ignorance of the network software along with the nature of the data (medical and therefore confidential) necessitated further investigation.

Action Recommendation: The first action would be to talk with the manufacturer's representatives and determine whether or not this is expected behavior. A check for rootkits (although often futile) must be done, as should a check for all other signs of intrusion into the GE medical workstation. On the IDS end, it's possible to check to see if the packets were corrected formed or showed any signs of tampering. It's an even better idea to monitor port 1600 activity on all machines in the network and turn off the GE medical workstation if there is any sign of attack through this port.

Resolution: I failed to find any clear signs of a break-in on this machine and had determined that the UDP packets looked legitimate based on this pattern:

16:25:08.759896 ic1.3701 > MY.NET.1.0.1600: udp 46
     4500 004a 60ee 0000 3c11 72e1 80e7 d504
     80e7 d400 0e75 0640 0036 0000 0000 007e
     0000 05e8 4e4d 5231 0000 4943 3000 0000
     0000 0000 0000

16:27:08.769361 ic1.3702 > MY.NET.1.0.1600: udp 46
     4500 004a 60ef 0000 3c11 72e0 80e7 d504
     80e7 d400 0e76 0640 0036 0000 0000 007e
     0000 05e8 4e4d 5231 0000 4943 3000 0000
     0000 0000 0000

Not only were the packets correctly formed but, as far as UDP was concerned, they were all identical. Above, you can see that three octets increment or decrement regularly. These are all part of the IP datagram. The change from 60ee to 60ef represents the changing ID number of the datagram. The decrement from 72e1 to 72e0 represents the differences in IP header checksum. The change from 0e75 to 0e76 shows the IP destination address incrementing, which we can already see in our earlier trace. I admit I don't understand the IP header checksum business but the behavior seems consistent. All further packets display the same properties:

16:31:08.790067 ic1.3704 > MY.NET.1.0.1600: udp 46
     4500 004a 60f1 0000 3c11 72de 80e7 d504
     80e7 d400 0e78 0640 0036 0000 0000 007e
     0000 05e8 4e4d 5231 0000 4943 3000 0000
     0000 0000 0000

16:33:08.799578 ic1.3705 > MY.NET.1.0.1600: udp 46
     4500 004a 60f2 0000 3c11 72dd 80e7 d504
     80e7 d400 0e79 0640 0036 0000 0000 007e
     0000 05e8 4e4d 5231 0000 4943 3000 0000
     0000 0000 0000

In the end, my judgement was that this traffic consisted of legitimate broadcast packets. I could find no signs of a break-in on the medical workstation, although I found myself somewhat unfamiliar with what it means to have a normal machine environment in an old GE medical system.
When I mentioned that the GE medical workstation was running NIS services (which looked more strange than suspicious, to me), this helped one of the GE technicians. In fact, the very first GE technician I'd asked about the port scan came back to me after doing a bit of research and some plain-old remembering. He said that port 1600 was used by the old GE AdvantageNet for communication between medical imaging stations as part of the coordination of traffic flow between them. An old Genesis master console not only scans port 1600 for other GE AdvantageNet devices but administer them as an NIS server as well, although data transfers via the DICOM standard take place over port 104, not over any of the GE or NIS ports. Since the MY.NET.2.4 machine had been a master console when it was originally active, it ran the scans and the NIS services.

I still do not know the purpose of all the other GE-specific services but I do expect I will be able to unravel those mysteries.

Historical side note: DICOM image transfers between many old medical systems do not take place over TCP/IP, as would be normal for the new, IP-based transmission standard. DICOM was once its own transmission protocol, not merely a format encapsulated in a TCP header. I wonder if anyone aside from the original vendors has a way to detect traffic signatures from these old devices. I wouldn't be surprised if some hospitals out there have old, misconfigured networks clogged by legacy DICOM traffic they can't properly diagnose due to poor firewalling, filtering, and/or packet detection.