Re: Fedex Kinkos Smart Card Authentication Bypass
Eric B wrote:
> Wait, so if I read this right, consumers with existing cards could
> dupe their legit cards for fake ones and cash in the fake ones yet
> still have credit on the legit card?
>
> So I'm assuming Fedex has no database/authentication system storing
> these serials...brilliant.
>
Yup.
According to Fedex Kinko's:
"Our analysis shows that the information in the article is inaccurate
and not based on the way the actual technology and security function.
Security is a priority to FedEx Kinko's, and we are confident in the
security of our network in preventing such illegal activity."
Our response:
http://ip.securescience.net/exploits/P1010029.JPG
> Good write-up, thanks!
>
> On 2/28/06, *Lance James* <bugtraq@xxxxxxxxxxxxxxxxx
> <mailto:bugtraq@xxxxxxxxxxxxxxxxx>> wrote:
>
> Abstract:
> ---------
> The ExpressPay stored-value card system used by FedEx Kinko's is
> vulnerable to attack. An attacker who gains the ability to alter the
> data stored on the card can use FedEx Kinko's services fraudulently
> and anonymously, and can even obtain cash from the store.
>
>
> Description:
> ------------
> The FedEx Kinko's ExpressPay system, developed by enTrac Technologies
> of Toronto, Ontario, is based on a Siemens / Infineon SLE4442 memory
> chip card. The data stored on this card is freely rewritable once a
> three-byte security code has been presented to the card's security
> logic. Neither this security code nor the data stored on the card is
> encrypted; anyone able to obtain the security code is free to rewrite
> the data stored on the card using an inexpensive commercially
> available smart card reader/writer.
>
> The first thirty-two bytes of the memory chip card are writable and
> subsequently permanently write-protectable (in this application,
> these
> bytes are write-protected), and contain a header which identifies the
> card as an ExpressPay stored-value card. Bytes 0x20 through 0x27
> contain the value stored on the card, represented in IEEE 754
> double-precision floating point format. Bytes 0x60 through 0x6A
> contain the card's eleven-digit serial number stored as unsigned
> zoned-decimal ASCII; digits 0x60 through 0x63 are the store number the
> card was initially issued at, and the remaining seven digits are
> assigned sequentially at the moment of first issue. A timestamp
> indicating date and time of issue are located from 0x30 through 0x37,
> and is repeated from 0xC7 through 0xCE.
>
> In order to write to the card, a three-byte security code must be
> presented in a specific sequence of commands as outlined by the
> SLE4442's white paper. By soldering wires to the contact points of
> the card and then connecting those wires to an inexpensive logic
> analyzer, an attacker can sniff the three-byte code as the kiosk or a
> card terminal prepares to write data to the card. This security code
> appears to be the same across all FedEx Kinko's ExpressPay cards
> currently in circulation.
>
> Once the three-byte code is known to the attacker, the card's stored
> value and serial number can be changed to any value. The ExpressPay
> system appears to implicitly trust the value stored on the card,
> regardless of what that value actually is. The system will also
> accept cards with obviously fake serial numbers (e.g. a non-existent
> store number followed by all nines). Using these altered cards,
> xeroxes can be made from any machine with a card reader, and computers
> can be rented anonymously and indefinitely. Most disturbing, however,
> is that since stored-value cards can be cashed out by an employee at
> the register at any time, an attacker could cash out altered cards
> obtained at little or no monetary cost. If a card is cashed out, its
> serial number does not appear to be invalidated in the system. If an
> attacker were to clone a known good card and cash it out, the clone
> would still be usable.
>
>
> Tested Vendors:
> ---------------
> - FedEx Kinko's
>
>
> Suspected Vendors:
> ------------------
> - Any client of enTrac Technologies who uses the ExpressPay
> stored-value card system.
> - Any company which uses a stored-value card system based on the
> SLE4442
>
>
> Vendor and Patch Information:
> -----------------------------
> Proof-of-concept of the initial security vulnerability was
> achieved on
> 8 February 2006, with research into the ramifications continuing
> through 12 February. Copies of this report were sent to both FedEx
> Kinko's and enTrac Technologies on 15 February; a read receipt was
> returned from enTrac on 19 February, while no receipt has yet been
> received from FedEx Kinko's.
>
>
> Solution:
> ---------
> - Encrypt data before storing it on the SLE4442 card, or migrate to a
> system which uses cards which have built-in encryption functionality.
> - Verify that the stored value on the card does not significantly
> differ from a reference value stored in a database.
> - Do not allow the use of cards with invalid serial numbers.
> - Invalidate serial numbers of cards that are cashed out.
>
>
> Credits:
> --------
> Strom Carlson, Secure Science Corporation: Hardware Security Division
> stromc@xxxxxxxxxxxxxxxxx <mailto:stromc@xxxxxxxxxxxxxxxxx>
>
>