The Ferret sniffer and insecure security software

There’s a new sniffer called Ferret that’s gotten some people excited, although I think that the point has, as it often does, sailed completely over most people’s heads. The presentation, on the topic of “Data Seepage”, is also available at that link, and it looks like it made for a very good talk, especially for the sort of crowd that attends Black Hat Federal. I think that it probably hit its target audience right where that audience is interested.

The sniffer itself, for all the attention it is getting, isn’t really anything special (and I believe that the authors realize this). Now, my disclaimer here is that I have yet to actually run it, although I have browsed the code as part of what I’ll be discussing. It makes for a very good demonstration to show people who have no intention of following what you normally do, and just want to see exactly what sorts of data is “leaked” from typical wireless communications. It serves this purpose well, although I feel that a serious attacker or penetration tester would simply log the sniffed traffic, in order to do a more in-depth analysis offline. So if you play with this (or any) tool, pay attention to what it is doing behind the scenes, how you would work it into your attack or assessment processes, and what kind of processing you could do on the output. You might find that you’re better off with something like scapy that’s more flexible for your needs.

(I might take a look at reimplementing some of what Ferret does in scapy for a future post)

Another interesting point is how this demonstrates something that is surprisingly common: Security software, especially of the “hacker”/attack flavor, is often some of the least securely coded software you can find. Much of it is “frankensteined” together out of various pieces of code that were only meant to be illustrative proofs of concept (as in this case), and is often so focused on a goal (as with most exploits) that it throws caution to the wind and makes lots of assumptions about user and network input. I know I’m very guilty of this.

There were a couple of potential vulnerabilities in this sniffer discussed on the DailyDave list earlier today, the first one of which I determined to not be exploitable (due to a boundary check elsewhere). The second was a definite coding error ( “sizeof(array-1)” versus “sizeof(array)-1″ ), which is probably exploitable somehow. I am sure there are other problems, however, and this illustrates something you should always remember: If you’re running software like this, be aware of the risk of crafted traffic exploiting your logging/analysis tools. This is especially the case in software like Ferret (…and Snort, Wireshark, etc.) that has to implement protocol dissection. There’s a lot of fields and special cases to get wrong!

Also, verify the vulnerabilities you find in software, in your rush to be the first to post that you owned it in 60 seconds ;) ,

Edited to amend my take on the second vulnerability as “probably exploitable” ;)