Preventing Bind Takeover Attacks

This article was published on: 05/10/22

Preventing Bind Takeover Attacks

by: Henry Schwarz

Triton’s TKM remote key load prevents bind takeover attacks. Other non-Triton ATMs’ remote key load solutions are vulnerable to this type of attack.

Remote key load is the secure delivery of a cryptographic master key from a host to an ATM over a public network. An early step in a remote key load is the ATM binding to the host, and the ATM remains bound to that particular host thereafter.

The bind process is: The host obtains its certificate from the certificate authority, and the host sends this certificate to the ATM. The ATM is pre-loaded with the certificate authority’s public key which the ATM uses to verify that the received host certificate was indeed issued by the legitimate certificate authority. Once the ATM has accepted the received host certificate, the ATM is bound to that host.

For a bind takeover, the attacker must obtain a host certificate from the certificate authority. This is possible if, for example, the certificate authority freely provides certificates to any applicant, or if the attacker is a host who in the past has legitimately obtained a host certificate from the certificate authority.

The attacker’s bogus host simply binds with the ATM before the legitimate host does. It’s that easy.

Once the attacker’s bogus host has bound with the ATM, the bogus host can deliver cryptographic keys to the ATM and serve as the ATM’s transaction processor. The bogus host can then approve transactions performed on the ATM by “mules” so cash is dispensed (cash-out attacks), or the bogus host can harvest account numbers and PINs, etc.

Triton’s TKM uses the following process to prevent bind takeover attacks, i.e. to ensure that an ATM binds with the correct host:
• Triton assigns a unique 16-digit number, named a Host-ID, to a particular host.
• The Host-ID is included as a field within the host certificate.
• The Host-ID is pre-loaded into the ATM.
• When the ATM receives the host certificate during the bind process, the ATM verifies that the Host-ID within the received host certificate is the same as the Host-ID which was pre-loaded into the ATM.

Triton has patented this defense against bind takeover attacks:
https://patents.google.com/patent/US8375203

This defense has always been provided by Triton’s TKM remote key load, since its initial release.

The Host-ID is stored within the host certificate’s Subject Common Name field. In the following example of a host certificate, the Host-ID is 0000000010004300:

This is similar to the approach employed by web browsers using SSL/TLS cryptography. The browser verifies that the Subject Common Name field within the received website certificate is the same as the website’s address. For example, the certificate sent to browsers from www.amazon.com is:

Here’s a tortured analogy, which is mostly just an excuse to link to a beautiful video. Some birds “imprint” with whomever they contact on the day they are born, and forever after treat them as their mother. The metaphor is that this is like an ATM binding with its host. But birds can imprint with anyone or anything, so long as it moves and makes a noise. So too a non-Triton ATM can bind with a bogus host, so long as the attacker has a host certificate issued by the certificate authority. In this video, the ultralight pilot (bogus host) imprints geese (non-Triton ATMs) so the geese follow him (non-Triton ATMs transact with bogus hosts).