Playing with the honeytrap module, I saw some strange behaviour from hosts attacking nepenthes.
They connected, exploitet to gain shell, connected the shell, and run a ftp command.
Nepenthes connected the viris ftp server, and asked for the file, providing the port where to send the file via the PORT command (active ftp).
In some cases, the virus would send the file to a _very_ different port, the honeytrap module kicked it, and we got the file send to a shell emulation.
So, we checked if there was a bug when sending the PORT command in nepenthes, and found none, having a look on some sdbot forks ftpd code, we got this:
if ( strcmp(tmpbuf,"PORT") == 0 )
po = atoi(p1);
po2 = atoi(p2);
h = strtoul(p1, NULL, 16);
send(i,"200 PORT command successful.\n",29 , 0);
the PORT command is parsed using sscanf, and splitup in a b c d p1 and p2.
Each comma seperated value in this listing is a bytes value, its range is from 0-255. a.b.c.d represents the remotes ip, and p1 and p2 are parts of the port.
Obviously 'recalculating' the port failed in some cases, but why?
Using the code to create a PORT command from nepenthes and the code from the virus to parse the command, we ended up that 61440 of 65536 ports would work with the virus code, which meant in 4080/65536 of all cases, or ~6.2% the ftp download would fail as the virus would 'calculate' the wrong port.
Now, to understand why the virus fails, one has to understand how the portnumber is encoded into the PORT command.
The port command has 2 bytes, and therefore needs 2 comma seperated values in the PORT command, when creating the PORT command, you get the integer value of the first byte of the port, print it, and then print the integer value of the second byte of the port.
int main(int argc, char **argv)
if ( argc < 2)
int port = atoi(argv);
printf("PORT 127,0,0,1,%i,%i\n",(port >> 8) & 0xff, port & 0xff );
as an example gives
so the port is encoded into 18 and 103, to regain the value of the port, one could calculate
ntohs((18 << 8) | 103)
but the viri authors decided to do better, and did
h = strtoul(p1, NULL, 16);
where p1 would be “1267\n” using our values, and h would be 4711, the right port.
Now, to see it failing, lets see what happens when using port 1280.
our port 1280
their p1 string 50
their port 80
As you might be able to see, their p1 string is too short, it should be “0500” which is 1280 when using 16 as base.
The port calculation would fail on every port where the hex value of the lower byte starts with “0”, using
instead, or using the previous posted shifting would prevent this.
To workaround this problem, we decided to use only ports for ftp known to be working with buggy viri.