Unusual XSS vulnerabilities
Hello, reader!
This article will not talk about what XSS is and what it is eaten with. We are all great uncles (well, aunts). This is an article that the introduction of arbitrary code is always and everywhere. I will show you that the most popular social network in Russia and the CIS, as well as the website of the President of the Russian Federation, is vulnerable to such types of attacks.
Vulnerabilities are closed and we can start.
Do you still run flash drives from a browser? Then we go to you.
One bright night, after drinking another cup of coffee, I decided to look for XSS vulnerabilities. I got into Google something similar to: filetype: php inurl: "*. Php? Search = *" and received ~ 1,500,000,000 pages in response. Every third was vulnerable ... sad.
Not about this, changing your request to the “Great and Mighty” found the swf, which sent the GET request to the root of the site.
Without thinking twice, I changed the request and submitted the following data to the input: * .swf? [Variable] = http: //127.0.0.1/. Seeing error 404 at the crossdomain, I cursed, but the GET request went to localhost. Quickly faking the crossdomain, I saw that cute alert (). And now a little more detail.
crossdomain.xml I wrote the most banal:
')
Having solved the problem with crossdomain, I saw the following picture:
Next, I tried to inject the tags body, script, but this didn’t cause anything at all, except mood decay, and then it’s only up to me that the links are clickable!
As a result, tags a, img could still be embedded in the page.
Well, the links are clickable, therefore we must use href = "javascript:" OR href = "data :,".
But data does not help us, we also need control over vk.com (although, perhaps, it was possible to get access through window.opener).
To demonstrate the attack, I decided to create a fake VKontakte.
The hand reached for the console and now wget uploaded index.html, as something inside me, it moved.
After all, the link will look like:
And now the most terrible: in js two types of quotes are used (it is clear to everyone), we have already used some, there are still some left.
But how then to place in the variable text data?
Suppose this is our evil:
From the point of view of js, everything is fine, but here html will swear.
But here you need to remember ASCII.
We encode characters in ASCII and our code takes on a completely different look, the browser does not swear at the syntax and the code works (a mini-hack is like that).
It remains only to place crossdomain.xml and our fake in the root of the site.
We redirect the user to our link:
And we get the login and password:
The vulnerability was fixed, it seems to me, by adding a couple of lines to .htaccess, but the vulnerability is still alive, they did not fix Flash, although I decompiled it and sent the fla file.
Paul looks down on us, something is wrong ...
And we just create an html page and embed a swf file into it.
Like Vkontakte, Kremlin was vulnerable. But here events developed a little differently.
So, in our arrangement there were already two vulnerable flash drives.
The scheme of work was similar to the VKontakte scheme:
SWF -> GET /crossdomain.xml -> GET / file
At the input they asked for the path to the xml file, processed it and marked the data with the xml in the picture.
The fake xml looked like this:
One second before the click ...
And here it is, alert dream:
Second alert, flash drive number 2:
XML:
The result of the click can be guessed.
Vulnerabilities were always and everywhere, just sometimes they can be in the most unexpected place.
I hope the article was interesting and useful.
Ps Because of my curvature, I add a video just now.
In contact with:
This article will not talk about what XSS is and what it is eaten with. We are all great uncles (well, aunts). This is an article that the introduction of arbitrary code is always and everywhere. I will show you that the most popular social network in Russia and the CIS, as well as the website of the President of the Russian Federation, is vulnerable to such types of attacks.
Vulnerabilities are closed and we can start.
Do you still run flash drives from a browser? Then we go to you.
In contact with
One bright night, after drinking another cup of coffee, I decided to look for XSS vulnerabilities. I got into Google something similar to: filetype: php inurl: "*. Php? Search = *" and received ~ 1,500,000,000 pages in response. Every third was vulnerable ... sad.
Not about this, changing your request to the “Great and Mighty” found the swf, which sent the GET request to the root of the site.
Without thinking twice, I changed the request and submitted the following data to the input: * .swf? [Variable] = http: //127.0.0.1/. Seeing error 404 at the crossdomain, I cursed, but the GET request went to localhost. Quickly faking the crossdomain, I saw that cute alert (). And now a little more detail.
crossdomain.xml I wrote the most banal:
')
<cross-domain-policy> <site-control permitted-cross-domain-policies="master-only"/> <allow-access-from domain="*"/> </cross-domain-policy> Having solved the problem with crossdomain, I saw the following picture:
Next, I tried to inject the tags body, script, but this didn’t cause anything at all, except mood decay, and then it’s only up to me that the links are clickable!
As a result, tags a, img could still be embedded in the page.
HREF, your time!
Well, the links are clickable, therefore we must use href = "javascript:" OR href = "data :,".
But data does not help us, we also need control over vk.com (although, perhaps, it was possible to get access through window.opener).
To demonstrate the attack, I decided to create a fake VKontakte.
The hand reached for the console and now wget uploaded index.html, as something inside me, it moved.
After all, the link will look like:
<a href="javascript: (html )">click-click</a>
And now the most terrible: in js two types of quotes are used (it is clear to everyone), we have already used some, there are still some left.
But how then to place in the variable text data?
Suppose this is our evil:
var a="<html><h1>Site.com</h1>\n"+ "<!— -- -->\n"+ "<div id='lga' style='height:231px;margin-top:-22px'>\n"+ "<!— - -->\n"+ "</html>";
From the point of view of js, everything is fine, but here html will swear.
<a href=" javascript: var a="<html><h1>Site.com</h1> <!— -- --> <div id="lga" style='height:231px;margin-top:-22px'> <!— - --> </html>"; ">FAIL</a>
But here you need to remember ASCII.
We encode characters in ASCII and our code takes on a completely different look, the browser does not swear at the syntax and the code works (a mini-hack is like that).
It remains only to place crossdomain.xml and our fake in the root of the site.
We redirect the user to our link:
And we get the login and password:
The vulnerability was fixed, it seems to me, by adding a couple of lines to .htaccess, but the vulnerability is still alive, they did not fix Flash, although I decompiled it and sent the fla file.
Paul looks down on us, something is wrong ...
And we just create an html page and embed a swf file into it.
Kremlin.ru
Like Vkontakte, Kremlin was vulnerable. But here events developed a little differently.
XML nonsense
So, in our arrangement there were already two vulnerable flash drives.
The scheme of work was similar to the VKontakte scheme:
SWF -> GET /crossdomain.xml -> GET / file
At the input they asked for the path to the xml file, processed it and marked the data with the xml in the picture.
The fake xml looked like this:
One second before the click ...
And here it is, alert dream:
Second alert, flash drive number 2:
XML:
The result of the click can be guessed.
Misuse
Vulnerabilities were always and everywhere, just sometimes they can be in the most unexpected place.
I hope the article was interesting and useful.
Ps Because of my curvature, I add a video just now.
In contact with:
Source: https://habr.com/ru/post/149081/
All Articles