According to Appthority’s report, the unsafe usage of Firebase allows unauthorized access to the hole database by simply appending /.json to the server URL.
Following this tip, we search potentially vulnerable Apps in our Janus by using RULE. There are 14645 Apps are found enclosing this URL, the total unique URLs are 3632. We try these URLs later automatically by using script.
Surprisingly, we found there are still vulnerable projects on Firebase and gigabytes can be retrieved from these databases.
Rather than mitigating the attack case by case, it’s a more convenient way to fix this issue by refusing the /.json request. Since there are still Firebase project vulnerable to this flaw, we are curious about why Google does not fix this problem from the ground up.
During our regular App auditing, we noticed that, Waze, a community-based traffic and navigation App ranking Top 2 in the navigation category on the App Store, has multiple security issues and poses a significant attack surface for Waze users on iOS platforms. We tried to contact Waze via email and twitter many times but got no response.
In general, there are two categories of security issues.
1) Remote Memory Corruption, including out-of-boundary (OOB) access and use-after-free (UAF), which could lead to a remote denial-of-service (DoS) attack for any Waze user, or even a remote code execution in the context of Waze App. Among the numerous memory crashes, we post the following two figures, from which, you can find the instruction pointer register (%rip) already points to a heap address, resulting in a KERN_PROTECTION_FAILURE at 0x17046a580.
2) Remote Manipulation of Waze. A remote user could manipulate any Waze app and deliver a number of operations such as resetting navigation destinations. The video below demonstrates how a computer can remotely manipulate three Waze apps on different iPhones simultaneously.
In 2014, Pangu Team (@panguteam) founded PWNZEN InfoTech Co., LTD, a startup company at Shanghai, China, and expanded its research team to the Pangu Lab, with more general research interests from iOS jailbreaking, to IoT security, App security auditing, Android security, etc.
For Waze team, please email to bugs#pwnzen.com (‘#’ -> ‘@’) for the details of issues.
If you are interested in our services, please email to info#pwnzen.com (‘#’ -> ‘@’)
Waze is a community-based traffic and navigation App, which ranks Top 2 in the navigation category on the App Store. Once the App for iOS lunched, the App starts services on port 12345, 8776 for any connection and another safe port 55432 for localhost connection.
Reverse engineering shows that the service on port 12345 receives and processes remote command message and a valid message should start with WL. There are 3 problems with this service.
1) The first one is that for any incoming message that starts with WL, Waze caches the message until the memory resource exhausted. This is not a practical attack, for the attacker should consume the same network traffic to crash the App remotely.
2) The second problem is that a message with format WL|msgID|msgSize|msg will be accepted by this App for next stage process. Some valid messages are listed below.
By sending randomly generated messages follow this format, we find that we can crash the App remotely.
3) The last and the most serious problem is that, after a few sequential interaction, we can use the message, which msgID is set to 48, to send touch event to manipulate the Waze App, make traffic jams, navigate end-user to other place, showdown the navigation, for instance. PoC for this attack will be released until all end-users upgrade their Apps.
What makes the problem severely is that the service is provided for any connection, even if the App is working in cellular network. That means an attacker can probe the device using Waze in cellular network and access the device without authorization. An end-user depending on Waze for driving will lose service or be misled when a malformed message arrived.
In the binary of this App, we also find the build-in request 127.0.0.1:12345 for this service, it’s likely that the service is built for inner use, so, it’s redundant for this App to expose this service for any connection.
2018.6.20 Google confirmed this problem.
2018.6.4 Without acknowledgement, Waze removed the service on port 12345 to fix this problem in it’s last update, good job Waze!
2018.6.1 Video released.
2018.5.26 Contact Waze via email, twitter and website, but no response.
While auditing iOS Apps from various customers, Pangu Lab noticed a common programming error, which leads to severe consequences such as data overwritten and even code execution in the context of affected Apps. The problem is caused by the abusing of third-party unzip libraries, including SSZipArchive and ZipArchive. When using either of these 2 libraries to unzip a zip file, and the malformed filename or symbolic link enclosing in the zip file is not processed deliberately, a path traversal attack which lead to arbitrary file overwritten will pose the end-user in dangerous state. Query in our Janus platform reveals that 15,979 iOS Apps, including the most popular Apps, “weibo”, “momo”, “kwai”, “netease music” and “QQ music” are vulnerable to this vulnerability.
2. Details for ZipperDown Vulnerability
Both of the third-party libraries, SSZipArchive and ZipArchive, do not process the “../” in a filename, related code is listed below.
Listing 2: SSZipArchive does not process the malformed zip file
Besides the third-party libraries, if the developer does not check the validation of a zip file in their code, attacker can overwrite any file within the sandbox by using a malformed zip file.
3. Attack scheme for ZipperDown
3.1 ZipperDown for iOS
Schemes for ZipperDown attack are collected but not limit to the following. 1) By using SNS App or Tool App, which accept a malformed zip file from attacker and use SSZipArchive or ZipArchive to process the file. 2) If the App downloads zip file via HTTP protocol, then uses SSZipArchive or ZipArchive to process the file, attacker can replace the benign zip file with the malicious one by Wi-Fi hijacking.
3.2 ZipperDown for Android
Compared to ZipperDown for iOS, the vulnerability is more severity for Android App. The differences between iOS and Android App are listed below.
1) Policy for sandboxing is different. For iOS App, all executable code should be signed and the code is resided in a random path directory. In this case, it’s hard for an attacker to predict the path containing executable code to overwrite. Moreover, even the attacker can successfully overwrite the binary file in this folder, sandboxing in iOS prevents the code execution for the unsigned binary. But there is no limitation for Android App.
2) Policy for data transfer is different. Apple has enforced all data should be transferred by HTTPS protocol, which is an obstacle for an attacker to replace a zip file with a malicious one. But this is easier for Android App.
3) Third-party libraries which lead to ZipperDown is different. For iOS App, the problem is caused by using SSZipArchive or ZipArchive. But in Android, the framework provides ZipEntry class for developer to unzip a zip file. As libraries for iOS, the ZipEntry class does not check the malformed zip file as well. Although we find third-party libraries for Android developer , Janus shows that few Apps use these libraries.
To mitigate the ZipperDown vulnerability, we suggest that, 1) Upgrade third-party library for unzipping a zip file to the latest version. You can follow this patch for details. 2) Check the integration of the file before processing, check the hash value for instance.
When coming across with this problem, we are shocked by the sheer volume of affected Apps. After a profound consideration, we decide to disclose this problem for both third-party library developer and App vendor. In order to help the vendor and protect the end-user, details for this vulnerability is not make public in our initial disclosure, and only the potentially vulnerable Apps are listed in ZipperDown web site. We hope to make connection with developer in this way. In the collaborative process, 283 mails are received for consulting this problem, and 260 mails in total are replied after we verified the mail sender. After all, we hope all iOS developers pay attention to this problem and remove threat posed to their Apps. For Android App, we also suggest that you should visit Janus to make sure your App is not in the list.