„Security through obscurity“ oder „Security by obscurity“ (deutsch „Sicherheit durch Obskurität“, auch „Sicherheit durch Unklarheit“) ist ein Prinzip in der Computer- und Netzwerksicherheit. Es versucht, die Sicherheit eines Systems oder eines Verfahrens zu gewährleisten, indem seine Funktionsweise geheim gehalten wird.“ – So beschreibt Wikipedia Security by obscurity.

Ein Geheimnis ist dann gut, wenn das Verfahren öffentlich sein kann und die Sicherheit sich nur auf den Schlüssel verlässt. Wenn also die Sicherheit einer Haustür darauf beruht, dass es kompliziert ist die Türklinke zu verwenden, ist dies nicht sicher. Es ist öffentlich bekannt, wie das Schloss einer Tür funktioniert, die Sicherheit hierbei beruht darin, dass nur bestimmte Personen den (geheimen) Schlüssel haben.

Ein klassisches Beispiel, das aus dem Alltag bekannt ist, wäre der berühmte Schlüssel unter der Fußmatte. Alternativ kann dieser auch in einem Blumentopf oder woanders versteckt sein. Jedem ist bekannt, dass es Menschen gibt, die ihre Schlüssel in der Umgebung des Schlosses verstecken. Dieses Geheimnis ist also nicht gut.

Im Folgenden möchte ich Beispiele aus der Welt der Programmierung und IT-Sicherheit näherbringen, die uns bei Audits über den Weg laufen.

Ping/Portscans ignorieren

Die wohl bekannteste Maßnahme ist das Ignorieren von Anfragen auf bestimmten Ports oder für bestimmte Protokolle (z. B. ICMP für Ping). Dies wird meist durch eine Firewall realisiert, welche Pakete entweder durch einen „DROP“ oder einem „REJECT“ ablehnt. Üblicherweise werden bei einem Portscan die offenen Ports in „connection established“ und „connection rejected“ eingeteilt. Wird bei einer Anfrage aber durch eine Firewall ein „DROP“ initiiert, kommt es zu keiner Antwort durch den Server. Hier können die Ports demnach in „connection established“ und „connection timed out“ kategorisiert werden.

Selbst wenn ein Angreifer einen traditionellen Scanner verwendet, wird man diesen zwar verlangsamen, doch da Portscans meist automatisiert ablaufen, nicht weiter stören.

Eine restriktive Firewall ist eine essentielle Schutzmaßnahme, aber das Verstecken von Diensten hinter der Firewall macht diese nicht sicher. Wenn man beispielsweise SSH auf einem Server ohne Authentifizierung betreibt und den Zugriff nur über eine Firewall einschränkt, stellt dies weiterhin eine kritische Schwachstelle dar.

Services (SSH, FTP) auf andere Ports

Während Anfragen an geschlossene Ports in Firewalls oft einfach ignoriert werden, legen viele Systemadministratoren ihre Services auf andere Ports. So wird SSH statt auf Port 22 auch gerne auf Port 2222 oder 2200 verlegt.

Hierbei wird ein Angreifer dazu gezwungen, Portscans durchzuführen, um genauere Informationen über offene Ports auf dem jeweiligen Server zu erhalten. Auch dies verlangsamt einen Angreifer lediglich und trägt nicht zur eigentlichen Sicherheit bei, die bei SSH, Login durch Schlüssel, oder Passwörter gegeben wäre.

Code Obfuscation

Durch Code Obfuscation wird lesbarer Code so verändert, dass er zwar ausführbar, aber von Menschen nicht mehr direkt interpretierbar ist.

Folgender Code definiert eine Variable „myPassword“ mit einem Wert und gibt diese über eine alert-Box aus. Im rechten Fenster ist der veränderte Code zu sehen, welcher nicht auf den ersten Blick lesbar ist.

Dies ist natürlich ein sehr simples Beispiel und es kann natürlich noch in beliebige Komplexitätsstufen ergänzt werden. Die Gefahr hierbei ist dennoch immer, dass der Inhalt nach wie vor zu einem gewissen Teil zurückgebaut werden kann und auch muss. Spätestens auf Maschinensprache ist die Logik wieder vorhanden.

Man erhöht somit die Angriffszeit (und natürlich auch die Zeit für einen Penetrationstest), da ein Angreifer zuerst den Code in eine lesbare Form bringen muss, um ihn adäquat anzugreifen.

