OWASP API Security Top 10–2

TL;DR Walkthrough of TryHackMe’s OWASP API Security Top 10 Part 2 room.

A full list of our TryHackMe walkthroughs and cheatsheets is here.

Background

For some reason known only to God, THM decided to require NLA on some of their VMs as of 23 Feb 2024. This caused me to get weird errors attempting to connect via xfreerdp or rdesktop from my Kali VM.

After a bit of Googling and getting nowhere in Kali I simply dropped THM’s *.ovpn file into

C:\Users\<username>\OpenVPN\config

on my Windows 10 Pro host OS on my refurbished Dell Latitude 5580 laptop. Once I did this I was able to RDP into THM’s VM successfully.

That was actually the most complicated part of this room. The rest was really straightforward. All I did was copy/paste and then tweak the same Invoke-WebRequest GET and POST requests I used in the OWASP Top 10 Part I room. More practice is always good.

— — Task 1 — -

xfreerdp /v:10.10.174.34:3389 /p:Administrator /p:Owasp@123 /dynamic-resolution

rdesktop 10.10.14.139 -u Administrator -p Owasp@123 -f

If neither of those works for you due to NLA then from Windows

mstsc /v:10.10.14.139

— — Task 2 — -

Is it a good practice to blindly insert/update user-provided data in the database (yea/nay)?

Nay

Using /apirule6/user_s, insert a record in the database using the credit value as 1000.

No answer needed

What would be the returned credit value after performing Question#2?

50

$postParams = @{name="Bob";username="bob_mht";password="#ge*byA@35U6";credit="1000"}
$headerParams = @{"Content-Type"="application/x-www-form-urlencoded"}
$Result = Invoke-WebRequest -Uri "http://localhost:80/MHT/apirule6/user_s" -Method Post -Body $postParams -Headers $headerParams
If($Result.Content -ne "$null")
{
$Result.RawContent
}

— — Task 3 — -

Is it an excellent approach to show error logs from the stack trace to general visitors (yea/nay)?

Nay

Try to use the API call /apirule7/ping_s in the attached VM.

No answer needed

What is the HTTP response code?

500

What is the Error ID number in the HTTP response message?

1401

$Result = Invoke-WebRequest -Uri "http://localhost:80/MHT/apirule7/ping_s" -Method Get
$Result.StatusCode
$Result.Content

As one will notice in the screenshot below, I did not get a 500 in response, I continued to get a 200 and error details. THM may have screwed up their API.

— — Task 4 — -

Can injection attacks be carried out to extract data from the database (yea/nay)?

Yea

Can injection attacks result in remote code execution (yea/nay)?

Yea

What is the HTTP response code if a user enters an invalid username or password?

403

Note that we still get a 200 response following the 403 though:

{“success”:”true”,”authkey”:”oWsZ8vWNuECjCAiZVJHOzsNsNH08zWRZ”}

I ran the one a couple times trying the SQL injection technique, even putting “Invalid” as the password. I still got a 200 StatusCode and an authkey in the response. I think THM might have screwed up their API.

$postParams = @{password="Invalid";username="admin"}
$Result = Invoke-WebRequest -Uri "http://localhost:80/MHT/apirule8/user/login_v" -Method Post -Body $postParams
$Result.StatusCode
$Result.Content
#$postParams = @{password="' OR 1=1 --'";username="admin"}

— — Task 5 — -

Is it good practice to host all APIs on the same server (yea/nay)?

Nay

Make an API call to /apirule9/v1/user/login using the username “Alice” and password “##!@#!!”.

No answer needed

What is the amount of balance associated with user Alice?

100

What is the country of the user Alice?

USA

$postParams = @{username="alice";password="##!@#!!"}
$Result = Invoke-WebRequest -Uri "http://localhost:80/MHT/apirule9/v1/user/login" -Method Post -Body $postParams
$Result.StatusCode
$Result.Content

— — Task 6 — -

Should the API logs be publically accessible so that the attacker must know they are being logged (yea/nay)?

Nay

What is the HTTP response code in case of successful logging of user information?

200

$Result = Invoke-WebRequest -Uri "http://localhost:80/MHT/apirule10/logging" -Method Get
$Result.StatusCode
$Result.Content

— — Task 7 — -

No answer needed

Summary

Overall this room was really just more practice on the same techniques used in Part I.

However the point is important:

• Webapps are by definition public facing.
• An attacker can send that webapp any input they want, regardless of what form the webpage presents the casual user.
• Attackers will find any directories or legacy webapps that are still accessible if you forget about them.

Therefore server side input validation is a best practice.

References

Invoke-WebRequest POST with parameters: https://stackoverflow.com/questions/17325293/invoke-webrequest-post-with-parameters

Invoke-WebRequest: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/invoke-webrequest?view=powershell-7.4