Specific Criticism of CVSS4
Marc Ruef
Obschon ich ein bisschen zwiespältig der Figur Kevin Mitnick gegenüberstehe, habe ich in mancherlei Hinsicht unverhohlene Hochachtung vor seiner Person. So ist es unbestritten, dass er einen beachtlichen Teil dazu geleistet hat, dass Social Engineering salonfähig geworden ist. Ohne seine bekannten Angriffe und die Medienwirksamkeit, die diese erzeugt haben, wäre das Thema Computersicherheit heute wohl noch viel eher ein rein technisches Gebiet – Die menschlichen und psychologischen Elemente würden wohl unweigerlich unterschätzt werden.
So ist es in der Tat gegeben, dass wir ab und an einen Social Engineering-Auftrag umsetzen müssen. Dabei geht es in den meisten Fällen innerhalb eines Penetration Testing-Projekts darum, die menschliche Komponente der Sicherheit zu überprüfen. Das Ziel ist nicht, einzelne Personen blosszustellen oder eine Demonstration umzusetzen, dass der Mensch ansich für Fehlleistungen anfällig ist. Dies ist wohl jedem bewusst. Stattdessen verstehen sich solche Aktionen als Überprüfungen der Prozeduren eines Unternehmens, die eben genau Fehler in der menschlichen Komponente sowie den umgesetzten Prozessen determinieren können soll.
Vor einiger Zeit kontaktierte uns ein Mitbewerber, der ebenfalls im Bereich des technischen Security Auditings tätig ist. Er machte daraus kein Geheimnis und fragte offen an, ob wir einen ihrer Mitarbeiter in Bezug des Penetration Testings auf den neuesten Stand bringen könnten. Ihre Leuten könnten zwar nmap und Nessus bedienen, wissen auch, wie sie ein false positiv erkennen – Aber das effektive Ausnutzen von Schwachstellen und damit der wichtigste Teil eines Penetration Tests ging ihnen abhanden. Weiter soll es sich nicht nur um eine herkömmlich aufgezogene Einzelschulung handeln. Stattdessen soll in dieser direkt einer ihrer Kunden abgearbeitet werden. Das Management wollte wohl mal wieder zwei Fliegen mit einer Klappe schlagen und die Techniker hätten dieses Kunststück dann vollbringen sollen.
Wie ich nunmal bin, riet ich von der Sache ab. Nicht, weil ich nicht wollte, dass der Mitbewerber einen Vorteil im Markt erlangen könnte, indem wir ihm unsere Herangehensweise zeigen. Nein, stattdessen erschien es für mich sowohl unmöglich, innerhalb eines Arbeitstages sämtliche Kniffe zu zeigen. Und zudem ist es umso schwieriger, eine Sache näher zubringen, wenn diese direkt in einem Projekt verknüpft ist. Die Aktion bleibt zwar sehr realitätsnah, wird jedoch aufgrund fehlender didaktischer Manipulationen umso schwieriger zu verstehen. Dennoch, man einigte sich auf diesen einen Tag.
Der Auditor des Mitbewerbers kam zu mir ins Büro und ich liess ihn mir als erstes erzählen, was er von diesem Tag erwarte. Zudem berichtete er mir, was er bereits innerhalb des Testings, eine Überprüfung einer Zweigstelle eines Unternehmens in der Ukraine, gefunden hatte. Seine Ausgaben mit nmap, Nessus, nikto, usw. zeigten mir, dass es sich um einen simplen und gut strukturierten Perimeter handelte. Obschon ein ganzer Klasse A-Netzblock auf den Kunden registriert war, schienen nur einige wenige Hosts aus dem Internet direkt erreichbar. Diese – neben einem Mail- und Webserver ebenfalls einen Terminal Server auf Windows Server 2003 – wurden wohl durch eine zentrale Firewall-Komponente (CheckPoint Firewall-1) geroutet.
Erfahrungsgemäss kann ich sagen, dass umso kleiner eine Umgebung ist, umso grösser die Chance ausfällt, dass der Administrator in dieser ein beharrliches Augenmerk auf die Sicherheit dieser richtet. So war es dann auch, denn sämtliche Geräte schienen auf dem neuesten Stand: Aktuellste Software-Versionen und die neuesten Patches machten es praktisch unmöglich, innerhalb dieses einen Tages einen rein elektronischen Einbruch umzusetzen. Andere Möglichkeiten mussten her.
Ich wies darauf hin, dass meine Erfahrungen mit Social Engineering sehr gut sind. Ein solide inszenierter Zugriff verspricht bei mindestens 10 % der Benutzer Erfolg. Er willigte ein, dass dies die letzte Möglichkeit im Rahmen des Projekts war, um noch einen Erfolg verbuchen zu können. Nachdem wir ein klassisches technisches Footprinting gemacht hatten, diskutieren wir das Vorgehen. Wir fanden 31 Mailadressen der Benutzer, was natürlich mit einer direkten Querprüfung der jeweiligen Personen einher ging. Vor allem eine Person namens Andrey, er nannte sich im Internet Andy, fiel uns auf. Dieser postete seit Jahren regelmässig in FreeBSD-Newsgruppen im USENET. Diskutiert dort vor allem Probleme bei Paketen. Da wir bei einem vorgängigen OS-Fingerprintnig gesehen hatten, dass sowohl Mail- als auch Webserver auf FreeBSD liefen, vermuteten wir, dass Andy der Administrator dieser Hosts war.
Da wir aufgrund des technischen Information Gatherings sagen konnten, dass der Administrator sehr gute Arbeit in Bezug der Sicherheit des Perimeters geleistet hatte, riet ich davon ab, diesen in einen Social Engineering-Eingriff zu verwickeln. Sein Verständnis für Computersicherheit wäre wohl zu hoch und die ganze Operation könnte auffliegen. Es erschien sodann erfolgsversprechender, wenn wir eine der weiblichen Angestellten angehen würden. Da sich Frauen erfahrungsgemäss weniger für Computer und noch weniger für die Sicherheit dieser interessieren, liess uns ein solches Szenario mehr Handlungsspielraum. Durch einen psychologischen Trick hätten wir beispielsweise mit unserem technischen Wissen Druck aufbauen und so die Zielperson zu einer kompromittierenden Handlung verleiten können.
Ich bin dafür bekannt, dass ich mich bis ins letzte Detail auf solcherlei Operationen vorbereite. So schlug ich vor, dass wir als erstes einige Dinge über die Ukraine lesen sollten. Ein kurzer Abriss historischer und politischer Entwicklungen, Darlegungen in Reiseführern und statistische Angaben zur Population und ihres durchschnittlichen Bildungsstandes würden eine wichtige Stütze werden. So rätselten wir zunächst darüber, wie gross die Chance sei, dass unsere Zielperson aufgrund eines soliden Sicherheitsverständnisses Verdacht schöpfen könnte. Ein bisschen Zahlentheorie – Numb3rs lässt grüssen – konnte uns bei der Beantwortung dieser Frage behilflich sein.
In den Jahren 2002 bis 2004 waren in der Ukraine 10’833’300 Telefonleitungen in Betrieb, 4,4 Millionen Mobiltelefone angemeldet, 3,8 Millionen Internet-Anschlüsse registriert und 94’345 Server mit der landeseigenen Top-Level-Domain .ua positioniert. Die Bevölkerung betrug im Juli 2005 47’425’336. Uns interessieren für die Rechnung aber nur diejenigen im erwerbstätigen Alter von 15 bis 64 Jahren. Dies sind 68 % der Gesamtbevölkerung mit 15’619’989 Männer und 16’992’628 Frauen; also ein Total von 32’612’618 potentiell erwerbstätigen Personen. Sodann besitzen nur jede zehnte Person ein Mobiltelefon und einen Internetanschluss. Und nur jede hundertste Person betreibt einen Server mit der Landesdomain. Im Vergleich zu den Industriestaaten, zum Beispiel Deutschland, ist das Verhältnis bei Mobiltelefonen zu 120 %, bei Internet-Anschlüssen zu 90 % und Internet-Servern mit DE-Domain zu 100 % grösser. Statistisch gesehen ist die Chance also rund 110 % kleiner, dass eine unserer Zielpersonen Zugriff auf Technologien hat und sich mit diesen auskennt (Für eine Grossstadt wie Kiev wohl nicht ganz so extrem, aber der Trend war dennoch absehbar). Da selbst der Erfolg von Social Engineering-Attacken hierzulande enorm hoch ist, müsste es in der Ukraine noch zig mal höher sein, wie uns die grobe Wahrscheinlichkeitsrechnung zeigte.
Sodann ging es ans Eingemachte. Wir riefen bei der Hauptnummer des Büros in der Ukraine an. Dort meldete sich eine Anya, die wir sogleich darüber informierten, dass im Hauptsitz in der Schweiz ein technisches Problem vorliegen würde. Unsere Datenbank sei korrupt geworden und einige Benutzerkonten seien nicht mehr zugänglich. Wir würden ihr ein Email schicken, das einen Link auf einen Intranet-Server enthielt. Als sie die durch uns vorbereitete Webseite aufrief wurde sie von uns angehalten, dort zur Überprüfung ihre Mailadresse, den Benutzernamen und das Passwort einzugeben. Der Trick bestand darin, dass diese sensitiven Benutzerdaten nach dem Abschicken des Formulars an uns gesendet werden würden und wir so in den Besitz dieser kommen würden. Halt das typische Phishing.
Die Aktion nahm jedoch eine unerwartete Wendung. Die Dame wusste nicht, was ein Benutzername ist – Sie würden sowas nicht nutzen. Ich musste mich wirklich beherrschen, dass ich nicht in schallendes Gelächter ausbrach, denn das Ganze schien an der Unwissenheit der Benutzer zu scheitern. Wir wiesen Anya an, dass sie im Büro nachfragen sollte, ob jemand einen Benutzernamen und ein Passwort kennen würde. Schön artig las sie das Mail, das wir ihr geschickt hatten und die Instruktionen für unsere Phishing-Attacke enthielt, im Grossraumbüro vor. Ich musste zeitweilig das Mikrophon des Telefons ausschalten, denn diese absurde Situation amüsierte mich ungemein. Diese unendliche Unbeholfenheit führte dazu, dass mir Anya schon fast ein bisschen leid tat, klang sie doch sehr sympathisch und hilfsbereit am Telefon.
Und in der Tat scheiterte das Ganze. Die Dame und ihre Kollegen waren nicht in der Lage, uns auch nur irgendeinen Benutzernamen nennen zu können. Sowas gäbe es da nicht. Analysen des Webzugriffs haben uns ebenfalls gezeigt, dass sie uralte Windows-Versionen im Einsatz haben, die gar nicht auf den Multiuser-Betrieb und sichere Authentisierungen ausgelegt waren. Uns blieb nichts anderes übrig als Anya zu sagen, dass wir der Sache nachgehen und uns wieder bei ihr melden würden. Eines hat mich die Geschichte gelehrt: Fehlendes Verständnis oder Wissen muss nicht zwingend ein Nachteil für die Sicherheit einer Umgebung sein!
Our experts will get in contact with you!
Marc Ruef
Marc Ruef
Marc Ruef
Marc Ruef
Our experts will get in contact with you!