 Greetings and thank you for joining me. This is the first in what I hope to be series of videos on some of the features of ReconNG. And this particular video is going to be about something that I'm rather excited about. I know that when I first started creating a framework I was very, very clear that I wanted to focus solely on reconnaissance type activities, not still the case, but I'm finding new uses for the framework and in this particular instance, exploitation. So this past weekend, or actually last week, I ran into a situation, a penetration test where I was dealing with an XPath injection vulnerability. And through tinkering with the vulnerability and learning a little bit more about XPath injection itself, I've built a XPath brute forcing module that I wanted to share with you, okay? So for the purposes of this demonstration, I've built an XPath injection demo page. Now this is built on the premise that there exists an application and within that application, once you authenticate, you have the ability to echo back all your user account information back to you. And when you go to do this, the application prompts you for your password. You give it the password. It searches the XML, which is actual the data store with all of the username information. It searches it using this particular XPath and echoes back to you your information if your password is correct. Okay, so let's actually exercise this system to see how it works first. So let's say we put in our password as password, and I know this to be wrong. So we should get back nothing in terms of an actual XML element. And you can see here that we don't. The query that's executed, excuse on the server side says username, ppan, password, password, and we get no XML down here. So I know that the password, I know that my password is not telling. Okay, I put that in there. And you can see that here, I get all of my user account information echoed back to me. Very, very simple, very, very contrived that you can understand how this would fit into a real-world situation. So now I want to test for injection. So what can I do? Well, I can try to append a true statement to my password. And if it echoes the same information back to me, then there's a pretty good chance that I'm actually injecting into this particular XPath query and controlling the output. So here I can say, or, I'm sorry, and, one equals one, and I don't want to end it with the trailing single quote because the XPath query is going to do that for me right here. And unlike SQL injection and XPath, we can't comment out the rest of the query. So we have to use everything that's left after our actual injection. So in this case, we'll leave that single quote off. And what this is saying is, well, the username is bpan and the password equals not telling and true, which means that both of these have to be true and we should get our response back. And we see that we do get our response back. Now if I set this to false, then this being false, we'll make all of this false and we should get nothing back. And we don't. So we have now confirmed that we do indeed have XPath injection on this particular application. So now we want to actually get the XML back. We want to see what the XML contents are. Right? And for this, and for the purpose of this video, let's say that it's a blind injection attack. We can't actually tell it to echo back more data than our only user account. All we can do is ask it these true false questions. Well, that's where the module that I have built comes in. So let's go take a look at that. We go into ReconNG and we load XPath. I'm using my smart loading feature here because it's the only module with XPath in the name. And it loads our XPath Bruder module. Now if we show the options here, we'll see that we've got several options to explain these very quickly. We have the base URL, which is going to be the URL to the resource of the vulnerability, not including the parameters. And we'll talk about that here in just a moment. Do we have our basic authentication password and basic authentication username? If basic authentication is being applied in this particular case, you have the ability to add a cookie. If authentication is being maintained through a session cookie, you can add that here. Then you enter the parameters separate from the URL. Now this goes for whether using a GET or a POST request. You'll enter the parameters here and you'll mark the area of the parameters that's injectable with this little inject flag here. And we'll do that here in just a moment. We can set whether it's using the method GET or POST. And then we also need to give it a string so that it has something in the page to look for when the result is actually true. So they can actually determine whether or not it's getting a true or a false result from the injection. So let's start to fill these out. First let's go for the base URL. And here it's my localhostdemosxbathinjection.php. So let's set base URL, enter that in there. We're not using basic authentication or any type of authentication, so we can skip the next three options. Let's go get our parameters. So here let's look at the parameters we used for our first true which was the password not telling without anything else that there are actual legitimate requests. So let's go copy this, set parameters, paste, and then we need to go back to add our inject flag and where did we modify the parameters when we were testing the page just after the password. So we'll go over here, enter the flag and hit OK. It was a post request, as you can see here there are no parameters. So we'll set post to true and then the string we want to look for when we actually have a positive response. Let's go back here and open up our positive response again and I think we're going to go with Peter simply because the nature of this particular page, P pan shows up in the page not telling is going to show up in the page. So we want to use something that's going to be unique and Peter should be unique. So we'll copy that and we'll set our string paste Peter in there and we're all ready to go. So now let's run the module. As you can see it initially did a true test which passed does a false test which passed and then it uses many, many, many queries and you'll see a total here in just a moment to actually brute force the contents of the XML document. We'll give it a moment here just to finish and as you can see 4,301 queries later we have successfully brute force the server side XML file through an XPath injection. I hope you enjoy the module. As always please report any bugs or issues that you run into with the framework and be happy to fix them. Thank you.