Miloslav Homer

I've written this article for the code.kiwi.com blog.

Do you want to know about pentesting but don’t know where to start? Not sure what the difference is between hacking and pentesting? Eager to learn how the pentesters know where to stop their activities? Want to hear all about it with a bit of a snarky attitude and in “human” language?

Then today is your day, my friend! Read on!

Pentesting or penetration testing is (according to Wikipedia) “an authorized simulated cyberattack on a computer system, performed to evaluate the security of the system”. This definition fails to mention that penetration testing is a professional service. Remember this for the future; I’ll be returning to this one a lot.

Of course, some hacking needs to be done, but I’d like to write about other aspects of pentesting and how it differs from hacking.

As an example of this direction of thought, penetration tests should bring value to the customer (the defender), usually in the form of information and intelligence whereas hacking should bring value to the attacker. This is the core conflict between hacking and pentesting.

Penetration tests need to be authorized.

This one seems obvious. And obviously IANAL so take all of this with a grain of salt.

When hacking a system without proper agreements in place, you shouldn’t be surprised that defenders would perform any necessary actions to protect their systems, including legal action and police officers knocking at your door. The legal systems are doing their best at defining and prosecuting cybercrime (Computer Fraud and Abuse Act for example) and there are instances where the perpetrators were actually prosecuted (check this article, this article, this article, or this one).

This brings us to one of the most critical aspects of pentesting — scope. Scope defines what should be included in the attack. Everything that is not included in the attack is out of scope and must not be touched at all. The scope should be explicitly agreed upon beforehand, and you should get it in writing.

Some of you might argue that a real attacker wouldn’t play by these rules. And while you are correct, remember that your task is to provide information about your targets. So try to voice this argument before a scope is established — after the scope is established, you should focus only on what was agreed.

Another thing to do before starting: verify that your customer can authorize the attack. As an obvious example — Evil Inc. cannot authorize an attack on their competitor Wicked and Co., although they’d love to do so. As a not-so-obvious example — an e-shop owner cannot authorize an attack on a SaaS that they use without some explicit precautions. If you are not sure, get a lawyer.

As a side note, it is your responsibility to ensure that nothing outside of scope is attacked. Your tools need to be precisely configured (therefore, you need to understand what you are using deeply) so that no collateral damage happens.

Penetration tests are a simulation of a cyberattack

To paraphrase a common saying — all simulations are wrong, but some of them are useful. Your goal isn’t the utter annihilation of your customer to prove your l337 skillz (that means elite skills — this style of writing about infosec from the 90s is hopefully going away). Instead, you should help them improve their security posture in a way that is as safe as possible.

This might restrict your activities and plans. Usually, you won’t be able to utilize social engineering tactics unless explicitly told to do so. Somewhat rarely you’ll be accessing outdated infrastructure riddled with holes you cannot touch — the goal of the test might be only the new custom-made application.

More often than not, you won’t be finishing your attacks. Discovered an RCE? Good, calling uname -a is enough; no need to escalate to root. Discovered an XSS? Good, just pop that alert, describe the risks, and move on. Verify that fixing your finding would stop the chain of the attack — you don’t need to waste your time (i.e. customer’s money) on escalations and lateral movement unless explicitly told to do so.

Another crucial difference between hacking and pentesting is the approach or method, or methodology. A real attacker only needs one usable vulnerability (or a vulnerability chain) to achieve her goals. A penetration tester should discover as many problems as possible, ideally all of them — so after a round of patching, there is not singular way for a real attacker to strike. This is aligned with bringing value to your customer — your customers don’t want to allow attackers access to their systems.

You’ll have some limitations when performing your attacks. These are usually time-based; you’ll be assigned a quite short time window to conduct the attack. This might make rate limits and firewalls fatal for your activities as you won’t have the time to perform a scan that takes several weeks just to comply with a rate limit. However, since the attacker might just be able to do so, you can ask for help — get that firewall exception for your IP, get that documentation or source code if possible. You are cooperating with the customer to discover as many vulnerabilities as possible — you are saving your time and the customer’s money, after all. Pentesting should evaluate the security.

Libraries of books have been written on the topic of evaluating security. Most of your customers didn’t read any of them. Instead, they’d like the answer to the question: “Is it any good?”

Or even worse, you’ll meet these pesky customers that like to have some quantification on that (after all, to evaluate — form an idea of the amount, number, or value of; assess. (Oxford dictionary)). So the question transforms to: “How much security do we have?”

Academically (and by that, I mean borrowing definitions from “academical” cryptography and economy), you should measure the amount of resources that the attacker needs to spend for his attack to achieve his objectives. Furthermore, if you are able to demonstrate that the value of the assets of the customer is less than the cost of the most efficient attack, you have officially won; no attacker would ever attack your assets as it is not an economically rational activity. Academics of the world, please forgive me for butchering some of your precise definitions, I’m trying to make a point here.

The point is — you cannot do the above as you are not omniscient. So you’ll need to come up with a different method of assigning severity to your vulnerabilities. There are some methods, most notably the CVSS vector.

Sometimes it is very applicable, and sometimes it is not, but overall it is a solid tool to keep under your belt. It is, however, far from perfect — as an exercise, try to rationalize any severity to any vulnerability, i.e. explain why a low severity issue is a high severity instead or downplay a high severity issue by manipulating the CVSS values.

Also, keep the general severity scale — informative, low, medium, high and critical. These lay out a good framework for task prioritization and that’s what the customer can use.

Finally, you come back with all these severities in your report and try to answer the big question: “Is it any good?” Then you’ll dodge that question again because you are not bearing the risk of operating this solution. You’ll try to explain what are the risks, what vulnerabilities are simple to exploit, and what are the consequences.

The customer must decide whether they accept the risk of the situation or not.

There is no such thing as a perfectly secure solution; everything can be attacked and destroyed. There is, however, a thing called acceptable risk. By fixing vulnerabilities, the risk is reduced. Every customer has a different acceptable risk level, so the most you can do is provide information about the risks in the solution. In some cases, high-risk levels are acceptable — consider early-stage startups. The cost of securing their assets might be several times higher than the total value of their assets.

Conclusion

In this article, I attempted to highlight key differences between a general hacking activity and pentesting as a professional service. Key takeaways in tl;dr form:

• get a precise scope and verify you are authorized to attack it.
• don’t attack anything outside that scope
• be time-efficient: ask for stuff that a real attacker might find out via trial and error
• be methodical: you should cover every conceivable scenario
• do your best to quantify the risk — the severity of the vulnerability
• do not ever report that a solution has good/bad security; acceptable risk judgment is not yours to make.

Hope to see you again. Good luck and have fun.