All posts by Daniel Thomas

The lifetime of an Android API vulnerability

By Daniel Carter, Daniel Thomas, and Alastair Beresford

Security updates are an important mechanism for protecting users and their devices from attack, and therefore it’s important vendors produce security updates, and that users apply them. Producing security updates is particularly difficult when more than one vendor needs to make changes in order to secure a system.

We studied one such example in previous research (open access). The specific vulnerability (CVE-2012-6636) affected Android devices and allowed JavaScript running inside a WebView of an app (e.g. an advert) to run arbitrary code inside the app itself, with all the permissions of app. The vulnerability could be exploited remotely by an attacker who bought ads which supported JavaScript. In addition, since most ads at the time were served over HTTP, the vulnerability could also be exploited if an attacker controlled a network used by the Android device (e.g. WiFi in a coffee shop). The fix required both the Android operating system, and all apps installed on the handset, to support at least Android API Level 17. Thus, the deployment of an effective solution for users was especially challenging.

When we published our paper in 2015, we predicted that this vulnerability would not be patched on 95% of devices in the Android ecosystem until January 2018 (plus or minus a standard deviation of 1.23 years). Since this date has now passed, we decided to check whether our prediction was correct.

To perform our analysis we used data on deployed API versions taken from (almost) monthly snapshots of Google’s Android Distribution Dashboard which we have been tracking. The good news is that we found the operating system update requirements crossed the 95% threshold in May 2017, seven months earlier than our best estimate, and within one standard deviation of our prediction. The most recent data for May 2019 shows deployment has reached 98.2% of devices in use. Nevertheless, fixing this aspect of the vulnerability took well over 4 years to reach 95% of devices.

Proportion of devices safe from the JavaScript-to-Java vulnerability. For details how this is calculated, see our previous paper.
Proportion of devices safe from the JavaScript-to-Java vulnerability. For details how this is calculated, see our previous paper.

Google delivered a further fix in Android 4.4.3 that blocked access to the getClass method from JavaScript, considerably reducing the risk of exploitation even from apps which were not updated. A conservative estimate of the deployment of this further fix is shown on the graph, reaching 95% adoption in April 2019. On the app side of things, Google has also been encouraging app developers to update. From 1st November 2018, updates to apps on Google Play must target API level 26 or higher and from November 1st 2019 updates to apps must target API level 28 or higher. This change forces the app-side changes necessary to fix this vulnerability. Unfortunately we don’t have good data on the distribution of apps installed on handsets, but we expect that most Android devices are now secure against this vulnerability.

Our work is not done however, and we are still looking into the security of mobile devices. This summer we are extending the work from our other 2015 paper Security Metrics for the Android Ecosystem where we analysed the composition of Android vulnerabilities. Last time we used distributions of deployed Android versions on devices from Device Analyzer (an Android measurement app we deployed to Google Play), the device management system of a FTSE 100 company, and User-Agent string data from an ISP in Rwanda. If you might be able to share similar data with us to support our latest research work then please get in touch: contact@androidvulnerabilities.org.

LDAP based UDP reflection attacks increase throughout 2017

There have been reports that UDP reflection DDoS attacks based on LDAP (aka CLDAP) have been increasing in recent months. Our network of UDP honeypots (described previously) confirms that this is the case. We estimate there are around 6000 attacks per day using this method. Our estimated number of attacks has risen fairly linearly from almost none at the beginning of 2017 to 5000-7000 per day at the beginning of 2018.
Number of attacks rises linearly from 0 at the beginning of 2017 to 5000-7000 per day at the beginning of 2018

Over the period where Netlab observed 304,146 attacks (365 days up to 2017-11-01) we observed 596,534 attacks. This may be due to detecting smaller attacks or overcounting due to attacks on IP prefixes.

The data behind this analysis is part of the Cambridge Cybercrime Centre’s catalogue of data available to academic researchers.

Ethical issues in research using datasets of illicit origin

On Friday at IMC I presented our paper “Ethical issues in research using datasets of illicit origin” by Daniel R. Thomas, Sergio Pastrana, Alice Hutchings, Richard Clayton, and Alastair R. Beresford. We conducted this research after thinking about some of these issues in the context of our previous work on UDP reflection DDoS attacks.

Data of illicit origin is data obtained by illicit means such as exploiting a vulnerability or unauthorized disclosure, in our previous work this was leaked databases from booter services. We analysed existing guidance on ethics and papers that used data of illicit origin to see what issues researchers are encouraged to discuss and what issues they did discuss. We find wide variation in current practice. We encourage researchers using data of illicit origin to include an ethics section in their paper: to explain why the work was ethical so that the research community can learn from the work. At present in many cases positive benefits as well as potential harms of research, remain entirely unidentified. Few papers record explicit Research Ethics Board (REB) (aka IRB/Ethics Commitee) approval for the activity that is described and the justifications given for exemption from REB approval suggest deficiencies in the REB process. It is also important to focus on the “human participants” of research rather than the narrower “human subjects” definition as not all the humans that might be harmed by research are its direct subjects.

The paper and the slides are available.

1000 days of UDP amplification DDoS attacks

 

We presented “1000 days of UDP amplification DDoS attacks”¬†at APWG’s eCrime 2017 conference last week in Scottsdale Arizona. The paper is here, and the slides from Daniel Thomas’s talk are here.

Distributed Denial of Service (DDoS) attacks employing reflected UDP amplification are regularly used to disrupt networks and systems. The amplification allows one rented server to generate significant volumes of data, while the reflection hides the identity of the attacker. Consequently this is an attractive, low risk, strategy for criminals bent on vandalism and extortion. Despite this, many of these criminals have been arrested.

These reflected UDP amplification attacks work by spoofing the source IP address on UDP packets sent from networks that negligently fail to implement BCP38/SAVE. Since UDP (unlike TCP) does not validate the source address, the much larger responses go to the attacker’s intended victim as they spoof the victim’s address on the packets they send out. There are many protocols that can be exploited in this way including DNS and NTP.

To measure the use of this strategy we analysed the results of running a network of honeypot UDP reflectors from July 2014 onwards. We explored the life cycle of attacks that use our honeypots, from the scanning phase used to detect our honeypot machines, through to their use in attacks. We see a median of 1450 malicious scanners per day across all UDP protocols, and have recorded details of 5.18 million subsequent attacks involving in excess of 3.31 trillion packets. We investigated the length of attacks and found that most are very short, but some last for days.

To estimate the total number of attacks that occurred, including those our honeypots did not observe, we used a capture-recapture statistical technique. From this we estimated that our honeypots can see between 85.1% and 96.6% of UDP reflection attacks over our measurement period.

We observe wide variation in the number of attacks per day over the course of the measurement period as attacks using different protocols went in and out of fashion.

This work is ongoing and data from our honeypot network is available to researchers through the Cambridge Cybercrime Centre.

Also, if you want to help stop these attacks being possible you could help CAIDA by
running their spoofer prober software that checks which ISPs are negligently failing to implement BCP38/SAVE.