Эта статья написана новичком для новичков в sql-inj, хотя будет просто интересно почитать историю взлома lito.ru . Перед прочтением советую хоть немного разобраться со структурой баз данных и самой субд MySQL.

Дело было вечером - делать было нечего.

Начало стандартное – не знаю как, попался мне в руки линк ведущий на lito.ru, немного осмотревшись, я обнаружил форум - количество юзеров мне понравилось, что-то около 1500 пользователей.
Сайт был литературной тематики, количество писателей было тоже немало, поэтому я взялся за "взлом", в кавычках, потому что его как такого и не было (потом узнаете почему).
Зайдя на форум, я не узнал его версию, о чём свидетельствовала следующая надпись "Powered by phpBB © 2001, 2005...". Поэтому тупой взлом, через новоиспечённый сплоит я отложил и завернул.
Моя точка зрения такова, что для новичков взлом через сплоиты губителен, так как человек таким образом ничему не учится, много ли мозгов надо что бы подставить в окно консоли или браузера строчку и нажать Enter. И так вернёмся к лито.
Движок был пхп'эшный что меня порадовало - не тусклые хтмл страницы, и вообще много не мало! Больше шанс на уязвимость!
Накатав в строке поиска по сайту "<><>" в ответ пришла страница с внедрённым неотфильтрованным запросом - хсс!
Самое интересное это то, что форум находился по адресу http://lito.ru/forum/ - то есть можно было линк на форуме оставить, а там и куки своровать,
но это я оставил на будущие безнадёжие. А сейчас надо было искать, что-то более серьёзное.
По началу всё было плохо... ни одной зацепочки! Уже собрался бросить это дело, как вдруг - sql-inj, явился не запылился!
Бага выглядела так:
то есть возвращалась инфа о пользователе с именем alex081971, кавычка закрыла текущую строку, а /* закоментили строку запроса.
Впоследствии вылезли и другие бажные скрипты:
как видно я просто не обратил внимания на то, что в базу посылается запрос не с числом, как нам кажется, а со строкой "61" для photolist.php!
Так что отсюда совет - не верь глазам, если как кажется (а когда кажется креститься надо) передаётся число - то это совсем не факт что не может передаваться строка. Выводы делайте сами. Больше я багов не нашёл, точнее не хотел уже искать - на php-inj или инклуд надежды было мало, а sql-inj уже что-то.
Что бы сделать? Предположив, что на сервере стоит MySQL новой версии, я начал эксперементировать с UNION, если не знаешь что это такое почитай доки по синтаксису различных СУБД. И так подставляю в своего осла
- как неудивительно, такой запрос не работает. Я зря надеялся на работающий UNION, так как перебрав около 100 стобцов я решил забить на это дело. Простым запросом -
я получил первого "писателя" с логином root, то есть в таблице была колонка id, а позже выяснилось что и name. Тут я вспомнил, что в MySQL 4.1 и выше введена поддержка подзапросов и забил в осла следующую строку -
не сработало, после долгого перебора имени таблицы с записями юзеров я и на это дело положил. Осталась надежда что таблица phpbb_users лежит в базе к которой мы шлём запрос, и так посылаю
но и тут тщетно! Видимо версия MySQL была старая, но нельзя же останавливаться на полпути!

Вперёд к победе

Продолжая бродить по ссылкам в поисках инклудинга или php-inj, я нашёл незаметную поначалу форму ввода логина и пароля для писателей. Для проверки на уязвимость я зарегистрировал себя на имя ZaCo. На главной странице подставляю в имя юзера - себя родимого, ну и пасс тоже свой, тут вижу пишет мне скрипт - Здравствуйте, Alex Zaharov! Alex Zaharov - имя и фамилия указаные при регистрации. Нажимаю logout и выхожу из сессии. Теперь захожу к себе под логином ZaCo' и рандомным пассом - не пускает! Хм... а если ZaCo'/* - всё равно не идёт. Тут я уже отчаился... Но! Самое интересное - при откатке назад мне пишут - Здравствуйте, Alex Zaharov! Ну что же иньекция проведена удачно дамы и господа! К сожалению управлять своими произведениями я не мог, меня не пускали, но это хоть что-то - сам факт что скрипт меня распознал наводил на мысли. Стало так же ясно, что скрипт проверки пасса был написан очень криво. Что бы лучше понять принцип его работы пришлось включить мозг, взять кусок (нам и куска хватит) бумаги и кусок, хотя нет - лучше целую ручку. По сообщениям скрипта его работа выглядела примерно так:
1)select userpasswd from users where user_name='ZaCo'
2)Какие-то действия типа кривого вывода инфы о пользователе
3)Если вытянутый пароль userpasswd===паролю который ввёл пользователь, то завести сессию и дать возможность управлять произведениями
Дальнейшая работа нас не интересует. Ясно, что запрос
давал возможность перейти к шагу 2 и сказать Здравствуйте, Alex Zaharov! Но нам надо было перейти через шаг 3) - что понятно невозможно для определённого пользователя со сложным паролем, например для root. Оставалось одно - каким-то образом достать пасс у пользователя root. Я заметил, что если в поле логина ввести несуществующее значение, то скрипт нам потом напишет - Здравствуйте, ! Значит можно подставлять к запросу логику. Для начала нужно было узнать имя колонки с паролями юзеров имя её - passwd.

Дальше больше

Подставляем такое значение в поле ввода логина -
ZaCo'and(substring(passwd,1,1)='r')/*, а в пасс любое значение - оно всё равно обрезается. Скрипт вывел - Здравствуйте, Alex Zaharov! так как мой пасс начинался на "r", в тоже время при значении логина - ZaCo'and(substring(passwd,1,1)='q')/* скрипт вернул - Здравствуйте, ! так как условие ложное! Значит я мог перебрать посимвольно пасс root'а! И так подставляю - root'and ascii(lower(substring(passwd,1,1)))>120/*
результат положительный, значит первый символ пароля имеет ASCII больший чем 120. поясню: lower - преобразует символы в нижний регистр('A'->'a'), substring(st,i,count) - выделяет строку из st с позиции i длиной count символов. После 5-7 запросов я получил код первого символа пароля пользователя root. Достав ASCII таблицу, оказалось первая буква в пароле "p", но мы искали код для символа в нижнем регистре, поэтому составил следующий запрос - root'and ascii(substring(passwd,1,1))=80/* он вернул положительный результат, значит первая буква пасса не "p", а "P"! После нескольких таких запросов я получил пасс root'a - "PlqGFk". Первый шаг сделан! Идём дальше.

В админке

Оказавшись в админке я мог расматривать заявления о регистрации на портале lito.ru, мог публиковать/удалять/менять новости, таким образом можно было и дефейс сделать - опубликоать новость типа "HaCkeD bY ZaCo", но после таких долгих операций над lito мне так просто отделоваться не хотелось. Кроме дополнительных sql-inj в админке, которых и так хватает, я ничего не обнаружил. А жаль... Не помню как, но я нашёл ещё одного админа с именем - Алексей Караковский, подобрав так же пароль и к этому админу я оказался в более интересном месте...
А здесь кроме всего прочего я нашёл меню управления статусами пользователей, их пароли и логины, а их было 1824 - неплохо для начала! Забавы ради я поставил себе статус редактора раздела и мог также безнаказанно публиковать и менять новости! Но не тут то было - меня видимо просекли, так как на следующий день мой статус стал "nobody" так сказать. Ну а на послеследующий день я лицезрел на главной странице сайта следующее:
"Леди и джентльмены.

Отражение третьей попытки взлома сайта закончилось неудачно.

Сайт закрыт на неопределённый срок.

Восстановление материалов, опубликованных после 12 сентября 2005 года, вероятнее всего, невозможно.

С прискорбием, главный редактор сайта Алексей Караковский.



P. S. Редакция, несмотря на невзгоды, не сдаётся и предлагает переждать тяжёлое время на форуме "Имён Любви" у Славы Фурты.
"
Алексей Караковский - тот самый админ чей пасс я тоже спёр.
Ну на этом моя история заканчивается! Кстати никакая информация на сайте не была изменена - никакие файлы не были удалены и т.д. и т.п.
И напоследок:
1) Всегда фильтруйте данные! 99% взломов происходит как раз из-за недостаточной фильтрации данных
2) Будте целеустремлённым человеком, настоящие ошибки не подают на блюдечке
3) Не верь глазам
Всё остальное лишь вытекает из предыдущего.
Это не руководство к взлому - это простая история как простой подросток имеющем в распоряжении 2 года общения с компьютером взломал базу паролей портала lito.ru - имеющего отнюдь немалую посещаемость. Так что ошибки есть везде - основная задача администратора хотя бы пытаться их закрыть.
email:zaco@yandex.ru