Главная
Статьи
Чат
Форум
Гостевая
 


ВНИМАНИЕ:
Вся информация размещенная на этом сайте предназначена в целях ознакомления.
Администратор сайта не несет ответственность за использо- вание этой информации.



Мозговой штурм Финляндии

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

Вся история началась с посещения одного зарубежного ресурса (не буду уточнять, какого), который специализировался по некоторым интересным услугам. Все бы ничего, да вот только пропускал он лишь избранных клиентов. Зайдет, скажем, хакер с американской прокси на страницу регистрации, аккуратно заполнит все поля, а подлый скрипт напишет, что домена нет в списке разрешенных. Я долго ломал голову, пока не кликнул по ссылке "About". Там черным по белому было написано, что посещать ресурсы портала разрешено жителям Франции, Италии и... Финляндии. К сожалению, у меня не было прокси-серверов из вышеперечисленных стран, поэтому мне захотелось найти бажный сервер в какой-нибудь доверенной стране и проверить его на безопасность. Начал я со страны Микки Хаккинена - не терпелось посмотреть на горячих финских сисадминов в работе.

Роковые исходники
Первым делом я начал ворошить Веб. Поиск бажных скриптов - занятие несложное, для взлома не нужно прибегать к помощи специальных эксплойтов, поэтому у меня был вполне реальный шанс поймать удачу за хвост. В качестве поисковой системы я заюзал google.com. Этот поисковик обладает гибкими настройками, поэтому идеально подходит для сканирования уязвимых сценариев. Я воспользовался поисковыми выражениями site и filetype, которые определяли домен и расширение файла соответственно. Стоило мне оформить запрос в виде site:fi filetype:cgi, как поисковик выдал множество ссылок на различные скрипты. Почему cgi? Да просто потому, что именно в этих сценариях чаще всего встречаются глупые ошибки. Последовательно открывая каждый сайт в домене fi, я насиловал параметры скриптов, надеясь, что у какого-нибудь сценария сорвет крышу :).
Но удача не спешила мне улыбаться. К тому моменту, когда я дошел уже до 10 страницы, не было найдено ни одного бажного сценария. Возможно, я уже устал и потерял бдительность, а может, скрипты действительно были бронебойными. В любом случае, я еще не сканировал сервер на скрипты pl и php, поэтому повода для грусти пока не было.
Наконец, мне посчастливилось наткнуться на один из серверов финской математической академии. Это было сразу видно по названию, а потом и по содержанию сайта. Скрипт назывался source_gsl.cgi. Он выполнял функцию вывода на экран исходника, переданного в качестве параметра. В моем напряженном мозгу тут же закралось подозрение на то, что в сценарии отсутствует проверка на пайп, null-байт и другие злые вещи. Но догадку надо было проверить.
Запрос на выполнение команды был сразу отклонен. Вместо вывода от бинарника id на экране царила пустота. Я попробовал вывести ../../../../../etc/passwd%00, но запрос также успешно отфильтровался. Потом попробовал убрать нулевой байт и обновить страницу. Надо же, какой конфуз - файл успешно отобразился на экране. Ну вот, еще один горе-кодер. Однако радости от этого мне было мало - одной читалкой файлов много не сделаешь. По крайней мере, прокси-сервер точно не поставишь. Я это прекрасно понимал, но сдаваться даже не думал ;).
Сила перебора
Я попробовал соединиться с 22 портом математического шелла. Соединение не фильтровалось. Первое, что пришло в голову, - попробовать сбрутить себе рабочий аккаунт. На самом деле такой шаг себя оправдывал - файл passwd содержал порядка 50 аккаунтов, поэтому вероятность подбора пароля была большая. Разумеется, я не хотел перебегать по словарю - этот процесс затянулся бы на долгие дни. Решено было попробовать пару login:login в качестве системного аккаунта. Для этого я сохранил passwd в отдельный файл и написал небольшой парсер на perl, который генерирует комбо-лист. Затем этот файл будет скормлен какому-нибудь переборщику.

Комбо-лист для Финских паролей
#!/usr/bin/perl
$in=$ARGV[0];
$out=$ARGV[1]; ## Определим параметры скрипта
exit print "Use $0 $in $out\n" unless ($out);
open(IN,"$in");
open(OUT,"> $out");
while(<IN> ) {
chomp;
if (~/sh$/) { ## Запишем только валидные аккаунты
($u,@undef)=split ":";
print OUT "$u:$u\n"; ## В виде пары login:login
}
}
close(IN);
close(OUT);

