write-ups-challenges-2023-2024/chatty/SOLUTION.md
2023-11-28 16:24:59 +01:00

2.2 KiB

Difficulty

How To Solve

After chatting a bit with the chatbot, you will notice that it starts posting messages containing links.

For these links, the chat platform will create a preview of the page contents behind that link. Inspecting the network traffic of the application reveals that the previews are already included in the replies from the chat server, which means that the previews are constructed on the server-side and not on the client-side. This is where a classical mistake is made by the developers of the chat application: they do not filter which URLs can previewed in the chat application. Consequently, the chat server will make a request to that URL regardless of the destination, this could even include requests to internal services.

At this point, it is not entirely clear which internal services might be vulnerable. However, when first launching the chatbot it told us that it supports a "\whoami" command. This reveals that the chatbot is running on 192.168.122.1, and if we are lucky we can also find other services running on the same subnet.

By brute-forcing our way through, we find that most IP addresses return empty previews, meaning that they could not be reached by the server. However, one IP address, 192.168.122.233 returns a peculiar result: "Restricted URL". So it seems that the developers were not that stupid after all...

I wonder how this filter has been implemented. URLs are notoriously complex. They contain a Scheme, a host to communicate with, a port, a path and optionally some query parameters. However, they can also contain information pertaining to authenticated requests. For example the following URL:

http://admin:admin@example.net/path

sends an authenticated request to example.net with username and password admin . Most web servers accept such requests, even though the request does not have to be authenticated.

So lets try to prefix our 192.168.122.233 URL with this information.

http://admin:admin@192.168.122.233/

And we found the flag!

It turns out that the developers used a regular expression of the form: http://192.168.122.233/.* to filter out restricted URLs, which does not match our authenticated request.

Flag