SMS уведомления от Clickatell

SMS уведомления от Clickatell Информеры

Хакер № 09/05 (81)

Clickatell возвращается

Master-lame-master

Хакер, номер #081, стр. 081-050-1


Интересная история нового взлома Clickatell

Однажды мне захотелось привести свои данные в порядок. Думаю, многие меня поймут: если не упорядочивать информацию несколько месяцев, то структура накопителей превращается в неизвестно что. Именно такое месиво давно имело место на моем компьютере: в корне диска «Цэ» располагались пять или шесть папок с именами temp1, 111 и т.п. Медленно начав разгребать мусор, я даже не предполагал, что незатейливая уборка может привести к сокрушительному взлому известной корпоративной сети.

Утерянный комплект сценариев

Обычно, когда роешься в хламе данных, то находишь давно утерянную информацию. Так вышло и в этот раз: за полчаса уборки я успел обнаружить три mp3-шки, которые я в поте лица искал месяц назад, пару текстовиков с заснифаными паролями, а также несколько увесистых tar.gz-архивов, попусту занимающие место на моих накопителях. Но это были только цветочки. Мне посчастливилось найти папку с названием clickatell, в которой находился архивчик tar В последнем располагались все web-сценарии компании Кликатель. Если ты постоянный читатель журнала, то знаешь, что полгода назад мне удалось с лихвой порутать Клик и отправить на шару пару сотен SMS’ок .

Небольшое лирическое отступление: администраторы Clickatell приняли решительные меры против моего взлома: они заставили всех клиентов сменить свои пароли, впоследствии зашифровав их относительно стойким алгоритмом MD5. Помимо этого, администрация сменила все пассворды на закрытые зоны и забанили мои IP-адреса на центральном брандмауэре . Единственное, что я успел сделать, это спионерить с WWW-сервера архив, содержащий контент всех admin- и public-сценариев.

И вот, спустя долгие месяцы, я нашел этот архив. Внутри находились две папки: public и admin. Помнится, что благодаря архиву я отыскал дырку в скрипте админки, которая позволяла выполнять любые команды. На сегодняшний день по понятным причинам, в админку зайти было проблематично, поэтому было решено испытать удачу в public-части проекта. Я четко помнил, что админский скрипт содержал баг в функции exec(), которой передавались незаэкранированные переменные. Поэтому я осуществил поиск подстроки exec во всех сценариях архива. Результат меня просто ошеломил: exec вызывался в каждом втором сценарии. Однако, посмотрев содержимое файлов, я был разочарован: все переменные проверялись на наличие специальных символов и иных конструкций. Казалось, что программисты подошли к проблеме безопасности с умом: на первый взгляд исходники не содержали ни одного изъяна — код был продуман до мелочей. Но при просмотре очередного скрипта мои доводы быстро рассеялись. Мне посчастливилось обнаружить кусок кода следующего содержания:

[кусок бажной программы]

<?
$auth = new siteAuth();
$auth->checkAuth($login);
$user_no = $auth->getUserNo();
$cmd = '/usr/clickatell/compile -v';
if (isset($ota_type)&&$ota_type!=-1) $cmd .= " -t$ota_type";
if (isset($name) && $name != "" &&$ota_type == 1) $port != -1) $cmd .= " -C$port";
if (isset($isp_name) && $isp_name != "") $cmd .= " -I$isp_name";
if (isset($sms_smsc) && $sms_smsc != "") $cmd .= " -a$sms_smsc";
if (isset($gprs_access) && $gprs_access != "") $cmd .= " -G$gprs_access";
$ota_ret = exec($cmd);
?>

Даже непосвященный в PHP человек скажет, что код содержит большой изъян. Действительно, внешняя переменная $cmd вполне может содержать специальные символы, с помощью которых можно легко произвести атаку. Мне оставалось лишь найти этот сценарий в public-зоне онлайн-системы Clickatell. Зная название скрипта и примерную структуру компании, я быстро решил проблему. Подставив в поток нестандартное значение переменной $ota_type, я получил то, что и ожидал — результат выполнения команды uname -a.

Смотрите также:  Версии BILLmanager

Устраиваем притон на сервере

Далее все протекало по стандартному сценарию: я залил connback-шелл и зацепился на порт 4444. В консоли не было никого кроме меня, у американцев уже закончился рабочий день. Но взломать WWW-сервер было непросто — на машине стояло крепкое ядрышко из семейства 2.4, а также вертелась парочка незатейливых IDS. Чтобы порутать такой сервер, нужно было приложить немало усилий, что я и намеревался сделать.

