TAG | Cisco
0 Comments | Posted by Christopher Werny
some of you may have seen my last blog post about the preparation of the Troopers network. Today I want to give you a little teaser on what to expect for the talk I will present during the IPv6 Security Summit. As the title implies, it’s not only about building a secure IPv6 WiFi, but also a reliable one. One might think that there aren’t many differences in comparison to IPv4, but the heavy reliance on multicast of IPv6 does have implications for Wi-Fi networks in general. (more…)
I am currently preparing the Troopers network in a lab environment to ensure that we all will have a smooth Wi-Fi experience during Troopers. I wanted to spice things up a little bit for the Wi-Fi deployment (more on that in a following blogpost) and get rid of IPv4 wherever possible. Our Wi-Fi infrastructure consists of typical Cisco Access Points (1602) and a 2504 Wireless LAN Controller. Beginning with WLC image 8.0 it is finally supported to establish the CAPWAP tunnel between the AP and the WLC over IPv6, which is awesome and I wanted to implement it right away. (more…)
3 Comments | Posted by Niklaus Schiess
this is a short write up about the Maintenance Operation Protocol (MOP), an ancient remote management protocol from the DECnet protocol suite. It’s old, rarely used and in most cases not needed at all. But as we stumbled across this protocol in some network assessments, it seems like a lot of network admins and other users don’t know about it. Even various hardening guides we’ve seen don’t mention MOP at all.
0 Comments | Posted by Christopher Werny
Given that Enno and I are network geeks, and that I am responsible for setting up the Troopers Wifi network I was curious which components might be used at Cisco Live and which IPv6 related configuration was done for the Wifi network to ensure a reliable network and reduce the chatty nature of IPv6. Andrew Yourtchenko (@ayourtch) already did an amazing job last year at Cisco Live Europe explaining in detail (at the time session BRKEWN-2666) the intricacies of IPv6 in Wifi networks, and how to optimize IPv6 for these networks. He was also a great inspiration for me when setting up the Troopers Wifi network a couple of weeks later. Thank You!
2 Comments | Posted by Daniel Mende
Recently we started playing around with Cisco’s virtual router, the CSR 1000V, while doing some protocol analysis. We found Cisco offering an BIN file for download (alternatively there is an ISO file which contains a GRUB boot loader and the BIN file, or an OVA file which contains a virtual machine description and the ISO file) and file(1) identifies it as DOS executable:
$ file csr1000v-universalk9.03.12.00.S.154-2.S-std.SPA.bin csr1000v-universalk9.03.12.00.S.154-2.S-std.SPA.bin: DOS executable (COM)
We didn’t manage to get the file running, neither in a (Free-)DOS environment, nor in a wine virtual DOS environment, except using the boot loader from the ISO file. So we became curious as for the structure and ingredients of the file.
Within the last months I had some time to work on my code and today I’m releasing some of that: a new version of dizzy as well as two new loki modules.
Recently we took a look on Ciscos XMPP client, called Cisco Jabber. The Client is used in combination with Ciscos Unified Communication Server (CUCM) and Ciscos Unified Presence Server (CUPS). Only the latter one is used for XMPP communication.
We built a small lab setup with this components (CUCM, CUPS and the Win7 Client) and watched the client working. (more…)
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…)
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,