Penetration Testing: the basics

What is Penetration Testing?

Penetration testing is what you might call ethical hacking. Now hacking is a large and arguably misused term, but it is the best term we have. Penetration testing involves an individual, team, or software, actively analysing a system for vulnerabilities. This takes can take many forms, which we will get into later, many of which are not what you might think of as "hacking". There is always a written consent by the party, almost always with a payment involved, making penetration testing a service, sought after by those looking to improve the security of whatever property or infrastructure they have. ^[i.n.]

^[p.n.]"Hacking", the wildly used term that it is, will be defined thus: "a person interfering with another system without permission from the system owner". The first thought that comes to mind is someone in a dark basement typing line after line into an arbitrary command prompt. This media portrayal, while cool, is misleading. Lot of "hacking" and most commonly seen cases of what most of us may call hacking, is more appropriately scamming, or misleading a human into giving up their valuable information. Actual attempts to penetrate a system often involve very methodical approaches, not really the high-speed action that we see in movies. Successful penetration of a system is what you would call genuine hacking, usually accompanied with the stealing of sensitive information. An individual breaking into a system is primarily looking for sensitive data. You can see this with the kinds of systems that are targeted. On a more serious level banks and pentagon computers receive millions of un-authorized access attempts every day, but the majority of this work is done through automated software. More human attempts (by human I mean small scale and operated by human beings) target services like forums in attempts to gain large amounts of emails, or online small financial services or stores looking for debit or credit card numbers. These emails or financial information can then be sold on under-belly websites, but that is different conversation. The important part is that it is very profitable, and there are little repercussions for those outside of western jurisdictions. You can see examples of this with the recent team viewer service hack: here, any one retrieving user accounts gets access to sensitive network information and potentially access to their computer through the popular screen sharing service. Another example is the steam user forums hack:

Here you might not see that value, but the group gets notoriety and advertising to a large audience (even if their damage was quickly fixed).

^[i.n.]

How do you "penetrate" a system? Exploits!

The main purpose of penetration testing is to identify vulnerabilities. These vulnerabilities, are then tested, and a penetration tester usually offers a solution along with identifying the problem. Generally speaking a vulnerability is a security "hole". This means it offers a way for an outside entity to gain access into the system, this most commonly manifests as weak passwords, but can also take much more complex routes such as database interactions flaws. These vulnerabilities are exactly what penetration testers are hired to find.

A common exploit is sql injection, which allows you to send commands to a database from outside of the system. It is usually the result of insufficient authentication for all protocols. Think of it as someone entering a bank from the employee entrance. Now if you still don't understand, think of this: someone is able to issue commands to your computer from their computer. That's what "gaining access" to a system involves. Sometimes not entirely, often your functionality is limited for fear of exposing your presence and leaving a trail. When you can control a computer without the user's knowing, you can send a file to be executed, what is called a payload.

What do you do after you "penetrate" a system? Deliver a payload of course!

After gaining access to a system, you need to find or develop a way to take advantage of it. This is typically called an "payload". The exploits we spoke about above allow you deliver a payload. Now this can be confusing but here is a great analogy: Think of a payload as a warhead, and an exploit as your propulsion system. Together you have a missile, but they are both rather useless alone. (credit to user "NULLZ" from security.stackexchange.com) ^[p.n.].

^[i.n.] So a payload is software that uses an exploit to gain access to a system. This can take different forms, there are completely independent payloads, that you cannot interact with once injected into a system. A staged payload, for example, established a communication channel between the hacker and the targeted system. This kind of payload gives the penetration tester control over his program by feeding remote commands. Getting into why you would use different kinds of payloads is a bit beyond this blog post but it is often about what kind of system you're using and any traces you leave behind for digital forensic investigation. Metasploit^[i.n.] If you're looking to learn about penetration testing, or want to try it yourself, you should checkout Metasploit. Metasploit is an open source penetration testing community. Any software you would need to get started is available there, and they even have a number of guides! Penetration testing can be lucrative career, or just a hobby. Many corporations have "bug bounties". you can see google's page here. Regardless of what your intentions are, if you're looking to learn I encourage to delv deeper with some hands on experience^[i.n.].

Peer review

The project is focused on the work of penetration testers. Penetration testing is a form of pre-emptive security employed by companies in which they -- or more commonly a hired third party -- attempt to highlight security risks in the company's software by using publicly available tools to subvert the security features in place. By fixing any security deficiencies found through this method, the risk of having these exploits taken advantage of by malicious entities is minimized. I found Seth's explanation of penetration testing to be very easy to understand. I have exposure to the computer science world, so while this likely helps my understanding, I believe even a non-informed reader with interest can understand the concepts being discussed. What is not evident to me at the moment is where the article is heading. I assume that the purpose of the blog is to explain what penetration testing is, however if this is the 'answer' to the blog post, it seems to be discussed heavily in the 'background' section, leaving me to wonder what is planned for the 'answer' section. If my instinct on the direction of the post is correct, I would suggest front-loading the definitional misconception of hacking in addition to some historical instances of famous vulnerabilities (Heartbleed) or companies marketing bug-bounties (Google, facebook etc.). These subjects I believe support the atmospheric foundation for the discussion at hand without needing to explain in depth what the process of penetration testing entails. A good approach to modularity seems to be underway in the post. As such I think the article lends itself to an effective use of the 'list a='roadmap'' type element. This is personal taste however, and is by no means mandatory. Seth expressed concern that he may not be covering the subjects in enough depth. I struggled with the same concern when I was writing my blog entry, however as a reader I don't find myself wanting for a much more in-depth explanation. If this blog were tailored for a highly technical and informed audience, then it would likely be necessary, however our group's conception of the genre was one that should be accessible to the general public without too much googling of definitions being necessary. I believe the best way to bridge any gaps in knowledge would be to use the 'ref' element to give inline links to points brought up for those readers who might be interested in understanding the full technicality of a given point or term. Although the project is still in its preliminary stages, it appears Seth has a good understanding of the most important structural tools made available by the schema. The topic is fitting and one that I think even non-computer science minded people would find highly engaging.Lastly Seth mentioned he is still trying to find good analogies for vulnerabilities. To offer some examples he is free to use or work off of, would be: 1) SYN-ACK Flooding : sending billions of letters to somebody's office when they're expecting only a few. Congestion and confusion ensues. 2) Buffer overflows : A goat in a pen on the side of a garden. The goat manages to escape the pen and can eat and rampage the garden at will. Except, instead of just a normal goat, this goat travels at the speed of light and in milliseconds can eat everything in the garden making it unrecognisable. Also, instead of being a normal goat, it is a speed-of-light-travelling-genius goat that knows how to plant vegetables. It can then plant the carrots where the beets had been. You're a blind and tactilely defunct farmer, so when you go to pick the beets you're picking carrots, but are none the wiser. SQL Injection : A criminal who dresses up like a security officer at a major bank, allowing him to walk through the 'employees only' door and looting the bank.

Instructor Note

There's a lot going well here, your use of images is well done and I think the second section is very well done. There are some aspects that could still use some work--the background section is a bit difficult to follow and see where you are heading (consider a list @type=roadmap?); 2) there are a few small corrections in formatting and typos that need cleaning up; 3) the post ends a bit abruptly, I feel like we have a sense of what 'hacking' is, but less of a sense of how it specifically relates to penetration testing (do people go from illegal hacking to penetration testing? are there ethical issues in penetration testing?); 4) I'm wondering why you decided against a sources section.