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@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> >> >> >> > > >