{"id":296451,"date":"2024-06-21T00:01:00","date_gmt":"2024-06-20T22:01:00","guid":{"rendered":"https:\/\/www.borncity.com\/blog\/?p=296451"},"modified":"2024-06-24T20:32:32","modified_gmt":"2024-06-24T18:32:32","slug":"wachstumschancengesetz-2024-rechnungsdatenformat-zugferd-als-risiko","status":"publish","type":"post","link":"https:\/\/borncity.com\/blog\/2024\/06\/21\/wachstumschancengesetz-2024-rechnungsdatenformat-zugferd-als-risiko\/","title":{"rendered":"Wachstumschancengesetz 2024: Rechnungsdatenformat ZUGFeRD als Risiko?"},"content":{"rendered":"<p><img decoding=\"async\" style=\"float: left; margin: 0px 10px 0px 0px; display: inline;\" title=\"Sicherheit (Pexels, allgemeine Nutzung)\" src=\"https:\/\/borncity.com\/blog\/wp-content\/uploads\/2021\/04\/Sicherheit_klein.jpg\" alt=\"Sicherheit (Pexels, allgemeine Nutzung)\" width=\"200\" align=\"left\" \/>Ich greife mal das Thema eRechnung (ZUGFeRD) auf, die ja im Wachstumschancengesetz 2024 als demn\u00e4chst verbindlich f\u00fcr den Business-to-Business-Bereich festgeschrieben wurde. Die elektronische Rechnung muss dann in Form eines PDF-Dokuments (f\u00fcr Menschen lesbar) und in Form einer XML-Datei (maschinenlesbar) \u00fcbermittelt werden. Das sind aber zwei Dokumentformate, die mit erheblichen Risiken in Richtung \"Verbreitung von Schadsoftware\" behaftet sind. Ich werfe mal einen Blick auf dieses Themenfeld.<\/p>\n<p><!--more--><\/p>\n<h2>Elektronische Rechnung wird Pflicht<\/h2>\n<p><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/vg09.met.vgwort.de\/na\/cfab4964633045a28fbe08ef0712d0e5\" alt=\"\" width=\"1\" height=\"1\" \/>Ab dem 1.1.2025 wird die Verwendung einer elektronischen Rechnung (kurz eRechnung) zwischen Firmen &#8211; sogenannter Business-to-Business-Bereich (B2B) &#8211; verpflichtend eingef\u00fchrt. Das ist im <a href=\"https:\/\/www.haufe.de\/steuern\/gesetzgebung-politik\/wachstumschancengesetz_168_600636.html\" target=\"_blank\" rel=\"noopener\">Wachstumschancengesetz<\/a> 2024, welches im M\u00e4rz 2024 verabschiedet wurde, festgeschrieben. F\u00fcr kleinere Betriebe gibt es aber bis Ende 2027 \u00dcbergangsregelungen.<\/p>\n<p>Das Ganze geht wohl auf die EU-Richtlinie 2014\/55\/EU aus dem Jahr 2014 f\u00fcr Rechnungen bei \u00f6ffentlichen Auftr\u00e4gen, die in elektronischer Form erfolgen muss, hervor. Haufe hat <a href=\"https:\/\/www.haufe.de\/steuern\/gesetzgebung-politik\/elektronische-rechnung-wird-pflicht-e-rechnung-im-ueberblick_168_605558.html\" target=\"_blank\" rel=\"noopener\">hier<\/a> einige Informationen zusammen getragen, so sind f\u00fcr eRechnungen die Formate XRechnung und ZUGFeRD zul\u00e4ssig bzw. vorgeschrieben.<\/p>\n<h3>Was ist ZUGFeRD?<\/h3>\n<p><a href=\"https:\/\/de.wikipedia.org\/wiki\/ZUGFeRD\" target=\"_blank\" rel=\"noopener\">ZUGFeRD<\/a> steht f\u00fcr <i>Zentraler User Guide des Forums elektronische Rechnung Deutschland<\/i>, ein grauseliger Name f\u00fcr eine Spezifikation zum Austausch elektronischer Rechnungen. ZUGFeRD-konforme Rechnungen sollen zwischen Unternehmen sowie zwischen Unternehmen und der \u00f6ffentlichen Verwaltung schnell, komfortabel und einfach elektronisch ausgetauscht werden.<\/p>\n<p>Die Spezifikation sieht vor, dass maschinenlesbares UN\/CEFACT-XML in menschenlesbare PDF-Dateien (<a href=\"https:\/\/de.wikipedia.org\/wiki\/PDF\/A#PDF\/A-3\" target=\"_blank\" rel=\"noopener\">PDF\/A-3<\/a>) \u2013 gem\u00e4\u00df der Richtlinie EU\/2014\/55 und des Standards EN16931 &#8211; einbettet werden. Damit sollen elektronische Rechnung noch f\u00fcr einen menschlichen Betrachter lesbar sein, aber auch maschinenlesbar f\u00fcr Software werden, die dann den XML-Datenteil auswerten.<\/p>\n<h3>Was ist XRechnung?<\/h3>\n<p>Bei <a href=\"https:\/\/de.wikipedia.org\/wiki\/XRechnung\" target=\"_blank\" rel=\"noopener\">XRechnung<\/a> handelt es sich ebenfalls um einen Standard f\u00fcr elektronische Rechnungen, in dem die Rechnungsdaten in maschinenlesbarer Form (XML) vorliegen. Das <a href=\"https:\/\/de.wikipedia.org\/wiki\/ZUGFeRD\" target=\"_blank\" rel=\"noopener\">ZUGFeRD<\/a> 2.1.1 Profil \"XRechnung\" erm\u00f6glicht seit 1. Juli 2020 ebenfalls elektronische Rechnungen konform zur XRechnung im XML-Format zu erzeugen und damit f\u00fcr den Versand an \u00f6ffentliche Auftraggeber zu verwenden.<\/p>\n<h2>Potentielle Sicherheitsprobleme und Fallen<\/h2>\n<p>Erstmals hat sich heise im M\u00e4rz 2024 in <a href=\"https:\/\/www.heise.de\/meinung\/Pflicht-zur-E-Rechnung-Trojanisches-ZUGFeRD-9646385.html\" target=\"_blank\" rel=\"noopener\">diesem Artikel<\/a> zum Thema ge\u00e4u\u00dfert und findet die Pflicht zur eRechnung eine gute Idee, deren Implementierung f\u00fcr Sicherheitsexperten aber kritische Fragen aufwerfen w\u00fcrde. Es wird allgemein auf die Komplexit\u00e4t von ZUGFeRD und das Problem XML-Valisierung eingegangen.<\/p>\n<h3>Hochrisikoformat ZUGFeRD?<\/h3>\n<p>Blog-Leser Patrick hatte sich in <a href=\"https:\/\/borncity.com\/blog\/2024\/06\/05\/digitalkompetenz-und-cybersecurity-neues-vom-cdu-hack-nchstes-cdu-datenleck\/#comment-183948\" target=\"_blank\" rel=\"noopener\">diesem Kommentar<\/a> dagegen konkreter ge\u00e4u\u00dfert und schrieb: \"Daf\u00fcr hat die Bundesregierung ein Hochrisikoformat (PDF) mit einem weiteren Hochrisikoformat (XML) f\u00fcr den Rechnungsdatenaustausch kombiniert und unter dem Namen \"Wachstumschancengesetz\" ab 2025 verbindlich f\u00fcr alle Businessanwender vorgeschrieben. [&#8230;] Hier \u00f6ffnen sich echte Chancen f\u00fcr fl\u00e4chendeckende Cyberangriffe mit Trojanern, die auch alle Kundendaten von Handwerkern, Einzelh\u00e4ndler etc. betreffen.\" Ich fand den Kommentar spannend, so dass ich einige Punkte in diesem Blog-Beitrag aufbereiten m\u00f6chte.<\/p>\n<h3>PDF-Format als Risiko<\/h3>\n<p>Patrick hatte mit seinem obigen Kommentar einerseits das Risiko PDF-Austauschformat im Sinn. Hinsichtlich des Risikos muss man beim Adobe PDF-Datenformation zwei Sachen unterscheiden:<\/p>\n<ul>\n<li>a) die M\u00f6glichkeit, Scripte in JavaScript in die Dokumente einzubetten<\/li>\n<li>b) die Implementierung der PDF-Reader, die immer wieder durch Schwachstellen auffallen<\/li>\n<\/ul>\n<p>Beide Punkte stellen ein immanentes Risiko dar, sobald PDF-Dokumente als ZUGFeRD fl\u00e4chendeckend durch die Lande geschickt werden.<\/p>\n<h3>XML-Format als Risiko<\/h3>\n<p>Bei ZUGFeRD werden zus\u00e4tzlich XML-Daten f\u00fcr die Rechnung im PDF-Dokument eingebettet. In der Theorie ist XML ein Format zum Datenaustausch, dessen Struktur und Inhalt daraufhin \u00fcberpr\u00fcft werden kann, ob diese \"wohlgeformt\" sind und der Spezifikation entsprechen. In der Praxis muss ein XML-Dokument durch einen XML-Parser eingelesen, validiert und interpretiert werden. Und an dieser Ecke lauern die Risiken, wenn beispielsweise Data-Inhalte im XML-Dokument den XML-Parser aus dem Tritt bringen und zu Puffer\u00fcberl\u00e4ufen, Code-Ausf\u00fchrung etc. f\u00fchren.<\/p>\n<p>Befragt man mal das Web nach XML und Sicherheit, wird man auf das OWASP <a href=\"https:\/\/cheatsheetseries.owasp.org\/cheatsheets\/XML_Security_Cheat_Sheet.html\">XML Security Cheat Sheet sto\u00dfen<\/a>. Das Dokument befasst sich mit der Frage, was passiert, wenn der XML-Teil eines Dokuments nicht den Spezifikationen f\u00fcr wohlgeformtes XML entspricht und gibt folgende Antwort:<\/p>\n<blockquote><p>Unexpected consequences may result from manipulating documents using parsers that do not follow W3C specifications. It may be possible to achieve crashes and\/or code execution when the software does not properly verify how to handle incorrect XML structures. Feeding the software with fuzzed XML documents may expose this behavior.<\/p><\/blockquote>\n<p>Da ist fast alles (mit Ausnahme der Detonation einer Atombombe) an Schlechtigkeiten drin. Dem XML-Parser kommt also eine zentrale Rolle zu, ob die XML-Daten sicher gelesen und nicht wohlgeformte Dokumente abgewiesen werden. Da wir alle wissen, dass diese Implementierungen mitunter \"steil gehen\" und erhebliche Sicherheitsrisiken aufrei\u00dfen, sind wir mitten im Thema.<\/p>\n<h2>eRechnung legt Deutschland lahm?<\/h2>\n<p>Der oben erw\u00e4hnte Kommentar von Patrick stellt darauf ab, dass eine mit sch\u00e4dlichen Inhalten gespickte eRechnung im ZUGFeRD-Format f\u00fcr allerlei Angriffe genutzt werden k\u00f6nnte. Massenhaft an Firmen geschickt, k\u00f6nnte man mit eRechnungen &#8211; dank der Hochrisikoformate PDF und XML &#8211; halb Deutschland lahmlegen.<\/p>\n<h3>PDF und eingebettetes JavaScript<\/h3>\n<p>Bez\u00fcglich PDF ist es vor allem eingebettetes JavaScript, welches zahlreiche Angriffsm\u00f6glichkeiten bietet. Ich habe mal ein wenig recherchiert, laut den <a href=\"https:\/\/www.bundesarchiv.de\/DE\/Content\/Downloads\/Anbieten\/Behoerdenberatung\/beratungsangebote-grundl-sgv-empfehlungen-pdf-a-versionen.pdf?__blob=publicationFile\" target=\"_blank\" rel=\"noopener\">Empfehlungen des Bundesarchivs zur Anwendung der verschiedenen PDF\/A-Versionen<\/a> ist das Einbetten von JavaScript-Inhalten in PDF\/A-3, welches ja bei ZUGFeRD genutzt wird, verboten. Andererseits ist das Einbinden von Dateien beliebiger Dateiformate zul\u00e4ssig. Theoretisch ist durch das Verbot von JavaScript-Inhalten in PDF\/A-3 eine gro\u00dfe Sicherheitsproblematik entfallen. Praktisch stellt sich die Frage: Halten sich die PDF-Generatoren daran? Und wie sieht das in der Praxis aus?<\/p>\n<h3>Problem XML- und PDF-Reader-Bibliotheken<\/h3>\n<p>Ein PDF-Reader f\u00fcr die eRechnung m\u00fcsste also JavaScript-Inhalte in einer PDF-Datei ignorieren oder die Datei sogar abweisen. Ich bin mir aber nicht sicher, ob das so passiert. Im Zweifel setzen die Programmierer auf eine Bibliothek zur Verarbeitung von JavaScript oder auf den Adobe Reader und das wandelnde Sicherheitsrisiko ist im System.<\/p>\n<p>Zudem: Ich gehe davon aus, dass eRechnungen, die beim Empf\u00e4nger eintrudeln, von diesem in einem normalen PDF-Reader ge\u00f6ffnet werden. Im d\u00fcmmsten Fall reicht ein Doppelklick auf die Rechnungsdatei, und diese geht im Microsoft Edge mit integriertem PDF-Reader auf (die Integration ist ja angek\u00fcndigt). Wenn dann noch JavaScript aktiviert ist, wird es lustig.<\/p>\n<p>Hei\u00df zu deutsch: Wenn sich eRechnungen nicht an die Vorgaben von PDF\/A-3 halten und der Reader zur Anzeige des PDF-Inhalts patzt, sind damit wunderbar Angriffe ausf\u00fchrbar. \u00c4hnliches gilt f\u00fcr den eingebetteten XML-Dokumentteil der eRechnung. Wenn dieser b\u00f6sartige Inhalte enth\u00e4lt und nicht vom XML-Parser abgewiesen wird, \u00f6ffnet dies f\u00fcr Angriffe und Manipulationen T\u00fcr und Tor.<\/p>\n<p>Und wir haben es ja nicht mit einer Software a la Adobe Reader oder Adobe Acrobat zu tun, sondern jeder Anbieter, der Buchhaltungssoftware strickt, wird da seine eigene Suppe kochen. Das wird ein gefundenes Fressen f\u00fcr Sicherheitsforscher und ein Alptraum f\u00fcr Leute, die vor gefundenen Schwachstellen warnen und Updates anmahnen.<\/p>\n<h3>Allerorten Zwang zu JavaScript &#8230;<\/h3>\n<p>Administratoren k\u00f6nnten m\u00f6glicherweise die Unterst\u00fctzung von JavaScript per Gruppenrichtlinien in Software wie Edge oder im Adobe Reader etc. deaktivieren. Dann w\u00e4re ein Angriffsvektor entsch\u00e4rft.<\/p>\n<p>Problem sind dann aber Szenarien, die aktiviertes JavaScript zwingend erfordern. Das ist beispielsweise der Fall, wenn Formulare in PDF-Dokumenten auszuf\u00fcllen sind. Patrick hat mich in einer Mail beispielsweise darauf hingewiesen, dass die Bundesagentur f\u00fcr Arbeit da in <a href=\"https:\/\/www.arbeitsagentur.de\/hilfe\" target=\"_blank\" rel=\"noopener\">ihrer Hilfe<\/a> folgendes schreibt.<\/p>\n<blockquote><p>\"Zum \u00d6ffnen der auf unseren Internet-Seiten zum Download angebotenen PDF-Dokumente ben\u00f6tigen Sie einen PDF-Reader bzw. PDF-Viewer oder einen aktuellen Browser, der die Ansicht von PDF-Dateien unterst\u00fctzt.<br \/>\n[&#8230;]<br \/>\nDas Ausf\u00fcllen interaktiver Formulare im Browser wird aus<br \/>\nSicherheitsgr\u00fcnden nur eingeschr\u00e4nkt unterst\u00fctzt. Daher ist in der Regel die Installation eines separaten PDF-Reader erforderlich. Es bieten jedoch nur wenige PDF-Reader zus\u00e4tzlich komfortable Funktionen zum Ausf\u00fcllen von Formularen an, unterst\u00fctzt wird diese Funktion zum Beispiel vom Adobe Acrobat DC, dem Foxit Reader oder dem Master PDF<br \/>\nEditor f\u00fcr Linux.\"<\/p><\/blockquote>\n<p>Kann man zur Kenntnis nehmen, scheint ja potentiell noch nichts schlimmes. Schaut man aber nach dem empfohlen Adobe Acrobat DC, findet sich bei Adobe bekommt man zur \u00dcberschrift \"Interaktiv.\" dann <a href=\"https:\/\/web.archive.org\/web\/20240303003641\/https:\/\/www.adobe.com\/de\/acrobat\/how-to\/create-fillable-pdf-forms-creator.html\" target=\"_blank\" rel=\"noopener\">folgende Erkl\u00e4rung<\/a>:<\/p>\n<blockquote><p>\"Mit JavaScript kannst du deine PDF-Dokumente um Berechnungen, Validierungsregeln und Schaltfl\u00e4chen mit zugewiesenen Aktionen erweitern.\"<\/p><\/blockquote>\n<p>Doch dies ist nicht nur auf die PDF-Reader von Adobe begrenzt. Mittlerweile unterst\u00fctzen auch aktuelle Browser interaktive Inhalte mit JavaScript verarbeiten, z. B. Firefox (hier ein Verweis auf die Warnung \"<a href=\"https:\/\/www.mozilla.org\/en-US\/security\/advisories\/mfsa2024-21\/\" target=\"_blank\" rel=\"noopener\">CVE-2024-4367: Arbitrary JavaScript execution in PDF.js<\/a>\" von Mitte Mai 2024).<\/p>\n<h2>Abschlie\u00dfende Gedanken<\/h2>\n<p>Patrick wies mich auf das gro\u00dfe Problem hin.\u00a0Weil auch die Webseiten der BfA, der Bundesregierung und den meisten weiteren \u00f6ffentlichen Stellen ohne JavaScript gar nicht mehr funktionieren, stellt sich die grunds\u00e4tzliche Frage nach der Cybersicherheit.<\/p>\n<p>Hier f\u00e4llt mir ein Spruch aus der Bauwirtschaft ein \"Beton, es kommt darauf an, was man damit macht\", der mir in den 80er Jahren mal untergekommen ist. Im Sinne der eRechnung abgewandelt, hei\u00dft es \"es kommt darauf an, was man damit macht\". Optimisten werden jetzt sagen, das kriegen wir hin. Pessimisten fragen \"was kann schon schiefgehen\", um dann den Erfahrungswert \"alles\" nachzuschieben.<\/p>\n<p>Das ist auch der Tenor des oben erw\u00e4hnen heise-Artikels <a href=\"https:\/\/www.heise.de\/meinung\/Pflicht-zur-E-Rechnung-Trojanisches-ZUGFeRD-9646385.html\" target=\"_blank\" rel=\"noopener\">E-Rechnung und ZUGFeRD: Sollen Menschen XML und PDF vergleichen \u2013 srsly?<\/a>, welcher in der URL die Aussage \"Pflicht zur eRechnung als trojanisches ZUGFeRD\" enth\u00e4lt.<\/p>\n<p>So einen kleinen Vorgeschmack aus der Praxis liefert Blog-Leser R.S. in <a href=\"https:\/\/borncity.com\/blog\/2024\/06\/05\/digitalkompetenz-und-cybersecurity-neues-vom-cdu-hack-nchstes-cdu-datenleck\/#comment-183984\">diesem Kommentar<\/a>. Er sei \"gerade dabei, den Mist zu implementieren\" schreibt der Leser und zieht vom Leder, wo es \u00fcberall hakt. L\u00e4uft mit (der) Sicherheit.<\/p>\n<p>Was mich an dieser Stelle wundert: Das Thema ist mir bisher so nicht in den einschl\u00e4gigen Medien untergekommen. Ohne den Hinweis von Patrick zu <a href=\"https:\/\/borncity.com\/blog\/2024\/06\/05\/digitalkompetenz-und-cybersecurity-neues-vom-cdu-hack-nchstes-cdu-datenleck\/\">einem Blog-Beitrag<\/a>, in dem es um die Digitalkompetenz einer gro\u00dfen deutschen Partei ging, w\u00e4re mir das \"Lichtlein auch nicht aufgegangen\".<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Ich greife mal das Thema eRechnung (ZUGFeRD) auf, die ja im Wachstumschancengesetz 2024 als demn\u00e4chst verbindlich f\u00fcr den Business-to-Business-Bereich festgeschrieben wurde. Die elektronische Rechnung muss dann in Form eines PDF-Dokuments (f\u00fcr Menschen lesbar) und in Form einer XML-Datei (maschinenlesbar) \u00fcbermittelt &hellip; <a href=\"https:\/\/borncity.com\/blog\/2024\/06\/21\/wachstumschancengesetz-2024-rechnungsdatenformat-zugferd-als-risiko\/\">Weiterlesen <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[426],"tags":[4328],"class_list":["post-296451","post","type-post","status-publish","format-standard","hentry","category-sicherheit","tag-sicherheit"],"_links":{"self":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/296451","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/comments?post=296451"}],"version-history":[{"count":0,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/296451\/revisions"}],"wp:attachment":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/media?parent=296451"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/categories?post=296451"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/tags?post=296451"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}