04/2021 – Fachartikel Swiss Infosec AG
Sichere Softwareentwicklung bei zugleich geringer Time-to-market
Software wird heutzutage in hohem Tempo entwickelt. Neue Features werden hinzugefügt, Benutzerfreundlichkeit, Performance und Sicherheit laufend verbessert. Das hinzugewonnene Tempo ist massgeblich DevOps-Praktiken und Werkzeugen zu verdanken, mit denen Software-Aktualisierungs- und Ausrollzyklen enorm verkürzt werden konnten. Bereits in der DevOps Pipeline ist entwickelte Software jedoch Sicherheitsrisiken ausgesetzt, wie jüngst der SolarWinds-Angriff eindrücklich demonstriert hat[1]. Angreifer waren in der Lage, eine Backdoor in die von SolarWinds entwickelte Software Orion einzuschleusen, womit sie Zugriff zu Systemen vieler Orion-Kunden erlangten. Abhängig vom betroffenen System kam es zu gravierenden Folgeschritten wie der Etablierung permanenter Zugänge und lateralen Bewegungen innerhalb der Umgebung des betroffenen Kunden.
DevSecOps-Ansatz als Allheilmittel?
Um Bedrohungen bei der Entwicklung von Software zu begegnen, müssen Sicherheitsthemen im DevOps-Zyklus berücksichtigt werden.
Abbildung: DevSecOps Software Lifecycle
Quelle: DoD Enterprise DevSecOps Reference Design, Version 1.0, 12 August 2019
In jeder Phase des abgebildeten DevSecOps Lifecycles sind sicherheitsrelevante Überprüfungen oder Aspekte möglich.
- Plan: Angriffsmöglichkeiten werden identifiziert und das Design der Software entsprechend angepasst.
- Develop: Die Software wird entwickelt. Dabei sind auf Sicherheit sensibilisierte Entwickler, die Best Practices befolgen, entscheidend. Eine IDE (Integrated Development Environment) mit integrierter statischer Codeanalyse gibt Entwicklern ausserdem prompte Feedbacks, z.B. nicht initialisierte Variablen, unbereinigter Input und unbehandelte Exceptions.
- Build: Der Code wird kompiliert. Davor wird er einer weiteren Qualitätsprüfung unterzogen, welche neben oben genannten Überprüfungen auch das Aufspüren von Malware beinhalten kann.
- Test: Neben Unit- und Integrationstests, die die Funktionalität prüfen, lässt sich die Software auch automatisiert auf Schwachstellen prüfen. Es lässt sich ausserdem ein Penetrationstest durchführen, bei dem eine manuellere und tiefere Untersuchung vorgenommen wird.
- Release: Die Software wird paketiert und signiert, um weitere Manipulationen zu verunmöglichen und einen Beweis liefern zu können, dass sie vom Hersteller stammt.
- Deliver: Die Software gelangt auf sicherem Wege zum Kunden.
- Deploy: Die Software wird schrittweise ausgerollt. Üblicherweise zuerst in einer Entwicklungs-, dann eine Test- und schlussendlich eine produktive Umgebung. In vorproduktiven Umgebungen kann die Software auf Anomalien und Malware untersucht werden. Beim Überführen in die produktive Umgebung müssen die Software und umliegende Komponenten sicher konfiguriert werden. Da heutzutage Infrastruktur als Code formuliert ist, z.B. als AWS CloudFormation Templates, Kubernetes Manifests, etc., lassen sich solche Konfigurationen zu einem grossen Teil statisch und automatisiert testen.
- Operate: Im Betrieb kann ein umfassender Audit durchgeführt werden, der die Software im Kontext der Umgebung überprüft und dabei auch nicht technische Aspekte wie Organisation, Prozesse, Richtlinien sowie Dokumentationen untersucht.
- Monitor: Logfiles der Software und der Umgebung werden laufend gesammelt und ausgewertet.
- Feedback: Aufgrund der Beobachtungen, möglicherweise auch aufgrund von tatsächlichen Angriffen, werden Schwachstellen in der Software identifiziert und fliessen in eine nächste Plan-Phase ein, woraufhin der ganze Zyklus von vorne beginnt.
Der SolarWinds-Angriff hat allerdings gezeigt, dass selbst alle oben genannten Massnahmen unzureichend sein können.
Was fehlte ist eine sichere Entwicklungsumgebung
Seit FireEye’s Enthüllung[1] am 13. Dezember 2020 haben weitere Untersuchungen[2],[3],[4],[5] bestätigt, dass der Angriff in der Build-Phase geschah.
Abbildung: Grober Ablauf des SolarWinds-Angriffs
Die Angreifer waren in der Lage, eine Backdoor in SolarWinds.Orion.Core.BusinessLayer.dll einzuschleusen, genannt SUNBURST. In der Quelldatei InventoryManager.cs konnten sie insbesondere Code einbetten, der BusinessLayer.dll zur Ausführung brachte. Das Einschleusen dieses Codes geschah automatisiert durch die separate Malware SUNSPOT. SUNSPOT untersuchte laufende Prozesse, um herauszufinden, wann die Orion-Software gerade kompiliert wurde. Sobald dies der Fall war, ersetzte sie InventoryManager.cs durch die modifizierte Version. Diese wurde daraufhin vom regulären Kompilierungsprozess in das finale Produkt eingebaut. SUNBURST war so geschrieben, dass statische und dynamische Code-Analysen die Backdoor nur schwer, wenn überhaupt, erkannt hätten. Der Angriff demonstriert damit eindrücklich, dass Massnahmen wie Secure Coding, SAST & DAST (static/dynamic application security testing), Release Signing und Sandboxing, selbst zusammen, unzureichend sein können. Die Build-Umgebung selbst muss auch ausreichend geschützt sein. Langfristig könnten reproduzierbare Builds eine Lösung darstellen[6]. Diese fördern zudem die Transparenz von Quellcode und ermöglichen es, auch von Herstellern absichtlich eingebaute Backdoors aufzudecken.
[1] https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html
[2] https://www.crowdstrike.com/blog/sunspot-malware-technical-analysis/
[3] https://news.sophos.com/en-us/2020/12/21/how-sunburst-malware-does-defense-evasion/
[4] https://www.microsoft.com/security/blog/2020/12/18/analyzing-solorigate-the-compromised-dll-file-that-started-a-sophisticated-cyberattack-and-how-microsoft-defender-helps-protect/
[5] https://blog.reversinglabs.com/blog/sunburst-the-next-level-of-stealth
[6] https://www.linuxfoundation.org/en/blog/preventing-supply-chain-attacks-like-solarwinds/
Gerne beantworten wir Ihre Fragen und unterstützen Sie bei der Etablierung sicherer Softwareentwicklungsprozesse, als auch bei der Durchführung von Penetrationstests und generellen Security Audits.
Fachteam IT-Sicherheit; 30.03.2021