Frage:
Umgehen des in / etc / passwd angegebenen Befehls / Skripts
M.S. Dousti
2018-08-20 16:28:00 UTC
view on stackexchange narkive permalink

Betrachten Sie die folgende Zeile aus / etc/passwd :

  sadeq: x: 1000: 1000: Mohammad Sadeq Dousti ,,,: / home / sadeq: /bin/custom-script.sh 

Der letzte Teil, /bin/custom-script.sh , zeigt den Befehl / das Skript, der bzw. das ausgeführt werden soll, wenn der Benutzer meldet sich beim System an. Derzeit ist es ein einfaches Bash-Skript, das dem Benutzer ein Menü anzeigt und die möglichen Befehle, die er ausführen kann, effektiv einschränkt.

Oder ich hoffe es! Möglicherweise gibt es eine Möglichkeit, wie Benutzer custom-script.sh umgehen und direkt auf Bash zugreifen können. Dann können sie jeden Befehl in ihrem Benutzerkontext ausführen.

Gibt es eine Möglichkeit, das obige Bash-Skript zu umgehen und andere Befehle auszuführen?

Bearbeiten: Betrachten Sie den folgenden einfachen Fall als custom-script.sh :

  #! / bin / bashecho Wie heißen Sie? Lesen Sie nameecho Hallo $ name  
Zuerst würde ich versuchen zu überprüfen, ob es eine Möglichkeit gibt, ".bashrc" oder ".bash_profile" zu überschreiben.Entweder durch Flucht vor Tricks oder durch einen Trick mit Umgebungsvariablen.Zweitens würde ich prüfen, ob es vielleicht eine Möglichkeit gibt, Umgebungsvariablen einzufügen.Aber wahrscheinlich würde keiner von ihnen funktionieren, Ihr Skript ist dafür zu einfach.Übrigens würde ein "Echo" Hi $ name "in der letzten Zeile viel besser aussehen!
@peterh: Die Verwendung von doppelten Anführungszeichen gemäß Ihrem Vorschlag scheint das von Dmitry Grigoryev in seiner Antwort unten erwähnte Problem zu verhindern.Vielen Dank!
Fünf antworten:
#1
+44
DrSheldon
2018-08-21 03:32:48 UTC
view on stackexchange narkive permalink

Angenommen, es gibt eine (wahrscheinlich unbeabsichtigte) Hintertür.

Der Standardwert / etc / passwd auf Sun-Workstations der frühen neunziger Jahre enthielt einen Eintrag wie den folgenden:

  games :: 0: 0: games: / nopath: / bin / false  

Mit anderen Worten, ein Konto mit dem Namen "games" ohne Passwort. Anscheinend hatte das Genie, das auf diese Idee kam, keine Vorstellungskraft und wies ihr eine UID und GID von Null zu (d. H. Wurzel und Rad). Im Allgemeinen war das in Ordnung, da das Home-Verzeichnis bedeutungslos war und die Shell auf ein Programm eingestellt war, das immer mit einem Fehler beendet wurde. Darüber hinaus wurden die Standardeinstellungen für den Zugriff über das Netzwerk - Telnet, Rlogin, RCP, FTP - festgelegt, um den Zugriff durch eine UID von Null zu verhindern. Es gab einen separaten passwd-Eintrag für root mit einem ordnungsgemäß festgelegten Kennwort, einem Home-Verzeichnis und einer Shell.

