API‐Versioning ‐ Solutions
First of all as we land on a 404 error at the webroot, we have to check for technologies used and try to fuzz directories. By doing this, we discover a directory named "apidocs"
By using the Seclist's API scpecific wordlists, we can also discover an api endpoint "/api/token" that we will talk about later.
When trying to access it, the api documentation, the server ask for a basic authentication.
Basic authentications aren't protected against bruteforcing so by guessing or bruteforcing the authentication, we easily discover the weak credentials (guest:guest). API2:2023 - Broken Authentication
Once logged in, we have access to a Swagger API documentation that details the different endpoints of the api and their usage.
Now the first thing to do is simply to try all the endpoints.
By doing this, we understand that the only endpoints we have access to as an anonymous user is the public endpoints but their is nothing interesting in it.
First flag (API4:2023 - Unrestricted Resource Consumption)
In fact, not really, because one of the two public endpoints say that the API use a third party service that can lead to paid requests if the daily limit is exeeded.
Let's check if a rate limit mecanism protect against this situation. Send 26 requests to the endpoint and get the first flag.
Second flag (API3:2023 - Broken Object Property Level Authorization)
If you remember, the lab name is "API-Versioning", maybe we should try decreasing the api version and see if the v1 haven't already been deactivated. So we can test the same endpoints and replace the "v2" in the url by "v1". (API9:2023 - Improper Inventory Management)
By doing this, we see that their is no authentication required to access the endpoints on the v1.
And we find the second flag by sending a GET request to the endpoint "/api/v1/confidential/missions".
Third flag (API1:2023 - Broken Object Level Authorization)
By using the same technic, we can try to delete a crew member from a mission. If we check to the response of the "/api/v1/confidential/missions" endpoint, we can see that the rocket of mission with the ID 7 haven't already been launched. So it could be really impactful if we can delete crew members from it.
If we check the prerequisites of the endpoint, we know that it takes an ID (the id of the mission in the url) and a memberID which is the UUID (Universally Unique Identifier) of the crew member. It would have been almost impossible to guess such information if the first vulnerability didn't leaked it.
So we have now all the information that we need to delete a user. To do so we only have to send a DELETE request to the endpoint "/api/v1/confidential/missions/7/crew" that contain in his body the parameter "memberID" with the UUID of the member to delete as value.
Fourth flag (API7:2023 - Server Side Request Forgery)
Well, for the fourth flag, we have a hint in the Swagger documentation that say us that the endpoint "/api/v2/missions/{id}/communications" contain a deprecated feature that we can be requested through a PATCH request.
But this request require a parameter that is hidden
Ok, so first, let's check if the API response for the v1 is too verbose and give us information to exploit the endpoint. As the endpoint wait a json payload we can try sending something like {"test":"test"}
If we try on a mission ID where the rocket isn't launched, we get an error message saying us that the rocket isn't launched.
It means that the endpoint is not used for missions that haven't started. So we can try on a mission that have started. Let's try the mission 1.
No luck, the error is a generic code 500 for an Internal Server Error.
The API doc say that we should try fuzzing the endpoint. Let's try, for this you can use this wordlist
Here we have an interesting behavior. it seems that the parameter used is the parameter named "callback". (It was also easily guessable as it is the same that is used in the missions communications data).
Now we know that the endpoint need a callback url. So let's try to configure an URL under our control as callback for the API.
A simple url pointing to our server give an error saying that the URL isn't valid. It may mean that the server use a whitelist to check the callback URL.
by default, the communications are transmitted through the internal URL "https://internal-communications.example.xyz:1234/satellite/messages".
Let's try to bypass the check with a simple trick using the character '@' to make the server validate the check while the callback will only consider that "internal-communications.example.xyz" is a username transmitted to our host.
Success ! Now check your server logs and see that he received a POST request containing an unreadable message.
If you remember, in the missions information, some information about the communications are leaked, and the encryption key and iv of the AES encryption are a part of it.
So we can try decrypt the message by using this information. For this you can use the CyberChef web application.
Well done, we found a new flag !
Fifth flag (API2:2023 - Broken Authentication)
For this flag, remember that we found an interesting api endpoint (/api/token) while fuzzing. This endpoint isn't documented in the API documentation so let's analyze it.
First, it seems to accept only POST requests.
So let's check what happen if we enter a random json payload
Ok so, now we now that the endpoint expect an email, if we look closely the endpoint name, we can understand that the endpoint must be used for user tokens. And we have luck because the API documentation give us a potential user email in the "Users" section.
Let's try to do something with it.
Nice, apparently, the endpoint doesn't check for any password and give us the jwt associated with the user email.
Now let's check if we can get the user information via the /api/v2/users/me endpoint.
Flag found !
## Bonus flag (API8:2023 - Security Misconfiguration)
Being able to account takeover is cool, but we only have one account and it have a very limited "user" role. It could be interesting to escalate privileges, for this we can try to exploit the JWT.
The server seems to have some checks as we cannot change the jwt content.
"None" algorithm doesn't work.
Embedded JWK, HMAC key confusion and other bypass methods as well...
But now that we know that the API already contain some weak and default credentials, maybe we can find the JWT secret.
Let's try to crack the JWT with hashcat and a specific wordlist from Seclists.
Got a hit!
Now that we have the secret, we can forge a valid JWT with the role "admin".
And check if the privesc worked with the /api/v2/users/me endpoint.
Well done :)