Remote shell $ nc target 6666 We’ve got a remote shell with the privileges of the user we logged in as. If we want a rootshell, we just bring a privilege escalator with us… (Credits to SUID and Securiteam)

Joy. This exploit is harder to pull off on an anonymous login, but possible. It’s tougher to pull off, mostly because we’re chrooted without far to go, with only user ftp. We can use this to defend normal user access.

Avoidance We can avoid this exploit by configuring the FTP daemon to disallow tarring/compression. We can also make sure that anonymous users can’t retrieve the files that they place on the server. Files to be downloaded again should probably be examined individually. Finally, we’ll look at a path filter later in this talk.

Avoidance This is in the globbing code, which we can’t shut off. There are no permissions checks on files or other settings that we can tweak. Since an authenticated session is required, the only way to avoid this is to prevent the attacker from logging in.

Containment If we’re running only an anonymous FTP server, we can set inetd/xinetd to always run it as user ftp, forcing anyone logging in to get only user ftp and to possibly get stuck in a chroot.

Site_Exec WU-FTPd had a serious format string vulnerability in the SITE EXEC functionality. Even from simple anonymous access, this got you all the way to root. http: //online. securityfocus. com/bid/1387

Containment Chrooting won’t stop the attacker if he’s root. Root can break out of chroots on many operating systems. Don’t trust the app to drop privilege – try to never give it extra privilege to drop. The exploit uses setuid(0) then breaks chroot.

Message Buffer Overflow WU-FTPd optionally offers messages when you login, change directory, trigger an error condition, … As a feature, these can include a number of “magic cookies, ” which WU-FTPd will substitute for, like: %R – client hostname %N – number of users in a class

Message Buffer Overflow There’s a buffer overflow condition in WU-FTPd’s handling of these. http: //online. securityfocus. com/bid/726 This can be exploited to give root, if an attacker can write a message file.

Are we vulnerable? On the positive side, most sites don’t use these by default. Then again, let’s look at a popular default /etc/ftpaccess file: # Messages displayed to the user message /welcome. msg login message cwd=* Problem: if an attacker can write to any directory that doesn’t have a. message file yet, he wins. (Spot the other one? )

Avoidance We can avoid this by not letting an attacker write to any directory. If this isn’t possible, we can block him from writing to any file that begins in a “. ” Finally, we can make sure that the FTP area has good permissions on its root directory.

Avoidance path-filter real, guest, anonymous /etc/ftperror ^[-A-Za-z 0 -9. _]*$ ^. ^- For any file to get through, it must match the first pattern and not match any of the following. Note that this stops both the message exploit here and the earlier tar vuln.

More Avoidance We can also remove all the messages from our configuration file, though this is difficult, since they’re pervasive. Finally, we can make sure that anonymous users can’t upload files. If we have real users, though, it gets difficult.

Containment Avoidance is really better here, but we can definitely try to contain the damage. We can contain the damage by running an anonymous-only FTP server, set by inetd/xinetd to always run as a nonroot user. Remember, anonymous FTP is automatically chrooted.

Go Beyond ftpusers The traditional way of making sure that only real humans used ftp, and not system accounts, was to periodically make sure all non-humans were in /etc/ftpusers. Now, just do this in ftpaccess: deny-uid %-499 deny-gid %-499 allow-uid ftp allow-gid ftp (replace 499 w/ max non-human uid/gid here)

Worms and Autorooters On top of all this, there are worms and mass/auto rooters which automatically scan for and exploit vulnerable systems. The Honey. Net project had a system scanned and compromised by a worm within 92 seconds of it coming online.

Guest access The server chroots to /home/ftp, then places jay in the /jay directory there. The /home/ftp area must be set up for the full chroot, with all binaries, libraries… that the FTP server would need.

Guest access Since we’ll have other users: /home/ftp/jay /home/ftp/toby /home/ftp/brian We’ll use a directive to keep them from exploring each other’s home directories: restricted-user %500 -

Guest access Setting up /home/ftp: //ftp. wu-ftpd. org/pub/wuftpd/guest. HOWTO Easy if you’re already offering an anonymous area, since that was a chroot!

Additional Cool Idea l Run this as a virtual server, so that an automated by-IP scanner can’t touch the server most of the time. l The attacker has to interact with the server by name.

Virtual Server l You can even have a separate password file, such that your users have separate e-mail passwords.

Alternatives to WU-FTPd l You can also avoid the pain of trying to dodge or contain all the ftpd root vulns. l Pro. FTPd has a slightly better security history. l Open. BSD’s ftpd has a bad security history.

vsftpd l vsftpd actually has never had a security issue. l vsftpd doesn’t use external programs like ls and tar. Remember that our first vulnerability came from WUFTPd using tar!

Alternatives to FTP Even better, get away from FTP! HTTP for anonymous file distribution. SFTP (SSH) for authenticated file movement.

Go Change Your Environment! Too many times, someone attends my talk and sets “harden my servers” as a low priority/procrastination point. Then they call me later when they get hacked to do forensics or to help them harden after they do a complete rebuild. If you can, please fix it now, before the next attack.

Def. Con Talks I’ll be speaking at Def. Con on how to harden Apache servers and on the Bastille Project, which tightens Linux and HP-UX systems.