[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:
LogicalTrust sp. z o.o. sp. k.
al. Aleksandra Brücknera 25-43 51-411 Wrocław, Poland, EU
According to art. 13 of the General Regulation on the Protection of Personal Data of 27 April 2016 (Official Journal EU L 119 of 04.05.2016) I inform that:
1) the administrator of your personal data is Logicaltrust Sp. z o.o. Sp. k. - al. Aleksandra Brücknera 25-43, 51-411 Wrocław,
2) contact with the Personal Data Administrator - firstname.lastname@example.org,
3) Your personal data will be processed for marketing purposes on the basis of Art. 6(1)(a) of the general regulation on the protection of personal data of April 27, 2016..
4) Your personal data will be stored until you withdraw your consent
5) You have the right to request from the administrator access to personal data, the right to rectify their removal or limit processing, the right to withdraw consent and the right to transfer data
6) You have the right to lodge a complaint with the supervisory authority
7) Your data will be processed in an automated manner, including in the form of profiling. Automated decision-making will take place on the principles set out in the regulations (options: subscription, competition, etc.) and the consequence of such processing will be receiving selected marketing information
8) providing personal data is voluntary, however failure to provide data may result in the inability to participate in the newsletter subscription, participate in contests, receive marketing offers, participate in surveys
At the same time, pursuant to Art.6(1)(a) of the general regulation on the protection of personal data of 27 April 2016, I agree to the processing of my personal data for the purpose of subscribing to the newsletter, participation in competitions, receiving marketing offers, participation in surveys