schule@synyx – security testing

(Fast) jeden Freitag treffen sich interessierte synyxer in der Schule@synyx, um sich gegenseitig etwas Neues beizubringen.

In verschiedenen Formaten (Vortrag, Workshop, Diskussion, …) möchten wir Wissen verteilen und unsere Erkenntnisse mit den Kollegen challengen. Hier macht es keinen Unterschied, ob der Inhalt aus der aktuellen Arbeit beim Kunden, einem R&D-Projekt oder einer Spielerei entstanden ist.

(Mein Kollege Arnold hat die Schule@synyx hier schonmal ausführlicher erklärt)

Ich habe zuletzt über das Thema “Security Testing in Continuous Integration” berichtet, das ich aktuell vertiefe und über das ich dieses Jahr auf Meetups und Konferenzen spreche.

Security Testing in Continuous Integration

Die meisten aktuell genutzten Programmiersprachen bieten komplexe Frameworks an, mit deren Hilfe man leicht bestehende Bibliotheken von Dritten einbinden kann, um sich viel Aufwand bei der Implementierung einer Lösung zu sparen. Leider besteht hier die Chance, dass diese Bibliotheken Sicherheitslücken mit sich bringen, über die man aber schnell den Überblick verliert. Da in den meisten Softwareprojekten sowieso schon Continuous Integration benutzt wird, um die bekannten Arbeitsschritte wie Tests, Packaging, Release, Deployments und Integrationstests ohne händischen Aufwand der Entwickler abzuwickeln, bietet es sich an, Tool-gestützte Sicherheitstests in die bestehenden CI-Jobs einzubinden. Für diverse Sicherheitstests stehen Open-Source-Projekte zur Verfügung.

Nach einer grundlegenden Einführung zu Sicherheit in Softwareprojekten und -betrieb, zur Klassifizierung von Sicherheitslücken in CVE, CPE und co, wurde anhand eines Java-Projekts auf Basis von SpringBoot und Maven (Link) demonstriert, wie man Schwachstellen in Dependencies mit Hilfe von OWASP Dependency-Check erkennen kann, ohne viel Ahnung von IT-Sicherheit zu haben.

Weiterhin wurde auf Basis eines bereitgestellten Docker-Images (Dockerfile im o.g. github-repo) gezeigt, dass auch im Betrieb leider viel schiefgehen kann, wenn man auf veraltete oder unbekannte Docker-Container setzt. Zum Scannen nach bekannten Schwachstellen in Containern empfiehlt sich der Einsatz von CoreOS Clair.

Wenn man die Software dann gebaut und deployed hat, empfiehlt es sich (insofern die Applikation eine API oder Webseite anbietet), auch die angebotenen (HTTP-)Endpunkte zu scannen. An dieser Stelle wird keine statische Prüfung über den Code oder die installierten Pakete ausgeführt, sondern tatsächlich dynamisch ein Webservice oder eine API angegriffen. Mit dem OWASP ZAProxy lassen sich hier Links erkennen (spidern), danach wird versucht, diese Links, Formulare und weitere dynamische Elemente über Query-Parameter, Formulardaten und Schadcode anzugreifen (natürlich nur eigene Systeme).

All diese Tools lassen sich mit 2-3 Shell-Befehlen ausführen und sind daher super geeignet, um bestehende CI/CD-Pipelines zu ergänzen. Alle erlauben das Whitelisting von bestimmten Schwachstellen, so dass man sich wirklich auf neue Schwachstellen konzentrieren kann, um diese schnell (je nach Priorität) zu beheben oder Updates auszuführen.

Im Anschluss an die Präsentation und Demo haben einige Teilnehmer noch diskutiert, wie man nun mit den gefundenen Schwachstellen umgehen sollte, sowohl technisch als auch im Prozess der Weiterentwicklung, z.B. wer den Fix priorisiert und ausführt.

Die Folien findet man hier, ein ausführlicher Artikel zu diesem Thema ist in Arbeit.