mitchell/RE-iOS-Apps
1
0
Fork 0
mirror of https://github.com/ivRodriguezCA/RE-iOS-Apps synced 2026-01-09 02:22:48 +00:00
Code Issues Releases Wiki Activity

minor: week -> weak

Browse Source
This commit is contained in:
Ben Gras
2019-04-11 11:24:09 +02:00
parent d75ebf4096
commit 72c9ff404c
1 changed files with 4 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
Module-3/README.md
View File

@@ -23,7 +23,7 @@ mv CoinZa.app/* CoinZaFiles/
#### Analyzing embedded files
Your end goal is to understand as much as possible what the developers are shipping with every application. It's a good idea to start by looking for _low-hanging fruit_ kind of issues. In iOS reversing these come as configuration files, example data files, database connection files or embedded private keys for SSH connections. Yes, as I've said before, I've seen all of these cases in real applications.
- The two most common configuration files I've encountered in iOS applications are `.plist` and `.json`. Start your research by reading through all the files you can find with these extensions and see if you can find some information that **should not be there**.
- A very important file is the `Info.plist` in the root directory of an iOS application. This file contains a lot of configuration data like if the application _enables_ week TLS settings on some domains (search for the `NSAppTransportSecurity` key), or if the application accepts custom [`Scheme URLs`](https://developer.apple.com/documentation/uikit/core_app/allowing_apps_and_websites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app) (search for the `CFBundleURLTypes` key).
- A very important file is the `Info.plist` in the root directory of an iOS application. This file contains a lot of configuration data like if the application _enables_ weak TLS settings on some domains (search for the `NSAppTransportSecurity` key), or if the application accepts custom [`Scheme URLs`](https://developer.apple.com/documentation/uikit/core_app/allowing_apps_and_websites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app) (search for the `CFBundleURLTypes` key).
#### Analyzing 3rd party frameworks
Almost every single iOS application uses at least one 3rd party framework. As a security researcher this is very important because this increases the attack surface and more often than not the developers forget to update their dependencies and the bigger the list of dependencies, the harder it is to keep track of updated versions. This means that as long as an application "still works" there's no incentive to update these 3rd party frameworks. This leaves users with outdated, and potentially vulnerable, code on their devices. All the 3rd party framework within an iOS bundle live in a folder called `Frameworks`.
@@ -136,7 +136,7 @@ if (iVar1 == 0) {
![Hopper Pseudo-code Mode](https://github.com/ivRodriguezCA/RE-iOS-Apps-Extras-Github/blob/master/Module-3/ghidra1.png?raw=true)
#### Conclusions
- A static analysis on an iOS application can take you as little or as long as you want. You can go as deep as you can. Specially because the same techniques used to inspect the main application binary can be used to reverse engineer the 3rd party frameworks' binaries. I personally spend many days, and sometimes even many weeks, performing static analysis on iOS applications. _Note: The first mobile bug I was ever rewarded for on [HackerOne](https://hackerone.com) was a week encryption vulnerability, specifically an insecure encryption key generation, basically I was able to predict past and future encryption keys. This was possible because I spent a lot of time understanding their key generation algorithm and was finally able to understand its behaviour without even running the application, all via static analysis._
- A static analysis on an iOS application can take you as little or as long as you want. You can go as deep as you can. Specially because the same techniques used to inspect the main application binary can be used to reverse engineer the 3rd party frameworks' binaries. I personally spend many days, and sometimes even many weeks, performing static analysis on iOS applications. _Note: The first mobile bug I was ever rewarded for on [HackerOne](https://hackerone.com) was a weak encryption vulnerability, specifically an insecure encryption key generation, basically I was able to predict past and future encryption keys. This was possible because I spent a lot of time understanding their key generation algorithm and was finally able to understand its behaviour without even running the application, all via static analysis._
- Many developers don't realize that any file they embed in their application will be very easy to extract and analyze.
- As researchers is very good idea to check the 3rd party frameworks bundled with the application.
- Gather as much information as you can on this step because you'll use it in the dynamic analysis step.
@@ -153,8 +153,8 @@ if (iVar1 == 0) {
- **The problem:** Even though the developers were thinking about protecting their users' generated content by encrypting the database, they did so by hard-coding a secret key that **all** installations of their app would use. This is a little bit harder to exploit but if an attacker is able to, for example, get a hold of users' _not encrypted_ iTunes backups, they will be able to decrypt the databases because **all** databases are using the same secret key.
- **Recommended fix:** Generate a secret key per installation and store it in the [iOS keychain](https://developer.apple.com/documentation/security/keychain_services), this way attackers would have to compromise the devices of every victim and that's a considerable harder attack.
- `NSAllowsArbitraryLoads`: Disables [App Transport Security](https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40009251-SW33) (aka ATS), allowing week TLS configurations.
- **The problem:** Apple introduced ATS to protect users from week and vulnerable TLS configurations, disabling this feature means that this application puts the security and privacy of the end user at risk.
- `NSAllowsArbitraryLoads`: Disables [App Transport Security](https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40009251-SW33) (aka ATS), allowing weak TLS configurations.
- **The problem:** Apple introduced ATS to protect users from weak and vulnerable TLS configurations, disabling this feature means that this application puts the security and privacy of the end user at risk.
- **Recommended fix:** Remove this key from the `Info.plist` and work with the backend engineers to update the servers' TLS configuration.
- `CFBundleURLTypes`: Having custom `Scheme URLs` is not an issue, but it means this app can be launched by other applications using the `coinza://` scheme URL and it probably takes some parameters with it. Just take a note about this feature, it will be helpful on the next module's exercises.