Скрипт прост, как две копейки, это видно по исходнику. Что примечательно, сценарий парсит только аккаунты с валидными шеллами. Другие мне на фиг не нужны. Было решено брутать программой Brutus под Винду. Прежде чем что-то запускать, мне потребовалось оформить комбо-лист и проверить баннер FTP-сервиса. Когда все было сделано, я запустил процесс перебора. Интуиция меня не подвела, и уже через минуту у меня был сбрученный аккаунт. Быстро прочекав операционку, я понял, что на сервере крутился старенький RH 7.2 с бажным ядром 2.4.24. Думаю, не стоит говорить, каким эксплойтом я поднял свои привилегии, - все понятно без слов. Однако у меня был печальный опыт, связанный с установкой руткитов на RH 7.0-7.2. После инсталляции бинарники начинали жутко глючить, что заставляло администраторов задуматься о безопасности :). Поэтому было решено использовать старый дедовский прием, который заключался в создании суидного шелла в комплекте с логвайпером. Содержимое такого нехитрого бэкдора не раз приводилось на страницах Х, поэтому повторять его код не стану. Я обозвал свое творение именем "at" и закинул его в /usr/bin. Теперь нестрашно, что на бинарнике будет светиться суид, - ведь софтина at требует дополнительных привилегий. В качестве логвайпера я выбрал утилиту Vanish2 (ты должен знать про этот чудесный клинер). Когда все логи были подчищены, я прочитал файл /proc/cpuinfo и узнал, что на этой тачке стоит хороший камень частотой 1500 MHz и воткнуто полгигабайта памяти. Отлично, тут созданы просто тепличные условия для хакерского плацдарма - теперь есть где запускать ресурсоемкие приложения :). Но это все вопрос будущего, сейчас же мне нужно было получить доступ к приватному ресурсу ради которого, собственно, и была заварена эта каша.
Полосатые носки атакуют
В качестве проксика я решил поставить пятые соксы, чтобы юзать не только прелести WWW, но и другие сервисы. Для этого я скачал архив (ftp.cdut.edu.cn/pub/linux/network/server/socks5/socks5-v1.0r5.tar.gz). Быстро скомпилив socks5 в домашний каталог, я оформил конфиг ~/socks/etc/socks5.passwd, в который вписал тестовый логин и пароль для соединения. Теперь мне предстояла работа по составлению рабочего конфига носков. На самом деле достаточно написать всего две строки, и соксы будут авторизовать юзера по заполненному паролю. Строки в ~/socks/etc/socks5.conf выглядит следующим образом:

auth - - u
permit u - - - - -

Это означает, что сокс будет авторизовать юзера по паролю, а также разрешать коннекты на любые хосты и порты. То, что доктор прописал :). Осталось лишь переименовать файл ~/socks/bin/socks5 во что-нибудь невзрачное и запустить его.
После того как я заюзал носки, скрипт успешно зарегил аккаунт в системе и дал мне возможность стащить важные документы. Когда главная цель была выполнена, стало можно приступать к взлому финской локалки.

