Subject: [IPFIX] Vulnerabilities in Flow Meters

From: Tobias Limmer <[email-masked]>
Date: Tue, 7 Apr 2009 14:18:54 +0200

Hi all,

flow meters usually employ hashtables for efficient flow aggregation.  
We analyzed possible vulnerabilities of two software-based Netflow/ 
IPFIX flow meters, nProbe and Vermont, from an attacker's perspective  
and discovered some major problems.

We found out, that hash functions used in these hashtables are easily  
exploitable. So attackers are able to decrease the meter's performance  
drastically and cause packet drops on purpose. More detail is provided  
in the technical report [1].

Now my question to this list: Has anyone already investigated this  
problem? What about hardware-based flow meters such as Cisco boxes? My  
guess is that these are vulnerable, too. Could you provide any  
information about that topic?

Thanks & bye,
Tobi

[1]
<http://www7.informatik.uni-erlangen.de/~limmer/publications/inc/eckhoff2009attacking-abstract.shtml 

--
Dipl.-Inf. Tobias Limmer
Computer Networks and Communication Systems
University of Erlangen-Nuremberg, Germany
Phone: +49 (9131) 85-27931  Fax: +49 (9131) 85-27409
eMail: limmer .at. informatik.uni-erlangen.de
WWW:   http://www7.informatik.uni-erlangen.de/~limmer

---

From: Paul Aitken <[email-masked]>
Date: Tue, 07 Apr 2009 13:29:12 +0100

Tobi,

> What about hardware-based flow meters such as Cisco boxes? My guess
> is that these are vulnerable, too. Could you provide any information
> about that topic?

Rephrased, "can you tell me how to break a cisco box" ? :-(

I'm sure we can discuss details of our implementation under NDA.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 07 Apr 2009 14:43:48 +0200

> I'm sure we can discuss details of our implementation under NDA.

Which is also the reason why breaking it will be difficult: figuring out
the problem in the hash is near impossible, as the general population
doesn't have the source/design. As such these kind of implementations
will be mostly safe.

But what is the problem with all of this? Everybody knows that at one
point in time one can DoS a certain point in a network, be it filling up
the link or some flow table. Depending on what you want to attack, you
pick the point where it breaks first.

If you are using software-based flow monitors then you are already at a
loss as they won't be able to keep up with 10GE, and most botnets can
easily sustain that multiple times.

The testing in that 'report' where done on 100mbit links, take a guess
how long it takes to fill those up with real truely valid data. The
problem in this setup is the probe itself, not the fact that an "attack"
is being made. Those things will probably not even survive a slashdot...

Thus what are you protecting when this attack happens and what is it
that you want to see?

Greets,
 Jeroen

---

From: Florian Weimer <[email-masked]>
Date: Mon, 20 Apr 2009 11:18:14 +0200

* Tobias Limmer:

> problem?

In 2003, I've asked a few vendors to look into this when I discovered
a similar issue in the Linux route cache (which has been more or less
fixed by using a keyed hash based on Jenkins' design).

fprobe and a few other code bases in use at that time were affected,
too.  softflowd is not affected.

> <http://www7.informatik.uni-erlangen.de/~limmer/publications/inc/eckhoff2009attacking-abstract.shtml 

Crosby and Wallach have collected quite a few references to similar
vulnerabilities: <http://www.cs.rice.edu/~scrosby/hash/>

IIRC, the general issue is also mentioned in one of the classic
algorithms textbooks, but I forgot which one.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99