Aber die geheimen Informationen stehen immer noch im Code und können von einem Angreifer mit Elan und Zeit wieder in eine lesbare Form gebracht werden. Oft fordert ein Obfuscated Code sogar heraus ihn zu verstehen, da es bei gutem sicheren Code keinen Grund geben sollte, ihn zu verschleiern.

Selbstentwickelte Kryptographie

Am meisten fällt Security by obscurity wohl in der Kryptographie auf. Nirgends wird mehr mit Geheimnissen gegeizt wie dort. Sämtliche als sicher standardisierte Verschlüsselungen sind quelloffene Algorithmen.

Da selbstentwickelte Kryptographie auch oft mit Code Obfuscation einhergeht, ist es nicht verwunderlich, dass hier auch Passwörter im Quellcode hinterlegt werden. Bei solcher Verschlüsselung wird oft damit argumentiert, dass die Routinen nicht bekannt sind und somit die Vertraulichkeit der verschlüsselten Daten gewährleistet ist.

Selbst nachprogrammierte Algorithmen zu AES, RSA können signifikante Fehler enthalten, die die Verschlüsselung angreifbar machen. Oft werden aber einfache XOR-Masken verwendet, um Daten zu „verschlüsseln“.

Verschlüsselung ist nicht gleich Verschlüsselung

Verschlüsselung ist eine essentielle Schutzmaßnahme, die an verschiedenen Stellen zum Tragen kommt. Je nach Szenario muss die korrekte Methode gewählt werden. Oftmals wird Verschlüsselung fälschlicherweise als absolut angesehen, wenn also für die Kommunikation TLS verwendet wird, ist alles verschlüsselt und sicher. Das ist jedoch nicht der Fall. TLS schützt die Kommunikation, soweit ist das richtig, aber TLS schützt keine gespeicherten Inhalte.

Ein anderes Beispiel ist WLAN-Verschlüsselung, die lediglich die Kommunikation von dem Endgerät, wie z. B. einem Smartphone, und dem verbundenen WLAN Access Point schützt. WLAN-Verschlüsselung (z. B. WPA2) ersetzt keinesfalls TLS als Transportverschlüsselung.

Verschlüsselung muss dem Einsatz entsprechend gewählt werden. Für die Verschlüsselung der Kommunikation kann TLS verwendet werden und für die Speicherung von Passwörtern sollten dedizierte Methoden verwendet werden.

Drei-Schicht-Architektur mit einem Proxy als dritte Schicht

Es kommt sehr häufig vor, dass sämtliche Zugriffe zu den Datenbankservern über eine dritte Schicht geregelt werden, dort aber keinerlei Zugriffskontrollen stattfinden, oder sogar die Datenbankbefehle vom Client direkt an diese Schicht geschickt werden, um sie dann ohne Veränderung auszuführen.

Die dritte Schicht agiert somit lediglich als Proxy und hat keinerlei Sicherheitsnutzen. Naja. Zumindest stehen die Datenbankzugangsdaten nicht mehr in der Applikation, doch können die Daten immer noch von der dritten Schicht bezogen werden.

Wie man in einer Zwei-Schicht-Architektur sicher eine dritte Schicht einzieht, haben wir bereits in einem anderen Blog-Artikel beschrieben.

Fazit

Sehr viele in der IT haben den Spruch „security through obscurity is no security at all“ schon mindestens einmal gehört und ich bin oft auch ganz vorne dabei, ihn zu nennen. Doch müssen wir den ganzen Aspekt differenzierter betrachten.

Natürlich sollte eine Applikation, welche keine Schwachstellen hat, keine Code Obfuscation brauchen. Oder ein gehärteter Server, welcher alle Ports geschlossen und Services auf neustem Stand sind, Portscans oder Pings ignorieren. Aber es schadet auch nicht und erzeugt bei einem Angreifer vermehrte Umstände. Zeit ist bekanntlich Geld.

Doch sollten Sie sich auf diese „Sicherheits“-Mechanismen niemals verlassen und sie sollten auch keine weiteren Umstände innerhalb Ihres Unternehmens erzeugen.

Seinen Schlüssel unter die Fußmatte legen ist also nicht sicher. Aber wenn man den Schlüssel in einen Safe mit geheimer Zahlenkombination steckt und diesen Safe mitsamt dem Schlüssel unter die Fußmatte packt, erhöht man die Sicherheit drastisch.