Join Osom to know newsletter!
Get your monthly dose of WordPress information.
Welcome back to another episode of Osom to Know podcast! This time we explore the world of bug bounties in a fascinating conversation with one of the experienced bug bounty hunters, Mat Rollings, aka “Sealthcopter”. Mat shares his journey from development to uncovering over 500 vulnerabilities this year, offers insights into the role of AI in security, and uses tools such as Semgrep and Psalm for open source analysis.
We discover practical tips for WordPress security, managing plugin updates, and navigating the impact of potential forks on best practices. Matt also discusses his dynamic analysis plugin, designed to uncover hidden vulnerabilities, and emphasises simplicity and education to turn vulnerabilities into opportunities for better security. Subscribe for more episodes that combine best web development practices with cutting-edge stories from great people from the tech.
Mat Rollings [00:00:00]:
I’d very much always try and frame it as, like, how can this be a learning opportunity to developer and the development team as a whole rather than, like, this developer made a mistake. They need to learn not to do it again or we’re gonna fire them. So, yeah, there’s a lot of, kinda silly coding mistakes I found. And because that install count was much lower, you get to see a lot of the stuff that hasn’t really had many eyes looking over it.
Maciej Nowak [00:00:25]:
Stealthcopter. Right? So that’s your nickname? You’re, known in the security space by this nickname? Hello, everyone. My name is Maciej Nowak, and welcome to the awesome to know podcast where we discuss all things related to building great website. In this episode, we are diving into fascinating world of back bounties with, our guest, Matt Rollings, a security expert known in the community as Stealthcopter. Matt will take us through his journey from developer to full time bug bounty hunter, sharing insights on vulnerability discovery, WordPress security, and the art of spotting overlooked flaws in the code. We will explore the value of bug bounties for companies, the common mistakes developers make, and how he’s helping to shape a safer ecosystem for everyone. Get ready for an eye opening conversation on the hidden side of web security. If you don’t want to miss new episodes and keep learning, please subscribe to our newsletter at osomstudio.com/newsletter.
Maciej Nowak [00:01:26]:
This is osomstudio.com/newsletter. If you are watching us on YouTube, subscribe to the channel and give a thumb. This means a world to us. Without further ado, please enjoy my conversation with Matt Rollings.
Lector [00:01:50]:
Hey, everyone. It’s good to have you here. We’re glad you decided to tune in for this episode of the Osom to know podcast.
Maciej Nowak [00:01:58]:
Hi, Mat. I’m happy to have you on the podcast.
Mat Rollings [00:02:01]:
Hi. Thanks for having me.
Maciej Nowak [00:02:02]:
Can you explain to our listeners, what bug bounty is so that, you know, everyone can get a gist of what we are going to talk about today?
Mat Rollings [00:02:12]:
Yeah. Sure. No problem. Yeah. So bug bounty is where companies will pay, cybersecurity experts, hackers, developers, to find vulnerabilities in their software or websites, or general any kind of, programs that they, deem critical to their day to day running in the business, anything that has, like, personal data behind. They’ll offer bounties up, so they’ll put a price on getting into certain systems or hacking certain things. In the case of WordPress, certain plugins and themes. And if you can demonstrate to them how to hack in an impactful way, their software, they’ll give you a monetary reward.
Mat Rollings [00:02:56]:
So it’s a great way as a security researcher to be able to make income while also securing the ecosystem.
Maciej Nowak [00:03:04]:
Alright. And why would companies would like to do that?
Mat Rollings [00:03:08]:
Well, it’s, it’s basically a cheaper way of managing cybersecurity threats. So if, some bad actors so you could have, spammers, cyber criminals. If they attack your website, they could do real financial damage to your reputation, to your website, to your customers. So if you can pay cybersecurity researchers to do this for you, show you how it’s done, help you fix it, then you you’re you’re effectively saving money and saving reputational damage.
Maciej Nowak [00:03:43]:
It’s like outsourcing security to outside people, something like this?
Mat Rollings [00:03:47]:
Yeah. Yeah. Perfect.
Maciej Nowak [00:03:49]:
But at the same time, I’m thinking about isn’t it like blind spot if you rely on bounties too much? I’m, like, I’m not saying this is the case, but, it’s like the internal theme is not sufficient in these cases?
Mat Rollings [00:04:05]:
Yeah. So bug bounty tends to come at quite a mature stage of, like, cybersecurity and within a company. So, typically, with a normal company, you would have, pen tests where you either have an internal team or you hire a third party to come and review your, either review your code, review your network infrastructure, and try and break into things, within a specific scope. And so it it’s not kind of something that’s designed to replace other security stuff. It’s kind of, an additional, step. So it helps you get that security and depth, which is what you really want. So, yeah, you shouldn’t rely on it as, like, just to solve all your problems, but it’s a really good way of being able because if you have, like, a massive public scope, you’re gonna have so many more eyes on your code and your network than you would by just having, like, typically you’d have, like, 1 or 2 pen tests a year. So if you open up this scope for a bug bounty program, you’re probably gonna find lots more vulnerabilities that might be missed during, a penetration test or over security reviews.
Maciej Nowak [00:05:18]:
You mentioned the public facing part. So you have many customers and so on, many eyes looking at the code. And I think this happens with open source a lot where this is the… there’s a potential that there are many people looking at it. At the same time, it’s, you know, the second edge of of the same sort where a lot of hackers all are doing the same thing. And there is always the discussion whether, you know, working on top of open source software is safe approach or better use, a technology that is closed source, for example? And what are your, takes on it?
Mat Rollings [00:05:59]:
Yeah. I mean, it can be a double edged sword because the the, like, the any adversary could have the source code, so they may be able to develop those exploits easier. But I don’t think it’s a good argument that just because it’s closed source, an attacker wouldn’t be able to develop an exploit for it. It might increase the costs to an attacker to do it. But you’re also then if you’re relying on your source code not being leaked, that’s probably quite a bad stance for a company to take because, there’s been a lot of instances where source code to private companies has been leaked. Yeah. And if if an attacker is determined enough, they’ll just reverse engineer your source code anyway.
Maciej Nowak [00:06:46]:
Mhmm. Alright. And, one of the most recent, I think, vulnerabilities that you have uncovered, let’s say, was in WPML, right? The the plugin, which is very popular in WordPress ecosystem. There was a lot of, let’s say, press coverage about that. And can you tell us a little bit more how did you come across this particular vulnerability?
Mat Rollings [00:07:12]:
Yeah. So this one, I wasn’t specifically looking for this type of vulnerability that I, found. So this was one of the the the plugin was one of the more popular, plugins that isn’t distributed via, WordPress.org. So this is something that interested me because I just started having a look at those more popular plugins where there may not be as many eyes on the source code. Because for WordPress, like, even if you don’t distribute via the, the public WordPress.org repo, your source code is still open source, because you can just read the PHP code once you’ve been given the zip to download. So I was just having a look through there. I’d I’d recently learnt what short codes were in WordPress which for any WordPress, experts is probably very obvious, but to me, it was something that was quite new. So I was looking for the more typical things you see with short codes.
Mat Rollings [00:08:10]:
So quite commonly, you see a lot of cross site scripting where developers aren’t protecting, for the against injection of JavaScript and HTML. And the other one I was looking for is local file inclusion. So if there’s any attributes in that short code that I put into a path, we’ve include or require or get template. Those can include other PHP files and you can exploit that as an attacker. But this one was a bit more interesting. So I’d gone looking for these cross site scripting and these local file inclusion attacks. And I’d found that this short code was actually rendering a template. And one of my favorite vulnerabilities is called, SSTI, which is server side template injection.
Mat Rollings [00:08:58]:
And this is where you can define a template yourself that, calls some of the commands that that templating engine defines, and you can use these commands to get arbitrary code execution so you’d be able to take full control of the server. So it was quite a complicated vulnerability in the end. Like, the payload was at least complicated because there were certain characters I couldn’t use. So I had to find a way to generate these characters in the payload itself and then use them in the final part of the payload to get code execution.
Maciej Nowak [00:09:30]:
I remember reading your, let’s say, case study or, you know, way to reproduce this, and I remember how you reproduce the the characters to enter the, let’s say, commands. But I’m super curious. How exactly were you looking at it? Like, what led you to focusing on that area? I understand you were, maybe trying to learn a new thing, for WordPress, but I am always amazed on how do you systematically, or systemically, look for vulnerabilities, you know, in general and in this particular plug in too?
Mat Rollings [00:10:10]:
Yeah. So for this plugin, this was one of the things I call, like, a drive by vulnerability. So I’m looking for something specific, but I don’t find that. But I find something that looks interesting, so then I take a bit more of a deeper dive and see what I’m able to do. So that that was for this case. More generally, what I do is because, most of these plugins are open source and freely available to download, there are these tools called, Slurpers, which will download all of the plugins and themes from the wordpress.org repo. And then you can do code analysis on your computer and you can start looking for start looking for code that you think might be vulnerable. So what I like to do is because I’ve come from a developer background.
Mat Rollings [00:11:02]:
I like to think about, like, if I was a developer, how could I write something that may accidentally introduce a vulnerability? So PHP is very flexible and so is WordPress as an extension of that. In the a lot of functions, like, they’ll accept in a parameter that you might think, well, this accepts a file path, but it also you can give it a URL or you can give it a PHP filter and you might be able to do things that a developer using that function wouldn’t have expected you to be able to do.
Maciej Nowak [00:11:35]:
To translate this to little like, rephrase this. You download automatically all of the plugins. Like like, they repository of what’s out there and, you know, automatic way, you search through potential patterns that you think are most of the time handled wrong way, like, without sanitization or like like, for example, the path. You you look for the path keyword and look where is it used and what’s what’s the input and how is it, provided from the user inputs, for example, or from other parts of the code. Right?
Mat Rollings [00:12:17]:
Yeah. So, most of the vulnerabilities I found is through writing regular expressions to find these snippets of vulnerable code. I’ll create like a target list of like maybe a 100 repositories that have this code in and I’ll just walk through all of the different codes and just rule out any that look like they’re not vulnerable. Put maybes on the ones that look like they might be vulnerable and yes is the ones where I think they’re probably vulnerable. And then I can go through and install those, into a Docker instance I’ve got with, WordPress installed. Then I can start seeing if I can hit that execution path. So set up tools like Xdebug so I can do, debugging and pause execution where I want to. And, like, that’s a super powerful thing to be able to do, because it’s really easy to then find where you’re going in the code and to get to where you need to get to try and get that exploit working.
Maciej Nowak [00:13:16]:
Alright. That’s that’s super interesting. It’s like, doing this in a mass way. It’s not like you, focus on one plug in and read the whole code, trying to figure out what does it or doing it, like, compiling it in your head rather than looking at, at a scale. Right?
Mat Rollings [00:13:35]:
Yeah. So I think a lot of people when they start, looking at, like, WordPress bug bounty, they will download 1 plugin hoping to find a vulnerability in it. And like that that does work but you have to spend a lot of time on a specific plugin to be able to get anything and you may not be rewarded for that and you may have to just move on to another plugin. So it’s quite a slow way of doing it. And because there’s a in WordPress plugins and themes, there’s a lot of copying pasting from other WordPress plugins and themes. So if you find, like, one vulnerability, it’s likely to be present in quite a few other plugins, maybe written slightly differently but a lot of the times copy and paste it in. So it’s quite a good way of like having a little bounty multiplier for you. So if you make like, $200 off one, you might find it 3 or 4 more times and make even more money.
Maciej Nowak [00:14:30]:
Mhmm. But $200 doesn’t sound like a big reward or anything that would make you spend time doing that, and I guess it comes with the scale, like, reusing the vulnerability. Like, if you have the same pattern found on a couple of of plugins because I guess this source can be coming also from places like Stack Overflow, you know, bugs being reintroduced and stuff like this.
Mat Rollings [00:14:57]:
Yeah. So, like, a $100 or so per bug doesn’t sound like a lot, but if it takes you, like, a few minutes, that’s actually a really good return on investment. So I’ve had some bugs where I found one instance of it, and then I found it in about 50 more plugins. So each bug on its own, like, may only be worth, like, less than $100, but then it all adds up once you start building on that.
Maciej Nowak [00:15:22]:
And this is the same bug?
Mat Rollings [00:15:25]:
Yeah. Exactly the same bug, just different plugins. Yep.
Maciej Nowak [00:15:30]:
But what if… I want to really try, I really want to understand that. So is this the same bug in a sense that this code looks exactly the same, or is it this the same type of bug? Like, not sanitized path or, you know, I don’t know, input, something like this. Or is it, like, literally the like, a code taken from Stack Overflow and reused across many, many plugins?
Mat Rollings [00:15:53]:
Yeah. So this one in particular, I found, cross site scripting and themes, and it was almost the exact same code used maybe 50 times, in any plug in with more than 1,000 installs. But when I create the regexes, I think it’s it’s very useful to create quite a loose regex so that you can match as many, of the same kind of, vulnerability even if they’ve just written it slightly different. Like, you might have more spaces, different brackets. There’s there’s lots of different ways in PHP of writing the same thing. Like if you’ve got string concatenation, you can use the dot method or you can, put PHP tags and echo it in there. So there’s like 3 or 4 different ways of probably, writing the same, cross site scripting vulnerability that I found.
Maciej Nowak [00:16:49]:
Forgive me for generalization, but if this boils down to writing project access for very common vulnerabilities, why people aren’t using, for example, the same method for writing the code? Like, you know, writing the code in a safety like, with safety in mind? Because, for example, in crypto, there are, code audits. It’s very popular where you have a big project. You do the audit. You hire external developers to do the audit, and there is also, there are also tools to do the analysis of the code. And I haven’t heard about anything like this in PHP world.
Mat Rollings [00:17:34]:
So there are definitely code scanners in the PHP world, and I know, some plugins are definitely using them because you can see the comments where they’re telling the the scanner to ignore certain things that they know are safe or, in many cases, they think are safe but might necessarily not be. Because sometimes scanning for these ignore this line can be quite a good way to find vulnerabilities where developers are telling the scanner to show up effectively.
Maciej Nowak [00:18:02]:
Yeah. They think they are wiser.
Mat Rollings [00:18:04]:
Yeah. But in many cases, I think most people just aren’t using the code scanners. And and that’s probably another double edged sword of the bean. There’s there’s not really any barrier to entry for a WordPress plugin. So, like, anyone can go and upload one, which is which is great for the for the ecosystem. You get a good amount of diversity, good amount of plugins doing anything, but it does mean that, a lot of the source code that’s on the WordPress.org repo probably hasn’t gone under much code review. I think they do an initial scan when you first upload a plug in, but I don’t think there’s anything after that for any updates that come to the plug in.
Maciej Nowak [00:18:43]:
Mhmm. And how about, updates to the to the plugins? You download this every, I don’t know, 2 or 3 days, 7 days maybe, and look for plugins that had added new codes so that you can find something new within that revision only?
Mat Rollings [00:19:01]:
Yeah. Exactly. So you’ll you’ll set up your Slurp or your downloader of plugins to continually run. And then you might set up certain alerts. So you might be interested in plugins of over 50,000 installs. If they match any of these regexes, you can, give yourself an alert so you can go and investigate them in a bit more detail. One of the other ways of scanning rather than just using regex is to use a tool called Semgrep, which is, really good at doing, taint analysis, which is following the user input. So from a source to a vulnerable function or potentially vulnerable function called the sync.
Mat Rollings [00:19:43]:
So if you’re able to write, these really specific rules in Semgrep or other kind of tools that do them, I think there’s another PHP one called, Psalm. But if you can write these really specific rules, you can, get a really good, you can reduce the amount of false positives so you’re only getting alerts on stuff that is really important to look at. So that’s a good way of doing it as well.
Maciej Nowak [00:20:11]:
And what are your most, impactful vulnerabilities found?
Mat Rollings [00:20:17]:
Yeah. So the most impactful ones are probably arbitrary file upload. So if you if you don’t, check the file extensions properly, there’s quite a few ways to mess that up. But if you if you’re if you’re a developer, like, try and use the functions that WordPress has given you to, handle file uploads. If you’re trying to use the PHP ones, they are generally, less secure, which allows you to put the users to upload any file types. They can just upload a PHP file, which can then be executed. So they’ve got remote code execution. The other one we see a lot of is privilege escalation.
Mat Rollings [00:20:57]:
So if I as a subscriber or an unauthentic user, if I can somehow manage to become an admin user, through this tends to be through more of like a logic flaw vulnerability where they’ve written something that maybe allow someone to, call an endpoint that accepts a role. And then you might be able to arbitrary arbitrarily set that role and just say: hey, I wanna register, but I’m an admin and it’ll let you register as an admin. And then if you get admin access, you can write a PHP file and you can get arbitrary code execution. Those are probably the the 2 big ones we say.
Maciej Nowak [00:21:35]:
Mhmm. Alright. And, in terms of impact on the WordPress world, and I think apart from WPML that you’re most, like, proud of. And maybe building on top of that, I’m curious where does the most, like, you know what are you most proud of in terms of the work you are doing? Is it like the most, like the biggest or most covered plug in or other most difficult, vulnerability fonts? Like, what drives you?
Mat Rollings [00:22:10]:
Yeah. So I just find it really fun, like, finding these vulnerabilities. I’ve only had a few of the bigger ones like WPML was probably the the biggest one that got picked up. I found some smaller ones in Elementor. But this year, I’ve so far, I’ve found about 500 vulnerabilities. So it’s kinda… It’s getting difficult to keep track of them all. But, yeah, I just really enjoy looking for them and and reporting them.
Mat Rollings [00:22:39]:
I’ve also, I’m I’m big into the, open source world. So I’ve open sourced some of my vulnerability reports there in GitHub. And also trying to give back to the WordPress bug bounty community. I’ve recently just launched a plugin, to try and help bug bounty hunters find and develop exploits in WordPress plugins and themes. So that is also on the same git repo as the, reports that are open sourced.
Maciej Nowak [00:23:12]:
Wow. How does it work? Like, what value does it bring to the developers?
Mat Rollings [00:23:19]:
The the plugin?
Marcin Novak [00:23:20]:
Yeah. The plugin. Yeah. The work you did.
Mat Rollings [00:23:24]:
Yeah. So this is it’s this like, you can get a lot of, you can get a lot of, results and vulnerabilities found from just doing, like, the the code analysis. So as I said, using the regex or semgrep to find stuff. But there’s also a lot of plugins where that won’t give you any results because they might be written in a more dynamic way. So your kind of static code tools won’t pick stuff up. Like, it might be registering REST routes or Ajax endpoints dynamically. So creating those once the plug in’s been initialized and you might not be able to pick that up statically. So this tool is kind of designed to help, bug bounty hunters, developers, kind of do the introspection dynamically on the plugin once it’s loaded.
Mat Rollings [00:24:16]:
So you can you can look at all the short codes it’s defined. You can click on each short code, find the function that it’s calling, the same with Ajax endpoints and REST endpoints, and you can just start inspecting those and looking at the code, and it highlights, where the user input is and where any of the sync functions that you’d be trying to exploit go to. So it’s got this and just a few of the little things that kinda aim to speed up development of the exploits.
Maciej Nowak [00:24:45]:
I’m curious how how did it start for you? So is it something you are focusing 100% now, Or is it, like, you know, side project and something else, keeps you busy? How does it work for you?
Mat Rollings [00:25:00]:
Yeah. So the plugin I developed, I kinda started working on it because I think I kind like, I’ve been a developer for, like, 15 years or so. And since I’ve switched to Bug Bounty, I’ve kinda missed that development side of it. So that was my reason for coming back into, like, doing some actual development work. In terms of, like, getting into bug bounty in general, I started, proper full time bug bounty hunting in January, because I’d wanted I’ve been in security for quite a while, but I hadn’t managed to break into the Bug Bounty side of things. But one of my friends, sent me, some information saying that there were companies that now pay for WordPress vulnerabilities, and I thought that’d be a good way to start getting into it. So I started having a go. The the first vulnerability I found was really really complicated.
Mat Rollings [00:25:54]:
Had to jump through so many hoops and I thought if if they’re all like this, I’m never gonna never gonna make it. But, after after the first few vulnerabilities, it just started. You let you learn more about WordPress, you understand how it works, and the mistakes developers can make, and so it just kind of snowballed. And, yeah, now I’m up to about 500 vulnerabilities. So that’s how it goes.
Maciej Nowak [00:26:16]:
So you’re focusing on bug bounties, since January. Like, it’s it’s like it’s your full time job now. Right?
Mat Rollings [00:26:23]:
Yeah. So I probably don’t work as hard as if I had natural full time job, but, yeah, that’s what I’m doing to make money now.
Maciej Nowak [00:26:33]:
Alright. And what what have
Maciej Nowak [00:26:35]:
you been up to before that? You mentioned that you can’t break into the bug bounty world, and, was it WordPress also previously or another development space, let’s say?
Mat Rollings [00:26:47]:
Yeah. I’d I’ve not really I’ve not really been in the WordPress space. I did have a WordPress blog back when I was a teenager, which did get hacked, as I think most people’s, teenage blogs probably did at the time. So I was aware of WordPress, but I’d never done too much of the messing with, like, a little bit PHP themes and stuff. But I kind of fell into being, an Android developer, shortly after university, and that went really well. I’ve had I’ve always had security…
Maciej Nowak [00:27:20]:
Same here. We we also started, like, I also started writing kind of Androids and iOS applications out of uni.
Mat Rollings [00:27:26]:
Oh, awesome. Yeah. It was really catching. Like, I think, like, the first few Android phones had come out, and I was like, oh, it’s Linux on a phone. I’m gonna love this. So I just started writing some apps, and they got a bit popular. And I’ve always had security in my mind, so I, I’ve got a semi popular port scanning tool foundry called PortDroid which is kind of taken off and made a little bit of money. So I’ve always been interested in the security side of stuff but I didn’t realize you could properly get paid for working in security until like 5 or 6 years ago where I did a a part time cybersecurity degree.
Mat Rollings [00:28:04]:
So I didn’t learn too much during the degree, but, like, outside of that with the people I’d, made friends with at university, we did a lot of CTFs and that kind of stuff, which is like hacking competition surprises, and end up learning, an awful lot. And, I got employed by a cybersecurity training company called Immersive Labs. And, after a few promotions there, I was end up leading the application security team, which I really enjoyed. But then I took a a job in, Fintech for a bit, which didn’t last very long in. It wasn’t really the world for me, and I kinda took a step back and decided that I wanted to focus on stuff I enjoy, which was like, finding bugs and teaching.
Maciej Nowak [00:28:52]:
Alright. And I’m curious – Isn’t that part, where you lead the team for the security for the application security is tempting you, or is it like now you have so much freedom that you value this more than, you know, I don’t know, working at a company with people where I’m not saying you can’t do this, you know, on your own, but I’m just curious. From the personal standpoint, how do you compare that to working at at the, you know, any kind of organization you were working with?
Mat Rollings [00:29:29]:
Yeah. I think I I did really enjoy my time, working with companies. But I think the the thing everyone enjoys the most probably about working at a company is the people there because you you have a lot of good people that you work with, or at least I did, with all the jobs I’ve had. But I I think you can like, the thing as I got higher up, in promotions, the thing that I enjoyed the most was mentoring people, which is something you don’t need a job to do. Like, if if you’ve got that income from somewhere else, there are still people within your community that you can help mentor, help guide. So that’s probably one of the justifications for open sourcing my, vulnerability reports and the plugin that I’ve written. So try and give back to the community. There’s a few people I’ve, helped mentor to get their first kind of bug bounty, reports on Patch Stack.
Mat Rollings [00:30:27]:
So there’s a few people to help there, and that’s really rewarding.
Maciej Nowak [00:30:30]:
Mhmm. I really like it. And I think we are at the moment in the conversation where I can repackage what you have, told us and, attack this from the different perspective. So we talked about you’re looking for typical ways of inputting flaws in the in, like, introducing flaws in the code. And the code is written by the developers. And I’m curious how your work and the methods you are using can affect or influence or change the minds or, you know, make an impact or on developers, you know, freelancers, but also developers at the agencies, which are numerous, right? So I’m curious how your work impacts regular developer Joe, let’s say.
Mat Rollings [00:31:22]:
Yeah. So I think I think it’s quite easy as a developer, especially, like, if you if you’re more junior, you might you might receive a vulnerability report and feel like you might take that quite personally. But the reason it’s been reported as a vulnerability comes from a good place from the security researchers that they’re not trying to say anything negative about you because everyone makes mistakes. I’ve written vulnerable code. I’ve been developed for so many years. Like, I’m sure a lot of my code is vulnerable. So if they went and looked at my code, they’d be I’d probably be able to point out vulnerabilities in mine. So, yeah, that that’s always the first thing I try and cover when talking, like, to developers or about developers is that the security reaches researchers are trying to help.
Mat Rollings [00:32:04]:
So definitely don’t take anything personally. And a lot of the vulnerabilities probably come from not considering what can be input to functions or what can come from user input. Like, pretty much all vulnerabilities are caused by, missing sanitization or validation on user input. So, there’s a lot of stuff that as a developer, you might not even consider it to be user input. You might have grabbed something from the database expecting it to be already sanitized, but the if that’s inserted into the the database without any sanitization, that value could be controlled by an attacker. And there’s lots of, like, weird and interesting things that an attacker will be able to control that you might not have considered it. But you like as a developer, you can put validation on all of your inputs. It’s it’s not difficult or too taxing.
Mat Rollings [00:33:04]:
So that that’s the number one way to stop pretty much all vulnerabilities.
Maciej Nowak [00:33:10]:
But I have to ask because when I was developing the code, it was like, okay we have like… Look, I have a background in so when I was learning to code, we started with C. And C doesn’t let you make any mistakes, right? If you do, the application just, dies. Right? I had to pay a lot of attention all the time to proper memo memory management and inpu ts and so on because app would die. With then, you know, Java, not so much, many times not but not so much. And with PHP, it’s even less.
Maciej Nowak [00:33:48]:
Right?So if you start developing with PHP, you are approaching this very relaxed way compared to C. And my my feeling is that sanitization or types checks and so on, it’s like the last thing people want to do because this doesn’t provide any value. Your app won’t be more functional. Your app won’t have more features. It won’t be faster. It will have 10 times more lines of code, because all of the checks, which is, like, a pain. Right? And, like, this is the natural, approach people are coming from.
Maciej Nowak [00:34:32]:
Right? So this doesn’t help the app be better. It’s just for it to even not crash less. Right? It’s just, you know, proper sanitization. This is so boring. So, like, how do how can you find that natural inborn urge to cut corners?
Mat Rollings [00:34:50]:
Yeah. I mean, some some of that is very difficult to try and fix. I mean, if you’re coming from an individual developer point of view, that can probably be very hard to change. If you’re coming from more of a business point of view, then you’ve got to evaluate, like, how much value, like, the data, that you’re storing has because if you have a vulnerability then attacker can exploit. If that ends up getting publicity, that might affect the the reputation of your company, which might end up resulting in like a drop of sales, which can be the same for individual individual developers as well. And it can also result if you if you have a vulnerability in your plugin and you don’t respond to the security researchers or the bug bounty programs that might have reported it to you. Your plugin can get taken off the wordpress.org repo which can result in less downloads, and so that can really impact you. So I mean, it’s difficult as a developer.
Mat Rollings [00:35:56]:
Like, if you’re not dedicating time to understanding all your inputs, knowing what you need to sanitize, it it can be difficult to change that state of mind. What I will say is some of the sanitizations and protections actually come for free in WordPress. Like, if you use some of the functions they’ve already written, there’s a lot of stuff that will already be escaped. You’ll be protected by if you use, WordPress’s functions for handling file uploads. Those are protected. You won’t be able to upload PHP files and those will actually save you a lot of time because they take all of the things you’d need to do in PHP manually and just put it in one line of code. So I think just education is probably the key part that can help the developers here.
Maciej Nowak [00:36:43]:
What resonated with me is that “don’t take it personal”. How do you know it’s you? Right? And then I had that flash, like, flash light bulb moment that if you have proper setup, you are using git. And if your vulnerability is ties to a prop given line of code, you can see who has written that line of code. And I had, like I’m amazed how this is helpful to have proper source code repository well maintained and managed and, all of the proper, source code management. How how helpful can that can that be actually?
Mat Rollings [00:37:24]:
Yeah. Exactly. So I’d I’d very much always try and frame it as, like, how can this be a learning opportunity to developer and the development team as a whole rather than, like, this developer made a mistake. They need to learn not to do it again or we’re gonna fire them. Because it’s much better as learning an opportunity because if you can tell the developer, yes, this code you’ve had was vulnerable. This is how you fix it. This is how you could capture it in automation so it doesn’t happen again. You’re pretty much guaranteeing that they’re very unlikely to make that same mistake again.
Mat Rollings [00:37:58]:
So you’ve probably made them a much better developer by pointing them out to them.
Maciej Nowak [00:38:02]:
Mhmm. And, you mentioned to use, what’s already been, properly prepared for, for example, handling files. What else, developers can do to avoid, to avoid mistakes? Let’s imagine you’re a security consultant. You’re hired by big organization. How would you enforce security for their IT processes? Let’s say they have a, you know, ecommerce platform they own, and they want to have everything secured. So how would you enforce security in such an organization?
Marcin Novak [00:38:40]:
Yeah. So, I mean, it’s quite difficult coming in, like, and just starting from 0 and trying to get a company up to a good state of, security posture. I think I usually like to start with, like, developer education, making sure developers know what to do if they do find a security vulnerability. There’s also very, easy ways to integrate, static code analysis like SAST scanners into the CI/CD, pipelines. So GitHub actions are great one for these. You can just run some free tools and go actions, get a vulnerability report and you can just start going through those triaging the easier ones. So it can be difficult with a lot of false positives, but, it’s definitely a great way to start and at least capture all the low hanging fruit.
Maciej Nowak [00:39:34]:
Alright. And, how about certifications for organizations like SOC 2 or, ESO? Anything like this. Like, how useful is that? Is it just for the sake of having a seal of approval, or is it changing anything within the organization?
Mat Rollings [00:39:55]:
Yeah. So, I mean, it’s it’s definitely gonna be a good thing. At least the company is getting ready to be certified. I think the one here that a lot of companies get is Cyber Essentials, which is one of the more basic ones that just shows they’re protecting against the certain level of basic vulnerabilities. So I think the certification in itself probably wouldn’t be too worth too much but it’s the companies getting themselves ready for that certification where the value really comes from, because it’s showing that they’re at least understanding what security they need to be implementing.
Maciej Nowak [00:40:28]:
Mhmm. Alright. And let’s assume you are hardly a ring, web development agency. Like, let’s assume our our episode is listened to by CMO who has to hire a new agency for website revamp or ecommerce rebuild. How should such a person vet a new agency with security in mind?
Mat Rollings [00:40:56]:
Yeah. That’s a good question. Yeah. I think if you can if you can find a way to make sure that security is something they actually care about or something they actually understand, that could be a real differentiator between them and another company that just wants to pump out the code and move on. So I don’t really have too many tips on how you could do that because it’s not something I’ve I’ve really done, but it’s something that would definitely add value if you’re looking for an agency.
Maciej Nowak [00:41:25]:
What should be the thought process to some extent, you know, to even start thinking on the client side about the security? What should maybe the people the the client ask the agency? Or how to even approach this process? Maybe, you know, particular questions aren’t great way to start, but something else is, you know, how to even start unpacking this problem.
Mat Rollings [00:41:51]:
Yeah. I think maybe just asking them, like, say give them, like, a hypothetical, like, you’ve recently found you’ve recently been informed that you’ve got a security vulnerability in one of the plugins you’ve written for us. Like, how do you deal with that? And then kind of understanding their thought process, like, are they engaging with their security research? Are they passing it through the proper channels? Are we getting alerted to this? Do we need to go and, inform our customers of any potential breaches? That kind of stuff. It would it would definitely be interesting to see what they think and whether that aligns with what you want as a company that would be hiring them.
Maciej Nowak [00:42:29]:
Mhmm. Mhmm. But this
Maciej Nowak [00:42:31]:
pose, maybe a question or a challenge what the company should be thinking about. Like, right, it’s a chicken and egg or kind of egg problem. Right? So to understand their thought process, I have to be able to create their thought process. I have to understand if what they are saying is aligned with what I want, but I don’t know what I want because, otherwise, maybe I will do something different. So what should, like, building on top of it, what should company want in a situation like this? Or how would the company on the client side, how that company should think about their own infrastructure, you know, their own security approach, let’s say.
Mat Rollings [00:43:19]:
Mhmm. Well, if I was the company that was, hiring this other company, I would want them to have transparency in their communication with me. So I I would wanna be informed of the security vulnerability as well as whatever they were doing to fix it. So I think the key the key thing for me is communication because you can you can fix all, like, if you’ve got a difference of opinions like what you would want them to do with them, what they’re planning to do, that communication is gonna be the key there because you can just ask them to do it differently because they’re working for you. So they should be able to so they should be receptive to that. So an open communication is probably the best thing.
Maciej Nowak [00:43:56]:
But but I’m thinking about the open communication and isn’t it, like, the lowest, like, the bare minimum you would be expecting from any kind of partner regardless if this is development partner? Like, any kind of a partner you work with should have that, communication top notch in my at least, like, in my opinion. Right? So, like, I’m even thinking beyond that because bad commune or, like, semi communications sound very often a no go. Right? A deal breaker. Because you can’t work effectively with a partner that has poor communication or, like, even in some cases, like, so so. I’m not even saying about, like, bad, but even so so communication is also is oftentimes a problem. And then the problem happens with the security, and then what? Right? So, I don’t know. I I’m thinking about this is the the requirement even to go any farther would the work? And what about, I don’t know, maybe best practices, like preventing, the the the bugs to happen? Like, look, I’m I’m fishing for ideas.
Maciej Nowak [00:45:13]:
Right? So don’t don’t don’t get me wrong, but, like, I want to understand.
Mat Rollings [00:45:20]:
Yeah. So, I mean, you could look for things like, are they using static code scanners? Are they using continuous deployment and continuous integration? Those kind of things. You could look to see if they have any of the certifications we’ve mentioned. Those kind of things just to show that they understand or at least trying to understand, a correct security posture.
Maciej Nowak [00:45:41]:
I’m thinking also about one more topic. Maybe a little bit adjacent to the security, but still a little bit related. So recently, there is that conflict between WordPress, founder, and WPEngine. I don’t want to dig into the conflict, but rather I’m thinking about, let’s say, second order consequences. So let’s assume there is a fork of WordPress. And I’m curious what’s your opinion on it? Like, if this happens and the the fork gets popular, how, in your opinion, would that influence the ecosystem? But maybe how this would, impact security of the websites, do you have any thoughts on it? Any comments?
Mat Rollings [00:46:36]:
So I I think it it it’s just it is gonna complicate things because it means there’s gonna be, probably 2 repositories or I mean, we’re already seeing, different repositories starting to be set up with all the the drama. But it means that as a security researcher or as the, companies that handle the bug bounties for the security researchers, triaging those reports is gonna become more difficult because they’re gonna have to find different points of contact, and even multiple points of contact if there’s a plug in in both repositories, like would you contact the wordpress.org security team or would you contact the other team? It just it does make everything more complicated. So, yeah, I can just see things getting more complex from a security research point of view, from a bug bounty point of view. And it also means if there’s if WordPress gets forked and it gets a popular following in the fork, it means any vulnerabilities in WordPress are likely to be present in the fork so you’re gonna need to have another program to triage the the sec the fork as well. So yeah you just end up with there’s gonna be a lot more to do, if we start seeing a popular fork emerge.
Maciej Nowak [00:47:55]:
Mhmm. Yeah. This is something
Maciej Nowak [00:47:57]:
I was also thinking about from the perspective of keeping up to date the plugins that will be forked to or not forked? Or how do you comply with the, let’s say, cores are growing or being developed in their own direction? Because you you can’t have the same direction unless you will, like, copy on an ongoing basis the developments of the core WordPress, and then these new updates would be just copied to the new codebase but what’s the point of, forking the WordPress this way? Right? So I my guess is if this happens and the fork is fork so for our listeners fork is a copy of of the code. So if the if the fork is getting popular and maintained and developed actively, it will just diverge from, from the original, let’s say, WordPress. And then we will not have too much compatibility, and plugin makers will have to decide if they are maintaining 2 versions of their plugins, keeping like, doubling the work most of the time? Like, I’m very curious how it will, unfold.
Mat Rollings [00:49:10]:
Yeah. I think it’s difficult to know, like, especially at this stage, what is gonna happen. I I would assume that, backwards compatibility is going to be very important even if there’s a fork because like WordPress is very backwards compatible like almost to its disadvantage when it comes to security. So I and, like, the the key value of WordPress comes from the amount of plugins and themes that are available. So I think any fork would probably have to follow a similar, like, very backwards compatible nature with WordPress. I guess over time it is something that would diverge, but I think for a short term, for short to medium term, you’d definitely be looking at them both being very compatible with each of them.
Maciej Nowak [00:49:59]:
Do you think it can be a likely scenario that the fork will be not one, but many purpose, like, purpose driven or purpose focused forks, like, Commerce, WordPress, or, like, you know, instead of Woo, everything gets merged, and this is Commerce WordPress. Or there is, Publisher WordPress or there is Speed WordPress or, like, we’ve simplified, cut to, like, fitting the very purpose admin panel, uncluttered, let’s say, very lean, maybe with integrated plugins. I don’t know. I’m just, you know, inventing this as I speak. Anything like this could be possible?
Mat Rollings [00:50:46]:
I mean, it could definitely possible, from a security point of view. It could be beneficial to have more of a, like, a team on a narrower focus. So they’ve got less of that flexibility that can introduce more of the bugs. But, yeah, I don’t think it’s anything I could predict with any certainty at the moment.
Maciej Nowak [00:51:06]:
Sure. I’m thinking about wrapping the, the episode with any maybe horror stories you remember you would like to share something that was crazy.
Mat Rollings [00:51:17]:
I’ve probably got a few things here. So, Patch Stack this month removed the minimum for 1 k installs and plugins and themes. So you could report anything that was still active on the WordPress.org. So I’ve I’ve reported about a 120 vulnerabilities this month. So I’m quite tired now, but I found lots. And I was really focusing on the high impact vulnerabilities. So I found a lot of file uploads, privilege escalations. Those kind of things were the main things I was looking at.
Mat Rollings [00:51:53]:
So I’ve I’ve seen a few, like, really silly things this month. There was at least 3 plugins that did this, in slightly different ways, but every endpoint in WordPress, you could put at the end of the URL, you could put question mark ID equals 1, and you would become the admin user. So…
Maciej Nowak [00:52:19]:
Oh. Via a session cookie or how would it?
Mat Rollings [00:52:21]:
Yeah. Yeah. It would just update the session cookie to log you in as admin straight away. So you just go to any URL in WordPress, put question mark ID equals 1, bam, press enter your admin.
Maciej Nowak [00:52:32]:
That’s wonderful. How do you do this? Like, what what happened behind the scenes? What how this that ID number 1 parameter changed to for the admin? There was a user in the user list that with the ID of of of number 1, and by the mistake, you would get promoted to that user?
Mat Rollings [00:52:52]:
Yeah. So, like, in almost every WordPress setup, your administrator user will have ID 1. Like, very occasionally, you’d need to enumerate that but that’s something you could find out very easily and WordPress exposes a lot of user information like that, without authentication. So you can you can get a user ID, you can probably find out an admin user ID. And I it’s difficult to always know the developer’s justification in writing some code. I know in one of the plugins, it they defined a load of rest routes, which inherited from an abstract rest route class. And in the initialization for that rest route class, they had the ability to provide a parameter which would change the user ID. So I assume that this was something they might have put in for testing or if there was some sort of admin functionality where they need to hit rest routes different users.
Mat Rollings [00:53:44]:
So that one just made every rest route be able to instantly admin, log in as admin and it would return the cookie so then you could use that to log in to the normal admin panel. Yeah. So some others that were in, so some plugins will give you like deliberately give you the ability as admin to log in as other users to see what the panel looks like and then give you the ability to switch back to admin. And it’s quite easy to mess that up. If you’ve got a button you can click to go back to be an admin, you might not necessarily need to have been admin previously for you to be able to press that button and take over an admin account. So, yeah, there’s a lot of, kinda silly coding mistakes I found. And because that install count was much lower, you get to see a lot of the stuff that hasn’t really had many eyes looking over it. And when I went into it, I was thinking, these are all gonna be plugins that have become abandoned and no one’s looked at for, like, 10, 15 years.
Mat Rollings [00:54:48]:
And, like, some of them definitely were, but there was a surprising amount of them that have just been updated in the past few months, and they’ve got these massive critical vulnerabilities and allow anyone to suddenly become admin, with no authentication.
Maciej Nowak [00:55:01]:
Stealthcopter. Right? So that’s your nickname? You’re, known in the security space by this nickname. And I wanted to start the conversation with you telling us how, how you picked that nickname nickname, but I think we can wrap up the conversation with that.
Mat Rollings [00:55:19]:
Okay. Cool. Yeah. So this was a long time ago. So back when I was a teenager, everyone kind of had, nicknames for the computer games they’re playing. And so I ended up going with Stealthcopter because there was a there was a certain computer game I was playing at the time had an invisible tank called a Stealth Tank, and I was like, cool if you could just have a stealth helicopter. So stealth copter.
Maciej Nowak [00:55:43]:
I like the nickname, by the way. So I I think this is one of the cooler nicknames I came across. So and I mean it. So I really like it.
Mat Rollings [00:55:51]:
Yeah. It’s very difficult once you’ve got one to stop using it.
Maciej Nowak [00:55:55]:
Yeah. I guess. Yeah. So so much history associated with that. Right?
Mat Rollings [00:56:00]:
Yeah. Exactly.
Maciej Nowak [00:56:02]:
Perfect. Alright. Thank you so much. This was a very fun conversation. I enjoyed it very much, and I learned a couple of things too. So thank you very much. Oh, one more thing. I want to ask.
Maciej Nowak [00:56:14]:
I remember now. So you had to write you you mentioned that you reported around 100 vulnerabilities this month. Does this mean you had to also write 100 reports for every back home?
Mat Rollings [00:56:28]:
Yeah. So that can be quite a taxing thing, just writing the reports. But because so many of these reports are the same, I’ve I’ve started working on templates that I can just reuse between reports.
Maciej Nowak [00:56:42]:
And the AI help in, you know, for writing them them?
Mat Rollings [00:56:45]:
Yeah. AI AI can be very helpful. I wouldn’t, like, completely rely on it, but it is good at, like, if you wanna give it a set of bullet points for I’ve done this, this, and this. How would you best describe this like summarize this in the best way possible? And I’ve helped quite a lot of people who are kinda newer to the book banning world write their vulnerability reports in a way that can because you really want the summary to give a high level impact for anyone that’s reading it because that needs to be read by the triages so they can understand what the impact of your vulnerability is. But also by the companies that receive these vulnerability reports and need to action them. So it’s important to them so that they can understand, like, what does this actually mean for us as a company? Is it something we have to go and fix immediately? Can we take a few days? Can we take a few weeks? Do we need to go and contact our customers, get them to urgently install a security fix? So I find the language in that is very important to not write it as, like, a bug bounty hunter, but to be able to write it in a way that can communicate to those stakeholders in a company and something to the triage so they can understand.
Maciej Nowak [00:57:52]:
Blaming issues. Right?
Mat Rollings [00:57:53]:
Yeah. Yeah. Yeah. So I’m a big fan of, like, keeping everything as simple as possible.
Maciej Nowak [00:57:58]:
Alright. Okay. Now I’m out of questions. So thank you again very much. Good luck with your, with your hunting, and and take care.
Mat Rollings [00:58:08]:
Yeah. Thank you very much for having me.
Lector [00:58:10]:
If you like what you’ve just heard, don’t forget to subscribe for more episodes. On the other hand, if you’ve got a question we haven’t answered yet, feel free to reach out to us directly. Just go to osomstudio.com/contact. Thanks for listening. And see you in the next episode of the Osom to know podcast.
Join Osom to know newsletter!
Get your monthly dose of WordPress information.