TAG | VoIP
I am little bit late to the party, but I had the pleasure to present a talk about VoIP based toll fraud incidents (more on this in a following blogpost, for the moment my slides can be found here) at the annual t2 security conference in Helsinki. The conference took place from 24th to 25th October in the Radisson Blu Royal hotel. I must say that it was a blast. Tomi (the host) took really good care of all speakers, and I really liked the spirit of the conference, very similar to Troopers. It is not an commercial event, seats are limited to 100 and it is all about delivering a great set of talks to the audience and having a good time during and after the conference. Sure the conference has some sponsors and tickets are sold, but Tomi doesn’t do it to earn money. His only intention is to cover the cost for setting up this great event.
Hi again and a happy new year 2013!
Lets continue were I left you the last time.
The CTL is basically a binary TLV file with 1 byte type, followed by 2 bytes length and finally the data. But as this is far to easy, some special fields omit the length field and just place the data after the type (I guess those are fields with a fixed length). Here is an example CTL file:
Red fields are the types (counting up), green fields are the length (note the missing length on some fileds) and the purple field contains the data (in this case data with a length of 8 bytes and a type 0x05, which is the signing cert serial number btw. [and yes, this is a real example; Cisco signs phone loads with this ‘random’ cert]).
The CTL contains a header with types from 0x01 to 0x0f which is padded with 0x0d. The same header is used for the signed files .sgn from the TFTP server later on. The header describes the file version, the header length, the certificate the file is signed by (further called Signing Cert), the corresponding Certificate Authority, the file name, the files time stamp and finally the signature. The header is followed by multiple cert entries, which again use types 0x01 to 0x0f. The cert entry contains a role field 0x04 which describes the use of the cert. We are interested in the CAPF cert (0x04) and the Call Manager cert (0x02).
0 Comments | Posted by Daniel Mende
Some of you may have heard the topic before, as we have spoken about on this years BlackHat Europe, TROOPERS12 and HES12, so this is nothing completely new, but as we’re done with responsible disclosure (finally (-; ) and all the stuff should be fixed, we’re going to publish the code that brought us there. I will split the topic into two blog posts, this one will wrap up the setup, used components and protocols, the next one [tbd. till EOY, hopefully] will get into detail on the tools and techniques we used to break the enterprise grade security.
First lets take a look on all the components involved in the setup:
As you can see in the picture, there are a lot of components and even more certificates involved. From left to right: (more…)
Cisco has released a security advisory for a vulnerability we discovered last year.
For comparison here is our original advisory to cisco:
Security Advisory for Cisco Unified Communications Solution
Release Date: 11/8/2012
Author: Daniel Mende
Multiple critical SQL injections exist in Cisco unified meeting place.
2 AFFECTED PRODUCTS
The following Products have been tested as vulnerable so far:
Cisco Unified Meetingplace with the following modules:
• MeetingPlace Agent 22.214.171.124
• MeetingPlace Audio Service 126.96.36.199
• MeetingPlace Gateway SIM 188.8.131.52
• MeetingPlace Replication Service 184.108.40.206
• MeetingPlace Master Service 220.127.116.11
• MeetingPlace Extension 18.104.22.168
• MeetingPlace Authentication Filter 22.214.171.124
The following parameters are affected:
http://$IP/mpweb/scripts/mpx.dll [POST Parameter wcRecurMtgID]
4 VULNERABILITY SCORING
The severity rating based on CVSS Version 2:
Base Vector: (AV:N / AC:L / Au:S / C:P / I:P / A:P)
CVSS Version 2 Score: 6.5
5 PROOF OF CONCEPT
POST /mpweb/scripts/mpx.dll HTTP/1.1
Accept-Encoding: gzip, deflate
&wcMeetingID=&wcRecurMtgID=‘ or 1=1 —&URL0=wcBase.tpl&TXT0=Startseite&URL1=&
As we are at the topic of Cisco’s Unified Communications Solution, there is a lot more in the queue to come up, just be patient a little longer, it’ll be worth it (-;
0 Comments | Posted by Enno Rey
if you’re following this blog regularly or if you’ve ever attended an ERNW-led workshop which included an “architecture section” you will certainly remember the “Seven Sisters of Infrastructure Security” stuff (used for example in this post). These are a number of (well, more precisely, it’s seven ;-)) fundamental security principles which can be applied to any complex infrastructure, be that a network, a building, an airport or the like.
As part of our upcoming Black Hat and Troopers talks we will apply those principles to some VoIP networks we (security-) assessed and, given we won’t cover them in detail there, it might be helpful to perform a quick refresher of them, together with an initial application to VoIP deployments. Here we go; these are the “Seven Sisters of Infrastructure Security”:
- Access Control
- Entity Protection
- Secure Management
Now, let me discuss them in a bit more detail and put them into a VoIP context.
Access Control (“try to keep the threats out of the environment containing the assets to be protected”)
This should pretty much always be an early consideration as limiting access to “some complex infrastructure” obviously provides a first layer of defense and does so in a preventative way. Usually authentication plays a major role here. Please note that in computer networks the access control principle does not only encompass “access to the network [link]” (where unfortunately the most prevalent technology – Ethernet – does not include easy-to-use access control mechanisms. And, yes, I’m aware of 802.1X…) but can be applied to any kind of (“sub-level”) communication environment or exchange. Taking a “passive-interface” approach for routing protocols is a nice example here as this usually serves to prevent untrusted entities (“the access layer”) from participating in some critical protocol [exchange] at all.
In a VoIP scenario limiting who can participate in the various layers and communication exchanges, be it by authentication, be it by configuration of static communication peers for certain exchanges (yes, we know this might not scale and usually has a bad operational feasibility) would be an implementation of the access control principle.
Isolation (“separate some elements of the environment from others, based on attributes like protection need, threat potential or trust/worthiness”)
In computer networks this one is usually implemented by network segmentation (with different technologies like VLANs or VRFs and many others) and it’s still one of the most important infrastructure security principles. I mean, can you imagine an airport or corporate headquarters without areas of differing protection needs, different threat exposure or separate layers and means of access? [You can’t? So why do you think about virtualizing all your corporate computer systems on one big unified “corporate cloud”? ;-)]
Again, it should be noted that “traditional network segmentation” is only one variant. Using RFC 1918 (or ULA, for that matter) addresses in some parts of your network without NATing them at some point, or refraining from route distribution at some demarcation point constitute other examples.
In the VoIP world the main realization of the isolation principle is the commonly found approach of “voice vs. data VLAN[s]”.
Restriction (“once [as of the above principle] isolated parts get connected try to limit the interaction between those parts at the intersection point”)
This is the one most people think of when it comes to network security as this is what the most widely deployed network security control, that is firewalls, is supposed to do.
Two points should be noted here, from our perspective:
In some network security architecture documents phrases going like “the different segments are [to be] separated by firewalls” can be found. Which, well, is a misconception: usually a firewall connects networks (which would be isolated otherwise), it does not separate them. It may (try to) limit the traffic passing the intersection point but it still is a connection element.
And it should be noted that the restriction it applies (by filtering traffic) always has an operational price tag. Which is the one of the reasons why firewalls nowadays tend to fail so miserably when it comes to their actual security benefit…
Still it should be noted – again – that it has an operational price tag (key management and the like). Which – again – is the very reason why it sometimes fails so miserably when it comes to providing actual security…
This encompasses all measures intended to increase the security of individual elements. It’s not limited to simple hardening though, but includes all other “security [posture] quality assurance” things like pentesting or code reviews (when the element looked at is an application).
Adding a comment again I’d like to state that, in times of virtualization and vaporizing security layers (deploying shiny apps pretty much directly connecting customers to your ERP systems, by means of fancy webservices) this one might become more and more important. In the past many security architectures relied on layers of isolation & restriction and thereby skipped the hardening/quality assurance step (“we don’t have to harden this Solaris box as there’s a firewall in front of it”). As the talks’ case studies will show this one is a fundamental (and overlooked) one in many VoIP deployments.
Secure management usually can be broken down to:
- Restrict the endpoints allowed to establish management connections.
- Either use a trusted environment (network link) or use secure variants of mgmt. protocols instead of their less secure counterparts (SSH vs. Telnet, HTTPS vs. HTTP, SNMPv3 vs. community-based SNMP and the like).
- Require sufficient authentication (as for methods, authenticator [e.g. password] quality, personalized accounts etc.).
- Logging of security related events and potentially all management actions performed.
While this is (should be) an obvious security principle, daily assessment experience shows that failures/weaknesses in this space account for the majority of critical vulnerabilities when it comes to infrastructure security. This applies in particular to VoIP implementations (see the case studies for examples).
This is where logging (+ analysis), monitoring etc. come into play. We’d like to note that while this is a valid infrastructure security principle, its actual security benefit is often overestimated given the “detection/reaction” nature of this principle and its subsequent bad operational feasibility.
As the above application to VoIP shows, these fundamental security principles allow for tackling any type of “securing assets within a complex overall setting” by going through a simple (checklist-type) set of questions derived from them. These questions could look like
- Can we limit who’s taking part in some network, protocol, technology, communication act?
- Any need to isolate stuff due to different protection need, (threat) exposure or trust(worthiness)?
- What can be done, filtering-wise, on intersection points?
- Where to apply encryption in an operationally reasonable way?
- What about the security of the overall system’s main elements?
- How to manage the infrastructure elements in a secure way?
- How to provide visibility as for security-related stuff, with reasonable effort?
 As it requires the usually most scarce resource of an organization, that is humans and their brains. The part that can not be easily substituted by technology…
 In general preventative controls have a better cost/benefit ratio than detective or reactive ones. And this is still true in the “you’ll get owned anyway that’s why you should spend lots of resources on detective/reactive controls” marketing hype age…
 To provide another example from the routing protocol space: the “inter-operator trust and TCP-” based nature of BGP (as opposed to the “multicast and UDP-“based nature of other routing protocols) certainly is one of the most fundamental stability contributing properties of the current Internet.
