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.