it-swarm.com.de

Warum ist die Verschleierung des Betriebssystems gegen "Es ist ein Unix-System!" nicht weit verbreitet?

Die Jurassic Park-Szene , auf die im Titel verwiesen wird, ist berüchtigt dafür, wie lächerlich es für diejenigen klingt, die technisch versiert sind. Es zeigt aber auch, was für mich ein eklatant großes Loch in der Websicherheit zu sein scheint, insbesondere bei IoT-Geräten. Sobald Angreifer feststellen, dass auf einem Server, einer Kamera oder einem Babyphone Linux ausgeführt wird, wissen sie sofort, wie es funktioniert. Sie wissen, dass Befehle wie Sudo große, saftige Ziele sind, und sie wissen, dass der Shell-Zugriff viele nützliche Tools wie ls und cat mit sich bringt.

Warum ist die Verschleierung des Betriebssystems nicht mehr eine Sache? Ich spreche nicht davon, die Version nur in Web-Headern zu verstecken. Ähnlich wie bei der Minimierung oder Verschleierung von JavaScript geht es darum, die Namen von Binärdateien und Dateipfaden im Betriebssystem selbst zu ändern. Wären nicht ganze Angriffsklassen praktisch nutzlos, wenn das Betriebssystem die Befehle ha7TrUO Und RRI6e29 Anstelle von Sudo und ls hätte? Stellen Sie sich einen Hacker vor, der irgendwie Remote-Root-Zugriff erhalten hat - was werden sie überhaupt tun, wenn sie keine Befehle kennen?

Die Implementierung wäre für Compiler ziemlich einfach. Nehmen Sie den einfachsten Fall von "Benennen Sie diese Funktion und alle Aufrufe um." Sie könnten einem Betriebssystem-Compiler und einem Anwendungs-Compiler dieselben zufälligen Namen geben, und sie könnten miteinander sprechen. Aber selbst wenn die Anwendung eine schlechte Sicherheit aufweist und anfällig für Bash-Injektionen ist, wären solche Angriffe erfolglos.

Offensichtlich kann diese Technik nicht in allen Szenarien verwendet werden. Abgesehen von Szenarien wie Servern, die von menschlichen Systemadministratoren verwaltet werden, scheint mir jedes Gerät oder jeder Server, der von der Automatisierung verwaltet wird, ein Hauptkandidat für diese Verteidigung zu sein.

Ich denke, die Frage (n) müssen etwas konkreter sein:

  1. Wird die beschriebene Verschleierung des Betriebssystems häufig verwendet und ist mir einfach nicht begegnet?
  2. Was sind die praktischen oder technischen Hindernisse für die Verwendung, wenn sie nicht weit verbreitet sind?
156
Indigenuity

Bevor ich Ihre Idee auseinander reiße, möchte ich sagen, dass es eine wirklich interessante Idee ist und es super Spaß gemacht hat, darüber nachzudenken.

Bitte denken Sie weiter über den Tellerrand hinaus und stellen Sie interessante Fragen!

Okay, lass uns das machen!


Lassen Sie uns einen Schritt zurücktreten und fragen, warum auf diesem Babyphone überhaupt Linux ausgeführt wird. Was wäre, wenn es kein Betriebssystem gäbe und die Anwendung in nacktem Mikrocontroller-Code geschrieben wäre (denken Sie an Arduino-Code)? Dann gäbe es keine Sudo oder ls oder sogar eine Shell, die der Angreifer verwenden könnte, oder?

Ich bin hier kein Experte, aber ich gehe davon aus, dass wir uns als Branche dazu entschlossen haben, Linux auf etwas zu setzen, das groß genug ist, um es größtenteils aus Gründen der Entwicklerfreundlichkeit auszuführen:

  1. Verkürzung der Entwicklungszeit: Beim Erstellen eines WiFi- und Bluetooth-fähigen, webverwalteten, Cloud-synchronisierenden, selbstpatchenden Whizpoppers mit Companion Android und iOS-Apps enthält Linux alle Bibliotheken, Dienstprogramme und Treiber, die Sie dazu benötigen.
  2. Verbesserte Testbarkeit: Wenn auf dem Gerät Bash oder Busybox mit einem SSH-Port ausgeführt wird, können Sie ganz einfach eine Verbindung herstellen und herausfinden, was während Ihrer Produkttestphase schief gelaufen ist.

Damit Ihre Verschleierungsidee funktioniert, müssen Sie nicht nur die Namen von Befehlszeilenprogrammen wie Sudo und ls verschleiern, sondern auch jede Linux-Kernel-API um zu verhindern, dass der Angreifer seine eigene kompilierte Binärdatei ablegt, die den Kernel direkt aufruft. Schauen wir uns also Ihre Idee noch einmal an:

