Coders Conquer Security Infrastructure as Code Serie: Deaktivierte Sicherheitsfunktionen

Cyber-Bedrohungen sind heutzutage allgegenwärtig und unerbittlich. Da immer mehr Bereiche unseres Lebens digitalisiert werden, steigt auch das Risiko für Cyberkriminelle – es gibt zu viel Code, der abgesichert werden muss, und private Daten sind einfach zu wertvoll. Zudem ist es nach der Bereitstellung von Programmen nahezu unmöglich geworden, mit der gesamten Angriffsfläche Schritt zu halten und diese vollständig zu schützen.

Es gibt Ansätze, um einige dieser Probleme zu lindern. Einer davon zeigt sich, wenn vorausschauende Unternehmen das Konzept „Infrastructure as Code“ (IaC) konsequent umsetzen. Natürlich gibt es, wie bei jeder Entwicklung, auch hier Sicherheitsrisiken, die man kennen muss. Da Entwickler den Code schreiben, der die kritische Infrastruktur für Anwendungen bereitstellt, ist ein ausgeprägtes Sicherheitsbewusstsein in jeder Phase des Prozesses unerlässlich.

Wie also kann sich ein Entwickler, der neu in einer Cloud-Server-Umgebung ist, weiterbilden, die Grundlagen erlernen und den Aufbau mit einem geschärften Sicherheitsbewusstsein angehen?Wir haben die nächste „Coders Conquer Security“-Serie ins Leben gerufen, um gängige IaC-Schwachstellen anzugehen, und die kommenden Blogbeiträge konzentrieren sich auf Schritte, die Sie als Entwickler unternehmen können, um sichere Infrastructure as Code in Ihrem eigenen Unternehmen bereitzustellen.

Fangen wir an.

Es gibt eine Fabel aus dem Wilden Westen über einen Mann, der panische Angst vor Banditen hatte, die sein Gehöft überfallen könnten. Um sich zu schützen, investierte er in alle möglichen Sicherheitsmaßnahmen: Er installierte eine extra starke Eingangstür, vernagelte alle Fenster und hielt zahlreiche Waffen griffbereit. Eines Nachts wurde er trotzdem ausgeraubt, während er schlief – weil er vergessen hatte, die Seitentür abzuschließen. Die Banditen fanden einfach die ungesicherte Stelle und nutzten die Situation sofort aus.

Deaktivierte Sicherheitsfunktionen in Ihrer Infrastruktur sind genau das. Selbst wenn Ihr Netzwerk über eine robuste Sicherheitsarchitektur verfügt, nützt diese wenig, wenn einzelne Elemente deaktiviert wurden.

Bevor wir tiefer einsteigen, eine kleine Herausforderung für Sie:

Besuchen Sie den obigen Link, um zu unserer spielerischen Trainingsplattform zu gelangen, auf der Sie versuchen können, eine Schwachstelle durch deaktivierte Sicherheitsfunktionen direkt zu beheben. (Hinweis: Es öffnet sich in Kubernetes, aber über das Dropdown-Menü können Sie zwischen Docker, CloudFormation, Terraform und Ansible wählen).

Wie haben Sie sich geschlagen? Falls Sie noch etwas Übung brauchen, lesen Sie einfach weiter:

Sicherheitsfunktionen können aus verschiedenen Gründen deaktiviert sein. Bei manchen Anwendungen und Frameworks sind sie standardmäßig ausgeschaltet und müssen erst aktiviert werden, um zu funktionieren. Es kommt auch vor, dass Administratoren bestimmte Sicherheitsfunktionen deaktivieren, um Aufgaben einfacher erledigen zu können, ohne ständig durch Sicherheitsabfragen oder Blockaden gestört zu werden (z. B. wenn ein AWS S3-Bucket öffentlich gemacht wird). Nach Abschluss der Arbeit vergessen sie dann möglicherweise, diese Funktionen wieder zu aktivieren. Manchmal lassen sie diese auch bewusst ausgeschaltet, um sich die Arbeit in Zukunft zu erleichtern.

Warum deaktivierte Sicherheitsfunktionen so gefährlich sind

Deaktivierte Sicherheitsfunktionen sind aus mehreren Gründen problematisch. Zum einen wurden diese Funktionen in die Infrastrukturressourcen integriert, um vor bekannten Exploits, Bedrohungen oder Schwachstellen zu schützen. Wenn sie deaktiviert sind, können sie Ihre Ressourcen nicht mehr absichern.

