Python-Anwendungen verwenden viele Skripte. Dies ist es, was Cyberkriminelle verwenden, um uns ein "Schwein" anzulegen - wo wir es am wenigsten erwarten.
Einer der Vorteile von Python ist seine Benutzerfreundlichkeit: Um ein Skript
.pyauszuführen , müssen Sie es nur in einer Datei speichern und den Befehl ausführen python (, python my_file.py). Es ist auch einfach unsere Datei, wie Module zu brechen my_app.pyund auch my_lib.pyweiterhin die Module zu verwenden Design verbinden import...from: import my_lib from my_app.py.
Diese Einfachheit und Leichtigkeit hat jedoch einen Nachteil: Je einfacher es für Sie ist, Code von verschiedenen Orten aus auszuführen, desto mehr Möglichkeiten für einen Angreifer, sich einzumischen.
Platzieren Sie Python-Code an einem sicheren Ort
Das Python-Sicherheitsmodell basiert auf drei Prinzipien:
- , sys.path , .
- , (main), sys.path.
-
python,-c-m.
Angenommen, Sie möchten eine Python-Anwendung ausführen, die "korrekt" auf Ihrem Computer installiert wurde. In diesem Fall ist der einzige Speicherort (neben dem Ordner, in dem Python installiert ist), der standardmäßig automatisch zu Ihrem sys.path hinzugefügt wird, der Ordner mit dem Hauptskript oder der ausführbaren Datei.
Wenn beispielsweise "
pipIn" vorhanden /usr/binist und Sie ausgeführt werden /usr/bin/pip, sys.pathwird nur "Hinzufügen" hinzugefügt /usr/bin. Nur root kann Dateien in / usr / bin schreiben, daher wird dieser Speicherort als sicher angesehen.
Die Vereinbarung verpflichtet uns jedoch dazu :
/path/to/python -m pip. Dies vermeidet Probleme mit $PATHund Konflikte mit der Windows-Dokumentation.
Im Allgemeinen ist sowieso alles in Ordnung, wenn Sie nur die Berechtigung haben, Dateien in den Verzeichnissen hinzuzufügen und zu bearbeiten, aus denen Python Module zum Importieren verwendet.
Download-Ordner - anfälliger Speicherort
Es gibt viele Möglichkeiten, Browser (und manchmal auch andere Software) zu zwingen, Dateien mit beliebigen Namen ohne Wissen des Benutzers im Ordner "Downloads" abzulegen. Diese Sicherheitsanfälligkeit wird durch einen Angriff namens DLL-Spoofing ausgenutzt. In unserem Fall werden wir über Python-Skripte sprechen, aber die Idee ist dieselbe.
Browser sind diesbezüglich ernsthafter geworden und versuchen nach und nach sicherzustellen, dass die vom Benutzer besuchten Websites keine Dateien heimlich in seinem Download-Ordner ablegen können.
Es wird jedoch sehr schwierig sein, dieses Problem vollständig zu lösen: Beispielsweise ist weiterhin eine Option verfügbar
Content-Disposition HTTP header’s filename*, mit der Websites ein Verzeichnis zum Platzieren der hochgeladenen Dateien auswählen können.
Wie der Angriff funktioniert
Sie führen die Installation aus :
python -m pip. Sie laden ein Python-Paket von einer absolut vertrauenswürdigen Website herunter, die jedoch aus irgendeinem Grund direkte Downloads anstelle von PyPI bietet. Vielleicht ist es eine Art interne Version, vielleicht ist es eine vorläufige Version - kein Unterschied. Also geht es zu dir totally-legit-package.whl:
~$ cd Downloads
~/Downloads$ python -m pip install ./totally-legit-package.whl
Es scheint in Ordnung zu sein, aber es stellt sich heraus, dass vor zwei Wochen auf einer völlig anderen Website, die Sie besucht haben, einige XSS-JavaScript-Dateien pip.py mit Malware ohne Ihr Wissen in Ihren Download-Ordner heruntergeladen haben.
Boom!
Absturz!
~$ mkdir attacker_dir
~$ cd attacker_dir
~/attacker_dir$ echo 'print("lol ur pwnt")' > pip.py
~/attacker_dir$ python -m pip install requests
lol ur pwnt
Seltsames Verhalten PYTHONPATH
Ein paar Absätze oben schrieb ich:
Der einzige Speicherort (außer dem in Python installierten Ordner), der automatisch zu Ihrem Standardordner sys.path hinzugefügt wird, ist das Hauptskript oder der ausführbare Ordner.
Was macht "default" hier? Welche anderen Standorte kann ich hinzufügen?
Grundsätzlich kann
$PYTHONPATHalles in eine Umgebungsvariable geschrieben werden . Aber Sie würden Ihren aktuellen Standort nicht einschreiben $PYTHONPATH, oder?
Leider gibt es eine Situation, in der Sie dies möglicherweise versehentlich tun.
Lassen Sie uns zur Veranschaulichung eine "anfällige" Python-Anwendung skizzieren:
# tool.py
try:
import optional_extra
except ImportError:
print("extra not found, that's fine")
Lassen Sie uns 2 Verzeichnisse erstellen:
install_dirund attacker_dir. Lassen Sie uns versagen install_dir, dann cd attacker_dirunseren Schadcode ausführen und dort unter dem Namen platzieren tool.py:
# optional_extra.py
print("lol ur pwnt")
Alles was bleibt ist es auszuführen:
~/attacker_dir$ python ../install_dir/tool.py
extra not found, that's fine
Bisher läuft alles gut.
Aber jetzt werden wir einen häufigen Fehler sehen. Viele Leute empfehlen die Zugabe in einer
$PYTHONPATHmehr Sache :
export PYTHONPATH="/new/useful/stuff:$PYTHONPATH";
Auf den ersten Blick ist dies sinnvoll: Wenn Sie Projekt X zu
$PYTHONPATHProjekt Y hinzufügen, wurde dort möglicherweise auch etwas hinzugefügt, oder vielleicht auch nicht. In jedem Fall möchten Sie die mit anderen Projekten verbundenen Änderungen nicht überschreiben. Dies ist besonders wichtig, wenn Sie Dokumentationen schreiben, die von vielen Personen verwendet werden.
Und jetzt sind wir mit "seltsamem" Verhalten konfrontiert
$PYTHONPATH. Wenn es vor dem ersten Start $PYTHONPATHleer war oder nicht installiert wurde, wird darin eine leere Zeile angezeigt, die als aktuelles Verzeichnis erkannt wird. Lassen Sie uns dies überprüfen:
~/attacker_dir$ export PYTHONPATH="/a/perfectly/safe/place:$PYTHONPATH";
~/attacker_dir$ python ../install_dir/tool.py
lol ur pwnt
Lassen Sie es für zusätzliche Sicherheit
$PYTHONPATHleer und versuchen Sie es erneut:
~/attacker_dir$ export PYTHONPATH="";
~/attacker_dir$ python ../install_dir/tool.py
lol ur pwnt
Genau, es ist überhaupt nicht sicher!
Und noch etwas : Es stellt sich heraus, dass Situationen, in denen eine Variable
$PYTHONPATHleer ist und eine Variable $PYTHONPATHnicht gesetzt ist, zwei verschiedene Geschichten sind:
os.environ.get("PYTHONPATH") == ""</code> <code>os.environ.get("PYTHONPATH") == None.
Wenn Sie sicher sein möchten, dass Sie bereinigen
$PYTHONPATH, verwenden Sie den folgenden Befehl unset:
~/attacker_dir$ python ../install_dir/tool.py
extra not found, that's fine
Im Allgemeinen war das Schreiben in eine Variable
$PYTHONPATHdie häufigste Methode zum Einrichten der Umgebung zum Ausführen von Python-Anwendungen. Glücklicherweise geriet es mit dem Aufkommen von virtuellen Umgebungen und virtuellen Umgebungen aus der Mode. Wenn Sie eine alte Konfiguration haben, in die etwas geschrieben $PYTHONPATHwird, auf die Sie jedoch verzichten können, ist es jetzt an der Zeit, sie zu löschen.
Wenn Sie dies aus irgendeinem Grund nicht tun können, verwenden Sie einen Life-Hack :
export PYTHONPATH="${PYTHONPATH:+${PYTHONPATH}:}new_entry_1"
export PYTHONPATH="${PYTHONPATH:+${PYTHONPATH}:}new_entry_2"
In bash und zsh ergibt dies folgende Ausgabe:
$ echo "${PYTHONPATH}"
new_entry_1:new_entry_2
Nun gibt es keine zusätzlichen Doppelpunkte und leeren Einträge.
Und schließlich: Wenn Sie noch arbeiten
$PYTHONPATH, verwenden Sie absolute Pfade. Ist immer!
Das Problem ist viel ernster
Es gibt verschiedene Optionen für die gefährliche Entwicklung von Ereignissen im Zusammenhang mit dem Start von Python-Dateien aus dem Ordner "Downloads":
- Python ausführen
~/Downloads/anything.py(auch wenn es selbstanything.pysicher ist). Ihr Download-Ordner wird hinzugefügtsys.path. - Nach dem Start wird auch der
jupyter notebook ~/Downloads/anything.ipynbOrdner "Downloads" hinzugefügtsys.path.
Daher ist es besser, die .py- und .ipynb-Dateien vor dem Ausführen aus diesem Ordner zu entfernen.
Die Ausführung
cd Downloadsund der anschließende Start python -cmit Anweisungen im importInneren oder der interaktive Start pythonmit anschließendem Import lösen das Problem nicht vollständig, wenn sich die importierten Dateien im Ordner "Downloads" befinden.
Leider ist dies
~/Downloads/nicht der einzige Speicherort, der schädliche Dateien enthalten kann. Wenn Sie beispielsweise einen Server verwalten, auf den Benutzer Dateien hochladen können, stellen Sie sicher, dass niemand oder nichts gestartet werden kann, cd public_uploadsbevor Sie den Befehl ausführen python.
In diesem Fall kann berücksichtigt werden, dass der Code zum Hochladen von Dateien an deren Namen angehängt wird
.uploaded. Dies hilft, ungeplante Skriptausführung zu vermeiden .py.
Vorsichtsmaßnahmen
Wenn Sie Python-Anwendungen haben, die Sie in Ihrem Download-Ordner verwenden möchten, geben Sie in der Regel den Pfad zum Skript (
/ path / to / venv / bin / pip) und nicht zum Modul ( / path / to / venv / bin / python -m pip) ein.
Vermeiden Sie es im Allgemeinen, Downloads als aktuelles Arbeitsverzeichnis zu verwenden, und verschieben Sie alle Skripte, die Sie verwenden möchten, vor dem Start an einen geeigneteren Ort.
Es ist wichtig zu verstehen, woher Python den Code bezieht, von dem es ausgeführt wird. Wenn Sie jemanden auch nur eine Zeile des linken Python-Skripts ausführen lassen, bedeutet dies, dass Sie die vollständige Kontrolle über Ihren Computer haben!
Bei Notwendigkeit
Wenn man einen solchen Artikel mit "Tipps und Life Hacks" zum Thema Sicherheit liest, kann man leicht davon ausgehen, dass der Autor sehr klug ist, eine Reihe kleiner Dinge weiß, die andere wissen sollten, und ständig darüber nachdenkt. Tatsächlich ist dies jedoch nicht ganz richtig. Ich werde erklären.
Im Laufe der Jahre habe ich mit beneidenswerter Häufigkeit beobachtet, wie Benutzer nicht verstanden haben, woher Python Code herunterlädt. Zum Beispiel setzen Leute ihr erstes Programm mit Twisted in eine Datei namens twisted.py. In diesem Fall ist der Import der Bibliothek einfach unmöglich!
Cyberkriminelle freuen sich viel mehr, wenn sie Systemadministratoren oder Entwickler erfolgreich angreifen konnten. Wenn Sie einen Benutzer hacken, erhalten Sie die Daten dieses Benutzers. Wenn Sie jedoch einen Administrator oder Entwickler hacken und es richtig machen, können Sie auf Tausende von Benutzern zugreifen, deren Systeme von einem Administrator kontrolliert werden, oder sogar auf Millionen von Benutzern, die Entwicklersoftware verwenden.
Daher ist „nur immer vorsichtig sein“ kein verlässliches Rezept. Diejenigen IT-Experten, die für Produkte mit einer großen Anzahl von Benutzern verantwortlich sind, müssen wirklich vorsichtiger sein. Zumindest sollten sie über die Besonderheiten der Arbeit bestimmter Entwicklungswerkzeuge informiert werden.
Fehler oder Funktion ...
Nichts von dem, was ich oben beschrieben habe, ist tatsächlich ein echter "Fehler" oder eine "Sicherheitslücke". Ich glaube nicht, dass die Python- oder Jupyter-Entwickler versehentlich etwas getan haben. Das System funktioniert so, wie es entworfen wurde, und das kann wahrscheinlich erklärt werden. Persönlich habe ich keine Ahnung, wie etwas daran geändert werden kann, ohne die Leistung von Python einzuschränken, für die wir es so sehr schätzen.
Eine meiner Lieblingserfindungen ist SawStop, ein einzigartiges Sicherheitssystem für Tischkreissägen. Damit können Sie die Drehung des Sägeblattes innerhalb von 5 Millisekunden stoppen - bei Kontakt mit dem menschlichen Körper. Vor der Erfindung dieses Systems waren Tischkreissägen äußerst gefährliche Werkzeuge, erfüllten jedoch eine wichtige Produktionsfunktion. Viele sehr nützliche und wichtige Dinge wurden an Tischkreissägen getan. Es ist jedoch auch richtig, dass Tischkreissägen einen überproportionalen Anteil an Unfällen in Holzbearbeitungsbetrieben hatten. SawStop spart jetzt jedes Jahr viele Finger.
Ich hoffe, dass ich durch die Detaillierung der Komplexität von Python-Skripten auch einigen Sicherheitsingenieuren einige Gedanken machen kann. Kann SawStop dazu gebracht werden, beliebigen Code für interaktive Interpreter auszuführen? Welche Lösung könnte einige der oben genannten Probleme verhindern?
Bleib sicher, Freunde.
Werbung
VDSina bietet sichere Server unter Linux oder Windows - wählen Sie eines der vorinstallierten Betriebssysteme oder installieren Sie es von Ihrem Image.