Die Implementierung wäre für Compiler ziemlich einfach. Nehmen Sie den einfachsten Fall von "Benennen Sie diese Funktion und alle Aufrufe um." Sie könnten einem Betriebssystem-Compiler und einem Anwendungs-Compiler dieselben zufälligen Namen geben, und sie könnten miteinander sprechen.

Sie müssen diese zufällige Zusammenstellung selbst durchführen. Andernfalls könnte jemand die Zuordnungen auf Google nachschlagen.

Sie müssen den Kernel also mit Ihrem "verschleierten Compiler" aus dem Quellcode erstellen, damit nur Sie die Zuordnungen der verschleierten Kernel-APIs kennen. (jemals den Linux-Kernel aus dem Quellcode erstellt? Es ist sicherlich mehr eine lästige Pflicht als docker pull Alpine, das ist die Richtung, in die die Dev-Kultur zu gehen scheint) .

Ein Betriebssystem ist jedoch mehr als nur der Kernel. Sie möchten Treiber für den Broadcom BCM2837-WLAN-Chip, der auf diesem Mini-PC-Gerät enthalten ist? Sie müssen diesen Treiber mit Ihrem Compiler gegen Ihren ofbuscated-Kernel erstellen, wenn Broadcom Ihnen sogar den Quellcode zur Verfügung stellt. Dann müssen Sie die gesamten GNU WLAN- und Netzwerksoftware-Stacks erstellen. Wie viele andere Dinge müssen Sie finden, um eine Quelle für Ihre Build-Pipeline zu finden und hinzuzufügen, bevor Sie ein funktionierendes Betriebssystem haben?

Oh, und wenn die Upstream-Repos eines dieser Dinge einen Patch ausgeben, sind Sie jetzt dafür verantwortlich, ihn neu zu erstellen (vorausgesetzt, Sie haben die Compiler-Verschleierungszuordnungsdateien gespeichert, die Ihrer Kernel-Binärdatei entsprechen). und auf Ihre Geräte übertragen, da Ihre Geräte aufgrund ihres Designs keine vom Hersteller erstellten Patch-Binärdateien verwenden können.

Oh, und um Hacker zu vereiteln, wird es nichts davon geben "Hier sind die Binärdateien für Whizpopper 1.4.7" , oh nein, Sie Ich muss eine einzigartig verschleierte Version von allem vom Kernel bis pro Gerät erstellen, das Sie versenden.


Also zu deinen Fragen:

  1. Wird die beschriebene Verschleierung des Betriebssystems häufig verwendet und ist mir einfach nicht begegnet?
  2. Was sind die praktischen oder technischen Hindernisse für die Verwendung, wenn sie nicht weit verbreitet sind?

Ich denke, die Antwort ist, dass das, was Sie beschreiben, den Zweck der Verwendung bereits vorhandener Softwarekomponenten so gut wie vollständig zunichte macht, wenn Sie buchstäblich alles aus der Quelle finden und erstellen müssen. Es ist möglicherweise weniger aufwändig, das Betriebssystem vollständig zu löschen, so zu tun, als wäre es 1960, und Ihre Anwendung direkt in den CPU-Mikrocode zu schreiben.

Ich mag Sicherheit mehr als die meisten Entwickler, aber ich mag f * that .

235
Mike Ounsworth

Mikes Antwort sagt im Grunde alles, was ich zu bieten habe, warum dies aus entwicklungspolitischer Sicht eine schlechte Idee ist (und wie Ghedipunks Kommentar sagt, bietet eine unbrauchbare Sicherheitsfunktion keine Sicherheit). Stattdessen werde ich darüber sprechen, warum aus Sicherheitsgründen Sie dies niemals tun würden.

