Содержание статьи
Практически все знают, что желательно использовать уникальные пароли для каждого отдельного сервиса/сайта/компьютера, но почему-то многие на это забивают. И если рядовой пользователь, заводя всюду одинаковые пароли, рискует подарить свою учетку в соцсети нехорошим личностям, то администраторы ресурсов несут на своих плечах бремя ответственности не только за себя, но и за всех своих юзеров. Насколько хорошо они справляются с этими обязанностями? Пока не проверишь — не узнаешь. Вот как раз об этом и будет мой сегодняшний рассказ.
WARNING
Вся информация предоставлена исключительно в ознакомительных целях. Ни редакция, ни автор не несут ответственности за любой возможный вред, причиненный материалами данной статьи.Знакомство с пациентом
День первый. Зима, отпуск, быстро надоевшее безделье — все это подстегивало и толкало к поискам очередной разминки для извилин. К счастью, от безделья устал и мой приятель и попросил изучить на предмет безопасности один из дейтинг-сайтов, которыми занимаются его друзья. Пришедшие акционеры хотели понять, как обстоят дела с безопасностью, и дали полный карт-бланш на действия. Назовем этот сайт условно super-puper-dating.com, и расскажу я о том, как делал для него black box тестирование.
Окинув пациента беглым взглядом, я пришел к выводу, что сайт самописный и на нем активно используется mod_rewrite. К сожалению, поиск информации об ошибках в работе сайта через гугл ничего не дал — никаких warning’ов и ошибок мускула в выдаче не значилось.
Начав подставлять одинарные кавычки во все параметры, я убедился, что без регистрации ничего путного не выйдет. Хорошо, регаемся. После этого на почту упало стандартное письмо от веб-мастера с моим ником, пассом, кодом активации и ссылкой на остальные сайты в этой группе. Правда, остальные ресурсы интересовали меня меньше всего, так как до этого я уже успел побывать на замечательном сайте yougetsignal.com — простой, не требующий регистрации сервис, который, помимо прочего, предоставляет услугу Reverse ip domain check. Он выдал мне много интересной информации. Точность его показаний колеблется в районе 75–85%, чего, впрочем, вполне хватает.
Первые находки
К сожалению, хотя и вполне закономерно, 99% всех сайтов, находящихся на серваке, являлись одним движком, только с разными шкурами. Один ресурс представлял собой внутреннюю биллинг-систему для продажи услуг юзерам дейтинг-сайта. Бегло изучив «соседей» и не найдя ничего интересного, я решил залогиниться на сайт и продолжить свои попытки там. Перепробовав все что можно и не получив сколько-нибудь положительного результата, уже было собрался закрывать вкладку и переходить к следующему сайту знакомств, как в форме ответа на мессагу в форуме обнаружился баг. Он заключался в том, что при отправке ответа в ветку параметры не проверялись на наличие посторонних символов, в частности кавычки. Это был единственный найденный за это время баг, но он привел к получению всех, так нужных мне данных. Итак, подставив кавычку в запрос http://www.super-puper-dating.com/mega1forums/index.php?replyto=19335'&topic=true, я получил следующее:
Unknown column 'rsquo' in 'where clause' Topic Category:
и
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 '; or parenttopic=19335') and forumlang='en' order by topicid' at line 1что говорило о трудностях перевода для MySQL.
Подставив в запрос uninon select, я получил сообщение: The used SELECT statements have a different number, что, в свою очередь, указывало на несовпадение количества выводимых колонок в запросе. Всего их оказалось ровно 26, и часть из них выводилась на экран. Первым делом я решил проверить версию установленной СУБД:
http://www.super-puper-dating.com/megaforums/index.php?replytoid=-2+union+select+1,2,concat(user(),0x3a,version(),0x3a,database()),4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26&addtopic=false
Ответ меня очень порадовал — 5.1.61! Вот и все, осталось только узнать имена таблиц и колонок в них через information_schema. Недолго думая, я скомандовал: UNION SELECT 1,2,TABLE_NAME ,...,26 FROM INFORMATION_SCHEMA.TABLES. Увиденный результат меня крайне опечалил: CHARACTER_SETS. Данное значение говорило не только об идентификации набора символов для данного пользователя, но и о том, что записи в этом баге выводятся по одной. Хотя сам вывод данных, безусловно, был уже позитивным моментом. Короче говоря, классика.
К сожалению, пользователь, под которым крутилась эта база, не мог работать с файловой структурой, и поэтому возможность закинуть шелл и быстро слить базы отсутствовала. Ввиду ограниченности прав я не мог посмотреть и таблицу mysql.users. Что тоже очень печалило. Запущенный в фоне сканер папок и файлов обнаружил наличие директории phpMyAdmin на одном из сайтов на этом серваке, что давало призрачный шанс ускорить процесс получения базы. К пяти часам утра я уже знал о наличии таблиц с названиемbillingrecurring, ccbill и users. Последняя содержала в себе больше 200К записей, причем в открытом виде (кошмар!). А вот админок или каких бы то ни было CMS, использующих базу и позволяющих редактировать шаблоны, найдено не было. В общем-то, неплохой улов для одного дня, так что можно и отдохнуть, благо утро уже почти наступило.
Знакомимся с соседями
Наступил второй день, и я продолжил ковырять сайт. Как было сказано выше, был получен доступ к базам — и это уже можно было показать как результат работы, но хотелось дойти до конца! Вытягивать записи из БД по одной, конечно, можно, но это не оптимальный метод, и его хотелось бы оставить только на крайний случай. К тому же надпись в phpMyAdmin, гласящая «Доступ запрещен», честно говоря, немного напрягала.
С помощью who.is я решил посмотреть данные владельца ресурса super-puper-dating.com. Он оказался уже в другом домене — будем называть его puper-domain.com. По этим данным было легко найти его идентификатор на сайте (назовем его Иван) и через скулю вытащить пароль. Идея простая: можно попробовать использовать пароль для почтового ящика (как показывает практика, владельцы даже крупных проектов тоже люди и тоже любят одинаковые пароли). Если бы пароль подошел, то в ящике могут быть данные для подключения к super-puper-dating.com. Пароль у Ивана оказался довольно непритязательным — god5it (как видишь, он до жути прост и нарушает все существующие законы создания безопасного пароля). Пароль подошел и к почте! Но, войдя в почтовый ящик, я увидел лишь папочку Junk, где лежал спам и больше ничего :(.
Ну да ладно, у меня еще была куча возможностей в виде сервера с доменом puper-domain.com. В первую очередь я проверил, есть ли у него соседи. Таковых оказалось около сорока. Неплохо, где-то явно должен быть баг. Полазив по сайтам десять часов, я нашел какую-то самописную CMS, с наполовину интегрированным WYSIWYG-редактором, папкиwebmail и urchin. При заходе в папку webmail меня перебрасывало в панель управления, а незапароленный urchin показывал статистику посещений сайтов. Там же я нашел и обращения к папке editor_files, где лежали файлы WYSIWYG-редактора. Однако уязвимым оказался только скрипт dialog_frame.php, который выводил на экран содержимое.htaccess, но показывать содержимое файлов с расширением php или файлов, находящихся в вышележащих каталогах, он отказывался напрочь. При изменении языкового файла данный скрипт выдавал сообщение об ошибке, которое выражалось полным раскрытием пути, его я получил и при обращении к другим файлам этих сайтов, но никакого чтения/записи так получено и не было. На этом я приостановил занятия, так как пришло время катания на коньках.
В гостях у puper-domain.com
День третий. Повторный проход по сайтам ничего нового не принес. И тогда я решил попробовать пасс с дейтинга на FTP на puper-domain.com, благо к почте он подошел. Как я говорил, мне удалось получить полное раскрытие пути, как правило содержащее в себе и имя учетной записи, из-под которой происходит вызов скрипта. Ранее запущенный Nmap услужливо сообщил мне, что все интересующие любого хакера порты светятся, как зеленый сигнал светофора, и никаких ограничений по IP не предусмотрено. Так как у меня была одна учетная запись и один пасс, я скомандовал своему FTP-клиенту
open 3.1.3.37
user:ivan
pass:god5it
и в ответ получил всего два слова: Login successful. Это меня одновременно удивило и обрадовало.
Как правило, внутренняя защита подобных проектов практически сведена к нулю, и дело здесь вот в чем. Над проектом работает от одного до десяти человек, и все они нацелены на общий результат, а создавать несколько аккаунтов с разными паролями администраторам (владельцам сайтов) сервака, как это обычно бывает, — лень. В данном случае админ был один, а это оказался его тестовый сервер, где он создавал свои и чужие проекты. Вот так мы и получили, что хотели, — читается практически все, включая папку root. Быстренько закинув веб-шелл, я увидел свои права uid=80(apache) gid=80(apache) groups=80(apache). Полазив по файловой системе, нашел достаточное количество конфигов с пассами, записал их в один файл для дальнейшего аудита. Надо сказать, что на этом сервере крутились разные самописные магазины и, соответственно, конфиги для подключения к биллингу :). Перед самым уходом заглянул в папку к руту и в подпапке backup обнаружил дамп базы MySQL со всеми ее пятнадцатью пользователями.
Также не был забыт и файл passwd из каталога /etc. Все это было нужно для дальнейшего анализа, ведь данных для подключения к интересующему меня серверу на этом компе я не нашел. идем напролом
Завершив FTP-сессию, я запустил PasswordsPro, загрузил добытые MySQL-хеши, а также добавил новый пасслист, который содержал в себе все найденные мною на втором сервере пароли.
Для восстановления исходных пассов был выбран режим гибридной атаки по словарю. И уже через две минуты брутер открыл 2/3 расшифрованных пассов, в том числе и root-пароль:god5it123. Таким образом, у меня было уже около тридцати пассов, включая два пасса, созданных по маске, Dr@upa7132и Br@iti123.
Расколотые хеши — это, конечно, замечательно, но они были не от интересующей меня машины. Поэтому я решил сгенерировать новые пароли на основе уже найденных и применить их по назначению, то есть для попытки логина на машину с дейтинг-ресурсом. Генерация пассов с моей стороны заключалась в следующем: берем первые две буквы доменного имени (первую делаем заглавной), затем символ @, после этого еще три буквы доменного имени и в конце маска чисел 123 и 7132. Ну что же, тестовые пароли есть, осталось найти валидных пользователей с первого сервера. Учитывая, что оба сервака относились к одному хостинг-провайдеру, можно было предположить, что создание учетных записей на основной и дополнительной машине будет одинаковым. Поэтому я открыл/etc/passwd, взятый с puper-domain.com, и посмотрел список пользователей. Среди системных юзеров находились и пользователи, имена которых являлись названием сайтов, точно так же, как и та учетная запись, к которой подошел пароль god5it.
Теперь у меня появилась хоть и довольно призрачная, но теоретически обоснованная возможность проникновения на целевую машину. Открываю yougetsignal.com, вбиваюsuper-puper-dating.com, получаю список сайтов, убираю у всех доменную зону и получаю порядка сотни возможных учетных записей. Создав комболист и загрузив его в brutus, выставляю поиск пользователей по FTP. Сам же тем временем, не особо рассчитывая на удачу, начинаю искать хостинг-провайдера и регистратора доменов с интересующим меня имененм. Он нашелся довольно быстро. Это была компания, которая предоставляла не только регистрацию доменных имен, но и услуги хостинга. С третьей попытки логин оказался удачным, подошел рутовый пасс от мускуля тестовой машины. Как оказалось, Иван является VIP-клиентом этой конторы и имеет 205 доменов на борту.
В это время тихонько тренькнул brutus, сообщив мне, что свою часть работы он выполнил на отлично. Да, действительно, одна из предложенных мной комбинаций оказалась верной. Причем за реально существующее системное имя пользователя отвечал сайт биллинг-системы, что тоже выглядит вполне логичным. Остальное было уже делом техники: снова был залит r57shell, сервер был изучен и найдены конфиги для соединения с БД.
После этого послушный phpMyAdmin отдал мне полный дамп базы users в течение пяти минут. К этому моменту у меня были полные доказательства, что безопасность в текущем виде никуда не годится, на этом я прекратил все дальнейшие манипуляции и убрал за собой.
Мои помощники
Итак, давай подведем итог, что помогло мне проникнуть на сервер:
- Одинаковые пароли. Никогда не используй одинаковые пароли для FTP, SSH и прочих ресурсов, в том числе и тестовых. А уж оставлять свои реальные пароли на тестовом сервере я вообще считаю преступлением. В нашей истории пароль Ивана на сайте знакомств полностью совпал с учетной записью на FTP, поэтому в целях безопасности рекомендую тебе всегда использовать уникальные пароли, а не создавать их по маске.
- Вывод ошибок. В журнале уже неоднократно писалось о том, что раскрытие пути в некоторых ситуациях может скомпрометировать систему. Именно так и получилось в данном случае. Не зная единственной учетной записи, я не смог бы проникнуть внутрь, даже имея на руках валидный пароль.
- Хакер, пентестер, да и любой человек должен хорошо запомнить поговорку: один раз — случайность, два — закономерность. Знание таких базовых истин позволяет совершать большие дела. Именно выявление закономерности позволило мне сгенерировать корректный пароль.
Заключение
Как ты смог увидеть на примере этой истории, именно использование одинаковых паролей оказалось фатальной ошибкой, которая позволила мне получить доступ к данным более чем 200К пользователей сайта. Поэтому, регистрируясь где-либо, прими для себя за правило считать этот ресурс уязвимым и придумывать для каждого уникальный пароль. Проще всего это делать с помощью менеджера паролей, например, LastPass. И самое главное, помни, что за свою безопасность в Сети отвечаешь ты сам! Как бы нам ни хотелось обратного, но сейчас даже главы государств под колпаком, а что уж говорить про нас.
