The first in a series of IOS app testing blogs, this blog will focus on some of the more simplistic IOS app vulnerabilities and how to exploit them. I won’t be wasting time talking/walking through the methods exactly and explaining all syntax used etc. This first blog is just to show how easy it can be to bypass basic PIN security as well as why securing application data is imperative.
I have been messing with app security for a while now and decided it was time to start writing some of this down. Therefore I have picked an example app from the app store to demonstrate some of the basic issues that stem from poor coding and a lack of thought around security, in real world apps….cause let’s face it…..rooting a phone is really difficult with all those point and click exploits these days.
I decided it would be a good idea to pick (test) a password safe app, as obviously you would think that the whole idea would be to build an app around security and focus on protecting your passwords. Surely a hacker would have to undertake something like the “12 trials of Hercules” or some other mythological test to prove worthy of gaining access to a safe containing all my passwords…….well…………..maybe not, I have an idea – let’s just leave the back door wide open and while we are at it, let’s just stick a big ass sign “saying hello, the door can be opened when one says OPEN!!!”
Anyway, so to start.
So the first thing we need is a rooted phone with some basic tools: ssh – gain cli access, clutch – unencrypt apps, class-dump-z – dump class info, sqlite3 – sqlite database client and cycript – runtime app hooking tool.
The first thing I have done is launch the app, provide a PIN code of four digits as a key and enter one password for a user called Doug.
Okay so let’s start this by locating the databases on the phone with the find command:
find / -name *.sqlite
We can see that an entry comes back for the password app, based on its stored location. Let’s use SQLite3 to review the tables in the database and make sure that the app is storing encrypted or hashed passwords:
Oh dear both the PIN (1402) and any passwords (secretpass) can be viewed in clear text. So we are not storing info securely. This is something that is common amongst most apps I have reviewed, especially free apps.
Okay so next stage:
Most apps these days are encrypted to stop people from revealing the class information and gaining an understanding of the inner workings of the app and functions that the app runs. However smarter people than me have proven that where an app must decrypt to run in memory the app can in fact be pulled from memory unencrypted. There are a number of tutorials on how to do this. I am not going to show you, in fact I am going to take the easy way out and let Clutch take a step forward.
Clutch decrypts apps and dumps the unencrypted app for you:
The one thing I found was that it lied about where it said it was dumping the output, so another find command and we located the unencrypted app – yeah!
The reason we unencrypted the app was to review the class information (functions). Step forward class-dump-z ya wee beauty!!
Reviewing the class dump we are able to find some interesting information, like check password etc.
Now what we want to do is to run the application and interact with the application in memory to see if we can find away to bypass the PIN checking function. Cycript is the application we will use to hook the ios app as it runs in memory. So first thing to do is run ‘ps aux’ locate the process id and run cycript with the -p flag and the process id.
Now that we have the app hooked and the app on the front screen asking for a password we can locate the name of the app window running:
If we run AppDelegate.messages we can see the application messages which corresponds to the functions and variables found in the class dump we performed earlier:
So as per the above we can see that the app deletegate function contains messages for the check password boolan as discovered in the class dump. Now we can set the message for check password to always be true:
This results in the check of the PIN always equaling true. This again stems from apple advising that developers should use variable and function names that are intelligible. I am not saying that you should obfuscate names of variables or functions as obfuscation is not the answer but it does add additional complexity to working out what is going on in the app.
Let look at a login before we hooked the app:
Now that we have hooked the app and fixed the function, lets put in the wrong PIN – Boom we are in, regardless of the PIN we enter. This is because the check always equals true. Happy days! We have found two major flaws in the app. I hope this has been useful to someone, even if only to act as another example.
Looking forward to seeing part 2 – me too! LOL