The sorry state of Finnish e-payment APIs

Juho Nurminen TurkuSec meetup, March 2017

The sorry state of Finnish e-payment APIs

...and how to use them securely

1


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


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


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


Side track: TUPASSource: fkl.fi

5


● 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 statusRedirection

payment approval


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.1Host: bankhost.example.com...Content-Type: application/x-www-form-urlencoded

field_1=value_1&field_2=value_2&...&field_n=value_n&hmacfield=0123456789ABCDEF0123456789ABCDEF


E-payment message format: Nordea

8

Source: nordea.fi


E-payment message format: Nordea

9

Source: nordea.fi


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


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


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


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


Breaking out of an e-payment message field

14

Live demo!


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


The problem with e-payment APIs: case OP● Vulnerability reported to [email protected]

○ 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


The problem with e-payment APIs: case OP● Vulnerability reported to [email protected]

○ 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


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


Questions?

19

[email protected]/jupenurlinkedin.com/in/jupenur

Technology

The sorry state of Finnish e-payment APIs