Browser Exploitation Framework (BeEF) with Gavin Johnson-Lynn

Five, four, three, two, one.

Drop that.

Welcome to the Test Guild Security Podcast. We're all getting together to learn more about security testing with your host, Joe Calantonio.

Hey, it's Joe. And welcome to another episode of the Test Guild Security Testing Podcast. Today we'll be talking with Gavin Johnson Lynn all about browser exploitation framework beef and his pluralsight costs on beef and Gavin has over 20 years experience running software in regulated environments and for global organizations. The last five years of his development career were spent with the focus on security, becoming a security lead for a significant payment project at a Fortune 100 company. He has experience with languages all the way from COBOL to. Net, and his experience of software testing really reveals a passion for security, leading him to become a speaker and blogger on the subject as well. He's also part of a red team using his defensive knowledge to aid a offensive security work. Really great costs on pluralsight. So really excited to dive in. You don't want to miss this episode. Check it out. It's no secret that the number and complexity of applications are growing, but what is alarming is that 90% of security incidents result from exploits against defects in software. The need for better application security has never been higher and Micro Focus Fortify is here to help. Fortify is the recognized market leader in application security and it is the most comprehensive and scalable application security solution that works with your current development tools and processes. With Fortify, you can start security applications in a single day, including custom code, open source or commercial components and scale as your needs grow with an on premise, as a service or hybrid implementation. Check them out. Head on over to micro focus.com Apple Security.

Hey Gavin, welcome to the Guild.

Hi Joe, how's it going?

Awesome, awesome. It's great to have you on the show. So before we get into it at a high level, what is the Beef framework?

So the Beef framework is really a framework that lets you take advantage of cross site scripting issues in websites. It provides a lot of commands that help you demonstrate just how big a deal cross site scripting can be.

Okay, cool. So for the folks that don't know what is cross site scripting?

So cross site Scripting typically involves JavaScript in browsers. So a good example would be if you've got a form, if somebody could put some HTML and JavaScript in one of their forum posts, that could then be reflected back to anybody who read that forum post. So really that would mean that the JavaScript is running on people's browser browsers where you wouldn't want that JavaScript running and that JavaScript could take advantage of lots of different things within the browser. You can find out people's geolocation, you can change the screen to look how you want. You can put little alerts onto the screen to ask for usernames and passwords. Really, you've got a lot of control about what they're looking at in the browser.

In your experience, how common still is cross site scripting? Is it something that's preventable and people just overlook it, or is it just something that's just part of the nature of software development?

It is very preventable. There are lots of controls you can use, so there are some fairly simple headers that you can pass back from your server that tell a browser to not load JavaScript from certain places. You can also use output encoding. So if you HTML encode output from your server, it doesn't get interpreted as HTML instead, it looks like text instead. And also simple things like input validation is somebody applying input validation to the things people are sending to the server. Which is very important at picking up really basic things that can be present in cross site scripting. And it's also important to note big companies, even like Google are affected by cross site scripting. So there was one that Google fixed early in 2019. So it's not just small companies, it's not just people who haven't got very many resources. It can affect much bigger companies as well.

So how destructive is this particular vulnerability?

So it depends. It depends on lots of things. If you've told, if the server tells a website to work in certain ways, then our mitigations. So your server might be able to tell the website not to give out your cookies in certain circumstances. Or you might have these headers that prevent calls out to external servers. So it's very important to have controls in place. But a lot of the issues, there's almost a running battle between people who find issues and the people who make the browsers. So people will find issues, they'll get exploited. The browser makers will notice this is getting exploited. They might be able to put things in place in their browsers that stop those exploits happening. One of the worst things that happens is when people don't really update their browsers. This might be home users or quite often it's it's businesses where they have applications that are reliant on certain browsers. This in particular happened within Explorer where people would have legacy code bases and they required Internet Explorer to do certain things. So they'd have the Internet Explorer on their machines. Might be an old version, it might not have many security updates on it. So it would have a lot of ways in which people could take advantage of that browser.

