Tiredful API Solution

I am writing this post to discuss how to use Tiredful API and what are the intended solution for the challenges. If you are reading this post means you guys know What is Tiredful API? If you don’t know please hit this link. The idea behind usage of the app is to consume the API-end points using RESTClient app such as Postman, Curl,ARC, RESTClient firefox add-on.For demonstration I am using RESTClient firefox add-on. Now, lets get started with main motto of this post – Solution to Tiredful API challenges.

‍

Solutions

Information Disclosure

First challenge in the list is “Information Disclosure”. From the following image you can see that API end point is <host>/api/v1/books/<ISBN>/ and use valid ids mentioned .

Start your RESTClient app, issue a HTTP GET request to the end point you will get the response from server as given below

Now for getting stack trace information try to manipulate the ISBN values, after trying different character sets you will get the stack information for the ISBN value containing Capital Alphabet.Following is the solution for information disclosure challenge.

Insecure Direct Object Reference

Now moving on to next challenge “Insecure Direct Object Reference”. From the following image you can see the API end point is <host>/api/v1/exams/<exam_id>/. According to the challenge user “batman” has took exams with exam id are MQ==, Mg==.Lets try to access the API end point.

On analyzing the exam ids we come to know that all these ids are base64 encoded. So to get the scorecard of another user we need to manipulate exam id and encode it in base64 form. According to challenge description authentication is needed to access the scorecard, so in order to get access token navigate to user token link and obtain an access token for user “batman”.

Use obtained access token to consume API end point as shown in the image.

Now try to access the another user’s scorecard, iterate over the exam-id parameter and don’t forget to use base64 encoding before issuing the GET request to API end point. You will get the scorecard of another user by using exam id 56(NTY=), 93(OTM=).

Access Control

According to challenge description, our aim is to execute an operation which should be allowed only to admin user.In this challenge to exploit access control flaw we will consume <host>/api/v1/articles/<article-id>/ end point.

So first try to access API end point in normal way and analyze the headers sent by the web server, you will find the API end point supports the DELETE HTTP method also.

Now try to issue a DELETE request to the API end point and analyze response from the application. In the response body you will see application responded with message “isAdmin” missing.

Now by the name of non standard HTTP header, we can deduce that the header is accepting boolean value. Set the “isAdmin” header with “True” and issue a DELETE request and you will be able to delete a resource which should not be allowed to anonymous user.

Throttling

The aim of this challenge is to force the server to respond with 429 response code (Too Many Requests). We need to use <host>/api/v1/trains/ API end point with Post body(Use Content-Type header with application/json value). Solution of this challenge is straight forward.Issue 10 requests to the API end point with anonymous user (without Authorization header) and 20 requests with authenticated request(with Authorization header).

Following is the throttling solution for authenticated user.

SQLite Injection

The aim of this challenge is to figure out database table names using SQLite Injection, since the app is using SQLite backend the syntax and table names will differ from our conventional SQLi on MySQL servers.

First try to consume API end point in a normal way, we will be consuming <host>/api/v1/activities/ with POST body(Use Content-Type header with application/json value). The POST body will contain “month” parameter.

Application will respond with activities stat for POST request, analyze the response body and try to deduce number of columns used in query. The response body contains 6 name-value pairs which means column used in the embedded SQLite query is 6 or more than 6.   Now try to append SQLite query to the value of “month” parameter and observe the result you will get the table names in the response body. Following is the payload used to extract table names from database. {“month”: “1 UNION SELECT 1,2,3,4,5,6,name FROM sqlite_master WHERE type=’table’;”}

Cross Site Scripting

Impact of the cross site scripting attack will depend on the client. Successful exploitation of cross site scripting flaw will be totally dependent on how client is processing data send by the server. The aim of this challenge is to find out which of the paramters mentioned in the POST body is accepting the cross site scripting meta characters. According to challenge we need to use <host>/api/v1/advertisements/ API end point with GET method to retrieve list of classified posted and POST method (Use Content-Type header with application/json value) to create a new classified.

  Since the challenge needs an authenticated user, so first obtain an access token for any user from user token page.

Now first create an advertisement with valid set of input and observe which of the parameters are accepting string values.

Now provide “<script>alert(‘solution’)</script>” as input to all the suspected parameters. In order to check if classified is created with cross site scripting meta characters, issue a GET request to the API end point and observe the result.

Following is the image listing all the classified created.

  These are all the intended solutions for the challenges, there are other ways also to exploit the vulnerabilities since the application is intentionally designed broken app. Please feel free to write us on info [at] payatu [dot] com, if you have any challenge/vulnerability idea in mind to include in this app. Happy hacking 😁

‍