NDK File Permissions Gotcha and Fix
The Android NDK (Native Development Kit) is a complementary toolkit for the Android SDK which enables developers to create native binary code. With the NDK, developers can harness the speed and performance of C to augment their Java Android SDK application. Typical uses for this are performance critical functions used in audio/video playback or rendering graphics in video games.
The NDK compiles the C portion to a shared library (.so), and exported functions in the shared library are accessible via JNI calls from the Java portion of the application. During the call to the native function, the program is running native ARM machine instructions outside the Dalvik virtual machine and developers should take note that the security model which is supplied by the Dalvik VM is not necessarily inherited in the native code runtime environment. An example of this can be seen when writing to a file.
When the standard method of writing to a file in the Android SDK (Java executed in the Dalvik VM) is used, the output file is created with the following permissions:
-rw-rw-r– 1 app_75 app_75 16 May 3 14:16 J.FLAG
The result is a file that is world readable but not writeable.
If one were to create a file via the NDK, using JNI, and simply used the following C library calls:
FILE * fp = fopen("/data/data/com.intrepidusgroup.scratch/C.FLAG", "ab");
fprintf(fp, "This is content.\n");
fclose(fp);
The new file would have the following permissions:
-rw-rw-rw- 1 app_75 app_75 22 May 3 14:17 C.FLAG
The file is world readable AND world writeable. This could potentially lead to security issues since the new file may be corrupted (intentionally or otherwise) by another application on the device if the file location is well known.
The difference in these default file permissions occurs because of the way the process execution is handled on Android. The Dalvik VM passes execution to the Zygote process, which has a umask of 000, and any process spawned off from Zygote will inherit this umask.
One way to match the SDK’s permission settings in native code, is to change the individual process umask with the umask(3) C library API call. This should be done before creating the file in the native code:
umask(002);
FILE * fp = fopen("/data/data/com.intrepidusgroup.scratch/C.FLAG", "ab");
This results in a file which has permissions that conform to those set by the Android Java SDK:
-rw-rw-r– 1 app_75 app_75 22 May 3 16:07 C.FLAG
Another way to do this is to use the open(2) system call itself to create the file, as this requires that permissions be explicitly specified when a new file is created.
const char * fn = "/data/data/com.intrepidusgroup.scratch/C.FLAG";
const char * content = "This is some content.\n";
fd = open(fn, O_CREAT|O_RDWR, S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH);
err = write(fd, content, strlen(content));
close(fd);
This also creates a file which has permissions:
-rw-rw-r– 1 app_75 app_75 22 May 3 17:15 C.FLAG
By removing or modifying the third argument to open(2) it is possible to restrict the file permissions even further. For example the exclusion of the S_IROTH flag would remove world readability from the file.
Google Wallet – Last Four Digits Revealed to Malware Vulnerability
If you’re using Google Wallet, please check your version number and ensure you’re up-to-date (1.1-R57v5 as of this post). This post describes an issue we discovered and reported to Google a few weeks ago. It has now been patched in the latest version of Google Wallet. We think it’s an interesting concern for both end users of Google Wallet and other application developers. While not the most earth shattering vulnerability, it’s probably not something you would want malware collecting about you or your credit cards.
To start, there has been a lot of great research into Google Wallet recently, including the ability to brute force the account PIN and viaForensics dive into application data storage. Both of those attacks required root level access to the device. However, in this attack, the heart of the issue involves the ability to send a specially formatted intent message to Google Wallet. This is something any Android application can do, once installed, without any additional permissions. The specially formatted intent message essentially tells Google Wallet to turn on verbose logging. Data which gets logged includes the last four digits of any credit cards that have been associated with your Google Checkout account (since Google Checkout is now rebranded/merged with Google Wallet). While the full card number is not shown, this data (along with other information that might get collected as well), could be used to target you for a fairly believable social engineering attack. Additionally, the inclusion of Google Checkout information means card numbers which I never thought of as part of my mobile phone’s digital wallet, were included as well (you’ll see these as “UNPROVISIONED” listings in the logs).
Last 4 digits of credit card numbers from Google Wallet/Checkout in the Android Logs
We’ve put together a short video which shows our “malware” application sending this intent message and collecting data on a non-rooted Galaxy Nexus (running version 1.1-R52v7 of Google Wallet) . You’ll notice the application does require the one permission, the ability to read the device logs. For the technical details, please see the our security advisory.
http://intrepidusgroup.com/advisories/intrepidus-advisory-20120418.txt
As for the fix, Google has stated they’ve reviewed all of Wallet’s logging features and have added the android:exported=”false” attribute to the LoggingPriorityChangeReceiver to prevent third party applications from enabling this feature.
Video: Google Wallet – Verbose Log Capture Malware Example
Java Reflection in Android…FTW
I’ll be hitting a few smaller security conferences this spring (whatup BeaCon and BSidesROC) with a turbo talk on how Java reflection can be useful for accessing hidden APIs in Android. The team at Gibraltar had some great posts on this last year, but getting reflection to work for accessing the NfcAdapterExtras and NfcExecutionEnvironment classes was not as straight forward as things seemed. Here’s some tips on how to get it working (at least on an Gingerbread Nexus S).
First, you want to get familiar with the nfc_extras framework. This is not included in the standard Android SDK, but you can either pull the /system/framework/com.android.nfc_extras.jar file from a device or look at the Android source. You’ll see there are two classes: NfcAdapterExtras and NfcExecutionEnvironment. What I really wanted was in the embedded NfcExecutionEnvironment, but the proper way to get that object is from NfcAdapterExtras.getEmbeddedExecutionEnvironment(). So we’ll need to create that object and method first.
I decided to use reflection to access these classes in my own Android application. Since they’re not in the SDK, I couldn’t just “include android.nfc_extras.NFCAdapterExtras” in my code. Instead, we’ll just ask for that class by name at runtime.
String sReflectedClassName = "com.android.nfc_extras.NfcAdapterExtras";
Class cReflectedNFCExtras = Class.forName(sReflectedClassName);
Wow, that’s pretty easy. Except that we’re going to need to tell the Dalvik VM to load that additional nfc_extras framework so that it knows about that class. To do that, add the following after your application tag in the AndroidManifest.XML file of your application.
<uses-library android:name=”com.google.android.nfc_extras” android:required=”true” />
Now back to our “cReflectedNFCExtras” class. The first thing we’ll need to do is get the singleton NfcAdapterExtras. This is returned by the get(NfcAdapter paramNfcAdapter) method. Note that it takes an NfcAdpater as a parameter, so we have to specify the class for that when looking for this method. The following line should work for that.
Method mReflectedGet = cReflectedNFCExtras.getMethod("get", Class.forName("android.nfc.NfcAdapter"));
However, at first I had mistake in my code that cause this method not to be found (thank Jeremy for fixing this). So instead, I had looped through all the methods using getDeclaredMethods() and stopped when the “get” method we want was found. Here’s the code for doing that followed by invoking the method and passing it the default NFCAdapter which would be the next thing we’d want to do.
Object oReturnedNFCExtras = null;
Method mReflectedMethods[] = cReflectedNFCExtras.getDeclaredMethods();
for (int i = 0; i < mReflectedMethods.length; i++){
Log.d("NfcAdapterExtras METHOD:", mReflectedMethods[i].getName());
if(mReflectedMethods[i].getName().contentEquals("get")){
//Standard default NFCAdapter... need to pass this in to get back the singleton
NfcAdapter defaultAdapter = NfcAdapter.getDefaultAdapter(this);
oReturnedNFCExtras = mReflectedMethods[i].invoke(cReflectedNFCExtras, defaultAdapter);
}
}From here out, it’s smooth sailing as long as you take care of one more thing. Your application needs a special premission in order to use this framework, the one for “NFCEE_ADMIN“. The problem is this premission is declared with the protectionLevel of “signature” in the com.android.nfc3 package. There’s a few ways to get around this, but as far as I know, they’ll all require that you have root on the device. Thus, even though we’re using reflection to access these classes, Android’s permissions are still enforced. My way of dealing with this was to resign the com.android.nfc3 package with the same certificate I used to sign my newly created Android application, then adding the following line to my application’s AndroidManifest.xml
<uses-permission android:name=”com.android.nfc.permission.NFCEE_ADMIN” />
So there you go. We can now be NFCEE_ADMIN’s as well (on our own rooted devices) using reflection. I’m curious to try this out with other /system/framework packages as well. In most cases, the process should be more straight forward:
- Create a class using Class.forName(“package.class”)
- Find the method using getClass().getMethod(“method”, paramTypes)
- Then invoke the method with the proper parameters
Verizon 2012 DBIR Challenge
Every year, Verizon Business publishes the Data Breach Investigations Report (DBIR). This year’s report analyzes of a cross-section of “855 incidents, 174 million compromised records” that have occurred over the past year. This was actually the eighth year they’ve produced the report, and it’s well worth the read.
For me, it was especially worth the read this year. Every year since 2009, they’ve had a little cryptography puzzle embedded in the document. In 2009, it was a very simple cipher, hidden as a string of 1s and 0s in the background of the cover. The 2010 puzzle was quite a bit different, and significantly harder. Then, last year, the cover challenge got much more complicated (and, I think, quite a bit more interesting).
I really like solving crypto puzzles like these. I missed the first one, was soundly beaten by the second, and didn’t have a chance to play the third. So when this year’s report hit the streets, I was ready. And, after a couple days’ casual effort and a nearly-every-waking-moment weekend, I solved the puzzle. Not only that, but I was first, and won the prize (an iPad!).
I won’t spoil the puzzle here, but will mention a few interesting bits that I seem to re-learn every single time I complete one of these challenges:
1. Not everything is not always as it seems.
2. There are a lot of different modern ciphers.
3. If something looks “odd,” it probably is, and should be carefully investigated.
4. Coincidences are important.
And, finally, something I’ve been thinking about for a while:
5. I really need to watch The Big Lebowski.
If you’d like to see a full-on account of how I solved this one, as well as some of the blind alleys I spent hours in, check out the full writeup here.
Android MDM. Part I: Build Up
We know that Android is popular, and recent polls show that Android is “winning” the race in sheer number of smartphones that are out there. Frequent readers will remember previous blog posts on Apple’s MDM solutions where David Schuetz dives into some of the security concerns.
But what about Android? It seems to be following the way of the iPhone in that it becomes super popular as a consumer device, and only then do we start thinking about using it in an enterprise environment. Android has supported mobile device management (MDM) solutions for a long time now (since 2.1). Yet Android, until recently, is often considered ill-prepared for an enterprise environment.
Here’s Your API. Good Luck
Android’s MDM support comes in the way of the DevicePolicyManagement API. This allows developers to control things like password complexity, lockout timing, remote wipe, and remote lock. Standard MDM features right? But what about things like tracking apps that are installed on a device, keeping track of serial numbers, being able to recover lost devices? Yeah, it can do that but just like all of the other Android decisions they’ve made, Google has given you the ability to do it yourself and then they stepped back to watch the carnage. This means that while no official Android MDM solution exists, third parties are picking up the slack and rolling their own.
The MDM Recipes
I categorize third party MDM solutions into three unscientific groups: Cross-platform Android clients that use ActiveSync, native Android solutions, and cloud based solutions. Native clients, such as Google Apps, have created a complete solution tailored to Android devices. They take advantage of the DeviceManagementPolicy APIs and then add in some other features such as asset tracking, GPS location tracking, app auditing, and permission controls. They are not building upon any pre-existing technologies so while this sounds like the best solution, not many MDM providers are going this route because it’s so specific to Android.
Cloud based MDM solutions (lets face it, it’s just Good Technologies), will give a user access to all of the cloud services, and then remove them when the device is no longer compliant with a device policy or an employee leaves the company. You can probably see how it would be easier to just stop granting access to your enterprise services rather than attempting to wipe a device when it leaves a company.
The most popular solution by far is the ActiveSync based solutions. This is an MDM app that relies on ActiveSync for device management policies, and then adds in their own bells and whistles. Airwatch, for instance, is an ActiveSync solution that has added in asset tracking, app auditing, and a lot of other features. In fact, the most popular solution that I’ve seen is just enabling ActiveSync and calling it a day.
As a stand alone solution, ActiveSync will push out device polices that control passwords, idle timeouts, and provide a remote wipe capability. But the bells and whistles that you’ll see with other solutions are nonexistent. The reason it’s so popular is that there’s minimal deployment time and for some environments it very low cost. Those organizations that have already implemented Exchange can enable ActiveSync services for smart phones and using using Android’s built in “Corporate Email Client,” it connects in and is ready to go.
MDM and ActiveSync
Why are we talking about ActiveSync when it comes to Google? The reason is that the Android Exchange client (AKA Corporiate Email Client) uses ActiveSync to pull down email, contacts, and calendar events from corporate networks since 2.1. But one of the features it has also implemented as part of ActiveSync protocol is password controls, remote wipe, and idle timeout.
So that’s great – you have an Exchange environment, you enable ActiveSync, and you now have a mobile device management solution for Android devices. But what about those other feature we talked about; app management, asset tracking, GPS tracking. None of those features are there. Well it turns out that a lot of organizations believe that’s enough. In talking with one of the local fortune 500 companies about how they manage their mobile policy, we found that they’re using a native ActiveSync to implement a Bring Your Own Device (BYOD) mobile policy. They had an Exchange environment, they wanted to allow employees to bring in their own devices to access corporate information, so they enabled ActiveSync and they were done.
Because this is such a popular implementation, it’s also become a target for clients that would like to evade this policy. In the next post I’ll talk about some specific problems that we’ll run into.
MDM Communication With C2DM
Cloud 2 Device Messaging (C2DM) is Google’s lightweight data push service. It’s Android’s answer to the Apple Push Notification Service or the Blackberry Push Service. These types of services are ways of pushing down information to an app as opposed to waiting for an app to pull data. A lot of the MDM providers use this solution to send down their device policies or remote commands. When a remote wipe command is issued from an organization, you don’t want to wait for the app to issue a schedule update, you want that command to be sent as soon as a device has connectivity to something.
A coworker of mine is looking into the security concerns with C2DM but in this scenario, we’re concerned that someone might be able to send a remote wipe to your phone without having administrative access.
So…what?
Android’s MDM solutions are up in the air which may be why a lot of people say that Android isn’t really ready for the enterprise. With the latest Ice Cream Sandwich version of Android that supports policy controlled encryption, I think you can see Google pushing Android into enterprise environments much more.
This is a nice little info blurb about Android MDM and the underlying technologies but lets be honest, the real fun comes from attacking. The next Android MDM post will discuss some attack vectors and evasion techniques that may make you re-think how much you trust your MDM provider.
Google Wallet coming for iOS?
The list of two OS types in WalletShared: ANDROID and IOS (click to enlarge)
Let’s start by saying this is no smoking gun, but a pretty interesting case of information leakage through an application. For our regular blog readers, you’ll know we’ve been looking into NFC based applications over the past year. The jewel of all NFC apps is easily Google Wallet and thus we’ve spent a large amount of time trying to understand it. When you decompile an Android application, which isn’t obfuscated, you’re able to see the same class names, method names, variable names, and other identifiers as in the developer’s source code. In this case, Google Wallet includes a package called “wallet.proto” which contains parsers for any “Protocol Buffer” formatted data the application uses. While the name “Protocol Buffers” sounds generic, it’s actually Google’s well-documented mechanism for serializing data (think of it as their version of XML or PLists). If you followed the Google Wallet PIN hashing issue, you’ll remember that the PIN hash is stored in a protocol buffer.
The “WalletShared” protocol buffers package in the current version of Google Wallet contains hints of iOS within the parsers definitions. This includes defining the “DeviceContext -> HardwareType” field with only two values: “ANDROID” and “IOS”. iOS strings are also found in two additional protocol buffers called “IosDevice” and “IosWallet”. The classes only leak a little detail about the information being collected which include items named “appId”, “appVersion”, “walletUuid”, and a few “model” and “version” items.
Function names with
Now you might ask why anything about an iOS application, written in Objective C, would get compiled into an Android application, written in Java. This could happen because of how a Protocol Buffer structured data definition file is created. A developer typically creates a “.proto” file, which is a programming language independent file which defines the data structure. This “.proto” file is then compiled using the “protoc” application and creates the appropriate files for the language you are programming in. Thus, it’s simple to use the same “.proto” file to create a Java object or an Objective C object if they are both going to use the same data structure. While Objective C is not in the official protocol buffers package, there is an add-on for that language available. Thus it is quite likely if there was a “shared” data structure which both clients and the server would need to parse, the same “.proto” file would be used regardless of the application’s programming language.
Of course, if Google is developing Google Wallet for iOS, it raises numerous questions. Since iOS devices do not currently include an NFC radio or secure element, is Google planning to release a case, or “sleeve,” with these components? Or do they know something about the next iPhone we don’t? And if the next iPhone does have NFC and a Secure Element, would Apple allow Google access to those components? In any case, if Google is working on developing their wallet for iOS, this could be a sign of strong commitment by Google to contactless payment technology. And that’s a win for everyone regardless of which device is in your pocket right now.
Quick Look at Apple Configurator
Shortly after the iPad event on Wednesday, Apple released the free Apple Configurator application. It’s billed as a way to “set up new devices, and install enterprise apps,” but my main interest was in learning how it might interact with Mobile Device Management. So I upgraded my iTunes to 10.6, installed the application, and started poking around.
Essentially, Configurator allows you to maintain a fleet of identical iOS devices. With it, you can re-baseline up to 30 devices simultaneously, pre-installing applications and configuration profiles at the same time as wiping it clean and updating the OS version. The application allows you to create configuration profiles directly, or you may import profiles created in the iPhone Configuration Utility (IPCU). [Aside -- the IPCU was also updated on Wednesday, and both that and Configurator support some new features, including the ability to disable Siri when the device is locked. Interestingly, Configurator also includes the ability to enable a "Siri Profanity Filter" and to disable Location Services, neither of which I've been able to find in the new IPCU.] The Configurator doesn’t include the capability to create an MDM enrollment profile, but you can import one from IPCU and it works just fine.
When used in this mode, Configurator can easily streamline the setup of large numbers of devices for corporate deployment. I haven’t found a way to pre-set all the “Welcome to iOS” responses (selecting a language, assigning an Apple ID, etc.), but even with those last few manual steps, this can make rapid deployment of large numbers of devices in an enterprise much, much easier. The device is wiped, then the latest version of the iOS installed, along with applications and profiles. At this point, the device can be set aside into a pool, ready to be used. You can even load pre-purchased App Store applications (for very small deployments, you can pre-set the AppleID used to purchase the apps you’re installing, otherwise you’d need to use the Volume Purchase Program to load redemption codes for each device).
But that’s not all! When baselining (or “preparing”) a device, the user has a chance to configure it as a “Supervised” device. When issuing the device to end users, you can just hand it to them, or have the system formally “check out” the device. By doing the check out, the device can be customized with the user’s name, photo, and pre-installed user-specific documents. When the user is done with the device, they return it, and the check-in process then backs up the user’s data, and wipes and re-baselines the device for the next user.
All of that would be interesting enough, but my focus is more on security than ease of deployment — what does Configurator do to enhance or replace MDM? Firstly, the profile that marks the device as supervised can not be removed by the end user. In fact, as far as I can tell, it can’t even be removed by the machine which prepared the device. The only way to “un-supervise” a device is to wipe it clean and start from scratch. It also locks the device to the system used to prepare it — trying to connect to iTunes or IPCU on another system results in an error. In fact, even using IPCU on the Configurator machine won’t work — it won’t let you install or remove profiles at all. However, I was able to manually install an MDM profile, as a user, by tapping on a link in Safari, so the end user might still be able to make changes that way even if IPCU is locked out. Also, even when the MDM enrollment profile is installed as part of the device preparation and baseline process, the user may still remove the enrollment.
One final interesting point — the use of the “supervised” term caught my eye. When researching the changes that iOS 5.0 brought to the MDM system, I found several mentions of supervised devices near other MDM-related strings in the iOS binaries. I also found several references to a “Chaperone” system. These included things like “PermissionSlip,” “AllowSleepOver,” and even “ReadyForKeyMaster” (though no mention of Zuul). Ever since seeing that, I’ve wondered if some form of parental-oriented device management and monitoring might be in the works. Well, this system seems to make use of Chaperone-related profiles, so perhaps we’re seeing the first elements of this beginning to enter production.
In summary, the new Apple Configurator application looks like it will be very useful for anyone maintaining a small fleet of devices (such as loaner devices, or in support of a class), and will also greatly streamline the large-scale preparation and deployment of devices within the enterprise. For further reading, here’s a link to the Configurator Documentation from Apple.
iOS MDM: Preventing Disassociation DOS and Potemkin Devices
I was thinking a couple of weeks ago about additional vulnerabilities in iOS Mobile Device Management, and noticed a couple of problems that I had not considered before.
It may be possible for a malicious individual, whether an outside attacker or inside troublemaker, to forge fake responses to the MDM server. They could, it seems:
- Send the server fake TokenUpdate commands
- Send the server fake responses to real commands
In both cases, the attacker would need to know the UDID of the device they’re trying to impersonate.
The first case, a fake TokenUpdate command, could be used to sever the link between the server and the targeted device. By sending the command with a bogus DeviceToken, the MDM server would no longer be associated with the device, as the Push Notification system wouldn’t know where to send messages. Thus, the device whose UDID was used in the attack would no longer be managed by MDM.
An attacker who manages to collect UDIDs for multiple devices could thus mount a denial-of-service attack against the organization’s MDM server. Each and every targeted device would have to be manually re-enrolled with the server in order to resume management. For a large number of devices, this could be a costly effort, especially if the attack is repeated multiple times.
The second case is a bit more sneaky. If a user reconfigures their managed device to point to an MDM server of their own, they could essentially proxy the MDM protocol and send fake responses to the real server. By doing this, they could essentially create a “Potemkin Device” that would appear, to the corporate MDM server, to be properly in compliance with all policies, when in fact the device would simply ignore all MDM commands.
This seemed a little extreme to me. There must, I reasoned, be some way to prevent this from happening. So I dug a little deeper, and remembered the “Sign Messages” flag in the MDM enrollment payload. I’d experimented with this before, but discovered it had no effect on whether the client trusted the commands from the server.
As it turns out, I had it backwards — this flag isn’t for the server to sign messages to the client, but for the client, the remote device, to sign its messages back to the server. Exactly what I was looking for.
The exact mechanics are pretty simple:
- The client includes an “Mdm-Signature:” header in the HTTP PUT messages it sends to the server
- This signature is a base-64 encoded, .DER format, SMIME signature
- The content which is signed is not included in the signature, but is instead the content of the PUT itself — the message being sent to the MDM server
- Finally, it’s signed using the private Identity key that was sent to the device at MDM enrollment
So to prevent both these attacks, you must:
- Ensure the “Sign Messages” flag is set by the MDM server when enrolling device, and
- Ensure the server itself actually checks the validity of the signed messages, and rejects them if the signature is invalid
Note that it may be possible to extract the identity certificate and key from a device and set up the fake MDM proxy even with message signature validation enabled at the server — but I haven’t investigated this yet.
I’ve updated my test server with code that performs this check. You can find it on Github.
david.
How to respond to spam…
This is a bit different from our usual blog content. When I need a break, I take a moment and do a bit of creative writing. This writing typically surfaces as a creative response to some targeted spam. This is one of those responses:
Please keep in mind I wrote this tongue in cheek and I don’t really feel this way about developers.
Hi Jeremy,
I’ve came across your company’s profile on LinkedIn and thought that you might be interested in hiring mobile software developers.
We have an Android developer available which is supposed to work remotely under your managerial control from our office in Ukraine.
Our company finds, employs and supports client’s own software development teams, which work under the client’s 100 % managerial control from our office. Companies from the Netherlands, Norway, Germany, Belgium, Denmark and the USA already have their teams in our office (references on demand).
Is this something that might interest you?
P.S. PHP, C++, Microsoft .Net developers are available for hire (CVs are available).
————————————
Dear Jane,
My organization is involved with mobile security in very special way. We are, what you would call, ‘White hat hackers’. What this means is that we work with organizations that develop mobile applications. Mobile applications are new, but they are not terribly hard to develop. So I will now tell you a story.
This is a story about Joe. And he is a different kind of hacker from the typical Intrepidus Group hacker. He is a hacker in the more traditional sense of “one who hacks” or someone that writes code. Joe is an overworked developer at a large insurance company.
Joe was sitting at his desk waiting for his latest bug fixed to be reviewed by the QA team. Joe checked the clock in his computer task menu. Only 3:45, and already, he was falling asleep. He knew it was going to be tough to finish the day. There were a couple more blocking issues on his application that he knew had to be fixed before it could be released. He performed a quick mental calculus on the level of effort to fix those remaining bugs. He knew his manager would not be happy, he estimated over two days to fix the remaining bugs.He got a little hot under the collar just thinking about the deadline, which was passed a week ago. His manager was under pressure to release the new mobile application. The executive management team was keen on “engaging” their customers in a mobile fashion. Joe had once worked with Objective-C and when the discussion of the insurance company’s mobile application came up; Joe figured he would get a chance to do some cool work. He dumbly volunteered to be an iOS developer. His life was never quite the same since that moment. He has been straining to learn the framework and finish the application on time. He had to constantly fight feature creep and outlandish expectations about what a mobile application could do. The executive management team seemed to be under the impression that the heavens would shine down upon their mobile applications and that the damn thing would just fart rainbows and solve the company’s problems.
Joe ruminated on this a bit longer. 4:00PM. He pecked away at his keyboard slowly to appear productive. His mind was racing. He couldn’t wait to get home and see the latest episode of Jersey Shore. He reviewed his bug list one last time. He realized there were several security issues in the list. He changed their priority to low and justified this with the explanation that mobile applications were inherently insecure and unimportant so it would be silly to spend time working on security bugs.
Joe took a break and headed to the restroom. He knew he could kill ten minutes this way. He finished his business up and checked his complexion in the mirror. Damn, Joe thought, the male pattern balding was getting worse. His wife’s constant nagging was finally getting to him. He would have to go visit a hair loss center. He did not want to admit it, but a lot of his identity was tied up in vain things, such as his looks. He was legitimately afraid his wife might not love him as much if he didn’t lose a bit of weight and fix this hair condition. Maybe getting a Camaro SS, one of those new ones with 500 horse power, would make his wife think twice. Joe sighed and headed back to his desk. This was going to be a long 50 minutes. Eventually the time passed and he meekly filed out with everyone else. He hopped into his aging Toyota Corolla and battled it out for an hour with all the other poor citizens in the strangling traffic Utopia.
Developers like Joe are what keep us employed. They don’t care about security more than they have to.
Thanks,
Bluetooth: Defining NAP + UAP + LAP
Just a quick follow up to last week’s post, defining what NAP, UAP, and LAP actually are and where they come from. They are the 3 components of 6 byte “BD_ADDR” (Bluetooth device address):
NAP: “Non-significant Address Part”. 2 bytes. These are assigned by the IEEE and are publicly available here. Depending on who makes the Bluetooth hardware, there can be anywhere from 1 to 10′s of possible NAP portions. For example, Xerox is assigned 00-00-00 through 00-00-09 (along with 00-00-AA and 9C-93-4E). A search through the IEEE database for “Motorola” returns 250 results. Just to be clear, the first 2 bytes of these assignments are the NAP, and the last byte is the UAP. We can narrow the search space even further by filtering the list based on the assigned UAP, which we can also get by sniffing communication:
UAP: “Upper Address Part”. 1 byte. The UAP is also assigned by the IEEE and is listed on the same IEEE page as the NAP. The cool part about the UAP, which links it to both the NAP and the LAP (next section), is that it can be derived from packet data. As I mentioned in the previous post, Ubertooth provides a utility for calculating the NAP on-the-fly. This part involves some fairly complex unwhitening and brute-forcing, so we’ll leave that to Ubertooth 
LAP: “Lower Address Part”. 3 bytes. The LAP is easy — it’s transmitted with every packet as part of the packet header! All we have to do (which the Ubertooth does for us) is sit on one channel and wait for a packet to be transmitted. This happens frequently — to the “tune” (har har) of 1600 hops over 79 channels every second, meaning we should see just over 20 packets per second on our one channel if the two devices are communicating at full bandwidth.
So! Now we have the full BD_ADDR. What can we do with it?
Well, first of all, we can sniff Bluetooth! (Pending hardware support ). Bluetooth’s special “hopping” pattern is derived from the master device’s MAC address. Using the BD_ADDR of the master, in theory we can follow that hopping pattern and start extracting useful data from the Bluetooth communication.
We can also target one device directly, or emulate that device and cause all sorts of mischief. We can tell the other device that we forgot our secret Link Key, and need to re-pair and make a new one. Or run attacks against the Bluetooth implementation.
