Security Audit Cryptopus 2020

Im Frühling 2020 wurde der bei Puzzle intern entwickelte Open Source Passwortmanager Cryptopus einem Security Audit unterzogen. Der Security Audit wurde von Melchior Limacher von der externen Penetration Testing Firma Limacher Informationssicherheit GmbH durchgeführt.

In diesem Artikel zeigen wir auf, weshalb ein Security Audit für uns wichtig war und wie wir maximal davon profitieren können.

Was prüft ein Security Audit?

Ein Security Audit kann ganz unterschiedliche Aspekte einer Software, einer Webapplikation, eines „Systems“ inkl. beispielsweise Netzwerk oder gar einer Firma prüfen. Der Umfang und die Ziele sind zu Beginn des Audits mit dem/der AuditorIn zu definieren.

Warum ein Security Audit?

Grundsätzlich sollte die IT Security von Anfang in einem Projekt involviert sein und in jedem Schritt des Software Development Lifecycles bereits Security Massnahmen angewendet werden.
Trotzdem kann es Sinn machen, das umgesetzte Projekt von einem/einer Security SpezialistIn oder Penetration Tester überprüfen zu lassen.
Ein Security Audit kann bisher unbekannte Schwachstellen identifizieren und Implementations- und Konfigurationsfehler aufdecken. Diese Prüfung erhöht die Sicherheit weiter.

Gute Noten für Cryptopus!

Auch wenn wir uns bewusst sind, dass ein Security Audit nicht 100% der Schwachstellen finden kann, freuen wir uns sehr darüber, dass Cryptopus gut abgeschlossen hat.
Rund um die Autorisierung wurden trotz intensiven Penetrationtests und Code-Reviews keine Schwachstellen gefunden. Auch das Verschlüsselungskonzept wurde verifiziert und als solide eingestuft.
Bei all unseren Rails-Projekten berücksichtigen wir die ausführlichen Security Guidelines des Frameworks. Ausserdem haben wir speziell rund um die Authentifizierung intensiv mit Unit- und Controllertests getestet. Beide Massnahmen haben sicher massgeblich dazu beigetragen, die Applikation so sicher zu machen.

Nach dem Security Audit

Mit einem Report hat man noch nichts gewonnen. Es ist wichtig, dass die Schwachstellen behoben werden! Ein internes Tracking und Zuweisen der Schwachstellen an deine verantwortliche Person unterstützt die Schliessung der gefundenen Schwachstellen.

Weiter wollten wir aus dem erhaltenen Report den grösstmöglichen Nutzen ziehen. Möglicherweise kommen die gefundene Schwachstellen auch in anderen Applikationen vor.
Wir haben also den Report genutzt, um generelle Verbesserungen an der Sicherheit der Puzzle Infrastruktur vorzunehmen, um Secure Coding Guidelines zu überprüfen und um weitere Projekte auf die Schwachstellen zu sensibilisieren.

Generelle Empfehlungen könnten beispielsweise lauten :

  • Durchgängige TLS Encryption ist aktiviert. Sicher gegen aussen, aber auch zu Um- und Backendsystemen. Nur TLS 1.2 und TLS 1.3 verwenden.
  • Sichere Session Cookies: Secure Flag, HtmlOnlyFlag, SameSite=StrictFlag, __Host-Prefix.
    • Weitere Infos siehe hier
  • Security Headers setzen
  • Alle Input Möglichkeiten müssen Input Validation aufweisen
  • Jede Anzeige auf dem Bildschirm muss vorher Output Encoded werden.
  • Kein Default Account mit Default Passwort (besonders nicht Admin!)
  • Admin Zugang muss besonders geschützt sein: MFA oder/und IP Whitelist
  • Keine hardcoded default Secrets
  • Keine Plaintext Secrets im GitHub/GitLab (Vorsicht: History).
  • File Uploads prüfen
  • Lange (>=12) und komplexe Passwörter enforcen
  • Security Vorgaben des eingesetzten Frameworks befolgen.

–> Achtung dies ist keine abschliessende Liste und kann ergänzt werden.

Als zusätzliche Sicherheitsschicht vor der Applikation kann ausserdem die Web Application Firewall ModSecurity mit dem OWASP ModSecurity Core Rule Set eingesetzt werden. Sie filtert bereits einen grossen Teil der Web Attacken.

Links und Referenzen

Kommentare sind geschlossen.