Orlando Cyber Studies

  Practitioner Lab 6: SSRF with blacklist-based input filter I start by looking at the website itself and try to find if its communicating with the backend In this case it does this inside of the items they are selling to check if there are any items in stock Now I will take a look at the request to see how it is working Here is the stock API which I can use to send request to the backend I tried to access the /admin page using the trust of the localhost but it is blocked. It tells me that External stock check blocked for security reasons. Now There are a few things I can do and I will try to do all the options I know I tried using 127.1 instead of 127.0.0.1 but it didn’t work. I also tried to URL encode it but it also didn’t work After trial and error, I found a solution to the problem If I used simply the loopback it would be blocked. But if I used 127.1 it would pass meaning that it wasn’t only blacklisting the localhost but it was also blacklisting the admin wor

 This lab contains a path traversal vulnerability in the display of product images. The application validates that the supplied filename ends with the expected file extension. To solve the lab, retrieve the contents of the  /etc/passwd  file. the first thing I do is check the website out and look for images. I will then click on the page with the image because this way I can see the request on Burp Suite In this case, the server is checking for a specific extension so i put it after the %00 null byte Now I am going to check how it works when I don’t put that. I want to see what type of answer it will give me. It will simply say no such file.

 This lab contains a path traversal vulnerability in the display of product images. The application transmits the full file path via a request parameter, and validates that the supplied path starts with the expected folder. To solve the lab, retrieve the contents of the  /etc/passwd  file. I began by going into the page with an image and captured the request. I then opened Burp Suite and looked at the request and as the lab specified the request will not work unless it has the main path of /var/www/images I tried to check what answer it would give me when I didn't have the full path name just to learn. After putting a full path name it worked out including the starting point of /var/www/images. Now the lab is solved.

 This lab contains a path traversal vulnerability in the display of product images. The application blocks input containing path traversal sequences. It then performs a URL-decode of the input before using it. To solve the lab, retrieve the contents of the  /etc/passwd  file. I started by looking around the page to see how it worked. I then opened one of the images to see the request. I looked at the request and then I changed it I had to encode it for it to work. and the lab is solved.

 This lab contains a path traversal vulnerability in the display of product images. The application strips path traversal sequences from the user-supplied filename before using it. To solve the lab, retrieve the contents of the  /etc/passwd  file. The first thing I do is look at the website and how it is working I see a lot of images so I can use Burp Suite to look at where are all these images coming from Here I can see the request for all these images I will try to change it for another file name to see if I can get it I know it is stripped so I will probably have to use // of them to get it to work. When I try to use the absolute path it doesn’t work because it it stripped. Now I will use the double to see how it works It took me a while but I figured out how it worked. This way it works when it is filtered.

 This lab contains a path traversal vulnerability in the display of product images. The application blocks traversal sequences but treats the supplied filename as being relative to a default working directory. To solve the lab, retrieve the contents of the  /etc/passwd  file. I began by looking into one of these pages which have images I then went into the source code and took a look at where the image was being accessed I then went into it and changed the image for the absolute path of the file /etc/passwd This then resulted in the lab being finished. To solve this using Burp I went into the http history and this allowed me to see the request for images. Here I take a look at the request and then change it to the absolute path of /etc/passwd and then I get the contents of the file

 This lab contains a SQL injection vulnerability in the login function. To solve the lab, perform an SQL injection attack that logs in to the application as the  administrator  user. I started by looking for a login page. After getting to the login page I look at the request on Burp Suite Here I put the SQL injection and now when I put this it will bypass the password thus letting me sign in like the Admin.

 This lab contains a SQL injection vulnerability in the product category filter. When the user selects a category, the application carries out an SQL query like the following: SELECT * FROM products WHERE category = 'Gifts' AND released = 1 The first thing that comes to mind is looking at the Refine your search message on top. This tells me that it is going to the database and getting the products that meet the description I looked at the original request and added the ‘+OR+1=1— and this gave me the extra products.

 This lab contains an OS command injection vulnerability in the product stock checker. I start by going to a product and then trying to request the stock. Since this deals with the backend I can use this to inject an OS command and get information. Here I changed the values of the productId to the whoami command and it became URL-encoded I found out that I could’ve also done the OS injection like this. This would have also worked

I got the request and then I used intruder to brute-force the range of ip’s that could be. With this I was then able to get the ip to the admin page. Now i go to the page and delete the user I put this request to delete the user called Carlos and now I double-check that the user was deleted

 Here I have to exploit SSRF The first thing I will do is look at the requests  that the web page makes with Burpsuite The website has an option to check the stock of an item. This has to connect to the backend. If i am able to change this request with the loopback address which is often trusted then I can access a page that I don’t have normal access to. Here is the request and as can be seen it is accessing the backend. By changing the request to http://localhost/admin i was able to gain access to the admin page and delete a user. After looking at the request I saw that the path to delete Carlos was to go /admin/delete?username=carlos I then added this to my original path and sent it, I then followed the request and it worked. The user Carlos was deleted and the lab was done.