All posts by Daniel Thomas

About Daniel Thomas

Chancellor's Fellow (lecturer/assistant professor), Computer and Information Sciences, University of Strathclyde Visiting Researcher, Cambridge Cybercrime Centre, Department of Computer Science and Technology, University of Cambridge

Screenshot of the archived version of the Action Fraud website linked to from the NCA contact us page.

Reporting cybercrime is hard: NCA link to Action Fraud broken for 3 years

Cybercrime, Uncategorized, , , ,
Screenshot of the archived version of the Action Fraud website linked to from the NCA contact us page.
Archived version of Action Fraud website

Yesterday I was asked for advice on anonymously reporting a new crypto scam that a potential victim had spotted before they lost money (hint: to a first approximation all cryptocurrencies and cryptoassets are a scam). In the end they got fed up with the difficulty of finding someone they could tell and gave up. However, to give the advice I thought I would check what the National Crime Agency’s National Cyber Crime Unit suggested so I searched “NCA NCCU report scam” and the first result was for the NCA’s Contact us page. Sounds good. It has a “Fraud” section which (as expected) talks about Action Fraud. However, since 2019 this page has linked to the National Archives archive of an old version of the Action Fraud website. So for three years if you followed the NCA’s website’s advice on how to report fraud you would have got very confused until you worked out you were on a (clearly labelled) archive rather than the proper website, which is why none of the forms work.

I reported this problem yesterday and I do not expect it to have been fixed by the time of writing but this problem going unresolved for three years is a clear example of the difficulties faced by victims of cybercrime.

2019 is also the year that Police Scotland declined to pay for Action Fraud as they did not consider it to provide value for money and instead handle fraud reporting internally.

I am PI of a jointly supervised between the University of Strathclyde and the University of Edinburgh PhD project funded by the Scottish Institute for Policing Research and the University of Strathclyde on Improving Cybercrime Reporting. Do get in touch with other stories of the difficulties of reporting cybercrime. The student, Juraj Sikra has published a systematic literature review on Improving Cybercrime Reporting in Scotland. It is clear that there is a long way to go to provide person centred cybercrime reporting for victims and potential victims. However, UK law enforcement in general, and Police Scotland in particular know there is a problem and do want to fix it.

Three paper Thursday: Ethics in security research

Legal issues, Three Paper Thursday, ,

Good security and cybercrime research often creates an impact and we want to ensure that impact is positive. This week I will discuss three papers on ethics in computer security research in the run up to next week’s Security and Human Behaviour workshop (SHB). Ethical issues in research using datasets of illicit origin (Thomas, Pastrana, Hutchings, Clayton, Beresford) from IMC 2017, Measuring eWhoring (Pastrana, Hutchings, Thomas, Tapiador) from IMC 2019, and An Ethics Framework for Research into Heterogeneous Systems (Happa, Nurse, Goldsmith, Creese, Williams).

Ethical issues in research using datasets of illicit origin (blog post) came about because in prior work we had noticed that there were ethical complexities to take care of when using data that had “fallen off the back of a lorry” such as the backend databases of hacked booter services that we had used. We took a broad look at existing published guidance to synthesise those issues which particularly apply to using data of illicit origin and we expected to see discussed by researchers:

Continue reading Three paper Thursday: Ethics in security research →

The lifetime of an Android API vulnerability

Open-source security, Operating systems, ,

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

Cybercrime

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

Academic papers, Cybercrime, Legal issues, , ,

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

Academic papers, Cybercrime

 

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.