Securelist.com - XSS и SQL Injection уязвимости

Securelist.com разрабатывается Лабораторией Касперского. На сайте есть блог, в котором постяться сотрудники ЛК, а простые пользователи, зарегистрировавшись, могут их комментировать. У комментраиев есть рейтинг.

Как только рейтинг всех комментариев пользователя становится >=100, то пользователь получает статус блоггера и может постить в блог. И однажды я там зарегистрировался...

[Disclaimer]
Все действия, описанные ниже, представлены исключительно для ознакомения. Администрация портала была поставлена в известность обо всех уязвимостях, найденных на сайте. Для снятия некоторых скриншотов сайта я воспользовался сервисом peeep.us хабрапользователя snusmumrik. Отдельное спасибо команде портала R3AL.RU за помощь и поддержку.


[XSS]
Зарегистрировавшись, я решил провести стандартный тест на XSS-уязвимость. Я вставил JS-script с alert'ом и он сработал, т.е. в поле Логина не было фильтрации против XSS.
Не долго думая, я вставил сниффер, прокомментировал несколько блогов и стал ждать. Сниффер висел на сайте около месяца. За это время я смог перехватить 91 аккаунт к сайту.

Давайте рассмотрим работу сайта подробнее:
1) Пользователь вводит логин и пароль

2) Сайт записывает в cookie (VLUserkaspru) пользователя параметры в виде:

где id - идентификатор пользователя (можно узнать по ссылке: securelist.com/ru/userinfo/id)

19DEShash - стандартный php DES-хеш с salt=19

3) При переходе на любую страницу сайта, скрипт берет cookie пользователя и разбивает на 2 части (по ":"), выбирает из БД пароль пользователя, где id=id, и сравнивает хеш пароля из базы со значением хеша из cookie.

Это значит, что, перехватив 1 раз cookie, я могу заходить на сайт когда угодно (или я могу сбрутить хеш).

Я решил узнать, как же хранятся пароли в базе. Проверить это было очень просто — нажимаем ссылку «Забыл пароль» и нам на E-Mail приходит пароль в открытом виде. Это значит, что пароли в базе хранятся открыто, не хешами.

Зайдя в аккаунт, я обнаружил, что я могу сменить E-Mail для восстановления пароля. Для подтверждения смены E-Mail'а ссылка приходила только на новый E-Mail => я могу в любом аккаунте изменить E-Mail, подтвердить его и вернуть на него пароль в открытом виде.
Поскольку я перехватил cookie сотрудников ЛК, я мог зайти в панель управления блогом.

Она выглядела так:


Вид профиля пользователя со статусом «Администратор» изнутри:
http://www.securelist.com/ru/userinfo/1052


Проведя несколько тестов, я обнаружил, что текст блога тоже не фильтруется => я могу вставить туда любой HTML/JS код (например, эксплоит).

Вот так выглядит страница редактирования блога:


Поле загловка постинга тоже не фильтруется, а заголовок выводится на главную => мы можем сделать небольшой deface:



Ну, или так:



И специально для Хабрахабра:
http://www.peeep.us/0eddc12c


Список интересных id, cookie которых я смог перехватить:

69 - Дмитрий Бестужев, Эксперт «Лаборатории Касперского»
72 - Сергей Голованов, Эксперт «Лаборатории Касперского»
81 - Мария Наместникова, Эксперт «Лаборатории Касперского»
82 - Юрий Наместников, Эксперт «Лаборатории Касперского»
85 - Татьяна Никитина, Блоггер
1052 - dr, Администратор
7053 - Александр Гостев, Эксперт «Лаборатории Касперского»

[SQL-Injection]
Прошло немного времени, и я уже хотел сообщить администрации сайта об уязвимости, но решил проверить параметры cookie на фильтрацию. И оказалось, что id не фильтруется!
Подставляя в куки различные параметры я узнал, что там Blind SQL Injection:


При таком параметре меня в мой аккаунт не пускало, зато при

я заходил как залогиненый юзер.

Пару часов я потратил на то, чтобы добиться нормального Blind-вывода. В итоге получил:


Те, кто знают SQL без труда смогут понять, что здесь я сравниваю ascii-код первого символа версии c 100. Если он больше 100, то я становлюсь пользователем (AND TRUE AND TRUE), иначе, я - гость (AND TRUE AND FALSE). Путем подстановки разных значений, я могу узнать ascii-код символа и перевести его в символ.

На сервере крутится PostgreSQL не самой последней версии.
Выводим таблички из INFORMATION_SCHEMA.TABLES:


И вот я уже начал выводить имена таблиц, но случился облом: вывести я смог только название первой таблицы, и уязвимость перестала работать (скорее всего, администратор спалил логи, однако не исключаю факт, что кто-то шепнул).

Совсем недавно на securelist.com появилась новая запись под названием «XSS для начинающих». =)

XSS уязвимость так и не исправили, хотя я направлял письмо в support и сообщение в книгу жалоб и предложений ЛК (ответили, что все необходимые меры были приняты). Может быть, этот пост заставит администрацию наконец-то закрыть уязвимость.

UPD: Внимание! Это не пиар сайта, фирмы или продукта продукта.
UPD2: На тему: Волшебный триптих или вредные советы от KAV (статья появилась раньше моего исследования, однако, про нее я узнал совершенно недавно).