Free Web Application Ethical Hacking Course (Includes Server-side request forgery SSRF)

Key Takeaways

now notice over here I am using the built-in browser in burp and so all my requests are already being passed in my burp proxy I am using the professional version of bur but for majority of these exercises you don't actually need the professional version you could just use the Community Edition which is available free for anyone you could see it's making a post request to the SL product slst and point so let's send that to repeater so that we could see it better and make that a little bit bigger you could see over here again it's to the/ product/ stock endpoint and if you go down over here it's taking in a parameter called stock API and right away I can see that this parameter is um a URL so it takes in a URL to another system that would be HTTP Colin stock. weik to shop.net on uh port 8080 if you want to see that a little bit clearer you could just right click um go to convert selection URL and then URL decode and here we go you could see the URL that it's actually making it allows me to delete any user on the system um and this is a a classic example of ssrf uh vulnerabilities the first thing that any pentester would actually check for is Local Host The Next Step would be to um check for um do a port scan on other internal servers on the system and then see if they have vulnerabilities that will give you remote code execution but that's going to be lab number two and lab number three for the sake of completeness let's complete this lab so we're going to delete a user to confirm that from the outside as an attacker I'm able to delete a user on an internal system so let's go to Carlos copy the URL to delete a user put it in here hit send you get a 302 that's great that means it actually deleted the user and then redirected you and um the interesting thing over here is if you follow the redirect it should give you like an unauthorized or an access denied because you're trying to access the application directly as a public user the admin application you can't do that you have to always access it through the ssrf vulnerability or the vulnerable parameter because there's a trust relationship between the public application and the internal application hey everyone David Bumble back with Rona Rona great to have you back hi David thank you for having me so r fantastic demonstrations and videos that we've created in the past I'll link them below if anyone's interested in SQL injection and other interesting topics have a look at the videos that I've linked on my channel below but Ron I've got to push your channel because you've done a crazy amount of content on your channel so just before we get started into I think we're talking about some very interesting topic today tell us about your channel and what's on there and then if you can introduce today's exciting topic that'd be great awesome um so I have a YouTube channel it's called my name so Rena kalil's uh Channel I essentially cover web security related content so we go into depth on each vulnerability category you'll see vulnerabilities like command injection like server side request fory which is what we're going to talk about like SQL injection and so on um what we do is we essentially cover the vulnerability in deep technical details um and then we have Lab videos where you gain hands-on experience and exploiting how the vulnerabilities work and today we're going to be covering a really important vulnerability category called server side request forgery or in short ssrf which is actually um one of the top most critical uh security risks facing web applications today I love it I mean you said it's one of the top ones on on the on on some kind of table is that right that's correct so um there's an organization called OAS it creates a ton of uh web security content and standards and tools and uh one of the standards that it has is the OAS top 10 list it lists the top 10 most critical security risks facing web applications today and server side request forgery Falls as the 10th most critical security risk facing web applications so for everyone who's watching I'll say the following R's got a huge amount of content on her YouTube channel which you can get for free so if you can't afford to buy a course go and watch the content for free but Ron you've also got courses on udemy which we collaborating on which is amazing and you've also got your Academy so could you tell us about the differences there quickly and then let's get into the technical details yeah absolutely so um the courses on YouTube are available for free but you will have to run into uh YouTube ads and sponsor messages there's also no support if you have any questions about the lab environment or the lab videos and so on now when it comes to udem me the courses are the same as YouTube however they're in a more structured way there's also uh support for um answering your questions so David's amazing team will be there to answer any questions uh that you have I'll also be there to answer questions and then there's my Academy where um you gain access to all the web security content so not individual courses but all the vulnerability categories are included in one course it's a bit more expensive but it contains more content you also gain access to uh my own Discord Channel where you could ask uh questions if you have any doubts about the material I love that I I love that you're giving back to the community so again for everyone who's watching if you don't have a lot of money and you're just starting out and you want to learn this stuff go and subscribe to R's amazing YouTube channel and you know go and consume that content how big is the SQL injection course it's about 9 hours long so just that one is 9 hours so 9 hours of free content right there but Rona ssrf what is it about I love the way that you teach you you you're going to take us through some theory of Hope and then some Labs right yeah absolutely let's start off with the theory and then we'll move on to the labs okay so like I said today we're going to be talking about a really important topic called server side request forgery or in short ssrf now this vulnerability category or is a little bit difficult to understand from the GetGo if you've never been introduced to it before and so what we're going to do is we're going to show you an example that models the real world for an application we're going to talk about the different functionality in the application and how that functionality could potentially introduce serers side request forgery attacks now once we're done with that example we'll be ready to Define what ssrf attacks are so now for the example we've got um a user who's uh browsing the web and an application um that is used to shop online now this application is hosted in an internal Network so behind a fire firewall however um it's configured uh so that it's public facing so anyone on the internet like this user over here is able to shop on this application now this is a modern application where the functionality that is presented in the application um is not solely done in the application itself so it uses thirdparty systems in order to perform certain functionality um and that you'll see that um in uh most modern applications today and one of the systems that it uses is this internal system over here so it's hosted on the internal Network and it's used in order to check if an item is in stock but it also uses third-party systems in order to uh purchase an item so let's say this application over here is not PCI DSS compliant and so it doesn't want to handle transactions and so what it does is it offloads that functionality to this third-party system that is hosted in the cloud now we're going to talk about the different uh functional use cases uh for this application and then how they could be potentially vulnerable um the first use case over here is to check if an item is in stock so when a user wants to buy an item the first thing they have to do is check if that item is still in stock for the specific store that they want to buy it from and so what they do is they click on the check St button and what happens is that the application makes a request to another application so another internal application that is responsible for checking if an item is in stock and that request looks something like this so the application is called stock. shop.net it's hosted on port 8080 you could see it's over HTTP because it's the internal Network and they didn't care about making it over https um and um it takes in the product ID of the item that they want to check if it's in stock or not and you've seen this in the real world right oh absolutely um so the Assumption over here is that no one has access to this application so the internal application itself and so the safeguards or the the security measures that are put on internal applications or applications that are um IP whitelisted are much less than the safeguards that are put on applications that are public facing but today you'll see how uh detrimental that can be if there is a vulnerability in the uh public facing application that could potentially allow you to access um less secure applications in the internal Network I just wanted to ask you because not everyone perhaps knows you you do Consulting on this stuff like that's what you do right you do a lot of Consulting so you see this kind of stuff and the training is based on a lot of your real world experience yeah absolutely so um uh my main role um as a consultant is to go into my client organization and test the uh applications that they develop and the thirdparty applications that they acquire and so I see these types of vulnerabilities um in majority of the pentests that I do some of them are critical others um are not so critical so it really depends on the functionality of the application um to determine the impact of the vulnerability itself and the nice thing about the course is that um the labs are structured in such a way that um they increase in difficulty and so you'll see a lab where um the impact might not be so much versus a lab where the impact is fullon remote code execution on the underlying server I love that because you know on YouTube I often get comment it's like David this is dumb this will never happen but it's so nice talking to experts like yourself who do this day-to-day and see what's actually happening in the real world so it's nice you know this is what you see rather than just like a a madeup story so sorry to take you in the tangent I just love that no worries yeah absolutely um it's definitely what we see just because it seems like a really um simple attack Factor doesn't mean that it doesn't exist in applications I've tested many Legacy applications I've tested applications that were developed let's say last year or the year before that so modern applications and we still see these vulnerabilities um in a ton of the applications and that's why they're actually under the they're listed as one of the top 10 most critical security risks facing web applications today and that's because you actually do see them and when you do see them they actually have uh critical impact all right so to go back to our example we've got um uh an internal application that is responsible I for checking if an item is in stock now when our public facing application makes that request it'll um get processed in the internal application and it'll respond with the number of units that are left in stock so that's the first functionality of the application the second functionality is to see if you could buy the item now that you know that it's actually in stock and uh the application makes use of a thirdparty system to perform any Financial transactions so um when a user clicks on the buy button what happens is the public facing application makes a request to the third-party system which is in this case AWS service.net it gives it the product ID and the financial information of the user and then the user is able to lie the item now the important thing to note over here is that there's a trust relationship between the public facing application and anything that is avail able on the same network so on the same internal Network there's also a trust relationship between this application and the thirdparty system if me as a regular user try to access let's say this application directly I will get an access denied because this is behind a firewall same goes if me as a user I try to access this third-party system I also get an access denied because there's IP filtering that doesn't allow me to access it the only application that is allowed to access it is this one over here because there's a trust relationship between those applications and I'm spending quite a bit of time on this because this is a crucial point to understand when it comes to understanding server side request forgery um vulnerabilities or attacks I'm glad you're doing it I and I love that that the way you train because you assume very little knowledge and then you take us from you know beginning to hardcore stuff so I appreciate it no problem so now what could potentially be the issue with applications that function this way well what if these parameters over here so the requests that get passed to other applications to perform certain functionality what if they're user controllable and two not properly validated at the back end so when I say user controllable what I mean is although to you as a user it appears that everything is being in one applic application but in reality it's actually done with multiple applications now what if that URL that you request to the other application is controllable by you as the user and what if it's not properly validated so what not properly validated means is that you could request any URL that you want it's not just this URL that you're allowed to request in that case you introduce the attack factor of server side request forgery so let's assume I'm an attacker instead of me requesting the stock shop.net port 88 SL check endpoint maybe I want to request the slash admin endpoint and what's going to happen is this application trusts this application and so it'll respond and give me the admin panel of this application over here now if I were to do this directly to this application I'm going to get add access to message but because I'm doing it from an application that has a trust relationship with the other applications that are available on the internal Network then I'm allowed to do that and as you can see over here it allows me to view items it allows me to add items on the application it allows me to delete items and so it affects confidentiality integrity and availability at a maximum level but that's not the only thing that I could do what if I want to do a port scan of everything that is available on my internal Network so this is how networks work right if you're sitting on the same network you could port scan everything that is adjacent in your network and depending on like on the authentication that is put put on those servers um or those applications and so on you may even be able to access them and that's what I essentially do over here I port scan the network for any web servers that are running on Port 80 and I find out that there's a cold fusion server running on 10.21.17 to and we all know that previous versions of cold fusion had authentication bypass vulnerabilities and so now I could start chaining vulnerabilities together I could exploit the ssrf vulnerability to perform an authentication bypass vulnerability on an internal server in the internal Network and we'll see an example of that in the lab where you actually do get a chance to port scan the internal Network identify a web server that is running on the internal Network and then perform your exploit on that um internal server um and the last example uh for today is um the third party system now not only could I attack anything on the internal Network I could also attack any third-party systems that this application has a trust relationship with over here and that's essentially what I'm doing over here based on the Privileges that this IM IM role has I could potentially gain access to the third party system and where have we seen that before um I'm pretty sure everyone on uh watching the video um have has heard in one form or another about the Capital One breach because it was one of the biggest um breaches so one of the biggest data breaches of all time where hundreds of uh millions of users uh personal information and credit card information were exposed both in the US and in Canada and the reason for this attack is essentially the hacker or the attacker exploited an ssrf vulnerability to dump the metadata of an ec2 instance and then uh found the credentials of a highly privileged uh role and then use that role in order to dump the S3 buckets which contained um the user's data so this is definitely a real world vulnerability which has been exploited before and has had significant impact on the data privacy of users whenever I talk to to people like you I think I should go and live in a cave but um doesn't I'm not I'm not sure it's going to help but Sor go on it's okay I feel like I can't trust anything anymore either this is why it's absolutely important to like be educated um on on these vulnerabilities of course you can't go and hack Real World Systems but a ton of these um organizations have bug Bounty programs if they do have a bug boundy programs you could legally try and see if they have any vulnerabilities of course there are full-on jobs just like my job where we test or we pent test for a living it makes it really difficult to trust any um any application that you put either your health information in or your personally identifiable information in or even your um financial information is but that's the world we live in today yeah it's uh it's woring but like you say the best thing to do is educate yourself and if you if you really enjoy this like you doing you know why not get paid to do it it's great exactly yes I think I have the best job in the world so um now we're ready to Define what server side request fory vulnerabilities are so ssrf is a vulnerability class that occurs when an application is fetching a remote resource without first validating the user supplied input so whenever you see a place in the application where it's potentially uh calling a remote resource so where you see a URL and you see that it's not properly validating that URL that it's requesting then the application is very highly vulnerable to server side request fory vulnerabilities all right so there are two different types of ssrf vulnerabilities the first one is regular or inband ssrf and the second one is blind or outof bend ssrf regular or inband ssrf is when you see the response of your payload directly presented back to you in the response of the request but blind or out of a band ssrf is when you don't see that response directly presented back to you in the response of the request instead you would have to send the response of your payload um to an attacker controlled servers like a burp collaborator um in order to be able to exfiltrate uh data from the backend system we'll see examples of both today so we've got uh two Labs that cover regular or inband um ssrf and then one lab that covers BL or out ofin ssrf all right so we'll start off with the first lab which is a basic ssrf against a local server so this is how all the labs are structured in the course they're the uh Labs that are created by the port swiger organization as part of the web Security Academy and in my opinion the web Security Academy is the gold standard when it comes to web security and that's why I use those slabs when it comes to uh my courses like I said the labs do increase in difficulty so the first lab is going to be really simple the second lab we're going to take it one step a notch and then uh the last lab is going to be one of the expert Labs where you're going to be chaining multiple vulnerabilities together in order to uh gain full-on remote code execution all right let's start off with the first lab um so the lab description goes like this lab has a stock check feature which fetches data from an internal system so similar to the example that we saw in the slides to solve the lab change the stock check URL to access the admin interface at localhost admin and delete the user Carlos so um because this is um a lab of uh easy difficulty level so it's one of the easier Labs it actually tells you where um the internal system is located and in this case it's located on Local Host and it also tells you the directory where you could access um the um admin functionality and um delete the user Callos in a real world scenario of course you would have to try to Brute Force these directories in order to find them you would also have to run a port skin in order to identify the server but we'll see examples of that in the upcoming Labs all right let's access the lab right click and open link a new tab now notice over here I am using the built-in browser in burp and so all my requests are already being passed in my burp proxy I am using the professional version of burp but for a majority of these exercises you don't actually need the professional version you could just use the Community Edition which is available free for anyone all right so for the first part of the exercise what we're going to do is essentially map the application what that means is we visit every page in the application and we look for locations where the application is um making um a request to an third-party system or to another system so a remote system and we're going to do that by clicking on view details looking at the requests clicking on check talk and looking at the requests now if we look at the uh check stock uh request that responds with the number of units that are left in stock you could see it's making a post request to the SL product slst endpoint so let's send that to repeater so that we could see it better and make that a little bit bigger you could see over here again it's to the SL product slst endpoint and if you go down over here it's taking in a parameter called stalk API and right away I can see that this parameter is um a URL so it takes an a URL to another system that would be HTTP colon stock.we like shop.net on uh port 8080 if you want to see that a little bit clearer you could just right click um go to convert selection URL and then URL decode and here we go you could see the URL that it's actually making now like I said whenever you see a URL what you want to do is you want to see if you could call any URL that you want not just the URL that it's actually requesting so the first thing that I'm going to do is just remove everything over here and see if I could access the main application stock that we like to shop.net and hit send and it doesn't work so it says missing parameter it's likely that this application is only responsible for checking if an item is in stock and the only valid uh directory is let's say SL product so the next thing that I'm going to do is see if there's anything running on Local Host so let's say Local Host hit send and here we go we get a 200 okay message which means that we were able to exploit this ssrf vulnerability in order to access the content of the local server now if you go and visit Local Host on your um web browser if you have something running locally on your computer you'll be able to see it otherwise it'll say that it's not able to resolve that ad address over here so you're actually accessing a resource from the local server where the application is installed so let's see what that resources we click on render and it looks like it's similar to the application that we're on with the exception that there's an admin panel so we didn't see that over here exactly we didn't see that over here so if you click on home there's no admin panel over here so um the next step is to see what's in the admin panel so I need the URL for that so I'm going to click on admin and the URL to the admin panel is SL admin hit send another 200 okay that's great hit render and here we go it allows me to delete any user on the system um and this is a a classic example of ssrf uh vulnerabilities the first thing that any pentester would actually check for is Local Host The Next Step would be to um check for um do a port scan on other internal service on the system and then see if they have vulnerabilities that will give you remote code execution but that's going to be lab number two and lab number three for the sake of completeness let's complete this lab so we're going to delete a user to confirm that from the outside as an attacker I'm able to delete a user on an internal system so let's go to Carlos copy the URL to delete a user put it in here hit send you get a 302 that's great that means it actually deleted the user and then redirected you and um the interesting thing over here is if you follow the redirect it should give you like an unauthorized or an access denied because you're trying to access the application directly as a public user the admin application you can't do that you have to always access it through the ssrf vulnerability or the vulnerable parameter because there's a trust relationship between the public application and the internal application but if you go back and do it from over here it should work so slash admin hit send and you're render and you could see over here Carlos is no longer a user on the system like I said I want to go live in a cave exactly yeah me too I don't blame you yeah so that was lab number one let's go um to lab number two which is a little bit more difficult all right let's move on to lab number two so it's a basic SSR up against another backend system if we look at the description it says this lab has a stock check feature which fetches data from an internal system so same as the previous lab but the difference is over here the stock check functionality is in an internal system and so you no longer have the system available on Local Host you actually have to port scan the internal Network to identify any web servers that are running on 192.168.0 dox so they're not giving us the last octed we actually have to port scan that one to see if there's any web servers running on it and then hopefully get the admin panel from there so let's access the lab again all the requests are being passed in uh my bare proxy all right so since this is similar to the previous lab we're going to click on view details and we're going to look for the Chuck stalk functionality and we'll look at the request in a repeater now again over here it's a post request to the SL product slst endpoint if you go down right over here you could see that there is s talk API uh parameter that takes in a URL in this case though the URL is HTTP col1 192.168.0.1 so right away what I'm going to do is see if there's an admin panel on this internal system click Send and I get an internal uh server error so uh my guess is the admin panel is not hosted on This Server itself so the next step is I'm going to do a port scan on um all the IP addresses for this uh specific octet so we're going to do from one to 2055 and see if there are any servers that are running on port 8080 for that one so let's right click Send to Intruder and use Intruder in order to perform our port scan so the first step is to clear all the parameters and just select the parameter that you want a Brute Force so that would be uh the last octus which is the one over here and then we're going to add port 8080 because I believe that's what the lab requested yes so port 8080 in a real world scenario you'd be checking Port 80 you'd be checking port 8080 you'd be checking uh Port 443 and so on in order to uh brute force all the possible IP addresses we're going to go to payloads click on numbers and then start from one all the way to 255 and um select one as the step which means that it will increment one each time so it'll start off with 192.168.0.1 and then it'll move on to 192.168.0 two and then3 and so on all right this looks good um let's click on start attack and what we're looking for is essentially any status code that is different from 500 so if we're not getting an internal server error message that means means we're potentially we've potentially hit a server that does exist on the system so if we click on status over here you could see on uh 142 we actually get a 200 okay message so that's a really really good um indication that we've actually hit a web server and that web server is actually valid so if we look at the response over here and actually what we're going to do is we're going to send it to repeater because it's easier to play with now in repeater over here we'll make this a little bit bigger we'll send it again and render the response and here we go we were able to find the admin panel on uh IP 192.168.0.1 142 um now the next step is just to delete the Carlos user just like we did in the previous exercise so we're just going to look for the there's no authentication on that server is that right yes there's no authentication because one it could potentially be because there's a trust relationship between the two and you don't need to authenticate between the two applications or two it's internal and so uh they just trust their internal Network and that's why there's no authentication uh so we're going to copy the directory and the path in order to delete the Carlos user put it in here so we're re exploiting the ssrf vulnerability to delete the user hit send and here we go we get a 302 which means that it did redirect so it did delete the user and then redirect and if we go over here it should say congratulations you solve the lab and here we go and it's this easy in the real world yes yeah it is um so sometimes you will see um the ssrf parameter has certain restrictions so in terms of let's say um encoding that you do in terms of certain characters that you could do and so on that you could put in there um and so on um and so we have Labs so this would be more of the expert Labs we have labs in the course where developers have put in security measures there's just inadequate security measures and so we talk about different ways to bypass those security measures in order to perform exactly what we did in the easy labs and just to so for because people often complain about this I just want to confirm that's available on your YouTube channel right so when you say in the course it's all available for free on your YouTube channel correct correct it's available on YouTube it's available for you to me and it's also available on my Academy awesome so now let's move on to the final uh lab which is rated expert in this lab we're going to be exploiting uh two vulnerabilities so let's look at the description of the lab the site uses analytics software which fetches the URL specified in the referral header when a product page is loaded to solve the lab use the functionality to perform a blind ssrf attack against an internal server in the 192.168.0 X range on port 8080 in the blind attack use a shell shock payload against the internal server to exfiltrate the name of the OS user so essentially for this lab not only are we going to be chaining two vulnerabilities together it's actually going to be one of the more difficult um ssrf uh vulnerabilities so those are called Blind ssrf where you don't see the response of your payload directly presented to you so um in the previous two labs when we saw the admin panel we were able to see what the URL is to delete a Carlos user or to delete any other user and so it made our job really easy but for this one it's blind so you won't see the response of the request you actually have to exfiltrate data to an attacker um controlled server which in this case is going to be a collaborator and to use collaborator you actually need um the professional version burp which is paid um and so this is not something that you could do uh with the free option all right let's access the lab as usual I'm using the built-in uh browser in burp and so all my requests are being passed in my bur proxy um for this lab specifically uh what we want is to test all the different parameters that are available in the application which could be hundreds and so um instead of doing that manually which is an error prone approach what we're going to do is we're going to use an extension called collaborator everywhere so this is an extension that is available for free on the um B Store so if you just search collaborator everywhere click on it and then click on install you should be able to install it I already have it installed and so um what I'm going to do is I'm going to add this URL over here in the scope um for burp and so what'll happen is that this extension will enter um my attacker controlled uh server URL in pretty much every parameter it sees when I'm mapping the application and then if gets any uh pingbacks it'll inform me that hey I think there's a vulnerability over here it's an out of band vulnerability that you might want to look at and we'll see an example of that right now so the URL over here is 0844 z which is this one over here I'm going to right click add to scope the reason we're adding it to scope is because um this collaborator functionality is intrusive functionality and so you definitely don't want to be doing this on um an application that you don't have permission to test and since the way applications function is like look at all these different applications it's reached out to um and so you don't want to be doing this on all these applications that you don't actually have access to and that's why you have to add it in scope um so the next step over here is to just map the application and see if it reports any issues so we're going to click on view details go down doesn't look like there are any entries over here go back to home and and here we go immediately it tells me um we got a collaborator ping back on both the referral header and the user Asian tedar so two locations are being used in the application where you could actually call any URL that you want including um a URL uh of your choosing which is the attacker controlled um server so this is interesting what I'm going to do is um I'm just going to select one of them and send them to your Peter and work from there so so you could see the extension over here and that's why you have to add it in scope but the extension over here it added it a forwarded header it added a from header it added an X originating IP header and it tested all of them but it only uh showed that it's vulnerable for the user agent header and for the referer header so those are the two headers that I'm going to work with um let's delete everything else and make sure this is a valid request and it is it's a 200 okay request all right perfect so what I'm going to do right now is uh use the referral header in order to um perform an ssrf attack so I'm going to port scan the internal Network to identify if there are any web servers that are running on um the internal Network now while I do that I'm going to use the user Asian T to put in a shellshock payload so that while I'm scanning the internal Network I'm actually also attacking any uh servers that are there of course if there's no if there's no server um it's not exploitable right um so nothing happens however if there is a server and it's vulnerable to shellshock I should um get a ping back on my attacker controll server now for those of you that are not familiar with uh shellshock again it's a vulnerability that I believe came out in 2014 um and and it affected uh many systems uh but mostly affected uh or became famous because of uh uh public systems that are available publicly like um web servers um and uh the way the vulnerability worked is there are certain parameters in the request like the user asan tatter which were not properly validated in the web server and then were passed as variables um to the command line um now when it's passed as variables to the command line you could break out of that command and perform any command that you want which led to remote code execution and that's exactly what we're going to do so for the referral header we're going to do our port scan over here so it was 192 and I don't remember the exact IP range they wanted us to port scan so 192.168.0 and let's say one for now port 8080 and uh for the user agent tter that's where we're going to put our shell shock payload of course I do not have that memorized so I'm just going to do a quick Google search and look for Shell Shock payload example and we'll just click the first entry which is the cloud flare blog I've read this one before it's a great blog explaining the vulnerability um if you've never heard about it before so if we go down right over here here we go that's the first payload it's also in the user Asian tar um so we're going to copy the payload and we're going to add it in here so we'll enter it over here what this payload does is it essentially ejects a CD or a DVD from the server that is vulnerable of course we don't have access to that server to confirm that the payload worked and so we're going to need to use something else um what we're going to do is let's add user so that we have um a full path and then bin and then we're going to perform an NS lookup to our attacker controlled server so that would be collaborator click on get started and then click on copy to clipboard that'll generate um a URL for our attacker controlled server put it in here and add HTTP to that and essentially what'll happen is over here if you do hit a server which has an application that is running on port 8080 and it's vulnerable to shellshock it'll perform an NS lookup um on our server and we get a ping back but um just getting a ping back doesn't really show impact and so what I want to do do is I want to uh actually run a command and then exfiltrate the response of the command to my attacker controlled server and the way to do that is to add the dollar sign and the command that I'm going to run is who am I and add it as a subdomain so when it does uh perform an NS lookup what it'll do is it'll run this command and then the response of that command will be added as a subdomain and it'll perform an NS lookup on that subdomain of course that subdomain doesn't exist in my collaborator server and so um all it does is it's it logs for me that someone tried to access so and so subdomain and this way I actually get the response of the command nice so that's how hacking works you just got to get really creative for how you exfiltrate data um exactly so let's do that click on send now we're just doing it for one that might not be vulnerable so if you click on pull now now you don't get any entries um but what we want to do it is for the entire range so we're going to send this to Intruder again and perform this for the entire range so clear add the last octat because that's the one that we want to uh Brute Force click on numbers one to 255 just like we did in the previous lab and we step by one and let's make sure everything looks good it does and start attack okay so while that's running I'm going to go to collaborator and see if I get any ping backs now we do have to wait until all 255 entries are complete and it's going pretty fast but hopefully we get a a eping back for one of them I'm glad in the lab that they didn't do something obvious like dot one yeah exactly no you actually have to work for it and here we go um we do get a ping back from one of the servers so we did find a server that is vulnerable to shellshock and you could see it tried to access the subdomain Peter Dash D zr4 which is not a real subdomain it's actually the output of the who Ami command and so we successfully gained remote code execution on the server in a real world scenario you'd actually have a shell so you would include a command that performs a shell um so it gives you a shell on your system this way you could run whatever command you want but this is more than enough proof in a pentest to sh to show that you've remote code execution yeah great demos Rona thanks so much no problem so now all that's left is to talk about how to prevent and mitigate ssrf vulnerabilities all right so when it comes to preventing ssrf vulnerabilities you always want to take a defense in depth approach so there are the official defenses which are um under the application layer defenses but there's also additional defenses that you can take um uh under the network layer defenses which will make it much much harder for an attacker uh to exploit the SSR of vulnerability or to at least prove impact if an SSR of vulnerability were to exist in your application so we'll first start off with application layer defenses and then we'll move on to the defense in depth approach which is the network layer defenses so for application layer defenses the first step is to sanitize and validate all client supplied input data so if you're taking in data of a certain type or of a certain structure sure that data should be sanitized and validated to be of that certain type and of that certain structure any other data should be rejected number two is enforce the URL schema port and destination with a positive allow list so if you're taking in URLs that have uh let's say the URL talk. we likos shop.com then you should um only put that specific URL in an allow list and only allow users to uh use that URL anything that is not in that allow list or also known as a white list should be rejected this immediately eliminates um ssrf vulnerabilities if it's done correctly of course if it's done incorrectly it could potentially have uh gaps um which allows us to uh bypass that defense another thing that you could do I'd hate to be I'd hate to be a developer with you on the team sorry I'm just joking it' be great to have you on the team but yeah yeah no um I've reached a point where um I you explained this to developers in a way that you see this in all applications it's not them it's not just their code um so it's it it it happens and it will happen with them and so this kind of develops a good relationship with the developers um when they understand that it's not that they're doing a bad job it just that no one is taught secure coding um when it comes to University I was a software developer myself and I didn't learn secure coding I had to learn all of these items on my own and that's why um developers make these mistakes um because no one taught them that they should do it a certain way yeah um all right the third step is uh do not send raw responses to clients so we saw with the first two examples we were able to see the raw response of the admin page we were able to figure out how to delete uh a user how to add a user and so on which made our life easier if we didn't get that raw response it would be a little bit more difficult for me as an attacker to figure out how to perform uh the functionality that I want to perform uh just like deleting a user the last step is disable HTTP redirections so what attackers sometimes do is uh they use a URL that they know is allowed by let's say Rex rules or by um a deny list and then um they actually redirect that URL to the real malicious UR l or the URL that they want to access um that they wouldn't have been able to um access from the get-go uh because of that defense that is put in place by developers um so it's really important that you disable HTTP redirections and um just use the URL that the uh individual had given you um of course with that defense that it's a positive um allow list we'll talk more about that uh in depth in the course as well or when I say course again either YouTube udemy or uh my Academy so that's the application layer defenses um I do have a note over here that says do not mitigate ssrf vulnerabilities using Deni lists or regular Expressions because chances are we can bypass these inadequate defenses and there's a few lab examples so the course has seven Labs um there's a few Labs where they did use Deni list or they used regular expressions and we were able to easily bypass those defenses all right um the defense in-depth approach is to also have Network layer defenses so the first one is segment remote resource access functionality to separate networks to reduce the impact of ssrf this is a common defense or a common um security practice which is always segment your networks you don't want to have um something that is public available in the same network as something that is highly critical and um important to your organization um so depending on where that server is it has access to everything that is on that Network and so if it's isolated or segmented um what'll happen is it reduces the impact of an ssrf vulnerability if an ssrf vulnerability were to exist in your application um and then the last item over here is to enforce deny by default firewall policies or network access control rules to block all that essential intranet traffic this prevents uh something like a blind SSR of vulnerability from pinging back to my attacker controlled server um if a SSR of vulnerability were to exist um now as I mentioned this is defense in-depth approach the real defense over here is to have an allow list um of URLs that are allowed and to sanitize and validate all client supplied input data and that's pretty much it Ron I really want to thank you for sharing and thank you for making your content available for free on YouTube so for everyone who's watching please go and subscribe to Ron's channel the channel has grown quite a lot recently we want to try and get it to 100,000 Subs so please go and subscribe go and have a look at our content amazing stuff there R any last words uh thank you for having me David brilliant Rona thanks so much and we just for everyone I've put links below if you want to get access to R's course on Udi links below her Academy's link below but if you can't afford it go to her YouTube channel and support her Rona thanks so much