Wenn Sie sich als Spiele anmelden wollten, würde Folgendes passieren:

  • Die Anmeldung als Spiele an der Konsole würde zunächst erfolgreich sein, dann aber die Shell / bin / false erzeugen, die sofort beendet wird.
  • Verwenden von Telnet oder rlogin würde die Anmeldung sofort ablehnen. Selbst wenn dies erfolgreich gewesen wäre, würde die Shell / bin / false sofort beendet.
  • FTP und scp verwenden keine Shells, aber sie wurden so konfiguriert, dass der Zugriff auf UID Null verweigert wird. Sie konnten sich also nicht auf diese Weise anmelden.
  • Bei einer GUI-Anmeldung werden die Standard-GUI-Dienste gestartet, einschließlich eines Fenstermanagers, eines Clock-Clients und eines Terminals. Letzteres würde sofort beendet, da seine untergeordnete Shell sofort beendet würde. Sie würden also bis auf eine Uhr einen leeren Bildschirm erhalten. (Mehr dazu weiter unten ...)
  • Wenn Sie sich wirklich als root anmelden müssten, müssten Sie dies entweder über die Konsole oder zuerst über rlogin / telnet as tun ein anderer Benutzer auf diesem Computer und dann su root . In beiden Fällen wird der Root-Eintrag passwd anstelle des Eintrags passwd für Spiele verwendet und funktioniert daher so, wie root funktionieren sollte.

Das Spielkonto schien also immer zu scheitern, es sei denn, Sie haben sich über die GUI angemeldet. In diesem Fall erschien nur die Uhr. Sie können jedoch mit der rechten Maustaste auf den Hintergrund klicken, um ein Stammmenü mit einer werkseitig bereitgestellten Liste von Programmen aufzurufen, die Benutzer normalerweise für sich selbst anpassen würden. (Das Anpassen des Menüs hat für das Spielekonto nicht funktioniert. Ich weiß nicht genau, warum.) Sie könnten versuchen, mehr Terminalfenster aufzurufen, die alle fehlschlagen würden. Es gab ein Puzzlespiel (was möglicherweise in erster Linie der Anstoß für das Konto war). Eine andere Möglichkeit war, sich abzumelden. Und dann war da noch das grafische Debugging-Tool dbxtool .

dbxtool war ein grafisches Frontend für den symbolischen Debugger dbx . ähnlich dem heutigen gdb . Da UID Null ist, können Sie jeden Prozess auf dem System anhängen und steuern, obwohl dies nicht hilfreich war, da von Sun bereitgestellte Programme ohne Symbole kompiliert wurden. Sie könnten eine Shell starten, dies würde jedoch Ihre Umgebungsvariable SHELL verwenden, die / bin / false war. Sie können jedoch auch Umgebungsvariablen ändern! Dies bedeutete, dass Sie eine Root-Shell wie folgt erhalten konnten:

  1. Melden Sie sich über die GUI als Spiele ohne Passwort an.
  2. Klicken Sie mit der rechten Maustaste, um das Root-Menü aufzurufen.
  3. Starten Sie einen dbxtool .
  4. setenv SHELL / bin / sh
  5. (optional) setenv HOME /
  6. Starten Sie eine Shell mit !
  7. Da das Terminal nicht eingestellt ist, führen Sie stty sane code aus >
  8. ol>

    Voila, Root-Shell ohne Passwort!

    Gehen Sie also nicht davon aus, dass ein Benutzer nicht aus einer ungültigen Shell entkommen kann.

Sehr interessant zu schreiben!Aber was ist mit einer gültigen Login-Shell?
@ThoriumBR: Jedes Programm, das einen "Execve" -Aufruf mit vom Benutzer angegebenen Parametern ausführen kann, sollte als verdächtig angesehen werden.Dies umfasst Shells, Skriptsprachen, das in der Antwort erwähnte vom Benutzer anpassbare Stammmenü und alles mit einem "Shell-Escape" (wie "more" oder "vi").
* Jedes Programm, das einen "Execve" -Aufruf mit vom Benutzer angegebenen Parametern ausführen kann. * Dazu gehören Anmeldeskripte, die benutzergesteuerte Dateien wie ".bashrc" enthalten, aber nicht darauf beschränkt sind.
Etwas ist sehr seltsam.In den aktuellen Büchern wird beschrieben, wie Sie eine Anmeldung deaktivieren (Shell in / bin / false ändern), z. B. aufgrund von SSH-Schlüsseln.Als ich auf einer moderneren Benutzeroberfläche etwas Ähnliches ausprobierte, stellte ich fest, dass Ihre Shell zum Zeitpunkt der X-Anmeldung ausgeführt wird. Wenn Ihre Shell keine echte Shell ist, werden Sie sehr schnell abgemeldet.Ich denke, was passiert, ist, dass das Login die GUI-Umgebung durch "shell -lc guienvprogram" erzeugt.
@Joshua: Sun verwendete anstelle des generischen X11 einen eigenen proprietären Anzeigeserver (NeWS).Es wurden Prozesse direkt über den Systemaufruf "execve" gestartet, anstatt eine Shell zu starten.
#2
+27
ThoriumBR
2018-08-20 17:01:12 UTC
view on stackexchange narkive permalink

