First, the devices support some additional restrictions and controls. These controls should be available in most commercial MDM solutions, and can also be found in the iPhone Configuration Utility (IPCU). Among these new controls are the ability to:

• Disable Siri
• Selectively disable iCloud features: Backup, Document Sync, Photo Stream
• Reject SSL sites with untrusted certificates
• Prevent moving messages out of an email account into another
• Prevent use of an email account from 3rd party applications

Additions to the MDM service as a whole include:

• Ability to ask a device to “Check Out” when removed from MDM
• Installing and removing applications (custom and App Store apps)
• Listing managed applications
• Configuration of some settings (Voice and Data Roaming)
• Applying iTunes redemption codes to installation of apps (for Volume Purchase Plan)

I’ve updated my experimental MDM server to support most of these features. I’ve also added some better documentation for the server code, and scripts to help create the necessary server and CA certificates.

Slides from the presentation, as well as the code and the Black Hat white paper and slides, are all available at Github. Enjoy!

We originally followed the post here to get the Ubertooth set up on BackTrack 5, but then had some trouble keeping the device connected and sniffing reliably (similar to our experience with the Proxmark III — sensing a trend here ) After updating the firmware and setting this up on an Ubuntu host, the device works flawlessly. I honestly don’t remember if these are my comments in the commands below or if I found it somewhere on the internetz. I apologize if I stole your commands:

cd ubertooth/trunk/host/bluetooth_rxtx/
./ubertooth-util -f #puts the device in flash mode. lights should blink prettily.
cd ../usb_dfu/
./ubertooth-dfu write /path/to/firmware/bluetooth_rxtx.bin #this is the standard firmware. there are other special ones. suit yourself.
../bluetooth_rxtx/ubertooth-util detach

The “Getting Started” section of the Ubertooth site gives a pretty good idea of what the device can do. We found that the Ubertooth sits on one Bluetooth channel (out of the 87) and sniffs the LAP out of the Bluetooth packets. A little bit on Bluetooth address breakdown (This image is from section 3.2 of this paper):

Bluetooth address breakdown

Bluetooth MAC addresses are comprised of 3 pieces: the Lower Address Part (LAP), Upper Address Part (UAP), and the Non-significant Address Part (NAP). The picture above illustrates this nicely. The Ubertooth can sniff the LAP out of the air, and use the error checking field in the Bluetooth packets to figure out the UAP (ubertooth-lap and ubertooth-nap, respectively).

The NAP (and UAP) are assigned on a per-vendor bases by the IEEE. That means the UAP is available through both the Ubertooth and the IEEE database of NAP+UAP addresses. Using both these resources (and matching up the UAP from both), we can figure out the first 2 NAP bytes pretty quickly! Of course it’s also possible to figure it out if we haven’t calculated the NAP (by appending the LAP to everything we can pull from the IEEE database and ping each one sequentially).

Automating stuff is fun. Here’s my (sloppy) script to figure out the NAP using first the short method, then the long if that one fails: https://github.com/intrepidusgroup/napfinder

This data ranges from boring to concerning. I held back a few that I felt were not responsible to disclose. At any rate, this highlights the dangers of using “cloud services” and not educating employees about the inherent risks this involves. Also, some of this is just plain laziness from those who probably know better.

After assuring Google I was indeed a human about a dozen times, here are the highlights:

• A GitHub Migration Map — Author Unknown
• “esecurity” flow chart
• An org chart with salary information
• The “melvyn” flow chart
• A single sign on app flow
• I don’t even know
• qwest.com current architecture solution
• Lubricant Supply Chain
• “Confidential” Application Design Docs
• Another Org Chart
• A Networking Diagram with Passwords
• UI Mockups
• MyBook General Photo Album Confidential API
• A Really Detailed Internal Business Process
• Marketing Plan With $ Figures
• Some Sort of Business Plan
• Music Studio SEO Strategy
• Facebook Ad Campaign Results
• Fax Numbers in a Payroll Process
• Payroll Email Process – Info Disclose
• Another Org Chart
• Another Internal Network Diagram
• ATM Vendor Proprietary Information
• DoD Stuff
• More DoD Stuff
• Even More DoD Stuff (I hope this stuff isn’t classified)
• Another Internal/External Network Diagram
• Hot Sexy Text Chat Mockup
• Zombie Attack Flow Chart

