One of the most important parts of a penetration test is to take a step back afterwards and look at the big picture. What were the root causes that allowed the compromise to take place? How can the system be better protected against such attacks in the future? In closing this series, we will show you how to address the specific security issues that allowed our attack to succeed, divided into three main categories: initial exploit, escalation, and data security.

This is the last entry in a series of six blog posts; the previous post was Part 5: Data Exfiltration.

After expanding our access to include complete administrative control over the server and database, the last step was to look for interesting/valuable data and figure out stealthy exfiltration methods. However, since this was only a penetration test, not a real-world break-in, there are some important differences in how far to take this part of the attack.

This is Part 5 in a series of six blog posts; the previous post was Part 4: Expanding Access.

Having found a way into the server, we were ready to explore the system and find ways to expand our access. We started with some general reconnaissance of the server, followed by a more targeted analysis of the main web application. This eventually resulted in full access to the MySQL database as well as administrative access to the entire server via secure shell (SSH).

This is Part 4 in a series of six blog posts; the previous post was Part 3: Gaining Access.

General Server Reconnaissance

After gathering as much information as possible in the reconnaissance phase, it was now time to find a way of breaking into the target server. Typically, the most promising angle of attack is third-party toolkits that are often outdated and most likely have some published vulnerabilities available. In most cases, such vulnerable toolkits provide an easy way for an attacker to get in. This way, he doesn't have to spend a large amount of time and effort analyzing and reverse-engineering the custom-written code that often powers the main web application.

This is Part 3 in a series of six blog posts; the previous post was Part 2: Recon and Scanning.

Before an attacker can start trying to break into a system, he first needs a deep understanding of the system and its components. This reconnaissance phase can be divided into three main parts: basic server reconnaissance, service-specific scanning, and manual follow-up to scan results.

This is Part 2 in a series of six blog posts; the previous post was Part 1: Introduction. 

You’ve heard of countless website and database breaches—and you’ve probably asked yourself how the attackers were able to get in. In many cases, minor vulnerabilities can be exploited to extend the attacker’s foothold and eventually compromise the entire server.

In this six-part blog series, we will walk you through the process of completely compromising a target server on a recent web application penetration test. It all started with a single input validation flaw in a third-party toolkit and ended with us getting full administrator-level access to the server and database.

It is really bad, according to a recent survey by the Ponemon Institute (available here with registration). The white paper, entitled Health Data at Risk in Development: A Call for Data Masking, presents the results of a survey of 492 health care IT professionals on their companies’ practices regarding use of live personal health care data in application testing.

It makes a scary read.  Here are the lowlights:

Recently I was asked to configure a web application using client certificate authentication. I did this is using Weblogic Application Server version 10.3, however the concepts for this apply to most application servers. The following sections describe the configuration changes that must be applied to the environment for this to work.

Web application

The web application needs to be modified to restrict access to resources and require the use of a client certification. In order to do this modify the deployment descriptor of the application by adding a security constraint:

…

<security-constraint>

<display-name>Sec_Constraint_1</display-name>

We are probably all familiar with access control as an IT architecture requirement.  It is one of the most common security features that we build into enterprise applications.  Access control allows authorized individuals to use the menu options, screens, reports and other features of a system that they need to do their jobs, while it keeps out the bad guys who might want to misuse a system.  For the business owner of an application, access control is all about knowing who can get to what, and who can't.  But for the compliance auditor, access control is more about knowing who authorizes whom to get to what, and why.

You see, compliance auditing is all about verifying controls.  A control is simply a procedural or technical "checkpoint" that reduces risk to an organization.  For instance, when a user requests access to a menu option within an application, that request should go to a manager for approval.  This is a control that ensures that the user needs the access that they have requested.  After the manager has approved the request, it should go to a different person to be provisioned.  This is another control.  It ensures that the manager can't give themselves or someone else unlimited access to the system without anyone else knowing about it.  The compliance auditor is interested in seeing that all of these controls are in place and are working properly. 

To be sure that the controls are in place, the auditor is going to want to see a documented process for access control that includes all of the applicable steps in provisioning a user to a system feature, and also the process for de-provisioning the user, should they leave or change job roles.  The written process will need to call out its control points, and it should be readily evident to the auditor that these controls cannot be easily circumvented.  The auditor is also going to want to see evidence that the written process is being followed each and every time. This is where the system architecture comes in to play.

To be easily audited for compliance, the access control features of a system have to be very transparent.  In other words, it should be easy for the auditor to figure out who has access to what features of the system.  This is fairly easy to accomplish provided the system uses RBAC (roles based access control) or some other well-known access control methodology.  For instance, RBAC maps each user to one or more roles, then maps those roles to one or more system features (It may also employ groups to aggregate users into roles).  The auditor is going to want to see that map of Users>(groups)>Roles>Features in plain language, and may want to see how the system implements the map at a technical level (although in practice few auditors are technical enough to discern whether the map is fully implemented in the code).  The auditor may even ask for a demonstration that the RBAC schema works, which may require a penetration test using automated tools or brute force.

The other architectural compliance feature that a system may need is a robust logging mechanism to track access control changes.  The auditor is going to want to see a cradle to grave audit trail that starts with the end-user request for access to the system, and carries through the approval process and the changes made to the access control map within the system.  This audit trail can be implemented piece-meal using e-mails trails, system logs, and the like.  This is probably the most common way for legacy systems to implement the process.  However, a much more robust and friendly way to implement the process is to use an enterprise RBAC environment such as Microsoft Active Directory or IBM Tivoli and a provisioning tool such as Courion that automatically tracks and logs all account provisioning activities.  This will require your application to have a service interface to the RBAC infrastructure, which may sound complex, and it is.  However, the one-time implementation costs will probably be far outweighed by the repeated administrative savings every time a user is provisioned, not to mention every time the auditors come to town.  Of course, using a service interface for access control will raise concerns about system performance and the in-transit security of provisioning requests, but these concerns can be readily addressed in the architecture as well.

And finally, don't forget that at the enterprise level the provisioning mechanism will need to be connected to the Human Resources system, so that every employee addition, deletion, or organizational move will trigger the provisioning system to either take action, or at the very least to notify someone that action needs to be taken.  This is another service interface, and will probaby require some glue code to make it work properly.

This is just the tip of the iceburg with respect to compliance and access control.  But I hope it has given you something to think about.  Next time, I will talk about data integrity and SOX compliance, which has made the news on more than a few occasions in the last couple of years. 

On my current project we were recently faced with an interesting security issue.  The heart of the problem was that we had a set of secured EJB 3 services that needed to be called from a jBPM engine in the same container that for various reasons was not in a security domain.  Here I'll go over the way we chose to solve the issue and show some snippets of the "proof of concept" unit test.

The solution we eventually came to involved using an EJB 3 interceptor to inject a custom system principal around any BPM "actions" that needed to call secure services.  This approach allows the interceptor to be reused for any unsecured system components and is configuration driven, as we'll see later.