Abusing corporate URL shorteners

Home > Blog > Misc

Abusing corporate URL shorteners


URL shorteners are great! They allows users to turn a 200 character url into something substansially less. It's ideal for those situations where you are limited on text space but need to use a link - for example sms or tweets. Whilst convenient, the wrong implementation could leave a business exposed. In this post I will share my experiences with URL shorteners and cover 3 different attack scenarios across 2 different implementations.

#1 - Accessing Internal Statistics

The first two vulnerabilities were reported to an undisclosed company via Hacker One. As part of the reconnaissance for this program, I stumbled across a URL shortener which appeared to be custom made rather that using a third party service. This seemed to be used internally across the business as the majority of collected URLs redirected me to a login page. However, by visiting an invalid URL the application would land on a broken 404 page. Inspecting the source code exposed multiple endpoints that allowed authenticated users to add/edit/delete URLs as well as view statistics. All endpoints required authentication with the exception to three statistical endpoints. They included stats on clicks, browsers and platforms used for each link..

Here's an example payload

var xhr = new XMLHttpRequest(); var result = ''; var url = "/stats/clicks"; xhr.open("POST", url, true); xhr.setRequestHeader("Content-Type", "application/json"); xhr.onreadystatechange = function () { if (xhr.readyState === 4 && xhr.status === 200) { result = xhr.responseText; console.log(result); } }; var data = JSON.stringify({"url": "a", "range": "all"}); xhr.send(data);

The response would look something like

{ "labels": [ "July 2017", "January 2018", "July 2018" ], "datasets": [ { "data": [ 517, 274, 72 ] } ], "totalClicks": 863 }

Whilst the information gained was not sensitive it highlighted a misconfiguration that needed to be addressed. This vulnerability was worth $500.

#2 - Accessing Sensitive Documents

Soon after finding the first vulnerability, I found this URL shortener allowed its users to create custom URLs. After a small amount of time brute forcing these URLs e.g. http://short.url/r/private, http://short.url/r/test, http://short.url/r/secret etc, it wasn't long until I stumbled across multiple documents labelled as sensitive. These documents ranged from customer contracts to internal rotas, network diagrams and more.

The customer promptly removed all associated documents and awarded a total of $2000 - This was made up of $1000 for the report + $1000 bonus during a promotional period.

#3 - URL Scraping

Another great example of abusing a URL shortener is one I reported to Coral Casino back in 2016.

One day I received a text message that said [USERNAME], stake £10 on any Hulk slot to get 10 FREE spins instantly - http://cora1.co.uk/xyzabc T&Cs apply text STOP to 82211 to optout Clicking on this link would redirect me to a promotion page that contained my username and mobile number in a parameters of the URL.

The domain https://cora1.co.uk uses a URL shortening service provided by Bitly, so by modifying the URL and appending the plus symbol I was able to see a statistics page of the link. E.g. https://cora1.co.uk/xyzabc+

This itself was not much of an issue, the problem is that I was able to see the user who posted the URL. If we go to the users profile e.g. https://bitly.com/u/user_xxx it would show that a total of 169k links have been created. If I were to view the source of the page and search for the parameter MOBILE_NUMBER= this will give me a UK mobile number who I know is a member of Coral. This could then have be exploited by creating a simple site scrapper, looping through each page of the employees bitly profile to scrape the customers mobile number

Whilst Coral never had any vulnerability reporting route or any bug bounty program in place, I managed to contact the right person in the security team who ultimately addressed this issue by marking the links & the users bitly profile as private. Unfortunately, the business never followed up on this and communications quiet.

Final thoughts

If you're an ethical hacker who stumbles across a URL shortener used by your target. Be sure to try these 3 attack scenarios:

  1. Bruteforce - are the urls predictable? Use a dictionary attack on the URL to capture the redirect location for further review
  2. Scrape - do the redirects include personal information? Are the URLs predictable? Harvest the data
  3. Authentication - is this a custom made app? Check any exposed endpoints in the source are correctly validating sessions.


about me

30 year old multistack developer & security researcher based in Gosport, UK. I like to blog about interesting vulnerabilities I come across, when allowed 🙄