full-disclosure - Sniffing RFID ID's ( Physical Security )

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Tue Jun 27 13:35:33 2006
From: Glenn.Everhart at chase.com (Glenn.Everhart@...se.com)
Subject: Sniffing RFID ID's ( Physical Security )

Every RFID that I have seen descriptions for (they're on websites for vendors!)
has a unique serial number that is manufactured in, and is designed not to be
writeable after manufacture. If someone does not use this information the part could
be "cloned" but the feature exists to block this.


-----Original Message-----
From: full-disclosure-bounces@...ts.grok.org.uk
[mailto:full-disclosure-bounces@...ts.grok.org.uk]On Behalf Of
mikeiscool
Sent: Tuesday, June 27, 2006 12:25 AM
To: Josh L. Perrymon
Cc: full-disclosure@...ts.grok.org.uk; dailydave@...ts.immunitysec.com
Subject: Re: [Full-disclosure] Sniffing RFID ID's ( Physical Security )


On 6/27/06, Josh L. Perrymon <joshuaperrymon@...il.com> wrote:
> I was contacted by Eweek recently about previous posts about RFID and how it
> is being used at the World Cup and Olympics. This got me thinking a little
> more about some previous ideas I have had. I think the real risk is in RFID
> access cards.
>
> World Cup and Olympics are / will be using embedded RFID chips in tickets to
> ID ticketholders. Upon buying the tickets patrons provide a lot of personell
> details-
>
> This is stored in a Database and I suppose a unique ID is assigned to each
> ticket holder. Now internal security can identify each ticket holder and do
> whatever they want with the data. ( ID terrorists so on, I dont care. )
>
> Risks: Not a lot here-
> As long as the ID used on the ticket is unique and not associated with
> personell details.  An attacker would have to embed an SQL injection into
> the RFID ticket or another RFID chip in their pocket to be parsed by the
> RFID reader / backend. I have't been involved in many of these systems but I
> will bet that input validation may not be built into the SDLC.  But overall,
> injecting SQL to get a remote connection may be fairly involved and take
> several attempts. But deleting the DB may be a lot easier.
>
> My ideas on RFID risk in its current implementation:
> I'm thinking a lot of the risk with RFID would be within ID cards and
> physical security. I have been in 100's of companies that use RFID ID cards
> for physical security to access a building. Just rock up and swipe your
> badge in front of the reader right???
>
> What if an attacker was sitting at the cafe downstairs sniffing RFID ( Well,
> sending out RFID signals to power the chips and get a response ). Wouldn't
> it be trivial to obtain the STATIC ID codes stored on the RFID chips and
> write them to a generic chip? THis new card could easily be used to walk
> right in  to the target company? As we all know.. once your inside it's
> trivial to root the entire network.  Just insert your usb/ CD with an
> autorun backdoor sploit connecting outside OR plug in a small wireless AP.
>
> Go back down to the coffee shop and hack away.
>
> Is anyone addressing this RFID issue for access cards? At MINUMIUM a private
> PIN# should be used with this type of ID.
>
> I'd like to hear your ideas / comments.


eh?

surely a RFID would only communicate it's private token with a trusted
(i.e. keyed) source.

like a smartcard ...


> Cheers,
>
> Joshua Perrymon
> CEO
> Packet Focus Security Research
> www.packetfocus.com
> josh.perrymon@...ketfocus.com

-- mic
 CMLRA, Mirios

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


**********************************************************************
This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you
**********************************************************************