Die Antwort ist eigentlich überraschend einfach: Es ist Zeitverschwendung und es gibt streng bessere Möglichkeiten. Jeder blöde IoT-Doodad (denken Sie daran, das "s" in "IoT" steht für "sicher"), der sich nicht die Mühe macht, solche Funktionen zu implementieren, würde verdammt sicher nicht zu einem Ansatz passen, wie Sie ihn vorschlagen.

  1. Die ganze Idee funktioniert einfach nicht, um Systemaufrufe einzuschränken. Ein Angreifer kann nur ein paar Register setzen und einen Opcode und einen Boom aufrufen. Er befindet sich im Kernel und führt den Systemaufruf seiner Wahl aus. Wen interessiert es, wie der symbolische Name lautet? Sicher, Sie können die Syscall-Tabelle manipulieren, um dies zu erschweren (wenn es Ihnen nichts ausmacht, alles neu zu kompilieren und das Debuggen Ihres benutzerdefinierten Kernels zu einer Form der Hölle zu machen), aber es ist, als würde man das verwendete Betriebssystem verschleiern. warum sich die Mühe machen, wenn es sowieso so wenige Kandidaten gibt? Selbst wenn der Angreifer vorhandenen Code auf dem System nicht rückentwickeln möchte, sollte Brute-Forcing möglich sein, es sei denn, der Suchraum für verwendbare Anrufindizes ist größer als je zuvor auf einem eingebetteten System.
  2. Warum Befehlsnamen verschleiern, wenn Sie sie nur völlig unzugänglich machen können? Ein chroot funktioniert nicht für Shell-Einbauten , wenn Sie eine Shell ausführen , aber es funktioniert gut für alles andere und Warum sollte in Ihrer maßgeschneiderten Einzweck-App in einer Box eine Shell ausgeführt werden? Ich meine, auf Entwicklungsgeräten würde zu Testzwecken eines installiert sein, und das wird möglicherweise nicht in Ihrem Einzelhandelsimage entfernt, weil Sie faul sind oder glauben, dass Sie es erneut benötigen. Ein Angreifer kann es jedoch nicht in dem Kontext ausführen, in dem seine App ausgeführt wird. Ein einfaches chroot (oder eine kompliziertere Sandbox/Gefängnis/Container) kann dazu führen, dass das Programm keine Dateien ausführen oder sogar darauf zugreifen kann, die über die für seinen Job erforderlichen Dateien hinausgehen.
  3. Warum die Kernel-APIs verschleiern, wenn Sie nur den Zugriff darauf entfernen können? Es gibt eine Reihe von Sandbox-Systemen, die einschränken können, welche Aufrufe ein Prozess (oder seine Nachkommen ... wenn er überhaupt einen erstellen darf) ausführen kann. Siehe https://stackoverflow.com/questions/2146059/limiting-syscall-access-for-a-linux-application
88
CBHacking

Wenn Ihr Ziel darin besteht, einem Angreifer ls und cat zu entziehen, gibt es eine noch bessere Alternative zur Verschleierung: Installieren Sie diese Dienstprogramme einfach nicht.

Obwohl ich nicht sagen würde, dass dies ein weit verbreiteter Implementierungsansatz ist, ist er zumindest implementiert. Betrachten Sie zum Beispiel Distroless , eine Sammlung von Docker-Bildern, in denen so gut wie nichts enthalten ist. Einige von ihnen (wie die für unterwegs) haben buchstäblich nichts in sich. Ein Angriff auf ein System, das in einem solchen Container ausgeführt wird, kann keinen Shell-Zugriff erhalten, da keine Shell ausgeführt werden kann.

Die einzige Möglichkeit, Shell-Zugriff durch Angriff auf eine Anwendung in einem solchen Container zu erhalten, besteht darin, die Container-Laufzeit zu umgehen, um genau dies zu verhindern.

Während ich ein Beispiel für ein Docker-Image gegeben habe, kann das gleiche Konzept allgemein auf Betriebssysteme angewendet werden. Zum Beispiel sind ls und cat Teil des Pakets coreutils in Debian. Sie könnten apt-get remove coreutils und seien Sie sicher, dass ein Angreifer ls oder cat nicht als Teil eines Angriffs verwenden kann. Dies bedeutet natürlich, dass Sie sie auch nicht verwenden können, und es gibt wahrscheinlich viele andere Dinge, die von coreutils abhängen, die ebenfalls entfernt werden müssen, aber für ein eingebettetes Gerät oder einen Server, der nur eines tut das kann in Ordnung sein.

Das allgemeine Prinzip ist die Reduzierung der "Angriffsfläche": Je mehr "Zeug" ein Ziel hat, desto einfacher ist es, Kompromisse einzugehen. Das Zeug können offene Netzwerkports, Codezeilen oder installierte Binärdateien sein. Wenn die Erhöhung der Sicherheit das Ziel ist, ist das Entfernen aller unnötigen "Dinge" ein guter Anfang.

30
Phil Frost

Weil Verschleierung keine Sicherheit ist und weil die Verschleierung des Betriebssystems im Grunde genommen Unsinn ist.

Es gibt nur so viele gängige Betriebssysteme und so viele Möglichkeiten, fundierte Vermutungen anzustellen. Wenn Sie feststellen, dass ich IIS oder MSSQL Server) ausführe, haben Sie eine Vermutung, welches Betriebssystem darunter ausgeführt wird.

Selbst wenn ich es irgendwie schaffe, einen Stapel auszuführen, der Ihnen nichts über mein zugrunde liegendes Betriebssystem sagt, und auch jeden anderen Hinweis darauf zu maskieren (Fingerabdruck ist eine Sache), habe ich immer noch nicht viel gewonnen.

In Bezug auf die Sicherheit gibt Ihnen das Wissen, dass ich Linux oder sogar Debian 8 verwende, nicht viel, woran Sie arbeiten müssen, und ich muss mir auch keine Sorgen machen. Wenn ich richtig gehärtet und geflickt bin, können Sie wissen, was Sie wollen. Wenn ich mich auf einem Patch-Level befinde, das gestern für das Software-Museum angewendet wurde, wird mich Ihre Reihe von Angriffen weit aufbrechen, indem ich sie einfach alle ausprobiere. Wenn Sie mein Betriebssystem verschleiern, müssen Sie nur ein paar nutzlose Exploits mehr ausprobieren. Bei einem automatisierten Angriff werden Sie einige Sekunden langsamer.

