Mobile devices play an important role in the business world. Yet with increased emphasis on the Bring Your Own Device (BYOD) model, defenses are not where they need to be to slow the loss of valuable intellectual property.
Corporate defenses have traditionally focused on the network, the endpoints, and not necessarily on the ecosystem of how these devices interact outside of network sockets. Smartphones bring unique network connectivity, an array of sensors, and can be overlooked by resources invested on IDS/IPS not being effectively leveraged.
Getting to the core of an exemplar attack, a Mobile Remote Administration Tool (RAT) is devastating. With access to the microphone, GPS/network location, camera, and an accelerometer, having control of a mobile device in a corporate setting is a dream for an attacker. We’ve improved an open source RAT and introduced a new feature, the ability to turn the mobile device into a virtual person sitting at the computer, able to type commands into the console.
Using a USB device to gain access to a computer is not new and the dangers of an unprotected port are extraordinary (see upcoming troopers talk, You wouldn’t share a syringe. Would you share a USB port? Bratus & Goodspeed). The takeaway from this particular talk is that the attack need not be performed from a specialized device (Teensy, Facedancer), like a thumb drive. The attack can be mounted from a common device that is routinely plugged into computers for charging or data transfer purposes… the Android mobile phone in your employee’s pocket!
Once again a vulnerability in Apples mobile operating system iOS was found by some guys of the Jailbreak Nation. The newest version of this operating system suffers from a weakness that makes it possible to unlock the lockscreen of all iPhones that use iOS version 6.1. In this case it does not matter whether a PIN or a password is used to unlock the phone. After successful exploitation an attacker is able to see and edit contact-information, to add new contacts to the phonebook, to view all pictures, to call the inbox or any of the contacts and to see and delete the list of recent calls or parts of it. Continue reading “Apple iOS and the history of a workin’ lockscreen… NOT”
Almost every higher class DSLR on the market today features multiple and complex access technologies. To name a few, canons new flagship features IP connectivity wired via 802.3 as well as wireless via 802.11. All the big vendors are pushing these features to the market and advertise them with real time image transfer to the cloud. We have taken a look at the layer 2 and 3 implementations in the CamOS and the services running upon those, so here is what we found while examine the EOS 1D X:
Our new workshop about mobile application testing, held for the 1st time at the Troopers conference 2013, is coming closer. So I would like to take the opportunity and post an appetizer for those who are still undetermined if they should attend the workshop ;-).
While the topic of mobile application testing is a wide field that may contain reverse engineering, secure storage analysis, vulnerability research, network traffic analysis and so forth, in the end of the day you have to answer one question: Can I trust this application and run it on my enterprise devices? So first you have to define some criteria, which kind of behavior and characteristics of an application you regard as trustworthy (or not). Let us peek at malware … besides harming your devices and data, malware is typically:
obfuscated and/or encrypted
contains anti-debugging features
contains anti-reverse engineering features
This makes the analysis process a difficult task and comparing these characteristics especially to ordinary iOS applications from the AppStore, at least one is also true for these apps: Those are encrypted and are only decrypted at runtime on your Apple gadget ;-).
The root cause of the vulnerability is Rails handling of formatted parameters. In addition to standard GET and POST parameter formats, Rails can handle multiple different data encodings inside the body of POST requests. By default JSON and XML are supported. While support for JSON is widely used in production, the XML functionality does not seem to be known by many Rails developers.
XML parameter parsing
The code responsible for parsing these different data types is shown below:
# actionpack/lib/action_dispatch/middleware/params_parser.rb
....
DEFAULT_PARSERS = {
Mime::XML => : xml_simple,
Mime::JSON => :json
}
....
def parse_formatted_parameters(env)
...
when Proc
strategy.call(request.raw_post)
when : xml_simple, : xml_node
data = Hash.from_xml(request.raw_post) || {}
data.with_indifferent_access
when :yaml
YAML.load(request.raw_post)
when :json
data = ActiveSupport::JSON.decode(request.raw_post)
data = {:_json => data} unless data.is_a?(Hash)
data.with_indifferent_access
else
false
end
...
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). Continue reading “All Your Calls Are Still Belong to Us – continued”
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.
The Components
First lets take a look on all the components involved in the setup:
2 AFFECTED PRODUCTS
The following Products have been tested as vulnerable so far:
Cisco Unified Meetingplace with the following modules:
• MeetingPlace Agent 7.1.1.9
• MeetingPlace Audio Service 7.1.1.8
• MeetingPlace Gateway SIM 7.1.1.2
• MeetingPlace Replication Service 7.1.1.9
• MeetingPlace Master Service 7.1.1.8
• MeetingPlace Extension 7.1.1.8
• MeetingPlace Authentication Filter 7.1.1.8
3 DETAILS
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
Severity: Low
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 (-;