Несмотря на всякие сложности, я горел желанием получить рута на этой операционке. Для этого, как обычно, я начал просматривать все каталоги на предмет нестандартных файлов, но большинство из них не читались с моими привилегиями. Но через полчаса удача мне улыбнулась: бороздя просторы папки /etc, я заметил, что конфиг crontab.hourly, weekly, daily и monthly вполне доступны для чтения! Это было немного странно, так как почти во всех системах, с которыми я имел дело, данные файлы не читались под правами nobody. Возможно, администратор просто перенес эти документы с другой машины, поэтому права на них выглядели нестандартно. Просмотрев все конфиги кронтаба, я получил массу дополнительной информации, которая помогла мне добиться успеха. Как оказалось, каждую неделю в воскресение, происходил бэкап всех данных на внешний носитель. После некоторой проверки оказалось, что дополнительный диск моунтится в точку /usr/local/clickatell/data, а все бэкапы содержатся в папке /backup. Зайдя в каталог data, я попытался прочитать директорию /backup, однако этого сделать не удалось — с папки был удален атрибут «выполнения». Но, зная премудрости системы Unix, мне удалось без труда вытащить нужный архив. Дело в том, что в файле crontab.weekly явным образом указывалось имя архива (home,etc,www-[date].tar.gz), поэтому обращение к архиву с запросом копирования в другой каталог увенчалось успехом.

Далее я приступил к распаковке архивов. Начал с home.tar.gz. Внутри находилось несколько домашних каталогов, но зайти в них мне не удалось — атрибуты, которые налагались на файлы, автоматически применились к распакованным данным. В голову пришла резонная идея: закинуть все бэкапы на WWW, а затем сливать их со сторонней машины. Но при попытке скопировать увесистый архив, система выругалась на превышение доступного дискового пространства. Чтобы не утруждать себя в пересоздании архива, я занялся небольшим по размеру архивом tar, где, по-видимому, располагались web-сценарии, шаблоны и прочая ерунда. Сперва я подумал, что этот архив аналогичен тому, который я слил полгода назад, однако ошибался. Внутри располагалось порядка десяти папок с различными конфигами, скриптами и картинками. И тут мне пришла в голову хорошая мысль — проверить php-инклуды на предмет паролей и другой конфиденциальной информации. Проверка показала, что в двух конфигах располагалась приватная инфа для подключения к БД. Причем, коннект происходил, как это обычно бывает, под рутовой учетной записью. Осталось проверить совпадает ли рутовый пароль для MySQL с системным. Для этого, по традиции я использовал утилиту ttyX (принцип ее работы я уже описывал в одном из «этюдов»). Запустив демон, я приконнектился клиентом, и получил эмулятор псевдотерминала. Затем осуществил суид на суперпользователя и… был наделен всеми возможными правами . Признаться, я не ожидал, что администратор установит один и тот же пароль на разные сервисы, хотя данное явление очень распространено среди всех админов.

Смотрите также:  Что такое DNS?

Укрепляемся в системе

Получив рута, я первым делом подумал о будущем. Мысль о том, что после создания халявного аккаунта с бесконечными SMS-кредитами, мне прикроют доступ на сервер, никак не радовала. Поэтому нужно было каким-то образом забэкдорить систему, либо облегчить механизм получения рутовых прав. Я решил сделать следующее: написать небольшой suid-шелл, дающий рута под правами любого пользователя, а также замаскировать connback-бэкдор под функциональный системный бинарник. Учитывая то, что на сервере был установлен tripwire, мне пришлось удалить два не совсем нужных бинарных файла, и заменить их на самопальные релизы . После этого с помощью команды touch, я установил неприметное время создания файла и на этом успокоился.

Затем мне в голову пришла еще одна мысль — попробовать добытый рутовый пароль в качестве входа на другие машины. Ах да, я совсем забыл сказать, что за машины были в подсети. Кликатель функционировал с помощью всего трех серверов: два из них были однотипными (www1 и www2), они обслуживали пользователей. Но запросы от юзера шли на центральный сервер, назовем его машиной-брандмауэром. Именно он пересылал пользовательские данные на один из двух обслуживающих серверов.

Так вот, я заюзал полученный рутовый пароль на серверах www2 и firewall, однако в обоих случаях в систему войти не удалось. Маловероятно, что администратор установил запрет на вход под рутовым аккаунтом — команда last на первом сервере показывала, что большинство входов осуществлялось именно под записью суперпользователя. Мне очень хотелось проникнуть на главную машину компании, поэтому я решил каким-то образом отловить пароль на этот сервер.

В этой ситуации у меня была нехилая свобода выбора: либо воспользоваться снифером, либо протроянить исходники ssh, или поставить какой-нибудь шпионский модуль. Я решил воспользоваться третьим вариантом, потому как первые два могли вызвать нестандартную реакцию IDS, располагающихся на машине.

Оцените статью
Все о IP и VPN
Добавить комментарий