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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BAY101-DAV21065D2C4253ECF6D8D41DE7E0@phx.gbl>
Date: Tue Jun 27 05:37:49 2006
From: drellman at hotmail.com (Saeed Abu Nimeh)
Subject: Sniffing RFID ID's ( Physical Security )



Josh L. Perrymon 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.

This was proposed here: http://www.rfidvirus.org/

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

The tag should only be revoked by a certain reader. Off the counter
readers would be able to revoke simple or non secure tags. If the tag
carries minimal symmetric or asymmetric security it would be hard to
decrypt information. However, would the organizers of WC or Olympics use
encrypted tags? I think they should if they want to stay away from
cloning or sniffing. I have proposed similar attack scenarios in loyalty
cards that are used in grocery stores to steal customer personal
information carried on the card.

Thanks,
Saeed

> 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.
> 
> Cheers,
> 
> Joshua Perrymon
> CEO
> Packet Focus Security Research
> www.packetfocus.com
> josh.perrymon@...ketfocus.com
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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

Powered by Openwall GNU/*/Linux Powered by OpenVZ