Script mit Login versehen

  • Hallo Autoit-Gemeinde,

    ich glaub ich stehe total im Wald und sehe den Wald vor lauter Bäumen nicht;(

    Könnte mir jemand auf die Sprünge helfen, wie ich einem beliebigen Script/Programm ein Login hinzufüge? Also das Autoit-Proggi(zur exe kompiliert) soll beim Starten erst mal ein Login-fenster anzeigen.
    User gibt die Daten ein > Programm startet weiter bzw. ist erst jetzt benutzbar.

    Ich habe eine Gui mit Inputs für PWD und User entworfen, eine IF-Abfrage geschrieben die das PWD und den Username auf Richtigkeit prüft . Bei True sollte das Proggi weiter laufen bei False beendet werden.


    Das Login ist für ein Proggi gedacht, dass nur ich selbst benutze und es unbenutzbar machen soll, für den Fall, dass sich jemand am Bürorechner zu schaffen macht.;)

  • 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:

    Code
    1. 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.

  • Hallo Zusammen,

    zunächst vielen lieben Dank für eure Antworten. Dazu habe ich noch eine Verständnisfrage: Ich hatte mal im Forum und im Netz recherchiert und ging davon aus, dass es mit den
    neuen Versionen von Autoit keine Möglichkeit des Decompilierens usw. mehr gibt. so war zumindest der Tenor. Sollte das nicht Stimmen?

  • 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:

    Code
    1. If Not _ZugangsKontrolle() Then Exit
    2. ConsoleWrite("Hier geht das Programm weiter" & @CRLF)
    3. Func _ZugangsKontrolle()
    4. Local $sPW = InputBox(" ", " ", "", "*")
    5. If $sPW <> "DeinFancyPasswort" Or @error Then Return False
    6. Return True
    7. 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

    SciTE4AutoIt = 3.7.3.0 AutoIt = 3.3.14.2 AutoItX64 = 0 OS = Win7Pro SP1 OSArch = X64 Language = 0407/german

    H:\...\AutoIt3\SciTE H:\...\AutoIt3 H:\...\AutoIt3\Include (H:\ = Network Drive)


    86223-publicdomain-88x31-png Any of my own code posted anywhere on the forum is available for use by others without any restriction of any kind.

  • 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.

  • Hallo Alpines, hallo Conrad,

    danke für die Infos,

    Das Programm bietet mir One-Klick-Lösungen zu verschiedenen immer wiederkehrenden Tätigkeiten an meinem Rechner und auf von mir benutzte Testrechnern. Z.B.
    Öffnen von Ordnern oder ausführen von Windows-Tools. Auch das Einloggen in verschiedene Datenbanken/Systeme die ich mehrmals täglich benötige gehört
    dazu und das ist auch der Grund warum es für andere nicht nutzbar sein soll. Für Test-Scenarien habe ich das Proggi nämlich auf einem Share liegen, damit ich auch auf den Testrechnern
    darauf Zugriff habe. Deswegen auch kein "Schnickschnack" wie mehrere Versuche oder so. Wenn das Login nicht passt ist Schluss und Exit. Eine Verteilung an andere ist ohnedies
    nicht vorgesehen, da es sehr personalisiert erstellt ist. Andere Kollegen haben ja andere Tätigkeiten und andere Schwerpunkte;) So gesehen ist das Proggi nicht wirklich wertvoll für andere.
    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. Wäre echt cool.:saint:

  • 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... :rofl:

    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:

  • 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.

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

  • 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

    .