Ankündigung

Einklappen
Keine Ankündigung bisher.

Rechnungen im ZUGFeRD-Format - Sicherheitsrisiken !!!

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    Rechnungen im ZUGFeRD-Format - Sicherheitsrisiken !!!

    Hallo an alle Interessierten und die Leut, die immer noch der Meinung sind, die Digitalisierung made in germany sei ein Fortschritt ... !

    *****
    Was ist das ZUGFeRD-Format?

    Das ZUGFeRD-Format (Zentraler User Guide des Forums elektronische Rechnung Deutschland) ist ein Standard für elektronische Rechnungen, der
    - sowohl strukturierte maschinenlesbare XML-Daten
    - als auch ein menschenlesbares PDF-Dokument kombiniert.

    Diese hybride Struktur ermöglicht es, Rechnungen
    - sowohl mit menschlichen Augen zu lesen und mit menschlichem Hirn zu verstehen
    - als auch automatisiert mit Software zu verarbeiten, was den Austausch und die Bearbeitung von Rechnungen vereinfacht und beschleunigt.​

    Soweit hört es sich doch ganz gut an - ist aber konzeptionell "ein trojanisches Pferd" !!! ???

    Und daran wurde 10 Jahre lang entwickelt - made in germany wird zur Lachnummer gemacht !!! ???


    *****
    Worin besteht das "vernichtende" Problem?

    Das zentrale Problem, das als "Das trojanische ZUGFeRD" bekannt ist, liegt in der potenziellen Manipulierbarkeit der Rechnungen. Da ZUGFeRD sowohl ein PDF als auch XML-Daten enthält, besteht die Gefahr, dass die beiden Komponenten unterschiedliche Informationen enthalten könnten. So könnte beispielsweise das PDF-Dokument einen anderen Betrag anzeigen als die XML-Daten, die von automatisierten Buchhaltungssystemen verarbeitet werden.

    Dies führt zu einer Vertrauenslücke: Unternehmen, die sich auf die automatisierte Verarbeitung der XML-Daten verlassen, könnten durch fehlerhafte oder manipulierte Informationen Schaden erleiden, ohne dass dies sofort auffällt. Um dieses Risiko zu minimieren, müssen Unternehmen sicherstellen, dass sie sowohl die PDF- als auch die XML-Daten einer Rechnung sorgfältig prüfen und vergleichen.

    Ich bin nur noch "staunend fassunglos" !!!

    Bin ich der Erste, dem dieses Manipulations-Problem aufgefallen ist? Nein, bin ich natürlich nicht!

    *****
    Hier ein Link zu einer vernichtenden Stellungnahme einer Sicherheit***pertin:

    Zitat:
    "... Das Forum elektronische Rechnung Deutschland (FeRD) empfiehlt sogar, "eigene Prüfmechanismen zur Sicherstellung der inhaltlichen Identität der beiden Rechnungen einzuführen". Während ich dachte, wir führen digitale Rechnungen ein, um danach zumindest den Versand und die weitere Bearbeitung (also alles außer der inhaltlichen Prüfung) maschinell und automatisch durchzuführen, ist bei ZUGFeRD wohl eher vorgesehen, dass ein Mensch das PDF manuell mit den maschinell lesbaren Daten in einem glorifizierten XML-Viewer vergleicht. ...

    Hä - wie bitte - ich glaub ich bin im falschen Film: Digitalisierung soll doch für uns Anwender ein Fortschritt sein - jetzt muss ich als Rechnungsempfänger nicht nur die Rechnung prüfen, sondern auch prüfen, ob beide Rechnungsbestandteile xml und pdf identisch sind ... ???

    *****
    Hier ein Link zu einer Besprechung eines Gerichtsurteils über einen Betrugsfall, der auch bei ZUGFeRD-Rechnungen entstehen kann:

    Zitate:
    "Sicherheitsmängel machen XRechnung und ZUGFeRD zum lahmen Gaul
    ...


    (Sachverhalt)


    Urteil des OLG Schleswig: Das hatte einen Fall entschieden, bei dem auf bislang ungeklärte Weise ein Dritter eine per E-Mail verschickte Rechnung so verändert hatte, dass statt der Bankverbindung eines ausführenden Handwerksbetriebs seine eigene erschien. Eine ahnungslose Kundin des Handwerkers überwies den Rechnungsbetrag auf das angegebene (falsche) Konto und wunderte sich, dass der Auftragnehmer später mahnte.

    Das Gericht musste entscheiden, ob der Auftraggeber in diesem Fall erneut zahlen muss oder der Auftragnehmer einfach Pech hatte. Tatsächlich blieb der Handwerker auf seinem Schaden sitzen, denn er hätte die E-Mail mit der Rechnung verschlüsseln müssen. Damit hätte er dem Angriff vorgebeugt, entschied das OLG. Security-Profis wissen: Verschlüsselung hilft da nicht, Signaturen wären die bessere Wahl.

    Doch wie ist es damit eigentlich in der XRechnung bestellt? Gelingt ein solcher Betrug damit vielleicht sogar noch leichter?
    ​...

    Schlimmer geht immer

    Weil die XRechnung für menschliche Nutzer unbequem zu handhaben ist, gibt es in Deutschland ZUGFeRD. Das Akronym steht für „Zentraler User Guide des Forums elektronische Rechnung Deutschland“ und spezifiziert ein PDF, in das die XRechnung eingebettet wird. Damit weiß der Mensch auch ohne Viewer, was in der Rechnung steht, kann alles schön ausdrucken und weiter herkömmlich arbeiten – perfekte Abwärtskompatibilität.

    Doch die Sache hat einen Haken: Zwar generiert der normale Nutzer beide Dokumente in einem, doch sind die angezeigten Daten nicht voneinander abhängig. Im PDF oder im XML-Datensatz lässt sich also etwas ändern, ohne dass der jeweils andere Teil davon betroffen wäre. Das führt zu der Frage, welcher Ansicht man dann vertrauen soll – der PDF-Ansicht oder der im XRechnung-Viewer? Damit ist ZUGFeRD für einen Täter wie dem im Fall des OLG Schleswig sogar noch komfortabler: Er belässt das PDF so, wie es ist; die automatische Buchhaltung, die auf den XML-Daten basiert, überweist an das modifizierte Konto.
    ...
    Fazit

    Die Idee der XRechnung ist gut. Solange das Format allerdings keine eingebaute Signaturfunktion mitbringt, stellt ein automatisches Verarbeiten ein viel zu hohes Sicherheitsrisiko dar.

    ​...

    Der Autor hat das BSI am 07.02.2025 über dessen Coordinated-Vulnerability-Disclosure-Prozess über die sicherheitsrelevanten Designfehler der XRechnung informiert

    Der Autor

    Tobias Eggendorfer ist Professor für IT-Sicherheit und freiberuflicher IT-Berater. Ihm gefällt an der XRechnung zwar, dass sie ein Praxisbeispiel für seine Vorlesungen liefert, doch daran hätte es dank vielfachen Pfusch am Softwarebau ohnehin nicht gemangelt. Deshalb versucht der Autor, Verfahren zu erforschen, die Sicherheit messbar machen.

    *****
    hier noch ein Link in die DATEV-community - auch bei der DATEV - zumindest STand 13.01.2025: schlimmer geht nimmer:

    Zitat:
    "... Ironischerweise kann auch bei ZUGFeRD etwas anderes in der XML stehen, als in der PDF-Sichtkomponente. Die Einladung für Lug und Trug ist also trotzdem gegeben. Daher empfiehlt es sich immer anhand der XML-Daten zu buchen, da diese rechtlich Vorrang haben.​"
    und nein, die DATEV-Lösung ist beim effektiven Abarbeiten einer ZUGFeRD-Rechnung auch keine Hilfe (Stand 13.01.2025):
    "... würden die Werte konsequent aus der XML Datei (in die Buchführung) übernommen werden, könnte man die Buchungszeile einfach mit der Sichtkomponente abgleichen. Leider ist das aktuell nicht der Fall. Da Werte aus der Sichtkomponente (hä? wie kann man denn sowas programmieren? DATEV der "Superstandard"?) übernommen werden, muss also ein Abgleich mit der XML Visualisierung vorgenommen werden um Gewissheit zu haben.

    Ist das absolut unsinnig? Ja.
    Kostet uns das wertvolle Zeit, die wir nicht haben? Ja.
    Hat sich die Datev dafür Arbeit gespart? Ja.

    Das ist eben das Ergebnis, wenn man in letzter Minute irgendwas zusammen programmieren lässt, von Leuten die absolut keine Ahnung von den praktischen Anforderungen an die Software haben. Ist leider keine Ausnahme."











    #2
    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.

    Die Hauptgefahr für Unternehmen: Der gespaltene Workflow

    In kleinen 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 aber nicht aus dem PDF, sondern aus der XML-Schicht.

    Das heißt: Die Person, die freigibt, prüft eine andere Datenquelle als die, aus der gebucht wird. Ein Angreifer muss nur die IBAN im XML ändern und das PDF unberührt lassen – Betrag stimmt, Lieferant stimmt, nur das Geld landet auf einem fremden Konto. Bei hohem Rechnungsvolumen fällt das erst auf, wenn der echte Lieferant mahnt.

    Die steuerlichen Fallen – oft unterschätzt

    Über den Betrugsfall hinaus lauern bei XML/PDF-Abweichungen handfeste steuerliche Risiken, die auch ohne böswillige Manipulation entstehen können – etwa durch Softwarefehler des Rechnungsstellers oder fehlerhafte Konvertierung:
    • Vorsteuerabzug gefährdet: Das BMF hat klargestellt, dass bei ZUGFeRD ausschließlich die XML-Daten steuerlich maßgeblich sind – nicht das PDF. Wenn das PDF 19 % MwSt. ausweist, im XML aber 7 % stehen, beträgt der zulässige Vorsteuerabzug 7 %. Wer auf Basis des PDFs 19 % geltend macht, hat bei der nächsten Prüfung ein Problem. DATEV formuliert es so: "Wer ausschließlich anhand der Darstellungskomponente prüft, übernimmt das Risiko eines unrichtigen Vorsteuerabzugs."
    • Steuerbetrag und §14c UStG: Laut BMF-Schreiben vom 15.10.2025 kann ein PDF mit abweichenden Rechnungsangaben als eigenständige, zusätzliche Rechnung gewertet werden. Die Folge: Der Rechnungssteller schuldet die Steuer aus beiden Dokumenten – also potenziell doppelt. Das betrifft nicht nur Angreifer, sondern jeden Aussteller, dessen Software PDF und XML nicht konsistent erzeugt.
    • Belegart vertauscht: Steht im XML der Typcode 381 (Gutschrift) statt 380 (Rechnung), kehrt die Buchhaltungssoftware die Buchungsrichtung automatisch um. Aus einer Verbindlichkeit wird eine Forderung, die USt-Voranmeldung wird falsch. Das passiert lautlos, weil ERP-Systeme den Typcode maschinell verarbeiten, ohne den PDF-Inhalt zu prüfen.
    • Fälligkeit und Skonto: Wenn das XML eine Fälligkeit von 10 Tagen mit 2 % Skonto enthält, das PDF aber 30 Tage nennt, bucht der automatische Zahlungslauf nach XML – das Unternehmen zahlt drei Wochen früher als erwartet oder verpasst umgekehrt einen berechtigten Skontoabzug.
    • Betriebsprüfung: Prüfer arbeiten mit der Software IDEA und können sämtliche XML-Rechnungsdaten maschinell gegen USt-Voranmeldungen und Buchungsjournale abgleichen. Was früher Stichprobe war, ist heute Vollprüfung. Jede Diskrepanz zwischen XML-Daten und gebuchten Werten wird sichtbar.
    • Geschäftsführerhaftung: Nach §69 AO haften Geschäftsführer persönlich für Steuerausfälle bei grob fahrlässiger Pflichtverletzung. Das Fehlen angemessener Prüfprozesse für XML-Rechnungsdaten kann als grobe Fahrlässigkeit gewertet werden – "Ich habe nur das PDF geprüft" ist keine Entlastung.

    Gefahr für Privatanwender – die IBAN-Falle

    Bei mobilen Banking-Apps (Sparkasse Fotoüberweisung, VR-Banking etc.) ist das Risiko geringer als zunächst vermutet. 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 bei 200 € auf der Rechnung.

    Die eigentliche Gefahr liegt bei Desktop-Banking-Software wie Hibiscus, StarMoney oder SFirm. Wer dort eine Factur-X-Rechnung per Drag & Drop importiert, bekommt die Überweisungsdaten aus dem XML vorausgefüllt – IBAN, Betrag, Verwendungszweck. Das Angriffsziel ist dabei nicht der Betrag (der würde auffallen), sondern die IBAN. Das PDF zeigt die korrekte Rechnung des Lieferanten, der Betrag stimmt, aber im XML steckt eine fremde Bankverbindung. Kaum jemand gleicht die vorausgefüllte IBAN manuell mit dem PDF ab. Am Kontoauszug fällt es nicht auf, weil der Betrag korrekt ist – erst die Mahnung des Lieferanten Wochen später deckt den Schaden auf.

    Was hilft?
    • Digitale Signaturen könnten das Problem 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 – keine der gängigen Buchhaltungs- oder Banking-Lösungen bietet das bisher eingebaut
    • Konkret heißt das: Vor jeder Freigabe sollten PDF-Inhalt und XML-Daten feldweise verglichen werden – nicht nur IBAN, sondern auch Steuerbetrag, Steuersatz, Belegart und Fälligkeit

    Unter Werbelink entfernt kann man eine Factur-X-Datei hochladen und bekommt beide Schichten feldweise gegenübergestellt – von IBAN über Steuerbeträge bis zum Dokumenttyp. Das ersetzt keinen Steuerberater, hilft aber, Abweichungen sichtbar zu machen, bevor sie in der Buchhaltung landen.

    Die Grundkritik des Threaderstellers teile ich: Ein Format, das Automatisierung verspricht, aber die Integritätsprüfung dem Empfänger überlässt, hat ein strukturelles Problem. Dass das BSI im Rahmen einer Coordinated Vulnerability Disclosure mit dem Thema befasst ist und der Gesetzgeber mit dem BMF-Schreiben vom Oktober 2025 zumindest die Rechtsfolgen klargestellt hat, zeigt: Das Problem ist erkannt – aber die Lösung liegt derzeit noch beim Anwender.

    Kommentar


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

      Kommentar

      Lädt...
      X