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.
We presented “Configuring Zeus: A case study of online crime target selection and knowledge transmission” at APWG’s eCrime 2017 conference this past week in Scottsdale Arizona. The paper is here, and the slides from Richard Clayton’s talk are here.
Zeus (sometimes called Zbot) is a family of credential stealing malware which was widely deployed from 2007 to 2012 or so. It belongs to a class of malware dubbed ‘man-in-the-browser‘ (a play on a ‘man in the middle attack’) in that it runs on end-user machines where it can intercept web browser traffic to extract login credentials or to manipulate the page content displayed to the user.
It has been used to attack large numbers of sites, mainly banks — its extreme flexibility is achieved with ‘configuration files’ that indicate which websites are to be targeted, which user submitted fields are to be collected, what webpage rewriting (so called ‘webinjects’) is required and where the results are to be sent.
The complexity of these files seem to have restricted the number of websites actually targeted. In a paper presented at WEIS 2014 Tajalizadehkhoob et al. examined a large number of configuration files and described this lack of development and measured a substantial overlap in the content of different files. As a result, the authors suggested that offenders were not developing configuration files from scratch but were selling, sharing or stealing them.
We decided to test out this conjecture by seeking out messages about Zeus configuration files on underground forums (many of these are have been scraped, leaked or confiscated by law enforcement) — and this paper describes how we found evidence to support all three mechanisms: selling, sharing and stealing.
The paper also gives an account of the history of Zeus with illustrations from the messages that were uncovered along with clear evidence the release of tools to decrypt configuration files by security researchers was also closely followed on the forums, and assisted offenders when it came to stealing configuration files from others.
Last week I gave a keynote talk at CCS about DigiTally, a project we’ve been working on to extend mobile payments to areas where the network is intermittent, congested or non-existent.
The Bill and Melinda Gates Foundation called for ways to increase the use of mobile payments, which have been transformative in many less developed countries. We did some research and found that network availability and cost were the two main problems. So how could we do phone payments where there’s no network, with a marginal cost of zero? If people had smartphones you could use some combination of NFC, bluetooth and local wifi, but most of the rural poor in Africa and Asia use simple phones without any extra communications modalities, other than those which the users themselves can provide. So how could you enable people to do phone payments by simple user actions? We were inspired by the prepayment electricity meters I helped develop some twenty years ago; meters conforming to this spec are now used in over 100 countries.
We got a small grant from the Gates Foundation to do a prototype and field trial. We designed a system, Digitally, where Alice can pay Bob by exchanging eight-digit MACs that are generated, and verified, by the SIM cards in their phones. For rapid prototyping we used overlay SIMs (which are already being used in a different phone payment system in Africa). The cryptography is described in a paper we gave at the Security Protocols Workshop this spring.
Last month we took the prototype to Strathmore University in Nairobi to do a field trial involving usability studies in their bookshop, coffee shop and cafeteria. The results were very encouraging and I described them in my talk at CCS (slides). There will be a paper on this study in due course. We’re now looking for partners to do deployment at scale, whether in phone payments or in other apps that need to support value transfer in delay-tolerant networks.
At our security group meeting on the 19th August, Sergei Skorobogatov demonstrated a NAND backup attack on an iPhone 5c. I typed in six wrong PINs and it locked; he removed the flash chip (which he’d desoldered and led out to a socket); he erased and restored the changed pages; he put it back in the phone; and I was able to enter a further six wrong PINs.
I really like the simplicity of the original assumption. The starting point of the research was that different crypto/RSA libraries use slightly different elimination methods and “cut-off” thresholds to find suitable prime numbers. They thought these differences should be sufficient to detect a particular cryptographic implementation and all that was needed were public keys. Petr et al confirmed this assumption. The best paper award is a well-deserved recognition as I’ve worked with and followed Petr’s activities closely.
The authors created a method for efficient identification of the source (software library or hardware device) of RSA public keys. It resulted in a classification of keys into more than dozen categories. This classification can be used as a fingerprint that decreases the anonymity of users of Tor and other privacy enhancing mailers or operators.
All that is a result of an analysis of over 60 million freshly generated keys from 22 open- and closed-source libraries and from 16 different smart-cards. While the findings are fairly theoretical, they are demonstrated with a series of easy to understand graphs (see above).
I can’t see an easy way to exploit the results for immediate cyber attacks. However, we started looking into practical applications. There are interesting opportunities for enterprise compliance audits, as the classification only requires access to datasets of public keys – often created as a by-product of internal network vulnerability scanning.
We found that software on your smartphone can infer words you type in other apps by monitoring the aggregate number of context switches and the number of hardware interrupts. These are readable by permissionless apps within the virtual procfs filesystem (mounted under /proc). Three previousresearchgroups had found that other files under procfs support side channels. But the files they used contained information about individual apps– e.g. the file /proc/uid_stat/victimapp/tcp_snd contains the number of bytes sent by “victimapp”. These files are no longer readable in the latest Android version.
We found that the “global” files – those that contain aggregate information about the system – also leak. So a curious app can monitor these global files as a user types on the phone and try to work out the words. We looked at smartphone keyboards that support “gesture typing”: a novel input mechanism democratized by SwiftKey, whereby a user drags their finger from letter to letter to enter words.
This work shows once again how difficult it is to prevent side channels: they come up in all sorts of interesting and unexpected ways. Fortunately, we think there is an easy fix: Google should simply disable access to all procfs files, rather than just the files that leak information about individual apps. Meanwhile, if you’re developing apps for privacy or anonymity, you should be aware that these risks exist.
I am at the Privacy Enhancing Technologies Symposium (PETS 2016) in Darmstadt until Friday, and will try to liveblog some of the sessions in followups to this post. (I can’t do them all as there are some parallel sessions.)
When Lying Feels the Right Thing to Do reports three studies we did on what made people less or more likely to submit fraudulent insurance claims. Our first study found that people were more likely to cheat when rejected; the other two showed that rejected claimants were just as likely to cheat when this didn’t lead to financial gain, but that they felt more strongly when there was no money involved.
Our research was conducted as part of a broader research programme to investigate the deterrence of deception; our goal was to understand how to design better websites. However we can’t help wondering whether it might shine some light on the UK’s recent political turmoil. The Brexit campaigners were minorities of both main political parties and their anti-EU rhetoric had been rejected by the political mainstream for years; they had ideological rather than selfish motives. They ran a blatantly deceptive campaign, persisting in obvious untruths but abandoning them promptly after winning the vote. Rejection is not the only known factor in situational deception; it’s known, for example, that people with unmet goals are more likely to cheat than people who are simply doing their best, and that one bad apple can have a cascading effect. But it still makes you think.
The outcome and aftermath of the referendum have left many people feeling rejected, from remain voters through people who will lose financially to foreign residents of the UK. Our research shows that feelings of rejection can increase cheating by 15-30%; perhaps this might have measurable effects in some sectors. How one might disentangle this from the broader effects of diminished social solidarity, and from politicians simply setting a bad example, could be an interesting problems for social scientists.