HTTP, FTP, & IPS: YMMV

The other day, I was looking up some information on the Samba project and how they went about initially decoding and implementing SMB, and came across the Myths about Samba page. You'll notice that it looks like most any other web page. Nothing too exciting.

When I passed the link on in an IM, though, I noticed that this Samba document was not, in fact, being served by HTTP, but FTP. I double checked, and sure enough, my browser was quite happy to render the HTML elements. P and H tags, some BReaks, etc. Though I never really put much thought into it before, it turns out that my browser doesn't care if it gets HTML pages over HTTP or FTP.

So, I did what any protocol nerd would do, and I whipped together a page that exercises the usual gamut of HTML markup, and dropped it on an anonymous FTP server. It has some HTML, some Javascript, an ActiveX control, and an embedded Flash movie, all without a single http URI handler (check it here). It all renders just fine. To make sure my browser wasn't performing some protocol prestidigitation under the hood, I confirmed my traffic in Wireshark, and saw a typical passive FTP session.

Client (C) ---- connect -------> FTP Server (S)
(C) <---- 220 FTP Banner ------------------ (S)
(C) ----- USER anonymous -----------------> (S)
(C) <---- 331 OK -------------------------- (S)
(C) ----- PASS mozilla@example.com -------> (S)
(C) <---- 230 Logged in ------------------- (S)
(C) ----- SYST ---------------------------> (S)
(C) <---- 215 UNIX Type ------------------- (S)
(C) ----- PWD ----------------------------> (S)
(C) <---- 257 "/" is current directory.---- (S)
(C) ----- TYPE I -------------------------> (S)
(C) <---- 200 OK -------------------------- (S)
(C) ----- PASV ---------------------------> (S)
(C) <---- 227 Entering Passive Mode... ---- (S)
(C) ----- SIZE filename.html -------------> (S)
(C) ===== connect =======> FTP Data Channel (D)
(C) <---- 213 8535 ------------------------ (S)
(C) ----- RETR filename.html -------------> (S)
(C) <---- 150 Opening BINARY mode data... - (S)
(C) <==== File data ========================(D)
(C) <---- 226 Transfer Complete ----------- (S)
(C) ===== Session Close ==================> (D)

I'm sure you see where I'm going with this: This means all the browser exploits you've heard of will also work just fine over FTP. All your ActiveX buffer overflows, all your image parsing bugs, all your scammy spyware drive-by download sites, they're all perfectly at home in FTP-land.

Now, for browsers, this isn't that big of a deal. Browser patches tend to fix problems with the rendering engine anyway, and don't care that the offending file got here over HTTP, FTP, a local file read, Gopher, or whatever. The same goes for typical browser security features. Web proxies will tend to also proxy passive FTP, browser add-ons like NoScript and Flashblock don't worry about the transport protocol, and Internet Explorer's trust zones don't distinguish between HTTP and FTP sites in a given domain.

But for IPS and IDS, this is kind of a big deal. Most network inspection devices require either port correctness -- in this case, something like port 80 -- and/or protocol correctness -- like an HTTP 200 message signaling the start of an HTML download. Neither of these are present for FTP-transported client-side attacks. Passive FTP occurs on a port chosen at random (well, sort of -- more on that in another blog post), and there's no preamble to the download on the data session (the RETR command happens on the command channel). So, in order to catch these browser attacks, an inspection device would need to be performing deep inspection on all packets, or have anticipated this evasion by keeping state for all FTP sessions to be able to follow along with the right data session port number.

Neither of these are impossible, of course. Maybe your IDS or IPS is ahead of the curve and accurately picks out browser attacks delivered via FTP. Lucky for BreakingPoint customers, they can find out how your IPS stacks up against an FTP-delivered attack -- the last StrikePack has a new category of "Browser FTP" strikes. Therein, customers will find 146 Internet Explorer strikes which have been ported over from HTTP to FTP. If you're relying on IPS to help buy some time for your unpatched browsers, you might want to see how it stands up to the HTTP vs FTP versions of these strikes.