 Thanks, it's a very steep room, I'm gonna have to look up to make sure I can see it all. Okay, so at WordFence, we have the motto, think like a hacker. And the idea behind it is that if you're gonna identify the potential vulnerabilities that can be used to compromise your site, then it puts you in a much better position to defend your site from an attack. So my job here today is to teach all of you how to think like a hacker. So we're going to look at a couple of different vulnerabilities, specifically how they work and how you exploit them, and also how you can mitigate and patch against them. And the idea is to teach you what's possible, what attackers are likely to do, what they're looking for, and give you a better understanding of how to think like a hacker so you can protect your sites. So to keep things simple, we're gonna use this Chrome browser with the white barrel on the top as the site owner. And then when we wear the hacker, we're gonna use this one over here, it's got the black barrel top, which is the incognito mode, aka hacker mode. So the first thing we're gonna do is the simplest attack, is a brute force attack. So what that means is we're gonna try and guess the password. And luckily, because all we have to do is find a login form, it doesn't matter what the site's running. But we know it's WordPress, so the theme makes it pretty obvious and even if it wasn't obvious by the theme, we can look at the source code of the page and there are various super signatures that WordPress will leave lying around for us. So we can assume the login form from that. We'll be hiding in here, nice and simple, occasionally it's renamed, it usually doesn't matter though. And now we need the username. Well luckily WordPress is gonna help us with that, so check admin, no. See here it says invalid username, we know it's not admin. The guy that writes this site's name is Steven, so let's check that. It's not that one, okay. What else can we try? Well if you look up here in the domain, there's a username in here, we've got valorant, valorant.dev. So why don't we try valorant, we'll see if that's the site. Username, random password, the message has changed. See this? So now we know we've got the username for this account, we've got the login form, all we need is the password. And here's where the brute force attack starts. So simple brute force attack, you just start trying different passwords, that was QWERTY, three, four, five, password. Okay, none of those are the password. And we can keep trying that for hours and hours, we'd get kind of bored, but we could eventually find the password. There is a much easier way and we can automate the attack. So there's a tool called WPScan, which is a WordPress vulnerability scanner and pentesting tool. And it provides a bunch of different features, it'll scan the site to look at different versions to work out what you're running, find vulnerabilities, and has some tools built in as well, including a brute force password attack mode. So we'll jump on the command line and we'll use that. So you can run it by WPScan, you'll tell it the sign address. Yeah, I won't try and talk while I type, otherwise it's gonna end badly. And you're right. Yo, so we're gonna tell it we want to enumerate the users to figure out all the users on this site. And we're gonna tell what we want just to figure out the passwords. Oops, gonna use the password database. So run through that. So what the password database using here is RockU, which was a site that was breached about 10 years ago. I think that was what 32 million accounts that came from that and they had plain text passwords. And so they extracted 14 million unique passwords from this database. And what that allows, gives us, is 14 million passwords that have been known to work and many of them have been renewed many times. And so we can try then as part of an attack to see if anyone is reusing those passwords. And so you can see up here, WPScan identified four users. The first one's actually not a user, it's the display name of the Valoran user, but close enough, it's figured out Valoran based on various things like the JSON API, the author API, login error message. There's also a support user and a mark user as well that's figured out. And as you can see down the bottom, we've got two password hits, Valoran's password there, which is something you might recognize. And there's also password for the mark user. It hasn't figured out the password for support. I could leave it running for a while, but it's not gonna figure that one out. It's a different password. So now we've got the password. We can go back to the login form. Notice how quick that was. Well now we're in on this site. We've got whatever we can do whatever we want now. Nice and easy. All right, so Hacker's gonna log out. So how do we fix this problem? And luckily WordPress can help us there too. So the simplest and most important thing we can do is set a good password. Oh, come on, there we go. Okay, set a good password. So if you go into your profile on your WordPress site, when you go to a new password, it hopefully gives you a password. So that is a randomly generated unique password that's not going to be guessed by a brute force attack anytime soon. So there's really no reason not to use that password. Any password the WordPress generates for you like that, you should use it. It's gonna keep your account safe from a brute force attack. But the question that everyone asks about after this is how do I remember it? And you don't. You don't want to have to remember these passwords. So that's where a password manager such as one password comes in. And so you store all your passwords in the password manager and then you remember the login details for the password manager only. And then all you have to do to access the site is you log into your password manager, grab the credentials and then log into your site. Nice and easy. Sorry, one password is the one I use. There's also last pass and pass dash lane, a whole bunch of others. If you need a list come and find me at the end I can talk you through the different options. So yeah, so use a password manager. I cannot stress it enough. But the thing is of course, not all of your users are going to use strong passwords even though you tell them use a strong password. And so that's where you need a login security plugin. So there are a bunch of different login security plugins in the repositories. I've just searched for login security here and it's found some things. And so what a login security plugin will do is it adds a couple of different extra features to your site. So first up, it'll add something like brute force cloud-based protection. And so what that allows it to do is detect brute force attacks from multiple IP addresses and block those attacks. So the wordfence.con site, we got hit by a brute force attack from over a million different IP addresses that are each doing a small number of requests over the millions of different IP addresses. And so we're working on the feature at the time but we enabled Google recapture on there which is a cloud-based login protection system. And what it allowed it to do was block those attacks entirely because the brute force attack wasn't able to authenticate through that and it stopped the attack completely. And these login security systems will also include things like two-factor authentication. So you can have a unique token generated on your phone. And so when you log in, you type in your password and you enter the token from your phone. And the benefit of that is a brute force attack, if it's going to guess the password, isn't going to get the token from your phone. In order to steal the token, you need a targeted attack directly at that user to grab the token via phishing or some other method. And so it completely eliminates brute forcing as well. So, okay, that's just only enough. How important it is to have some form of login security plug-in on your site because it'll protect your users that aren't using good passwords. So now we could set that password and run the brute force attack again. It wouldn't find anything but we don't have time for that so we'll move on. So let's pretend that there's a solid password and we haven't got in. So what's the next thing we can do? And as I mentioned before, don't be scan scans of vulnerabilities and version numbers. So we'll scroll up through the output it provided. Where is it? No, I gotta find it. Scrolling is not working today, there we go. Okay, so hopefully you can see that. It says there are 52 vulnerabilities found. So this version of WordPress is version 4.7. It was released in 2016 in December. So it's quite old. And as I just said, it has 52 vulnerabilities. So that gives us potentially 52 different ways to compromise this site. So one of the ones we're gonna look at is this one here, this is actually one of my favorites. It came out just as I started working in WordPress security so it's a bit sentimental for me. And it's just so easy to exploit. So what this vulnerability does, it allows you to modify page and post content without having to log in at all. Which is really cool, so I'll show you how it works. So we'll go to the site. We'll find a page, a post actually. Got a hello world because why not? What we need to do is figure out the ID of this post. Luckily WordPress is going to help us here. We'll go to the source, comment, oops, can't type today. Yeah, I really can't type. That's it, okay, comment post. Right here it's telling us the ID of this post is one. We probably could have guessed that from hello world but so be it. So now we know the ID is one, we're gonna update the post. Go back to the command line. And let me just type this in. Oops. Now the URL, so you need the URL for the JSON MPI which I can never remember, so it's written down next to me. Post one, oops, one, okay. Oops, equals one, right. Now what we wanna do, title, we'll change the title to greetings. And the content too, good. It's still morning, right? Go. Yes, 20 more minutes. Great, okay. We'll run that, nice big block of output. Go back to our site. Refresh the page. We've updated the post. Nice and easy. Now those who recognize the command and notice there's no authentication in there at all, no cookies, no nothing. That's how simple it was. And so we saw hundreds and hundreds of sites hit by this when the vulnerability was released. So what happened? WordPress, security discovered the vulnerability and quietly told WordPress. They fixed it and rolled out the update quietly. They didn't announce that they just rolled out the update. And then a week later, they disclosed it. They told, they announced what the vulnerability was. They allowed that week for automatic updates and updates to be applied in order to fix the vulnerability. They didn't wanna leave it too long so someone else couldn't discover it. And as soon as they did announce it, Attacker started using it. And they were searching websites for WordPress 4.7 that weren't patched and they're updating posts here and everywhere in it. We were cleaning so many sites. And this is one of the reasons I remember it was there was so many sites that were cleaning. Luckily it was all in the database. It was fairly easy to clean, but the fact is it was still very easy for them to exploit. And you get things like crypto miners and the face mints and irrimingers and that sort of thing in there. So it was quite bad. So the question we have is why isn't this site updating? Because why hasn't this site replied the automatic update and fixed the problem? So we're gonna go check site health. And those who know WordPress version numbers are gonna know I've done something really weird with this site. But we'll scroll down and wait for it to load. There we go. Have a look in here, critical issue. Automatic updates have been disabled. So the site owner of this site has disabled automatic updates for whatever reason. And there are some legitimate reasons to do it, but the problem is if you disable automatic updates, you need to be really careful about applying your updates as quick as possible. So as soon as an update is there, you have to go review it, you have to test it and apply it. You can't just leave it sitting around for days or weeks. Because it was less than a week, it was about a week when they released the update and then disclosed the vulnerability and then sites started getting hit, hit. So if you spent longer than a week reviewing this plugin, your site was gonna be hit from it. So we'll get rid of the config. What is it? Okay, so we'll go into the config file and automatic updates are disabled via this line in here. So we'll comment that out and we'll go back to here and more fresh the page. Wait for it to load again. It's still loading and it should be gone. There we go. This site's now going to automatically update to the latest version and protect itself. We don't really have time to wait for the automatic updates, so we'll just go and apply it manually. There we go. But normally, if the automatic updates were working, then this would have happened sometime during that week. It's a couple of days depending on your site. A couple of hours if you're lucky. But because of the disclosure period, they maintain for the vulnerability. Disclosure, either sites were pretty safe that had automatic updates available. So that's just running through its update. Hopefully it won't take much longer. And there we go. Doing weird things. Okay, it's updated now, so we'll go back into our command line and we'll run this again. How are we? Oh, run it again and we've got a new error. Got an error here, actually, I should say. So the fix for this vulnerability comes from how it's being exploited, which is the ID value here. So what's going on in the code, in the old code, the vulnerable code, is when the request comes in, it says, okay, so I've been asked to modify this post with an ID of 1WCBNE. And the code goes away and says, okay, find me the post that has the ID of 1WCBNE. It checks the database, the post doesn't exist. So it doesn't care anymore. It just says, okay, that's fine, keep going. There's no post, we don't have to do any authentication. Which is kind of silly. Because the next bit of code says, okay, so we asked to modify the post that has an ID of, wait, this should be a number. Let's turn it into a number. So it turns it into one. And the checks the database and says, is there a post ID one? Yes, great, we've got content, great, update it, done. And so that's how it's bypassing authentication is because the ID has been turned into a number after it's authenticated. So the fix here is they're enforcing the ID value to be an integer, a number. And so when the request comes in with the ID of 1WCBNE, it's rejected initially because the ID is not an integer. The ID is not a number. So that's the simple fix they applied, which patched up the problem. And as I said before, it had automatic updates running. Your site would have been protected and you'll be fine from that one. So that is a core vulnerability. You might have noticed there were also some other updates to be applied. So we're gonna look at one of them now. So, wait for it to load, so here we go. So we're gonna look at this one in the middle. It's IP block align. So this is a simple little extension that allows you to block IP addresses from accessing your site. And the idea is if you know an attacker who's using your site IP address and is gonna attack your site, you can block them to rent them from getting to your site. So we'll go and ignore its instructions and we'll block ourselves. Hopefully this won't backfire epically because that could be funny and bad. Okay, so we're gonna block ourselves. We'll go back to our hacker browser, refresh the page. We're now banned by the administrator. So with the attacker, we see this page. This just gives us more reason to wanna try and attack this site because why not? It's also very easy to get new IP addresses. You can get VPNs, you can use Tor, bunch of ways to get different IP addresses. So ultimately this isn't gonna do much. So with the attacker, we wanna figure out how can we exploit the site. Well, let's do some recon, figure out what we're dealing with. So we'll view the source of the block page and it's telling us we're running the WordPress IP address blocker pro plugin, the light version of the plugin and the version is 10.3. And as we've seen before, version numbers are fantastic because we go over and check the vulnerability database and we have a vulnerability for the IP address blocker version 10.3. So this is a vulnerability known as a CSRF leading to arbitrary file upload. So CSRF is cross-site request forgery and how that works is if you log into your site over here and I as a malicious person can get you to visit my site here, my site can make fake requests to your site. And in many cases, all you'd be doing is updating options and the face when it's just causing some minor nuisances, but in some cases you can do a lot worse. And in this case, what you can do with the CSRF vulnerability is get the malicious site to upload a file onto the site you're logged into. And because it's an arbitrary file, we can get a remote shell and get full access to the site. So let's see that action. Let's see, first of all, we've got to unblock ourselves. Where we go? Okay, so we'll pretend that we've got a new IP address. Obviously, it's easy just to unblock in here. Go back in. So what we need to do as the attacker is get the site administrator to visit our site. And the question is, how do we do that? Well, it's easy, it's a blog, it's got a comment section. So let's exploit that. So, hi, I love your site. I wrote a review. Oops, where is it? Obviously, we'd use something a little bit less obvious, but you get the point. Oops, okay. That's in there now. We're the site owner. We're going through our site. We see, oh, look, someone's left his comment. Oh, great, they wrote a review. Let's have a look at it. Oh, nothing to see here. Oh, well, let's go away. Nothing to see here, right? Yeah, well, now the hacker knows you visited their page. They can go to the site and they can go content, uploads. What is it, 20 or eight, shell, PHP, hack, remote shell. We can now run whatever PHP code we want on that site. It gives us full access to do whatever we want. Currently, it's listing all the files in the directory. We can, I don't know, we can say hello. We can read the config file, run a crypto miner, DOS, how competitive site. So we can do all sorts of fun things. Game over, basically. So, what's the fix here? What can we do to prevent this from happening? And as a user, as a site owner, what you really should do anytime you get a suspicious link like this is open up in Incognito mode, because whoops, that was really not what you should do. Okay, right click on it and you go to open Incognito window or private window or whatever it is that your browser calls it. And what that does is it opens up the malicious site in a completely separate environment which isn't logged into your site. So even if this is a vulnerability such as this one we just exploited, it's not gonna have access to it and that will protect you from that. And you should do this anytime you're visiting strange links to comments in your blog or even comments on forums or emails, anything like that. If you're not sure where it comes from, if you're not sure of the site, then it's best to open it in an Incognito window because it protects you from any sort of attack like this. And the other thing, of course, is, as we saw before, there's an update available for this vulnerability. And the update was made available pretty quickly. And the fact that you have to go and physically open, say, a link in a comment or visit a specific page to be attacked by it means that you're more likely to see the update before you get hit by the vulnerability. And if you see an update for a plugin, go have a look at it. Open it up, click on the details and check the change log because we can see here that 10.4 has security enhancement. So this version, this update, we know it has security fixes. We should apply that as soon as possible. We shouldn't delay on the home. And so we'll go and update that one. And the question from a developer point of view, how do we fix this? And for CSRF attacks, the fix is to use what's called a nonce or a CSRF token. And WordPress makes that incredibly simple. So if we go and view, this is the code they changed. This is the change they did to fix the vulnerability. And we look for nonce. So you can add a nonce field into your form here. It's just lying here in the middle. And what that does is it adds a nonce onto the form. And so when the form is loaded in the browser, it generates a random token and it sends to the user. And then when the form is submitted, it has to send that token back. The server will reject any request to do anything if it doesn't have that token. And that's set down here. So it's running a WP verify nonce function, which is where it checks if that's in the response. And the way the reason this works is because browser security policies mean that the malicious site cannot read any data from your site. See, it can't get the nonce. There's no way for it to get the nonce. All it can do is send requests, but it can't read the response. And so if you've got a nonce running on the form, it blocks them entirely and there's no way that it can exploit the vulnerability. So it's a nice, simple fix. And as I said, WordPress makes it really easy. So that is this fun and really. But what if there's a bigger vulnerability, something like a zero-day on a site? So for those who haven't heard the term, a zero-day means the developer has had zero days to fix the vulnerability. So it's out there being used in the wild and the developer doesn't know about it or hasn't fixed it yet. And there's one we discovered, I think it was asked, I don't remember exactly who discovered this one, in an extension for WeCommerce. So this one here, it's the abandoned cartlight for WeCommerce has a stored cross-scripting vulnerability. And so what that means is you can inject JavaScript onto a page and save it on the database. Then when the administrator views the page, it executes the JavaScript, which gives you full control over their browser. You can do whatever you want. I'm noticing a pattern here. So go to the shop, we'll add something to the cart and we'll go to the checkout. Okay. So the way it works, it was on the form when it's having in details. So put a first name, put some JavaScript in here, where it's, you've been phoned. Here are your cookies. Oops. What is it? Yeah. Cookie. Hopefully I've got that right. That box is tiny. So it's really hard to see what I've typed. And then you've got to put an email address in for it to save properly. Oops. No, we don't want to reveal who we are. Use it there instead. Okay. So that should have sent it to the site. So we're a site owner. We're viewing our, where's my mouse? Okay. We're viewing our abandoned carts. There we go. We've been hacked. Nice and easy. And every time that page gets loaded, it's going to run the JavaScript. And normally it wouldn't announce a presence like that. It would be subtle in the background. And see, it wouldn't even know what's going on. And when they exploited this in the wild, we'll go down in here. What they were running, I can find it. Here we go. What they were running when they exploited this in the wild was that code, which was creating a new administrator account on the sites that were hit by it. So once they create an administrator account on the site, they can log in and do whatever they wanted. You know, change the payment details, steal customer information, you know, send fake products, that sort of thing. So this was quite bad. And because it was a zero day, it was exploited before anyone knew about it. So there were no updates available to patch this vulnerability at the time. And all you had to do was access the abandoned cart's page for it to be executed, which made it really, really easy for them to take over your site. And there wasn't much to do. You weren't clicking on a new link or anything like that. You were just doing something you would normally do as part of maybe your daily process. Okay. And I'm running out of time. Okay. Okay, so what you can do to fix this vulnerability is to fix zero day vulnerabilities. Is this where a firewall comes in? And so luckily, I know someone that makes a firewall. So we'll go and enable WordFence. WordFence security, and enable give it. Come on WordPress. Enable yourself. Give it a sec. Okay. Come on. Here we go. Okay. So we'll go back to our checkout form. I'll open the inspector. And if we just change this to trigger it to update again, we should see a nice big red warning over here. WordFence has blocked it. So WordFence has a default rule to catch CSR cross-scripting attacks and a block this by default. So if you had WordFence or another firewall that has similar rules running, you would have been protected from this from the start and your site wouldn't have been safe regardless of the update being applied on the side or not, which is really, really useful. Okay. So something else that an attacker will do when they're trying to attack a site is they'll look for different things like backups of configuration files or your new installations that haven't been applied yet. So this site, for example, we have, oops, give it to that, has a new install that hasn't been run. It's still sitting there waiting for someone to run it. So we're an attacker, we might as well just, what is it, set up attack? Yep, might as well just attack it ourselves. So we're in the script. It takes about five seconds. Maybe. There we go. Refresh the page. Looks like the site's not all right. We're still on the installer. But, oops. Hello. Yeah, can't type today. And I really can't type. There we go. Remote shell in this new installation. And the site owner's gonna come back. They're gonna run their install. They're not gonna see any different. They're not know their site there. Installer is backdoor. And this gives us full access to the site. And we can also, because we're running in subdirectory, go back to the full site that this is running subdirectory of. So we can infect that one as well. Again, game over. So the thing about this one is, an attacker isn't gonna find that instantly. They're gonna have to be searching your site to find it. So you can copy up the setup script and you can run it. And we should do it within a couple of minutes. Usually you're safe. There's very, very low chance they're gonna find it that quickly. But you don't wanna leave it there, leave it sitting there for hours or days or weeks or months or years. And with clean sites, we've had a thing like this sitting there for years. And it's been compromised so many times because an attacker comes along and installs it, configures it, removes all evidence and the site owner's forgotten it's even there. So you really need to keep track of any new installations that you put on the site. Okay, so last thing to talk about is plugins. Okay, so there's a belief that some people have is that if a plugin is disabled, you can't do anything. It's safe, the code's not gonna be run and that is a very big problem. Because there are some plugins that respond to requests that don't go through WordPress. So for example, this one here, Adobe Auto Suggest has an unauthenticated SQL injection vulnerability. What that means is we can modify the database queries that are applied to the database. And if you can do that, then you can update the login details, you can bypass passwords, you can extract information, delete information, change stuff. It gives you full access to the database. And the reason why this works when the plugin is disabled is because the URL, it goes directly to the plugin, it doesn't go through WordPress. So we'll grab this and we'll see what we can do with it. Update the URL, our voice is not gonna work. Okay, now what we wanna do is figure out all the databases on this site. Oh, wait a minute. You'll notice our firewall WordPress has blocked it again. So this is another reason why you want a firewall running on your site. It's because it can block attacks like this. So this is again, something that is a generic rule in WordPress is blocked. And our firewalls of similar will block this sort of attack because they can detect the happening. So we'll run this again. And now we've got the database. So it's giving an information schema. We know now the site's database is hackDB. Tables, you wanna figure out the table prefix because sometimes that gets changed. And look, it is hackDB underscore thing. Users, we want user pass. User email, user login. What's the thing? And I put that on there. Okay, that's now gonna download the users from the database using this vulnerability in this disabled plugin. This gives a signature to passwords as well as a password that's barely purchasing. So, well, that's running. Are there any questions? There's a mic over here. There we go. There's our email addresses, our hash passwords and our login details. The bottom hash is an MD5, which is trivial to find in the lookup table so we could log in as that user as well. He was also an administrator from RL Count. Yeah, I'll throw it over to questions. Good morning, thank you. I've got a question about, after viewing all of that wonderful things, last pass or those password protectors? Yep. Are they safe? Yes, the big ones, like one pass words, last pass, and pass, dash, name, all those things. They spend a lot of time and money making their products safe. Even one password, I know they have a $1 million bounty. If you can compromise one password and extract passwords out of it, they will give you a million dollars. That's how sure they are their security is safe is because they're putting their money with their mouth is. So, yeah, you can trust those products because of that. Let's go. What do you think of EasyUpdate Manager to keep everything up to date? Well, for core updates, definitely let the automatic updates happen. And the health check in WordPress 5, whatever it is, will tell you if automatic updates are working properly. And so, you can check that to make sure automatic updates are there for core. And for plugins and themes, a tool like WordFence or probably others will actually alert you when their updates available. And so, as long as you've got alerting working for the scanner, it'll tell you to go in and apply the update. And as long as you go in and do it within a day or two, you should be fine. And as you're having a firewall, the reason why you want to run a firewall on your site is so that it can protect you from attacks before you do the updates as well, such as the ones we saw there. The firewall was blocking them. So, if you keep a firewall and then apply updates when you're notified about them, then you should be fine. Where can I get all those fun little tools of yours? That link up there, the SSID-A-U, has all the information I was talking about, including one of the things I skipped. And I've got links at the bottom, to WP Scare and SQL Map and such. And also, if you've got any questions, email me, steven at wordfence.com. And I'm running lock picking out of the hallway track shortly. So, ask me any questions over that. And I can teach you lock picks. And I've got a bag full of WordFence swag that's really, really heavy. So, please take some, because I don't want to have to carry it for the rest of the day. It's ridiculously heavy. Thanks so much. Steven, thanks for that. The WordFence plugin is available in a free and a paid for solution. We see on some sites where we've got it installed in the free version, where it's clear that the site's being attacked and the attacker then just changes IP addresses. So, it goes ahead and blocks the IP that it comes from, but then within seconds, it just randomly generates IPs and comes from. Are we doing something wrong? Is there a way to block that out with the free version? In the WordFence premium version, we have the, oh, come on, the real-time IP block or whatever it's called. And the idea of that is it uses the entire premium WordFence network to identify malicious IP addresses and block them proactively. And so, in order to block attacks where the IP addresses are changing, you need some form of infrastructure around it, some cloud-based solution. And so, that's what's part of the paid version of WordFence, is that it can track it from there. I mean, it works pretty well. We haven't had it breached, but I look at it and think, is there a better way? Yeah, the problem is it's so easy to change IP addresses that all you can do is try and block them when they come up and detect the attacks. Thank you. Okay. As far as I know, yeah. Yep, good question. Does WordFence play well with S2 member and other membership plugins? As far as I know, it does, yeah. In the firewall rules that you can whitelist half, so if it does block things that should be blocking, you can add whitelisting in there. And so, you can allow through the specific calls that are being blocked if it's causing problems. And if you're a premium subscriber, we've got the support you can reach out to if I help, and that's something we can help with. Things with, we make changes to WordFence if we need to, if it conflicts other things. Like, we recently got made changes to get it working in WP Engine, which is fantastic. We've been wanting to do that for ages, so we're finally working on WP Engine, okay? So, yeah, if there are specific problems with plugins, we can look at it and try and work around it, yeah. Do we have any more questions for Stephen? I have a question for you, Stephen. Yep. So, let's say that I have a bunch of client sites and I want to see how hard they are to hack. What would your advice be for developers who want to put their sites to the test? How do you start thinking like a hacker? Like, what would be the first thing that you would suggest for them to try? If you're a developer and you want to start thinking like a hacker, I'd recommend looking for CTFs to capture the flags. So what they are are hacking competitions. We've got sites, specifically set up vulnerable sites that you've got to try and break into. And so it teaches you to look for the different ways you can break into, like trivial things like the SQL injection. You'll often have a login form that you can modify the query through or config files that are in plain text, that sort of thing. And so, that's a fantastic way to start. If you're a developer wanting to get into security, you're looking for those sorts of things because it makes it a bit of a challenge and you get the momentum building up as you start solving the challenges. Fantastic. Who is it? Who's going to try and capture the flag? I think I'm going to give it a well. We used to run one at the US WordCamps but we've stopped doing that now, unfortunately. Do we have any other questions for Stephen? We've got a little bit of time before our next presentation. So any last questions on the back? Anyone? I think we're done. So wrap up then, Stephen. If there's a little bit of time, I can show you the thing I dropped off my list. Yeah, go for it. Cool. The other thing I was going to talk about is I'm a null theme. So I don't know if anyone here has heard or used about news, null things and plugins before but I'm sure I answered don't. So the one thing I faked for this talk is let's imagine that 2019 is actually a paid premium theme. So I wanted it on my site, I didn't want to pay for it and so I found it on a null theme site. So I've downloaded, I've installed it, I ignored the thousands of ads on the null theme site and I've installed it on my site. I'm pretty happy with that, but there's a problem. If we go down the bottom here, select everything, so that bottom line. If I go into source, what they've done when they were removing a license thing from this plugin is they've added in a bunch of different SEO spam links and so what they're doing is they're using my site's reputation to promote their own services. So for example, nullplugins.com is promoting themselves. He will say about how to hack a toolkit. Apparently, where can't Brisbane get advertising from null things? Who would have known that? And some guy called Stephen Rees Carter also does these dodgy people. Okay, so that's the problem and they do that all the time but there is a bigger problem if you're using null themes and plugins because they're modifying the code, you don't know what they've also added. So in this case, yeah, where's the URL? Go over here. They've added a back door. So now this attack of the person that writes these null themes can log into your site, do whatever they want, add crypto mining, dosage competitors, that sort of stuff, right? The other important thing to note is there are sites like this, a source code search engine which means you can find websites based on the source code they've got. And if we go back to here, where was it? You'll see this thing like here, I've got this thing 2019. Now if they add in some unique HTML in there, they can then use the source code engine to find your site. Once they've found your site, they can use the back door they've installed and they've got full access to do whatever they want on your site. And we're investing in, at the moment, a specific null themes plugin site that we've downloaded all of the, we've crawled through their site, downloaded all of the ones they provide and they're all infected with malware. Every single download on that site has malware in it. So as soon as you download that null theme or plugin and put it on your site, your site's infected with malware. And so I don't have anything to say, just don't do it. Pay for the license or get something else. Get something that's free that's in the repository. You don't want to touch null themes and plugins. And the fix of that one obviously is you go and delete the theme or plugin and you install the proper version or something else. Then you want to run a malware scam because it might have affected across the other different sites. Yeah, I think that kind of covers it all up. It's the only thing I was going to show there is still time is that hash at the bottom. So remember how I said this is an old hash? So there's old users, if we grab that and then we go over here, we've got a lookup tool, reverse that. And that's the password for that username. So now we can log in as that user to the site. So even though all of the other accounts on that site have got them modern hashes, that's an old account that's been sitting there for years, full administrator, we can now log into the site. So the SQL injection vulnerability that allowed us to download this page allows us to get in as well as a site owner. So again, full access to do whatever we want. Yes, so... Sorry, can we just get that one through the microphone just so that we can pick it up? I was just saying, can you tell that it's an MD5 from the length of the hash? Yes. Is that the... Yeah, the MD5s have a spookling, I think it's 32 characters from memory. Shell ones have 40 characters and then as the hashing algorithm gets stronger, they get a bit longer. A Shell 256 is quite long and 512 gets even longer. But you can also tell it by looking at it, these top two are very different. So the dollar sign, P dollar sign, that's telling WordPress the hashing format. So it says that specific hash format, I can't remember what they're using, it's not possibly a B-crypt or something. And WordPress knows when it sees that, you can apply that hash and work out how to compare the password. And if it doesn't see that, then it knows that that's going to be an MD5 because that's the old legacy password that you used to use in the supports both. Yeah, can we just grab a microphone down the front here? Yep, just this gentleman in the middle. So as far as fixing old password hashes, is that just a matter of updating your WordPress, maybe changing the salt in the WP Conf and just making a new password or just making new password once the upgraded? You don't need to change, if you're one upgrade password from the MD5, you don't need to touch the salt. We just go and change the password on the user. I think even if they log in, it might reset the password at that point. I think that's what WordPress does from memory. So as long as that user can log in, if they're an old user and they haven't logged in for years, then reset the password on them, or just delete the account. If it hasn't been used that long, delete it. There's probably no reason it's there. Yeah, but a login or password change will reset the password. Yeah. Just one last question right up the back. Yep, gentleman up the back. Hang on, if we just wait for the microphone to come up just because otherwise it doesn't get picked up on the recording. If they auth off LDAP, does it drop a hash in the local WordPress table as well? I've got no idea. Honestly, I haven't used LDAP with WordPress. You'd have to have a look in the database to see what it puts in there. Cool, thanks. But some single sign-on systems, if they don't grab a password on the way through, they're not going to generate, store some passwords in the database. They'll use them online. Yeah, you wouldn't think. Yeah, it does. I'll just throw it back to this. In case you want that again, yeah. And as I said, if you've got any more questions about stuff or links to anything, just send me an email. Fantastic. And how can we find you on social media, Steven? Um, I, it was on my front page. Are you on Twitter? Yes. Everyone's on Twitter, right? There we go. I should have put on that page too. What's the hashtag? WCBNE, yeah? Who's already posted today with hashtag WCBNE? All right. I'd like to see those hands doubled by lunchtime, please. Yes, I'm Lauren on Twitter. Yeah. Fantastic.