Hello everyone!
Securelist.com developed by Kaspersky Lab. The site has a blog in which employees are fasting LC, and ordinary users, once registered, can comment on them. We have comments or rating. Once the rating of all user comments becomes> = 100, the user receives the status of the blogger and can post to your blog. And once I have registered there ...
[Disclaimer]
All the actions described below are presented solely for oznakomeniya. Portal administration has been advised of all vulnerabilities found on the website. To remove some screenshots I took the site service peeep.us habrapolzovatelya snusmumrik. Special thanks to the team of the portal R3AL.RU for help and support.
[XSS]
By registering, I decided to do a standard test for XSS-vulnerability. I put the JS-script with alert'om and it worked, ie in the Username field was not filtering against XSS.
Without hesitation, I put a sniffer, commented on several blogs and waited. Sniffer hung on the site for about a month. During this time I was able to intercept 91 account to the site. Let's look at the work site more:
1) The user enters a username and password
2) The site writes cookie (VLUserkaspru) user parameters in the form:
id: 19DEShash
where id - the identifier of the user (can be found on the link: securelist.com/ru/userinfo/id)
19DEShash - standard php DES-hash with salt = 19
3) When you go to any page of your site, the script takes the user's cookie, and splits into 2 parts (by ":") is selected from the database password for the user where id = id, and compares the hash of the password from the database with the value of the hash cookie.
This means that, catching just one cookie, I can go to the website at any time (or I can sbrutit hash).
I decided to find out how the passwords are stored in the database. Check it was very simple - click the link "Forgot password" and we are on the E-Mail comes password in the clear. This means that passwords are stored in the database is open, not hashes.
Going into account, I found that I can change the E-Mail to reset your password. To confirm the change of E-Mail'a link only comes to the new E-Mail => I can change any account E-Mail, confirm it and return it to the password in the clear.
As I caught cookie employees LK, I could go to control panel blog. It looked like this:
image
View user profile with the status "Administrator" from the inside:
image
After a few tests, I found that the text of the blog is also not filtered => I can insert there any HTML / JS code (for example, an exploit).
Here is the edit page of the blog:
image
Field zaglovka posting is also not filtered, and the title is displayed on the main page => we can do a little deface:
imageimage
Well, or so:
imageimage
And especially for Habrahabr.
List of interesting id, cookie that I could intercept:
69 - Dmitry Bestuzhev expert "Kaspersky Lab"
72 - Sergey Golovanov, expert "Kaspersky Lab"
81 - Maria Namestnikova, expert "Kaspersky Lab"
82 - Jury governors, expert "Kaspersky Lab"
85 - Tatiana Nikitina, Blogger
1052 - dr, Administrator
7053 - Alexander Gostev, expert "Kaspersky Lab"
[SQL-Injection]
After a short time, and I would like to inform the site of the vulnerability, but decided to check the settings on the cookie filtering. And it turned out that id does not filter!
Substituting in the cookie various options, I learned that there is Blind SQL Injection:
12345) AND 1 = 2 -: hash
When this parameter is changed in my account is not allowed, but at
12345) AND 1 = 1 -: hash
I went as a logged user.
A couple of hours I spent on it to achieve normal Blind-O. The result was:
12345) AND 1 = 1 AND (SELECT ascii (substring (version (), 1,1)))> 100 -: hash
Those who know SQL can easily understand that here I compare ascii-code of the first character version of c 100. If it is greater than 100, then I get the user (AND TRUE AND TRUE), otherwise, I - Guest (AND TRUE AND FALSE) . By substituting different values, I know ascii-character code and translate it into a symbol.
On the server, PostgreSQL does not spinning the latest version.
Derive signs of 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
So I started to write the names of the tables, but there was a bummer: I was able to bring only the name of the first table, and the vulnerability has stopped working (most likely, the administrator logs burned, but do not exclude the fact that someone whispered).
Most recently, on securelist.com a new record called «XSS for beginners." =)
XSS vulnerability did not fix it, even though I sent a letter in support and a message in the book of complaints and suggestions LC (answered that all necessary measures have been taken). Maybe this post will make the administration finally close the vulnerability.
UPD: Warning! This is not a PR site, company, or product product.
UPD2: On the topic:
Magic triptych or bad advice from KAV (the article appeared before my research, however, I learned about it quite recently).
Securelist.com developed by Kaspersky Lab. The site has a blog in which employees are fasting LC, and ordinary users, once registered, can comment on them. We have comments or rating. Once the rating of all user comments becomes> = 100, the user receives the status of the blogger and can post to your blog. And once I have registered there ...
[Disclaimer]
All the actions described below are presented solely for oznakomeniya. Portal administration has been advised of all vulnerabilities found on the website. To remove some screenshots I took the site service peeep.us habrapolzovatelya snusmumrik. Special thanks to the team of the portal R3AL.RU for help and support.
[XSS]
By registering, I decided to do a standard test for XSS-vulnerability. I put the JS-script with alert'om and it worked, ie in the Username field was not filtering against XSS.
Without hesitation, I put a sniffer, commented on several blogs and waited. Sniffer hung on the site for about a month. During this time I was able to intercept 91 account to the site. Let's look at the work site more:
1) The user enters a username and password
2) The site writes cookie (VLUserkaspru) user parameters in the form:
id: 19DEShash
where id - the identifier of the user (can be found on the link: securelist.com/ru/userinfo/id)
19DEShash - standard php DES-hash with salt = 19
3) When you go to any page of your site, the script takes the user's cookie, and splits into 2 parts (by ":") is selected from the database password for the user where id = id, and compares the hash of the password from the database with the value of the hash cookie.
This means that, catching just one cookie, I can go to the website at any time (or I can sbrutit hash).
I decided to find out how the passwords are stored in the database. Check it was very simple - click the link "Forgot password" and we are on the E-Mail comes password in the clear. This means that passwords are stored in the database is open, not hashes.
Going into account, I found that I can change the E-Mail to reset your password. To confirm the change of E-Mail'a link only comes to the new E-Mail => I can change any account E-Mail, confirm it and return it to the password in the clear.
As I caught cookie employees LK, I could go to control panel blog. It looked like this:
image
View user profile with the status "Administrator" from the inside:
image
After a few tests, I found that the text of the blog is also not filtered => I can insert there any HTML / JS code (for example, an exploit).
Here is the edit page of the blog:
image
Field zaglovka posting is also not filtered, and the title is displayed on the main page => we can do a little deface:
imageimage
Well, or so:
imageimage
And especially for Habrahabr.
List of interesting id, cookie that I could intercept:
69 - Dmitry Bestuzhev expert "Kaspersky Lab"
72 - Sergey Golovanov, expert "Kaspersky Lab"
81 - Maria Namestnikova, expert "Kaspersky Lab"
82 - Jury governors, expert "Kaspersky Lab"
85 - Tatiana Nikitina, Blogger
1052 - dr, Administrator
7053 - Alexander Gostev, expert "Kaspersky Lab"
[SQL-Injection]
After a short time, and I would like to inform the site of the vulnerability, but decided to check the settings on the cookie filtering. And it turned out that id does not filter!
Substituting in the cookie various options, I learned that there is Blind SQL Injection:
12345) AND 1 = 2 -: hash
When this parameter is changed in my account is not allowed, but at
12345) AND 1 = 1 -: hash
I went as a logged user.
A couple of hours I spent on it to achieve normal Blind-O. The result was:
12345) AND 1 = 1 AND (SELECT ascii (substring (version (), 1,1)))> 100 -: hash
Those who know SQL can easily understand that here I compare ascii-code of the first character version of c 100. If it is greater than 100, then I get the user (AND TRUE AND TRUE), otherwise, I - Guest (AND TRUE AND FALSE) . By substituting different values, I know ascii-character code and translate it into a symbol.
On the server, PostgreSQL does not spinning the latest version.
Derive signs of 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
So I started to write the names of the tables, but there was a bummer: I was able to bring only the name of the first table, and the vulnerability has stopped working (most likely, the administrator logs burned, but do not exclude the fact that someone whispered).
Most recently, on securelist.com a new record called «XSS for beginners." =)
XSS vulnerability did not fix it, even though I sent a letter in support and a message in the book of complaints and suggestions LC (answered that all necessary measures have been taken). Maybe this post will make the administration finally close the vulnerability.
UPD: Warning! This is not a PR site, company, or product product.
UPD2: On the topic:
Magic triptych or bad advice from KAV (the article appeared before my research, however, I learned about it quite recently).
No comments:
Post a Comment