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