coelner/hacktricks
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

GitBook: [master] one page modified

Browse Source
This commit is contained in:
CPol 2021-05-10 12:55:29 +00:00 committed by gitbook-bot
parent d61fb62ec7
commit 838209caa4
No known key found for this signature in database
GPG Key ID: 07D2180C7B12D0FF
1 changed files with 44 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
ios-pentesting/README.md
View File

@ -167,10 +167,6 @@ After decompressing them you should see `<NAME>.app` , a zipped archive that con
There are multiple ways to define the UI in an iOS application: _storyboard_, _nib_ or _xib_ files.
### Plist
**plist** files are structured XML files that **contains key-value pairs**. It's a way to store persistent data, so sometimes you may find **sensitive information in these files**. It's recommended to check these files after installing the app and after using intensively it to see if new data is written.
### Binary
Inside the `<application-name>.app` folder you will find a binary file called `<application-name>`. This is the file that will be **executed**. You can perform a basic inspection of the binary with the tool **`otool`**:
@ -301,6 +297,8 @@ When a backup process is initiated the keychain **data backed up remains encrypt
* **kSecAttrAccessibleWhenUnlocked**: Items are secure at rest and when the device is locked. The items are only accessible when the device is unlocked.
* **kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly**: Like **kSecAttrAccessibleWhenUnlocked** but you a passcode must be set in the device. If the passcode is unset, these secrets are deleted from the device.
You can also select the "_**ThisDeviceOnly**_" on keychain objects to ensure that even the encrypted keychains objects **never leave the device during backups**.
The iPhone uses the **passcode introduced by the user unlocking the device to decrypt the secrets in the keychain**.
iOS uses the _**AppIdentifierPrefix**_ \(Team ID\) and the _**BundleIdentifier**_ \(provided by the dev\) to enforce **access control oven keychain items**. Then, the same team **can** **configure** **2 apps to share keychain items**.
@ -311,3 +309,45 @@ Tools like [**Keychain-Dumper**](https://github.com/ptoomey3/Keychain-Dumper) ca
In **iOS earlier than 10.3**, when an application is deleted from the device, iOS **doesn't clean up the keychain**. So on these devices you can **find secrets of deleted apps**.
{% endhint %}
### Cookies
iOS store the cookies of the apps in the **`Library/Cookies/cookies.binarycookies`** inside each apps folder. However, developers sometimes decide to save them in the **keychain** as the mentioned **cookie file can be accessed in backups**.
To inspect the cookies file you can use [**this python script**](https://github.com/mdegrazia/Safari-Binary-Cookie-Parser).
### Plist
**plist** files are structured XML files that **contains key-value pairs**. It's a way to store persistent data, so sometimes you may find **sensitive information in these files**. It's recommended to check these files after installing the app and after using intensively it to see if new data is written.
The most common way to persist data in plist files is through the usage of **NSUserDefaults**. This plist file is saved inside the app sandbox in **`Library/Preferences/<appBundleID>.plist`**
This data cannot be longer accessed directly via a trusted computer, but can be accessed performing a **backup**.
### Custom Keyboards
From iOS 8.0 Apple allows to install custom extensions for iOS like custom keyboards.
The installed keyboards can be managed via **Settings** &gt; **General** &gt; **Keyboard** &gt; **Keyboards**
Custom keyboards can be used to **sniff** the **keystrokes** and send them to the attacker server. However, note that **custom keyboards requiring networking connectivity will be notified to the user.**
Also, the **user can switch to a different** \(more trusted\) **keyboard** for introducing the credentials.
Moreover, **applications can prevent its users from using custom keyboards** within the app \(or at least for sensitive parts of the app\).
Note that because of auto-correct and auto-suggestions, the default iOS keyboard will capture and store each non-standard word word in a cache file if the attribute **securetTextEntry** is not set to **true** or if **autoCorrectionType** is not set to **UITextAutoCorrectionTypeNo.**
By default the keyboards store this cache inside the applications sandbox in `Library/Keyboard/{locale}-dynamic-text.dat` file. However, it might be saving the date elsewhere.
It's possible to reset the cache in _**Settings**_ &gt; _**General**_ &gt; _**Reset**_ &gt; _**Reset Keyboard Dictionary**_
**Therefore, check always these files and search for possible sensitive information.
Intercepting the network traffic is another way to check if the custom keyboard is sending keystroked to a remote server.**
### **Log Files**
The most common ways to debug code is using logging, and the application **may print sensitive information inside the logs**.
In iOS version 6 and below, logs were world readable \(a malicious app could read logs from other apps and extract sensitive information from there\). **Nowadays, apps can only access their own logs**.
However, an **attacker** with **physical** **access** to an **unlocked** device can connect it to a computer and **read the logs** \(note that the logs written to disk by an app aren't removed if the app ins uninstalled\).
To inspect the application logs, connect the iPhone to your computer and open _**Xcode**_ &gt; _**Devices**_ &gt; _**{Your device}**_ and you should see the live logs in the console.
It's recommended to **navigate through all the screens** of the app and **interact** with **every** UI element and **functionality** of and provide input text in all text fields and **review the logs** looking for **sensitive** **information** exposed.