Its a common technique. You suspect one of your systems has been compromised, so you run a port scanner against the system. The hope is that if the system is backdoored you will identify an undocumented listening port. But what if a clever attacker hides the backdoor in plain site? What if they hide the backdoor behind an existing port you actually expect to see listening on the system? Unfortunately this is far too easy to accomplish if the host is running Windows.

The UNIX way

On a UNIX or Linux system, listening ports are always opened exclusively. In other words, if a mail process opens up TCP/25 to accept inbound mail connections, any other application that attempts to listen on TCP/25 will receive a bind error and be denied access. The only way the second application can bind to TCP/25, is to first kill off the mail process using the port. So only one application at a time is ever permitted access to a listening socket.

The Windows way

In Windows, exclusive access to a listening port is optional. Its perfectly legal to have multiple applications listening on the same TCP or UDP port. This of course can simplify the process of setting up a backdoor behind an existing application.

With Windows, exclusivity of socket access is actually a process that has been evolving over the years. Windows 95, 98 and ME actually had no way to open a port exclusively. There was nothing one application could do to prevent another from attaching to the same listening port. For versions of Windows between NT and XP, it is possible to request exclusive port access via the SO_EXCLUSIVEADDRUSE option. If exclusive access is not specifically requested however, the default is to fall back to providing shared access.

With Windows 2003 and later, the default is exclusive port access unless both applications specifically request shared access via the SO_REUSEADDR option. The exception is that if the same account is used to launch both applications, shared access is still possible unless exclusive access is specifically requested. This means that if a savvy attacker can launch their backdoor via the system account, this enhanced security will usually be defeated.

Try it yourself

To test how this works, you’ll need a copy of the Windows version of Netcat. Copy nc.exe into one of the directories in your path statement. Once you do, open a command prompt and try the following command:

C:\>nc -l -p 135

Can’t grab 0.0.0.0:135 with bind

We just told Netcat to listen (-l) on TCP port (-p) 135. When Windows first boots up, Microsoft RPC opens TCP/135 with the SO_EXCLUSIVEADDRUSE option set. Thus if any application (like Netcat) tries to listen on TCP/135, it receives the bind error shown above. This is the type of behavior we would like to see all of the time.

Now try opening a port that is not already in use:

C:\>nc -l -p 1234

It should appear as if the command is hanging (command prompt does not return). This tells you that Netcat is now listening on port TCP/1234. To verify this, open a second command prompt and type the command:

C:\>netstat -an | find “1234″

TCP 0.0.0.0:1234 0.0.0.0:0 LISTENING

This shows us that Netcat is now listening on TCP/1234 on all network interfaces.

When Netcat opens a listening port it does not request exclusive access to the port. This means it is possible to bind Netcat to an existing listening port that has not already been opened exclusively. To test this, open a third and fourth command prompt. Enter the same Netcat command into each that you run within the first command prompt. Each command should execute without error.

Does this mean Netcat is listening multiple times? Go back to the second command prompt window and try the following command:

C:\>netstat -aon | find “1234″

TCP 0.0.0.0:1234 0.0.0.0:0 LISTENING 448

TCP 0.0.0.0:1234 0.0.0.0:0 LISTENING 3044

TCP 0.0.0.0:1234 0.0.0.0:0 LISTENING 3016

We’ve added in the “o” switch which prints out the process ID for the application holding open the listening port. Note that a different instance of Netcat is responsible for each of the open listening ports. Because Netcat does not require exclusive access to the port, we can listen on the port multiple times.

So what happens when someone tries to connect to the port? Try it and find out using the following command:

C:\>nc 127.0.0.1 1234

This is a test

You should see the text “This is a test” appear in only one instance of the Netcat listeners. If you leave this session active and open (yet another) command prompt and type:

C:\>nc 127.0.0.1 1234

This is test 2

You should see this text appear in a different instance of the Netcat listener.

What have we learned

Since Windows does not require applications to have exclusive access to a listening port, its possible to have a malicious backdoor sitting behind a legitimate application, on the same listening port. This makes the backdoor undetectable when performing a port scan. In order to connect to the backdoor you must first busy out the legitimate application with an active session, but this is easy to achieve.