Also, SOPA and PIPA are bad. Please let your representatives know. See: reddit.com for a nice write up.

@bitexploder, @sorcerer13 and @rossja

Last week, we gave a talk at Immunity’s awesome INFILTRATE conference in Miami Beach, FL. Our presentation, “Voight-Kampff’ing The BlackBerry PlayBook”, discussed some of the black-box style, independent research we performed on the BlackBerry PlayBook. Although some content was similar to our PlayBook talk at SecTor 2011, there were some very notable additions. In particular, we discussed reverse engineering of PlayBook firmware images; flaws in authorization of AppWorld downloads; and exposure of an authorization token used for BlackBerry Bridge (the PlayBook’s PIM and email sync component).

The lattermost point has stirred up a bit of press post-INFILTRATE, so we’d like to clarify a few things:

1. The exposure of the authorization token is facilitated by a bug in the Persistent Publish/Subscribe (PPS) facility of the QNX operating system. This bug causes the contents of otherwise-inaccessible files to be readable from a special file in the same directory. RIM was made aware of this PPS bug as a result of our SecTor talk, as well as notification from others, and again by us prior to INFILTRATE (with special emphasis on disclosure of the Bridge token) — they have fixed this PPS bug in Tablet OS 2.0 (beta).

2. This token exposure effectively renders the BlackBerry handset password moot. The exposed authorization token is accessible after the user has “unlocked” BlackBerry Bridge (where “unlocking” would entail entering the paired BlackBerry device’s password if one is set). Unlocking Bridge is an expected behavior/process for Bridge users. After all, if you’re using Bridge on your device, you’re going to do this. In the case where a BB handset password has not been set, a malicious actor could just request this token from the Bridge service directly.

3. This isn’t “sniffing”. Some highly misinformed comments on news articles have suggested things like “a bad guy would have to be within 10 meters to exploit this.” This issue is not, I repeat not related to Bluetooth (which is used by BlackBerry Bridge). As an aside, despite the title of the article, threatpost has one of the best (press) write-ups so far.

4. The pervasiveness of malicious mobile applications exacerbates this flaw. Unless you’ve been living under a rock, you know that even “savvy” users are frequently duped by seemingly legitimate applications which later turn out to be doing Bad Things. The downplaying of this as an attack vector is nonsense, and the “if dumb users install malicious apps, they deserve whatever’s coming to them” argument is silly. Note that client-side browser or document reader vulnerability could even render this vector moot in the end.

In upcoming posts, we’ll dive a bit deeper into the meat of our research, so stay tuned. For those interested, we have posted the slides at SlideShare, and uploaded some initial code to the Intrepidus Group GitHub page.

You can follow along even without a Fire by grabbing the 6.2.1 software update from Amazon’s site. Download the “bin” file, extract it, then find the “service.jar” framework file. This jar will be in the Android format, so to view this in jd-gui, you’ll want to convert it first (dex2jar works well).

Besides the standard com.android.server package you would expect to see in the service framework file, you’ll also notice there’s a “com.lab126.services” package (Lab126 appears to have done work for a number of Kindle releases). At that point, it’s pretty hard to ignore a class called “EasterEggReceiver”.  There’s not much to this class and nothing has been obfuscated to make it hard to follow. Any application which broadcasts an intent message to the “com.amazon.internal.E_COMMAND” service with the correct extra data can enable the ADB daemon to restart as root. No permissions are needed to send that intent and there are no checks in the framework to see who sent the intent message (like maybe try to limit this to only apps with a certain signature) — simply any Android app on the device can call this backdoor feature.

Dex2Jar view of Kindle Fire's Services framework file

The means of data passing and the severity of this “feature” are different from the HTCLoggers.apk issue from October of last year, but I think they are both signs of the same trend. Mobile developers writing any sort of inter-process communication call or service need to ensure they are communicating only with other trusted apps. Android already gives you a way to do this, if your apps are signed with the same certificate. I’m a fan of Easter Eggs, but sometimes you want to make sure to limit who can walk away with your tasty burrito.

