This course focuses on API Security and explains the kinds of vulnerabilities that we can find inside APIs, how to exploit them, and how to secure them as well. These skills will allow you to obtain bug bounties from vulnerabilities and also protect your own APIs as well.
Hi within this lecture we're going to take a look at the API4, challenge4. So, if you come over here to API4 it says lack of resources and rate limiting. Okay, there is no rate limiting. So, I immediately think that we're going to be doing some kind of brute-forcing or dictionary attack or something like that. But also it says that we believe OTPs are great. So, which means that this is going to be something about OTP. So, let's see what an OTP is. Over here we're going to give some mobile application or mobile number. It's just a phone number. Okay, mobile number. And then we're going to do a post which will verify the OTP. So, OTP stands for one-time password, so it's a kind of multi authentication. So, you log in and you get an SMS message or a message from a service to your phone and you give that number, give that four-digit, six-digit number to the login system so that you can log in. So, this is a multi-factor authentication or one-time password. Over here after we do the OTP we can get the user. So, this is pretty obvious. Of course, we're going to have to take a look at the postman as well to see what kind of things that we're going to do, but over here we have the clue, we have the hint. It says that we believe OTPs are great, but let's see what we can find about OTP. So, over here we're already done with the API3 & API2.
I'm going to go ahead and try to log into this phone number. Of course, this is not my phone number, this is just a regular example that is given to us. But anyway even if we give the regular or our own phone number, I don't think we're going to receive any message and that is not the case. As you can see, if you send something, if you send a request like this you get a message, you get a response saying that, everything is okay but your four digital OTP sent on mobile number. So, of course, this doesn't belong to us. And the idea over here is that can we find the OTP or can we find one-time password of another phone number so that we can hack them. So, if you come over here to verify OTP as you can see, we already have this. Okay, we already have these headers and bodies; we don't have to change anything over here. Just we need to find the four-digit number. If you find it, then we're going to get an authentication key back. So, easy I'm just going to send this and here you go. It says that invalid OTP. So, what I'm going to do, I'm going to try and see if this is actually wrong OTP, wrong password or this is invalid like I'm going to send something like 8,000-7,000. I'm going to see if we get any different response like this.
Okay, so can it be any four-digit number or it goes up to 2,000 something like that. But as you can see we don't get any different thing. We already have seen this, we always get invalid OTP, which means that we're not getting the authentication token and also which means that it can be anything four digits. So, I'm taking a look at the logs as well to see if there is something new or if there is something wrong with each request that I have sent, but it doesn't seem so. Since we cannot find any more clues or hints, I believe what we have to do, we have to try and change this OTP starting from 1,000 and ending in 9,999 and just brute force the whole possibilities. So, what I'm going to do as you might guess, is to send this request to the Burp Suite Intruder. If we manage to do that then it's okay, we're going to get the OTP eventually. So, I'm going to come over here to settings and change The Proxy one more time. So, remember, we have to configure this proxy and the Burp Suite Proxy in the same way. So, I'm going to open the Burp Suite. I'm going to turn the intercept on, and I'm just going to send OTP one more time. So, once I send that I will just get this over here, and of course, I'm going to send this to intruder as we have done before and we already have the host and port. Now in the positions if this is not labeled for you, then you're going to have to clear and edit yourself and make sure that this is added as a parameter to be changed.
Okay, and by the way, right now I'm using the Attack Type: Sniper. We have used Pitchfork before, but remember I said that if we had only one parameter that we would use sniper. Now, this is the time we can use the sniper; we already have chosen it, we only have one parameter, so we only have one payload list. And I'm not even going to create that list. I can just come over here and choose numbers for example. And just state that, indicate that it will start from 1,000; it will go up to 9,000 or 9,999. Okay, so it will just step one at a time and here you go now it will actually try 8,999 times, which is a lot. Okay, and the idea over here is that we can leave this by the way, we don't have that kind of thing right now, the idea over here, I'm going to start the attack. Of course, it's going to take a lot of time. It will just try and try and try but the idea over here is that the backend or the API should have anticipated this and should have rate-limiting or some kind of protection mechanism against us. So, over here it appears that it doesn't have that and we're not getting any kind of 500 or any other error messages. We are trying and trying, of course I believe we couldn't find it yet, but we will eventually. So, what I'm going to do, I'm going to pause the video because it's going to take so much time after I find the relevant OTP. I'm going to show it to you guys. Here you go. Now I found the OTP in here, which is the request number 872, and it appears that the OTP should be 1,872. So, I really suggest that you don't wait until this is done in your computer as well, since this is just an example if you have understood why we're doing this, then it's okay, you can try with this number, but if we come over here in the response, I already have the key as you can see.
Now I can send this to repeater in order not to lose the packet. So, right-click it and just send it to repeater, and here you go. Again, I can just send it over here and I can get the success true over there. So, what I'm going to do, I'm going to take that number and use it in my postman. So, let me come back and of course, here you go. It's still sending the request. So, I'm just gonna turn off the proxy over here, turn off the intercept. I'm going to bring this down and here we go. So, we can just send this from here as well or we can go to get details and change the authentication token whatever you want. I'm just going to send this and here you go. We already have the key so we can copy this key and use it in the get details. But I believe it's already saved in the postman because of these tests. So, I'm going to come over here and just go to headers and here you go, yeah it's saved. If it wasn't, I can just delete it and just paste it over there. But here you go, once I send this request, I get the flag because now I'm able to reach it. So, the idea we're here is that even though the phone number is not mine; I brute force the OTP since it was four digits, it was possible to brute force because why not? Even though we had the community version.
Okay, we had the community version. We waited a little bit but, we got it done. If we had the pro version of the Burp Suite then it will take so less time. Okay. So, over here we managed to give the OTP and we managed to get the authentication token so that I can reach the id 1, the John or something like that. We don't even know the John; we don't even have that phone number. So, if you don't have rate limiting over here, if you don't have rate limiting as you can see, someone can easily grab the API key or the authentication token for any user and can reach their data or use the system as if they were that person. So, that was it. That was the challenge of API4, and it's a good case to understand the multi authentication factors, the OTP factors, they are considered to be safe if they are implemented in a proper way. Unless they have this kind of vulnerability, they are safe. So far so good. Now we're going to stop here and continue within the next lecture to solve the API5 challenge.
Atil is an instructor at Bogazici University, where he graduated back in 2010. He is also co-founder of Academy Club, which provides training, and Pera Games, which operates in the mobile gaming industry.