Details

Geschrieben von Joel Peretz

Kategorie: IT Security

Veröffentlicht: 17. Januar 2024

Zugriffe: 10508

• Technology
• Information
• Cyber
• IT Securtiy

Sicherheitsrelevante Software Tools in kritischen Infrastrukturen

 

Schutz vor Bedrohungen: Die Rolle sicherheitsrelevanter Softwaretools in kritischen Infrastrukturen - Einsatz von neuesten und innovativsten Software-Releases

---

 Theme: Schwachstellen; Exploits

---

Digitalisierung bedeutet, Aufgaben leichter und häufig auf eine bisher nicht mögliche Weise zu erledigen. Dies ist wirtschaftlich und befriedigend. Was früher unmöglich war oder nur mit erheblichem Aufwand und vielen Mitarbeitern bewältigt werden konnte, lässt sich jetzt mit einem Smartphone auslösen. Daten abrufen, Prozesse starten, Einkäufe tätigen und die Kommunikation von praktisch überall aus durchführen und verwalten – das klingt auf den ersten Blick vorteilhaft und verlockend. Dennoch birgt die Digitalisierung erhebliche Gefahren und Nachteile. 

Einerseits entwickelt sich die digitale Welt sehr schnell, insbesondere bei fortgeschrittenen Technologien und Forschungsbereichen wie Künstliche Intelligenz, Robotik, Machine Learning und Cloud Computing. Andererseits nehmen die Herausforderungen in Bezug auf die Integration von sich ständig weiterentwickelnden Technologien zu, und die IT-Fachkräfte weltweit müssen sich rasant weiterentwickeln. Das Management und die Geschäftsführung sind überzeugt, dass der Einsatz dieser Technologien für das Unternehmen von Bedeutung ist oder sein kann. Die Termine können nicht so geplant werden, dass auf die Reife neuer Technologien und Software gewartet wird. Es ist ungewiss, wann sie überhaupt vollständig einsatzbereit sind. 

Außerdem können bösartige Hacker und schädliche Software mittlerweile Schwachstellen ausnutzen, um Schaden anzurichten. Oft wird dabei ein wichtiges Prinzip 'vergessen', eine Art Faustregel, die schwer zu befolgen ist: Niemals die allerneueste Version von irgendetwas einsetzen, sei es Verwaltungssoftware, Entwicklungswerkzeug, Server oder Ähnliches. Es schließt nicht aus, dass es in seltenen Fällen dennoch erforderlich sein kann, etwa wenn ein Fix für einen Treiber benötigt wird oder wenn Software in der Entwicklung nicht downgraded werden kann. Es gibt verschiedene Szenarien, die man sich vorstellen könnte, aber im Allgemeinen weiß man, dass es nicht ratsam ist und daher der Faustregel widerspricht.

 

Gerade bei kritischen Infrastrukturen trägt das Ganze eine immense Bedeutung, man kann sogar sagen, eine noch größere Bedeutung. Es stimmt zwar, dass es keine hundertprozentige Sicherheit gibt, aber nichts dagegen zu unternehmen, wäre fatal. Niemand bestreitet, dass Sicherheit in IT-Systemen unabdingbar ist. Bei älteren Versionen von Softwarekomponenten bedeutet es nicht automatisch, dass keine weiteren Schwachstellen vorhanden sind, auch wenn bereits bekannte Schwachstellen, sogenannte Exploits, entdeckt und gepatcht wurden. 

Es wäre naiv anzunehmen, dass alle Schwachstellen, selbst wenn sie entdeckt wurden, auch kommuniziert wurden – sei es von bösartigen Akteuren oder möglicherweise sogar von Mitarbeitern von Unternehmen, die beauftragt wurden, Schwachstellen zu finden. Natürlich genießen Erstere einen höheren Grad an Glaubwürdigkeit und Vertrauen, aber in allen Lebensbereichen hat sich gezeigt, dass dies allein nicht ausreicht. Das Mindeste, was man tun kann, ist zu vermeiden, was so gut wie sicher ist: dass in brandneuer Software Schwachstellen gefunden werden. Und es ist besser, wenn dies von den wohlwollenden Teilnehmern in der Gesellschaft geschieht.

 

Angriffe und Folgen

Nun, hier kommen wir ins Dilemma. Wenn die IT allgegenwärtig ist, insbesondere in kritischen Infrastrukturen eines Landes und in der Wirtschaft, verspüren viele Interessenten das Bedürfnis, ihren Einfluss geltend zu machen. Ein Land kann sich nicht schutzlos und schwach den Gefahren stellen, und ein Unternehmen ebenso wenig. Doch sowohl ein Land als auch ein Unternehmen verfolgen ihre eigene Politik. Angefangen bei der Bewertung der Sachlage, der Auswertung der Schäden auf der sofortigen, mittel- und langfristigen Zeitskala bis hin zum Wettbewerb und der Positionierung im internationalen und lokalen Markt – welche Auswirkungen kann es haben, wenn der Sicherheitsschutz durchbrochen ist?

