Sessions is temporarily moving to YouTube, check out all our new videos here.

My First Pen Test: Lessons in Dealing with Security Testing

Luke Lanchester speaking at HydraHack in March, 2017
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

Discover how you can protect yourself from security attacks: with pen testing, you scan your application looking for little faults that would allow attackers to get in. You can start by doing it yourself, or you can pay third parties to do the job for you.


All right. All right, everyone, hopefully, this isn't going to be too technical. I've tried to make it more relevant for everyone, but this is a guide to surviving your first pen test, so kind of why you should, what you should, how you can. So, my name's Luke. I'm an engineer at 383, just down the road. So, I don't know if... There's a fair few of us around, if you want to chat to any of us. Suppose the first question is, what is a pen test? Kind of, move that out of the way. Kind of, you know, what does it actually entail? And, it's, basically, you are paying someone to attack your system. Hopefully, it's someone you trust. That kind of factors into it, and, kind of, it's good preparation. It's, kind of, you can attack your system, or you can let someone else, who you might not, and then you find about it when you're on <i>BBC News</i> and everyone's wondering why they're getting emails from spammers. So, why should you actually test? This is probably a good approximation of what some big platforms look like now. Before you know it, you might be working on one little wing of your application, not realizing that someone has left a port open that they used six months ago, or that API, which you thought you might need for that app, but you didn't actually need, no one remembered to turn it off, and, so, kind of, it's leaking all of your data. So, kind of, this is a chance to step back and objectively look at the platform as a whole. Kind of, what is your attack surface? Because, at the end of the day, you will have missed things. This is just a small list of things, which have been thrown up by pen tests that I've been through. So, kind of, someone said, "Oh, you've left ports open. You haven't actually validated that form." You know that one place you just use a variable really quickly? You promised you were going to come back and sanitize correctly, but didn't. Well, you didn't. And, kind of, these are all things which, otherwise, would've gone unnoticed. That's the biggest risk with pen tests, it's things you wouldn't have realized otherwise until they're used against you because, at the end of the day, you have to get everything right. But an attacker only needs to find that one bad misstep, that one place where you've left a window open or a door ajar, and they're in because, as soon as they can find one route in, they can use that and leverage it to find a dozen more. So, in terms of actually pen testing, you're scanning your application, looking for these faults, and, kind of, there's two main routes of doing this. You can easily start off by doing it yourself, so there are tools out there. Kali Linux, or BackTrack, as it used to be called, the OWASP Top 10. There's dozens of tools that they list to scan against those kind of vulnerabilities, and then, kind of, as you go through, just various other aspects of your platform. There's a lot that you can do yourself just to kind of try and catch things, so, if you run an SSL test, oh, you didn't actually patch your servers against BEAST attacks. Kind of, it just throws it up now before someone else is stealing your data in flight. As you move kind of up the scale, and, say, you've got e-commerce or more personal data, you're probably going to want to start paying third parties to come in. The advantage of a third party is they hold no biases, so, in your head, you might know that section of code's a bit ropey, so I'm going to test it. It's fine. It's not really. A third party, they're going to look at it, they're going to go through absolutely everything. There are automated tools like Detectify, which is really useful because they will test on a schedule. One thing that's often happened is people have released a platform, it's brilliant, it's secure. Six months later, someone's forgotten, oh, you've actually exposed this file and that. Detectify, constantly testing, so you can deploy an infrastructure change, next report, hang on, you've done something wrong. And, then, of course, you can pay actual companies to go away and audit, not just the application as the world sees it, but you can also hand over the code, and they will comb through it. And they will find every dirty little comment you've left that you meant to come back to and throw it straight back, which is brilliant. That's what you want. You want someone to point out all of your faults, because if they do it and tell you, you can fix it. One, kind of, mantra I've always lived by with any form of testing is if you do not find something wrong, then it's probably a sign you haven't tested thoroughly enough. It's the classic, if you get a bug report in JIRA, why didn't any of your unit tests catch it in the first place? So, kind of, if you get a nice report back that says, "You're all clear. Everything's good," start thinking like an attacker. What have I missed? What wasn't I looking for? Because, at the end of the day, you can never be 100% sure. This isn't a race with a finish line. There's always new vulnerabilities. Someone is always going to make a new marketing site for a new OpenSSL bug. It's just the way of the world now. What you are relying on is that you can remove the low-hanging fruit, which will stop those annoying script kiddies who come along to WordPress sites and riddle them with malware, which just makes you a little bit harder. It's kind of, you know, if there's a street of houses, and yours is the one with the nice, big lock on the door, the lights are on, people are going to look at you and go, "I might as well try next door." That's what you want for kind of your average everyday site, and that is my very, very, very quick blast through. So, hopefully, it gets us back on track. Does anyone have any questions? Go on. - [Man 1] What was a BEAST attack? Can you give us a rundown on that? - BEAST was one of the SSL ones. I think that was where you could pad strings and get an oracle attack back on it or something. I can't remember. There's BEAST, Heartbleed, Poodle. If you put them through... So, Qualsys, they do an absolutely amazing SSL test. You can give it a domain, and it will go away, and it will test all of your protocols, all of your cipher suites, kind of everything under the sun, and it will say, "You are vulnerable to this, this, and this." And, it will give you a grading out the other end, so, kind of, I put my own site through it once, got an F back, which is as bad as possible, and, now, I'm on an A-plus. It's kind of, you know, you can put HTS stapling and stuff on it, you can make sure you're resistant to everything. It's a good check if someone else has gone through and said, "You know, actually, you've done what you can do." Anyone else? - [Man 2] If you were to pick one and just tell us which one you use, then... - So, Detectify tends to be a favorite. We've used that a lot with a lot of our clients in that. It's got a very good, wide spread, so it will test your forms, so, kind of, try not to put it to anything too production worthy, otherwise, you're going to have a newsletter filled with a lot of funny email addresses. But it will also check little things, like the number of sites that have .htaccess files publicly viewable, sites that deploy via Git where you can actually access the Git repository via your public URL. I have seen that. It's brilliant because that's all your secrets gone. It'll just continually test for these little things. - [Woman] Cool. Thank you, Luke. - Brilliant. Cheers.