Shadow software attack still works

Abstract

This page shows that it is possible for a user to catch a port which is/was owned by another user, which represents an opportunity for malevolent attacks.

I. BACKGROUND
I'm going to face the problem with a practical approach in order to give a clear idea of the essence of the problem. Then, this kind of attack can be extended on every software which is near, as working mechanisms, to the following shown example.

My choice was irc bouncers and/or irc bots.

Irc bouncers are used as gateway to connect on irc servers. There are lots of advantages that you can obtain using this programs like the possibility to use an host different from your real one to connect on the irc server. Bouncers, in fact, should protect you against DoS attacks and similar actions.

II. DESCRIPTION
Exploiting default settings of the bouncers(port listener, banners, response messages and so on), it is possible to simulate its interactions with the users in order to obtain the password of the victim.

III. ANALYSIS
To exploit this opportunity the attacker should know and/or own the following information:

1) the port of the victim's bouncer;
2) the response messages of the victim's bouncer;
3) an account on the same machine of the victim;

The attacker could code a simulator of the bouncer used by the victim, listening on the same port. Since the port is busy because used by the victim's bouncer, the simulator will not run, but this is not a problem.
If the machine has got a crontab it's enough to put the simulator under crontab with the lowest range of time (e.g. trying to run the simulator every minute). When the machine will be rebooted or the victim's bouncer will crash, the attacker's fake bouncer will run correctly.
When the user will log into the bouncer, he will send his personal data that will be logged, then the simulator will die. Now, the victim's data are stolen. When the victim will try to log into the original program again, probably the real bouncer has been loaded. However his data are stolen.

IV. DETECTION
In many systems a solution was introduced for the root's ports (users can't bind ports<1024) but not for the users' ones. It's not a bug but, personally, I think it's a negligence in the design(in the small) of the architecture for assigning the ports. Some easy control could be done by default.

The main victims could be shell providers or sellers of internet services.

V. FIX
The problem exists because many programs doesn't adopt any kind of defensive mechanism (such as TLS) and users can catch any port (but the root's ones) of the machine to realize a simulator.
A possible solution is to assign a range of ports for each user, it is done by a lkm named fixbind.
This is not "the solution" (it's much better using TLS) but just a proof of concept to show how it's possible to manage the SYS_bind call. The uid<555 is a design choice so don't move me stupid critics.

Definition of the solution with the language of first order logic:

A1. base_port = first_port+(step*uid) => base_port-1 < port_range < base_port+step

A2. assign_port(uid, port) <=> base_port-1 < port < base_port+step && uid < 555

One can download this fix from http://www.rosiello.org/archivio/fixbind.c

VI. CREDITS
Angelo Rosiello
angelo@rosiello.org

Rosiello Security
http://www.rosiello.org

Software: fixbind.c