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"
When trying to access it, the api 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).
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 endpoint we have access to as an anonymous user is the public endpoint but their is nothing interesting in it.
But 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".
By doing this, we see that their is no authentication required to access the endpoints on the v1.
And we find the first flag by sending a GET request to the endpoint "/api/v1/confidential/missions".
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.
Well, for the third 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 if 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 the last flag !