Die Verschleierung funktioniert nicht. Die Leute können Sie scannen, Sie mit einem Fingerabdruck versehen oder einfach ihre gesamte Exploit-Bibliothek werfen, um zu sehen, was funktioniert.

Wenn Sie Zeit mit dem verschwenden, was Sie für das eigentliche Härten hätten ausgeben können, schaden Sie Ihrer Sicherheit.

Richtiges Härten funktioniert. Ich sagte oben, dass "Sie könnten wissen, was Sie wollen" . Ich habe meine IP-Adresse und Root-Passwort auf Sicherheitskonferenzen veröffentlicht, auf denen ich eine Rede gehalten habe. SSH mit Remote-Root-Anmeldung und einer Reihe aktivierter Dienste. Ernsthaft gehärtete SELinux-Maschine. Niemand hat es jemals geschafft, meine Rede zu unterbrechen, obwohl es einer Person einmal gelungen ist, eine Textdatei in das Stammverzeichnis zu legen, als meine Richtlinie noch nicht perfekt war.


Nachtrag: Ihr Ausgangspunkt war ein Film. Verschleierung ist ein großartiges Filmgerät, weil eine solche Offenbarung den Zuschauern sagt, dass der Held (oder Bösewicht) eine Information gefunden hat und somit Fortschritte macht. Es ist der Computer, der dem Herausfinden des Safes entspricht, obwohl Sie den Code noch benötigen. Es spielt keine Rolle, ob es sachlich korrekt ist oder ob es dem Publikum die richtige emotionale Botschaft vermittelt.

13
Tom

Für ein extrem weit verbreitetes Beispiel macht Intel Management Engine, das über ein eigenes Betriebssystem verfügt, so etwas, wenn es einen Firmware-Aktualisierungsmechanismus gibt, die Firmware jedoch in einem ganz bestimmten Format vorliegen muss, dessen Details vertraulich sind. Es scheint sich um eine Huffman-Codierung mit unbekannten Parametern zu handeln. Ähnlich wie bei Ihrem Vorschlag (bei dem es sich im Wesentlichen um eine symmetrische Verschlüsselung der Firmware handelt) erfordert ME zum Zeitpunkt der Firmware-Vorbereitung spezifische Änderungen und weist zur Ausführungszeit eine entsprechende Abweichung von den Standardmechanismen auf.

7
Roman Odaisky

Was Sie beschreiben, heißt "Sicherheit durch Dunkelheit" und ist ein weithin bekanntes Sicherheits-Antimuster . Das heißt, es ist keine neue Idee, sondern eine alte, schlechte Idee, dass Menschen, die nicht in die Sicherheitsphilosophie eingeweiht sind, ausgebildet werden müssen, um nicht darauf hereinzufallen.

Stellen Sie sich vor, Sie entwerfen ein Haus, um sicher zu sein, und dachten, Dunkelheit sei eine vielversprechende Strategie. Alle Häuser bestehen aus Fluren und Räumen, Türen mit Türklinken, Lichtschaltern usw. Da diese allgemein bekannt sind, kann dies als unsicher angesehen werden, da ein Eindringling das Haus anhand dieser allgemein bekannten Bauelemente leicht navigieren kann. Sie könnten versuchen, die Konstruktionsprinzipien von Grund auf neu zu gestalten, Türgriffe durch Rubiks-Würfel zu ersetzen, Decken mit halber Höhe zu machen, um den Eindringling zu verwirren usw. Sie haben ein Haus, in dem es schrecklich ist zu leben, das nicht gewartet werden kann, weil kein Bauunternehmer etwas will damit zu tun, und das Schlimmste ist, dass es umsonst ist, weil jeder Eindringling, der einmal drinnen ist, sich mit seinen Augen umsehen und sein Gehirn benutzen kann, um es herauszufinden. Hacker sind im Herzen Puzzlesüchtige.

Die Lösung zur Sicherung Ihres Hauses besteht nicht in einer nicht standardmäßigen Konstruktion, sondern in besseren Schlössern, gesicherten Fenstern, einem geeigneten Sicherheitssystem usw. Sie möchten Ihr Gold nicht in einem geheimen Durchgang verstecken, weil Abbot schließlich und Costello wird sich auf diesen Kerzenhalter stützen und ihn versehentlich öffnen. Legen Sie Ihr Gold mit einer guten geheimen Kombination und einem Manipulationsalarm in einen Safe. Das Computeräquivalent verfügt über einen eingeschränkten Zugriff auf Berechtigungsnachweise durch Kryptografie mit öffentlichen Schlüsseln, eingeschränkte Benutzerzugriffsrollen, Überwachungssysteme, Reduzierung der exponierten Oberfläche, Minderung von Eintrittsbedrohungsvektoren usw.

