Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

The author of this post was looking into a private program that offered a network monitoring solution. While running some basic tests and clicking around through the app, they noticed an endpoint that sent a full PDF copy by email of a web page.

In the request, there is a query parameter called location that has a full URL path inside of it. Since this was an authenticated endpoint, they assumed this was a SSRF bug waiting to happen, where only the PATH was controllable; the domain was being set somewhere else.

What can you do while only controlling the path? There is a well-known trick that uses the @ in order to change the domain of the request. When an @ sign is used, the FIRST part is the username/password is the data after the @ sign becomes the domain. So, by adding this character, such as example.com|my_path to example.com|@my_domain.com| will change the domain used.

The author of this post then starts getting complete screenshots, via email, of whatever page they want. More importantly, this is on the LAN side of the network and has authentication on it. We need impact now though! They tried things on localhost, but nothing came up. So, they searched Github and other places for internal domains only to find an instance of Redash running.

For whatever reason, the credentials were being auto-saved into the login page of Redash in plaintext. According to DayZeroSec, it is fairly common that credentials are auto-filled on internal sites for convenience.

While manually looking for more things, they found an instance of puppet. This is a software used to manage the infrastructure of server configuration and other things. By looking at this, they were able to find all other domains on the internal network including kibana, grafana and many other things.

The author then have an extremely clever idea: the request being made takes a screenshot of an authenticated page, has a user provided email and is a GET endpoint. What does all of this mean? It is the perfect candidate for a cross-site request forgery (CSRF) attack!

The CSRF bug is absolutely amazing! Since this makes an authenticated internal request as this user, requests for settings and other things can be taken. To make this even worse, this can be done blindly and at scale.

But, here's the final icing on the cake: if we use the original @attacker.com trick from before, we can make a request to our own server. Now, this request will have the header X-CH-Auth-Api-Token attached to it, which allows us to have the API key of the organization.

I had never thought about using the @ symbol with domains. Since it is common to only control the path of a request, I will keep this in mind! Additionally, the two ways they went about exploiting this were amazing; either one of these was of horrific impact.