## 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
