© Andriy Popov / 123RF.com

Seit dem 1. Januar 2025 soll die XRechnung das Leben von Buchhaltern leichter machen. Wer keine teure kommerzielle Lösung will, kann sich mit LibreOffice behelfen. Doch Sicherheitsmängel des XRechnung-Konzepts machen Betrügern das Leben leicht.

Wer als Freiberufler oder Gewerbetreibender Rechnungen für die öffentliche Hand oder im B2B-Bereich stellt, kommt, abgesehen von einigen Ausnahmen, kaum um die XRechnung herum. Hört man auf seinen Steuerberater, landet man wahrscheinlich bei DATEV, einer Lösung, die nicht gänzlich überzeugt. Also muss eine Alternative her. Zum Glück gibt es etwas Passendes für LibreOffice.

Wie der Zufall es wollte, stand bei mir ein Beitrag für die Zeitschrift “Kommunikation und Recht” [1] zu einem Urteil des OLG Schleswig an: 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?

Satz mit X(ML)

Deutschland versucht sich an Digitalisierung jenseits des Faxgeräts. Auf den ersten Blick klingt das gut. Was könnten eine elektronische Patientenakte (ePA [2]) und das besondere elektronische Anwaltspostfach (beA [3]) nicht alles erleichtern – wären da nicht diese IT-Sicherheitsleute oder gar der Chaos Computer Club [4]. In deren Ohren klingt wahrscheinlich auch die EU-weite XRechnung verdächtig.

Dabei ist die Grundidee einfach: Statt eine Rechnung zu drucken, sie per Post (oder als PDF) zu verschicken und dann von Hand die IBAN, die Rechnungsnummer und so weiter für eine Überweisung abzutippen und das Spiel anschließend für die Buchhaltung zu wiederholen, wäre doch eine maschinenlesbare Rechnung praktisch. Dann könnte der Computer die Überweisung selbst ausfüllen und die Buchhaltung gleich miterledigen. Ganz nebenbei wäre auch das Finanzamt glücklich, dem das die Prüfung erleichtern würde.

Laut Spezifikation [5] ist eine XRechnung in XML verfasst. Im Kern gibt es einige Pflichtfelder. Dazu gehören Rechnungssteller und -empfänger, Steuer-IDs, Rechnungspositionen, Umsatzsteuersätze und so weiter. Zudem sind Zusatzfelder für bestimmte Anwendungszwecke erlaubt. Listing 1 zeigt ein (gekürztes) Beispiel für eine einfache XRechnung. Wenig überraschend: Die für eine Rechnung erforderlichen Daten sind in XML verpackt, inklusive IBAN und Steuernummern. Wer sich das Ganze in einem besser lesbaren Format ansehen will, greift beispielsweise zum E-Rechnungs-Viewer Quba [6], einer Open-Source-Lösung (Abbildung 1).

Abbildung 1: So sieht eine maschinenlesbare XRechnung im E-Rechnungs-Viewer Quba aus.

<?xml version="1.0" encoding="UTF-8"?>
<rsm:CrossIndustryInvoice xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"
  xmlns:qdt="urn:un:unece:uncefact:data:standard:QualifiedDataType:100"
  xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100">
  <rsm:ExchangedDocumentContext>
    <ram:BusinessProcessSpecifiedDocumentContextParameter>
      <ram:ID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</ram:ID>
    </ram:BusinessProcessSpecifiedDocumentContextParameter>
    <ram:GuidelineSpecifiedDocumentContextParameter>
      <ram:ID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</ram:ID>
    </ram:GuidelineSpecifiedDocumentContextParameter>
  </rsm:ExchangedDocumentContext>
  <rsm:ExchangedDocument>
  [...]
  </rsm:ExchangedDocument>
  <rsm:SupplyChainTradeTransaction>
    <ram:IncludedSupplyChainTradeLineItem>
    [...]
    <ram:SpecifiedTradeProduct>
      <ram:SellerAssignedID>1</ram:SellerAssignedID>
      <ram:Name>Leistung: Beratung</ram:Name>
      <ram:Description>Leistung: Beratung</ram:Description>
    </ram:SpecifiedTradeProduct>
    <ram:SpecifiedLineTradeAgreement>
      <ram:NetPriceProductTradePrice>
        <ram:ChargeAmount>123.000000</ram:ChargeAmount>
      </ram:NetPriceProductTradePrice>
    </ram:SpecifiedLineTradeAgreement>
    <ram:SpecifiedLineTradeDelivery>
      <ram:BilledQuantity unitCode="XPP">1.0000</ram:BilledQuantity>
    </ram:SpecifiedLineTradeDelivery>
    <ram:SpecifiedLineTradeSettlement>
      <ram:ApplicableTradeTax>
        <ram:TypeCode>VAT</ram:TypeCode>
        <ram:CategoryCode>E</ram:CategoryCode>
        <ram:RateApplicablePercent>19.000</ram:RateApplicablePercent>
      </ram:ApplicableTradeTax>
      [...]
      <ram:SpecifiedTradeSettlementLineMonetarySummation>
        <ram:LineTotalAmount>123.00</ram:LineTotalAmount>
      </ram:SpecifiedTradeSettlementLineMonetarySummation>
     </ram:SpecifiedLineTradeSettlement>
    </ram:IncludedSupplyChainTradeLineItem>
    [...]
  </rsm:SupplyChainTradeTransaction>
