Paper discussing the caveats of port assignments above 1024 and how users should have blocks of ports assigned to them.
98b106f520298d4b1409ec2597c5001842dc8da75de5cd665c577160a99ee686
<HTML>
<BODY TEXT="#000000" BGCOLOR="#ECF5FA" LINK="#0000FF" VLINK="#008080" ALINK="#800000" title="bugs" bgproperties="fixed">
<font color="#000000" face="Arial, Helvetica, sans-serif"><div align="center"><strong><u>Vulnerabilities</u></div></strong></font>
<p><h4 align = 'center'>2004-04-16</h4><p><b><h2 align = 'center'><FONT COLOR='#FF0000'>Shadow software attack still works</b></FONT></h2><p><p><center> Copyright © 2004 Rosiello Security
<p>
<i>Abstract</i></center>
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.
<p>
<b>I. BACKGROUND<br></b>
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.
<br><br>
My choice was irc bouncers and/or irc bots.
<br><br>
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.
<p>
<b>II. DESCRIPTION<br></b>
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.
<p>
<b>III. ANALYSIS</b>
<br>
To exploit this opportunity the attacker should know and/or own the following information:<br><br>
1) the port of the victim's bouncer;<br>
2) the response messages of the victim's bouncer;<br>
3) an account on the same machine of the victim;<br>
<br>
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. <br>
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. <br>
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.
<p>
<b>IV. DETECTION<br></b>
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.<br><br>
The main victims could be shell providers or sellers of internet services.
<p>
<b>V. FIX<br></b>
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.<br>
A possible solution is to assign a range of ports for each user, it is done by a lkm named fixbind.<br>
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.
<br><br>
Definition of the solution with the language of first order logic:
<br><br>
A1. base_port = first_port+(step*uid) => base_port-1 < port_range < base_port+step<br>
<br>
A2. assign_port(uid, port) <=> base_port-1 < port < base_port+step
&& uid < 555
<br><br>
One can download this fix from <a href="http://www.rosiello.org/archivio/fixbind.c">http://www.rosiello.org/archivio/fixbind.c</a>
<p>
<b>VI. CREDITS</b>
<br>
Angelo Rosiello <br>
angelo@rosiello.org
<br><br>
Rosiello Security<br>
http://www.rosiello.org
<p><b>Software: <a href='../archivio/fixbind.c'>fixbind.c</b></a></body>
</html>