Virus Jumps to RFID

MrShaggy writes "According to a BBC article, researchers have been able to make the jump between RFID tags and viruses. They found that the mere act of scanning a mere 127 bytes could cause an attack vector that would corrupt databases. From the article;'"This is intended as a wake-up call," said Andrew Tanenbaum, one of the researchers in the computer science department at Amsterdam's Free University that did the work revealing the weaknesses on smart tags. "We ask the RFID industry to design systems that are secure," he said.'"

Comments

Correction on the University name

[MartijnL]

The University is called the "Vrije Universiteit" or VU for short ( http://www.english.vu.nl/home/index.cfm/ ). Which is not "Free as in Beer". It also didn't stand for Free as in: open for everyone. That didn't come along until the 1960's.

Erm

[LordPhantom]

2 words - Input Validation

This article can be summed up in the following sentance:

OH NO! Anyone can put ANYTHING on a tag that might be read by database software! Horrors!

C'mon people, this is basic data security 101 - never trust inputs without validation. This isn't a problem with insecure tags, it's a problem with import software/database code.

#ERROR

[Doomedsnowball]

I can see premade RFID tags containing SQL code being sold on eBay. Lower your grocery store prices, evade background checks, travel anonymously, use VIP entrances, ignore 'Authorized Personnel' signs! This is total FUD. The database equivalent of believing everything you hear. If there is no authenticating, then it's no surprise that there could be malicious hacking. The real story is that if it is possible to have a single binary check system, someone could change their Zero value to a One to defeat it.
Noooooooooooooooooo!!!

read only

[Lord Ender]

So a specially-crafted RFID tag could cause code to execute on a vulnerable RFID reader. That's not a virus. But if this code causes the RFID reader to begin writing copies of the bad data to tags, then we have a virus.

But read-only RFID tags and RFID readers are much cheaper than the writable kind, so this is not very practical. And RFID tags typically can't hold bit strings which are long enough to contain useful software. So, again, this is a bit silly.

Re:read only

[Peter Mork]

"So a specially-crafted RFID tag could cause code to execute on a vulnerable RFID reader. That's not a virus. But if this code causes the RFID reader to begin writing copies of the bad data to tags, then we have a virus."

The real article (not the lame BBC article) describes how to construct a self-replicating virus that copies itself to RFID tags as they are written. They also describe how to create RFID worms. The attack vectors are basically SQL injection, cross-site scripting, and buffer overflows.

Re:FUD?

[DrSkwid]

You have totally missed the point.

I walk up to the reader with a crafted RFID and infect the database.

This is "I can to read ANYONE's card" not "anyone can read MY card".

Bit obvious really : "don't trust random stranger's data" - Film at 11

Re:FUD?

[LiquidCoooled]

If the tag data is expected to be an alphanumeric code to represent the customer: Slashdot_LiquidCoooled_634315

this can be used (incorrectly) to produce a raw piece of SQL:

select * from Customers where Code='Slashdot_LiquidCoooled_634315'

if that code contains quotes and they are not being handled correctly then it is certainly possible to corrupt the database.

Suppose my RFID was programmed with something like this and it was not being validated correctly:

'; Drop table [customers];

The resulting SQL could end up something like:

select * from Customers where Code=''; Drop table [customers];'

bye bye customers table (if permissions set at defaults and the wind is blowing your way)

oh no!

[joe 155]

well these people weren't the first to do this, nor will they be the last. I first read about this on the 15th of March, and the malware itself has been publically available since then... it's all in the register article, here: http://www.theregister.co.uk/2006/03/15/rfid_tags_ infected_by_virus/

The full article -- it's legit

[davecb]

There is a PDF and also a complete discussion at http://www.rfidvirus.org/virus.html, breifly outlining "Replication Using Self-Referential Queries" and "Replication Using Quines".

For example,
Database systems usually offer a way to obtain the currently running queries for system administration purposes. However, these functions return queries as an normal string, which makes it possible to store them in the database, thereby replicating the query.

We have developed two versions of the virus, one that is contained in a single query, and one the requires multiple queries. The virus using a single query requires less features from the database, but cannot carry SQL code as a payload. The virus using multiple queries requires a database that supports this, but it does allow SQL code as a payload.

Details on the virus using self-referential queries can be found athttp://www.rfidvirus.org/exploits/sql_self/index .html

Completely Innacurate

[Philodoxx]

First off this is basically a dupe of http://it.slashdot.org/article.pl?sid=06/03/15/132 4233. It was innacurate when it was first reported and it's innacurate now.

Here is my reply from the original post and it applies here:

"There are a variety of standards on how RFID tags are encoded, all of which break down into partitioning the tag's data into segments to form the unique identifier

For the sake of argument I'll use EPC SGTIN96. In the SGTIN tag has four partitions: Filter, Company Prefix, Item Reference, and Serial Number. Each of these fields is of varying size depending on how big tag is. Typically RFID tags are 96 bits (although some tags can get up to 1Kbit), even using 7 bit ascii there's not a whole lot you can fit in 96 bits. When I poll the reader, or the middleware I'm getting back a number, e.g. 12345 and it's my responsibility to parse through that number to get the fields I'm interested in. In this scenario I would have to be doing some *very* sloppy programming to open myself to an SQL injection attack (something along the lines of treating known numeric data as a string).

ISO and EPC Gen 2 tags do support custom data, which I suppose could be used to store strings but since it is severely space constrained (typically in the range of 2-32 bytes) I question the viability of such an attack. Not to mention that the field will likely be used to writing in ids instead of human readable data. Finally, it is common to encrypt the custom payload on an rfid tag. So even if somebody were to change it to "AND 1 = 1" it would be caught when the program tries to decrypt the tag."

An RFID tag contains just a number; newer RFID tags have support for custom payload but 99% of RFID tags are so space constrained that nobody would put raw strings in the tag. I spent a good chunk of last year devleloping RFID applications and not once did I do a straight lookup on the database from data I pulled from the RFID tag. So while I guess this classifies as a vulnerability somebody who does straight database lookups using RFID tag data will bring down the company long before an RFID tag exploit will.

Not really possible on modern RFID systems.

[510madness]

Unless I missed something obvious (happens), I don't think this is a serious issue...

1) Most malicious SQL statements (i.e ";DELETE FROM USERS;") require more than 64-96 bits, the current standard for RFID tags.

