FTP WTF



  • We have this vendor that we have to go to their FTP site and retrieve a file.  In order for our FTP software to work we must be able to perform the 'ls' command (because that is how the Java class gets a file list on our internal application works, dont go there...).   The vendor tells me "there is a test file out there, let us know if you can retrieve it."  I try to get it and cannot.  I try manually at command line and see nothing in the directory.

     

    After shooting them an email I get the response "we do not allow customers to use the 'ls' command as a security policy."  I was told that if somebody hacked in that removing the 'ls' command would prevent them from knowing which file to download.  I am surely no security expert, but how exactly is removing the 'ls' command going to make your FTP server more secure?

     

     



  •  That's called "security by obscurity".  It's a common, and utterly useless, attempt to make things "secure".  All it normally does, as in this case, is make life hell for people who want to use the system normally.

    FTP is not always *nix-centric.  Try running "dir" at the command line and see if you get results. If you do, it only proves what fools these people really are.

     

     



  • I would guess that it's a bit of "security through obscurity". Perhaps they are trying to protect against someone attacking their FTP server at random, managing to brute-force a username and password, and then trawling through the files to see if there is anything interesting (there are lots of bots out there that behave this way). Removing the 'ls' command would prevent the attacker from finding any files on the server. However, if the attack is specifically targeted toward that server, this particular counter-measure would be less effective, as the attacker would likely have more knowledge of what they are trying to get from that server. Someone there thought that the security-vs-convenience tradeoff in this case was worth it - obviously, that's not a universally-held opinion. :-)

    Hopefully that isn't the only security measure that they are relying on, though - if it were me, I'd implement things like denyhosts (to detect and block IP addresses after a number of unsuccessful login attempts) and a half-decent password policy (minimum length, non-dictionary word, etc.) to counteract the brute-force attack. Just my 2 cents, of course... and I also am not a "security expert", but I do play one on TV.



  • @cowboy_k said:

    I would guess that it's a bit of "security through obscurity". Perhaps they are trying to protect against someone attacking their FTP server at random, managing to brute-force a username and password, and then trawling through the files to see if there is anything interesting (there are lots of bots out there that behave this way). Removing the 'ls' command would prevent the attacker from finding any files on the server.

    The brute-force bots don't care what's on the server. They're looking for disk space to use for distributing illegal materials.

    @cowboy_k said:

    Hopefully that isn't the only security measure that they are relying on, though - if it were me, I'd implement things like denyhosts (to detect and block IP addresses after a number of unsuccessful login attempts) and a half-decent password policy (minimum length, non-dictionary word, etc.) to counteract the brute-force attack.

    That's overkill. If you're trying to stop the bots, all you need are uncommon usernames and passwords that aren't the ten most popular. Denyhosts will work today, but I don't expect it to be long before the FTP bots adopt the distributed attacks that the SSH bots are using.



  • @duncan99 said:

    FTP is not always *nix-centric.  Try running "dir" at the command line and
    see if you get results.

    Uh... How does this relate to Unix? "ls" maps to FTP NLST command, "dir" to "LIST". Nothing Unix(or not)-centric here.



  • @Spectre said:

    @duncan99 said:
    FTP is not always *nix-centric.  Try running "dir" at the command line and
    see if you get results.

    Uh... How does this relate to Unix? "ls" maps to FTP NLST command, "dir" to "LIST". Nothing Unix(or not)-centric here.


    DAMN YOU L33T H4X0R FOR BREAKING ALL OUR SECURITY MODELS!

    Spectre, you will be sued to high-heaven for fooling our grand security model for now allowing the LS command. Since FTP NLST is not known by most people...



  • @Spectre said:

    @duncan99 said:
    FTP is not always *nix-centric.  Try running "dir" at the command line and
    see if you get results.

    Uh... How does this relate to Unix? "ls" maps to FTP NLST command, "dir" to "LIST". Nothing Unix(or not)-centric here.

    I don't know what telnet client you are using, but BSD telnet maps both "ls" and "dir" to LIST.  Neither map to NLST.



  • @morbiuswilters said:

    I don't know what telnet client you are using

    Windows <font face="Courier New">ftp</font>. Guess MS added a touch of originality.

    @morbiuswilters said:

    but BSD telnet maps both "ls" and "dir" to LIST.  Neither map to NLST.

    Aye, I've just checked. For NLST there is "nlist".

    Also, telnet? WTF?



  • @Spectre said:

    @morbiuswilters said:
    I don't know what telnet client you are using

    Windows <font face="Courier New">ftp</font>. Guess MS added a touch of originality.

    Zesty.

     

    @Spectre said:

    @morbiuswilters said:
    but BSD telnet maps both "ls" and "dir" to LIST.  Neither map to NLST.

    Aye, I've just checked. For NLST there is "nlist".

    Also, telnet? WTF?

    Whoops.  I'm used to referring to BSD telnet in my day-to-day work and I guess my brain's auto-complete algorithm favors it over the less-frequently-typed "BSD FTP".  In repentance, I shall flog my servants with extra vigor tonight.



  • This might not be too much of a WTF.

     

    It very common, at least on UNIX to setup FTP accounts to be chroot-ed.  This means that the default dir you drop them in now becomes / and they can't go any higher.  It keeps people from getting into places they shouldn't be.  The only problem is a lot of FTP servers on UNIX at least exec out to run the ls command.

     But the ls command is in /bin and you can not longer get to the real /bin.  So into order for it to work you have to make a copy in a bin directory under the chroot point.  And on top of hat if ls requires any shared libs, you need them also.

    I've seen plenty of places were ftp is used to pickup or push a file with a known name, ls would not be needed.  If the sysadmins set the account up to be chroot-ed, and didn't follow up with making copies of ls into all the accounts, then you would get exactly what was seen, no WTF at all.



  • @PG4 said:

    I've seen plenty of places were ftp is used to pickup or push a file with a known name, ls would not be needed.  If the sysadmins set the account up to be chroot-ed, and didn't follow up with making copies of ls into all the accounts, then you would get exactly what was seen, no WTF at all.
    In this case I'd humor the client who needs ls by either adding it for them, or (in case this is demed too dangerous) adding a script that simply returns the name of the one file in the directory. I'm pretty sure that it's possible to supply a string to a client without compromising the integrity of the server.



  • @j6cubic said:

    @PG4 said:
    I've seen plenty of places were ftp is used to pickup or push a file with a known name, ls would not be needed.  If the sysadmins set the account up to be chroot-ed, and didn't follow up with making copies of ls into all the accounts, then you would get exactly what was seen, no WTF at all.
    In this case I'd humor the client who needs ls by either adding it for them, or (in case this is demed too dangerous) adding a script that simply returns the name of the one file in the directory. I'm pretty sure that it's possible to supply a string to a client without compromising the integrity of the server.
     

    Right, the problem here is that we don't know the exact name of the file.  The file being created has the date in the file name (not by my choice, vendor demanded and I am not the PM lol) so I need to be able to see what files the vendor has dropped.  Not a huge WTF I agree, but it just seemed silly that they would use "security" as the reason for not allowing peolpe to use ls.  Also, they allow you to use the 'ls' command on their SFTP site but not their FTP site...  



  • @amischiefr said:

    Also, they allow you to use the 'ls' command on their SFTP site but not their FTP site...

    Well of course - SFTP is secure and everyone knows FTP isn't ;)



  • This isn't ideal because there could be a huge load of crap in their directory, but couldn't you get around their silly rule by using mget and just grab everything that's there?

    It would teach them, too, if you happened to get confidential data meant for other customers, or proprietary internal-use-only data because you had to get around their silly rule about the ls command.



  • @jetcitywoman said:

    This isn't ideal because there could be a huge load of crap in their directory, but couldn't you get around their silly rule by using mget and just grab everything that's there?

    It would teach them, too, if you happened to get confidential data meant for other customers, or proprietary internal-use-only data because you had to get around their silly rule about the ls command.

    mget uses the NLST command to pull the list of files to request.  If NLST isn't allowed by the server, mget won't work either. 



  • @PG4 said:

    It very common, at least on UNIX to setup FTP accounts to be chroot-ed.  This means that the default dir you drop them in now becomes / and they can't go any higher.  It keeps people from getting into places they shouldn't be.  The only problem is a lot of FTP servers on UNIX at least exec out to run the ls command.

     But the ls command is in /bin and you can not longer get to the real /bin.  So into order for it to work you have to make a copy in a bin directory under the chroot point.  And on top of hat if ls requires any shared libs, you need them also.

    I've seen plenty of places were ftp is used to pickup or push a file with a known name, ls would not be needed.  If the sysadmins set the account up to be chroot-ed, and didn't follow up with making copies of ls into all the accounts, then you would get exactly what was seen, no WTF at all.

     

    And this, my friends, is TRWTF.



  • Well, the obvious solution is to try to check all possible filenames by brute force alpha/numeric/specialchar guessing, running through all possible combinations until you find what is actually on there.  Then they'll be happy they are still so "secure" and you'll have the same results -ls would give you.



  • @operagost said:

    @PG4 said:

    It very common, at least on UNIX to setup FTP accounts to be chroot-ed.  This means that the default dir you drop them in now becomes / and they can't go any higher.  It keeps people from getting into places they shouldn't be.  The only problem is a lot of FTP servers on UNIX at least exec out to run the ls command.

     But the ls command is in /bin and you can not longer get to the real /bin.  So into order for it to work you have to make a copy in a bin directory under the chroot point.  And on top of hat if ls requires any shared libs, you need them also.

    I've seen plenty of places were ftp is used to pickup or push a file with a known name, ls would not be needed.  If the sysadmins set the account up to be chroot-ed, and didn't follow up with making copies of ls into all the accounts, then you would get exactly what was seen, no WTF at all.

     

    And this, my friends, is TRWTF.

    What now?  This is fairly standard for chroot'd programs.  If a daemon has its root directory changed by the kernel to some directory that is far below the normal root, then it will not have access to the regular system binaries.  They will either have to be copied or null-mounted if the daemon needs access to them. 


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.