12:37 Securelist com xss and sql injection vulnerabilities | |
Hello! Securelist.com developed by Kaspersky Lab. The site has a blog in which fasting LC staff, and ordinary users, once registered, can comment on them. We have kommentraiev rating. Once the rating of all user comments is> = 100, the user receives the status of the blogger and can post to your blog. And once I have registered there ... [Disclaimer] All these steps are presented solely for oznakomeniya. The portal administration was made aware of all vulnerabilities found on the website. To remove some screenshots of the site I used the service peeep.us habrapolzovatelya snusmumrik. Special thanks to the team portal R3AL.RU for their help and support. [XSS] register, I decided to do a standard test for XSS-vulnerability. I inserted the JS-script with alert'om and it worked, ie, in the Login box was not filtering against XSS. Without hesitation, I put a sniffer, commented on several blogs, and waited. Sniffer was hanging on a site about a month. During this time I was able to intercept the 91 Account to the site. Let's look at the work site in more detail: 1) User enters username and password 2) The site records a cookie (VLUserkaspru) user settings in the form of: id: 19DEShash where id - id Users (you can find the link: securelist.com / ru / userinfo / id) 19DEShash - standard php DES-hash with salt = 19 3) When you go to any page on the site, the script takes the user's cookie and splits into 2 parts (by ":"), selects from a database user's password where id = id, and compares the password hash from the database with the hash value of the cookie. This means that, taking over a time cookie, can I visit the site whenever you want (or can I sbrutit hash). I decided to find out what the passwords are stored in the database. Check out this was very simple - click the link "Forgot password" and we at E-Mail Password comes in clear. This means that the passwords are stored in the database is open, not hashes. Going into account, I discovered that I can change the E-Mail Password Recovery. To confirm the change of E-Mail'a links come only at the new E-Mail => I can change your account in any E-Mail, confirm it and return it to the password in clear text. Since I caught the cookie LC staff, I could go to control panel blog. It looked like this: View user profile with the status of "Administrator" from the inside: After some tests, I discovered that the text of the blog is also not filtered => I can insert there any HTML / JS code (for example, exploit). Here is the blog editing page: Golf zaglovka posting is also not filtered, and the caption is displayed on the main page => we can do a little deface: Well, or so: And specifically for Habrahabr. The list of interesting id, cookie which I was able to capture: 69 - Dmitri Bestuzhev expert Kaspersky Lab 72 - Sergey Golovanov, expert from Kaspersky Lab 81 - Maria Namestnikova , Expert Kaspersky Lab 82 - Jury governors, expert from Kaspersky Lab 85 - Tatiana Nikitina, blogger 1052 - dr, Administrator 7053 - Alexander Gostev, Judge " Kaspersky Lab » [SQL-Injection] A little time passed, and I would like to inform the site about the vulnerability, but decided to check the cookie settings for filtering. And it turned out that the id is not filtered! Substituting the various parameters of the cookies, I learned that there is Blind SQL Injection: 12345) AND 1 = 2 -: hash With this option I have in my account is not allowed, but at 12345) AND 1 = 1 -: hash I went as a logged in user. A couple of hours I spent on it to achieve normal Blind-output. 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 am comparing ascii-code for the first character version of c 100. If it is greater than 100, then I get a user (AND TRUE AND TRUE), otherwise, I - guest (AND TRUE AND FALSE). By substituting different values, I can find ascii-character code and translate it into a symbol. On the server, PostgreSQL is not spinning the latest version. Print the 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 And now I've started to write the names of tables, but there was a bummer: I was able to deduce only the name of the first table, and the vulnerability is not working (most likely, the administrator logs burned, but do not exclude the fact that someone whispered). Most recently, at securelist.com a new record called «XSS for beginners. =) XSS vulnerability was not fixed, although I sent a letter of support and communication in the complaint book LC (was told that all necessary measures have been taken). Maybe this post will make the administration is finally close the vulnerability. UPD: Attention! This is not a PR site, company or product, product. UPD2: On topic: Magic triptych or harmful advice from KAV (article appeared before my research, however, about her I learned quite recently). | |
|
| |
| Total comments: 0 | |