Всем привет! ]]>Securelist.com]]> разрабатывается Лабораторией Касперского. На сайте есть блог, в котором постяться сотрудники ЛК, а простые пользователи, зарегистрировавшись, могут их комментировать. У комментраиев есть рейтинг. Как только рейтинг всех комментариев пользователя становится >=100, то пользователь получает статус блоггера и может постить в блог. И однажды я там зарегистрировался…
[Disclaimer] Все действия, описанные ниже, представлены исключительно для ознакомения. Администрация портала была поставлена в известность обо всех уязвимостях, найденных на сайте.
[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. Совет от ЛК: «Не ходите по ссылкам в спамерских письмах». От себя добавлю, что порой и сайты об интернет безопасности могут быть уязвимы.
Зарегистрировавшись, я решил провести стандартный тест на XSS-уязвимость. Я вставил JS-script с alert'ом и он сработал
0_0, ппц хм, и что не закрыли хss , если были уведомлены...
Сообщение отредактировал XALIF - 21.10.2009, 23:31
--------------------
Модератор - деревянная палка с прокладкой из сукна, служащая для приглушения звука у пианино. Анонимность - миф! ]]>IRC]]> ]]>Jabber]]> icq:698-009 jabber:xalif@thesecure.biz
securelist.com XSS и SQL Injection уязвимости, By LMaster
21.10.2009, 23:06
