thelightfinder

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. 

Link to Lab 6 This Lab shows a bit of promise of fun. The task is to exploit a CL-TE request smuggling vulnerability to bypass the Front-end Server Access control to the admin panel, the front end server doesn't support chunked encoding. Access to login endpoint: As seen above the login endpoint is accessible without any restriction. But an attempt to admin endpoint: well, it seems we can't access the admin panel, maybe not. Interestingly we have this endpoint to our rescue: we have already been informed that the server pair is vulnerable to CL-TE request smuggling, let's craft the exploit:  the above request poison the Back-end server such that the next request will be routed to " /admin ". Let's request the " /login " endpoint: The Back-end server responded with 401 Not authorized, I guess not so fast, let render the full response: I believe the Back-end server is very clear about what it expects from us, it expects that we either login as Admini

Lab 5 can be found here . In this Lab, we need to confirm TE-CL vulnerability via differential response, provided with a Front-end Back-end server pair where the Back-end server does not support Transfer-Encoding, the tasks is to poison the Back-end server so that when a normal request is made to the Back-end server a 404 Not Found is obtained. Since this lab is similar to the previous one I will go straight to exploitation, the poisoned request: Considering it has already been made clear that the Front-end Back-end server pair is TE-CL, the request uses a payload such that the content length read by the Back-end server is just 5, this is why we get a response of " Bad Request 'Missing Parameter' ", the rest of the request body is left to poison the Back-end server. A subsequent request to the web-root or any directory at all results in the following: Lab 5 Solved.

Lab 4 can be found here . For Lab 4 our task is to confirm CL-TE Vulnerability via differential Response. A Front-end Back-end server pair has been provided, the Front-end server does not support chunked encoding, to solve the Lab we need to smuggle a request to the Back-end server so that subsequent request to the web-root (/) results in a 404 Not Found response. Like Lab 3 the provided endpoint is a comment posting section as below: Response is: We got a confirmation redirect. From the lab task, we have already been informed that the Front-end Back-end Server pair is CL-TE, meaning that the Front-end support Content-Length Header only while the Back-end support Transfer-Encoding Header, therefore avoiding the need for any test, we use the following request: The above request now includes Transfer-Encoding: chunked so that the Back-end server will read a chunked request, the request also includes an extra payload which will be ignored by the Back-end server and will poison the next re

Lab 3 can be found here . For this Lab, a Front-end and Back-end servers that handle duplicate HTTP Request headers differently are provided, the task is to find a way to obfuscate the Transfer-Encoding Header to achieve HTTP request smuggling. The provided endpoint accepts POST request for posting comments as follows: Since both servers accept Transfer-Encoding header the above request chunk encoded becomes: Sending the request to the server, the response was: a confirmation redirect is obtained, meaning the server is happy with us, so far so good. Since the essence of the Lab is to play with how the server handles duplicate headers, we attempt this: the server still isn't complaining: well, that's because at this point both the Content-Length (CL) and Transfer-Encoding (TE)  Header values are valid, therefore even if one is using the CL and the other is using the TE we don't notice any discrepancy. Let's assume that the Front-end Server processes the first Header and