Bemühungen, ein Computersystem dunkler zu machen, machen Ihr System nur weiter von der Unterstützung entfernt, schwieriger zu bekommen Sicherheit Patches, schwieriger zu auf sichere Weise zu verwenden .

Edit: Manchmal einige sicherheit durch Dunkelheit ist akzeptabel, wenn sie zusätzlich zur tatsächlichen Sicherheit verwendet wird. Ein häufiges Beispiel ist das Ausführen von SSH auf einem High-Port wie 30000. SSH ist verschlüsselt und der Zugriff erfolgt hinter einer Authentifizierung mit Anmeldeinformationen. Dies ist Ihre wahre Sicherheit. Wenn Sie es jedoch an einem hohen Port haben, fällt es zunächst weniger auf, wenn jemand schnelle Scans durchführt. Alles, was komplizierter ist als dies, wie der Versuch, Ihr Betriebssystem zu verschleiern, würde es nur zu einem betriebsbereiten Albtraum machen, der die tatsächlichen Sicherheitsmaßnahmen (z. B. die Aktualisierung von Patches) erschweren würde.

5
user1169420

Denken Sie Benutzerfreundlichkeit

  • Versuchen Sie Ihrem neuen Systemadministrator zu erklären, dass er ha7TrUO Anstelle von Sudo, RRI6e29 Anstelle von ls und so weiter drücken muss ... Ja, es gibt eine Liste von Übersetzungen, die Sie nur lernen müssen !
  • Durchsuchen des lokalen Netzwerks muss auch nicht möglich sein: Sie müssen eine Papierliste führen, um eine Gesamtansicht zu erhalten!?

  • Wenn Sie alle kritischen Befehle umbenennen, müssen Sie dies ausführen, um ein System-Upgrade durchzuführen!

  • Und als Nick2253-Kommentar aus , Wenn Sie versuchen, ein eingebettetes System zu erstellen, dann verschleiern Sie das Endprodukt, bevor Sie das Endprodukt veröffentlichen.

    • Sie müssen hausgemacht Skript erstellen, um alles für die Verschleierung zu binden.
    • Wenn etwas schief geht, wird das Debuggen schwierig.
    • Sie müssen hausgemachte Deobfuscation-Skripte erstellen, um Debugging durchführen zu können.
    • Benutzerdefiniertes Feedback (mit Protokolldateien) muss auch deobfuscated sein.

    Auf diese Weise fügen Sie eine wichtige Arbeitsebene mit neuen potenziellen Fehlern hinzu.

    Für sehr wenige Sicherheitsverbesserungen siehe weiter

Dunkelheit kann sich selbst schaden.

Denken Sie untere Ebene

  • Selbst wenn Sie versuchen, Dateien umzubenennen, auf Anwendungs- und Betriebssystemebene zu funktionieren, werden bei alledem Standardbibliotheken verwendet, die direkt aufgerufen werden, wenn der Angreifer ausführbare Binärdateien sendet. Sie könnten sogar in Betracht ziehen, alle Standardbibliotheken zu verschleiern! (Einschließlich Dateisystem, Netzwerkprotokolle ...)

  • Während Sie den unveränderten Kernel verwenden, verwenden sie Standard Variablen und Namespaces. Sie müssen also verschleierte Version des Kernels erstellen ...

... Dann binde alles zusammen!

Nun, selbst wenn alles verschleiert ist, muss sich die Anwendung mit dem Internet befassen. Die Verschleierung verhindert nicht, dass konzeptionelle Fehler auftreten!

Dunkelheit Wenn nicht auf allen Ebenen, wird die Sicherheit nicht verbessert.

Volle Dunkelheit Ist nicht wirklich möglich, da Standardprotokolle verwendet werden müssen, um mit dem Internet umgehen zu können.

Denken Sie Lizenz

Wenn Sie verteilenGNU/Linux planen, müssen Sie den Quellcode wie in GNU GENERAL PUBLIC LICENSE GPLv und/oder - beschrieben freigeben. GNU WENIGER ALLGEMEINE ÖFFENTLICHE LIZENZ LGPLv (abhängig von der Anwendung und den verwendeten Bibliotheken). Dies impliziert die Veröffentlichung der Verschleierungsmethode zusammen mit jedem verteilt Produkt.

Beantworten Sie Ihre beiden Fragen genau:

Ich bin ein Experte, aber mit einem sehr kleinen Fokus. Ich habe an einigen verschiedenen Infrastrukturen für kleine Unternehmen gearbeitet und vor einigen Jahren einige Entscheidungen getroffen. Evolution und Geschichte scheinen meine Entscheidungen zu bestätigen, aber es ist nur mein persönlicher Standpunkt.

Wird die beschriebene Verschleierung des Betriebssystems häufig verwendet und ist mir einfach nicht begegnet?