That is a great point. I worked for older healthcare medical type company and they had an application that only ran in IE9 and hospitals really resist upgrading their browsers. And it's even to the point where those browsers weren't even supported by Microsoft anymore. So you actually see that also there's still people tied to older browsers.

It does happen a lot and it is a problem. Yeah, it is very important from a security perspective to keep things up to date. And this is one of the reasons why.

You know, I've heard of other tools like metasploit and like I said, I'm a beginner to security testing. So is Metasploit the same type of tool as Beef or like, when would someone use Beef over say, Metasploit or some other tool?

So Beef is very specifically targeted at websites, whereas metasploit can take advantage of lots of things. So typically metasploit will be, if you've got old versions of Telnet or WordPress or FTP, that sort of thing running in a server, there'll be lots of things to take advantage of. Vulnerabilities in those in metasploit. Metasploit. Quite often the intent of using metasploit is to not just exploit it, but to get what they call a shell on a machine. So if you can take advantage of a vulnerability in a certain way, you might be able to get a shell on a different machine. And that means you've got essentially command line access to that machine. Now you can get vaguely similar things to that in Beef. So there is a metasploit module that lets you take control of someone's browser, but that's only one of the very many commands that are available in Beef.

So if someone's starting a testing type of activity, when would someone use Beef? Is it when they're testing web applications? It probably would be a good tool to start with.

That's a good question. So I see a few good scenarios for using Beef. The first one is what they call penetration tests. So if somebody's doing a penetration test on a website, they're testing it to find as many vulnerabilities they can in it. Now, if you find cross site scripting in a website, quite often when you've had a penetration test, you will get a report comes back that details all the vulnerabilities that have been found. And if Cross Site scripting is in there. It'll be demonstrated by a very simple sort of dialog box popping up, saying, kind of XSS or something really simple like that. And that kind of doesn't give you the information you might need to realize how important cross site scripting is. If you're not very technical, if you haven't done much around security, you might see that dialog box and think, what's the big deal? How dangerous is this? So it's very useful to use something like Beef to display just how big a deal this can be.

So that's the first big scenario for it. The next scenario is more red team engagements. When I say red team engagement, it can be security tests with specific objectives in mind. So you might.

The goal you have might be to go into a business, take advantage of vulnerabilities in their systems, get people's usernames and passwords, perhaps some sort of admin access to their systems. So a tool like Beef could be very useful in that sort of scenario. So if you've found a vulnerability in one of the websites, you might be able to get cross site scripting injected into that. You'll use Beef to talk to it. So then people inside the business who are using that website, they won't know Beef stay. They might be able to have things like dialog boxes coming up, asking for their usernames and passwords. And if it's been designed right, it'll be very solid and they won't notice it. In that case, they enter the username and password. That username and password will be sent back to the Beef server that you're running and you'll have a username and password. So that will really help things like a red team engagement work quite well.

The last scenario is, I think it's very useful just as a demonstration tool. So again, going back to people maybe not understanding security, or maybe they do understand security, but if you take for example development teams and product managers, they want to get features out of the customers, right? They just want to get lots of features to their customers. They may be not as focused on security as they could be. And that might be because they don't understand the importance, lots of other reasons, and it's very useful to use Beef as a demonstration tool. So if you find a cross site scripting vulnerability, you can use Beef to start controlling somebody's browser. You can give them a good idea of what sort of things cross site scripting can do and just how dangerous it can be.

I would think that's a Pretty effective demonstration to actually show it, hook it into a browser and manipulating it for sure. How hard is it to fix a cross site scripting? Did developers resist? Is it a big change for them? I guess if you do find an exploit for them to actually resolve it.

So quite often the fix will be something very simple like putting a content security policy in place, which is going back to the headers that the browser receives from the server. So you can have content security policy in place that says if I'm going to allow JavaScript, I only allow it to come from certain places. And so you'd have essentially an allow list in place that says I only allow JavaScript to come from my server or maybe from one or two very specific places. And then if somebody's injected cross site scripting, it's going to try and get the JavaScript from your beef server. That Beef server isn't going to be one of those allowed places and it's not going to be able to run. So something like content security policies make it relatively easy to to block script once it's already in place, but really you want to block it before it even gets into your website. And that's where things like input validation come in, or you check in to make sure somebody hasn't got something that looks like JavaScript or HTML in the things that they send in your server.

