Первое, что делает хакер, заходя на машину - старается вычистить логи. С одной стороны это правильно, применяя логвайпер взломщик никогда не запалится. Но с другой стороны, хакер может забыть, что с помощью логов реально выудить полезную информацию, в том числе и рутовый пароль. Как? Зацени зарисовки реальных взломов, и узнаешь всю правду о таинственных журналах.

1. История - великая наука.

Пошел я как-то на Гугл - ловить жертв. Так я называю поиск бажных скриптов. Задал поиск только php-сценариев с содержанием слова 'html'. То есть, я захотел найти сервера, где существуют скрипты, включающие статические html. Во-первых, я имел возможность проверить жертву на cross-side, во-вторых на баг в include(). Внезапно я столкнулся со сценарием, который показывал содержимое файлов, находящихся в папке "content/". То бишь, ссылка выглядела следующим образом: http://host.com/view.php?path=content/data.html. Я решил изменить патч и вставил туда ../../../../../../../etc/passwd, но сервер отрапортовал "Access Denied" и загрузил дефолтовый контент индексной страницы. Тогда я подумал, что проверка проводится по наличию слова 'content/' и не ошибся. Исправив запрос на content/../../../../../../../../../etc/passwd, я получил желаемый результат - пароли были на экране.

Следующий шаг, который я выполнил - проверил порты на сервере. К моему счастью открытыми оказались 21 и 22 порты. Брутать аккаунт по известному логину - последнее дело, поэтому я решил воспользоваться помощью логов. "Но причем тут логи?", спросишь ты. В системе существует замечательный журнал команд под названием .bash_history, который располагается в домашнем каталоге пользователя. В /etc/passwd присутствовали 10 аккаунтов с валидным шеллом, поэтому осуществить поиск хисторей можно было даже вручную. С третьей попытки мне удалось выцепить содержимое .bash_history одного юзера (запросом http://host.com/viev.php?path=content/../../../../../../../home/user/.bash_history. Там были всякие неинтересные команды типа "vi test.c" и "gcc helloworld.c -o hello", но кроме этого я нашел инфу о том, что юзер активно использует ssh-клиент и лезет им в сторону локальной сети. Внезапно я увидел первый прокол - команду "ssj user@local.host.com", вслед за этой командой следовал пароль в ЧИСТОМ виде. Это самая распространенная запись, которая может встретиться в .bash_history :). Думаю, ты понимаешь, что после обнаружения пароля, я проверил его на правильность и без проблем зашел в систему. Но тут же ощутил, что мне не повезло - на машине крутилась стабильная фряха с ядром 4.9 :). Но не все так плохо - пользователь, права которого я получил, входил в группу wheel, посему имел право суидиться на рута (кстати, несколько команд su я узрел в .bash_history). Следующий лог, который я захотел изучить носил имя .mysql_history (лог кверизов к mysql). Выполнив команду grep -i pass .mysql_history, я получил строку, в которой юзер назначал права руту на все базы. Пароль передавался в качестве аргумента функции password() и выглядел очень впечатляюще (этакая строчка в 20 символов) :). Я опробовал пассворд через su и тут же получил нулевой uid.

Выводы: файлы .bash_history и .mysql_history имеют важное значение как для хакера, так и для админа. Взломщик может удаленно выцепить
конфиденциальные команды через бажный скрипт (нередко права на файл позволяют ему сделать это) и найти среди них пароли (это могут быть как аргументы вызова htpasswd, так и ввод пароля после ошибочных команд su и ssh). Второй файл может быть полезен, если хакер желает узнать пароль на определенную учетную запись. Файло необходимо проанализировать на наличие функции password() и строки 'indentifed by'. Админ может засечь неприметного взломщика по наличию посторонних команд в .bash(mysql)_history. Посему необходимо каждый раз выполнять команду unset HISTFILE, а также удалять историю запросов к БД.

2. Кривоватый радиус.

Как-то раз мне посчастливилось получить доступ к серверу, на котором крутился радиус. То есть сервак выполнял роль VPN-шлюза в какой-то сетке. Мои права на машине были жутко урезаны, но, несмотря на это, я очень хотел покопаться в расшаренных ресурсах локалки и опробовать VPN-подключение. Но, к сожалению, использовать снифер я не мог, поскольку мои привилегии не позволяли, да и расшифровывать MPPE я не умел :). В связи с этим у меня оставался лишь один вариант - посмотреть конфиги от радиуса, ибо они были вполне читабельными. И как ты думаешь, что я в них увидел? Конечно же полный логгинг юзера и
пароль (который, кстати говоря, рекомендуют включать только в режиме debug). Когда я перешел в /var/log/radius, то понял, что все радиусовые логи имеют пермишены 644! Это же надо быть таким идиотом, чтобы открыть драгоценные логи :). Пропарсив журналы я быстро нарыл 40 VPN-аккаунтов, среди которых были какие-то админские учетки. Оставалось лишь прицепиться со своей тачки и просканить локалку. К моему удивлению, в сети я нашел 3 виндовых сервера, в которых имелись дыры ASN.1 библиотеки. Весь мой вечер я занимался установкой VNC, изучением информации на серверах и т.д. и т.п. Словом, день прошел не зря :). И все благодаря логам.

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

