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.

Since I started this series several months ago, OWASP has released its final version of its latest and greatest Top 10 list for 2010. In today's post, we will use this list to summarize the vulnerabilities covered so far and briefly talk about some of the new additions. For most of these, I have simply linked the title of the vulnerability to the corresponding post in my blog series.

Due to vacation schedules and lots of other things going on this summer, "next week" has turned into "next month" for this final post in my top 10 series. Today's subject may be a little surprising to many developers: Aren't buffer overflows so 2003? Hasn't this been fixed in virtually all modern programming languages by preventing direct memory access? While the second statement is certainly true, it doesn't mean that today's developers don't need to be aware of buffer overflows, especially when interacting with closed-source and/or legacy software written in languages that allow arbitrary memory access (C and C++ being the most common examples).

No matter how well-written or secure your application is, Denial of Service (DoS) attacks always pose a risk. Most web applications are publicly accessible by design, so the server/application really has no way to tell 10,000 legitimate user requests from 10,000 malicious requests designed to bring it down. If a DoS attack originates from a single source or from a few sources, it can be blocked fairly easily once the source(s) are identified. Unfortunately, most DoS attacks today are actually DDoS attacks (distributed DoS), which means that they originate from hundreds or thousands of different places across the Internet, most commonly from botnets. This makes it nearly impossible to shut down the malicious traffic without also cutting off the legitimate users...which is exactly the point of a DoS attack.

Some common types of DoS attacks are the following:

Writing secure code is the most important aspect of secure development, since this is where the proverbial rubber meets the road. However, there are many other environmental factors that contribute to your application's overall security posture. This includes the application/web server, backend systems such as databases, and of course the underlying operating systems and network infrastructure. Consider the following common vulnerabilities: