Securelist.com - XSS and SQL Injection Vulnerabilities
Securelist.com is being developed by Kaspersky Lab. The site has a blog where LK employees post, and ordinary users, having registered, can comment on them. Commentaries have a rating. As soon as the rating of all user comments becomes> = 100, the user receives the status of a blogger and can post to the blog. And once I registered there ...
All the actions described below are presented for information only. The portal administration has been notified of all vulnerabilities found on the site. To take some screenshots of the site, I used the peeep.us service of the snusmumrik user hub . Special thanks to the team of the portal R3AL.RUfor help and support.
registering, I decided to conduct a standard test for XSS vulnerability. I inserted a JS-script with alert and it worked , i.e. in the Login field there was no filtering against XSS.
Without hesitation, I inserted a sniffer, commented on several blogs and began to wait. Sniffer hung on the site for about a month. During this time, I was able to intercept 91 accounts to the site. Let's look at the site’s work in more detail:
1) The user enters the username and password
2) The site writes the following parameters in the user's cookie (VLUserkaspru) in the form:
where id is the user’s identifier (can be found on the link: securelist.com/userinfo/id )
19DEShash - standard php DES hash with salt = 19
3) When going to any page of the site, the script takes the user's cookie and breaks it into 2 parts (by ":"), selects the user's password from the database, where id = id, and compares the password hash from the database with the cookie hash value.
This means that by intercepting a cookie 1 time, I can visit the site at any time (or I can remove the hash).
I decided to find out how passwords are stored in the database. It was very simple to check it - we click the link “Forgot password” and we receive an open password on E-Mail. This means that passwords in the database are stored openly, not by hashes.
Having logged into my account, I found that I can change E-Mail to reset my password. To confirm the change of E-Mail, the link came only to the new E-Mail => I can change E-Mail in any account, confirm it and return the password to it in clear form.
Since I intercepted the cookie for the LC staff, I could go to the blog control panel. It looked like this: Inside the profile of a user with the status “Administrator” : After several tests, I found that the text of the blog is not filtered either => I can insert any HTML / JS code there (for example, an exploit). This is how the blog editing page looks: The posting title field is not filtered either, and the title is displayed on the main => we can do a little deface: Well, or like this: And especially for Habrahabr . List of interesting id whose cookies I could intercept: 69 - Dmitry Bestuzhev, Kaspersky Lab Expert
72 - Sergey Golovanov, Kaspersky Lab expert
81 - Maria Namestnikova, Kaspersky Lab expert
82 - Yuri Namestnikov, Kaspersky Lab expert
85 - Tatyana Nikitina, Blogger
1052 - dr, Administrator
7053 - Alexander Gostev, Kaspersky Lab expert »
Some time passed, and I already wanted to inform the site administration about the vulnerability, but decided to check the cookie settings for filtering. And it turned out that id is not filtered!
Substituting various parameters into cookies, I found out that there Blind SQL Injection:
12345) AND 1 = 2 -: hash
With this parameter, I was not allowed to enter my account, but with
12345) AND 1 = 1 -: hash
I logged in as logged in user.
I spent a couple of hours achieving normal Blind output. As a result, I got:
12345) AND 1 = 1 AND (SELECT ascii (substring (version (), 1,1)))> 100 -: hash
Those who know SQL can easily understand that here I am comparing the ascii code the first character of version c is 100. If it is greater than 100, then I become a user (AND TRUE AND TRUE), otherwise, I am a guest (AND TRUE AND FALSE). By substituting different values, I can find out the ascii code of the character and translate it into a character.
The server is running PostgreSQL is not the latest version.
Displaying labels from INFORMATION_SCHEMA.TABLES:
12345) AND 1 = 1 AND (SELECT ascii (substring (table_name, 1,1)) from INFORMATION_SCHEMA.TABLES LIMIT 1 OFFSET 1)> 100 -: hash
And so I already started to display the names of the tables, but there was a bummer: I could only output the name of the first table, and the vulnerability stopped working (most likely, the administrator burned the logs, but I do not exclude the fact that someone whispered).
More recently, a new entry has appeared on securelist.com called XSS for Beginners . =) The
XSS vulnerability was not fixed, although I sent a letter to support and a message to the LC complaints and suggestions book (they answered that all necessary measures had been taken). Maybe this post will force the administration to finally close the vulnerability.
UPD: Attention! This is not a PR site, company or product product.
UPD2: On the topic:
Magic triptych or harmful tips from KAV (The article appeared before my research, however, I learned about it quite recently).