Blog

RSS

What Happens When Your Vulnerability is Weaponized for Botnet Proliferation

Written by

Larry Cashdollar

January 26, 2021

Larry W. Cashdollar has been working in the security field as a vulnerability researcher for over 18 years, and is currently a member of the Security Incident Response Team at Akamai Technologies. He studied computer science at the University of Southern Maine. Larry has documented over 150 CVEs and has even presented his research at BSides Boston, OWASP Rhode Island, and Defcon. He enjoys the outdoors and rebuilding mini-bike engines in his spare time.

An examination of exploits used by the KashmirBlack botnet

Not too long ago, I read a couple of excellent articles by Sarit Yerushalmi and Ofir Shaty on their research of the KhasmirBlack botnet, which are published here and here.

Their articles described the KashmirBlack botnet infecting sites via various exploitable WordPress plugins. One of the things I noticed is that the botnet used some of my own vulnerability disclosures, so I decided to investigate how the botnet was using these vulnerabilities to propagate itself.

This post will focus on the weaponization of a few of the exploits only, as Sarit and Ofir documented everything else. I'll examine two of the exploits I disclosed a few years ago, as well, to satisfy my own morbid curiosity. After some Google Dorking, where I was searching for a certain file used by the botnet, I discovered an infected site and downloaded the malware to a local virtual machine. 

The Zip files I discovered were password-protected, with the password 'adeliaputri1996'. The password was found in the unarchiving script documented by Sarit Yerushalmi and Ofir Shaty. After unzipping all of the archives, I see the botnet is written in Python, and has a bunch of command-line utilities for propagation and exploitation of targets. The SHA 256 sums of the initial directory of python scripts are below. 

I focused specifically on jq.py and wpxp.py, since those contain exploitation code for some of the vulnerabilities I discovered back in 2015 and 2018, which were assigned CVE IDs CVE-2015-1000013 and CVE-2018-9206 respectively. First off, jq.py is a Python script that takes a list of the target hosts in a flat text file as an argument. The script uses threading to speed up the scanning of hosts for vulnerable installations of BlueImp's jQuery application.

The KashmirBlack CVE-2018-9206 exploit scans a list of 85 unique paths, which I believe the botnet author collected, either via Google Dork or from their own exploitation experiences. It checks these paths by making POST requests to upload files to them. The script then checks whether the existence of its uploaded payload file sssp.php exists or not in the corresponding upload files/ directory.

  
  Public/lib/metronic/assets/global/plugins/jquery-file-upload/server/php/ test/assets/plugins/jquery-file/upload/server/php/ update/UserControl/assets/jquery-file-upload/server/php/ site/assets/global/plugins/jquery-file-upload/server/php/ blueimp-jQuery-File-Upload/server/php/ pixel/photobook/assets/jquery-file-upload/server/php/ support/vendor/jquery-file-upload/server/php/ . . . assets/global/plugins/jQuery-File-Upload/ public/vendor/jquery-file-upload/ static/plugins/jquery-file-upload/ static/js/jquery-file-upload/ core_web/javascript/jQuery-File-Upload/ 

A full list of paths is available here.

Based on these paths, we may be able to infer other applications that used vulnerable versions of Blueimp jQuery code. For example, Metronic might have been impacted by CVE-2018-9206. 

The wpxp.py python script implements various exploits for a plethora of file upload vulnerabilities in WordPress plugins. This attack tool also takes a list of target sites stored in a flat text file as a command-line argument.

The attack tool exploit code contains variables storing the path, post data, and variable name to build the exploitation POST request for each vulnerability. It's a modular way to exploit the same type of vulnerability for many different impacted software vendors. 

During my analysis, I also noticed an admin login brute force attack tool named wpl.py.  This leads me to believe that not only are vulnerable plugins and CMS installations a clear risk, but weak login credentials are still a major vector in getting sites infected with malware.

Again, this attack tool uses the same threaded python code as the other tools to increase its scanning efficiency. 

Conclusion

As a researcher, I'm sometimes curious how some of the vulnerability disclosures I've made will fold into the threat landscape ecosystem. I believe this is the first time I've discovered that some of my CVEs were being used to propagate a botnet while reading an article. As always, awareness of vulnerabilities in your software and maintaining patches on your systems, along with strong passwords and multi-factor authentication, are the foundation of building a secure system. 

 



Written by

Larry Cashdollar

January 26, 2021

Larry W. Cashdollar has been working in the security field as a vulnerability researcher for over 18 years, and is currently a member of the Security Incident Response Team at Akamai Technologies. He studied computer science at the University of Southern Maine. Larry has documented over 150 CVEs and has even presented his research at BSides Boston, OWASP Rhode Island, and Defcon. He enjoys the outdoors and rebuilding mini-bike engines in his spare time.