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.

<br><br>Good write-up, thanks!<br><br><div><span class="gmail_quote">On 2/28/06, <b class="gmail_sendername">Lance James</b> &lt;<a href="mailto:bugtraq@securescience.net">bugtraq@securescience.net</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Abstract:<br>---------<br>The ExpressPay stored-value card system used by FedEx Kinko's is<br>vulnerable to attack.&nbsp;&nbsp;An attacker who gains the ability to alter the<br>data stored on the card can use FedEx Kinko's services fraudulently

<br>and anonymously, and can even obtain cash from the store.<br><br><br>Description:<br>------------<br>The FedEx Kinko's ExpressPay system, developed by enTrac Technologies<br>of Toronto, Ontario, is based on a Siemens / Infineon SLE4442 memory

<br>chip card.&nbsp;&nbsp;The data stored on this card is freely rewritable once a<br>three-byte security code has been presented to the card's security<br>logic.&nbsp;&nbsp;Neither this security code nor the data stored on the card is<br>encrypted; anyone able to obtain the security code is free to rewrite

<br>the data stored on the card using an inexpensive commercially<br>available smart card reader/writer.<br><br>The first thirty-two bytes of the memory chip card are writable and<br>subsequently permanently write-protectable (in this application, these

<br>bytes are write-protected), and contain a header which identifies the<br>card as an ExpressPay stored-value card.&nbsp;&nbsp;Bytes 0x20 through 0x27<br>contain the value stored on the card, represented in IEEE 754<br>double-precision floating point format.&nbsp;&nbsp;Bytes 0x60 through 0x6A

<br>contain the card's eleven-digit serial number stored as unsigned<br>zoned-decimal ASCII; digits 0x60 through 0x63 are the store number the<br>card was initially issued at, and the remaining seven digits are<br>assigned sequentially at the moment of first issue.&nbsp;&nbsp;A timestamp

<br>indicating date and time of issue are located from 0x30 through 0x37,<br>and is repeated from 0xC7 through 0xCE.<br><br>In order to write to the card, a three-byte security code must be<br>presented in a specific sequence of commands as outlined by the

<br>SLE4442's white paper.&nbsp;&nbsp;By soldering wires to the contact points of<br>the card and then connecting those wires to an inexpensive logic<br>analyzer, an attacker can sniff the three-byte code as the kiosk or a<br>card terminal prepares to write data to the card.&nbsp;&nbsp;This security code

<br>appears to be the same across all FedEx Kinko's ExpressPay cards<br>currently in circulation.<br><br>Once the three-byte code is known to the attacker, the card's stored<br>value and serial number can be changed to any value.&nbsp;&nbsp;The ExpressPay

<br>system appears to implicitly trust the value stored on the card,<br>regardless of what that value actually is.&nbsp;&nbsp;The system will also<br>accept cards with obviously fake serial numbers (e.g. a non-existent<br>store number followed by all nines).&nbsp;&nbsp;Using these altered cards,

<br>xeroxes can be made from any machine with a card reader, and computers<br>can be rented anonymously and indefinitely.&nbsp;&nbsp;Most disturbing, however,<br>is that since stored-value cards can be cashed out by an employee at<br>

the register at any time, an attacker could cash out altered cards<br>obtained at little or no monetary cost.&nbsp;&nbsp;If a card is cashed out, its<br>serial number does not appear to be invalidated in the system.&nbsp;&nbsp;If an<br>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.

<br>- Any company which uses a stored-value card system based on the SLE4442<br><br><br>Vendor and Patch Information:<br>-----------------------------<br>Proof-of-concept of the initial security vulnerability was achieved on

<br>8 February 2006, with research into the ramifications continuing<br>through 12 February.&nbsp;&nbsp;Copies of this report were sent to both FedEx<br>Kinko's and enTrac Technologies on 15 February; a read receipt was<br>returned from enTrac on 19 February, while no receipt has yet been

<br>received from FedEx Kinko's.<br><br><br>Solution:<br>---------<br>- Encrypt data before storing it on the SLE4442 card, or migrate to a<br>system which uses cards which have built-in encryption functionality.<br>- Verify that the stored value on the card does not significantly

<br>differ from a reference value stored in a database.<br>- Do not allow the use of cards with invalid serial numbers.<br>- Invalidate serial numbers of cards that are cashed out.<br><br><br>Credits:<br>--------<br>Strom Carlson, Secure Science Corporation: Hardware Security Division

<br><a href="mailto:stromc@securescience.net">stromc@securescience.net</a><br><br></blockquote></div><br>