Ich weiß also wirklich nicht, in welchem ​​Verhältnis die Verschleierung weit verbreitet verwendet wird, aber ich verwende nicht Sicherheit durch Dunkelheit = und empfehlen, nicht.

Was sind die praktischen oder technischen Hindernisse für die Verwendung, wenn sie nicht weit verbreitet sind?

Keine Barrieren! Es ist nur kontraproduktiv. Die Zeitkosten werden schnell gigantisch und die Verbesserung der Sicherheit ist ein Köder.

Natürlich sind einige minimale Dinge zu tun:

  • Starten Sie den ssh Server nicht, wenn er nicht benötigt wird
  • Installieren Sie nicht Sudo, sondern verwenden Sie korrekte Berechtigungen, Gruppen und eine kohärente Struktur.
  • Halten Sie Ihre globale Infrastruktur auf dem neuesten Stand !!!

Kleines Beispiel when light come over obscurity

  • Sichern von ssh: in beide Richtungen.

    • Verschieben Sie den SSH-Port von 22 auf 34567

      • leicht und schnell erledigt, aber

      wenn ein Angreifer sie findet, kann er viel Zeit mit sanfter roher Gewalt gegen diesen Port verbringen, bis der Endbenutzer sie entdeckt.

    • installieren Sie die Firewall

      • Stärker, erfordern mehr Wissen, aber.

      Sicherer und aktuell.

4
F. Hauri

Wären nicht ganze Angriffsklassen praktisch nutzlos, wenn das Betriebssystem anstelle von Sudo und ls die Befehle ha7TrUO und RRI6e29 hätte? Stellen Sie sich einen Hacker vor, der irgendwie Remote-Root-Zugriff erhalten hat - was werden sie überhaupt tun, wenn sie keine Befehle kennen?

Eine bessere Alternative wäre, diese Befehle einfach gar nicht erst zu installieren. Ich glaube nicht, dass Sie tatsächlich brauchen eine Shell, um einen Linux-Kernel auszuführen, obwohl dies impliziert, dass Ihr Startvorgang etwas anderes als sysV-init oder systemd ist.

Wie andere angemerkt haben, ist dies jedoch ein Kompromiss zwischen Sicherheit und einfacher Entwicklung. Leider interessieren sich viele Gerätehersteller viel mehr für Letzteres als für Ersteres.

Die Implementierung wäre für Compiler ziemlich einfach. Nehmen Sie den einfachsten Fall von "Benennen Sie diese Funktion und alle Aufrufe um." Sie könnten einem Betriebssystem-Compiler und einem Anwendungs-Compiler dieselben zufälligen Namen geben, und sie könnten miteinander sprechen. Aber selbst wenn die Anwendung eine schlechte Sicherheit aufweist und anfällig für Bash-Injektionen ist, wären solche Angriffe erfolglos.

Ich bin mir nicht sicher, ob Sie die Hilfe von Compiler brauchen. Ich denke, Sie können dies meistens erreichen, indem Sie den Linker ¹ modifizieren, um eine Randomisierung auf alle Symbolnamen anzuwenden. Wahrscheinlich würde es ausreichen, nur eine Hash-Funktion mit einem Salz anzuwenden, das nur dem Hersteller bekannt ist. Ich bin mir nicht sicher, ob Sie dafür überhaupt Quellcode benötigen, d. H. Ich denke Sie könnten das Mangeln auf bereits kompilierten Code anwenden.

(¹ Ich denke, das ist eine Art Lüge. Möglicherweise müssen Sie den Objektcode ändern, um die Symbolnamen zu ersetzen, aber dies ähnelt immer noch eher der Assembler-Ebene, dh a) Sie tun nicht alles die schwer Bits zum Kompilieren von C/C++/etc. Code und b) Sie benötigen nicht den C/C++/was auch immer Quellcode. OTOH Ich bin mir nicht sicher, ob Sie so etwas überhaupt können, wenn Ihr Gerätecode stattdessen so etwas wie Python ist.)

Es besteht jedoch immer noch die Möglichkeit, den Prozess rückzuentwickeln, und darüber hinaus kann dies gegen die GPL² (insbesondere GPLv3) verstoßen, es sei denn, Sie geben das Salz aus, was den Zweck zunichte machen würde.

In der Tat ist "wegen der GPL" wahrscheinlich der Hauptgrund, warum Sie dies nicht sehen; Es wäre schwierig, auf eine Weise zu implementieren, die tatsächlich nützlich ist, abgesehen davon, dass jedes Gerät anders ist. OTOH, das würde zumindest bedeuten, dass Angreifer nur auf bestimmte Geräte zielen können, anstatt eine Sicherheitsanfälligkeit auf " any Geräten unter Linux x.y.z" ausnutzen zu können.