2) Any RFID software system that is compliant with EPCglobal's Tag Data Specification (http://www.epcglobalinc.org) is inherently "immune" to this issue. The TDS spec defines several tag formats for use in software systems that require the tag's binary data to be in hexadecimal or decimal format and futhermore treated as a URI. e.g. urn:epc:raw:64.1234567890. Simply encoding a tag with ";DELETE FROM USERS;" will not cause any damage in an EPCglobal-compliant RFID system because the binary data read from the tag is never used in ASCII format, just decimal and hex.

3) Futhermore, the TDS specifies exactly which bits are to be used for various 'fields' such as 'company', 'item', 'serial number' etc. Most RFID systems perform operations on each field seperately, so any SQL statement would be broken up; ";DELETE FROM USERS;" could become something like ";DELE"."TE FROM"." USERS;". Again this doesn't matter so much because the data is never used in ASCII format, only Hex/Decimal.

In English....

ASCII: ";DELETE FROM USERS;"
Binary: 001110110100010001000101010011000100010101010
100010001010010000001000110010100100100111101
001101001000000101010101010011010001010101001
00101001100111011 (153bits, impossible to fit on Gen1 tags!)
Decimal: 59686976698469327082797732858369828359
URI: urn:epc:raw:153.5968697669846932708279773285836982 8359

As you can see, the URI form of the tag is pretty harmless. :)