So that's a great point. There's this push to shift left most activities within the software development lifecycle, security being one of them. Is there a way to incorporate Beef into a CI CD pipeline to automatically say when someone checks in code, just double check to see if there's any common vulnerabilities? Or is it more of a manual activity where someone needs to actually plan an attack ahead of time?

I'd say it's more likely to be manual. You could theoretically put some cross site scripting JavaScript in your database and then look at the interface and see if it runs. Or look at your Beef server and see if you've got a connection from the interface. So there could be a little bit of automation in there, but.

It'S more useful from a manual perspective, I think. Yeah.

So in your course, this is what I love about having a podcast is I'm learning as well. And in your course on pluralsight on Beef, you talk about different test stages that I just never thought about the three stages. I think it was recon, vulnerability and exploitation, I guess. Can you talk about each part of those stages, what that incorporates so people maybe get a flavor of what they may want to implement when they're doing some activities like this.

So in terms of reconnaissance, that's obviously gathering information on a subject, in terms of something like a pen test, you might do reconnaissance on a website to see what sort of server headers it passes back to you, that sort of thing. When we're doing a pen test, you tend to structure it in gathering information and then using any information and then taking advantage of that use. So there are kind of clear steps you go through to understand vulnerabilities, understand where they might be from, and then start trying to take advantage of them.

And you also talked about the different type of attacks. So this can help you. I guess you said stored reflective and DOM based. For folks that don't know, can we talk a little bit? What is stored, what is reflected and.

What is DOM based so stored? Cross site scripting goes back to the example about having a form and a forum post. So if somebody's creating a forum post on your website, they putting some JavaScript in that, it's getting saved on your server. That is what we refer to as stored. So it's getting saved in your data store somewhere. So then when somebody else comes along and looks at that post, it gets retrieved from the storage by the server, sent back to the client in the browser and runs in the browser. So that that's stored now reflected. That is if somebody makes a request to the server and the server sends JavaScript back as a reflection of that request. So a good example of this is a search box on a website. So if somebody can type something in a search box on a website that's got JavaScript in it, that'll go to the server. If the server is vulnerable to this cross site scripting attack, the server will send the response page back, the response page will have the JavaScript in it and the page will run that JavaScript. So that's how it's reflected back from the server. The final1 is DOM based. So DOM based is very specifically not involving the server. So DOM based, I don't know if you understand what we mean by dom, but DOM is essentially the HTML page that we've got, the entirety of the HTML. So that is when an attack is DOM based, it is something purely on the client side that's running that runs some JavaScript from somewhere and you've got a cross site scripting vulnerability. Again that might be something like the URL. If somebody's managed to type something in the URL. If the client side JavaScript looks at that URL, pulls pieces out of it and puts them on the page. Perhaps then it might run some JavaScript.

How does it work? Under the hood? You talk about hooking a browser. So you inject JavaScript onto a client and then that opens up a communication port.

With Beef. And once you have that, you can then inject more activity or spy on activities that they're doing.

That's right. It's really interesting how this works. So once you've got your JavaScript running on somebody's page, the. The first thing that the Beef script does is gather lots of information about what it can see from that page. So it'll gather information on what sort of browser you're running. It'll understand.

What sort of operating system you've got. It can see what sort of CPU you're running. It'll tell you sort of width and height of your browser window. There are all sorts of details. It gathers straight away and passes those back to the Beef server.

So as soon as it passes those back to the Beef server, you, as the person running the Beef server, can see these. So there's a nice user interface that you can see all this in.

And after it's passed that back on the first time.