(² Der Einfachheit halber werde ich nur "GPL" verwenden, aber beachten Sie, dass dies im Allgemeinen auch für [~ # ~] l [~ # ~] GPL-Zeug gilt.)

Beachten Sie jedoch, dass Sie in der GPL das Salt nicht veröffentlichen müssen, da Sie die Quellen "geändert" haben. Wenn die Randomisierung des Symbolnamens zur Kompilierungszeit erfolgt, haben Sie nicht die Quellen geändert. Der Grund, warum Sie das Salt veröffentlichen müssten, ist, dass die GPL erfordert, dass Benutzer ihre eigenen Versionen einer GPL-Bibliothek ersetzen können, was sie nur tun können, wenn sie das Salt kennen. (Wie bereits erwähnt, können Sie dies möglicherweise mit GPLv2 verhindern, aber die technischen Auswirkungen ähneln denen von "Nur signierte Software ausführen", für die GPLv3 speziell geschrieben wurde.)


Letztendlich könnte es hier einen Vorteil von einige geben, aber Sie werden kein besonderes System besonders sicherer machen (es ist bekannt, dass "Sicherheit durch Dunkelheit" "Im Allgemeinen gibt es überhaupt keine Sicherheit). Was Sie können erreichen, macht es schwieriger, viele Systeme über einen einzigen Vektor anzuvisieren.

4
Matthew

Faire Offenlegung: Ich bin der CTO eines Unternehmens, das genau dies aufbaut. De-Bias für alles, was Sie wollen.

Es IS ist tatsächlich möglich, einen Systemkernel, Gerätetreiber, Pakete, den gesamten Stapel pro Host mehrmals pro Tag vollständig zu erstellen, und es kann sehr effektiv sein. Genau das tun wir und wir helfen unseren Kunden dabei. Wir sind nicht die Einzigen - wir können daraus schließen, dass zumindest Google dies auch für alle Computer tut (Referenz in Kürze).

Wenn Sie nun die Möglichkeit hatten, pro Maschine von Grund auf neu zu erstellen, welche Dinge können Sie ändern?

Das Kernel Self Protection Project ermöglicht dies bereits durch zufällige Neuordnung von Kernelstrukturen: https://lwn.net/Articles/722293/ . Dieser Artikel verweist auch auf den berühmten Austausch, an dem Linus Torvalds es Sicherheitstheater nennt, aber der Autor des Projekts (der bei Google arbeitet) kommentiert: "Nun, Facebook und Google veröffentlichen ihre Kernel-Builds nicht. :)"

Dies führt zu der Schlussfolgerung, dass zumindest Google dies tut und dies für nützlich hält. Können wir MEHR Arten von Scrambling über einen geschlossenen Satz machen? Warum läuft auf der grundlegendsten Ebene kein Windows-Virus unter Linux oder Mac? Weil die Formate unterschiedlich sind. Es ist alles x86 darunter und doch ist es nicht dasselbe. Was wäre, wenn zwei Linux auf ähnliche Weise unterschiedlich wären? Windows vs Linux ist keine "Verschleierung", nur weil wir nicht viele Möglichkeiten haben, Linux so unterschiedlich zu machen wie Windows von Linux. Aber es ist nicht unmöglich und es ist nicht wirklich so schwer. Nehmen Sie den KSPP-Ansatz und wenden Sie ihn auf Systemaufrufe an. Kompilieren Sie dann alles oben auf diesen Systemaufrufen neu. Das wird hella schwer zu brechen sein - zumindest nicht im Vorbeiflug.

Ihre Frage betraf jedoch das Umbenennen von Symbolen (Namen von ausführbaren Dateien, Bibliotheken usw.). Dies hat zwei Aspekte: (a) Ist es nützlich? (b) Kann es zuverlässig gemacht werden?

Wir suchten nach einer Möglichkeit, PHP Code-Injektionen ein für alle Mal zu lösen. Ungeachtet dessen, was HackerNews würde Sie glauben lassen , PHP Code-Injektionen sind kein gelöstes Problem außerhalb von Internet-Message-Boards. Entwickler, Administratoren und Benutzer im realen Leben PHP sind einer kontinuierlichen Anzahl von Code-Injektionen ausgesetzt.

Also machten wir uns daran, Polyscripting (mit MIT lizenziertes Open Source) auszuprobieren: https://github.com/polyverse/polyscripted-php

Wir teilen dies öffentlich, um Feedback einzuholen, und betreiben zwei Websites, polyscripted.com und nonpolyscripted.com , die genau das tun, was Sie aufgrund ihrer Namen erwarten würden. Wir haben auch Pentester angeheuert, um zu versuchen, es zu brechen.

Und ich fange gerade erst an, mit ausführbaren, gemeinsam genutzten Bibliotheken und dem Umbenennen von exportierten Symbolen über einen geschlossenen Satz (zum Beispiel in einem Docker-Container) zu experimentieren. Ich persönlich denke nicht, dass dies so viel Wert hinzufügt, aber wird es ein wenig hinzufügen? Ich glaube schon. Es kommt also auf die Kosten an. Wenn Sie für noch geringere Kosten nur einen geringen Wert erzielen können, warum nicht einfach? Das ist genau der Grund, warum wir alle ASLR haben - es ist nicht gerade die beste Verteidigung seit geschnittenem Brot, aber wenn Sie bereits verschiebbaren Code haben und ihn trotzdem neu ordnen werden, warum sollten Sie ihn dann nicht bis zum Limit verschieben und nach dem Zufallsprinzip sortieren?

Kurz gesagt, der von Ihnen beschriebene Ansatz wird von vielen Menschen (einschließlich Google, Facebook, dem Linux-Kernel usw.) sowie von vielen Akademikern auf dem Gebiet der Moving Target Defense und einer Handvoll Unternehmen wie dem unseren versucht. Ich versuche es trivial konsumierbar zu machen wie ASLR.

2
Archis Gore

Ich würde sagen, wie ich das aus Hacker-Sicht sehe.

Wenn Sie alle Dienstprogramme umbenennen, wird dies die Dinge für mich viel schwieriger und weniger komfortabel machen, aber was könnte ich tun?

  1. Wenn ich auf dem System bereits Zugriff auf Shell hätte, würde ich einfach entweder eine Busybox (alle grundlegenden Dienstprogramme in einer Binärdatei) oder einen vollständigen Satz von Binärdateien hochladen, die ich für grundlegende Vorgänge benötige.

  2. Um die Berechtigungen weiter zu erweitern, muss ich möglicherweise nach Suid-Root-Binärdateien suchen, und es gibt nur wenige davon (Sudo, Mount usw.). Hacker können solche Dateien nicht hochladen (es sei denn, er ist bereits root). Mein einfaches kleines Linux-System hat nur 24 Suid-Binärdateien. Sehr einfach, jedes manuell zu versuchen.

Ich stimme jedoch zu, dass dies das Hacken dieser Box erschweren würde. Es wäre schmerzhaft, dieses System zu benutzen (zu hacken), aber möglich. Und Hacker arbeiten stunden-, tag- oder monatelang auf dem System ... aber Administrator/Benutzer arbeiten möglicherweise jahrelang auf dem System und können sich nicht an die Namen ha7TrUO und RRI6e29 erinnern. Vielleicht wird niemand versuchen, das System zu hacken, aber der Administrator wird jeden Tag darunter leiden.

Aber ... wenn Sie die Sicherheit zu hoch, aber für Benutzer/Administrator unangenehm machen, verringern Sie häufig sogar die Sicherheit. Wenn Sie beispielsweise komplexe Kennwörter mit mehr als 20 Zeichen erzwingen, werden die Kennwörter höchstwahrscheinlich auf Haftnotizen auf dem Monitor geschrieben. Wenn Sie das System so verschleiert machen, wird es für gute Benutzer sehr schwierig sein, daran zu arbeiten. Und sie müssen einige Dinge tun, um ihr Leben leichter zu machen. Zum Beispiel können sie ihre Busybox-Binärdatei hochladen. Temprorary. Und sie werden es vergessen oder absichtlich dort lassen (weil sie planen, es wenig später zu benutzen).

1
yaroslaff

Es passiert tatsächlich, weil SSH-Verbindungen verschlüsselt sind. Das Ändern der Namen einiger Kernbinärdateien führt zu nichts anderem. Es würde auch viel Chaos verursachen: z. Alle Skripte, die auf diesen Dienstprogrammen basieren, werden entweder unbrauchbar gemacht, oder Sie benötigen eine Art Proxy "Deobfuscator", der sicherlich als Angriffsvektor enden würde. Ich habe jedoch einige Server in freier Wildbahn gesehen, die keine Root-Anmeldung zulassen und stattdessen Sudo verwenden müssen. Die Benutzernamen von Sudoern bleiben etwas geheim. Ich bin mir nicht sicher, wie sicher es ist, aber ich bin kein Experte.

0
galaktycznyseba

Warum haben nicht alle Türen zehn Schlüssellöcher, von denen nur eines tatsächlich für Schlüssel oder Schlossknöpfe funktionierte? Antwort: Meistens ist die Mühe die zehn zusätzlichen Sekunden der Zeit eines Diebes nicht wert.

Wenn es Millionen von eindeutigisoliert erstellt Quellcode-Betriebssystemen gäbe, könnte es zu einer Verschleierung kommen. In der Praxis haben wir jedoch ungefähr vier eindeutige Codebasen im allgemeinen Gebrauch - alle Leckinformationen über sich selbst nach Ereigniszeitpunkt und für mehrere Betriebssystemfunktionen auf niedriger Ebene, bei denen Chiphersteller vorgeschriebene Maschinenbitcode-Sequenzen zum Aktivieren oder Zugreifen auf bestimmte CPU-Funktionen angeben Alle haben wahrscheinlich kurze Sequenzen, die genau den gleichen Code enthalten.

0
Dusty