The open-source nature of the Android Open Source Project (AOSP) allows Original Equipment Manufacturers (OEMs) to customize the Android operating system, contributing to what is known as Android fragmentation. Google has implemented the Compatibility Definition Document (CDD) and the Compatibility Test Suite (CTS) to ensure the integrity and security of the Android ecosystem. However, the effectiveness of these policies and measures in warranting OEM compliance remains uncertain. This paper empirically studies for the first time the nature of OEM customizations in the Android TLS protocol stack, and their security implications on user-installed mobile apps across thousands of Android models. We find that approximately 80% of the analyzed Android models deviate from the standard AOSP TLS codebase and that OEM customizations often involve code changes in functions used by app developers for enhancing TLS security like end-point and certificate verification. Our analysis suggests that these customizations are likely influenced by factors such as manufacturers’ supply chain dynamics and patching prioritization tactics, including the need to support legacy components. We conclude by identifying potential root causes and emphasizing the need for stricter policy enforcement, better supply chain controls, and improved patching processes across the ecosystem.

The Web PKI ecosystem provides an underlying layer of security to many Internet protocols used today. By relying on Certificate Authorities (CAs), communication can be authenticated and encrypted based on a chain of trust. Unfortunately, this chain of trust has been broken in the past. For instance, in 2011, adversaries managed to issue fraudulent certificates on behalf of the DigiNotar CA, resulting in a loss of trust in DigiNotar. To better detect fraudulent certificates, Google introduced the concept of Certificate Transparency (CT), which is based on append-only logs that allow one to monitor and detect wrongly issued X.509 certificates.In this work, we investigate the potential of these logs as a data source for target reconnaissance. Concretely, we divide our study into two parts: First, we deploy several honeypot web servers over a period of 200 days to study the effect on incoming scanning traffic after pushing a certificate to one or more CT logs. We find that adding a certificate to a CT log leads to incoming network probes, just seconds after publishing the entry. This suggests that CT logs are used as input for web scans. In the IPv6 address space, our web server received 2,700 packets after pushing our certificate to a CT log, compared to 0 packets in our control group.Second, we use large-scale active measurements to find potentially vulnerable domains from CT log data. Using certificate issuance and renewal patterns, we identify websites that are either at the beginning or at the end of their life cycle. Our results show that freshly deployed websites are not more likely to contain a known CVE compared to websites that just renewed their certificate. On the other side of the spectrum, however, we find that websites with an expired certificate, yet still deployed in the wild, tend to contain more outdated software, and hence more known CVEs. As such, CT logs can indeed function as a data source for target reconnaissance.

Security misconfigurations and neglected updates commonly lead to systems being vulnerable. Especially in the context of websites, we often find pages that were forgotten, that is, they were left online after they served their purpose and never updated thereafter. In this paper, we introduce new methodology to detect such forgotten or orphaned web pages. We combine historic data from the Internet Archive with active measurements to identify pages no longer reachable via a path from the index page, yet stay accessible through their specific URL. We show the efficacy of our approach and the real-world relevance of orphaned web-pages by applying it to a sample of 100,000 domains from the Tranco Top 1M.