Angreifer suchen immer zuerst nach leicht ausnutzbaren Schwachstellen und verwenden dafür oft Skripte, die gängige Sicherheitslücken systematisch abprüfen. Das ist vergleichbar mit einem Dieb, der in einer Straße alle Autos auf unverschlossene Türen prüft – das ist schließlich viel einfacher, als eine Scheibe einzuschlagen. Hacker sind vielleicht überrascht, wenn sie feststellen, dass eine gängige Sicherheitsmaßnahme inaktiv ist. Aber wenn das passiert, dauert es nicht lange, bis sie diese Lücke ausnutzen.

Zweitens erzeugt eine vorhandene, aber deaktivierte Sicherheitsfunktion ein falsches Gefühl von Sicherheit. Administratoren könnten glauben, sie seien vor gängigen Bedrohungen geschützt, ohne zu wissen, dass jemand diese Schutzmechanismen außer Kraft gesetzt hat.

Ein Beispiel dafür, wie ein Angreifer eine deaktivierte Sicherheitsfunktion ausnutzen kann, ist die AWS S3-Funktion „Block Public Access“. Mit dieser Funktion können Kontoadministratoren und Bucket-Besitzer zentral steuern, um den öffentlichen Zugriff auf ihre Amazon S3-Ressourcen zu beschränken. Wenn Administratoren jedoch beim Zugriff auf den S3-Bucket auf Probleme stoßen, entscheiden sie sich manchmal dazu, ihn öffentlich zu machen, um die Aufgabe schnell zu erledigen. Wenn sie dann vergessen, die Sicherheitsfunktion wieder zu aktivieren, hat ein Angreifer vollen Zugriff auf die im S3-Bucket gespeicherten Informationen. Dies führt nicht nur zur Offenlegung von Daten, sondern verursacht durch Datentransfergebühren auch zusätzliche Kosten.

Vergleichen wir das mit echtem Code; sehen Sie sich diese CloudFormation-Snippets an:

Anfällig:

CorporateBucket:
   Type: AWS::S3::Bucket
   Properties:
     PublicAccessBlockConfiguration:
       BlockPublicAcls: false
       BlockPublicPolicy: false
       IgnorePublicAcls: false
       RestrictPublicBuckets: false
     VersioningConfiguration:
       Status: Enabled
     BucketEncryption:
       ServerSideEncryptionConfiguration:
         - ServerSideEncryptionByDefault:
             SSEAlgorithm: "AES256"

Sicher:

CorporateBucket:
   Type: AWS::S3::Bucket
   Properties:
     PublicAccessBlockConfiguration:
       BlockPublicAcls: true
       BlockPublicPolicy: true
     IgnorePublicAcls: true
       RestrictPublicBuckets: true
     VersioningConfiguration:
       Status: Enabled
     BucketEncryption:
       ServerSideEncryptionConfiguration:
         - ServerSideEncryptionByDefault:
             SSEAlgorithm: "AES256"

Deaktivierte Sicherheitsfunktionen verhindern

Um zu verhindern, dass deaktivierte Sicherheitsfunktionen Ihrem Unternehmen schaden, bedarf es sowohl klarer Richtlinien als auch entsprechender Praktiken. Es sollte eine feste Vorgabe existieren, dass Sicherheitsfunktionen nur unter ganz bestimmten Umständen deaktiviert werden dürfen. Vorfälle, bei denen Funktionen zur Fehlerbehebung oder für Anwendungsupdates vorübergehend abgeschaltet werden müssen, sind zu protokollieren. Nach Abschluss der Arbeiten muss sichergestellt werden, dass alle Funktionen wieder vollständig aktiviert wurden.

Muss eine Sicherheitsfunktion zur Optimierung der Betriebsabläufe dauerhaft deaktiviert werden, sind alternative Schutzmaßnahmen für die betroffenen Daten zu implementieren. So wird sichergestellt, dass Angreifer trotz fehlender Standardschutzmechanismen keinen Zugriff erhalten. Wenn eine notwendige Sicherheitsfunktion fehlt, ist es nur eine Frage der Zeit, bis ein Angreifer diese offene Tür findet und ausnutzt.

Mehr erfahren und Herausforderungen meistern:

Besuchen Sie die Secure Code Warrior Blogseiten für weitere Einblicke in diese Schwachstelle und erfahren Sie, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken schützen können.

Bereit, diese Schwachstelle nach dem Lesen des Beitrags zu finden und zu beheben? Probieren Sie eine spielerische IaC-Sicherheits-Challenge auf der Secure Code Warrior-Plattform aus, um Ihre Cybersecurity-Fähigkeiten stets auf dem neuesten Stand zu halten.

Dies ist eine wöchentliche Serie über unsere acht wichtigsten Infrastructure-as-Code-Schwachstellen; schauen Sie nächste Woche wieder vorbei!