IPS Evasion

IPS’ are just fun, aren’t they? Bunch of high-speed pattern matchers with built-in protocol decodes. Well, I built one a while back and got tired after 5 years. There’re only so many signatures you can have in a product before you run out of DFA/NFA space and you have to resort to turning off less important ones (i.e., *ahem* low severity) for the sake of performance. Interestingly enough, performance and security are at cross-roads. The more secure you are, the slower you run. Just the way things works, I suppose.

So I was thinking, wouldn’t it be fun to go over all the advisories that are being released and write about the million ways you can evade an IPS? Let’s start with CVE-2006-5815, which is a ProFTPd buffer overflow in the sreplace function. The vulnerability is when ProFTPd tries and displays the contents of a .message file in any given directory. If the contents are larger than a certain size, then you get a off-by-one buffer overflow and all hell breaks loose. You can read more about this vulnerability here. BTW, this might be categorized in your IPS as “oh-so-2006″ and the signature might be disabled. So check for it first.

Now, nobody in their right mind would artificially create a file with shellcode in it just to trigger the vulnerability and hose themselves. So the file itself has to be under the attacker’s control. So what does one do? Well, upload the malicious file of course. This is done using the STOR verb in the FTP protocol.

So the idea is that we upload the file and then issue a CWD command which forces the FTP server to read and display the contents of the .message file which triggers the vulnerability. The naive IPS signature would of course be “STOR .message” in any line of the FTP protocol. But what are the ways you can evade this?

• Insert spaces in and around the STOR command
• Insert telnet options around each character of the STOR command and the .message filename. Last I checked, WUFTPd ignores telnet options in the control stream.
• Upload some arbitrary file with the exploit and then rename it to .message
• Upload the file first and after some number of days rename it and then issue a CWD command
• If the FTP server supports TLS, then this whole thing can be done over encrypted channels which means the IPS is S.O.L.

The hypothetical real IPS would do the following to properly detect the intrusion.

• Statefully follow the PORT/PASV commands
• This could be done over IPv6 which means the IPS would have to implement/follow/track EPRT and EPSV commands
• Decrypt the connection in case it’s running over TLS
• Cache all file uploads indefinitely
• Watch for the RNFR and RNTO verbs in the FTP signaling stream
• Run the pattern match on the previously uploaded file that’s now being renamed to .message and detect the overflow
• And then finally block this command from ever executing
• Just for good measure, the source IP uploading the file and the IP that executes CWD on the appropriate directory could be completely different. This adds a whole different layer of complexity

Does your IPS do this?