In this case, I literally wrote the original exploit, and I recognized the application running, so it was pure coincidence. As to how I found the original vulnerability itself, it was source code review since the app was open source.
I'm going through the room for the fist time and new. It doesn't even tell you to do the things your doing, it just connect to the web application and answer the questions. This room and others have totally lost me
Yes I agree, I have a general idea of what they're doing in the video because I've been studying on bug hunting and for certs but this is definitely not for beginners...
Hello, on the last task SSRF, i got stuck on for a while. how did you know to add the ?c= in the URL after /admin?. just a little information would be appreicated . thank you for the video , it helped me ALOT.
Hey Tib3rius, So the way you completed task 20 is different than how thm tells you to do it (they say to use Developer Tools). The main issue I was having would occur when I copied the JWT token value and modified it in the encoder/decoder that thm suggest to use. After reinserting the new modified value and refreshing the page, I get the “invalid token/signature” message. I believe after watching your video that the issue is with the encoder/decoder website that try Hack me suggest to use, but I was hoping that you’d be able to validate that? Thanks for reading if you see this.
I see what the issue is. The room is incorrect. JWT doesn't use Base64, it uses Base64URL, which is similar but not the same. One of the major differences is that Base64URL doesn't use padding characters (=). If you watch my video again, you'll see that I keep having to remove %3d, which is a URL encoded =. There are other differences but most of the time you can just get away with removing the equals sign(s). Let me know if that helps!
@@Tib3rius I do understand what you mean but now the problem seems to be the “.” Between the encoded value. W/o the “.” the value will show a valid result. However, with the “.” included It throws the result off. I tried encoding &decoding the brackets separately and together but it doesn’t work. I also noticed after watching your video that I’m not able to edit the Values under the Inspector tab the same way you did.
I just fought this exact same problem for 2 or 3 freaking hours and I finally got through. Here's how I accomplished this, I used Burp to capture the GET of the /flag on initial login as guest. I copied the Cookie: jwt-session= value. I then deleted the signature section of the token (the last section of the dots as described in the THM Tutorial.) I then separated the Header and Payload without the Dot at the end of the section. I copied the Header into Burp's decoder, decoded it to plain. Then in the second box, highlight all of the output, set this section to encode to Base64, then edit the alg=none. Copy the output of the base64 below, including any =s. Do this same thing with the Payload section of the token, this time changing the username to = admin. Copy it's Base64 output back to your notepad. Now you have 2 NEW Base64s. Use something like Notepad++ to compare to highlighted areas to see if they match, hashes kind of get lost in the fuzz! So with these two new Base64 you have, we'll craft the final JWT session. Organize this by putting the header Base64, a dot, then the payload Bas64, then another dot, and fire this request from repeater (or via the method shown by THM with your browser) with your new JWT token and you should have your flag.
hi bro good video im confused about one bit though for the last task on SSRF. Can u explain why you put the encrypted characters in the url for example instead of http you put http(%3a) and you added something similiar after 'admin'. Just wanted to know the reasoning for that as i got my url looking like yours just without the encoding and i couldnt get the correct page to load
Good question! Those aren't actually encrypted but rather encoded characters. Specifically, they are URL-encoded and assuming you are talking about 58:04, I pressed Ctrl-U after selecting the string and Burp Suite automatically encoded them for me. The colon (:) was encoded to %3a, the question mark (?) to %3f, and the equals sign (=) to %3d. Without this encoding, the request might not be parsed correctly, because at least the ? and = are special characters in the URL. The ? denotes the start of the query string, and the = is used to separate URL parameter names from values. By encoding them, it essentially means that the HTTP server will interpret them as literal ? and = characters instead.
@@Tib3rius I understand the why we do encoding in the URL. What I don't understand is why we add ?c= at the end. What does that mean and do? And why this is essential to include that at the end of the URL? Can you please explain. Thank you for the video! That was very helpful.
@@pabian3k Sure thing! So from the debug code we can see that the value of the server parameter in the URL has the value "/public-docs-k0..." appended to it, plus an integer file ID after that. Meaning that if we passed the value "127.0.0.1:8087/admin" (i.e. the location we want to get to), the backend server would instead make a request to 127.0.0.1:8087/admin/public-docs-k0.../1.pdf. There's no way to prevent that string being appended, so what we need to do is manipulate the value we pass so that whatever gets appended does not become part of the URL path. There are two ways we could do this. The first is by ending our value with a ?c= which defines the end of the path and starts a new URL parameter called "c" (can be called anything, I use c out of habit). Now the final URL will be 127.0.0.1:8087/admin?c=/public-docs-k0.../1.pdf. In most cases, the ?c=... bit will just be ignored by the server, since it's a random variable. Meaning the URL is practically equivalent to 127.0.0.1:8087/admin. The second way is to add an encoded # to the end of our value. The # symbol denotes the start of the "fragment" part of a URL, which is generally never sent to the server as part of a request. The final URL will be 127.0.0.1:8087/admin#/public-docs-k0.../1.pdf but the request sent in the backend will likely just be 127.0.0.1:8087/admin (or the stuff after the # will get ignored either way). In both cases we end up with a URL which requests the admin page and nothing else.
haha, yea I struggled on that point too. I will need to look into it more to really understand what's going on. I think I read somewhere that sometimes you need to specify the HTTP protocol (like in a full URL). I also missed changing the id to 1 from what the debugger revealed.
Appreciate the feedback! These are edits of live streams so I tend to elaborate if chat asks me to, unless it's a Monday stream which is aimed at newcomers. If you have a specific question, I can try and answer it here. :)
39:05 if you could explain how you figure out which vulnerability , how u did
, it will be really helpful for me
In this case, I literally wrote the original exploit, and I recognized the application running, so it was pure coincidence. As to how I found the original vulnerability itself, it was source code review since the app was open source.
@Tib3rius Thank you so much for your valuable information. I asked a few others, but you're the only one who responded. I really appreciate it!
I'm going through the room for the fist time and new. It doesn't even tell you to do the things your doing, it just connect to the web application and answer the questions. This room and others have totally lost me
Yes I agree, I have a general idea of what they're doing in the video because I've been studying on bug hunting and for certs but this is definitely not for beginners...
That was kinda funny, when you remember you wrote an exploit for that particular vulnerability.
39:45
I didn't understand the revshellgen setup and how it enabled the connection and etc
I kindly request and expect you're invaluable information
Hello, on the last task SSRF, i got stuck on for a while. how did you know to add the ?c= in the URL after /admin?. just a little information would be appreicated . thank you for the video , it helped me ALOT.
It's a common "bypass" for when you don't have full control of the URL being SSRF'd. I explain more at 57:00. Its just a technique I've used before.
@@Tib3rius Thank you very much, i apprecite the insights and the stream < 3
Hey Tib3rius,
So the way you completed task 20 is different than how thm tells you to do it (they say to use Developer Tools). The main issue I was having would occur when I copied the JWT token value and modified it in the encoder/decoder that thm suggest to use. After reinserting the new modified value and refreshing the page, I get the “invalid token/signature” message. I believe after watching your video that the issue is with the encoder/decoder website that try Hack me suggest to use, but I was hoping that you’d be able to validate that? Thanks for reading if you see this.
I see what the issue is. The room is incorrect. JWT doesn't use Base64, it uses Base64URL, which is similar but not the same. One of the major differences is that Base64URL doesn't use padding characters (=). If you watch my video again, you'll see that I keep having to remove %3d, which is a URL encoded =. There are other differences but most of the time you can just get away with removing the equals sign(s).
Let me know if that helps!
@@Tib3rius
I do understand what you mean but now the problem seems to be the “.” Between the encoded value. W/o the “.” the value will show a valid result. However, with the “.” included It throws the result off. I tried encoding &decoding the brackets separately and together but it doesn’t work. I also noticed after watching your video that I’m not able to edit the Values under the Inspector tab the same way you did.
I'm not really sure what you mean tbh. Could you share a pastebin of what you've tried?
I just fought this exact same problem for 2 or 3 freaking hours and I finally got through. Here's how I accomplished this, I used Burp to capture the GET of the /flag on initial login as guest. I copied the Cookie: jwt-session= value. I then deleted the signature section of the token (the last section of the dots as described in the THM Tutorial.) I then separated the Header and Payload without the Dot at the end of the section. I copied the Header into Burp's decoder, decoded it to plain. Then in the second box, highlight all of the output, set this section to encode to Base64, then edit the alg=none. Copy the output of the base64 below, including any =s. Do this same thing with the Payload section of the token, this time changing the username to = admin. Copy it's Base64 output back to your notepad. Now you have 2 NEW Base64s. Use something like Notepad++ to compare to highlighted areas to see if they match, hashes kind of get lost in the fuzz! So with these two new Base64 you have, we'll craft the final JWT session. Organize this by putting the header Base64, a dot, then the payload Bas64, then another dot, and fire this request from repeater (or via the method shown by THM with your browser) with your new JWT token and you should have your flag.
You are a life saver man
Thanks !
hi, Tib3rius, what was the additional script added here (40:55) ?
I accidentally pasted my copy buffer, but I didn't actually save the file, I just exited using :q! 😊
@@Tib3rius Thanks! I was trying to follow the steps but couldn't seem to run the script. Found out the antivirus was blocking it. Ü
hey have you got something like a community?
hi bro good video im confused about one bit though for the last task on SSRF. Can u explain why you put the encrypted characters in the url for example instead of http you put http(%3a) and you added something similiar after 'admin'. Just wanted to know the reasoning for that as i got my url looking like yours just without the encoding and i couldnt get the correct page to load
Good question! Those aren't actually encrypted but rather encoded characters. Specifically, they are URL-encoded and assuming you are talking about 58:04, I pressed Ctrl-U after selecting the string and Burp Suite automatically encoded them for me. The colon (:) was encoded to %3a, the question mark (?) to %3f, and the equals sign (=) to %3d. Without this encoding, the request might not be parsed correctly, because at least the ? and = are special characters in the URL. The ? denotes the start of the query string, and the = is used to separate URL parameter names from values. By encoding them, it essentially means that the HTTP server will interpret them as literal ? and = characters instead.
@@Tib3riusahh makes so much sense now thanks
@@Tib3rius I understand the why we do encoding in the URL. What I don't understand is why we add ?c= at the end. What does that mean and do? And why this is essential to include that at the end of the URL? Can you please explain.
Thank you for the video! That was very helpful.
@@pabian3k Sure thing! So from the debug code we can see that the value of the server parameter in the URL has the value "/public-docs-k0..." appended to it, plus an integer file ID after that. Meaning that if we passed the value "127.0.0.1:8087/admin" (i.e. the location we want to get to), the backend server would instead make a request to 127.0.0.1:8087/admin/public-docs-k0.../1.pdf.
There's no way to prevent that string being appended, so what we need to do is manipulate the value we pass so that whatever gets appended does not become part of the URL path. There are two ways we could do this. The first is by ending our value with a ?c= which defines the end of the path and starts a new URL parameter called "c" (can be called anything, I use c out of habit). Now the final URL will be 127.0.0.1:8087/admin?c=/public-docs-k0.../1.pdf. In most cases, the ?c=... bit will just be ignored by the server, since it's a random variable. Meaning the URL is practically equivalent to 127.0.0.1:8087/admin.
The second way is to add an encoded # to the end of our value. The # symbol denotes the start of the "fragment" part of a URL, which is generally never sent to the server as part of a request. The final URL will be 127.0.0.1:8087/admin#/public-docs-k0.../1.pdf but the request sent in the backend will likely just be 127.0.0.1:8087/admin (or the stuff after the # will get ignored either way).
In both cases we end up with a URL which requests the admin page and nothing else.
@@Tib3rius thank you very much!
Sir what's the purpose of c
56:21
It's a common "bypass" for when you don't have full control of the URL being SSRF'd. I explain more at 57:00. Its just a technique I've used before.
For the extra mile, it is working but elaboration would be much better than, oh it worked
haha, yea I struggled on that point too. I will need to look into it more to really understand what's going on. I think I read somewhere that sometimes you need to specify the HTTP protocol (like in a full URL). I also missed changing the id to 1 from what the debugger revealed.
Appreciate the feedback! These are edits of live streams so I tend to elaborate if chat asks me to, unless it's a Monday stream which is aimed at newcomers. If you have a specific question, I can try and answer it here. :)
@@pr0tagnist Which bit are you talking about? I can try and explain further in the comments if you have a specific question.
teşekkürler Türkiyeden sevgiler...
:)