1.1 Introduction

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.

1.2 Scope of work

The scope of the penetration test was limited to the following targets:

• Deployment scripts
• F-droid client

The scoped services are broken down as follows:

• Review of deployment scripts: 1 days
• F-droid client review: 3 days
• Reporting: 1 days
• Total effort: 5 days

1.3 Project objectives

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.

1.4 Timeline

The Security Audit took place between September 5, 2022 and September 19, 2022.

1.5 Results In A Nutshell

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.

1.6 Summary of Findings

1.7 Summary of Recommendations

2.1 Planning

Our general approach during penetration tests is as follows:

1. Reconnaissance
   We attempt to gather as much information as possible about the target. Reconnaissance can take two forms: active and passive. A passive attack is always the best starting point as this would normally defeat intrusion detection systems and other forms of protection afforded to the app or network. This usually involves trying to discover publicly available information by visiting websites, newsgroups, etc. An active form would be more intrusive, could possibly show up in audit logs and might take the form of a social engineering type of attack.
2. Enumeration
   We use various fingerprinting tools to determine what hosts are visible on the target network and, more importantly, try to ascertain what services and operating systems they are running. Visible services are researched further to tailor subsequent tests to match.
3. Scanning
   Vulnerability scanners are used to scan all discovered hosts for known vulnerabilities or weaknesses. The results are analyzed to determine if there are any vulnerabilities that could be exploited to gain access or enhance privileges to target hosts.
4. Obtaining Access
   We use the results of the scans to assist in attempting to obtain access to target systems and services, or to escalate privileges where access has been obtained (either legitimately though provided credentials, or via vulnerabilities). This may be done surreptitiously (for example to try to evade intrusion detection systems or rate limits) or by more aggressive brute-force methods. This step also consist of manually testing the application against the latest (2017) list of OWASP Top 10 risks. The discovered vulnerabilities from scanning and manual testing are moreover used to further elevate access on the application.

2.2 Risk Classification

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:

• Extreme
  Extreme risk of security controls being compromised with the possibility of catastrophic financial/reputational losses occurring as a result.
• High
  High risk of security controls being compromised with the potential for significant financial/reputational losses occurring as a result.
• Elevated
  Elevated risk of security controls being compromised with the potential for material financial/reputational losses occurring as a result.
• Moderate
  Moderate risk of security controls being compromised with the potential for limited financial/reputational losses occurring as a result.
• Low
  Low risk of security controls being compromised with measurable negative impacts as a result.

4.1 CLN-001 — XML parsers might be vulnerable to XXE attacks

Description:

Technical description:

SAXParserFactory factory = SAXParserFactory.newInstance();

Impact:

Recommendation:

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();
  }

4.2 CLN-002 — Vulnerable TLS versions accepted

Description:

Technical description:

Impact:

Recommendation:

4.3 CLN-003 — Encryption algorithms using insecure mode and padding scheme

Description:

Technical description:

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");

Impact:

Recommendation:

4.4 CLN-004 — Clear text traffic is enabled in the application

Description:

Technical description:

<base-config cleartextTrafficPermitted="true"/>

Impact:

Recommendation:

4.5 CLN-005 — HTTP Request URLs are logged

Description:

Technical description:

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).

Impact:

Recommendation:

5.1 Review of Nearby Swap Feature

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.

5.2 Review of Deployment Scripts

The deployment scripts at https://gitlab.com/fdroid/fdroid-http-fronters/ were reviewed for security issues; none were discovered.