zurück zur Übersicht

5 Dinge die Penetrationstester nicht ausstehen können

Als Penetrationstester hat man mit vielen unterschiedlichen Personen zu tun, von Entwicklern, Abteilungsleitern bis zu Vorständen. Auch wenn die meisten Projekte einwandfrei vonstatten gehen, hat wahrscheinlich jeder Penetrationstester seine Top 5 der „No-Gos“ in Penetrationstests. Dies sind meine persönlichen Top 5

Absichtliches verstecken von Funktionen vor einem Penetrationstest

Die meisten Entwickler freuen sich über einen Penetrationstest! Oftmals einfach aus dem Grund, das ihnen selbst das Wissen um sichere Softwareentwicklung fehlt und sie selbst „Bauchschmerzen“ bei der aktuellen Entwicklung haben, oder einfach weil ihnen die Zeit dafür fehlt. Leider erlebt man als Penetrationstester auch genau die andere Seite. Manchmal versuchen Entwickler absichtlich bestimmte Funktionen zu verstecken, von denen sie wissen, dass eventuell nicht sauber gearbeitet wurde.Besonders unschön war ein Fall vor ein paar Jahren: Damals hab ich mich gewundert, dass der Abruf des Administrationsportales nur mit „403 Forbidden“ quittiert wurde, und hab mir schon gedacht das die ja ganz genau sind. Einige Stunden später hab ich über eine andere Schwachstelle Einsicht in die .htaccess Konfiguration erlangt. Es stellte sich heraus, dass eine Filterung auf unsere Firmen-IP-Adresse stattgefunden hat. In dem Fall handelte es sich um einen Black-Box-Test ohne vorherige Bereitstellung von Zugangsdaten. Allerdings heißt Black-Box nicht, dass die Entwickler bewusst Maßnahmen durchführen sollten um den Penetrationstest zu erschweren!

Deswegen: Lieber Entwickler, unterstützt uns bei unserer Arbeit, denn unser einziges Ziel ist es, dass am Ende die Sicherheit der Applikation erhöht wird. Das sollte das Interesse aller Beteiligten sein.

Nach dem Penetrationstest ist vor dem Penetrationstest

Nicht nur Entwickler, Projektleiter und andere beteiligte Personen nervt es, wenn die gleichen Schwachstellen im erneuten Test der Applikation wieder auftreten. Auch den Penetrationstester nervt es, wenn Empfehlungen nur halbherzig implementiert werden. Es kann durchaus passieren, dass die Schwachstellen nicht einwandfrei behoben wurden – dafür führen wir ja die Re-Tests durch. Was ich persönlich allerdings nicht verstehe, ist wenn Entwickler komplett die ausführlichen Verbesserungsvorschläge in unseren Abschlussberichten ignorieren.  Zuletzt hat mir ein externer Entwickler bei einem Kunden versucht zu erklären, dass Parameter in POST Requests überhaupt nicht manipuliert werden könnten und er deswegen in seiner Applikation nichts anpassen müsste. Damals hat sogar der (nicht technische) Projektleiter reingegrätscht und mit deutlichen Worten widersprochen.

Ok, wir bauen einfach eine Web Application Firewall davor!

Sicherheitsprodukte sind wichtig und notwendig. Allerdings sollte man es tunlichst unterlassen diese als „First and Last Line of Defence“ zu verwenden, frei nach dem Motto „eine WAF löst all unsere Implementierungsprobleme“. Das tut sie eben nicht! Eine Web Application Firewall kann in der Regel nur patternbasiert gegen Angriffe helfen – nicht selten dauert die Implementierung bei großen Applikationen Monate, um die richtigen Einstellungen der Patterns zu haben. Was eine WAF in der Regel nicht kann, ist vor logischen Fehlern schützen. Ein Klassiker sind zum Beispiel Autorisierung- und Authentisierungsübergriffe. Dabei handelt es sich um Angriffe, die es dem Angreifer ermöglichen, unerlaubt auf Applikationsbestandteile zuzugreifen, oder legitime Funktionen aufzurufen um Datensätze auszulesen, die nicht für den aktuellen Benutzer freigegeben sein sollten. Deswegen: Nein, als Penetrationstester kann ich in diesem Zusammenhang die Erwähnung einer WAF als Alternative zur notwendigen Behebung von Schwachstellen nicht mehr hören. Als „Second Line of Defence“ nach der applikationseigenen Abwehr eignet sie sich allerdings sehr gut – insbesondere weil eine WAF die notwendige Visibilität für Angriffsversuche darstellen kann.

Können Sie uns jetzt noch ein Siegel geben?

Manchmal kommt es auch vor, dass Applikationen sehr gut entwickelt wurden und wenig berechtigte Kritik zulassen. Ein Penetrationstest kann allerdings niemals den Anspruch auf Vollständigkeit haben. Firmen, die behaupten, sie könnten Sicherheit in technischen Systemen hundertprozentig zertifizieren machen sich unseriös.
Warum? Ein Penetrationstest hat immer einen begrenzten Fokus. Wenn das Ziel eines Angriffes zum Beispiel eine Webapplikation und die zugehörige Infrastruktur ist, prüfe ich genau diesen Testgegenstand. Weder prüfe ich Windows auf Schwachstellen, noch prüfe ich jede einzelne Codezeile des Applikationsservers oder des verwendeten Servers. Als Penetrationstester fokussiert man sich auf die jeweiligen Applikationen und Dienste und nicht auf das Gesamtsystem als solches (mit allen jeweiligen Komponenten).Deswegen: Nein, wir können leider kein Siegel ausstellen, auch nicht nach einem super Ergebnis. Aber ein Abschlussbericht enthält bei uns in jedem Fall detaillierte Informationen über die einzelnen Tests, auch wenn wir nichts Kritisches gefunden haben!

Während dem Penetrationstest Schwachstellen fixen, ohne Rücksprache

Das ist so ungefähr das Schlimmste und landet daher auf Platz 1 meiner „TOP-Liste“. Bisher ist es zum Glück noch an einer Hand aufzählbar, wie oft das passiert ist. Als Leser müssen Sie sich einfach mal vorstellen, Sie würden gerade versuchen ein Problem in Ihrem Fahrzeug zu identifizieren. Sie sind sich fast sicher, dass es sich um ein defektes Kabel handelt. Und auf einmal wechselt jemand die gesamte Verkabelung aus und Sie denken sich, was geht hier vor sich!?! So ähnlich geht es einem Penetrationstester wenn „plötzlich“ Schwachstellen nicht mehr existieren, die doch vor 10 Minuten noch da waren. Das beschriebene Szenario sorgt nicht unbedingt für Motivation bei Ihnen oder? Eben, bei uns auch nicht.

 

Schreibe einen Kommentar