Message-ID: <4405019D.7070707@securescience.net>
Date: Tue, 28 Feb 2006 18:06:21 -0800
From: Lance James <bugtraq@...urescience.net>
To: Eric B <ericboothe@...il.com>
Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: 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@...urescience.net
> <mailto:bugtraq@...urescience.net>> 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@...urescience.net <mailto:stromc@...urescience.net>
>
>

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists