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 Standardwerkzeugen | Prüfungen mit Standard EBICS-Clientsoftware | Prüfungen mit secuvera Pentest-Adapter | |||
| In die Prüfung investierter Aufwand | normal | normal | moderat | sehr hoch | moderat |
| Mit dem Aufwand erreichte Prüftiefe | gering | gering | mittel | mittel+ | 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.