Script mit Login versehen

Zunächst: Wirklich sicher ist das natürlich nicht. So eine simple Abfrage lässt sich mit einem Disassembler (bzw. Debugger) relativ leicht umgehen, im Falle von AutoIt reicht auch ein Decompiler und ein anschließendes Entfernen der Abfrage, da der Code im Klartext vorliegt. Jedoch wird es wohl für den simplen Zweck, Kollegen am Rumschnüffeln zu hindern, reichen. Wobei es da wohl einfacher wäre, bei Verlassen des Arbeitsplatzes den Rechner kurz mit Win+L zu sperren... Aber gut, davon mal abgesehen ist das ganze simpel umsetzbar.

Am schönsten liest es sich vermutlich, wenn du deine ganze Zugangskontrolle in eine Funktion packst. Abhängig vom Erfolg der Benutzerdatenabfrage gibst du dann einfach True (bei korrekten Daten) oder False (bei inkorrekten Daten oder Abbruch) zurück. Dann kannst du direkt am Anfang des Skriptes einfach so eine Zeile einfügen:

If Not ZugangsKontrolle() Then Exit

Liest sich sehr angenehm und ist eigentlich selbsterklärend für den Code-Leser. Wenn die Zugangskontrolle nicht erfolgreich ist, terminiert das Skript an dieser Stelle. Wenn sie erfolgreich ist, läuft es ab diesem Punkt einfach normal weiter.

Edit:

Zwecks Kapselung und Wiederverwendbarkeit würde ich ALLES, was mit der Authentifizierung zutun hat, in diese eine Funktion packen, inklusive GUI-Erstellung.

Die einfachste Möglichkeit wäre deine Pfunkzion() umzuschreiben, sodass diese True/False zurückliefert und bei True GUIDelete($Form1)und ExitLoop aufruft damit das Script nicht mehr in der While-Schleife läuft und somit dann den Code ausführt der danach kommt.

Danach kannst du dann dein normales Script einfügen mit GUI etc.

Natürlich kann man das alles noch viel schöner lösen.

Zitat von hipfzwirgel

Sollte das nicht Stimmen?

Du brauchst keinen Decompiler um deine Simple If-Abfrage auszuhebeln.

Wenn ich genauer ins Detail gehen würde verstößt das gegen die Forenregeln aber das was chess gesagt geht schon in die richtige Richtung.

Ein paar Minuten im Disassembler und das Programm ist geknackt.

Moin.

Wenn es wirklich nur darum geht dass nur Du das Programm benutzen sollst, dann brauchst Du auch keinen Benutzernamen. Dann ist ein Passwort in ausreichender Stärke genug:

If Not _ZugangsKontrolle() Then Exit
ConsoleWrite("Hier geht das Programm weiter" & @CRLF)

Func _ZugangsKontrolle()
    Local $sPW = InputBox(" ", " ", "", "*")
    If $sPW <> "DeinFancyPasswort" Or @error Then Return False
    Return True
EndFunc

Ich würde hier keinen Schnickschnack mit 3 Versuchen etc. machen, denn falls Du Dich vertippst, dann startest Du das Programm eben nochmal. "Title" und "Prompt" bei der InputBox lasse ich auch immer leer, damit es weiter keinen Hinweis gibt, was dort gebraucht wird.

Gruß, Conrad

Das eher schwieriger, es ist aber möglich ohne großen Aufwand einfache If-Abfragen abzuhebeln oder einfach komplett zu überspringen.

Absolute Sicherheit gibt es nicht, du kannst zur Sicherheit noch einen Obfuscator nutzen oder einen Online-Interface zum Login anbieten,

aber selbst das ist, wenn man sich die Zeit dafür nimmt, knackbar.

Deshalb solltest du dir die Frage stellen ob dein Programm wirklich so kostbar ist, dass du es mit einem Passwort absichern möchtest und wenn ja,

wie schwierig du es dem Angreifer machen willst.

Verteilst du dein Programm nur an DAUs musst du nicht so viel Arbeit reinstecken wie an jemanden der weiß was er am Rechner tut.

Zitat von hipfzwirgel

Vielleicht könnte man ja mal AutoIt so designen oder eine Möglichkeit einbauen, das es nicht disassemblierbar und es keine Möglichkeit mehr gibt aus einer EXE
wieder Programmcode heraus zu bekommen.