Installing a certificate can now be done in the Settings->Security menu of an Android 4.0 device and handled in the “Credential Storage” section. This does not require the device to be rooted (at least on the builds we’ve seen so far). The “Trusted Credentials” setting will list both the system wide installed certificates as well as any user added ones. An additional feature is now with a few simple clicks, the end user can disable any CA certificate on their device. Is your vendor still hanging with DigiNotar? Now you can disable that yourself without having to pull files from the device. Just click on the certificate, scroll down to the bottom of the pop-up message, then click the “Disable” button on the right.

Android 4.0 Credential Storage menu

Installing your own certificate is almost as easy. Here was my process. I needed the CA cert I generated in Mallory loaded onto to my Nexus. Mallory creates a unique CA certificate per-installation and stores it in Mallory’s “ca” directory.  To move this onto the phone, I started up Python’s SimpleHTTPServer in that directory.

~/mallory/current/src/ca$ python -m SimpleHTTPServer

http://192.168.90.1:8000/ca.cer

Mallory's CA Cert loaded on the device

~benn

As I was signing up for the beta, I noticed something interesting: the registration page immediately told you if the email you’d typed in matched an EA Origin account. This piqued my interest: was this exploitable, other than testing if email addresses were associated with Origin? I signed up with my Origin account, and strangely, it asked for a new password, without authenticating my current password. Digging further, I realized that you could reset the password to a new one of your choosing, with one caveat: the holder of the email account needs to access the verification link sent to the email address as part of signup. Here’s the email:

NewUser:
Thank you for joining the Star Wars™: The Old Republic™ community! To complete your registration and activate your account, simply verify your email address by clicking here. Remember, we will update or create an EA account using this email address upon your email validation.

Normally, this would be good enough to prevent unauthorized password resets, but I found it strange that nowhere on the registration page or the email did it say that my password would be reset, and no indication after the reset. Conceivably, you could sign up a large number of Origin accounts for the SWTOR beta, and if the target doesn’t log into his Origin account immediately, he’d be unaware his account has been compromised. If you’re a gamer, you’ve probably signed up for a dozen betas, hoping to get lucky now and then – a “confirm you want to join the Star Wars beta” email from EA would raise no suspicions whatsoever.

I decided to report the issue to EA. I couldn’t find a security contact on their website, but a bit of e-stalking later with a colleague, found the email address of the EA CISO, and shot off an email describing what I’d found. To my surprise, instead of being ignored or receiving a letter from their legal department, I got a response within the hour – “Do you mind sharing your details so we can address the issue promptly? We take security very seriously and would like to get on it right away.” I couldn’t have asked for anything better.

Four days and some email exchanges later, I received an email from one of their Online Development Directors:  thank you for reporting the issue, a patch has been deployed – oh and we’d like to send you some free SWTOR swag to show our appreciation.

This was a pretty fun experience for me. It wasn’t a critical vulnerability, but had the potential for mass abuse. EA was on the ball in fixing the bug, and kept me in the loop. You don’t get that too often. Now if only I could use this to have EA give me a permanent beta testing status for all games

@sorcerer13

For the RFnoID project, a group of us temporarily turned into nocturnal, lab-dwelling creatures to get this set up. Full credit for this post goes to my group members: Rob Lee-Own, Scott Velivis, and Vincent Lin.

Step 1: Obtain USRP. Ettus Research has several models. For the RFnoID project, we used the plain ol’ black USRP1. At Intrepidus Group, we have the USRP N210. An enormous, frustrating, caveat to the USRP will be mentioned later, but for now, keep this in mind: The USRP1 uses USB, while the N210 uses Gigabit Ethernet to communicate with the computer. Select with care!

Step 2: Select your daughter boards. The USRP requires RFID works in three frequencies: 125 KHz, 13.56 MHz, and 900 MHz. We’re going to be focusing on ISO14443-A, which operates at 13.56 MHz. For the rest of this article, NFC refers to the 13.56 MHz band. We’ll need one daughter board for receiving, and one for transmitting. The low frequency transmit and receive daughterboards (LFTX and LFRX) should fit the bill for 13.56 MHz RF communication at DC to 30 MHz.

Step 3: Select your antennae! This part took trial and error, including some home brew (courtesy of Scott and Rob):

We ended up going with two of the DLP-RFID-ANT from Digi-Key at $40.

Here’s the tl;dr so far:

