Encrypted exploit delivery - #IRONSQUIRREL

This research deals with the delivery of encrypted browser exploits to a victim’s browser.

It is a follow-up post to some research I did 2 years ago.

Even if you are already familiar with the content of that research, you may still find valuable information in this post.

Introduction

In this blog I will propose that attackers who legitimately need to launch encrypted attacks (such as law enforcement agencies tracking suspect activity online) can reduce the threat of their attacks being nullified via reverse engineering. They can do this by using both encrypted and one-time URLs to deliver the exploit code.

For years, attackers have been using exploit kits to attack home and corporate computers by exploiting vulnerabilities in the browser or in one of the browser plugins (e.g. Flash, Java, Silverlight). Meanwhile, both oppressive regimes and law enforcement agencies started to deploy malware to their targets, via 0-day exploits.

One famous example is when Ahmed Mansoor was targeted by iOS Safari browser 0-day exploit. If you are not familiar with the case, I recommend reading the following:

https://citizenlab.ca/2016/08/million-dollar-dissident-iphone-zero-day-nso-group-uae/

Phishing text message

 

Ahmed did not fall for the phishing link – he sent it to Citizenlab instead. They analysed the network dump of the exploit traffic, and found the exploit code. They shared the exploit code with Apple, and Apple patched the vulnerability in days. Whoever was selling the exploit to the attackers lost a precious iOS Safari 0-day exploit.

Another famous example is the Tor browser exploit used by the FBI to target users of a paedophile website. If you are not familiar with the case, I recommend reading the following:

https://lists.torproject.org/pipermail/tor-talk/2016-November/042639.html 

Tor exploit code posted to Tor forum

Someone noticed the exploit code, was able to recover it from the browser and post it on the Tor mailing list. Mozilla fixed the vulnerability in days and the precious 0-day was lost.

I believe countless hours were spent by the community finding new vulnerabilities and developing new exploit code, but not enough research and energy was spent working out how to make the analysis of browser 0-days significantly harder. My research tries to fill this gap.

The solution

My research attempts to solve this issue so that attackers don’t lose their exploit code easily and can extend the lifetime of the 0-day from days to months.

My proposed solution uses key agreement between the exploit server and the browser. After the key agreement, the exploit code is delivered with AES encryption.

For key agreement, Ellyptic-curve based Diffie-Hellman is used. The Diffie-Hellman key agreement means that two parties can agree on a shared (common) secret over a public channel. Ellyptic-curve based Diffie-Hellman is only different in the way that it uses Ellyptic-curve fields instead of modular arithmetic. Both protocols are susceptible to MiTM, because there is no authentication of the other party.

Ellyptic-curve Diffie-Hellman (secp256k1) is used for key agreement and AES is used for encryption. By delivering the exploit code (and shellcode) to the victim in an encrypted way, the attack can not be replayed. Meanwhile the HTML/JS source is encrypted thus reverse-engineering the exploit is significantly harder.

Encrypted exploit delivery

Steps explained from the diagram above:

  1. the victim initiates a connection to a website which is controlled by the attacker
  2. the exploit server generates the private ECDH keys
  3. the exploit server sends the crypto libraries (JS), ECDH parameters and the server ECDH public key to the client
  4. the client browser generates its own private ECDH key, calculates the shared (common) secret in memory
  5. the client browser sends the client ECDH public key to the webserver
  6. the server can calculate the shared (common) secret
  7. the server sends the exploit code in an encrypted way to the client
  8. the browser can decrypt the exploit code, as it has access to the same secret. After decrypting it, the exploit Javascript code is evaluated, and is running
  9. if the exploit code is successful, the payload shellcode can do many things. For example it can initiate a malware download.
  10. the optionally encrypted malware is downloaded to the victim client
  11. the malware is decrypted and started

Besides the obvious point that the exploit code is not readable by default anymore, this encrypted exploit delivery has one extraordinary feature. The exploit is not replay-able anymore. Reverse engineers use exploit replay for browser exploit analysis all the time. With the exploit replay, it is possible to rerun the analysis as many times as needed. But the encrypted exploit breaks the replay-ability, because the browser will generate a different public key every time it runs, thus the same shared secret cannot be calculated by the client, and the exploit code cannot be decrypted.

But if the defenders/reverse engineers can trigger the exploit code as many times as they want, they still will be able to analyze it. And this is why attackers should use one-time URLs to deliver the exploit code. By using one-time URLs, reverse engineers have a one-time chance to analyze the exploit code. And this is not easy. If you have reversed any binary in Olly/Immunity/GDB in your life, imagine reversing an application where you cannot restart the application. After you stepped through a function, there is no way to go back.

There are many actions that I recommend for attackers and defenders, please check the resources for more.

Resources

Code on Github: https://github.com/MRGEffitas/Ironsquirrel

Please clone or fork the code, use it, submit issues and patches to it.

Video recording of my presentation: https://www.youtube.com/watch?v=eyMDd98uljI

Slides on Slideshare: https://www.slideshare.net/bz98/how-to-hide-your-browser-0days

This research has been already presented at Camp++ (Hungary), AlligatorCon (Poland) and SyScan360 (China). It is planned to be presented at Hacktivity (Hungary) and DeepSec (Austria).

 

 

 

Leave reply

 

Our partners