An XSS Road Trip (Journey Through The Web #1)

I think one of the reasons I love investigating a websites security is the adventure itself. The web is a big place and no two websites are the same which is the main reason why I like reading other peoples stories about their findings. There are so many hackers out there who show us how they trick systems and it’s exciting to learn how they did it, even if the vulnerability itself might be simple.

For this reason I have decided to document a part of my findings here in a kind of series. Today there are a handful of XSS vulnerabilites waiting for us.

Minecraft Server (1.000.000+ unique players)

Just browsing through the web, I decided to take a look at some minecraft server websites. The one I’m writing about here recently celebrated their millionth user. On top of that, they do have plans for a future bug bounty program. Sounds good, a lot of users to protect and they would probably answer bug reports.

Their website contains multiple links to various subsystems, like forums and a link to their buycraft-page, which is a popular hosted shopsystem for minecraft servers. I decided to focus on their probably selfmade systems.
One of them was a statistics page, on which you can get some insights into their users like kills in specific game modes, votes for their server and more. A typical mistake would be to display an error page if a non-existing username has been entered with a message containing the input username without encoding it (i.e. “The user testtesttest does not exist”).

This did not work, because they just redirect back to the search in this case. Another system was a ban/kick/mute log. Same attempt there, this time you basically see the same page for existing and non-existing users. If the user hasn’t been kicked, muted or banned yet, they just don’t display any log. But the non-existing username will be displayed too, without encoding.

So the payload would be as simple as the following:

?user=thisdoesnotexisttest"><script>alert(‘XSS’)</script>

It will also be executed multiple times. They don’t just render the username right into the page as a heading, they retrieve the players skin dynamically from an API.

Their code probably looks like this:

<img src="https://[censored]/<?= $GET['user'] ?>">

Which will be parsed to:

<img src="https://[censored]/thisdoesnotexisttest"><script>alert(‘XSS’)</script>">

So how critical is this vulnerability in this particular case?
I could not find a cookie based session user system on their main domain at first. Their forum session cookie is limited to the forum subdomain. So I thought they are using a small, maybe even selfmade CMS for all of their content on the main homepage.

I simply added a /login to the domain and received a warm welcome from their admin login.

That’s enough, I tried to report it. Didn’t find an e-mail address on their website and joined their Discord. Wrote a message in a public channel asking for the right person to address an issue like this to. Regular users said a PM should be just fine.

So I contacted one of their staff. No answer. Tried another user after that and… You know. Trying to report it to them somehow. No response yet, probably they won’t answer at all.

Didn’t they read it? I personally don’t really think so, especially because they 404'd the admin login shortly after.

So the vulnerability is still out there, which is why I’m not adding the server name, demo video or screenshots here. Sorry for this dry read.

T-Mobile Austria

In case anyone missed the glorious and sad Twitter thread about T-Mobile Austria saving their customers passwords in plaintext and why it’s not a problem. Spoiler: Their security is amazing (according to them).

After the first XSS screenshots appeared on Twitter, I wanted to take a look at their website aswell. I was pretty lucky on finding this vulnerability, because finding the vulnerable URL has to do with clicking the right elements and paying attention.

On the right site of their website, there is a small help overlay, which will be completely revealed after clicking on it. The first button has a link on it:
https://business.t-mobile.at/grossunternehmen/kontakt/?ref_=Pool-Tarife#/email

Pay attention to the GET-parameter. I changed it to something like ref_=testtesttest and searched for testtesttest in the source afterwards. It has actually been rendered into the source as a value for an input field.

<input value="Allgemeines Kontaktformular testtesttest" name="page_referer" type="hidden">

Changing the parameter to ref_="><script>alert('XSS')</script> did result in an output similar to the following:

    <input value="Allgemeines Kontaktformular">
    <script>alert('XSS')</script>" name="pagereferer" type="hidden">

I tried to report the vulnerability but did not receive an answer yet. However, I couldn’t reproduce the issue anymore after some days, so I think a lot of people found and reported that vulnerability, allowing me to present a demo video below.

Deutsche Presse-Agentur (dpa) Newsportal

Deutsche Presse-Agentur GmbH is the largest press agency in Germany, founded in 1949. Based in Hamburg, it has grown to be a major worldwide operation serving print media, radio, television, online, mobile phones, and national news agencies. News is available in German, English, Spanish, and Arabic.

Most german police departments publish their press releases on the DPA newsportal. After a car drove into a crowd in Münster, I wanted to read the press release. When searching for Münster on top of the page, you see suggested categories, that fit your search. The category link is: https://www.presseportal.de/r/Münster

Basically just like a subreddit on reddit. I couldn’t resist and tried to add anything to the URL (just as in the first case in this article) to see if they display a blank page with the non-existing category name I entered. They do.

The rest was simply adding my XSS payload (url encoded this time, since this is not a GET parameter and adding a slash as in </script> would make their page say 404, because it is a different page then).

Example payload:

https://www.presseportal.de/r/M%C3%BCnstertest%3Cscript%3Ealert('XSS')%3C%252Fscript%3E

I reported the vulnerability through their contact form and received an answer some days afterwards. They wanted to get back to me when it’s fixed. The vulnerability has been fixed after around five days, at least I could not reproduce it anymore, they no longer display the input on the 404 page, they also have not responded to me yet.

Below is my Deutsche Presseagentur (dpa) XSS demo.

Instagram Fullsize Profile Picture Viewer (instadp.com)

Well, I “somehow” landed on their website and had to satisfy my curiosity.
I tried a simple injection via parameter as in the first and previous case in this article and my payload has been executed multiple times. Pretty simple, but the impact was interesting. I could not find a cookie based session user system again.

But they are saving their users search history in a cookie. They probably use the cookie in order to show the history in their burger menu.

My history cookie (please don’t tell Lady Gaga):

[
  {
    "id": "184692323",
    "username": "ladygaga",
    "picture": "https:\/\/scontent-frx5-1.cdninstagram.com\/vp\/c007285e1d9707df62af135295143838\/5B690C49\/t51.2885-19\/s320x320\/26072499_1864575183834016_21233502267637760_n.jpg",
    "link": "http:\/\/instagram.com\/ladygaga\/"
  },
  {
    "id": "44291",
    "username": "test",
    "picture": "https:\/\/scontent-frx5-1.cdninstagram.com\/vp\/7bc2392e741fa139623a80db18d34fc3\/5B5C1AC3\/t51.2885-19\/s320x320\/20969214_1233408386771253_3371551294455021568_a.jpg",
    "link": "http:\/\/instagram.com\/test\/"
  }
]

Imagine sending instadp.com to a friend or co-worker, wait some weeks and send him a special link including a XSS payload, which will send his/her cookie to your server.

That could be awkward.

I reported it to them and checked the vulnerability again less than 24 hours after that. Seems like they are redirecting to the homepage now when the URL includes characters like <. Would it hurt to thank me for reporting this or at least answer my e-mail at all? It’s incredible how many people behave like this. But that won’t stop me, at least it seems to be fixed.

Below is my instadp.com XSS demo.

Thanks a lot for reading! I’m still very new to writing about my findings.
Do you have any suggestions for the next part of this series?

Feel free to leave a comment!

Author: Paul Dannewitz
Image: Rich Cullen