</rsm:CrossIndustryInvoice>

IBAN? Da war doch was?

Was soll da schon schiefgehen? Das macht das Leben doch leichter, es lässt sich ja alles automatisieren. Doch wie gut schützt die XRechnung vor Angriffen wie dem, über den das OLG Schleswig entschieden hat? Verschlüsselung, das wissen wir schon, wird es nicht richten.

Der Angriff auf das PDF im Fallbeispiel war nicht trivial. Zum einen muss der Angreifer automatisch die IBAN und die weiteren Bankverbindungsangaben im PDF finden. Je nachdem, wie das Dokument zustande kam, muss das keine zusammenhängende Zeichenkette sein. Überhaupt stehen die Angaben an unterschiedlichen Stellen in Rechnungen, vom rechten Seitenrand über die Fußzeile bis hin zu beliebigen Stellen im Fließtext. Das Problem kennt jeder, der Rechnungen zum Überweisen abtippt.

Hat der Angreifer die Schlüsseldaten gefunden, muss er die IBAN und gegebenenfalls die BIC sowie den Namen der Bank sauber ersetzen. Das Ganze muss schnell gehen, denn viele Angriffsorte bleiben nicht. Mögliche Stellen wären:

• der Computer des Rechnungsstellers, beispielsweise durch eine Schadsoftware,
• der Mailserver des Rechnungsstellers, wo die E-Mail allerdings nur sehr kurz in der Queue verharrt,
• der Mailserver des Empfängers, auf dem die Nachricht dank des häufig genutzten IMAP recht lange liegt,
• eventuelle Malware-Scanner auf beiden Seiten sowie
• der Rechner des Rechnungsempfängers, etwa durch eine Malware.

Das macht dem Angreifer bei einer herkömmlichen Rechnung eine Menge Arbeit. Die XRechnung kommt ihm da viel mehr entgegen: Dank des standardisierten Formats finden sich die Bankangaben leichter, Plaintext editiert sich ohnehin besser. Da wird doch das Format eine Signatur enthalten? So ist es aber nicht.

Nun soll nach Ansicht des OLG Schleswig der Rechnungssteller haften, falls die Rechnung unterwegs verändert wird. Obendrein ist seit 01.01.2025 die Nutzung der XRechnung Pflicht – eine ungünstige Kombination. Es bleibt nur die Option, mit einer E-Mail-Signatur zu arbeiten und so den Anhang der Nachricht mit zu schützen.

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.

Eine naheliegende erste Gegenmaßnahme wäre eine PDF-Signatur. Sie umfasst die eingebundene XML-Datei und schützt so beide Teile vor nachträglicher Veränderung. Dazu eignet sich die Digital-unterschreiben-Funktion im PDF-Viewer. Schön wäre, wenn der ZUGFeRD-Standard sie vorschreiben würde.

Abgerechnet