3. Что Apache нам покажет?

И, наконец, последняя инфа о пользе логов. На этот раз админских. Было время, когда мне очень захотелось попасть в одну интересную админку, но к сожалению я не знал пароля. Надо сказать, что аутентификация была отнюдь не Апачевая, а скриптовая. То есть юзеру предлагалось ввести логин и пароль, после чего он перенаправлялся на скрипт проверки авторизации (все происходило с помощью метода GET). Потыкавшись в структуре сервера я чудом нашел каталог admin.host.com/logs/, где лежали 2 файла - access.log и error.log. Да, конечно, подобная вещь - редкость, но порой такие казусы случаются даже на весьма солидных порталах. Я слил access.log к себе на машину (журнал весил целых 10 метров) и стал его изучать. Внутри него я увидел обращения к скрипту, а также заветные параметры с логином и паролем. Зайдя внутрь я добрался до скриптов PhpMyAdmin и аплоадера файлов. Через второй сценарий я смог залить полноценный php-шелл. В общем то, история на этом и заканчивается, т.к. ядрышко на машине имело релиз 2.4.18 :).

Выводы: апачевые логи следует прятать от посторонних глаз хакеров, и не в коем случае не передавать логины и пароли методом GET (QUERY_STRING бережно логируется в access.log, что подтверждает мой рассказ). Вообще, всю конфиденциальную информацию лучше транспортировать через SSL, но некоторые особо одаренные админы до сих пор не понимают этого :). Часто в исходе удаленной атаки злоумышленник получает права nobody, которых хватает для прочтения access.log'а. Не вредно заглянуть и в error.log, бывает, что в STDERR запускаемых скриптов завалялся какой-нибудь пароль :).

4. Время собирать камни.

Итак, ты понял, что история запросов всегда поможет не только получить права юзера, но и взять нулевой уид. Кривой радиус способствует проникновению в защищенную локальную сеть, а access.log позволяет завладеть ключевым паролем к админке. Помимо этих трех взломов, могут иметь место и другие атаки с помощью логов, если журналы ведутся сторонними приложениями с записью всех юзерских обращений. В
конце концов, я не сказал о том, что пресловутый /var/log/wtmp всегда поможет тебе (то есть хакеру) определиться с логином, которому можно без проблем сменить пароль. Логи - самое ценное, что есть у хакера, и только они могут разрулить даже самую хреновастую ситуацию.

Check Also

Утекшие недавно личные данные граждан Болгарии уже появились на хакерских форумах

Личная информация граждан Болгарии, похищенная ранее на этой неделе, уже просочилась в отк…

Оставить мнение