1 Comment | Posted by Christopher Werny
it’s me again with another story of a toll fraud incident at one of our customers (not the same as the last time of course ;-)).
The story began basically like the last one: We received a call with an urgent request to help investigating a toll fraud issue. Like the last time I visited the site in order to get an idea on what was going on exactly. The customer has a VoIP deployment consisting of the whole UC Suite Cisco offers: Call Manager, Unity Connection for the voice mailboxes, Cisco based Voice-Gateways and of course, IP phones.
During the initial meeting I was told that the incident had taken place over the weekend, and had caused a bill of almost 100.000€ during this time period. Similar to the other incident, described two weeks ago , our customer didn’t discover it by himself but again the Telco contacted him beacause of that high bill. After the meeting I got ready to work my way through a whole bunch of log- and configuration files to analyze the situation. Spending 1 ½ days on the customer site to analyze the issue, I was able to reconstruct the incident. As stated earlier, the customer uses Cisco Unity Connection as voice mail application. Unity is reachable over a specific telephone number so that employees are able to listen to voice mail messages if they are on the road . When dialing this specific number, one has to enter the internal extension followed by a PIN for authentication. It turned out, that someone had brute forced one of the mailboxes PIN.
So how could this toll fraud issue happen by just bruteforcing the PIN of a mailbox? After successful authentication though the PIN, one is also able to configure a transfer of a call to a telephone number of your choice. Now it should become clear, where this is going…
After the bad guys retrieved the valid PIN, they configured a call transfer to some $EXPENSIVE_LONG_DISTANCE_CALL. In addition they changed the PIN in order to access the system whenever needed. As the issue started on a Friday evening (when almost everybody had already left for the weekend) nobody noticed the compromise of the mailbox. The bad guys logged in about 200 times during the weekend and configured different numbers to which the calls should be transferred. They started with some numbers located in African countries, which wasn’t successful because the configuration of the Call Manager blocked outgoing calls to such suspicious countries.
So, how could they initiate the calls nevertheless? These guys were smart. After realizing that the first approach wasn’t working they found a clever way to circumvent the restriction. They just used a so called “Call-by-Call” Provider. To use such a provider you have to prepend a provider specific prefix to the number. E.g. one prefix of a German provider is 010049. So they dialed 010049+$EXPENSIVE_LONG_DISTANCE_NUMBER and were able to circumvent the restriction on the Cisco Call Manager.
The first question which came to my mind was: Why can Cisco Unity initiate outbound calls? Well, according to our customer, there were some requirements that Unity should contact some home workers on their normal phone that new messages are present. In order to stop the potential exploit on short notice, we first configured the Call Manager denying Unity to initiate outbound calls. After digging into the configuration of Unity Connection and the Call Manager I found some configuration on the Unity connection box which enabled the attacker an easy game.
- The PIN was only 4 digits long.
- Unity Connection did not prevent the use of trivial PINs like „0000“ or „1234“.
- There was no restriction on to which number a call transfer could be configured.
- The ability to configure a call transfer over the Phone Interface is at least debatable.
These properties are a little unfortunate as Unity connection gives you all the tools you need to address the issues mentioned above. However, in this scenario the config had not been handled appropriately. So this case could basically be broken down to configuration weaknesses which favored the attacker to exploit the issue. Like in the last incident , the initial deployment and configuration was done by an external Service Provider.
So how can we assure that this won’t happen again?
- Use longer PINs. I recommended that the PIN should be at least 6 digits, which increases the number range you would have to bruteforce significantly, causing the attacker requiring up to 100 times as long for the attack! The password policy for the mailbox is configured in a so called authentication rule, where one can define all sort of things as for the mailbox password. In this authentication rule it was just one click to disable the use of trivial PINs.
- In Unity Connection, one can configure so called restriction tables to define to which numbers a call can be transferred. In the default installation there are some predefined restrictions, which didn’t work with the number plan of this particular customer.
- I recommended evaluating the need for configuration of call transfers over the phone, along with the advice to disable this functionality if not necessary.
All in all it is not rocket science to configure Unity Connection in a secure way, which unfortunately doesn’t mean you won’t find all kinds of scary misconfigurations. All the years at ERNW showed me this impressively.
As already said : It can cost you quite a lot of money if you do not take precautions to prevent that kind of incidents in the first place. So if you own the mentioned products (or plan on integrating them in your environment) check the configuration to ensure something like this won’t happen to you 😉
And one more thing: If you are interested in more VoIP security coverage don’t miss out Troopers 2012 where Enno and Daniel will give a talk on how to compromise the Cisco VoIP Crypto Ecosystem.
Have a great day,
One of our customers called us recently and asked for some support in investigating a toll fraud issue they encountered in one of their sites. Their telecommunications provider had contacted them informing them that they had accumulated a bill of 30.000€ over the last ten days.
Without knowing anything more specific, I drove to the affected site to get the whole picture.
They have a VoIP deployment based on Cisco Unified Communications Manager (CUCM, aka Call Manager) as Call Agent. The CUCM is connected via a H.323 trunk to a Cisco 2911 ISR G2 which is acting as a voice gateway. The ISR has a primary rate ISDN (PRI) Interface which is connected to the PBX of the telco. Furthermore they use a feature called Direct-inward Dial (DID) or Direct Dial-in (DDI) which is offered by Telco’s to enable calling parties to dial directly to an extension on a PBX or voice gateway.
Basically one then has a so called head number (in networking terms a prefix), together with some phone extensions. When someone from outside wants to call, he dials the head number + phone extension. Before the telco forwards the call to the ISR, the head number is stripped and only the phone extension number is forwarded to the voice gateway. E.g. when calling 12345-678, the local voice gateway will only see the 678 as called number.
After having a good overview of the design, I started to dig around in the log and configuration files to understand what exactly happened and why.
So here is what happened:
Apparently someone from some East European country had called the head number of our customer and prepended a “malicious number” (in some country in Africa) to which the ISR should setup a call. The ISR only sees the malicious (African) number because, as said before, the head number was stripped by the telco. The malicious number was of course some $EXPENSIVE_LONG_DISTANCE_CALL ;). So the voice gateway received a call from the PBX and forwarded it back to setup the call with that number.
Before we proceed, a little bit of theory how a Cisco router decides how to forward a call, might be helpful:
In Cisco IOS, the call-routing table is configured based on so called dial-peers. These dial-peers specify how a call with a specific destination number should be forwarded.
As an example:
dial-peer voice 1234 pots description ===incoming_calls=== incoming called number ^[2-7]..$ port 0/3/0
This configuration tells the router that calls to a number which matches the regular expression, should be forwarded to port 0/3/0.
As it turns out our customer uses the following dial-peer which is used for outbound calls.
dial-peer voice 5678 pots description ===outgoing calls=== destination pattern 8T port 1/1/1:15 -> The ISDN Interface
The T is a placeholder value which means that any amount of digits can follow the 8. The reason the pattern matches the digit 8 is that this digit must be dialed before the actual number.
Do I have to mention that the malicious number also starts with an 8? 😉
So back to the presumed course of action:
The call with the malicious number hits the router. The router tries to match a configured dial-peer to forward the call. I think you can guess which dial peer matched for the malicious number 😉
So the router sends the call back to the PBX to setup a call to the malicious number. Which is billed to our customer…
We then monitored the situation and applied a workaround (more on this in a minute) and observed what happened. As it turned out, unfortunately the attacker was able to circumvent our workaround. We discovered that is was possible to “dial-in” to the router directly by just calling the head number (as the PBX leaves the called number field empty). E.g. the called number field in the log files looks like this:
The router subsequently provided a line and it was possible to call the number again. Our workaround did only affect incoming calls with the number prepended, but not those where the router is the actual origin of the establishment of the call.
So how can we resolve this issue and stop the toll fraud?
As a long-term solution the configured dial patterns should be reviewed and modified to prevent such things in the future, but – given the overall complexity of the setup – this could not be done overnight.
I am currently working with the customer to develop more suitable dial patterns. I will write a follow up post with the final results when we are finished.
In the mean-time, we developed a temporary workaround to prevent this from happening again:
In Cisco IOS you can manipulate the calling or called-number with so called translation rules and you are also able to reject calls based on the called number. Our customer does not use any extension beginning with 8, so we can drop all calls on the gateway which starts with 8 as called number. So we developed the following translation-rule:
voice translation Rule 11 rule 1 reject /^8+/ rule 2 reject /^$/
voice translation-profile reject_calls translate called 11
Rule number 2 addresses the case when the called number field is empty. We mapped this profile to the dial-peers responsible for the incoming calls and specified that calls with the numbers in the translation rule must be rejected.
dial-peer voice 3456 pots description ===Incoming_Calls=== call-block translation-profile incoming reject_calls call-block disconnect-cause incoming call-reject incoming called-number
Be careful when you develop and implement your dial patterns, as errors in this space can cost you quite a lot of money 😉
VoIP is a complex technology and this complexity can lead to all types of vulnerabilities, as Daniel and Enno are going to show in their talk at Troopers 2012. Toll fraud is still quite common and happens all the time, as you can see in an ERNW newsletter from 2009 covering a similar story from another environment.
On a side note:
The telco told us that our customer is the 8th customer affected by a toll fraud issue in the last two months. According to the telco all eight companies are in the same city, and the initial VoIP deployment at our customer was performed by an external service provider.
Maybe the same service provider has done the deployment in the other companies too…
Have a great day,