The QualysGuard Private Cloud Platform (QG PCP) makes many promises, one of which is that vulnerability scan data can be hosted by a private cloud platform in a client's data center and under the client's control. If taken at their word, this may seen promising, but the reality is that Qualys still will have to manage this platform remotely. By doing so, they will have access to this data remotely anyway and can pull it down to their site as needed. Needless to say, Qualys requires the client to provide a backdoor to the system.
The Qualys PCP equipment is leased and never sold to the customer. There are many legal issues with this which allows them to access their equipment. They require the customer to give them remote access in order for them to manage it remotely. That is a requirement and not an option. They keep it a big secret how it is managed.
What kind of remote access to the QG PCP do they require?
1. Persistent iVPN tunnel
2. VPN remote access account
Qualys still has the means to pull the data back to Qualys through SSH/SCP even though it is hosted on a customer site. In fact, Qualys does not allow the customer to monitor the network traffic being sent back to Qualys. Such requests were flat out refused during a security assessment. What they pull back is their business and the customer has no right to know.
Network monitoring had to be done outside of the QG PCP as Qualys did not allow internal network sniffing. This traffic analysis did show a few weaknesses.
1. Emails were being sent to email server UNENCRYPTED. Yes, one could see the message being sent as well as who the recipients were. Emails were being back to Qualys through the Internet. A lot of sensitive information were sent unencrypted including server names, configuration, scripts, running jobs, listening ports, full internal DNS names.
2. Internet connections from Indonesia were seen accessing the QG PCP even though it was supposed to be in a controlled access network in a data center
3. A lot of failed DNS requests to www.qualys.com and other qualys subdomains, looks like the system has not been fined tuned to be hosted at a client site. The interesting thing is that it tries to do windows updates on its own by accessing the Internet.
4. Undocumented protocols used by the Qualys PCP; namely AppleTalk, CMIP-Man, and Feixin
5. syslog messages sent across the network unencrypted.
Firewall rule analysis shows that SSH is allowed into the platform through VPN firewall as well as HTTP(S) protocols.
The Qualys PCP itself does access network traffic in and out of the controlled access network environment as seen in the diagram below.
1. The Qualys PCP Service Network requires outbound communication for
a. NTP – Time Synchronization
b. DNS – Name Resolution
c. SMTP – Email
d. WHOIS – External Internet
e. Daily Vulnerability Updates - External Internet.
WHOIS pulls information from the Internet and Daily Signature Updates are pulled from Qualys through the Internet on port 443. In effect, the PCP is pulling information from Qualys through the Internet to retrieve updates. A man-in-the-middle attack could intercept the update and instead return a malware update to the Qualys PCP provided that a vulnerability exists in the platform.
2. The physical scanners communicate to the Qualys PCP. This requires that inbound port 443 be opened on the PCP. Physical scanners in the DMZ also need to communicate to the PCP on port 443. Access to the PCP from the DMZ increases the risk.
3. Qualys SOC accesses the PCP through iVPN and VPN connections from the Internet for maintenance and support.
A sniffer placed on a virtual scanner showed that it chose to use SSLv3, which is deprecated, by default on some servers to communicate to the Qualys PCP. In particular, it uses SSLv3 with RC4-MD5. MD5 is obsolete. Qualys documentation claims they use TLSv1 and the latest modern secure protocols.
Application analysis was done by running Perl scripts against the qualysapi server and testing for vulnerabilities. The server itself was found to be vulnerable by accepting login credentials for API requests via base64 encoding and passed through plaintext HTTP. This could result of loss and capture of Qualys Admin credentials which could result in access to vulnerability scan results.
The Qualys Web Application tests resulted in a number of vulnerabilities.
Additional vulnerabilities were found inside the Qualys PCP infrastructure itself. It was found to be very insecure.