Introduction
While on an assessment I came across HP SiteScope installed on a server. Having never heard of SiteScope before I started with a Google search. According to Wikipedia,
HPE SiteScope is agentless monitoring software focused on monitoring the availability and performance of distributed IT infrastructures, including Servers, Network devices and services, Applications and application components, operating systems and various IT enterprise components
Availability and performance monitoring servers usually contain sensitive data like credentials which makes them targets of interest.
SiteScope is a web service typically running on port 8080 with a standard web login form. Trying the usual simple credentials (admin:admin, admin:sitescope, etc) didn’t get me anywhere so I began looking for existing exploits. My first stop was a quick Metasploit search which turned up a handful of existing modules including 3 RCE and 1 command injection exploits.
Unfortunately, none of these exploits worked on the SiteScope version (11.31.461) that I found. That left 3 other auxiliary modules, but after looking over the info I didn’t have a lot of hope they would work either. The auxiliary/scanner/http/hp_sitescope_getfileinternal_fileaccess module was based on vulnerabilities reported to ZDI in 2012. From the module info,
This module exploits an authentication bypass vulnerability in HP SiteScope to retrieve an arbitrary file from the remote server. It is accomplished by calling the getFileInternal operation available through the APISiteScopeImpl AXIS service. This module has been successfully tested on HP SiteScope 11.20 over Windows 2003 SP2 and Linux Centos 6.3
The target I was assessing was a Windows Server 2008 R2 server and running SiteScope version 11.31.461. I assumed HP had patched this issue in newer versions, but couldn’t find any advisories on it. After reviewing the code it looked like the module was just calling an existing API function. Since there was a low risk of bringing down the server I decided to give it a try. To my surprise it worked! I was able to pull down the C:\windows\win.ini file (default setting in Metasploit).
So now I had blind file access to the system, but it was hit or miss as to which files I could access. Some files I thought I should have access to would fail during download. The files I knew for sure I had access to were all the SiteScope configuration files. After a little research I found that SiteScope credentials are usually stored in the master.config and user.config files. So I downloaded the configuration files only to find that the passwords appeared to be encrypted.
Back to research. After looking through posts on various support forums I found that the path to the main SiteScope files were located in the < INSTALLFOLDER >\WEB-INF\lib folder. Notice that I mentioned the passwords looked encrypted and not hashed. This is important because encrypted data means there’s a key somewhere. I started methodically pulling down SiteScope files from the target until I came across ss_pu.jar. Then using jd-gui I decompiled the jar and started digging through the code. Pretty soon I came across a PasswordEncrypt function in the com.mercury.sitescope.platform.security.encryption file. PasswordEncrypt calls the “getKey” method in the CryptoSiteScopeKey class. As you can see from the image below it’s a simple getter method that returns the hardcoded 3DES key used to encrypt SiteScope passwords by default.
So what’s interesting about this implementation is that I couldn’t find a “PasswordDecrypt” function. In fact, it looks like SiteScope might actually be just comparing the encrypted values for authentication. This begs the question, “why not just use a hash function?” Anyway, now that I had the encrypted passwords, the method (3DES), and the key all that was left was to implement a decrypt function. There are many ways to do this, but I chose to just use the code that was already in the jar with some slight modifications. I quickly wrote up a PasswordDecrypt function in a new file called PasswordDecrypt.java.
package com.mercury.sitescope.platform.security.encryption.tool;
import com.mercury.sitescope.platform.security.encryption.EncryptionManager;
import com.mercury.sitescope.platform.security.encryption.chain.handler.CryptoUtils;
import com.mercury.sitescope.platform.security.encryption.key.CryptoToolsKey;
import com.mercury.sitescope.platform.security.encryption.key.CryptoSiteScopeKey;
import java.io.PrintStream;
public class PasswordDecrypt
{
public static void main(String[] args)
{
System.out.println("Decrypting password...\n");
if (args.length != 1)
{
System.out.println("\n\nWrong parameters. Please enter password to decrypt\n");
System.exit(0);
}
String decryptPass = args[0];
CryptoSiteScopeKey key = new CryptoSiteScopeKey();
CryptoUtils.setKey(key);
String encryptedPass = "";
try{
encryptedPass = EncryptionManager.getDecrypted(decryptPass);
}
catch (Exception e)
{
System.out.println(e);
}
System.out.println("\n\nDecrypted Password = " + encryptedPass);
}
}
jar files are really just zip archives so all you have to do to patch a jar is compile the code into a .class file and zip it back up into a jar. Now that I had my new patched version of ss_pu.jar I could call the PasswordDecrypt function with the encrypted administrator password for the win.
At this point I was able to login to SiteScope with administrator access. After exploring the SiteScope menu for a few minutes I was drawn to the “Credential Preferences” option.
It turns out that in order for SiteScope to monitor other servers it needs to be configured with valid credentials to those systems. Remember that SiteScope is advertised as an agentless solution. The system I was on appeared to have credentials for both Windows and Linux servers stored in its profiles. Opening one of the profiles showed the username and a masked password, but even administrators are not able to unmask the passwords through the web interface.
I could configure new profiles for SiteScope to use, but not view existing credentials. I clicked a few of the profiles and noticed that the length of the masked passwords changed which means that, at least, some information about the password was being returned by the server. Was it just the password length or was SiteScope sending more?
I opened up Wireshark to explore the traffic in more detail and was immediately presented with the clear text passwords stored in the credential profiles! That’s not good.
In this case the target I was working on was an internal facing server, and also wasn’t configured with SSL. Anyone listening on the wire internally could intercept credentials being passed in the clear. So at the very least this was a configuration issue for the administrator, but this is also a major flaw in SiteScope. Even if SSL is configured malicious users could still MitM their own session to obtain clear text credentials for any profile stored in SiteScope. Depending on the level of access these accounts have, this could mean complete domain and/or root compromise.
Other findings
While digging around the SiteScope code I also came across a class called “OldEncryptionHandler” which appears to be a proprietary encryption scheme with a hardcoded private key of “SiteScopeFreshWaterSoftware”.
public class OldDecrypt {
public static void main(String args[]){
//String subEncryptedString = "MGNCOIMKMGMGNOOAMK";
String subEncryptedString = "MDMKOHNIMDMLOBNBNIKL";
StringBuilder result = new StringBuilder();
int il = subEncryptedString.length() / 2;
int pp = 0;
for (int i = 0; i < il; i++)
{
int h = subEncryptedString.charAt(pp++) - 'A';
int l = subEncryptedString.charAt(pp++) - 'A';
int c = h * 16 + l;
c -= "SiteScopeFreshwaterSoftware".charAt(i % "SiteScopeFreshwaterSoftware".length());
result.append((char)c);
}
System.out.println(result);
}
}
Some items in the configuration files appear to still use this function for encryption. For example, the _httpSecureKeyPassword and _httpSecureKeystorePassword configuration items located in master.config are encrypted with the OldEncryptionHandler.
Mitigations
The following mitigations are taken directly from HPEs response to my report.
With regards to SiteScope version 11.31.461 (and prior) still being susceptible to exploits in Metasploit.
A fix for this is available in SiteScope release 11.24 IP7 onwards, via a flag called “_disableOldAPIs=true” that can be set in the “groups/master.config” file. Setting of this flag will prevent this and other such unauthenticated services from being executed.
A quick Shodan search shows, at least, 230 public facing SiteScope servers across the world. I wonder how many admins know about this setting, and why wouldn’t HPE just remove the old APIs from new versions if they are no longer needed?
With regards to any hardcoded encryption keys.
These hardcoded keys are used for backward compatibility and obfuscation. For encryption, Key Management can be enabled which will mitigate this vulnerability. For enabling Key Management please refer SiteScope Deployment Guide - Chapter 20: Configuring SiteScope to Use a Custom Key for Data Encryption.
With regards to custom cryptographic functions like OldEncryptionHandler
ss_pu.jar contains only obfuscation keys and those keys are not used for encryption. Customizable cryptographic keys are generated during key management. Encryption is done by key management in SiteScope. Please refer SiteScope Deployment Guide - Chapter 20: Configuring SiteScope to Use a Custom Key for Data Encryption.
With regards to SiteScope insecure transmission of credentials:
The fix is planned to upcoming release approximately Q3 2017.
Disclosure Timeline
- 4 April 2017: Inital report - PSRT case opened
- 22 May 2017: Requested coordination assistance from US-CERT
From initial report to 6 June 2017 I made repeated requests for mitigation guidance. The only response I received is:
We are working on all the findings/items in the report with the product team.
- 6 June 2017: Response received from PSRT with mitigations for 3/4 items, and a request to delay disclosure until Q3 2017
After discussing with US-CERT we decided to disclose in accordance with the US-CERT 45 day disclosure timeline in an effort to encourage HPE to provide defender mitigations as soon as possible. Vulnerability Note from US-CERT: https://www.kb.cert.org/vuls/id/768399
