Port 666

Detecting Reverse Connect Proxy Bots

How many Star Trek classic fans are in the house? Man, I just love that show. I honestly believe that is was Star Trek that generated my interest in engineering and of course kept me from getting dates until college, but that's a story for my therapist. There is an episode called "The Corbomite Maneuver," where the intergalactic King of Cool Captain Kirk bluffs a goober alien into thinking he has a heavy duty bomb onboard and the alien backs off. Then he, Spock and Scotty drink a case of Newcastle and ash out a Cohiba. OK, I am kidding about that part; Spock wasn't there.

Sometimes I feel that when we learn security, NAT/PAT is the Corbomite Maneuver of networking. It seems logical that NAT should be a safety net since my users are on RFC 1918 non-Internet-routable IP addresses front-ended by a single routable one. Logic breaks down where news headlines begin. Many, many networks are still being hacked every day. How are the hackers getting around NAT? How are they breaking this rule? Well, the truth is they are not breaking it, as much as they are going around it via one of two ways:

- Compromise an internal host
- Exploit a vulnerability in the firewall to compromise trust

The old-school method of getting an internal host was via email and load a netcat shell so that I can reverse-telnet back thru a firewall (via port 80) to my machine. I am seeing a newer method now called reverse proxy tunneling, which is taking over ground from the traditional IRC bots. Most bot coders have avoided a SOCKS type of proxy since NAT would prevent an inbound request and the code base is much too fat.

Reverse-connect proxies are taking advantage of a couple of things that many network admins do:

- Do not filter egress traffic
- Do not look for well-known ports. (Sockets below 1024)

A Port 666 reverse-connect proxy gets its name from the custom hex string 0x029a which in ASCII is 666. This piece of code actually uses some of the concepts from SOCKSv5 to form a huge global network for (at least now) spamming folks to death. SOCKSv5 has the advantage of being overlooked by many IDS/IPS systems. Typically how this gets thru your NAT filter is like this:

- A proxy bot is installed on your machine. Methods like Java exploits, Flash overflows, iFramers, etc.
- The bot starts to contact back to the host command-and-control server via 80 or if it is blocked it starts port walking to find an open port 8088,25,23, etc.
- Once connected that machine is under the control of the bot herder and it is a reverse proxy. 0wn3d

It is that easy and that quick. Port 666 proxy bots are designed to look like legitimate traffic on your network and truthfully, can be hard to track down. I am a huge Snort user and believer on my networks. If you have a Snort server there is a good rule set called: ?unusual-client-port-connection? that works good for Port 666 detection.

If you have a Cisco network then are two great options for detecting this threat:

- Netflow: This is fantastic telemetry data to monitor the flow of traffic and detect an anomaly or even just feed it straight into a CS-MARS box
- Flexible Packet Matching: This is one of the best security features in Cisco products that I just completed a detailed WebEx workshop on. (replay available) FPM is the next-gen Access Control List that can look so deep into a packet that we can look for offset 0x029a and drop this on the spot.

Keep in mind that NAT is just another tool on your network to secure it. It is not bulletproof to hackers but only a speedbump on the road to stealing your data. Plus, know when any vendor is trying to pull the Corbomite Maneuver on you when it comes to security!

Jimmy Ray Purser

Trivia File Transfer Protocol
Biblical speaking, the number 666 is considered the mark of the beast. However, in the oldest copies of the book of Revelation the number is actually 616.

• Security
• bots
• Cisco
• hacking
• Jimmy Ray Purser