Secrets Exposure – die Gefahr lauert überall

Unternehmen konzentrieren sich bei der Bekämpfung der Secrets Exposure auf die Repositories ihrer Anwendungen und ihre CI/CD-Pipelines. Doch die Gefahr lauert auch an anderen Stellen, denn die offengelegten Secrets müssen nicht im Quellcode versteckt sein.

Bei der Anwendungsentwicklung geht es nicht ohne sogenannte Secrets. Neben herkömmlichen Zugangsdaten wie Passwörtern und Benutzernamen für Datenbanken gibt es sie auch in Form von API-Keys, Zertifikaten, Tokens, IDs oder URLs.

In der Praxis schleichen sie sich aus Bequemlichkeit in den Quellcode einer Applikation ein, weil Entwickler ihr den Zugang etwa zu einer Datenbank oder einem Cloud-Service ohne komplizierte Sicherheitsmaßnahmen geben möchten. Vergessen sie dann, diese sensiblen Informationen beim Einchecken in das Live-Repository wieder aus dem Quellcode zu entfernen, ist die Secrets Exposure perfekt.

Ähnliche Szenarien sind über die gesamte CI/CD-Pipeline möglich – vom Source Code Management über Build- und Testing-Umgebungen bis hin zum Deployment. Doch Secrets Exposure droht auch weit jenseits von Code-Repositories, wie die folgenden drei Szenarien zeigen:

• Risikovorfall #1: AWS-Zugangsdaten in Slack; als das Cybersecurity-Team eines Fintech-Startups entdeckte, dass Hacker die Cloud-Umgebung des Unternehmens kompromittiert hatten, gingen sie sofort auf die Suche nach der Ursache. Die fanden sie allerdings nicht im Quellcode einer Anwendung, sondern in der Kommunikationsplattform Slack: Ein Entwickler hatte die Zugangsdaten zu AWS in einem privaten Channel gepostet. Dieser hatte unglücklicherweise eine Webhook-Integration, die Nachrichten über einen externen Service protokollierte. So kam es, dass dieses Secret auch für unbefugte Dritte offengelegt wurde.
• Risikovorfall #2: Hartkodierte Secrets in Jira; das Engineering-Team eines SaaS-Unternehmens nutzte Jira zum Tracking von Bugs und Problemen in der IT-Infrastruktur. Bei der Bearbeitung eines Incident hängte ein Entwickler eine Konfigurationsdatei an ein Ticket. An sich nichts Ungewöhnliches, sie enthielt allerdings einen sogenannten Database Connecting String – eine Zeichenkette mit sensiblen Zugangsdaten für die Verbindung der Anwendung zur Datenbank. Da Jira solche Dateien sehr lange vorhält und praktisch jeder im Unternehmen Zugriff auf das Ticketsystem hatte, lagen diese sensiblen Informationen monatelang offen. Die Konfigurationsdatei wurde erst bei einer standardmäßigen Sicherheitsübung entdeckt.
• Risikovorfall #3: API-Keys in Microsoft Teams; ein Anbieter von Enterprise-Software integrierte Microsoft Teams mit verschiedenen DevOps-Tools, um automatisierte Benachrichtigungen über Deployments zu erhalten. Die Entwickler des Unternehmens posteten gelegentlich API-Keys in Teams-Nachrichten, um fehlerhafte Builds zu analysieren. Da Microsoft Teams Logs von Nachrichten unbegrenzt speichert und keine native Scanning-Funktion zum Auffinden von Secrets beinhaltet, lagen diese Zugangsdaten de facto im Klartext ab und waren für jeden mit Zugriff auf die Chat-Historie frei verfügbar.

Holistische Secrets Detection ist ein Muss

Diese Fälle von Secrets Exposure zeigen, dass Unternehmen, die Anwendungen entwickeln, unbedingt elaborierte Secrets-Scanner benötigen. Eine ganzheitliche Application Security Platform (ASP) durchsucht nicht nur den Quellcode oder die unterschiedlichen Tools einer CI/CD-Pipeline nach möglichen Exposures, sondern findet Secrets zuverlässig in sämtlichen Bereichen eines Unternehmens.

Gute Plattformen bieten KI-basierte Secrets Scanner, die nicht nur nach regelbasierten Methoden arbeiten oder via reguläre Ausdrücke (RegEx) nach Secrets suchen, sondern speziell auf das Auffinden von Secrets trainiert sind. Das ist insofern wichtig, da RegEx-Muster und regelbasierte Scanner zwar klassische Secrets wie API-Keys oder Tokens erkennen können.

Bei generischen Secrets, die keinen festen Regeln folgen und auch außerhalb eines Quellcodes vorkommen, sind sie allerdings oft wirkungslos oder gar kontraproduktiv. Die Folge sind in vielen Fällen eine hohe Anzahl False Positives, die den Entwicklern und Cybersecurity-Teams Zeit für wertschöpfende Aufgaben stehlen.

Eine ASP mit exzellenter Secrets Detection weitet den Suchbereich über Repositories hinaus auf Non-Code-Tools wie Slack, Microsoft Teams, Jira, Confluence und Co. aus. Sie scannt Nachrichten und Dateien, die Entwickler über diese Tools teilen, in Echtzeit und markiert sie unmittelbar, sodass die Verantwortlichen ohne Zeitverlust handeln können. Überdies gibt eine fortschrittliche ASP zu jeder gefundenen Sicherheitsverletzung einen vollständigen Kontext, inklusive exaktem Speicherort des Secrets, dem Autor und weiteren Metadaten, was den Aufwand zur Behebung der Exposure maßgeblich verkürzt.

Jochen Koehler ist Vice President of Sales EMEA bei Cycode.

Cycode