Zunächst könnte dies auf Schwachstellen im Management hinweisen. Es würde möglicherweise bedeuten, dass das Management oder Politiker es versäumt haben, sich rechtzeitig auf dem Laufenden zu halten und über Entwicklungen im Bereich oder sogar über die Gefährdungslage informiert zu sein. Zudem wird die Verunsicherung in der Bevölkerung oder bei Konsumenten stark steigen, was zu wirtschaftlichem Vertrauensverlust führen kann. Dies könnte auch einen allgemeinen Vertrauensverlustprozess auslösen, der erhebliche Schwierigkeiten bei der Ausweitung der Digitalisierung und der Einführung schriftlicher Computersysteme, die möglicherweise notwendig und sinnvoll sind, mit sich bringen kann. Was man nicht weiß, führt zu Irritationen. So zu tun, als ob alles in Ordnung ist und die Gefahren nicht so hoch sind, wird auf lange Sicht nicht von Nutzen sein. Schließlich wissen die Angreifer mehr als der durchschnittliche Bürger, und das Problem ist, sie können überall physisch ihren Sitz haben. Ein Angreifer kann in einigen Fällen, wenn auch nicht immer, sogar im Ausland auf einem anderen Kontinent sitzen und nach einer Dusche und einem Abendessen bequem einen Angriff starten. Die Verfolgung von Profis ist sehr erschwert, manchmal sogar unmöglich oder wenig erfolgversprechend.

Wir kommen nun zu den Software-Werkzeugen oder Frameworks, mit denen Programme erstellt werden. Man kann sich das vorstellen wie den Bau einer Tür aus Stahl mit einem sicheren Schloss, das nicht durchbohrt werden kann, auch nicht mit spezieller Ausrüstung. Stellen Sie sich jedoch vor, dass trotz dieser Sicherheitsvorkehrungen ein Fehler gemacht wird, indem man fertige Türen produziert und jedem Kunden zwei Schlüssel aushändigt. Einer für die eigene gekaufte Tür und der andere ein Master-Schlüssel für alle anderen Türen. In der Realität wäre es schwer vorstellbar, dass dies mit physischen Schlüsseln passiert. Was aber, wenn nur ein Schlüssel ausgegeben wird und der andere maschinell im letzten Moment von der Maschine hinzugefügt wird? Nun, das wäre ebenfalls eher unwahrscheinlich.

Jetzt nehmen Sie an, es wurde im Design der Schlüssel ein Fehler gemacht und übersehen, dass die beiden Schlüssel die eigene Tür öffnen, aber wenn man sie fast bis zum Anschlag im Schlosszylinder einführt, öffnen sie jede Tür. Einige Angreifer werden genau so vorgehen: Sie werden mit Phantasie oder basierend auf Erfahrung systematisch und automatisiert alle Möglichkeiten erkunden, die bereits bei anderen Produkten bekannten Fehler sowie ähnliche oder völlig neue Angriffsmethoden. Wenn sie herausfinden, wie sie einen herkömmlichen Schlüssel für die Öffnung einer anderen Tür oder sogar aller Türen verwenden können, ist es Game Over für das System. Je nach den verfügbaren Möglichkeiten, die sie jetzt in der Hand haben, werden die Schäden oder Manipulationen im System entsprechend aussehen.

 

Schwachstellen und Exploits

Bekanntlich gibt es Schwachstellen, die sogenannten Exploits, die gerade erst gefunden und gemeldet wurden. Zero-Day-Exploits sind jene, die gerade erst entdeckt wurden. Stimmt das? Nicht unbedingt. Der Begriff "Zero Day" bedeutet im besten Fall, dass sie gemeldet und bekannt gemacht wurden. Schwachstellen sind oft erst Jahre nach ihrer Entdeckung gemeldet worden. Wenn sie nicht gemeldet werden, bleiben sie vielleicht bis heute unbekannt. Es gibt sogenannte "Bugs Bounty"-Enthusiasten, die nach Fehlern oder Schwächen in der Konstruktion von Software suchen. Wenn sie fündig werden, melden sie es. Und wenn nicht? Es gibt auch Mitarbeiter in Unternehmen, die nach Verfehlungen in Treibern oder API-Schnittstellen suchen. Werden sie es melden, wenn sie fündig werden? Klar, sagen wir, und vielleicht behalten wir es für uns. Kriminelle oder andere mit schlechten Absichten würden, wenn sie etwas finden, jedoch sofort an die Öffentlichkeit gehen und dabei entkommen, oder? Bestimmt nicht.

Wir sehen, dass die Anzahl der Möglichkeiten und der Schwierigkeitsgrad beim Schutz von Systemen sehr unterschiedlich sind. Was ist also die genaue Relevanz zu unserem Thema hier, denn die meisten davon wissen wir bereits seit langem?

 