Wer selbst Rechnungen nach dem XRechnung-Standard schreiben möchte, kann auf Tools wie die vom Steuerberater angebotenen zurückgreifen. Zum Glück gibt es darüber hinaus eine Lösung für LibreOffice, die sich auf der Website des Projekts unter Themenbücher und Kurzanleitungen ganz unten als XRechnung [7] versteckt. Heruntergeladen und ausgepackt, findet sich ein Ordner mit einer LibreOffice-Datenbank, mehreren OpenDocument-Textvorlagen (».ott«), einem Erklär-PDF und einigen weiteren Dateien.

Die Vorlage »Vorlage_Rechnung_Extension.ott« gibt vor, wie die Rechnung später aussehen soll. Sie enthält zahlreiche Feldbefehle, die größtenteils erhalten bleiben sollten. Löschen Sie einen zu viel, läuft später das Skript zur Rechnungserstellung eventuell nicht mehr durch und bricht mit einer Fehlermeldung ab. Die ist zumindest selbsterklärend, denn sie meldet, welcher Feldbefehl fehlt. Weniger intuitiv ist unter anderem, dass ein Feld für ein Logo existieren muss, selbst wenn man keines verwenden möchte. Etwas hinterhältig: Terminiert das Erstellen der XRechnung mit einer Fehlermeldung, wird die Vorlage überschrieben. Daher empfiehlt es sich, davon eine Sicherungskopie anzulegen.

Um das PDF später mit der XML-Datei zu einem ZUGFeRD-Dokument zu verschmelzen, braucht es das Mustangprojekt [8]. Das heruntergeladene Java-Archiv landet im ausgepackten Ordner. Außerdem braucht LibreOffice noch das Recht, dort Makros auszuführen. Das erledigt eine Einstellung unter dem Menüpunkt Sicherheit |Makrosicherheit. Dort gibt es den Reiter Trusted Locations. Hier geben Sie das Verzeichnis an, in dem die .odb-Datei liegt. Anders als in der Anleitung darf die Makrosicherheit hoch bleiben.

Die Datenbank »Xrechnung_V2502_002.odb« (Abbildung 2) offeriert mehr als bloße Rechnungen: Hier lassen sich Kunden- und Produktlisten anlegen. Das macht die Rechnungserstellung weitaus komfortabler als das Befüllen einiger Tabellenzeilen eines Textdokuments. Von der Rechnungsnummer bis hin zur Zahlungsfrist lässt sich alles in den Einstellungen festlegen.

Abbildung 2: So begrüßt die LibreOffice-XRechnung-Datenbank den Nutzer.

Wer Redundanz mag, findet einen QR-Girocode zum schnelleren Bezahlen sicher praktisch. Allerdings wären die Zahlungsdaten dann dreimal im Dokument vorhanden: einmal im Klartext im PDF, einmal im XML und obendrein als Girocode. Die Einstellung lässt sich etwas versteckt rechts oben in den Einstellungen der Datenbank deaktivieren (Abbildung 3).

Abbildung 3: Wer genau hinsieht, entdeckt oben rechts die Option für Überweisungs-QR-Codes; sonst braucht es zusätzlich Qrencode.

Aus den fertigen Rechnungen generiert die Datenbank dann mithilfe der Vorlage eine XML-Datei und auf Wunsch zusätzlich ein ZUGFeRD-PDF. Sie packt alles versandfertig in eine E-Mail, sofern in OpenOffice das Mailprogramm unter Einstellungen | Internet | E-Mail korrekt konfiguriert ist. Theoretisch würde es jetzt genügen, anschließend im Mailclient auf Senden zu drücken.

Besser wäre es allerdings, das im neu erstellten Unterverzeichnis »Archiv/« lagernde PDF noch im Reader zu signieren, um Manipulationen vorzubeugen. Das bietet allerdings keinen hundertprozentigen Schutz, denn selbst signierte PDFs lassen sich manipulieren. Dazu würde sich beispielsweise eingebettetes Javascript eignen.

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. Doch der Gesetzgeber lässt wenig Spielraum. Wer die Anforderung XRechnung erfüllen muss, findet mit LibreOffice immerhin eine einfache Lösung. Der Autor hat das BSI am 07.02.2025 über dessen Coordinated-Vulnerability-Disclosure-Prozess über die sicherheitsrelevanten Designfehler der XRechnung informiert. (jcb/jlu)