Author Archives: jeremy.allen
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
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,
Google Wallet PIN Brute Forcing
Google Wallet is a project of great interest right now as it is a big shift in how we pay for goods and services in the US (Japan is quite far ahead of everyone on mobile payments). Some researchers have discovered that Google Wallet is storing the PIN for your wallet on the device in a relatively insecure format. Since this information was already released into the wild, we felt we should share our perspective and how we would approach this problem. The PIN data is stored in the application’s SQLite database.
The SQLite database is stored in the Google Wallet data directory. Google wallet stores the pin in the proto column of the metadata table. The data is encoded using the protobuf format (also by Google). The following SQL query retrieves the data:
select hex(proto) from metadata where id = "deviceInfo";
This query retrieves the protobuf data encoding a number of device and user specific information. Protobuf is a data serialization format, similar to JSON in concept. Next the data must be deserialized. The standard way to work with protobuf data is to define a .proto file, which acts as a key for deserialization. These .proto files get compiled down to application specific code and are not in their native human readable format. Raj decided to start to write a generic protobuf decoder (Protobuf Easy Decode) . This Python module can decode protobuf data without a .proto file. Some data is inevitably lost when reading raw protobuf data without a .proto file.
Recovering the PIN with the decoded data required some understanding of the specific .proto structure. Once the salt and the hash of the salted pin retrieved, brute forcing the PIN is a trivial matter: brute_pin.py illustrates how to brute force the PIN.
Excuse me, your clouds are leaking
I recently started playing around with Gliffy, a nice online diagramming tool that has become quite popular. Gliffy makes sharing your diagrams with the world easy. Unfortunately, many Gliffy users do not realize that they are sharing their diagrams with the entire world. Some quick Google searches revealed a number of entertaining diagrams.
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
OWASP ATL: Mobile Application Assessment Presentation
I recently gave a presentation at OWASP ATL on the OWASP Mobile Top 10 and how to assess mobile applications. This was a light weight discussion of the OWASP Mobile Top 10 and some topical and technical concerns related to securing mobile applications.
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
- http://www.youtube.com/watch?v=0453HDZYdGU
- http://www.youtube.com/watch?v=kZ1pKShrKyk
- http://www.youtube.com/watch?v=NvyM1wzwT2o
- http://www.youtube.com/watch?v=HRRqL7IAkJw
- http://www.youtube.com/watch?v=24FT-plmjAs
iOS Application MiTM
- http://www.youtube.com/watch?v=Hgk310uUdjI
- http://www.youtube.com/watch?v=x1T6kjtcpLw
- http://www.youtube.com/watch?v=0VwJ1bss5wA
- http://www.youtube.com/watch?v=50NAa324WC0
- http://www.youtube.com/watch?v=btl147-ioKQ
- http://www.youtube.com/watch?v=5YFC2L0vapM
- http://www.youtube.com/watch?v=UL6mjywzBwU
Sound Cloud and Data Protection
Protect your Apple Developer Certificates
A discussion of Apple Developer certificates came up. The conversation was focused on how a third party developer wanted access to an organizations certificate so they could build the application for the organization and (potentially) publish it to the Apple App Store. The developer’s request did not surprise me, but it did surprise a couple of people at our lunch table.
As a policy, third parties should never be granted access to your Apple Developer certs. Anyone that has that cert and private key can publish applications as your organization. This has huge implications. Please, don’t let anyone outside of your organization have access to your certs. In fact, don’t let more than a few people in a tightly controlled environment have access to them. If you deal with SOX and any sort of separation of duties you are probably familiar with separating developers from production. You may not be aware that having access to that Apple developer cert (issued to your organization as a whole) lets the possessor publish applications as you. If you have a third party developer, tell them no when they ask for access to your certs and handle it in house.
I also recommend any org building iOS apps create build environment and only publish binaries they build themselves to the app store. The best secure SDLC and developers in the world can be undermined by this one operational security mistake. Guard your developer certs very closely. A third party developer can slip in malicious code. A third party developer may not have the same security practices and constraints as you. The list goes on. The idea is simple: protect your Apple dev certs like a nuclear launch code.
Here are bad code signing things that have happened:
http://threatpost.com/en_us/blogs/possible-new-rootkit-has-drivers-signed-realtek-071510
http://www.symantec.com/connect/blogs/stuxnet-code-signing-incident-emphasizes-role-acs
http://www.f-secure.com/weblog/archives/00002017.html
Note: Reader Karl observes that you can still have separation of duties from developers by not giving them the iTunes connect credentials required to upload to the store. Karl is likely correct on this point. It is certainly not quite as easy as I made it out to be getting things into the App Store with just a code signing cert.
Be wary though, production code signing certificates should likely be kept out of most development environments, as there are still risks with Ad-Hoc application publication and many other abilities Apple dev certs enable that should not be granted to a development team carte blanche.
Intrepidus hosting a Convergence notary
Suffice to say, the Certificate Authority trust model seems to be fundamentally broken, and with increasing attention paid to it from numerous angles, it’s likely to need a massive overhaul before getting any better. However, there are efforts underway to change the way we think about trust in this capacity. Moxie Marlinspike, known for his contributions to (breaking) SSL and the CA system (among other things), recently developed an alternative to the traditional CA trust model. The project, called Convergence, pairs a Firefox add-on with a set of server-side components to help validate the authenticity and trustworthiness of a particular SSL-enabled site.
Although Moxie’s blog post (that led up to Convergence) and the video of his talk at BlackHat USA 2011 explain the rationale a bit more, the concept is simple: you visit a (SSL-enabled) site, let’s say SomeTrustedSite.com, and the Convergence add-on sees a certificate with a fingerprint FOO. The add-on asks a set of Convergence “Notary servers” what they see. If they see FOO, you can reason that SomeTrustedSite.com‘s cert is legit. If one or more of the notaries sees something that isn’t cert fingerprint FOO, something’s probably rotten (such as man-in-the-middling of your connection, or a notary’s connection, or some other network nastiness). Most importantly, you decide which notaries you want to trust, rather than relying on a browser-vendor defined list of Certificate Authorities. Convergence also attempts to anonymize inquiries to notaries so as to minimize the likelihood of a notary getting a bit too privy to your browsing habits.
Per the Convergence site, the installation process for the add-on is fairly straightforward: run Firefox, visit Convergence.io, click “Download”. After that, add any notaries you wish to trust — two Thoughtcrime notaries are enabled by default, and there’s an ever-growing list of additional notaries on the project’s Github wiki. As this project caught our eye, Intrepidus Group decided to spin up a notary server of our own, which can be added by loading our notary file (if you have Convergence installed, you can simply browse to “.notary” files/links to add the associated notary info).
And Intrepidus isn’t the only company to get on the Convergence notary server train. Late last month, Qualys announced their support of the project, as well as spinning up two notaries. We certainly hope to see more of this type of backing in the near future, and encourage others to run their own notaries as well.
ARM, Pipeline and GDB, Oh My!
This post off will start with an important question. Look at Listing 1 below; after executing the instruction located at main+12, what values will be stored in r0 and r1? Take a moment to consider this.
Listing 1: Disassembly of main()
My first (albeit incorrect) answer was that r0 would have 0x000083bc (main+8) stored in it and that r1 would have 0x000083c8 (main+12+8) stored in it (the address of the instruction, plus the value from the add instruction). I thought this because I made a few assumptions about the state of the processor during the execution of the instructions. First, I assumed that while executing the instruction located at main+8, “mov r0, pc“, the pc register would have the address main+8 stored in it and therefore that address would be moved into r0. I also made the assumption that while executing the instruction at main+12, “add r1, pc, #8“, the pc register would have the address of main+12 stored in it and this address plus 8 would be moved into r1. According to Listing 2, I felt that GDB supported my assumptions by showing the pc register with the currently executing instruction stored in it.
Listing 2: GDB reported pc values before execution of instructions.
By examining r0 and r1 while executing the instruction located at main+16 (Listing 3) it became obvious my two predictions would not come to pass. The r0 register had 0x000083c4 stored in it and the r1 register had 0x000083d0 stored in it. Perplexed, I needed to try to understand the mechanism at work here.
Listing 3: Actual values of r0 and r1
After a few minutes of thinking, I started to remember a topic covered in my NYU:Poly computer architecture class, pipelining. I then noticed that both of the values were exactly 0×8 higher then I expected. Doing a quick Google search, I came across the fact that the ARM processor executing my code has a 3 stage pipeline with a 4 byte fixed instruction size.
To understand this problem, we now have to get into some details of ARM processor architecture. Pipelining, as it relates to a processor, is a term used to describe an optimization to optimize the execution of instructions. When a processor executes one instruction there are normally a few distinct steps required before finally executing it. For example, ARMs pipeline stages include fetch, decode, and execute* (see note at end of post). The processor must first load the instruction from memory (fetch), decipher what the instruction must accomplish (decode), and perform the operations necessary to complete the instruction (execute). Each step usually relates to a set of components inside the processor and requires a certain amount of time to accomplish. In addition, the steps must performed in a strictly serial manner per instruction. In a non-pipelined processor only one phase of one instruction is performed at once. This leaves the hardware on the processor responsible for the other stages idle. A pipelined processor is designed to have each phase active for an instruction all of the time.
Let us work through an example (Image 2); during one clock cycle Instruction 1 will be in the execute phase, Instruction 2 will be in decode phase, and Instruction 3 will be in the fetch phase. So why is this important? From a high level point of view, the pc register points to the currently executing instruction. This is the convention that GDB employs. However, from an ARM pipeline point of view, the physical pc register always points to the instruction currently being fetched. The reason for this resides in the deepest levels of the ARM processor architecture. The pc register is used as a direct input into the address register. The address register is used to index memory used to fetch the instruction. See image 1 below from “ARM system on a chip, second edition” for a good diagram of this.
Image 1: ARM Layout (source: ARM system on a chip, second edition)
Our example image below shows a time based view of this processor over the course of 5 clock cycles. Carefully analyzing image 2 during clock cycle 3, we see that the instruction being fetched is 2 instructions after the instruction being executed. Therefore, within the processor, pc must point 2 instructions after the current executing instruction, or 8 bytes ahead (each instruction is 4 bytes long). Instructions that use the value stored in the pc register will be using this actual value of pc. When we see an instruction such as “mov r0, pc” we can think of this as r0 will get pc + 8 where pc represents the current executing instruction as reported by GDB.
Image 2: Pipeline (Source: http://winarm.scienceprog.com/arm-mcu-types/how-does-arm7-pipelining-works.html)
With this in mind, the correct answers to the initial question is:
r0 = 0x000083c4 = (main+8) + 8 = 0x000083bc + 8
r1 = 0x000083d0 = (main+12) + 8 + 8 = 0x000083c0 + 8 + 8 = 0x000083d0.
As you can see, these solutions match what was observed by GDB. Yay!
So what are the key lessons learned? Depending on the number of stages or the specific hardware, the difference between the address of the currently executing instruction and the value stored in the physical program counter register (eip, pc, rip, etc.) may be different. It is important to research this behavior for any processor architecture you are going to be reverse engineering on, writing shell code for, or simply writing assembly to be executed.
-Raj
*Note: There are many different ARM processors and pipeline architectures, however, this is a good description of it to understand the general mechanism at work.
Skype 5.5 and New Hidden Emoticons
WARNING: This post is humorous (and not very technical) in nature. Please don’t take anything that follows seriously.
With that warning out of the way, we all know that Emoticons are a very serious topic. When Skype updates their emoticon set the Internet takes notice. When Skype announced new emoticons, they included a bit about two new “hidden” emoticons. With something this important hidden, there can be no rest until they have been discovered.
Skype encrypts and obfuscates their binary to prevent reverse engineering (and perhaps to compress it, etc.). Using the very powerful hacker tool, “Process Explorer” I was able to dump the process image. Using another advanced hacker tool, “strings” I was able to find the emoticon list. With a bit of spam to my co-workers I found a couple of hidden emoticons (zilmer) and (hollest). Zilmer and Hollest appear to people that were, or are, associated with the organization behind Skype.
Full Skype 5.5 emoticon listing:
(mooning) (u) (skype) (skype) (punch) (call) (talk) (mp) (mp) (mp) (~) (~) (o) (o) (e) (zilmer) (hollest) (wfh) (toivo) (bug) (wtf) (smoking) (smoking) (smoking) (rock) (poolparty) (poolparty) (finger) (fubar) (drunk) (swear) (headbang) (headbang) (*) (ninja) \o/ (d) (beer) (beer) (^) (flex) (flex) (cash) (cash) (pi) (pi) (coffee) (tmi) (bandit) (music) (tumbleweed) (sun) (rain) (rain) (F) (heidy) (heidy) (lalala) (lalala) (lalala) (lalala) (h) (highfive) (highfive) (highfive) (handshake) (n) (y) (y) (emo) (waiting) (waiting) (waiting) (shake) (nod) (smirk) (happy) (whew) (rofl) (bow) (think) (clap) (chuckle) (chuckle) (makeup) (makeup) (hug) (hug) (wait) (envy) (angel) (devil) (facepalm) (facepalm) (wave) (wave) (wave) (nerd) (mm) (mm) (mm) (worry) (party) (wasntme) (angry) (doh) (puke) (yawn) (yn) (yn) (yn) (yn) ]:) (inlove) (inlove) |-( |-) :^) :$ 
:* 
(:| ;( 
:O 
:D 
A few classic emoticons get rendered by WP here. So, please do enjoy that.
If you use Skype a lot check out Tattler.
@bitexploder
The OWASP Mobile Top 10 Risks for iOS Developers
The OWASP Mobile Top 10 Risks is an overview of a generic list of the most common risks found in mobile applications. We see these risks in mobile applications every day. When we see them they often show up as vulnerabilities in the applications we are assessing. No list, such as this, can adequately cover *every* issue an application will face. However, this is a good starting point for a security team or development team looking to understand the most common mobile application security issues for iOS. This article focuses on these risks (and ways to mitigate them) for iOS. For a more generic look at these controls and for further ideas on mitigations check out the OWASP Mobile Top 10 Controls.
1 – Insecure or unnecessary client-side data storage
This risk addresses the obvious concern of sensitive data being stored on mobile devices. All developers must carefully consider if storing a piece of data on a mobile device’s persistent storage is absolutely critical to the application’s correct functioning. If it is not the data should simply not be stored. If the data is required, and it is sensitive, it must be protected. Data protection often means “encryption”. For iOS developers, this is not an onerous problem. Apple provides a very easy to use, and secure, data protection mechanism for iOS 4 and newer devices using 3GS or newer hardware. The mechanism is aptly referenced as “Data Protection”. Apple provides two methods of doing this that very straight forward to use. Pass in the correct option (NSDataWritingFileProtectionComplete) to NSData writeToFile:options:errors: and the file is protected and encrypted when the device is locked. Alternatively, you can use NSFileManager setAttributes:ofItemAtPath:error: and pass in the NSFileProtectionKey attribute with the NSFileProtectionComplete value to protect existing files.
For more information see: Implementing Common Application Behaviors.
Note: The user must have a passcode for this to work. iOS 3.x on 3G and older devices do not have this capability and require much higher effort and less secure/user friendly solutions.
2 – Lack of data protection in transit
After data has been secured on the device the next high concern area is protecting the communications between the mobile application and the server. By far, the most common communication protocol is HTTP. For iOS developers this typically means using the NSURL or NSURLConnection class. By default, NSURL or NSURLConnection will fail with an error in the event of an SSL issue. Development environments do not, typically, have a valid SSL certificate, which creates a problem. NSURL and NSURLConnection behavior is changed to accept invalid certificates to continue development without hassle.
With NSURLConnection an application must implement the delegate methods canAuthenticateAgainstProtectionSpace and didReceiveAuthenticationChallenge to ignore SSL issues. Implementing these methods also gives you the opportunity to warn the user in the event of an invalid SSL certificate. The best behavior is to fail with an error the user can’t accept for production builds. Conditional code that is never compiled into the production binaries (that excludes the risky code) is best. Make sure all production code has development oriented SSL code pruned out of it.
The long and short of it is that you have to actively work at making this insecure on iOS.
3 – Personal Data Leakage
This is less of a technical issue and more of a purposeful choice that must be made as a developer. Developers must take care to guard their user’s private information. Applications must protect their user’s personal data. Use the same data protection mechanism described in the previously discussed risk “Insecure or unnecessary client-side data storage” to protect personal user data. Beyond this it is an application design decision about how the application will handle the user’s personal data. Personal data privacy has become a hot topic and user’s are becoming much more aware that their private data may be at risk in mobile applications.
4 – Failure to protect resources with strong authentication
This issue is something of a server and client issue. Very little authentication is typically performed on a mobile device. The majority of the authentication that mobile devices encounter is oriented around a server authenticating a mobile application. Application’s on mobile devices rarely authenticate other services directly. If this does occur an application is usually being asked to share a resource, such as a photograph or some other piece of data managed by the application, with a server.
The main concern is that iOS applications properly authenticate to servers and that they implement strong authentication that uniquely identifies each mobile application user to the server. One of the main concern for developers is to never embed client side secrets in their application and then use those as an integral part of an authentication method.
5 – Failure to implement least privilege authorization policy
For the local side of things only request permissions you absolutely need. Does your application *really* need access to the user’s GPS? This falls more along the lines of protecting your user’s sensitive privacy oriented data. Be judicious with what resources you attempt to access.
The other part of this issue is server application oriented issue. The key issue at hand is that applications, especially thick-client oriented applications, may contain a great deal of functionality that is not available to lower privilege users. The server is responsible for checking that a user can perform a requested action. Even if the functionality is accessed in the application, the server must not allow lower privileged users to access and execute higher privileged server side functionality. Vertical privilege escalation is a constant risk to server side applications.
Horizontal privilege flaws allow users of mobile applications to easily circumvent authorization controls and access the data of other users at the same privilege level. Care must be taken to only allow a mobile application to access server side data that belongs to the currently authenticated user.
6 – Client-side injection
Client side injection is an interesting problem that can lead to a variety of issues depending on the application and how it operates. Many iOS applications utilize SQLite, which means that at some level those applications may be vulnerable to SQL injection. Often the consequences of SQL injection against a client side application are minimal.
A recent vulnerability in the Skype client for the Mac (I know, it isn’t an iOS app) illustrates the possibilities of “Rich User Environments” and the consequences they can have when an application implicitly trusts input.. The vulnerability was a simple cross site scripting attack that allowed remote code execution. Similar issues can surface in mobile applications if the application uses UIWebView or other rich environments and does not carefully check user (and other!) input.
The mitigation falls down to standard data validation. Any specific advice given here would be to specific to be useful in a general way. Make sure your data confirms to your expected length, range, type and format. Length is obvious, range is for data that has expected numerical ranges (positive integers only), type is for any sort of integer or other data structure being read and format is for the actual data formatting (such as phone numbers).
Data type is actually an interesting one. Any sort of serialized NS objects are inherently insecure and should never be trusted from a remote source. Similar to NIB files (serialized objects), they must only be used locally and only come from trusted sources. If a user can directly input objects into the system and manipulate them a variety of difficult to catch security bugs can result.
Another interesting issue is with format strings. From the comfortable confines of the NS* Objective-C environment it barely feels like you are writing code that gets compiled down to native instructions. Drop down to a library, like SQLite and that illusion is quickly shattered. Format strings using the %@ formatter are vulnerable to a variety of interesting attacks: ()
7 – Client-side DOS
This issue is fairly obvious. Make sure you are being a defensive programmer. This can result from development errors and bad logic. Modern mobile applications do a lot of parsing of formats such as XML and JSON. Defects in these parsers or in the way they are used can result in unexpected DoS.
8 – Malicious third-party code
Assume the device is jailbroken. Let me say that again: assume your user’s device is jailbroken. Act accordingly. Also, even on legitimate, non jail-broken devices there are interesting problems that can arise related to the URL / Protocol handling mechanism. iOS is not very big on Inter Process Communication. One of the few mechanisms available to iOS developers to accomplish this is the custom URL scheme. Use these with extreme caution. External (malicious) web sites can call these. The behavior when multiple applications define the same scheme is undefined (and you can’t stop an application from trying to usurp your scheme).
From iOS 4.2 and on there is a better IPC mechanism (application:openURL:sourceAppplication:annotation). If you need to perform IPC, use this. You can even pass real objects instead of hacking them up into a URL ready format (see: trusting serialized objects is a bad idea).
9 – Client-side buffer overflow
This is still quite possible. Since Objective-C is a strict superset of C there is no limit to the depth in which an iOS can get itself in trouble with old C programming issues. I won’t belabor them here, but they are quite possible. Pay careful attention to your string formatting (NSLog, etc.). Stick to the NS* class hierarchy when at all possible. Abstract away your C code to the smallest amount possible and be extremely cautious with any C string and memory operations.
10 – Failure to apply server-side controls
See: The OWASP Top 10.
Other Thoughts
For some other thoughts on iOS application security please visit our earlier blog post on the topic.
For some other