Wenn Software jeglicher Art auf den Markt kommt oder verbreitet wird, sollte man sich sehr bewusst sein, dass dies genau der gefährlichste Zeitpunkt im gesamten Lebenszyklus des Systems ist. Hier nimmt man etwas Neues in die Hand und installiert es im System. Hier könnte man selbst und eigenhändig dazu beitragen, dass Schäden entstehen. Wenn es von einer zuverlässigen Quelle wie bekannten Unternehmen stammt, sollte man sich darüber informieren, welche Maßnahmen sie ergriffen haben oder ergreifen, um ihre Software abzusichern. Ein Blick in die Vergangenheit des Unternehmens kann nicht schaden. Wenn es aus quelloffener Quelle stammt, könnte man den Quellcode manuell und automatisiert mit Tools durchforsten und nach allem suchen, was auffällig ist.

Auch wenn nichts gefunden wird, bedeutet das bei weitem nicht, dass nichts vorhanden ist. Bei manchen Softwareprodukten wie Frameworks und Werkzeugen tauchen Schwachstellen erst nach Monaten auf. Wenn diese Software nicht zum Beispiel dringende Sicherheitsupdates geliefert hat, sollte man beim Einsatz der allerneuesten Version dieser Software sehr vorsichtig sein.

Informationen zu bereits vorhandenen spezifischen Listen von Exploit-Datenbanken können bereitgestellt werden. Es ist jedoch zu beachten, dass solche Informationen sich schnell ändern können, und es ist wichtig, aktuelle und zuverlässige Quellen zu konsultieren. Sicherheitsfachleute und IT-Experten können regelmäßig aktualisierte Informationen zu Exploits und Schwachstellen von anerkannten Quellen wie dem National Vulnerability Database (NVD), dem Common Vulnerabilities and Exposures (CVE) System, dem Exploit Database (Exploit-DB), dem Metasploit Framework und anderen erhalten. In diesen Datenbanken sollte man je nach dem, wonach man sucht, fündig werden. Falls es bereits Exploits gab, kann man kreativ nach diesen Exploits suchen. Wenn es in der Vergangenheit Probleme im Bereich des Arbeitsspeichers gab, kann man im Arbeitsspeicherbereich suchen, und so weiter.

Natürlich bleibt die Gefahr, dass es etwas ganz Neues gibt, was von Tools, die es nicht kennen, nicht entdeckt werden kann.

 

Hier ein paar Links zu den einigen bekannten Exploits-Datenbanken.

National Vulnerability Database (NVD) https://www.nist.gov/cybersecurity

Common Vulnerabilities and Exposures (CVE) https://cve.mitre.org/

Exploit Database (Exploit-DB)  https://www.exploit-db.com/

Metasploit Framework https://www.metasploit.com/

 

 

Im Folgenden sehen Sie eine Liste bekannter Zero-Day-Exploits. Es ist wichtig zu beachten, dass sie existierten, bevor sie entdeckt wurden. Dies dient lediglich als Anregung zum Nachdenken. Später werden wir auch über Exploits-GAU wie Log4Shell sprechen.

1. Stuxnet (2010): Zielte auf bestimmte Siemens-Industriesteuerungssysteme ab und wurde berühmt wegen seiner Verwendung gegen das iranische Atomprogramm.

2. Heartbleed (2014): Eine schwerwiegende Sicherheitslücke im OpenSSL-Kryptographie-Protokoll, die dazu führte, dass Angreifer vertrauliche Daten aus dem Arbeitsspeicher eines Servers extrahieren konnten.

3. WannaCry (2017): Ein Ransomware-Angriff, der auf eine Schwachstelle im Microsoft Windows-Betriebssystem abzielte und weltweit große Systeme beeinflusste.

4. Meltdown (2018): Eine Sicherheitslücke in modernen Mikroprozessoren, die es Angreifern ermöglichte, auf geschützte Bereiche des Speichers zuzugreifen.

5. SolarWinds (2020): Ein komplexer Cyberangriff, bei dem Angreifer die Softwareversorgungskette von SolarWinds infiltrierten und schädlichen Code in Software-Updates einschleusten, der von zahlreichen Organisationen verwendet wurde.

 

Heute habe ich mich mit neuen Exploits im SNMP-Protokoll beschäftigt, die über ein Python-Skript remote ausgenutzt werden könnten. Dieses Thema liegt jedoch nicht im Fokus des Artikels, den ich behandeln soll. Vielleicht ein anderes Mal.

Bis dahin, das sind die:

CVE-2002-0013: By flooding SNMP with a large number of GetRequest, GetNextRequest, or SetRequest packets, an attacker can use SNMPv1 to initiate a denial of service attack or obtain elevated privileges.

CVE-2002-0012: Attackers can carry out a denial of service attack or obtain elevated privileges by utilizing SNMPv1 trap handling.

---

 Glossar