Blog
Der Pentest. Ein Muss für sichere Software
Von Haus aus bin ich Softwareentwickler. Seit ca. zwei Jahren führe ich zudem regelmäßig Pentests durch – eine natürliche Folge meiner intensiven Beschäftigung mit IT Security.
Es ist jedoch nicht allzu lange her, dass ich mich selbst in der Rolle des „Prüflings“ wiederfand, nämlich als „meine“ eigene Anwendung getestet wurde – von jemand anderem als mir selbst. Und ich muss zugeben: Ich hatte Lampenfieber.
Diese Erfahrung möchte ich zum Anlass nehmen, hier mal einen kurzen Überblick darüber zu geben, was ein Pentest genau ist und warum Pentester:innen unsere natürlichen Verbündeten sind. Denn am Ende geht es nur um eins: um sauber und sicher gecodete Software – die wir schließlich alle anstreben!
Schritt 1: Vorgespräch
Die Vorbereitung: Alles beginnt mit dem Vorgespräch, in dem die zu testende Anwendung demonstriert und dem/der Pentestenden die Zugangsdaten für einen „normalen“ Benutzer und einen „allmächtigen“ Benutzer übergegeben werden. Bei der Gelegenheit werden auch die Rahmenbedingungen des Pentests wie etwa Testumfang, Testzeitraum etc. abgesteckt.
Wichtig: Auf dem zu testenden System dürfen keine produktiven Daten liegen. Auch keine sonstigen Daten, die unter die DSGVO fallen könnten. Im besten Fall gibt es ein dediziertes System, manchmal genügt auch das vorhandene Testsystem. So oder so sollte es während des Testzeitraums nicht verändert werden.
Schritt 2: Prüfung der Testbarkeit
Der oder die Pentester:in prüft, ob die Zugänge funktionieren. Manchmal fehlen zum Beispiel ein paar Firewall-Freigaben, die noch rechtzeitig erteilt werden sollten.
Schritt 3: Durchführung
Zum vereinbarten Zeitpunkt beginnt der Pentest. Üblicherweise scannt der oder die Pentester:in das System zunächst ganz allgemein und sammelt erste Informationen ein. Intelligente automatisierte Tools weisen schon jetzt auf interessante Punkte hin, z. B. auf vergessene Backups, offene Verzeichnisse auf Webservern etc.
Moderne KI-Tools können diese Automatisierung auf ein noch höheres Level heben. Hierzu empfehle ich die Idee meines Kollegen Sergej Michel, der mit INVAIDER ein solches Tool geschaffen hat.
All dies kann der/die Pentester:in dann bewerten und entscheiden, welche davon er/sie genauer untersuchen möchte.
Neben diesen offensichtlichen Dingen existieren zudem Checklisten mit Punkten, welche der oder die Pentester:in zu prüfen hat. Das können offizielle Checklisten sein, z. B. die vom BSI oder auch vom OWASP, aber auch eigene Erfahrungswerte des oder der Pentester:in sowie Punkte, die der Kunde von sich aus vorgibt.
Sind diese Punkte abgehakt, wird der oder die Pentester:in das System individueller begutachten. Dies ist der Moment, wo sich ihre oder seine Erfahrung besonders bemerkbar macht: Viele Pentestende haben ihre eigenen Schwerpunkte, sollten darüber hinaus aber unbedingt ein breites Spektrum an Angriffstechniken kennen und selbst beherrschen.
Finden sie tatsächlich eine akute, kritische Lücke im System, wenden sie sich umgehend an den Auftraggeber und das Entwicklungsteam, damit die Lücke schnellstmöglich geschlossen werden kann. In einem solchen Fall sollte dann selbstverständlich auch nach Spuren gesucht werden, um festzustellen, ob diese Lücke bereits ausgenutzt wurde.
Schritt 4: Auswertung
Der oder die Pentester:in übergibt eine Liste mit allen gefundenen Schwachstellen (Findings) an das Team, inklusive Risikobewertung. Keine Panik: Diese Liste kann durchaus lang sein, auch wenn keine gravierenden Schwachstellen zu finden waren. Findings, deren Risiko als „low“ eingestuft wurde, sind eher als Hinweis zu verstehen: „Liebe:r Entwickler:in, schau dir diese Stelle noch mal genau an, sie könnte möglicherweise zur Gefahr werden“.
Ein Beispiel: Eine Anwendung nutzt fortlaufende Datenbankschlüssel und gibt diese an den Browser weiter. Angreifer können dies einfach erkennen und ggf. Datenbankschlüssel von fremden Daten erraten. Das ist an sich noch kein Problem. Findet der Angreifer jedoch eine Rechteprüfung, die nicht sauber arbeitet oder die schlicht vergessen wurde, kann er auf Informationen zugreifen, auf die er keinen Zugriff haben sollte. Das hört sich theoretisch an, es gibt aber zahllose reale Fälle auch von großen Softwareherstellern.
Es kann übrigens auch vorkommen, dass Schwachstellen gefunden werden, die außerhalb des vereinbarten Scopes liegen. Auch diese sollten dokumentiert werden, dann aber als out-of-scope markiert sein, damit sie gleich an die verantwortliche Stelle weitergeleitet werden können.
Wichtig ist auch eine gute Strukturierung der Findings: Jedes Finding sollte eine eindeutige Nummer tragen und einzeln aufgelistet sein. Nur dann lässt sich darüber kommunizieren und sicherstellen, dass die Findings im Anschluss behoben wurden.
Schritt 5: Nachgespräch
Ein Nachgespräch sollte zumindest angeboten werden. Hierbei werden die Findings besprochen und erläutert. Es können natürlich auch Rück- und Verständnisfragen gestellt werden. Auch das Nachgespräch gehört meiner Meinung nach zu einem professionellen Pentest dazu.
Schritt 6: Nachtest
Sind die Findings behoben, sollte ein Nachtest erfolgen. Um sicherzustellen, dass die Schwachstellen tatsächlich behoben wurden. Denn was nutzt eine Prüfung, deren Ergebnisse nicht interessieren und aus der man folglich nichts lernen wird.
Fazit
Ein Pentest ist eine gute und wichtige Sache. Er gibt letzte Sicherheit, dass die getroffenen Security-Maßnahmen im Softwarecode greifen und auch miteinander funktionieren. Er ist also eine Art letzte Instanz, die zwischen uns Entwickler:innen und der gefährlichen Welt da draußen steht. Wenn er gut durchgeführt wird, legt er alle Schwachstellen unserer Software offen, die wir im Tagesgeschäft durchaus mal übersehen können.
Das gute Zusammenspiel zwischen Pentester:innen und Entwickler:innen ist dabei übrigens kein Nice-to-have, sondern absolut erfolgsentscheidend, wenn die Software am Ende höchsten Ansprüchen genügen soll. Und bei Micromata soll sie das definitiv!
