Abusing services using SVG files: Part 2. A practical exploit using a vulnerable site
This is a 4 part series based on a vulnerability writeup I wrote, detailing step-by-step exploitation instructions in an internal comms channel. See part 1 before jumping on to this one for added context.
When targeting a service, the attacker must understand what kinds of assets the service contains. Some examples could contain:
- Ability to purchase products using someone else’s money
- Credit card info, or access to payments
- Personal data, accounts & credentials
- Secrets
- Etc
These can either be used to gain direct value, such as money or products but can also be, and often are, information. The information gathering can be automated so the attacker can exfiltrate as much data with as little effort as possible and sell it to the highest bidder. If the attack is not caught, the data can prove to be quite valuable someday, so hanging on to it might also be an option for some players.
I promised a practical exploit, and building on part 1, and we’re not going to cause any problems using just alert boxes, right? We need to gather the data we deem valuable or figure out a way to get to the data if it is not directly accessible. This could go multiple ways, such as gathering accounts via a fake login page, steal credit card info via a fake payment page or exfiltrating the user data.
Let’s say we have a site with a login form, and the site is loading a vulnerable SVG-file. We could easily change the forms action property in javascript to post the data to another site altogether! Incidentally, this was my first example exploit from around 2002 or 2003 that I did against a site we built in a company way back then... Happy memories 😀
Changing the action property of a form within the SVG is easy as pie
It’s quite simple really, when I did my first exploit, javascript wasn’t really used nor well supported in browsers, so there wasn’t much we could do besides changing the action property. Nowadays, it would be trivial to insert a new handler to the form DOM element that intercepts the form handling, exfiltrates the data via a new XHR request and proceeds with the regular functionality while being transparent to most users.
If we’re going to apply this to our services, we could decide to just exfiltrate the cookie or localstorage data. Exfiltration is actually quite trivial but there are some issues that complicate this a bit. You’ll probably see that your XHR requests do not work as expected, at least if CSP headers are set at all. The default CSP in most browsers should block these kinds of requests quite well.
Not to worry, there are other way to achieve the data exfiltration. Let’s see how we can build up on the previous example while also keeping the example simple.
We’ll use the same html file as last time:
Let’s modify our SVG file a bit:
Did you see what we did there? We dynamically created an image in Javascript, set the src attribute to point to our evil site https://evilsite.com with the cookie value we got in part 1. This value would then be logged and stored in the attacker's server for either immediate or later abuse.
If you’re familiar with javascript you’ll probably notice that the url with the cookie value will most likely break the URL and not work. No problem, we’ll just change it to a base64 encoded string.
And we’re done. A practical exploit exfiltrating the cookie of any user that sees that SVG file in the context of the target service.
As we have total control over the javascript, we could of course read or modify all the data in the DOM using parent.document.querySelectorAll() or any of the other functions available to us via the Document object.
Why does this work?
The users are generally instructed to verify the address of the site you’re using, then they’re told to check that there’s a padlock icon in the address bar. Check and check. The actual loading of the image is transparent, and most people won't notice it until it’s too late.
Working copies of our services in different URLs are something that companies are also battling with. Just this spring we squashed 4 copycat sites of one of our production systems. They were (almost) exact copies of the official site with added scripts that tried to get to users’ credit cards replacing the payment service with a payment service located in Russia. Those sites were convincing, but they had URLs that while closely resembling our systems, we’re clearly fake. If a user followed the usual instructions they’d see that the site was not the actual one and would not insert their payment info to the fake site.
There are some limitations with the above way of exfiltrating data, such as the maximum length for url’s. These are also quite easy to overcome with a bit of scripting as we’ll see in the next part.
I’ll show you this approach in the next part where I’ll be outlining an actual attack I built against one of our services. This ends up with a total takeover of the end user's session so beware. The vulnerability has now been fixed though, so it won't work anymore.
Originally published at https://www.linkedin.com.
