Date post: | 11-Apr-2017 |
Category: |
Technology |
Upload: | juho-nurminen |
View: | 441 times |
Download: | 2 times |
Juho Nurminen TurkuSec meetup, March 2017
The sorry state of Finnish e-payment APIs
...and how to use them securely
1
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
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
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
Juho Nurminen TurkuSec meetup, March 2017
Side track: TUPASSource: fkl.fi
5
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 statusRedirection
payment approval
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.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
Juho Nurminen TurkuSec meetup, March 2017
E-payment message format: Nordea
8
Source: nordea.fi
Juho Nurminen TurkuSec meetup, March 2017
E-payment message format: Nordea
9
Source: nordea.fi
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
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
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
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
Juho Nurminen TurkuSec meetup, March 2017
Breaking out of an e-payment message field
14
Live demo!
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
Juho Nurminen TurkuSec meetup, March 2017
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
Juho Nurminen TurkuSec meetup, March 2017
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
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
Juho Nurminen TurkuSec meetup, March 2017
Questions?
19
[email protected]/jupenurlinkedin.com/in/jupenur