RoB: Ransomware over Modern Web Browsers
File System Access (FSA) API enables web applications to interact with files on the users’ local devices. Even though it can be used to develop rich web applications, it greatly extends the attack surface, which can be abused by adversaries to cause significant harm. In this paper, for the first time in the literature, we extensively study this new attack vector that can be used to develop a powerful new ransomware strain over a browser. Using the FSA API and WebAssembly technology, we demonstrate this novel browser-based ransomware called RØB as a malicious web application that encrypts the user’s files from the browser. We use RØB to perform impact analysis with different OSs, local directories, and antivirus solutions as well as to develop mitigation techniques against it. Our evaluations show that RØB can encrypt the victim’s local files including cloud-integrated directories, external storage devices, and network-shared folders regardless of the access limitations imposed by the API. Moreover, we evaluate and show how the existing defense solutions fall short against RØB in terms of their feasibility. We propose three potential defense solutions to mitigate this new attack vector. These solutions operate at different levels (i.e., browser-level, filesystem-level, and user-level) and are orthogonal to each other. Our work strives to raise awareness of the dangers of RØB-like browser-based ransomware strains and shows that the emerging API documentation (i.e., the popular FSA) can be equivocal in terms of reflecting the extent of the threat
In this work, we implemented a novel browser-based ransomware, namely RØB – Ransomware over Browser, that performs its malicious actions via the emerging web technologies, the FSA API and WebAssembly (Wasm). Although the security model of the FSA API suggests restricting access to some of the system directories (e.g., file system root, user’s home, operating system), our experiments reveal that RØB can still encrypt files in user directories, data partitions, external storage devices (e.g., flash drives), shared network volumes, and cloud-integrated directories, making the suggested defense mechanism by the FSA API developers futile.
We found RØB can evade all these AVs. In addition to AVs, many highly accurate ransomware defense studies exist in the literature such as detection systems that employ static analysis or dynamic analysis features [52]. We examine their effectiveness against RØB-like ransomware; however, they, unfortunately, fail to detect RØB due to the distinct features such as not requiring any installation, running within the browser, and using Wasm-based encryption libraries. Hence, there is a need for a new solution that can effectively tackle browser-based ransomware attacks
We propose three potential defense solutions at different levels (i.e., browser-level, file-system-level, and user-level). Our first solution, namely malicious modification identification, monitors the FSA API to detect malicious modifications of RØB-like attacks before they overwrite the victim’s local files. Our second approach, namely local activity monitoring, monitors the browser’s local activity (e.g., read and write function/API calls, file system activities) to detect the potential patterns of ransomware. Our third solution aims to increase the (in)security awareness of users via a new UI design for the FSA’s permission dialog boxes. Unlike the existing dialog boxes of FSA API, the new dialog boxes we present inform users about the risks and implications of allowing web applications that utilize FSA API to interact with local files. These three proposed approaches are crucial to providing solutions to mitigate this new attack vector at different levels; however, neither of them is a panacea on its own due to the distinct features of this new attack vector. More research effort is needed to enable web ap
Overview
Figure 1. WACA framework architecture and key components
WACA is a keystroke-based privacy-aware continuous authentication framework that uses the accelerometer and gyroscope sensors of a smartwatch. WACA will consist of four main stages: Pre-processing, Feature Extraction, User Profiling, and Decision Module.
Backend Module. This module receives HTTP requests from clients (victims), it creates a public-private key pair and a unique ID for each victim. Keys and victim IDs are stored in its database. Afterward, it sends an HTTP response to the victim, which includes the other components of RØB, client ID, and the generated encryption keys for the client. The keys stored by the Backend module for each client are shared with the ones who make payments for the recovery of their files.
Web User Interface Module. This module includes the contents regarding the look of the website that aims to trick victims to enable RØB to access their local file system. The attacker can design the Web UI component differently depending on the malicious scenario. For example, this module can be designed by the adversary as a media (e.g., picture, video) editor.
File System Access Module. This module contains the necessary logic to interact with the victim’s files from the web application using the FSA API. RØB works in a read-encryptoverwrite loop for every file in the selected directory of the user. Encryption Module. This module includes the functions/modules to encrypt the victim’s files. RØB performs hybrid encryption on the victim files to make recovery attempts impossible for users. In our implementation, this module first generates a symmetric key and encrypts the victim’s files with AES-256. After the encryption of all of the files, it encrypts the AES key with RSA-2048 using the public key that is generated by the Backend module.
Extortion Module. This module redirects the user to the ransom note link that informs the victim about the ransomware attack and gives details regarding the ransom payment method.
Project Team Members
Publications:
- Abbas Acar, Wenyi Liu, Raheem Bayeh, Kemal Akkaya, and A. Selcuk Uluagac, “A Privacy-preserving Multi-factor Authentication System”, Wiley Security and Privacy, 2019. [pdf] [bibtex]
- Abbas Acar, Hidayet Aksu, Kemal Akkaya, and A. Selcuk Uluagac. “WACA: Wearable-Assisted Continuous Authentication.” Security and Privacy Workshops (SPW), 2018 IEEE. IEEE, 2018. [pdf] [bibtex]
- Abbas Acar, Hidayet Aksu, Kemal Akkaya, and A. Selcuk Uluagac. WACA: Wearable-Assisted Continuous Authentication Framework with Motion Sensors. In Proceedings of the 25th Usenix Security Symposium, 2016 (poster). [pdf] [bibtex]
Invention Disclosures:
- Abbas Acar, Hidayet Aksu, A. Selcuk Uluagac, and Kemal Akkaya, “A Method for Continuous User Authentication with Wearables,” Filed to US Patent and Trademark Office (US 15/674,133), August 2017. [link] [bibtex]
Presentations and Talks:
- Abbas Acar, Hidayet Aksu, Kemal Akkaya, and A. Selcuk Uluagac. WACA: Wearable-Assisted Continuous Authentication Framework. Presentation of the accepted paper at 39th IEEE Symposium on Security and Privacy Workshops, San Francisco, CA, May 24, 2018.
- Abbas Acar, Hidayet Aksu, Kemal Akkaya, and A. Selcuk Uluagac. WACA: Wearable-Assisted Continuous Authentication Framework with Motion Sensors. Poster Presentation at Florida Institute of Cybersecurity Research Annual Conference on Cybersecurity, University of Florida, Gainesville, March 1, 2018. [poster]
Media Coverages:
- Abbas Acar, Amit Kumar Sikder, Leonardo Babun, and A. S. Uluagac,”Experts talk cyber attacks on business, lead live hack,” FIU News, Gisela Valencia, December 21, 2017
** Project Name: SaTC: TTP: Small: Collaborative: Privacy-Aware Wearable-Assisted Continous Authentication Framework
Project Sponsor: National Science Foundation
Project Duration: August 15, 2017 – July 31, 2019 (Estimated)
Award Number: 1718116.
