Nicht nur für Programmierer! Vorsicht bei der Verwendung bestimmter Registryfunktionen in Autoit!

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Unsere Datenschutzerklärung wurde aktualisiert. Mit der Nutzung unseres Forums akzeptierst Du unsere Datenschutzerklärung. Du bestätigst zudem, dass Du mindestens 16 Jahre alt bist.

    • Nicht nur für Programmierer! Vorsicht bei der Verwendung bestimmter Registryfunktionen in Autoit!

      [Blockierte Grafik: https://abload.de/img/info8dl7v.png]Kurze Einführung
      Autoit ist eine leicht zu erlernende Programmiersprache - sie ist von der Syntax her Powershell sehr ähnlich, aber meiner Meinung nach um einiges leichter zu verstehen. Gerade im administrativen Bereich bietet sie einen recht großen Funktionsumfang, um durch eigene Befehle oder frei zugängliche userdefinierte Includes Sachen sehr einfach umzusetzen, die in anderen Sprachen eine größere Praxis erfordern und nur schwer zu erstellen sind. Auch einige Tools im Antimalwarebereich setzen diese Sprache ein. Durch Zufall bin ich auf ein Poblem gestoßen, über das ich hier Anwender und Programmierer solcher Tools informieren möchte.

      Das Problem
      Wie es aussieht, funktionieren einige interne Befehle zum Auflisten von Registryeinträgen in der Programmiersprache Autoit zur Zeit nicht wirklich sicher. Betroffen sind - getestet unter Autoit 3.3.14.2 - folgende interne Registrybefehle der Sprache:
      Verwendet ein Antimalwaretool diese Funktionen, kann Malware Starteinträge sehr einfach für das Tool an den Stellen der Registry unsichtbar machen, an denen sie zum Lesen der Starteinträge verwendet werden. Es reicht hier aus, einen speziell angepassten Registrywert oder Registryschlüssel zu erstellen, um Malwareeinträge für das Tool verschwinden zu lassen.
      Dabei ist es für Malwareschreiber extrem einfach und schnell festzustellen, ob diese Funktionen im Tool verwendet werden und wo genau sie zum Einsatz kommen.
      Sehr erschreckend (mein Eindruck): Um zu erkennen, dass diese Lücke besteht und wie sie ausnutzbar ist, reicht es eigentlich aus, lesen zu können und in der API Programmierung recht gut bewandert zu sein (eigentlich Grundvoraussetzung für so ziemlich jeden Malwareschreiber).

      Vorsicht! Auch Windowskomponenten reagieren auf diese Modifikationen.
      Bei meinen Tests musste ich feststellen, dass auch der in Windows enthaltene Registryeditor bis Windows8.1 auf diese Modifikationen reagiert und diese speziellen Einträge nicht listet. Erst ab Windows10 funktioniert der Registryeditor da korrekt.
      Auch Powershell kann scheinbar diese Einträge nicht immer korrekt listen, gibt aber nach meinen Tests unter STDError einen Fehler zurück. Tools oder Scripte, die interne Powershell Funktionen zum Listen der Registry benutzen, sind hier also eventuell ebenfalls betroffen.

      Was bedeutet das für Programmierer von Antimalwaretools, die Autoit als Sprache verwenden?
      Die Verwendung der Funktionen RegEnumKey und RegEnumVal sollte unbedingt vermieden werden. Es gibt Includes für Autoit, die die Registry-API in sichererer Art bereizstellen (zum Beispiel die Include WinAPIReg.au3).
      Verwendet Ihr Tool die Autoit Funktion RegEnumKey oder die Funktion RegEnumVal in seinem Code, sollten diese umgehend durch sicheren Code ersetzt werden.

      Was bedeutet das für Anwender?
      Ist das Tool, dass Sie zur Malwareanalyse oder Malwarebeseitigung verwenden in Autoit geschrieben, sollte das erhaltene Ergebnis möglichst mit anderen Tools, die in anderen Sprachen geschrieben wurden, überprüft werden. Zu erkennen, ob ein Tool die problematischen Funktionen verwendet, ist für einen Anwender schwer nachzuvollziehen (aber nicht unbedingt unmöglich). Weiter darauf eingehen darf ich hier nicht.

      Kann ich als Anwender denn erkennen, ob ein Tool in Autoit programmiert wurde?
      Zu erkennen, ob ein Tool in Autoit programmiert wurde, ist auch für einen Anwender Recht leicht.
      Als Hilfsmittel kann dazu das Freewaretool Resource Hacker verwendet werden.
      Öffnet man eine in Autoit programmierte EXE mit dem Tool, ist links unter der Resourcenart RCData der Eintrag Script zu finden. Klickt man den Eintrag an, findet man ganz rechts im Text den Eintrag AU3, der auf Autoit 3 hindeutet.

      [Blockierte Grafik: https://abload.de/img/1ays76.jpg]
      ________________________________________________________

      PPFScanner PPFS Android MisterXMail@web.de
      Mfg AHT

      Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von AHT ()

    • FAQs zu diesem Thema

      Frage: Sollte ich als Anwender nicht bei der Analyse von Virenproblemen besser auf in Autoit programmierte Tools verzichten?
      Antwort: Nein, denn andere Tools bieten meist einen anderen Funktionsumfang. Die Ergebnisse sollte aber nicht für wirklich sicher gehalten werden und mit Anwendungen, die in anderen Sprachen geschrieben wurden, überprüft werden.

      Frage: Virenschreiber müssten ja in Autoit geschriebene Tools speziell angreifen, um diese Lücke auszunutzen. Werden in Autoit geschriebene Tools denn wirklich so oft verwendet, dass sich das überhaupt lohnt?
      Antwort: Ja, die werden oft verwendet. Manche in Autoit geschriebene Tools werden in bestimmten Bereichen weltweit verwendet - und das im Prinzip sozusagen alternativlos.

      Frage: Ist wirklich jedes in Autoit geschriebene Antimalwaretool anfällig auf diese Lücke?
      Antwort: Das kann ich nicht genau sagen. Es gibt in Autoit auch sichere Funktionen, mit denen man die Registry lesen kann. Das die problematischen Funktionen irgendwo im Tool zum Einsatz kommen, wenn man eines untersuchen würde, ist aber sehr wahrscheinlich. Nutzt jemand nur als Programmiersprache nur Autoit und ist nicht sehr gut im Bereich API Programmierung unterwegs, wird er als Programmierer nicht auf diese Lücke stoßen.

      Frage: Lohnt es sich für Malwareschreiber überhaupt, diese Lücke auszunutzen?
      Antwort: Das kommt drauf an. Die meiste Malware muss nicht lange auf einem Rechner aktiv sein, um ihre Arbeit da zu tun. Für Botnetze oder eventuell auch für Banking Trojaner könnte sich ein Ausnutzen der Lücke schon lohnen, da diese vielleicht etwas länger unentdeckt bleiben müssen. Die meiste Malware wird diese Softwarelücke aber wohl nicht nutzen.

      Frage: Wäre es nicht für Malwareschreiber sinnvoller, gleich ein Rootkit zu schreiben, als diese Lücke auszunutzen?
      Antwort: RootKits werden in der Regel sichtbar, wenn zum Beispiel von einer Live-CD gescannt wird und die Malware aktuell nicht läuft. Bei Ausnutzung dieser Lücke bleibt der Starteintrag auch von einer Live-CD für das angreifbare Tool unsichtbar.



      ________________________________________________________

      PPFScanner PPFS Android MisterXMail@web.de
      Mfg AHT

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von AHT ()

    • Das "Exploit" in Aktion

      Ich habe auf meinem System unter Vista 32Bit mal eine solche Modifikation unter dem Registryschlüssel HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run erstellt.

      Der PPFScanner gibt hier das korrekte Ergebnis zurück. Hier ein Screenshot:
      [Blockierte Grafik: https://abload.de/img/1dfs66.jpg]

      Man sieht dort unter dem besagten Schlüssel 5 Werte.



      Der Registryeditor von Windows zeigt nur 3 davon an:

      [Blockierte Grafik: https://abload.de/img/2ovspx.jpg]


      Die Autoit Funktion RegEnumVal liefert ebenfalls nur 3 Werte in dem Schlüssel

      Quellcode

      1. [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run]
      2. Sidebar = C:\Program Files\Windows Sidebar\sidebar.exe /autoRun
      3. EPLTarget\P0000000000000000 = C:\Windows\system32\spool\DRIVERS\W32X86\3\E_FATILFE.EXE /EPT "EPLTarget\P0000000000000000" /M "XP-312 313 315 Series"
      4. GarminExpressTrayApp = "C:\Program Files\Garmin\Express Tray\ExpressTray.exe"


      Powershell bringt eine Fehlermeldung und listet keinen der dort vorhandenen Werte. Fatal ist hier, dass Tools, die nur STDOUT auslesen, auch keinen Hinweis darauf erhalten, dass dort doch Werte stehen. Auch mit Powershell sollte man da etwas vorsichtig sein. Die Fehlermeldung erscheint zwar auf dem Bilschirm, schreibt man die Ergebnisse aber in eine Datei, erscheint die Fehlermeldung dort natürlich nicht:
      [Blockierte Grafik: https://abload.de/img/3obsxv.jpg]



      Wer sich die Ergebnisse da mal ansieht wird wohl erkennen, dass die ganze Sache wohl als ziemlich bedenklich einzustufen ist.
      ________________________________________________________

      PPFScanner PPFS Android MisterXMail@web.de
      Mfg AHT