Das ist als würdest du ein Auto zu bauen versuchen, welches fahren kann aber nicht auseinanderschraubbar ist - das ist unmöglich.

Woher soll der Interpreter oder dein PC denn dann wissen welche Anweisungen er ausführen soll?

Den Programmcode kriegt man auch ohne weiteres nicht raus, deshalb mach die Sperre so vernünfitg wie es geht und

steck den Rest deiner Energie lieber in das Programm selber, immerhin willst du es ja nicht öffentlich verteilen sondern nur an gezielte Personen.

Habe mir für eines meiner Tools auch überlegt, wie ich es angehe, damit nur ich es nutzen kann. Vorweg aber... egal was du machst... absolute Sicherheit gibt es nicht!

Ich mache es in meinem Tool so, dass beim ersten Start ein Token generiert wird, dass dann mit dem eingegebenen Passwort verschlüsselt und als Binary in der Registry gespeichert wird, um damit dann die Daten zu verschlüsseln bzw. entschlüsseln. Alternativ könnte man den verschlüsselten Token auch auf einem USB-Stick speichern...

Edit: Für den Namen des Registry-Schlüssels generiere ich eine GUID, die dann mit dem Passwort verschlüsselt in einer *.ini gespeichert wird. Diese kann folglich nur gefunden werden, wenn beim nächsten Start das richtige Passwort angegeben wurde.

Micha_he - walte deines Amtes...

Zitat von timee000

Pfunkzion

Zum Thema Sicherheit an sich habe ich auch noch eine kleine Idee, das muss ich aber erst selber testen...

Ansonsten hab ich aber noch einen schönen Dialog für einen Login gehabt und eben mal in eine passende Funktion gepackt:

#include <EditConstants.au3>
#include <ButtonConstants.au3>


If Not AccessControl("MaxMustermann", "top!secret123") Then Exit 1
MsgBox(0, "Mein Skript", "Hallo Welt!")


; Return Values:
; - 0 (@extended = 0) => Cancel Button or Close Button pressed
; - 0 (@extended = 1) => Incorrect Username/Password entered
; - 1 				  => Login successfull
Func AccessControl($sAUser, $sAPass)
Local $hWnd
Local $cUser, $cPass, $cCancel, $cOK
$hWnd = GUICreate("Zugangskontrolle", 300, 170, -1, -1)
GUISetBkColor(0xffffff)
GUISetFont(8.5, 400, 0, "Segoe UI")
GUISetIcon("user32.dll", -7)


GUICtrlCreateIcon("user32.dll", -7, 10, 10, 32, 32)
GUICtrlCreateLabel("Bitte Zugangsdaten eingeben:", 55, 18, 200, 20)
GUICtrlCreateLabel("Benutzername:", 10, 50, 140, 20)
$cUser = GUICtrlCreateInput("", 150, 50 - 2, 140, 20)
GUICtrlCreateLabel("Passwort:", 10, 85, 140, 20)
$cPass = GUICtrlCreateInput("", 150, 85 - 2, 140, 20, $ES_PASSWORD)
$cOK = GUICtrlCreateButton("Anmelden", 10, 120, 135, 40, $BS_DEFPUSHBUTTON)
$cCancel = GUICtrlCreateButton("Beenden", 155, 120, 135, 40)
GUISetState()


While True
Switch GUIGetMsg()
Case -3, $cCancel
GUIDelete($hWnd)
Return SetExtended(0, 0)
Case $cOK
If (GUICtrlRead($cUser) == $sAUser) And _
(GUICtrlRead($cPass) == $sAPass) Then
GUIDelete($hWnd)
Return 1
Else
MsgBox(16, "Zugangskontrolle", "Die eingegebenen Zugangsdaten sind inkorrekt.", 0, $hWnd)
GUIDelete($hWnd)
Return SetExtended(1, 0)
EndIf
EndSwitch
WEnd
EndFunc

Zitat von chesstiger

Zum Thema Sicherheit an sich habe ich auch noch eine kleine Idee, das muss ich aber erst selber testen...

Okay, das habe ich hiermit erledigt. Daher will ich meine Idee jetzt mal etwas ausführen.

