[EN] A-Z: Documents - hacking web app inside iOS app
Documents is an iOS file manager app developed by Readdle. It has an HTTP server feature, which allows easy file transfer between the device and a computer in a local network. It’s also very interesting from the security perspective because we can expect a wider attack surface than in a typical mobile application. Running an HTTP server may expose the application to many kinds of web-related attacks.
User types device’s IP address in a desktop browser.
On the device, a randomly generated PIN appears.
The user rewrites the PIN from the app to the browsers.
The user becomes authenticated and granted access to the app data.
The application displays user-controllable data, so I decided to check if it can be abused somehow.
I created a directory with a payload <img src=x onerror=alert(2)> in its name. (yeah, these characters are completely legal on iOS, macOS, Linux, etc.), but nothing happened - the directory name was displayed correctly.
However, there’s one more place where these names are displayed. It’s a current directory path, above file list, which is not so obvious while being in the root path. I entered my malicious directory and the payload executed - it was improperly displayed exactly in this place.
Ok, so I XSSed myself and that’s it? Of course not!
I started wondering how this vulnerability could be used in a real-life scenario. I asked myself two questions, which lead me to a scenario requiring a little interaction with a victim.
How to put malicious directory in on a victim’s device?
How to convince the victim to open in it in a browser?
An attack without user interaction would be awesome, but I didn’t find a way to do it.
Payload in directory name is a must, but it is possible to hide it a little bit. Documents handle zip files - by tapping an archive the app automatically unpacks it. On the other hand, Documents (and iOS itself) does not handle many common file formats like docx. So the user seeing docx may try opening it on the desktop.
Summarizing these steps:
1. Create malicious directory
2. Create a docx file:
3. Zip it.
4. Send it to a victim (for example using email or any communicator).
5. The victim saves the attachment in Documents, unpacks it, notices a file in the unsupported format, then decides to open the file on the desktop.
6. The victim opens the browser navigates to Documents HTTP server.
7. The victim enters a directory from the archive - payload executes.
I couldn’t forget about payload. Popping alert is always fun, but what real harm could be done?
XSS gives full control over the affected web page (in a range of origin). So the first thing which came to my mind was just to steal files. Payload could read a list of files and directories and recursively go through them (download) and send them to the attacker’s server. I created PoC, but for quicker development, I decided to steal one file which path was hardcoded in payload.
This code would dynamically add script from http://172.20.10.2:8000/1.js. This is the IP of the attacker’s server (it could be an address on the local network or the Internet).
Content of 1.js file:
And simple python HTTP server to server 1.js and receive stolen files:
When I was looking for XSSes I noticed one more thing. Device’s name is always displayed in the top-left corner (m in screenshots), so I changed my device’s name to check if it’s also vulnerable.
But for this one, I didn’t find any practical way to use it. Unless you convince someone to change their device’s name. ;)
Lack of authorization
The next thing on which I focused was proper authentication and authorization. I started with the most obvious mechanism - code verification. With no luck for me, the application properly handled code guessing and usage of unusual characters.
Let’s look at how this process works:
We send our verification code, then we receive authentication status.
2. If our code is correct, we attach it as Session-Id header in further requests.
So, the application recognizes a legitimate user by Session-Id header. I spent some time in the web interface using different functionalities, collecting requests. Then, I went through captured traffic to check if all of the requests include this header and what would happen if I removed it.
These requests drew my attention:
The application doesn’t provide only an HTTP interface, but also Web Socket. Additionally, GET /rdwifidrive/web_socket_url is sent without Session-Id header. The application responds with a web socket URL even to unauthenticated users, so I analyzed web socket communication to ensure how authentication is handled in the WS layer.
Yes, no authentication at all and the server responds with paths of photos from Camera. The application has (of course if you grant) permission to Photos, which are available in Photo Albums directory (look at the second screenshot).
These paths are then used to get (large resolution) thumbnails of photos.
Something’s missing in this request too. Session-Id again.
Putting things together, what can be done without authorization:
Get the WebSocket URL.
Connect to WebSocket and get Photos paths.
Download photos using the received path.
It could be enough to steal photos from users in our local network. However, there’s one more thing, which you may have noticed already:
The server relaxes Same-Origin Policy that these requests can be issued from any domain making the application additionally vulnerable to CSRF. It extends exploitation possibilities, because this attack may be performed over the Internet.
Summarizing the whole issue, how attack could be performed:
Attacker prepares a malicious website which:
Gets WebSocket URL from a device
Connects to the WebSocket and gets Photos paths
Downloads photos using received paths
Sends downloaded photos to the attacker’s server
Attacker tricks a victim into opening its page
The website performs steps 1.1 - 1.4, finally stealing photos.
Now, the last question may come to our minds - how the attacker may know an IP address of a victim’s device? There are two answers:
If a victim is connected to a WiFi network - IP must be guessed.
If a victim uses tethering - a device’s IP is always the same - 172.20.10.1.
For this vulnerability I also prepared PoC. It consists of:
1. Malicious website: index.html
2. Python server serving index.html and receiving photos.
These vulnerabilities were submitted to Readdle in August 2019. They quickly responded and started working on fixes. The same month Readdle updated the application. Readdle rewarded me $1100 for these findings and announced they’re going to start the official Bug Bounty program.
Written on December 8, 2019 by
We invite you to contact us
through the following form:
By sending an inquiry you agree that the LogicalTrust Company can contact you (e-mail, telephone) and send you its offer.
LogicalTrust sp. z o.o. sp. k.
al. Aleksandra Brücknera 25-43 51-411 Wrocław, Poland, EU