Highly accurate Information Security Testing

Lifeguard Case Study

Background

Shorebreak Security completed a comprehensive internal and external penetration test in August of 2013 on Customer “X”, a very successful, privately owned Information Technology company.

In February of 2014 Customer “X” signed up for Shorebreak Security’s Lifeguard service and Shorebreak Security started testing the network daily.

The following is a timeline of major events and lessons learned stemming from the first eight months of Lifeguard service.

Timeline

February 2014: Incomplete Remediation

Despite having had a comprehensive test four months earlier, our engineers discovered the existence of a new, externally accessible, root-level (administrative access) vulnerability. This vulnerability was identified during manual penetration testing, and would not have been identified at all had we relied on vulnerability scanning alone. Our test team validated the vulnerability by exploitation, and gained root access to the server.

The customer was notified via text message and email right away.

Customer X’s IT staff remediated the finding and the Lifeguard dashboard automatically notified us that the system had been fixed. Verification testing, however, showed that the fix was only partially effective, and that the vulnerability was still exploitable. The customer conducted a second round of remediation, and upon verification we were able to successfully “close” the finding in Lifeguard. Despite the initially incomplete remediation, this entire cycle was still completed in less than 24 hours.

March 2014: Manual Testing Uncovers “zero-day”

Within just two weeks of the first critical finding, manual testing identified a previously unknown vulnerability (“zero day’) in a software vendor’s authentication system within a web application. The vulnerability could be exploited to gain root-level (administrative) access to the underlying operating system.

Customer X remediated the vulnerability with external security controls within 24 hours. We immediately conducted testing to verify the fix, and the vulnerability was successfully closed. The Shorebreak Team then drafted a security advisory and sent it to the vendor of the vulnerable software, so that a patch could be developed.

April 2014: Response to OpenSSL “Heartbleed”

The OpenSSL “Heartbleed” vulnerability was made public in April of 2013. Because Lifeguard scans were constantly cataloging hosts, ports, services and banners, our team was able to immediately identify vulnerable hosts. Within hours, Customer X was notified and could begin remediation efforts.

Validation testing showed that Customer X’s remediation was incomplete. In this case, the vendor-supplied patches had been applied but the systems were not rebooted, leaving the systems vulnerable. Customer X was notified that the vulnerability was still present and a second round of remediation and verification testing was conducted and completed.

Customer’s X’s exposure to the Heartbleed vulnerability was less than 48 hours and remediation was complete before most vulnerability scanner vendors had published new signatures to check for the vulnerability.

September 2014: Reaction to the “ShellShock” vulnerability

The critical GNU Bash “shell shock” vulnerability was published in September of 2014, and we contacted Customer X to advise them on the issue and proceeded to conduct testing to identify vulnerable systems. Within 24 hours, Customer X had been reassured that their exposure to this vulnerability has been minimized.

October 2014: New Apps, New vulnerabilities

Two additional critical findings were identified as the network configuration changed and new vulnerabilities were made public.

In one case, manual testing discovered that a new web application had been deployed with a manufacturer default admin password. In another, an “SQL injection” vulnerability was identified and exploited, resulting the ability to bypass the authentication system of the web application and become a valid user.

Both vulnerabilities were reported and quickly rectified.

 

Observations

On average, one “critical” finding was discovered each month. Had the customer waited until their next annual penetration test to identify these vulnerabilities, criminal hackers or other adversaries could have easily compromised network.

In almost every case, manual testing was key in identifying the vulnerability.

In many cases, the customer remediation effort was insufficient in addressing the vulnerability. Without Lifeguard, the customer would have believed that the vulnerability was remediated, but in reality would have remained exposed.

 

Why Lifeguard Works 

 

Please contact us is you would like a free consultation on how Lifeguard can help your organization become more secure.