--- layout: page title: Third Audit Report ---
For more information about this document and its contents please contact Radically Open Security B.V.
Version | Date | Author | Description |
---|---|---|---|
0.1 | September 19th, 2022 | Abhinav Mishra | Initial draft |
0.2 | September 28th, 2022 | Marcus Bointon | Review |
1.0 | September 28th, 2022 | Marcus Bointon | 1.0 |
Between September 5, 2022 and September 19, 2022, Radically Open Security B.V. carried out a penetration test for Tracking the Trackers
This report contains our findings as well as detailed explanations of exactly how ROS performed the penetration test.
The scope of the penetration test was limited to the following targets:
The scoped services are broken down as follows:
ROS will perform a penetration test of the F-droid client and review the deployment scripts with Tracking the Trackers in order to assess their security. To do so ROS will access the F-droid client app and the deployment scripts, and guide Tracking the Trackers in attempting to find vulnerabilities, exploiting any such found to try and gain further access and elevated privileges.
The Security Audit took place between September 5, 2022 and September 19, 2022.
During this crystal-box penetration test we found 2 Elevated and 3 Low-severity issues.
The review of the deployment scripts did not uncover any security issues. However, the F-droid client application had some misconfiguration. The elevated severity issues are about insecure configuration of TLS, where the application backend accepts TLS version 1.0 and 1.1. The other elevated severity issue is about a possible issue with the XML parser in the application.
Three low-severity issues were also discovered related to the Android app leaking URLs in the Android log, an insecure base network config, and the cryptography implementation in the app.
By exploiting these issues, an attacker might be able to capture the traffic between the Android client and the server, leak information from the device, perform XXE attacks etc.
ID | Type | Description | Threat level |
---|---|---|---|
Input validation |
The application's XML parser implementation might be vulnerable to XML External entity (XXE) attacks.
| Elevated | |
Insecure configuration |
The backend domains used by the application accept obsolete TLS 1.0 and TLS 1.1 protocols.
| Elevated | |
Weak Cryptography |
The encryption algorithms used in the app use an insecure mode and padding scheme.
| Low | |
Insecure configuration |
The base network config of the application allows clear-text traffic.
| Low | |
Information leakage |
The Android app (org.fdroid.fdroid.debug ver.
1.14-alpha3-505-gc8514adb9-debug) logs URLs.
| Low |
ID | Type | Recommendation |
---|---|---|
Input validation |
Limit resolution of external entities when XML input is parsed.
| |
Insecure configuration |
Unless support for legacy browsers/devices is needed, disable TLS 1.0 and TLS 1.1.
If TLS 1.0 support is required, disable TLS 1.0 compression to avoid CRIME attacks.
| |
Weak Cryptography |
Replace all uses of RSA/ECB/PKCS1Padding and
SHA1 with more secure alternatives.
| |
Insecure configuration |
Unless it is very explicitly needed for the app to work, do not allow or use unencrypted, clear-text traffic.
If it is needed, only allow it to explicitly permitted, trusted domains.
| |
Information leakage |
Avoid logging any sensitive information like
usernames, passwords, URLs, tokens etc in the Android log.
|
Our general approach during penetration tests is as follows:
Throughout the report, vulnerabilities or risks are labeled and categorized according to the Penetration Testing Execution Standard (PTES). For more information, see: http://www.pentest-standard.org/index.php/Reporting
These categories are:
We were able to gain information about the software and infrastructure through the following automated scans. Any relevant scan output will be referred to in the findings.
We have identified the following issues:
The application's XML parser implementation might be vulnerable to XML External entity (XXE) attacks.
The XML standard allows the use of external and internal entities. These are declared in the DOCTYPE of the document. When parsing an XML file or input, the content of the external entities is retrieved from an external storage such as the file system or network.
The following parts of the application implement an XML parser, which might be susceptible to XXE attacks.
Affected Instances:SAXParserFactory factory = SAXParserFactory.newInstance();
If the XML parser has no restrictions for external and internal entities, then this might lead to arbitrary file disclosures or server-side request forgery (SSRF) vulnerabilities when XML input is parsed.
Limit resolution of external entities when XML input is parsed. This can be done by:
DOCTYPE
handling is not necessary, disable support for all
DOCTYPE
declarations
In this case, we can use setFeature
for the SAX parser
to disable the DOCTYPE declaration completely:
try { factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); SAXParser saxParser = factory.newSAXParser(); PrintAllHandlerSax handler = new PrintAllHandlerSax(); saxParser.parse(FILENAME, handler); } catch (ParserConfigurationException | SAXException | IOException e) { e.printStackTrace(); }
In this code, if the SAX parser parses any external entities, it will throw an error.
The backend domains used by the application accept obsolete TLS 1.0 and TLS 1.1 protocols.
The Android app communicates with multiple domains. The TLS implementations on these domains accepts weaker TLS versions, specifically 1.0 and 1.1.
Affected InstancesThese obsolete protocols may be affected by well-known vulnerabilities such as FREAK, POODLE, BEAST, and CRIME.
As TLS 1.2 (on fdroid.tetaneutral.net) and 1.3 (on fdroid.tetaneutral.net) is also accepted, any communication using these later versions does not present a risk.
Android has provided support for TLS 1.2 since platform version 16, released in 2012 in Android 4.1 "Jelly Bean", so the term "legacy" would apply to devices older than that.
Use of TLS 1.0 and 1.1 make the communication susceptible to downgrade attacks, as they work on SHA-1 hash for the integrity of exchanged messages. The handshake authentication is also done on SHA-1, which makes it easier for an attacker to impersonate a server for MITM attacks. The PCI DSS (Payment Card Industry Data Security Standard) specifies that TLS 1.0 may no longer be used as of June 30, 2018, and also strongly recommends disabling 1.1, so this may impact compliance with regulations.
The encryption algorithms used in the app use an insecure mode and padding scheme.
The following sections of the application code contain cryptographically weak implementations:
Affected Instances:public ZipSignature() throws IOException, GeneralSecurityException { md = MessageDigest.getInstance("SHA1"); cipher = Cipher.getInstance("RSA/ECB/PKCS1Padding");
getLogger().debug("Sig File SHA1: \n" + HexDumpEncoder.encode(sfDigest)); getLogger().debug("Signature: \n" + HexDumpEncoder.encode(signatureBytes)); Cipher cipher = Cipher.getInstance("RSA/ECB/PKCS1Padding");
getLogger().debug("Sig File SHA1: \n" + HexDumpEncoder.encode(sfDigest)); getLogger().debug("Signature: \n" + HexDumpEncoder.encode(signatureBytes)); Cipher cipher = Cipher.getInstance("RSA/ECB/PKCS1Padding");
It is important to analyse the whole code base to see whether any other code is affected, and implement fixes there too, if needed.
Encryption operations should use a secure mode and padding scheme so
that confidentiality and integrity can be guaranteed. In this case, check the code to find
all instances where RSA/ECB/PKCS1Padding
and SHA1
are being used.
If sensitive data is being encrypted, then consider improving the
encryption mode and padding.
If sensitive data is being encrypted using an insecure mode and padding, it might lead to data being stolen or recovered from the encrypted data.
RSA/ECB/PKCS1Padding
and
SHA1
with more secure alternatives.The base network config of the application allows clear-text traffic.
The Network Security Configuration allows apps to customize their network security settings. These settings can be configured for specific domains and for a specific app, for example; customize which certificate authorities (CA) are trusted for an app's secure connections, protect apps from accidental usage of cleartext traffic etc.
The Android application
(org.fdroid.fdroid.debug ver.1.14-alpha3-505-gc8514adb9-debug
)
contains network_security_config.xml
with the following configuration:
<base-config cleartextTrafficPermitted="true"/>
This configuration allows the app to make connections to unencrypted resources.
Allowing clear-text traffic impacts confidentiality, authenticity, and protection against tampering. An attacker performing a machine-in-the-middle attack can eavesdrop on transmitted data and modify it without being detected.
The Android app (org.fdroid.fdroid.debug ver. 1.14-alpha3-505-gc8514adb9-debug) logs URLs.
We noticed that the application logs URLs in the Android log.
Note: This also applies to the production application version (org.fdroid.fdroid ver. 1.15.2).
Logging sensitive information in the Android log is not a recommended practice as this information can (in some scenarios) be accessed by other applications on the same device. URLs can contain tokens or other sensitive data which might be logged, leading to the disclosure of that data to other apps.
In this section we list some of the things that were tried but turned out to be dead ends.
During the pentest, we analysed the Nearby Swap feature of the application closely. This feature allows people to share installed apps with others, even without internet access (but both the parties must have the F-droid app). The F-droid app enables user to start a local web server, and host a page with links providing direct download of selected apps.
This feature was tested for multiple cases like exploiting the web server to access local device files, tricking the users into sharing additional apps, the download process, etc. No security issues were discovered during the test.
The deployment scripts at https://gitlab.com/fdroid/fdroid-http-fronters/
were reviewed for security issues; none were discovered.
We discovered 2 Elevated and 3 Low-severity issues during this penetration test.
The main purpose of this pentest was to determine the security issues in deployment scripts and the F-droid Android client app. No major security issues were discovered during the deployment script review, in the time available. However, the F-droid client app has some weaknesses that, when resolved, would give the application better defences against attacks, and would correspondingly improve protection of the app's users.
We recommend fixing all of the issues found and then performing a retest in order to ensure that mitigations are effective and that no new vulnerabilities have been introduced.
Finally, we want to emphasize that security is a process – this penetration test is just a one-time snapshot. Security posture must be continuously evaluated and improved. Regular audits and ongoing improvements are essential in order to maintain control of your corporate information security. We hope that this pentest report (and the detailed explanations of our findings) will contribute meaningfully towards that end.
Please don't hesitate to let us know if you have any further questions, or need further clarification on anything in this report.