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