Was ist das gefährliche an einer "normalen" Zugangskontrolle? Man kann disassemblieren und die Sicherheitsabfrage einfach "überspringen", grob erklärt. Oder sogar noch einfacher: Man könnte sogar mit einem einfachen Texteditor alle hartkodierten Strings aus einer ausführbaren Datei auslesen, wo dann auch Benutzername und Passwort bei wären. Man müsste also eine Situation schaffen, in der die Sicherheitsabfrage obligatorisch für den Betrieb des Programmes ist. Man könnte also hergehen, und die eigentliche ausführbare Datei verschlüsseln. Der Schlüssel besteht dann aus dem Benutzername und dem Passwort. So liegt in dem ausgelieferten Skript keine Information über die richtigen Zugangsdaten vor. Wenn man sie falsch eingibt, wird trotzdem entschlüsselt, nur das Ergebnis ist unbrauchbar.

Ich habe die Idee mal in einem Beispiel umgesetzt. Dabei wird aus Benutzername:Passwort zunächst ein SHA256-Hash gebildet. Dieser wird dann als Schlüssel für eine AES256-Verschlüsselung genutzt. Damit wird das eigentliche Skript in kompilierter Form verschlüsselt. Die verschlüsselte EXE wird dann per FileInstall in das Zugangskontrollprogramm gepackt. Dieses fragt beim Start Zugangsdaten ab, packt das eigentliche Skript aus, entschlüsselt es mit den eingegebenen Daten und überprüft dann nur kurz, ob eine ausführbare Datei entstanden ist. Wenn ja => Ausführen. Wenn nein => Fehlermeldung. Nach Ausführung werden dann wieder alle temporären Daten gelöscht.

Natürlich krankt auch diese Idee an ein, zwei Punkten. Nach der korrekten Eingabe der Zugangsdaten kann man theoretisch innerhalb der Laufzeit der Software einfach die entschlüsselte Datei sichern und nachher separat starten. Eine EXE direkt aus dem Prozessspeicher auszuführen, dürfte etwas komplexer sein. Soweit ich weiß, sieht Windows keine Standardfunktion dafür vor, man müsste also selber einen PE-Loader basteln... Ansonsten sollte das aber schon halbwegs sicher sein.

Im Beispiel enthalten sind 4 Dateien:

- acl.au3: Enthält die Passwortabfrage und die Entschlüsselungsroutinen.

- script.au3: Das eigentliche Skript, welches geschützt werden soll. Beliebiger Inhalt.

- mkau3.au3: Dieses Skript baut aus den anderen beiden die endgültige Datei.

- myprogram.exe: Beispieldatei zum rumprobieren, kann durch ./mkau3.au3 neu erzeugt werden.

Zitat von chesstiger

Soweit ich weiß, sieht Windows keine Standardfunktion dafür vor, man müsste also selber einen PE-Loader basteln... Ansonsten sollte das aber schon halbwegs sicher sein.

Im Beispiel enthalten sind 4 Dateien:

- acl.au3: Enthält die Passwortabfrage und die Entschlüsselungsroutinen.

- script.au3: Das eigentliche Skript, welches geschützt werden soll. Beliebiger Inhalt.

- mkau3.au3: Dieses Skript baut aus den anderen beiden die endgültige Datei.

- myprogram.exe: Beispieldatei zum rumprobieren, kann durch ./mkau3.au3 neu erzeugt werden.

Alles anzeigen

myprogramm.exe wird als malicious (high confidence) eingestuft, natürlich ein False-Positive.

Naja, ein paar Scanner schlagen bei Skriptsprachen ja immer an. Die paar sind da kein Problem.

Naja, eine verschlüsselte, ausführbare Datei im Ressourcenfeld zu haben, ist ja (verständlicherweise) irgendwie verdächtig. Aber von den großen Scannern schlägt ja nichts an, unser Panda in der Firma auch nicht.

Ich schmeiße mal eine neue Idee in die Runde.

Prinzip: Die Daten sind gar nicht da, wenn der rechtmäßige Nutzer nicht da ist.

Und das kombinieren wir mit schon genannten Methoden:

Step 1:

Das Script, welches das Passwort entgegen nimmt, kann von der bösen Person Ede Knastmann gerne im Quelltext eingesehen werden. Es ist im Prinzip nur ein Launcher, welcher das PW an ein kleines TrueCrypt-Archiv sendet.

Sofern TrueCrypt mit dem PW zufrieden ist, bindet es ein neues Laufwerk ins System ein, unter immer dem selben Laufwerksbuchstaben. Z. B. Laufwerk K.

