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 >
ol>

Voila, Root-Shell ohne Passwort!

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

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.

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.

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.

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.