Sie können die Skriptausführung nicht umgehen. Dies ist Ihre Login-Shell und wird jedes Mal gestartet, wenn Sie sich anmelden. Und als Login-Shell werden Sie bei jedem Ende abgemeldet. Sie können jedoch Macken, Fehler und Inkonsistenzen in der Anmeldeshell verwenden, um zu entkommen.

Sie können mit einer beliebigen Option im Menü zu einer Shell entkommen. Wenn Sie im Menü vim , less , more oder einige andere Befehle starten können, können Sie sich theoretisch befreien. Wenn der Systemadministrator erfahren ist, verwenden diese Befehle ihre eingeschränkten Versionen und funktionieren nicht.

_ "Sie können die Skriptausführung nicht umgehen." _ So sicher sind Sie .Das hat mich [googeln] gebracht (https://www.google.com/search?q=linux+bypass+login+shell): viele Anekdoten, CTF-Herausforderungen usw., bei denen sshd auf eine Weise falsch konfiguriert ist, mit der Sie umgehen könnendie Login-Shell ([manchmal sogar die Standard-SSH-Konfiguration der Distribution!] (http://commandline.ninja/2012/05/06/binfalse-sbinnologin-and-ssh/)).Also ist dies eines der Dinge, die "theoretisch in Ordnung sind, wenn Sie es richtig machen, aber in der Praxis gefährlich"?
Der letzte Link befasst sich mit dem Erstellen eines Tunnels und nicht mit dem Anmelden. Bei den meisten Lösungen wird "sudo" verwendet, wenn sich ein anderer Benutzer im System befindet.Und ich konnte bei dieser Google-Abfrage nichts Interessantes finden.Möchten Sie einen Weg zur Umgehung der Login-Shell teilen?Es wird eine schöne Ergänzung zu meiner Bibliothek sein!
Ja, wenn wir "Bypass the login shell" als _ "Shell-Zugriff auf dieses System über ssh erhalten" _ definieren, stimme ich Ihnen zu: Mir ist nichts bekannt.Für eine etwas breitere Definition _ "Lassen Sie das System etwas anderes tun, als es die Anmeldeshell zulässt" _, ist möglicherweise mehr Härtung erforderlich, als nur die Anmeldeshell der Benutzer festzulegen. Ihre Antwort ist gut, ich wollte nur darauf hinweisen, dass es einen jr gibt.Sysadmin-Falle lauert hier!
#3
+15
Elhitch
2018-08-20 17:01:33 UTC
view on stackexchange narkive permalink

Ich erinnere mich an eine Wargame-Herausforderung, bei der es einen ähnlichen Fall gab - die Shell zeigte auf etwas, das einfach eine Ausgabe mit dem Befehl more druckte und dann die Sitzung beendete. Da more jedoch über einen integrierten Texteditor verfügt (in diesem speziellen Fall war es vi), reichte es aus, die Größe des Terminalfensters, über das Sie eine Verbindung hergestellt haben, so zu ändern, dass more aktiviert ist, und es dann zu verwenden um der Shell zu entkommen.

Die Antwort hängt also davon ab, was Ihr Skript tut. Überprüfen Sie die Manpages für jeden Befehl, den Sie ausführen, um eine Sicherheitsanfälligkeit zu vermeiden.

Und versuchen Sie es mit `! Xclock`, während Sie die` man` Seite lesen!
#4
+8
Dmitry Grigoryev
2018-08-21 12:33:10 UTC
view on stackexchange narkive permalink

Mit dem von Ihnen veröffentlichten Beispielskript kann der eingeschränkte Benutzer beispielsweise viel über das System lernen, z. B. Namen anderer Benutzer und installierte Programme. ZB

  Wie heißt du? > / home / * Hi / home / foo / home / bar / home / sadeq  

Das aktuelle Skript, das du hast kann auf ähnliche Weise ausgenutzt werden, möglicherweise bis zu dem Punkt, an dem der Benutzer einen echten Shell-Zugriff erhalten kann.

Sie könnten die Situation wahrscheinlich verbessern, indem Sie das Anmeldemenü in einer Sandbox-Umgebung starten: Dies ist nicht unbedingt der Fall 100% kugelsicher, aber zumindest Sandboxing wird eine ganze Reihe von Sicherheitslücken schließen, die der Autor des Skripts möglicherweise hinterlassen hat.

@TobySpeight Ich glaube nicht, dass eine Befehlssubstitution nach einer Variablenerweiterung ausgelöst werden kann
Du hast recht (diesmal habe ich getestet!) - das ziehe ich zurück.
#5
+4
dtrizna
2018-08-20 18:54:31 UTC
view on stackexchange narkive permalink

TLDR: Das erwähnte Skript ist sicher!

Wenn Sie jedoch verstehen, dass Sie in der Produktion möglicherweise eine andere Version verwenden, sollten Sie die folgenden Konzepte kennen:

1 Gibt an, ob das Lesen für die Befehlsinjektion anfällig ist. Wenn es anfällig ist, dann 'Name' Wert wie 'Bob; cat / etc / passwd ' könnte den Inhalt der passwd-Datei zurückgeben und ' Bob && / bin / bash -i ' könnte eine interaktive Bash-Sitzung geben.

Solche Fragen waren schon gefragt, zB hier:

https://stackoverflow.com/questions/34640504/is-it-possible-to-perform-shell-injection-through-a-read-and-or-to- Ausbruch aus

Die Antwort lautet "Nein, nicht anfällig", weil:

"(..) moderne Shells die Anweisung vor analysieren Jede Variablensubstitution ist daher von diesem Angriff nicht betroffen. "

In Ihrem Beispiel kann die Benutzereingabe durch 'read' nicht innerhalb der Standard-Shell umgangen werden.

2. Wo wird die Eingabe analysiert?

Ihr Skript ist sicher, da 'Echo' keine Escape-Technik bietet (zumindest nicht bekannt). Aber denken Sie daran, "gefährliche" Binärdateien zu verwenden, wie in f.e. hier:

https://fireshellsecurity.team/restricted-linux-shell-escaping-techniques/

Wenn Benutzereingaben analysiert werden von: man | less | more, awk, find, nmap, python | php | perl, bash | sh selbst, dann ist ein Escape möglich, das eine vollständig interaktive Shell gewährt (ich habe gerade mit less, python und find getestet). .

Wenn Sie die Eingabe wie in Ihrem Beispiel nur für das Echo verwenden, sind Sie in Ordnung.

3. Gibt an, ob Ihre Eingabe innerhalb der Shell verwendet wird Befehl mit Sternchen (*), wie: tar * oder ls *

Ich kann mir nicht vorstellen, wann er in Ihrem Szenario nützlich sein kann, aber es ist immer so besser zu erwähnen. Wenn dies der Fall ist, machen Sie sich bitte mit dem folgenden Schreiben vertraut:

https://www.defensecode.com/public/DefenseCode_Unix_WildCards_Gone_Wild.txt

Ein Verhalten kann auch dazu führen, dass Ihr Skript nicht mehr angezeigt wird.

Wildcards Gone Wild war eine interessante Lektüre;Dank dafür.Ich bin überrascht, dass die Verteidigung gegen diesen Angriff nicht diskutiert wird, um sicherzustellen, dass das Argument "-" explizit vor einem Platzhalter angegeben wird.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 4.0-Lizenz, unter der er vertrieben wird.
Loading...