HTML5-based data transfer for terrorists, pirates and investigators
Tue 6 Oct 2015
The software you’re reading this article with is, even in its factory state, probably enough to conduct acts of terrorism and piracy that are ‘extremely difficult, if not entirely impossible’ to intercept or examine forensically, according to one of the first research efforts to evaluate the threats and possibilities presented by the new emergence of HTML5-based transfer and communications services and tools.
HTML5 Zero Configuration Covert Channels: Security Risks And Challenges [PDF] by Jason Farina et al at the School of Computer Science & Informatics, University College Dublin, examines the recent crop of free and/or open source tools which leverage HTML5’s capabilities to manage peer-to-peer, node-avoiding, network-shy transfers, and finds the potential uptake of them to present a considerable challenge to security investigators wanting to decipher the packets, or even identify that the tools are currently in use and at least gather encrypted traffic for analysis.
Despite referring to fully authorised mainstream web browser applications such as Chrome, Firefox, Safari and Opera, the paper’s summary on the subject declares that the ‘ephemeral nature’ of recent HTML5 file transfer systems ‘can make any attempt to verify or re-create the circumstances of the file transfer difficult if not impossible,’ further emphasising that ‘investigation of the unauthorised transfer for information through one of these services without access to either end of the transfer can prove extremely difficult.’
The paper contends that the additional privacy afforded by the services it writes of ‘are open to abuse by cybercriminals’, providing them with off-the-shelf counter-forensic capabilities, and adds: ‘Cybercriminal activities such as data exfiltration, the distribution of illicit images of children, piracy, industrial espionage, malicious software distribution, and can all be aided by the use of these services.’
Blame Google for the secure HTML5 transfer tools
Not for the first time it is open source software that is facilitating ‘closed’ or secure channels of information, namely WebRTC (Real Time Communication), a browser-to-browser data transfer protocol that was developed by Google after its acquisition of ON2 in February 2010 and adopted into the official W3C standards for HTML5 the following year. The technology introduced data authentication, end-to-end encryption and source authentication via Datagram Transport Layer Security (DTLS) and the Modadugu and Rescorla extension, which facilitates secure handling of key exchanges for the Secure Realtime Transport Protocol (SRTP).
The research illustrates the difference between the older VOIP standard for exchange and the WebRTC approach. Both handle non-sensitive data via the establishment of control and signalling paths, but VOIP involves third-party relay servers into the exchange, putting the communication at risk of interception. Instead WebRTC uses Interactive Connectivity Establishment (ICE) to create a direct connection between two end clients. In the event of the communication needing to pass through a firewall which takes exclusive control of NAT transactions, WebRTC employs Session Traversal Utilities for NAT (STUN). If that should be blocked, WebRTC falls over to the Traversal Using Relay Nat (TURN) protocol – the only circumstances under which WebRTC will permit a ‘trusted’ intermediary server to become involved in the transaction.
Tools which use WebRTC for secure (and insecure) HTML5 transfer
Similarly the PipeBytes service, whilst advertising ‘unlimited size’ for file transfers (a prescription of HTML5 and your network connection, rather than any particular generosity on the part of the service itself) via drag ‘n drop, and whilst going to great lengths to ensure source and recipient authenticity, undoes all this good work by finally sending files over a plain text connection.
By contrast the report individuates the HTML5-enabled peer-to-peer service provided by sharefest.me as being particularly resilient against any attempts at interception or compromise, citing it as ‘an example of P2P privacy in a distributed network ensuring that data can be transferred without risk of interception’, and noting that the nature of its fully-encrypted traffic is ‘extremely difficult to determine’ for eavesdroppers.
Since ShareFest is publicly available on GitHub, including full instructions and support for installation on a user’s own server, along with the API key, bespoke use of the protocol is possible. On the negative side ShareFest generates identifiable STUN traffic, which the researchers were easily able to recognise and home in on – though this does not at all compromise the secure nature of the traffic in transit. However it does reveal the user; in a test, the researchers ran ShareFest, JustBeamIt and PipeBytes through a Tor circuit to ascertain if full anonymisation was possible, but all three protocols failed to complete under these circumstances.
Speak of the devil, and he’s…gone
The paper’s researchers emphasise the evanescent nature of HTML5-based transfer systems as the chief obstacle to security investigators. Prior to transfer taking place, permission tokens are generated which expire after 1000 seconds and cannot be reused, and no ‘server trail’ remain behind to audit. In the case of services involving P2P, the inevitable fragments are hard to find, expire quickly, are encrypted and would be of little or no use in reassembly even if they were less protected. The paper makes an analogy with the ‘unplugging’ problem that hinders security investigators on the spot, wherein vital evidence may be held long-term uncached in RAM memory, and can be removed without trace from existence just by removing the electricity. Likewise WebRTC leaves little or no history, and even the less secure applications set all downloaded components to expire on browser quit at the latest, often earlier.
Though none of the current crop of HTML5 file sharing and transfer systems are in themselves perfect, most allow of some potential modification which completely seals up the IP origin of the senders and recipients whilst maintaining impenetrable security for transit. Most of the applications that the paper examines are so recent as to be considered nascent or alpha implementations of the possibilities for WebRTC to provide truly zero-trace internet file and communications transactions. The paper concludes: