12.07.2015 Views

HP 2012 Cyber Risk Report

HP 2012 Cyber Risk Report

HP 2012 Cyber Risk Report

SHOW MORE
SHOW LESS
  • No tags were found...

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

White paper | <strong>HP</strong> <strong>2012</strong> <strong>Cyber</strong> <strong>Risk</strong> <strong>Report</strong>Easily reversible dynamic password generation: The thick client application being testedcommunicated with a Web service that first authenticated the user attempting to log in. Next,the application requested the password to the back-end database server. The password wasoriginally encrypted during transmission, but by combining another SQL attack, a flag in thedatabase was able to be flipped, and thereby turn off this encryption. It appeared the systemimplemented dynamic passwords that changed frequently; however, after gathering multiplepasswords, a pattern emerged. The password was time based and therefore easily guessable.Direct access to the database with administrative permissions was confirmed, allowing forcomplete compromise of the system (see Figure 16).Web service allowed direct SQL queries: An application allowed connections to its backenddatabase via a Web-based interpreter that was accessible to the Internet withoutauthentication. With limited knowledge of SQL, an attacker could easily retrieve all recordsin the client database, including full user account details: user names, passwords, and emailaddresses, among other personally identifiable information (PII).By sharing these accounts of real-world penetration testing findings, our goal is to drawattention to the limitless creativity and endless determination of malicious attackers.Penetration testers emulate these techniques in an effort to effectively test each securitycontrol to help ensure that sensitive data and application capabilities are protected. Asdemonstrated in these accounts, automated security testing alone is an incomplete measure ofan environment’s overall security posture and must be supplemented with manual analysis.In the next section, <strong>HP</strong>’s software security researchers aim to highlight a crucial vulnerabilityoften used in combination with many of the attacks and techniques mentioned earlier whoseeffective mitigation has yet to be holistically adopted.The X-Frame-Options header—a failure to launchIn order to illustrate the constantly changing nature of Web application security, researchersfrom the <strong>HP</strong> Software Security Research group examined an established vulnerability formallyreferred to as cross-frame scripting (XFS). XFS is an important tool for any attacker trying tocraft a phishing or social engineering attack and can be exploited to load a vulnerable websiteinside an HTML iFrame tag on an attacker-controlled malicious page. This enables the attackerto capture events, such as keystrokes, invoked by any user on the victim website.XFS vulnerabilities also pave the way for clickjacking 6 attacks, which deceive users into clickingcertain elements on the victim website loaded inside an invisible iFrame tag. Often, this resultsin unintended and possibly even privileged actions. For years, researchers have warned againstthe ineffectiveness of script-based frame-busting protections in mitigating the threat of XFS.Developers and supporting server administrators, however, continue to rely solely on theJavaScript-based mechanism (Figure 17) to detect XFS-based exploits.Various mitigations proposed against XFS have repeatedly proven to be incomplete orineffective. The most popular of these mitigations is the use of JavaScript frame-busting logic,or essentially a client-side script that resembles the one shown in Figure 17. 5Figure 17. Typical JavaScript frame-busting logicif (top!=self) top.location.href = self.location.href;6 cvedetails.com/cve/CVE-2002-1217/14

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!