The document discusses vulnerabilities in Finnish e-payment APIs: - Many APIs still use the insecure MD5 hash function, allowing potential collision attacks. - Documentation is sometimes inaccurate or contradictory, making the APIs difficult to use securely. - Special characters are not escaped when calculating HMACs, allowing attackers to modify messages without changing the HMAC. - The OP e-payment API was found to be vulnerable to easily manipulating payment sums without special conditions. While reported, OP deemed it not worth fixing.

1. Juho Nurminen TurkuSec meetup, March 2017
The sorry state of Finnish
e-payment APIs
...and how to use them securely
1

2. Juho Nurminen TurkuSec meetup, March 2017
Who am I?
● Hacker, researcher, developer, student
● Professionally breaking web and mobile software at 2NS
○ Also hacking networks, IoT devices, doing code reviews, handling
responsible disclosure, doing generic IT stuff…
● Vulnerability researcher and bug bounty hunter
○ Google, Mozilla, F-Secure, Avast!, LähiTapiola, Piwik, ...
○ Firefox and Chrome: CVE-2011-2800, CVE-2011-3877,
CVE-2014-1527, CVE-2015-1261, CVE-2015-4508
● Also, taking care of rescue cats at Dewi ry
2

3. Juho Nurminen TurkuSec meetup, March 2017
What's an e-payment API?
● Allows businesses to accept payments online
● A major reason to why online shopping in Finland is so easy
● Provided by banks and Payment Service Providers (PSPs)
○ Nordea, OP, Handelsbanken, S-Pankki, Ålandsbanken…
○ Paytrail, Checkout Finland, Maksuturva…
● Every provider has their own spec and implementation
● Bank e-payment APIs often closely resemble TUPAS
3

4. Juho Nurminen TurkuSec meetup, March 2017
Side track: TUPAS
● "Tunnistuspalvelu asiointipalveluntarjoajille"
● The de facto standard for strong customer
authentication in Finland
● Maintained by Finanssialan Keskusliitto (FK)
● Implemented by individual banks according to FK standards
● Enables authenticating to online services using bank credentials
● Design has a lot in common with Finnish e-payment APIs
4

5. Juho Nurminen TurkuSec meetup, March 2017
Side track: TUPAS
Source: fkl.fi
5

6. Juho Nurminen TurkuSec meetup, March 2017
● Merchant creates a signed
payment request
● Customer receives message,
forwards it to the bank
● Bank does validation, then
initiates 2FA authentication
● Customer authenticates to
bank, approves payment
● Bank creates a signed reply
● Customer forwards the
message back to merchant
6
How bank
e-payments work
Payment
Payment status
Redirection
payment
approval

7. Juho Nurminen TurkuSec meetup, March 2017
E-payment message format
● Messages are submitted to the bank via HTTP POST as
application/x-www-form-urlencoded
● Field naming and exact format varies, contents are more or less the same
7
POST /epayment-endpoint HTTP/1.1
Host: bankhost.example.com
...
Content-Type: application/x-www-form-urlencoded
field_1=value_1&field_2=value_2&...&field_n=value_
n&hmacfield=0123456789ABCDEF0123456789ABCDEF

8. Juho Nurminen TurkuSec meetup, March 2017
E-payment message format: Nordea
8
Source: nordea.fi

9. Juho Nurminen TurkuSec meetup, March 2017
E-payment message format: Nordea
9
Source: nordea.fi

10. Juho Nurminen TurkuSec meetup, March 2017
Calculating the HMAC
10
● Hash function: MD5 or SHA256
● Field values are concatenated together with secret key, separated by a
single-character delimiter
○ Different delimiters in different implementations: "&", "+", "|", or none
sha256(value_1&value_2&...&value_m&secret_key)
● Not all fields are included in the calculation
○ Those omitted are not protected from modifications