The client side then regularly polls the server. So every so many number of seconds, it'll send a message to the server. And it's really just saying that this connection, slowburn, the user hasn't closed the page yet, so we're still able to send the commands. So what happens then? Is it sending all these requests? And these are just simple web requests. There's nothing clever about them. They're just a web request to our Beef server. Our Beef server sends a response back. So when we want to run a command, we'll go into the Beef user interface. We have a huge selection of commands. There are something like 300 commands you can choose from.

And you can choose a command, you click Execute. And the next time the client sends a message to your server, Beef will respond with some JavaScript that will let it execute whatever command you've chosen.

So really, this is all just kind of standard web requests going back and forward. So it makes a web request, it gets a response containing JavaScript, because it's the beef JavaScript that's running that. It takes the new JavaScript from the server, runs that JavaScript. There'll be commands in there that tell it to respond to Beef. So whatever it gets out of that executed command, it'll respond to the server. So there's a very interesting communication method going on here. It's literally just web requests. And part of the beauty of it being web requests is there aren't really any restrictions on web requests going on. So if you think about a typical business, it'll be looking for bad things going on in its network. But what people always do is go to websites, they're just making web requests all the time. So it's very difficult to see this sort of thing going on in the background. It's just sort of normal network traffic really. So it's really interesting how it's been done.

So I assume it's hard to detect then once this has been executed, someone in a large organization, I always hear they learned about an exploit six months after the fact. Is this one of the reasons why?

Yeah, definitely. It would be very difficult to see this. I mean, if you, if you imagine you're in a large business with hundreds of people, they're all making web requests all the time. They've all got different pieces of software that just make requests left, right and center. Really? How do you pick up the different ones? You can get software that runs on, on your network that tries to pick up malicious things going on. But as far as I'm aware that this isn't. This doesn't count as malicious activity. It's not usually picked up as that sort of thing.

So some of the information it returns is like the browser type. And as you mentioned, a lot of people may say that's no big deal, but I assume as you're doing this type of testing that as you learn, you modify your attack so you can say, oh, they're using IE9, I know there's a known exploit, let me run that against them. Is that how it works?

Exactly, yeah. So there is a degree of automation in Beef. So you can say as soon as somebody can connects to the Beef server, as soon as somebody's browser has connected to the Beef server, you can take that information and respond according to the information you've got. So if it comes along and says I'm in Internet Explorer 9, then it might have a specific response for Internet Explorer 9. And obviously that browser has been around for a long time. There are known exploits in.

Should be easy to craft a response that would, that would make use of the fact that you're using Internet Explorer 9. Yeah.

Cool. So you do talk about this in your cross, but what are some other automation features that Beef has? You had like matching and chaining. Can we just talk a little bit about each one?

So that bit there was more around the matching side. It's Trying to take what it understands from the client and craft the response specific to that. So it could be the specific browser you're using. It be could it might be a specific operating system or a specific CPU and obviously some responses. It doesn't matter what operating system or what CPU you're using, it can just send a response. So a really good one's the geolocation response. It kind of demonstrates really well how useful some of the Beef commands can be and how bad cross site scripting can be. So that there's a really simple geolocation command and you literally in the Beef user interface, you click the button and it sends off the JavaScript to the client's browser and it just does a lookup on a different website and that lookup sends you a response back and it gives you lots of information about exactly where that person is with their browser. And it's surprising how much information it gives you. It'll give you things like your postal code. When I do it, it tells me kind of a town that's about a mile away. It tells me who my Internet service provider is. It gives me all sorts of details and it's so simple to do. It's literally just a kind of a click of a button. Getting back to automation, the other side of automation is you can actually chain commands together. So you can get it to run a command and then based on the response you get, you can get it to run different commands. So again, possibly going back to the geolocation one, you might be able to say run the geolocation. If the response says a specific country or a specific browser, then you might run a different command. So that's a kind of chain of commands. So you can chain lots of commands together.

Is it part of Kali Linux or how hard would it be if someone's using say a Mac to get up and running with Beef?

