Openvas Credentials Hunt — Part II
In my last post, I described how it is (was?) possible to use the OpenVAS Download an EXE package for Microsoft Windows feature to extract username and passwords stored as credentials in the open-source vulnerability scanner. What I did not tell last time is that this same feature also can be used as a privilege escalation vector if the stars are properly aligned.
Imagine you are an OpenVAS administrator and you want to use the before mentioned feature to deploy a credential that will be used to scan your Windows servers. Despite the solution you choose to deploy the package to your servers when the executable responsible for creating the credential runs, it will need administrative privileges to work. Otherwise, Windows won’t let the credentials be created with an access denied error. With that in mind, we can then safely assume that, if this feature is being used, at some point in time the deployment package will be executed with administrative privileges. How often this occurs is not something we will concern ourselves with. The package execution can be a single task executed only for new machines or it could be something done regularly by a GPO or any other management tool.
So how can this feature be used for privilege escalation? Before adding the user to the local administrator group, the OpenVAS credential deployment package checks what’s the name of the local administrators’ group. Once the name is known it is saved to a file called AdminGroupName.txt inside the %TEMP% directory. The credential deployment package then reads the file AdminGroupName.txt content and concatenates it in a command line like net localgroup ${content from AdminGroupName.txt} ${package usename} /add. There are two major problems here, the first one is that the AdminGroupName.txt are blindly inserted into the command line without any sort of sanitization or checks. The second one is that the file is read from the %TEMP% directory, which when running under the LocalSystem authority will map to C:\Windows\Temp, a globally writable directory. What that means is that an attacker aiming to gain administrative privileges in a machine in which the credential deployment package is run regularly can pre-create the C:\Windows\Temp\AdminGroupName.txt with content similar to the following and make it read-only afterward.
{administrator’s group name} {hostname}{credential username} /add & {some malicious payload}& echo
When the credential deployment package runs it won’t be able to overwrite the tampered file because of the read-only flag but this won’t stop it from executing the next execution step and the attacker’s payload will be executed as well.
If you have access to an OpenVAS instance and want to test it yourself, download a credential deployment executable and create an AdminGroupName.txt file using the following command as a payload:
mshta vbscript:Execute(“msgbox “”I could use this for privesc =]””:close”)
Running the credential deployment package should present you with a message like the following:
I reported this problem to the OpenVAS team on 07/31/2020 and it has already been fixed as according to https://github.com/greenbone/gvmd/issues/1228.