Step 2:

Auf dem streng gecrypteten Laufwerk liegt das eigentliche Anwendungsprogramm, welches nun vom Launcher gestartet wird.

- Aber halt! Ede Knastmann könnte den Rechner ja geschickt verseucht haben, so dass der Inhalt des gecrypteten Containers im Hintergrund heimlich kopiert wird!

Darum nun Step 3 ...

Step 3:

Das ist jetzt die große neue Idee:

Das Anwendungsprogramm im Container ist nicht lauffähig, ohne hinzugeladene Daten. Aber die liegen nicht im Container und nicht auf der Platte.

Sondern die liegen auf einem ESP32 WLAN-Modul. So ein Ding passt mitsamt Akku in eine Streichholzschachtel. Programmiert werden kann das Teil mit der Arduino-IDE.

Der ESP32 stellt einen Webserver dar und bietet in der kleinsten Version immerhin 4MB Speicher.

Darauf kann man eine wiederum verschlüsselte Datei ablegen, die das Programm im Container ins Ram lädt und dort entschlüsselt. Erst mit diesen Daten wird es vollständig lauffähig.

(Kritikpunkt weiter unten)

Wenn der rechtmäßige Benutzer die Arbeit beendet, schließt er das Programm im Container.

Der parallel noch immer laufende Launcher bemerkt das und schließt zudem den TrueCrypt-Container.

Der Benutzer entfernt sich und/oder schaltet seinen ESP32 in der Hosentasche aus.

Ede Knastmann mag den Quelltextdes Launchers einsehen, doch das nützt ihm nichts.

Ede mag zudem auch das Passwort für den Container per Keylogger erbeutet haben, doch es nützt ihm wiederum nichts, ohne den Daten aus dem ESP32.

Ede hat zwar heimlich im Hintergrund den kompletten Inhalt des geöffneten Containers kopiert. Doch dummerweise läuft das darin befindliche Programm partout nicht, ohne den Daten vom ESP32 ...

Ede ist hartnäckig - neulich hat er sogar die WLAN-Verbindung mitgenifft. Doch die erfolgte ja verschlüsselt.

Also schon ziemlich sicher!

Dennoch gibt es keine 100%ige Sicherheit.

Zu irgend einem Zeitpunkt liegen die Daten ja lauffähig im Ram.

Wenn Ede tatsächlich so krass drauf sein sollte, dass er den RAM-Inhalt ausliest und analysiert, dann ...

- Auch dagegen mag es Schutz geben, aber langsam wird's utopisch.

Zumindest könnte man aber nach getaner Arbeit noch den Speicher clearen. Kleine Routine, die das RAM kurzzeitig mit Müll vollpumpt, bis hart an den Anschlag.

Allerdings kann einem dabei noch die Windows-Auslagerungsdatei wieder in die Suppe spucken ...

Ich hatte mal eine Praktikantin, die ich sehr hart im Verdacht habe, dass sie mir eine Schadsoftware installiert hatte, die im Hintergrund mindestens Hardcopys erstellte. Womöglich zudem noch gepaart mit einem Keylogger.

Aber ich glaube eher nicht, dass Ihre Malware den oben von mir beschriebenen Weg irgendwie geknackt hätte.

Wenn man also nicht gerade die NSA am Hals hat und draußen vor dem Haus ständig Fahrzeuge mit getönten Scheiben parken, dann scheint mir das Prinzip einen ausreichenden Schutz zu bieten.

'Nen ESP32 kriegt man in 100 Varianten für unter 10,- EUR und die Programmierung ist halt wie bei 'nem ollen Arduino.

Gegenüber einem USB-Stick hat man da den Vorteil, dass auf dem Ding komplexe selfmade Software laufen kann, die Daten nur beliebig widerwillig heraus rückt (und das natürlich vorzugsweise verschlüsselt).

Einen simplen USB-Stick könnte man zudem im Rechner eingesteckt vergessen. Doch der ESP32 befindet sich permanent in der eigenen Hosentasche. Entfernt man sich aus der Reichweite des Rechners, dann sind die darauf gespeicherten Daten halt ebenfalls definitiv außer Reichweite.

Kann man alles wohl noch weiter verfeinern, mir ging es nur darum, die neue Anregung in die Runde zu werfen

.