Penetration Test Report (Cure53): pentest report fdroid

Pentest-Report Bazaar / FDroid 01.2015
Cure53, Dr.-Ing. Mario Heiderich, Abraham Aranguren, Fabian Fäßler, Jann Horn
Index
Introduction
Scope
Identified Vulnerabilities
BZ -01-002 TOFU Requests too easy to recognize and intercep t ( Low )
BZ -01-003 Repository Fingerprin t is no t verified on firs t Fetch ( High )
BZ -01-004 Command Injection Flaw in roo t - based Installation Method ( Critica l)
BZ -01-005 App with WES Permission can replace APKs before Installation ( High )
BZ -01-007 Malicious symlinked APK can lead to arbitrary File Read ( Medium )
BZ -01-008 Multiple XSS Problems in WP - FDroid Plugin ( Medium )
BZ -01-011 Persisten t XSS via SVG Upload in MediaWik i ( Medium )
BZ -01-012 Arbitrary Command Execution via fdroid impor t and SVN ( Critica l)
BZ -01-013 Directory Traversa l Exploi t Potentia l caused by fdroid impor t ( High )
BZ -01-014 RCE via fdroid checkupdates Command on Gi t Repository ( Critica l)
BZ -01-015 SVN Repository Access leaks Credentials to loca l Processes ( Low )
BZ -01-017 Unauthorized Access to interna l Network Resources ( Medium )
Miscellaneous Issues
BZ -01-001 SHA 1 is used for Integrity Protection ( Info )
BZ -01-006 Symlinking is implemented using a Shel l Command ( Medium )
BZ -01-009 Malicious App can injec t additiona l Fields into aap t Outpu t ( Low )
BZ -01-010 Insecure PHP String Comparison in WP - FDroid Plugin ( Low )
BZ -01-016 Metadata Directive Injection using Newlines in Values ( Low )
Conclusion
1/17
Introduction
“Bazaar lets you download apps securely, and share the apps on your phone with
people in close proximity using whatever means are available (WiFi, Bluetooth, NFC,
SDCard, etc). It also audits your installed apps by comparing them to the versions that
other people have installed to make sure they are not malware. We are building upon
the FDroid free software app store for Android to improve the security of the process
while enabling decentralized and peer-to-peer distribution.”
From https :/ / dev . guardianprojec t . info / projects / bazaar /wiki
This test against several components of the FDroid application and service compound
lasted twelve days and involved efforts from four testers from the Cure53 Team. The test
yielded seventeen security issues and weaknesses total. Among them, two were
classified as ‘Critical’ in regard to their severity. The scope of this project was particularly
broad, since the assignment covered a server-side implementation (composed in
Python), an Android app, and a Wordpress Plugin (written in PHP). In addition, a
majority of services offered on the FDroid website were also examined.
Importantly, many issues discovered during this test and marked as ‘Critical’ and ‘High’ in
severity were caused by an overly large amount of trust put into the user-submitted
APKs and connected repositories. Once an attacker has control over one of APK or
repository, the command injections almost inevitably follow. Right then and there it is
possible for the attacker to take over the affected machines and spread the attack onto
other devices and phones. Consequently, the aforementioned issues should be treated
with a sense of urgency, and the possibility of this particular pathway of exploitation
should be promptly eliminated. Other problems spotted during the test entail classic web
security problems - for instance XSS1. Further, several bypasses for the XSS filter of the
MediaWiki software were spotted and should be reported to their respective maintainers.
Note: Some of the examples and demos listed in this report were run on a shared VM
that Cure53 has used for this test. Those links might no longer be available if the report
is read at a much later date. The IP addresses will be obfuscated prior to the publication
of the Report.
Scope
● Android Application
○ https :/ / gitlab . com / fdroid /fdroidclient
● Python Server Code
○ https :/ / gitlab . com / fdroid /fdroidserver
○ https :/ / f - droid . org / wik i / page / Installing _ the _ Server / Repo _ Tools
● ChatSecure Proposal
○ https :/ / dev . guardianprojec t . info / projects / bazaar / wik i / Bootstrapping _ Trust
● PHP Wordpress Plugin
○ https :/ / gitlab . com / fdroid / fdroidserver / tree / master / wp - fdroid
1 http :/ / en . wikipedia . org / wik i / Cross - site _ scripting
2/17
Identified Vulnerabilities
The following sections list both vulnerabilities and implementation issues spotted during
the testing period. Note that findings are listed in a chronological order rather than by
their degree of severity and impact, which is simply given in brackets following the title
heading for each vulnerability. Each vulnerability is additionally given a unique identifier
(e.g. BZ-01-001) for the purpose of facilitating any future follow-up correspondence.
BZ-01-002 TOFU Requests too easy to recognize and intercept (Low)
When a user adds a new repository without explicitly specifying a fingerprint, the FDroid
app fetches the file index.xml instead of the desired file index.jar. In the case of a plain
HTTP connection, this setup makes the fact of it being a “trusted-on-first-use” (TOFU)
request obvious for attackers. Henceforth the response can be manipulated without any
checks failing on the client.
It is recommended to always fetch index.jar instead and parse the ZIP file with signature
verification disabled. This should mitigate the possible MitM issue and safeguard the
necessary integrity of the response.
BZ-01-003 Repository Fingerprint is not verified on first Fetch (High)
A user might choose to add a repository without entering a fingerprint, yet he or she
might still manually verify the displayed fingerprint after the TOFU request has been
completed. Comparing fingerprints could easily be perceived as requiring much less
effort than entering them, with both presumably providing comparable levels of security.
Unfortunately, the FDroid app does not verify that the key provided during the TOFU
request has signed the application list in any way. Combined with the issue described in
BZ -01-002, the following attack scenario seems feasible:
1. A user adds the repository http :/ / trusted . example . org / without providing a
fingerprint, then presses “refresh” to load the repository’s data for the first time.
2. The app downloads index.xml from the repository.
3. An attacker intercepts the request. He notices that this is a TOFU request (see
BZ -01-002), then appends a unique marker like -backdoored to all file-names
and replaces the SHA-256 hashes2 of the APK files3 with the hashes of
backdoored variants. However, the attacker does not replace the repository’s
public key.
4. The user verifies that the repository’s signing key hash shown by the app
matches the expected one. In this scenario it does.
5. The user, confident that the repository data has not been tampered with,
downloads and installs the application.
6. The attacker sees a request to an APK file with the -backdoored marker and can
therefore replace the response without causing security checks to fail.
2 http :/ / en . wikipedia . org / wik i / SHA -2
3 http :/ / en . wikipedia . org / wik i / Android _ application _ package
3/17
7. The user installs the back-doored application.
8. After the user has refreshed the repository data again (or this has been done in
the background), the attacker loses his ability to provide manipulated APKs to the
client. Nonetheless, the transition to now accessing the real repository will not
trigger any security warnings for the victim.
It is recommended that for each and every case of the initial “fetch” of a repository that
reveals that the repository uses signing; all information apart from the signing key
(obtained without signature verification) should be discarded. After the key has been
obtained, the rest of the information received from the repository should be solely
verified with the use of that key.
BZ-01-004 Command Injection Flaw in root-based Installation Method (Critical)
A root-based installation met