thelightfinder

Link to Lab 6 To solve this lab, we need to bypass the application's check for file type extension and exploit the directory traversal vulnerability in the image display endpoint. Check whether the application filters our input: Response from Server: The server doesn't recognize the file, let's try bypassing with null byte: Response from Server: Lab Solved!

Lab 6 Link To solve this lab we need to exploit path traversal vulnerability in the image display endpoint, the application validates the supplied path starts with the expected folder. Let's test the application behavior: Server Response: Nothing is blocked so we exploit the application using this request: Response from Server: Lab Solved!

Link to Lab 4 This Lab has a path traversal vulnerability in the image display endpoint, it attempts to defeat exploitation by stripping the path traversal sequence from the user input before decoding and using the input. The task is to read /etc/passwd  file. As usual, test with normal exploit: Response from Server: The server responded with the image, we can confirm that the input is being stripped. Let's try encoding our input be before sending to the server and hopefully the server will decode it for us: Server Response: The server disagrees, let try doubly encoding the input: Server Response: Lab Solved!

Link to Lab 3   In this Lab, the Task is to retrieve the content of the /etc/passwd  by exploiting path traversal vulnerability in the product display image endpoint. The application attempts to block exploitation by stripping path traversal sequences from the input before usage. Attempting to exploit the vulnerability with normal path traversal sequences: The server responded with: We can inference that our path traversal sequences have been stripped, let's test a bypass by doubling the sequences: Server Response: Lab Solved!

Link to Lab 2 This Lab Contains a path traversal vulnerability in the display product image endpoint. The application blocks traversal sequences but treats the supplied filename as being relative to a default working directory. First, we try to exploit this lab using the normal traversal sequences: The server responds with an error showing path traversal is blocked. Let's modify the request with an absolute path: The server responds with: Lab Solved!

Link to Lab1   The task of the Lab is to retrieve the content of /etc/passwd by exploiting a file path vulnerability in the display of product images. The image display endpoint is: To exploit the path traversal vulnerability, we send the following request: The server responds with the following: The /etc/passwd  has been accessed. Lab Solved!

Link to Lab 11 Lab 11 is tagged expert, but it wasn't so difficult, the Lab involves a Front-end server which doesn't support chunked encoding and a Back-end which does, also the Front-end server is serving as web cache for static resources. The task for this Lab is to perform a request smuggling attack to steal other users' API key via web cache deception. Since we already know that we are dealing with a CL-TE server pair and because this Lab is very similar to the previous Lab, I will skip to exploitation. The Endpoint which serves the API key is /my-account so the idea is that when the server processes the normal request, the smuggled request will be left on the back-end socket. When any normal user makes a request for a static resource, their request will get appended to the smuggled request, the Back-end server will then respond with the appropriate response for / my-account endpoint, the Front-end server will cache the response and we can retrieve the user's API k

Lab 10 can be found here This was quite an interesting Lab, first, I couldn't follow my normal procedure of posting while I solve the lab, more so, I failed to solve the lab without a hint. This lab, similar to the previous lab had a CL-TE server pair, the task is to poison the Front-end server cache so that normal users request to the cache get served our exploit. What made this lab different really was just that we have to find an endpoint which returns a redirect response where the Location  header was an absolute  URL. To the best of my knowledge, there is only one such endpoint, which perhaps was the reason I couldn't find it easily: The ' next post' endpoint responds with a redirect with an absolute URL: Well, the general idea is that we need to smuggle a request that will induce a redirect to an exploit server we control, this redirect response will then get cached by the Front-end server, so a legitimate user request will get redirected to our exploit server du

Lab 9  link The task for Lab 9 seems very similar to Lab 8 task, same CL-TE server pair, just that in this case, we need to steal another user's data instead of discovering header. But who knows maybe there will be surprises along the way. Let's find out. The following request was made: The Content-Length in the above request was obtained using trial by error. I started with a lower value and kept incrementing until I got the required cookies: After obtaining the cookies: Server response after the above request has been sent: Lab 9 Solved.

Link to Lab 8 Lab 8 is a bit different from the previous Lab, the Front-end server doesn't support chunked encoding the Back-end server does, CL-TE, the task is to find out the HTTP Request headers added by the Front-end server, when forwarding the request to the Back-end server and then as usual delete the user Carlos . The admin panel is not protected in this level as the previous one so we have direct access: Response from the server: So, we just have to worry about the Headers. The headers will be smuggled through the comment section using this request: The Back-end server will only process the first chunk leaving the rest as smuggled request, the next request will then be appended to the smuggled request and used to post the comment. Hence, the large Content-Length . After the smuggled request has been executed the comment is posted which contains the header 'X-HiGNRK-Ip' . All that is left now is to smuggle a request with this header. Easy: The response from the serv

Link to Lab 7 Here Lab 7 is exactly the same as Lab 6 except that the Front-end Back-end server pair is TE-CL, this means that the Back-end server does not support chunked encoding. The smuggled request: Observe that the ' Content-Length ' is less than the actual content-length to trick the server into leaving the rest of the request body which will serve as the next request. The smuggled request has been executed, the server responds with the Administrator's Dashboard. All that is left is to delete  Carlos : The smuggled request has been executed: Lab 7 Solved.