11. Juho Nurminen TurkuSec meetup, March 2017
The problem with e-payment APIs:
hash functions
● Starting with the obvious: MD5 still in use
○ The only option when using Nordea, OP, Paytrail, or S-Pankki
○ Supported in Checkout Finland, OmaSP, POP Pankki, Säästöpankki, and Ålandsbanken
● Attacks may not always be possible due to restrictions on field lengths
○ BUT: S-Pankki and Ålandsbanken only apply restrictions on some fields
○ Paytrail allows ridiculous field lengths despite specifying an upper limit
● A collision attack could potentially allow forging arbitrary messages
11

12. Juho Nurminen TurkuSec meetup, March 2017
The problem with e-payment APIs:
self-contradictory documentation
● Documentation is sometimes inaccurate, even wrong
● Often not even possible to use APIs exactly as specified
● E.g.: Most API docs say only alphanumeric chars allowed in field values
○ Yet some fields are supposed contain URLs
○ ...and some fields are supposed to contain decimal points or commas
○ How do you specify a URL without using ":" or "/" ?
○ Since when are decimal points and commas alphanumeric?
12

13. Juho Nurminen TurkuSec meetup, March 2017
The problem with e-payment APIs:
no escaping in field values
● Special characters, including HMAC
delimiters, never escaped when
calculating the HMAC
● If an end-user controls an HMAC field,
they may be able to break out
● Allows an attacker to modify messages
without changing the HMAC
● Spoofed messages let the attacker pay
less for products and services they buy
13
● A real-world attack, with most likely
plenty of vulnerable services out there
● It's basically free money, so go get it
None of this

14. Juho Nurminen TurkuSec meetup, March 2017
Breaking out of an
e-payment message field
14
Live demo!

15. Juho Nurminen TurkuSec meetup, March 2017
The problem with e-payment APIs:
case OP
● The OP e-payment API doesn't use any delimiters in
HMAC calculations
● This, and the structure of the messages, lead to
payment sums being easily manipulated
○ Not dependent on merchant implementations
○ No special conditions required
● A potentially huge issue, could have caused big
losses for companies using the API
15
Source: op.fi

16. Juho Nurminen TurkuSec meetup, March 2017
The problem with e-payment APIs:
case OP
● Vulnerability reported to tietoturvailmoitukset@op.fi
○ OP: Yes, it's a vulnerability, and yes, it's exploitable. But... did
risk analysis, not worth fixing
● Not satisfied with response, reported to NCSC-FI
○ NCSC-FI: Looks bad, but can't force OP to take action. Will hold a meeting with them.
● A few days pass, I get a quick phone call from OP
● This was in late November / early December, no contact from OP since
16
Source: op.fi

17. Juho Nurminen TurkuSec meetup, March 2017
The problem with e-payment APIs:
case OP
● Vulnerability reported to tietoturvailmoitukset@op.fi
○ OP: Yes, it's a vulnerability, and yes, it's exploitable. But... did
risk analysis, not worth fixing
● Not satisfied with response, reported to NCSC-FI
○ NCSC-FI: Looks bad, but can't force OP to take action. Will hold a meeting with them.
● A few days pass, I get a quick phone call from OP
● This was in late November / early December, no contact from OP since
17
Source: op.fi

18. Juho Nurminen TurkuSec meetup, March 2017
Using e-payment APIs securely
● Don't use bank APIs directly, pick a PSP instead!
○ Some PSPs offer XML or JSON based APIs, which seem ok
● Don't allow user input in requests, not even in fields you don't think
matter!
○ If you absolutely have to, restrict it as much as you can
● Validate everything, and be strict about it!
○ Also remember to validate outputs
○ E.g. if the response contains a payment reference, make sure it matches the one you sent
in the request--even if you're not using the payment reference for anything!
18

19. Juho Nurminen TurkuSec meetup, March 2017
Questions?
19
jupenur@protonmail.ch
twitter.com/jupenur
linkedin.com/in/jupenur