Penetration Testing:
Lessons from the Field
Agenda:
•
About me: Alberto Soliño
–
Director of Security Consulting Services at Core Security
–
One of first five employees at Core
–
Former member of Special Projects Group at World Bank
•
Examine real-world penetration testing consulting engagements for
common problems/trends.
Objective of today’s talk:
•
Share with some lessons we have learned through many years of
consulting engagements.
•
Focus on problems triggered by the design and implementation of the
applications tested.
•
Pay specific attention to Web application issues, which are
proliferating rapidly as these apps become more complex and
ubiquitous.
•
Illustrate how different vulnerabilities can be used together to
compromise systems and steal protected information.
Common Customer Challenges:
• Application developers are still taught to consider security as a secondary concern, after uptime and functionality.
• Many unapproved commercial applications get onto networks and devices driven by user demand, regardless of policies.
• Organizations are focused on check-box compliance tasks, and don’t have resources to focus on underlying security issues.
• Companies who grow via mergers and acquisitions often find out too late that they will inherit major security problems.
• Increasingly pen testing thought of as a QA process rather than mimicking what an attacker can do.
• IT organizations have insufficient capabilities or plans in place to respond to incidents as they occur.
Application Security Lessons
•
Remember 20 years ago?
•
What were attackers doing with no BO, XSS, etc..? No pen test
frameworks?
– Manually uncovering a set of vulnerabilities that altogether would compromise IT infrastructures.
•
What should pen testers do today?
– Take advantage of available tools to set a foundation and raise the bar.
– But.. more importantly:
Notes on today’s examples:
•
Testing engagements involved the use of both manual and automated
penetration tests conducted by SCS experts.
•
Scope was limited ONLY to application assessments carried out using
a black-box approach.
•
Projects involved were medium-size engagements of two weeks using
two or three security consultants each.
Case 1: Weak Authentication
• Overview: Authentication systems remain a common source of exploitable vulnerabilities in Web applications, typically based on poor design and
insufficient controls.
• Service type: Web application blackbox • Attacker profile: Anonymous attacker
• Main goal: Circumvent authentication to hack into the application • Notes:
– Web interface (case1.com)
– User profiles: IT staff, application administrators
Case 1: Weak Authentication
Findings: The application was easily subverted via login manipulation.
• case1.com/images -- directory listing
• case1.com/admin -- login screen for application administrators
• Image names within the /images directory were named after the page that included the images, i.e.,: adminlogin_logo.gif (case1.com/admin/login.html),
adminlogout_button1.gif (case1.com/admin/logout.html) .
• Through the image names we were able to find new files within the admin subdirectory (e.g.,: admincpanel_header.gif, led us to /admin/cpanel.html) . • That is how we found the control panel page for page administrators
Case 2: Public Information
• Overview: Many Web applications provide too much contextual information about their underlying design, giving attackers the clues they need to hack into the systems remotely and carry out a range of potential activities.
• Service type: External penetration test • Attacker profile: Anonymous attacker
• Main goal: Hack into the tested network from the Internet • Notes:
– One internal Web application found during the network scan. – No vulnerabilities were found in the network services.
Case 2: Public Information
Findings: The Web application was subverted via available information.
• The IP address hosting the application resolved to internal.case2.com. • We looked up the host name in several search engines.
• We found a log file in a third-party Web server that contained pairs of
usernames and passwords for the internal application (this looked like the output of a key logger).
• We used those credentials to log in to the Web application.
• Once logged in, we exploited an SQL injection vulnerability within the internal application functionality and through xp_cmdshell uploaded a CORE IMPACT agent. As a result, we were able to access the server running the internal
Case 3: Password Reset
• Overview: Many Web applications do not handle new user authentication intelligently, leaving them open to attacks when outsiders are able to garner enough information to admit themselves to the apps.
• Service type: Web application black-box • Attacker profile: Anonymous attacker
• Main goal: Hack into someone else’s account to subvert application • Notes:
– Anonymous users were presented with a login screen – User profiles: Anonymous
Case 3: Password Reset
Findings: The Web application was accessed via available information.
• While manually reading the contents of all HTML and Javascript files
available to anonymous users, we found a reference to a log file that was left behind unintentionally (commented in the html file).
• The log file contained logs for emails sent to new users after registration. • We also found a problem with the authentication scheme of the application.
The application would start creating the session for the user, even if the password supplied during login was incorrect.
• Once inside the password reset page, the ViewState hidden field (ASP.NET application) contained confidential data for the user (e.g. secret Q&A).
• We successfully used the secret answer to reset the password for any users of the application. All we had to know was the ‘username’ which, in this case, was equal to the e-mail address of the victim.
Case 4: Web Services Security
• Overview: Many organizations don’t consider the implications of implementing their own authentication methods instead of using available frameworks.
• Service type: Web services PT
• Attacker profile: Authenticated attacker
• Main goal: Subvert normal web services functionality • Notes:
Case 4: Web Services Security
Findings: Signature collisions
• Every web service request was signed using a secret key.
• Signature was calculated sorting the elements based on the element name. • Element values were then extracted and appended all together to construct a
unique string (value1value2+....+valueN).
• That unique string was signed using HMAC-SHA-256 with the user’s secret, then sent to the server.
• Having the element’s values appended all together allowed us to alter the values (but still maintain the unique string) allowing an attacker to tamper with the request and still have a valid signature.
Case 5: Hybrid
• Overview: Many organizations don’t consider the implications of specific application vulnerabilities on the company’s overall security.
• Service type: Web application blackbox • Attacker profile: Anonymous attacker
• Main goal: Hack into the customer’s organization • Notes:
– Anonymous users were presented with a log-in screen – User profiles: Anonymous
Case 5: Hybrid
Findings: User enumeration, WebDAV upload, SQL Injection
• The password reset functionality allowed us to brute force valid usernames due to the fact it would say whether or not a user was valid for the application.
• WebDAV functionality allowed us to upload valid HTML files (although nothing else).
• We uploaded a change password HTML page into the corporate web site and performed a phishing attack against the list of users.
• Several users trusted the email and opened the link pointing to their website (our fake page) and changed their passwords.
• The users/passwords recovered allowed us to log into their internal network through their VPN and also to log into the application, exploit a SQL Injection, install an agent and then pivot into their servers.
Other Common Findings...
• Attack escalation through instrumentation
• Internal network access through client side and phishing attacks
• On internal pen tests, vulnerabilities at network services are still found
• Backup files, hidden debug parameters, input validation only performed in the client can still be seen
• Weak custom authentication and encryption algorithms
• Poor reaction to attacks: only a few customers actually realized something wrong was happening until it was too late
What Organizations Need to Consider:
• How critical it is to pay attention to the security of their services, software and infrastructure, in particular Web applications.
• The potential damage that employees or users can do to the network, applications and sensitive data they have access to.
• Business applications may work as expected from a functional standpoint, but each of them carry dozens of critical security vulnerabilities that could ruin their overall enterprise in a matter of minutes.
• How likely it is that they have already been compromised in the past and how important it is to act fast when they have been breached.
Big Picture Conclusions...
• In the same fashion as network services, with applications you are only as secure as your weakest link.
• Several low-risk vulnerabilities available together could be used to compromise applications, and to move from one app to another.
• Application vulnerability scanners, protocol fuzzers and penetration testing solutions are very important for performing applications assessments on ongoing basis to minimize risks.
• It remains important to complement such tools with security assessments performed by experts who can spot problems, especially those that require deeper understanding of relationships between different components and the customer’s business operations.
Questions?
For more information about Core’s Security Consulting Services, contact:
Kip West
Manager, Security Consulting Services 617-695-1134
Alberto Solino
Director, Security Consulting Services [email protected]