In this blog post I will be explaining how I found an open redirects issue in SoundCloud’s redirection system, which could have been abused by attackers to mislead users and maybe phish their credentials or trick them into performing harmful actions.
So it was a rainy day and I was just getting home after a long day working on university assignments (I have to mention that to unload it :S), when I noticed that I have received a message from SoundCloud informing me that a user likes a track I previously posted on my profile.
I started looking around for links and noticed an interesting link that uses a GET parameter called “url”, which clearly works as an intermediate medium that redirects to whatever that parameter points to. The link looked like the following (Follow the link, the track is cool for those who like Trance and EDM 😉 ):
So I immediately started messing around for a while to see if it’s well protected against open redirects. After trying for like 10 minutes, I concluded the following points (URL shortened for simplicity):
- Anything after the domain name which is not a / is not accepted and a 403 page is returned, so http://soundcloud.com/-/t/click/postman-email-notifications-sound_like?url=https://soundcloud.com.eg for example or http://soundcloud.com/-/t/click/postman-email-notifications-sound_like?url=https://soundcloud.comm will not work.
- We can actually redirect to https://whatever.soundcloud.com, but that would be pointless because we need to find a subdomain takeover first, which is clearly a bigger issue in itself anyways.
- Using any scheme before the domain name is accepted, and by “any scheme” I mean that strukt://soundcloud.com would cause the server to happily issue a 302 redirect to strukt://soundcloud.com.
- The string supplied to the “url” parameter cannot start with a dot.
So with all the givens (disregarding the second point as it’s not that useful in our context), I was wondering how can I leverage these bits of knowledge into bypassing the protection in place.
Eventually, a simple but often interesting thought came to my mind, what would happen if I try to inject CRLF characters somewhere in the value of the “url” parameter? , maybe I can achieve a different behavior or at the very least an error that would guide me further. So I started with %0a (LF) and it was completely ignored by the application, the redirect was made to https://soundcloud.com.
I then tried with %0d (CR) and, to my surprise, I received a different response than the first one.
The value injected after the %0d character is directly appended to the string “http://soundcloud.com”, I tried to then change whatever is after the CR character but it seems like it’s still checked by the back end code. But wait a second !, we know that we can substitute the scheme of the URL we are supplying with whatever we want, right ? Well, yes, we can actually supply any string we want before the “://soundcloud.com” part. So the following is acceptable:
And the following are the request and response of the above:
And voilà!, a redirect to http://soundcloud.comevilsoundcloud.com//soundcloud.com is issued by SoundCloud’s server with no complaints.
Thanks for reading, see you in another write up