Lack of URL redirect validation for 3rd-party app

Johnfiel
3 min readApr 8, 2021

Hi again!

So, here is one more write-up on a simple-yet-tricky Open Redirect bug I found on a private application.

I once submitted an open redirect vulnerability for this specific target (let’s call it site.com) a few months back and confirmed that the bug has already been fixed — that’s what I thought, at least.

My target site.com is using a 3rd-party Live Chat application (livechat.com) and used as a widget on their application. The site.com is redirecting its users to their Live Chat Channel whenever the chat icon is clicked, and the endpoint site.com/redir?url= is responsible for that.

I decided to have another look for any open redirect vulnerability. The target is returning an Error 404 whenever you put any malicious value for the URL parameter — this was the previous bug they had, which I thought was fixed.

Their chat widget has the link:

site.com/redir?url=https://direct.lc.chat/<someID>/<anotherID>

Do you see something interesting? Do you already have an idea of how to exploit this? :)

I tried playing a bit with the URL for any possible path traversal.

site.com/redir?url=https://direct.lc.chat/someId/anotherId/../../../../../../../etc/passwd/

Unfortunately, I bumped into a wall which I am no longer surprised. I tried encoding them and still saw the same wall. lol

image from Google

But I noticed something interesting. The URL is now site.com/redir?url=https://direct.lc.chat/etc/passwd/ but returns a different error instead of 404 which I mentioned above. This means that the firewall error was the reaction of the /etc/passwd/ or path traversal injected in the URL but was not validated by the backend.

Having this idea, I am now in the assumption that the validation for the URL parameter is that their backend only validates the hosts (white listing) but not anything after the hostname.

To confirm my theory, I visited livechat.com, registered an account, and created my own chat channel. Skipping all the setups, I now have a link to my own chat channel which let's say is https://direct.lc.chat/attackerID. I added my own link to my target /redir endpoint so now I have the URL of site.com/redir?url=https://direct.lc.chat/attackerID and BOOM I got redirected to my own channel! My target site.com doesn’t validate whether the parameter contains their own LiveChat channel ID or not as long as it contains https://direct.lc.chat domain 😁

Attack Scenario

This should be good to go and ready for reporting. But to elaborate a bit on how this bug can be used as an attack vector, using the application’s popularity on social media, an attacker can simply lure victims using some fancy captions for his post ( e.g. “Free $$$$, chat with our support agent now! etc.”) and from there, an attacker can perform social engineering — ask for victims’ user credentials and/or credit card information, XSS, etc.

Thanks, everyone for reading! :)

Happy Hacking!

Facebook: https://www.facebook.com/r00t.ssh/

“Every error lies a great risk.”

--

--

Johnfiel

Security, Technology, and everything in between.