Всем привет!
Securelist.com разрабатывается Лабораторией Касперского. На сайте есть блог, в котором постяться сотрудники ЛК, а простые пользователи, зарегистрировавшись, могут их комментировать. У комментраиев есть рейтинг. Как только рейтинг всех комментариев пользователя становится >=100, то пользователь получает статус блоггера и может постить в блог. И однажды я там зарегистрировался…


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

[XSS]
Зарегистрировавшись, я решил провести стандартный тест на XSS-уязвимость. Я вставил JS-script с alert'ом и он сработал, т.е. в поле Логина не было фильтрации против XSS.
Не долго думая, я вставил сниффер, прокомментировал несколько блогов и стал ждать. Сниффер висел на сайте около месяца. За это время я смог перехватить 91 аккаунт к сайту. Давайте рассмотрим работу сайта подробнее:
1) Пользователь вводит логин и пароль
2) Сайт записывает в cookie (VLUserkaspru) пользователя параметры в виде:
id:19DEShash
где 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 сотрудников ЛК, я мог зайти в панель управления блогом. Она выглядела так:

Вид профиля пользователя со статусом «Администратор» изнутри:

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

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

Ну, или так:

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

[SQL-Injection]
Прошло немного времени, и я уже хотел сообщить администрации сайта об уязвимости, но решил проверить параметры cookie на фильтрацию. И оказалось, что id не фильтруется!
Подставляя в куки различные параметры я узнал, что там Blind SQL Injection:
12345) AND 1=2--:hash
При таком параметре меня в мой аккаунт не пускало, зато при
12345) AND 1=1--:hash
я заходил как залогиненый юзер.
Пару часов я потратил на то, чтобы добиться нормального Blind-вывода. В итоге получил:
12345) AND 1=1 AND (SELECT ascii(substring(version(),1,1)))>100--:hash
Те, кто знают SQL без труда смогут понять, что здесь я сравниваю ascii-код первого символа версии c 100. Если он больше 100, то я становлюсь пользователем (AND TRUE AND TRUE), иначе, я — гость (AND TRUE AND FALSE). Путем подстановки разных значений, я могу узнать ascii-код символа и перевести его в символ.
На сервере крутится PostgreSQL не самой последней версии.
Выводим таблички из 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
И вот я уже начал выводить имена таблиц, но случился облом: вывести я смог только название первой таблицы, и уязвимость перестала работать (скорее всего, администратор спалил логи, однако не исключаю факт, что кто-то шепнул).

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

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