So it was part of Kali Linux, but they recently removed it. I think if you just go to the GitHub repository for beef, then it gives you some really useful details on exactly how to install it. They don't recommend installing on Windows, so any Linux based operating system is fine. You can just literally clone the GitHub repo and run it from there, that sort of thing. It is very simple to get running. Yeah.

Nice. So in your course you also talked about developer tools and it seems like it's one of the most overlooked features for developers as the developing code. As a security expert, are there things developers can do with developer tools without using any other tools that Help them to make sure that there's no type of security issues that they're injecting into their code as they're writing it.

I find developer tools really useful. So that's one of the things that shows you what's going on in any website you're at. So if you're on a website that Beef is running in, for example, there's a tab on the developer tools that's for networking and you'll see loads of requests going to the Beef server. Sort of every second or two it'll send a request to the Beef server just as part of its communication channel. So that gives you a really good idea of what this web page is actually doing. But you can actually see a lot more detail about the page itself. You can see the underlying HTML, you can see the JavaScript, you can see things like cookies, you can see browser headers that are coming back from the server. So again, going back to content security policies, if a website's using content security policies or other security based headers, then you'll be able to see them coming back in the browser and it's incredibly useful. Obviously, I've come from a software development background. Some of that development involved user interfaces. So that was HTML, it was JavaScript, and it's very useful just as a debugging tool for that as well.

So, Kevin, I know you have other unique ways of using Beef or ways people don't may not think about. Can you give an example of maybe a unique way you could use Beef to find vulnerabilities or do an exploit?

So yeah, so sometimes systems are connected with each other. So if we're talking about a form, then really we're just seeing the form. So we're sending something to a form, we get something back from the forum, we can see if a cross site scripting injection attack has worked. But there are other scenarios involved which think Beef is quite useful in. One good scenario is if you take an example of somebody submitting a customer support request. So they would do that through the public side of a website. They would go into the company's public website, they would submit their request. If they thought there was a potential for a cross site scripting attack, they could, as an attacker put some JavaScript into that request. Now you don't necessarily get a response straight away from that. So if you're trying to run cross site scripting somewhere and it's not necessarily going to be picked up straight away, then it's very useful to have the Beef server running in the background because It'll be there day and night, just sitting there waiting for someone to talk to it. So in this sort of scenario, it might be a day or two later somebody picks up this customer service ticket and they might pick it up on an internal system. It might be an entirely different website, and it might be just that internal website that has this cross site scripting vulnerability. And so it's very useful to have the Beef server in place there to pick up the fact that somebody has actually triggered this cross site scripting. And it's really good to highlight the fact that things aren't necessarily very simple. Things can be much more complicated. And it's very useful to have Beef in place to see how that sort of thing plays out.

Okay, Gavin, before we go, is there one piece of actual advice you can give someone to help them with their security testing efforts and what's the best way to find or contact you in terms of testing?

The biggest failure I see is a lack of input validation. If you're trying to make requests to a service and you find it just takes any characters you like, it'll take JavaScript, it'll take HTML, then that's a really big sort of red flag in my view. So people need input validation. I see that as kind of the front gate to any service is a little bit of input validation to stop any really weird things going into it. And that's a really important thing to me. I'm on Twitter, I'm on gavgl on Twitter. I've got a blog that is gavngl me and obviously my course is on pluralsight. Look on there. I think you can send questions through pluralsight. So if you've looked at my course and you've got any questions, then feel free to fire away.

Yeah, thank you Gavin for your security testing awesomeness. For links to everything of value we covered in this episode, head on over to testguild.com S11 and while you're there, make sure to click on the Try It Today link under the Exclusive Sponsor section to learn all about Micro Focus Fortify, which is the recognized market leader in application security. So that's it for this episode of the Test Guild Security Podcast. I'm Joe and my mission is to help you succeed with creating end to end full Stack automation on as always, Test everything and keep the good. Cheers.

Thanks for listening to the Test Guild Security Podcast. Head on over to testguild.com for full show notes, amazing blog articles and online testing conferences. Make sure to subscribe to join the Guild and continue your testing journey. This has been a Joe Calantonio production.