1. USRP @ $1700 (USRP N210) or $700 (USRP 1)
2. LFTX, LFRX @ $75 each
3. 2x DLP-RFID-ANT @ $40 each

At this point, you should be able to hook it all up, set up GNU radio on your computer, plug in the USRP, and capture NFC goodness right out of the air. Wahoo!

In this video, we’re issuing a read command using libnfc in the left terminal, and detecting NFC energy using the USRP in the right terminal.

Still with me? Good. Here’s where we started spending long nights in the lab banging our heads against the desk. First, a little background on the software/protocol: NFC at its most basic level follows the ISO 14443-4 “Transmission protocol” specification. You can purchase that from ISO for 136 CHF. Google tells me that’s about $150 in real money. The real gem to pull out of those endless pages is that 0×52 is the WUP (wakeup) command, and it will wake up all tags in the area. 0×26 does something similar. In short, we used some hack-y Python to convert hex numbers into a wave format the USRP could understand and transmit. Code here. Feel free to use that code, but please credit RFnoID if you do find it useful. The USRP will modulate this wave at the carrier frequency. You do not need to do that part. You can set up the USRP to use that .wav file using:

from gnuradio import gr

gr.wavfile_source(“wave52.wav”, True)

We’ll get more into the software behind this in Part 2. Back to the hardware. Here’s what we were trying to get:

Notice that wave is 5.5V peak-to-peak. The NFC tag gets its energy from the RF signal the reader (or, in this case, the USRP) transmits. That’s the energy required to wake up and power an NFC tag.

When we transmitted, the tag simply wasn’t responding. Looking at our signal using the oscilloscope, we found that our signal was roughly .5V peak-to-peak. We required an amplifier to boost the signal to the 5.5V level and, luckily, found one in the lab. The amp doesn’t have to be this fancy, but needs to be SMA-in, SMA-out. We’re still searching for a cheaper amplifier that meets our criteria. Luckily Scott understands antennas much better than I do and says: “the 13.56mhz band is so narrow that even a very non-linear amp would look linear for a ~200khz bandwidth.” We’ll keep this post updated if we find something cheap that fits our criteria.

The second major issue we encountered came when we tried to do 2 things: first, detect energy in the NFC band; and second, send a blocking signal (0×52 works well for this purpose because it re-starts the tag’s initialization and anti-collision routine). We were using a USRP1. Remember we mentioned before that the USRP1 connects to the computer using USB. We were getting a large delay (~300 microseconds) we believe was coming from the USB stack (in the Linux kernel) buffering before sending a complete frame, causing a delay in detecting the RF energy. In theory, the USRP N210, which connects via Gigabit Ethernet, would not have this issue and could send frames as soon as they were received from the USRP.

More on the software (GNU radio and the scripts we used) in Part 2!

-Max

Download the presentation here: [download id="276"]

These videos show various testing techniques on real applications. The applications targeted didn’t have any serious problems. In the case of the game, “WordFeud”, a Scrabble clone, the game maintained game state on the server and tampering with client side values did not yield any interesting results. The SoundCloud demonstration shows how it uses the iOS data protection API to avoid storing OAuth tokens in the applications file sandbox and instead uses KeyChain.

Video Demo Series Here:

iPad SSL MiTM

1. http://www.youtube.com/watch?v=0453HDZYdGU
2. http://www.youtube.com/watch?v=kZ1pKShrKyk
3. http://www.youtube.com/watch?v=NvyM1wzwT2o
4. http://www.youtube.com/watch?v=HRRqL7IAkJw
5. http://www.youtube.com/watch?v=24FT-plmjAs

iOS Application MiTM

1. http://www.youtube.com/watch?v=Hgk310uUdjI
2. http://www.youtube.com/watch?v=x1T6kjtcpLw
3. http://www.youtube.com/watch?v=0VwJ1bss5wA
4. http://www.youtube.com/watch?v=50NAa324WC0
5. http://www.youtube.com/watch?v=btl147-ioKQ
6. http://www.youtube.com/watch?v=5YFC2L0vapM
7. http://www.youtube.com/watch?v=UL6mjywzBwU

Sound Cloud and Data Protection

1. http://www.youtube.com/watch?v=5fhktPV0LCs
2. http://www.youtube.com/watch?v=p6R15lVmOYA