[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4405DF30.4020606@securescience.net>
Date: Thu Mar 2 02:22:20 2006
From: bugtraq at securescience.net (Lance James)
Subject: Re: Fedex Kinkos Smart Card Authentication Bypass
Lance James wrote:
> 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
>
Following up with a video for skeptics
http://www.securescience.net/exploits/ssc_expresspay_vuln.wmv
Thanks.
>
>
>> 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>
>>
>>
>>
>
>
>
Powered by blists - more mailing lists