Rechnungen im ZUGFeRD-Format - ein Sicherheitsrisiko !!!

[Gast]

Hallo an alle Interessierten!

Von meiner Softwarefirma habe ich folgende Auskünfte erhalten:

Kontonummern-Check:

1. Beim Einlesen einer Rechnung im ZUGFeRD-Format prüft die Software die Übereinstimmung der Rechnungsdaten mit den im Buchhaltungssytem vorhandenen LieferantenStammdaten, eine abweichende Kontonummer führt zum Abbruch des Überweistungs-Automatismus!

2. Das funktioniert natürlich nicht bei "Direktzahlungen", wenn also für einen einzelnen Lieferanten kein Personenkonto angelegt ist.

3. Ab Oktober wird meine Hausbank bei jeder Überweisung vollautomatisch (für Privatpersonen nicht abwählbar ! ) eine Überprüfung des Empfängers durchführen, also Empfängername und IBAN miteinander abgleichen - wenn was nicht übereinstimmt, wird dies vor Ausführung der Überweisung angezeigt!

==> also eine "gefälschte" Kontonummer oder ein Tippfehler sollte dann eigentlich nicht mehr durchgehen!

Bruttobetragscheck:

1. Meine Software prüft nicht (!), ob der Bruttorechnungsbetrag im pdf mit dem in der xml-Komponente übereinstimmt!

2. Nachdem ich meine Softwarefirma auf diese Problematik "als Verbesserungsvorschlag" hingewiesen habe - wäre doch für eine Software einfach, das zu tun - kam leider zumindest bis heute keine Rückmeldung mehr - hoffen wir mal, dass die Programmierer schon an einer Lösung tüfteln ... !?

3. Es gibt schon eine technische Lösung, wenn der Auftraggeber die Bestellung elektronisch ausführt: Dann kann die Software die Bestelldaten mit den Daten in der xml abgleichen.

==> also noch verbesserungsfähig!

[Berliner Bär]

Das Thema ist berechtigt und wird in der Praxis noch viel zu wenig beachtet.

Das Kernproblem: PDF und XML sind zwei unabhängige Welten

Bei ZUGFeRD/Factur-X existieren PDF und XML technisch nebeneinander, ohne erzwungene Konsistenz. Was der Mensch im PDF sieht und was Software aus dem XML liest, muss nicht übereinstimmen. Das lässt sich mit jedem PDF-Editor in Minuten herstellen – und genau das machen sich Angreifer zunutze, die Rechnungen per E-Mail abfangen und manipulieren.

Gefahr für Unternehmen – gerade bei KMU

In kleineren und mittleren Unternehmen läuft es typischerweise so: Ein Sachbearbeiter oder Projektleiter prüft die Rechnung visuell anhand des PDFs – Betrag plausibel, Lieferant bekannt, Leistung erbracht – und gibt frei. Die Buchhaltung übernimmt die freigegebene Rechnung dann in DATEV, lexoffice, sevDesk oder BuchhaltungsButler. All diese Systeme lesen die Buchungsdaten aus der XML-Schicht: IBAN, Betrag, Steuersatz, Fälligkeitsdatum.

Wenn ein Angreifer nur die IBAN im XML geändert hat, das PDF aber unverändert ließ, merkt das niemand: Die Person, die freigegeben hat, hat das PDF gesehen – dort war alles korrekt. Die Person, die bucht, verlässt sich auf die Freigabe und die Software. Der Betrag stimmt, der Lieferant stimmt, nur das Geld landet auf einem fremden Konto. Bei hohem Rechnungsvolumen fällt so etwas erst auf, wenn der echte Lieferant mahnt.

Das BMF hat im Oktober 2024 klargestellt, dass für die steuerliche Anerkennung einer ZUGFeRD-Rechnung ausschließlich die XML-Daten maßgeblich sind. Das PDF ist rechtlich nur eine Visualisierungshilfe. Umso wichtiger, dass die XML-Daten vor der Verarbeitung geprüft werden.

Gefahr für Privatanwender – anders als man denkt

Bei mobilen Banking-Apps (Sparkasse Fotoüberweisung, VR-Banking etc.) ist das Risiko geringer, als es zunächst scheint. Diese Apps nutzen OCR und lesen aus dem visuellen PDF – also aus derselben Quelle, die auch der Mensch sieht. Wenn dort der Betrag manipuliert wäre, würde es auffallen: Wer etwas für 100 € bestellt hat, stutzt, wenn auf der Rechnung 200 € steht.

Die eigentliche Gefahr für Privatanwender liegt woanders: bei Desktop-Banking-Software wie Hibiscus, StarMoney oder SFirm. Wer eine Factur-X-Rechnung per Drag & Drop importiert, bekommt die Überweisungsdaten direkt aus dem XML vorausgefüllt – IBAN, Betrag, Verwendungszweck. Und hier wird es tückisch: Das Angriffsziel ist typischerweise nicht der Betrag, sondern die IBAN. Das PDF zeigt die korrekte Rechnung des echten Lieferanten, der Betrag stimmt, alles sieht plausibel aus. Aber im XML steckt die IBAN des Angreifers. Kaum jemand gleicht die IBAN einer Überweisung manuell mit dem PDF ab – wozu auch, die Software hat die Daten ja "aus der Rechnung" übernommen.

Das Perfide: Am Kontoauszug fällt es nicht einmal sofort auf, weil der Betrag korrekt ist. Erst wenn der Lieferant nach Wochen eine Zahlungserinnerung schickt, wird klar, dass das Geld an ein fremdes Konto ging.

Was hilft?

• Digitale Signaturen (XAdES/CAdES) könnten das Problem an der Wurzel lösen, sind im ZUGFeRD-Standard aber optional und werden kaum eingesetzt
• Das Forum elektronische Rechnung (FeRD) empfiehlt Empfängern, eigene Prüfmechanismen für die Konsistenz beider Rechnungsdarstellungen einzusetzen – aber keine der gängigen Buchhaltungs- oder Banking-Lösungen bietet das bisher als eingebaute Funktion
• Konkret heißt das: Vor jeder Freigabe oder Zahlung sollten PDF-Inhalt und XML-Daten feldweise verglichen werden – insbesondere IBAN und Bankverbindung

Unter Werbelink entfernt kann man eine Factur-X-Datei hochladen und bekommt PDF- und XML-Schicht feldweise gegenübergestellt. Damit lässt sich schnell erkennen, ob die IBAN im XML mit der im PDF übereinstimmt – oder ob jemand nachgeholfen hat.

Die Grundkritik des Threaderstellers teile ich: Ein Format, das Automatisierung verspricht, aber die Integritätsprüfung dem Empfänger überlässt, hat ein strukturelles Sicherheitsproblem. Dass mittlerweile auch das BSI im Rahmen einer Coordinated Vulnerability Disclosure mit dem Thema befasst ist (Meldung von Prof. Eggendorfer, Februar 2025), zeigt, dass das Problem ernst genommen wird – wenn auch spät.

[mhanft]

Den E-Rechnungs-Inhalt kann man auch direkt auf ELSTER anschauen, https://www.elster.de/eportal/e-rechnung

[Berliner Bär]

Den E-Rechnungs-Inhalt kann man auch direkt auf ELSTER anschauen, https://www.elster.de/eportal/e-rechnung

Ja, da gibt es jede Menge Tools für die lesbare Darstellung des XML-Inhalts - nur hilft das bei den Problemen, die ich hier beschrieben habe, so rein garnicht.

[mhanft]

Naja, wenn der Buchhalter den Inhalt der E-Rechnung anschaut, sieht er ja, dass was anderes als im PDF drinsteht, und kann die Zahlung stoppen bzw. gar nicht erst buchen.

Und (Banking-)Software für Privatanwender muss halt künftig auch den Inhalt der E-Rechnung anzeigen - ich denke, im Laufe der nächsten Jahre wird das unweigerlich kommen...

Falls Privatanwender überhaupt eine E-Rechnung kriegen - gesetzlich vorgeschrieben sind E-Rechnungen ja eh nur im B2B-Bereich (und ja, die E-Rechnungs-Erzeugung ist für Firmen durchaus ein gewisser Aufwand, so dass ich mir schon vorstellen könnte, dass z.B. die Telekom an ihre Millionen Privatkunden gar keine E-Rechnung verschickt). Also stellt sich hier das Problem möglicherweise erst gar nicht.

Mal schauen, wie sich das im "Real Life" entwickelt...