Показать сообщение отдельно

  #2  
Старый 24.06.2005, 20:17
silveran
Постоянный
Регистрация: 02.05.2005
Сообщений: 786
Провел на форуме:
807041

Репутация: 263


Отправить сообщение для silveran с помощью ICQ
По умолчанию

Думаю, не стоит описывать, как я вошел на этот ресурс – использовался тот же пароль админа, который загадочным образом подошел к мантису. Надо сказать, что по функциональным возможностям мантис просто отдыхает. В блоге было намного больше функций, среди которых я обнаружил полезный скрипт upload-файлов. Сразу же захотелось залить PHP-шелл и выполнить несколько команд. Но я жестоко обломался, так как upload.php заявил, что не хочет принимать файлы с расширением PHP . Конечно, можно было бы замаскировать web-шелл под картинку или doc-файл, но переименовать залитый документ было бы весьма затруднительно.

Mantis спасает положение

Кроме upload-скрипта, в блоге не было ничего полезного. Новости также не радовали – сплошная рутинная полоса о выполненных заданиях. Я понимал, что расклад не в мою пользу, поэтому решил вернуться на страницы mantis’а и перечитать все его архивы. Признаться, я надеялся найти там какие-нибудь пароли либо новые ссылки . Результат поиска меня, мягко говоря, ошарашил. В одном из постов промелькнула загадочная ссылка на http://blog.clickatell.com/pa. Я зашел туда и увидел... незапароленный PhpMyAdmin! В первую минуту я просто находился в состоянии эйфории – мне казалось, что все базы пользователей хранятся именно на этом серваке. Однако это оказалось не совсем так. В базах находились настройки, сообщения и прочие вещи, относящиеся к blog’у и какому-то web-календарю. Но, несмотря на это, PhpMyAdmin выступил главным звеном цепочки хакерских действий. Просматривая таблицы базы wordpress (она как раз и относилась к blog’у), я нашел очень интересную фичу. Оказывается, все настройки upload-скрипта находятся в таблице wp_options. Нужный параметр, который грех было не поменять, назывался fileupload_allowedtypes. С помощью нехитрого SQL-запроса UPDATE wp_options set option_value=’jpg gif png doc pdf php’ WHERE option_name=’fileupload_allowedtypes’ я слегка модифицировал настройку движка . Теперь скрипт уже не ругался на левое расширение файла и без слов сохранил веб-шелл в каталог /data/apache/wordpress/wp-content (путь, куда сохраняются залитые файлы, я узнал из той же таблицы wp_options).

Как ты уже понял, сервер, где располагался blog, меня мало интересовал. Эта машина не являлась главной в сервисе clickatell. Но поискать интересную информацию в каталогах сервера мне очень хотелось. Команда uname –a показала, что компьютер находится под управлением Linux. Уже через пять минут я обнаружил загадочную директорию admin, в которой располагались какие-то сценарии. Исходя из того, что более ценной инфы мне найти не удалось, я сжал всю админку в архив, скопировал в каталог /data/apache/wordpress/wp-content и слил все это дело на свой компьютер. Теперь мне предстояло изучить содержимое загадочного архива.

Проникновение в админку

При детальном рассмотрении скриптов оказалось, что зона администрирования находится по адресу www.clickatell.com/central/admin. Действительно, при попытке обращения к этой ссылке с меня потребовали логин и пароль. Мне повезло, так как htpasswd также находился в архиве, который я скачал с сервера blog. Быстро скормив этот файл Джонику, я получил один подобранный аккаунт администратора. Надо сказать, что пароль был уникальным и не совпадал с пассвордом в MySQL.
Зона администрирования представляла собой несколько скриптов, которые позволяли мониторить статус SMS-шлюзов, смотреть активность, а также выполнять SQL-запросы. Перерыв все сценарии, я не нашел возможности заливать или редактировать файлы, а уж тем более выполнять команду. В принципе, встроенный SQL-клиент позволил бы мне вывести все таблицы на экран, но я боялся, что мой браузер подвиснет из-за переизбытка информации . В связи с этим было решено еще раз просмотреть внутренности всех скриптов в локальном каталоге admin. Я пошел в верном направлении, так как быстро нашел уязвимость в сценарии router_tester.php. Там располагался следующий код:

system("/usr/local/clickatell/bin/router_tester -U $user_no $m $feats $p -t $msisdn $c -v 1 -i $iter -L $outlevel /usr/local/clickatell/bin/routerd.conf &> /var/tmp/$fname 2>&1");

Обратившись к этому скрипту через админку, я понял, что PHP-программиста в этой конторе следует немедленно уволить . Переменная $user_no запрашивалась прямо из формы. Таким образом, ничто не мешало мне ввести в форму слово «;id;». И действительно, эта конструкция позволила мне обрести некий web-шелл, но уже на главном сервере.

Через полчаса я находился в консоли и бродил по каталогам главного сервера. Мои права были абсолютными, так как администраторы даже не удосужились обновить ядро в системе . Все базы проекта я также бережно забэкапил и сохранил у себя на компьютере. Я много раз рассказывал о том, как осуществлять бэкап из MySQL, поэтому даже не заостряю на этом внимания. Единственная сложность – мне приходилось очень долго искать нужный аккаунт, так как многие таблицы связывались внешним ключом по идентификатору пользователя. Таким образом, чтобы найти анлимитный аккаунт, мне надо было открыть таблицу с балансом, найти там пользователя с минусовыми кредитами, а затем запомнить его номер. Потом уже в другой таблице отыскать идентификатор и определить client-id и пароль юзера (по-видимому, там установлена старая версия MySQL, которая не поддерживает вложенных запросов. – Прим. ред.). Ну а после этого - залогиниться под анлимитчиком и отослать сотню-другую SMS-сообщений .

Тяжкие последствия

К сожалению, администраторы заметили мое пребывание на их серверах. Все мои айпишники прокси-серверов попали в бан-лист, админские пароли немедленно поменялись. К тому же, теперь сисадмы заставляют бедных пользователей менять их пароли на более сложные. Кроме этого, пассворды заносятся в базу уже в виде MD5-хэша, расшифровать который довольно проблематично.

Но, как известно, админ никогда не закрывает все баги . На данный момент ресурс до сих пор страдает SQL-инжекцией, а пароли на blog и mantis остались неизменными. Но даже эти незакрытые бреши уже не позволяют сливать новые дампы пользовательских таблиц и пользоваться анлимитными аккаунтами. Впрочем, быть может, кто-нибудь из читателей отыщет новые уязвимости, которые не удалось найти мне .
 
Ответить с цитированием