Воруем ключи
Сперва я запустил mc и стал бродить по папкам в поисках ценной информации. Я мониторил истории команд, логи httpd-запросов, но ничего путного не обнаружил. Мне очень хотелось забраться на другие тачки в сегменте. Я набрал команду locate known_hosts, чтобы узнать, какие юзеры любят путешествовать по SSH-протоколу :). В итоге выяснилось, что 4 пользователя юзают SSH. Однако ни одного ключика не было найдено :(. Внезапно мое внимание привлек интересный каталог /mnt/backup. В этой директории располагался бэкап системы. Но не того сервера, которым я овладел, а какого-то иного. Разумеется, locate не ищет файлы в папке /mnt, поэтому я не знал, находятся ли файлы с именем known_hosts в каталоге с бэкапами. Оказалось, что находятся. Прошвырнувшись по домашним каталогам, я обнаружил, что у юзера arasila помимо списка хостов имеются и авторизационные ключи. Мне хотелось проверить валидность этих ключиков для соседних серверов. По всей видимости, на этих тачках должны находиться аналогичные приватные ключи.
Прежде чем действовать, я аккуратно забэкапил рабочий каталог .ssh у юзера arasila, и лишь затем перенес туда файлы с другой машины. Теперь можно выполнять su - arasila и соединяться с хостами по ключу. Однако меня поджидал крутой облом: кей был защищен паролем, который не позволял соединиться с узлом.
Но все оказалось не так уж и плохо. Я вспомнил, что существуют тулзы, которые умеют перебирать пароль SSH-ключа. Одна из них выпущена командой THC и находится тут: www.thc.org/root/tools/thc_ssh_crack.c. В этой софтине юзаются функции SSL, которые пытаются вытащить приватный ключ из файла. Если им это не удается, значит, пароль неверный и перебирается другое слово. Недолго думая, я слил эту тулзу, скомпилил с параметром -lssl и запустил перебор по словарю. К сожалению, брутфорс не принес никаких успехов. Но что-то заставило меня прочитать исходник tch_ssh_crack.c и увидеть там рекомендацию по взаимодействию брутфорсера и известного John'а The Ripper'а. Дело в том, что Джоник является неплохим генератором паролей, которые можно использовать в качестве эталонных. Эта идея мне очень понравилась, и я решил воплотить ее в жизнь. Для этого мне пришлось перенести ключ на другой сервер, где уже стоял Джон, и осуществить симбиоз двух брутфорсеров. Строка запуска выглядела следующим образом:
./john -stdout -incremental | nice -10 ./crack id_dsa
Команда nice повышает приоритет второго брутфорсера, что уменьшает время процесса. Поразительно, но уже через 20 минут Джоник подобрал пароль к ключу. Теперь я смогу соединиться с другими серверами, принадлежащими академии, без знания пароля! К моему счастью, публичный ключ действительно находился на другой стороне, поэтому я без проблем залогинился на другой машине. Там также вертелся RH 7.2, видимо, финны очень любят однообразие :). На трех порутанных хостах я поставил соксы, объединил их в цепь и еще долго пользовался ей в своих грязных целях.

Институт - источник халявы
Взлом серверов академии принес мне большую пользу. Дело в том, что все госучреждения юзают инет на халяву, поэтому я мог без проблем прокачивать варез через финский сервер. Как выяснилось позже, за машинами толком никто не следил, они располагались на стенде для студенческих проектов, поэтому юзались лишь для компиляции и тестирования исходников. Поэтому мне даже не пришлось прикрывать свой IP-адрес в netstat'e и хайдить лишние процессы.

Что помогло хакеру при взломе?
1. После того, как хакер увидел /etc/passwd, он решил перебрать пары login:login. Это решение не было случайностью - когда на сервере прописано слишком много пользователей, вероятность совпадающего пароля далеко не нулевая.
2. Даже самопальный руткит может надолго прикрыть задницу хакера. Действительно, зачем ставить полный комплект бинарников, когда за сервером толком не следят? Можно ограничиться суидным bash и простым логвайпером.
3. Взломщик захотел пощупать и другие серверы в академической сетке. Для этого ему пришлось решить нелегкую задачу: найти private key, расшифровать пароль и заюзать ключ для соединения.

Волшебная сила ключей
Использовать ключи для соединения гораздо удобнее, чем доверяться паролям. Дело в том, что если пользователь юзает ключ, никто не сможет соединиться с шеллом с левой машины. Исключение описано в этом взломе - если доверенную тачку порутал хакер, он легко может соединиться и с другими серверами. Именно поэтому пользователи создают ключ, защищая его так называемой ключевой фразой. Только после ее ввода ssh-клиент получает содержимое ключика. Создать ssh-ключ очень просто. Рассмотрим организацию соединения по SSH2 DSA-ключику. Для этого выполни команду ssh-keygen -t dsa. Бинарник спросит у тебя парольную фразу и местоположение ключей. Когда он закончит свою работу, скопируй содержимое файла id_dsa.pub в authorized_keys2 (все операции проводятся в папке ~user/.ssh). Теперь переноси публичный ключ и authorized_keys2 на машину, с которой ты будешь соединяться. Пожалуй, все. Юзай стандартный клиент ssh, который соединит тебя с удаленным узлом без ввода пароля.

Hosted by uCoz