Exposing the common flaws penetration testers always see

Written by Joseph Poppy 28/09/2018

We live in an age where cyber security threats are (or at least should be) at the forefront of everyone’s mind. In 2018, British Airways suffered a huge security breach that led to almost 500,000 payment cards being compromised, showing that even the big players can still get hacked if they’re not 100% vigilant. It would be reasonable to assume that, with so much at risk, everyone’s security is as tight as it can be and it’s only the most skilled of hackers armed with the latest intel and tools who can penetrate such defences.

This is an incorrect assumption.

Here come the pen testers

The life of a penetration tester, or pen tester, is not a glamourous one. They work hard trying to breach or compromise system and network server infrastructure or even an application, so that a company can review their weaknesses and improve their security before a hacker gets around to doing the same.

Getting into clients’ infrastructure is always interesting, but sometimes they see something truly fascinating. They exploit a flaw or chain together an intricate series of attacks in such a way that us mere mortals are somewhat taken aback by their technical prowess. This is not always the case however.

The fact is, many penetration testers and cyber security experts (not just at Bulletproof) often see the same old flaws cropping up time and again, or worse, misconfigurations that even the most remedial of hackers would be able to spot. I asked our penetration testers what simple things they see over and over again, a sort-of Hall of Shame if you like. Here’s what they came up with:

SSL hardening

We’ve spoken briefly on the notion of SSL/TLS before. Without getting too bogged down into the nitty and the gritty, they are essentially the protocols used to keep the data being transferred between clients and servers secure. They authenticate the servers and encrypt the data.

TLS v1.3 has recently made an appearance, improving on from v1.2. The reason new versions come about, is because cryptographic flaws and various vulnerabilities get discovered in older versions and then disseminated among the hacking community.

To take a (very) simple analogy, if you were a cake maker and you discovered a cake recipe that contained significantly less poison than before, you’d be a fool to continue using the old recipe. Yet when it comes to TLS/SSL, many companies follow this flawed logic and continue to allow the use of insecure versions in their applications or throughout their infrastructure. Failing to make these important updates puts data at unnecessary risk, which leads me on to the next thing.

Failing to make important updates

I believe it was Aristotle who said, ‘A poorly patched infrastructure is just asking for malware’. This is less of a common, recurring problem (though you’d be surprised) and more of a flaw so severe our pen testers felt they should raise it. Failing to keep software up-to-date with the latest patches is like leaving your doors and windows open for burglars along with a post-it note stuck to the fridge that says, ‘help yourself to tea and coffee’.

Joking aside, the WannaCry ransomware that temporarily crippled the NHS back in 2017 managed to do so because of unpatched machines. There should be strict patch management within every business, with updates pushed out to all machines by policy.

Common or weak passwords

A penetration tester loves a common or a weak password. Specifically, they love your common or weak password. The standard user is not always tech savvy and they have many passwords to remember. So if they can get away with using Password1, they will. This is why enforcing a strong password policy and having security training for all staff is a must.

Password1 is less forgivable when you’re a system admin. It’s also somewhat worrying just how common it is to find servers or equipment with the default credentials still in place.

Password spraying, and other brute-force attacks, are a hacker’s bread and butter. Any weak passwords are going to get compromised. Then privilege escalation attacks will surely follow. Before you know it, your data has been stolen.


Cross Site Scripting or XSS, involve leveraging text input fields to insert malicious JavaScript into a page. If successful, this script will then be executed in another user’s browser to fulfil a range of purposes.

What makes this style of attack doubly malicious is, not only does it put user data (passwords, cookies, credit card details etc.) at risk, but it makes your website an unwitting accomplice. There are various forms of XSS attacks all with subtle differences, but the important thing to note here is that defending against such attacks is not too difficult. Good input validation and sanitisation practices can usually solve the problem.

It doesn’t take a lot of work to prevent XSS, so there’s no real reason to be vulnerable to them. Yet, more often than not, penetration testers are finding they’re able to inject code into otherwise well-crafted apps.

Directory browsing

Often, we make it all too easy for the hackers. There have been many cases (and will be many more) where pages not meant for public consumption can just be browsed to without requiring any authentication whatsoever. Whilst these aren’t advertised or linked to on the main page, with a bit of ingenuity or use of scanning tools, chances are they can be found. These pages could be areas only those with administrator-level accounts should be able to access. Whether they contain important information, or trivial files, it’s good practice to make sure the relevant restrictions are in place.

Poorly trained staff

This doesn’t always come up, as not all penetration tests contain a social engineering element. But when they do, well, companies tend to fail nine times out of ten. Using a variety of phishing techniques, our penetration testers attempt to leverage the human aspect of a business to gain access to or compromise a network. If they’re taking part in a red team project, they’ll even employ face-to-face interaction to try and get access to a physical location.

You might think that getting access to a restricted building would be a difficult task. However, it has been achieved with as little as two emails and a photoshopped printout of a pass. For all their technical wizardry, our penetration testers all agree that the easiest way to breach a network is to get staff to let them in. As touched upon in the weak password paragraph, a hacker only needs one set of credentials in order to do some damage. Even if you have the best cyber defences and out of 300 staff members, only one opens a malicious attachment or follows the link in a phishing email, that’s your network compromised.

In conclusion

We don’t think these issues will be going anywhere anytime soon. They exist for a number of reasons, oversight being one of them and in today’s fast-paced world, that isn’t likely to go away. Now that you know the basics, you can make sure you avoid them and get a good result on your next penetration test. You can rest easy knowing that your company or app is more secure than most, and also gain a smug sense of self-satisfaction, which is what life seems to be all about these days.

Of course, we’ve saved the biggest issues for next week’s blog. The issues that come up before a penetration test has even started. Make sure you stop by for some top tips on arranging and scoping a security review.

  • Bulletproof are CREST approved

    CREST approved

  • Bulletproof are ISO 27001 and 9001 certified

    ISO 27001 and 9001 certified

  • Bulletproof are Tigerscheme qualified testers

    Tigerscheme qualified testers

  • Bulletproof are a PCI DSS v3.2 Level 1 service provider

    PCI DSS v3.2 Level 1
    service provider

  • Bulletproof have 24/7 on-site Security Operations Centre

    24/7 on-site Security
    Operations Centre

Get a quote today

If you’re interested in our services, get a free, no obligation quote today by filling out the form below.

By submitting this form, I agree to the Bulletproof privacy policy.