Slashdot Mirror
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.'"
Hang on a minute, in this case the tag is not the problem.
It is the software running on the host machine which does not validate the data coming from the tag that has major issues.
If I can corrupt a database by entering an invalid lookup code then theres something severely fucked up.
My bet is its something like the sql injection attacks we see on the web, and you don't see people blaming the input box in those cases.
quote from the article:
In some cases, said the researchers, viruses could be spread by household pets such as cats and dogs that are injected with the tags to help identify their owner.
The pets aren't going to be spreading this "virus" themselves its not sexually transmitted, it cannot be passed by rubbing up against your leg. It will be the vets computer which gets infected because of crappy validation.
MEOOOOOOOOEEEEEEEEOOOOOOOOOOOWWWWWWWWWWWWW!
Charlie says: always validate your external inputs before doing any data processing.
Smart tags, dumb research.
(and thats coming from someone who doesn't like RFID)
liqbase
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.
http://virtualize.wordpress.com/
It is the software running on the host machine which does not validate the data coming from the tag that has major issues.
Absolutely. This is just like the Windows JPEG "virus" that was due to buggy JPEG parsing. Describing RFIDs as an attack vector is appropriate, but inert data can not be a virus. You typically don't execute images or identification information. Perhaps there needs to be some catchy name for this type of attack, but really it's just a new example of the common overflow bug.
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.
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!!!
7h3$3 4r3n'7 7h3 Ðr01Ð$ ¥0 4r3 £00|{1n9 f0r. M0v3 4£0n9. --OB1
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.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
This is a good example of how people will sometimes trust data that isn't trustworthy at all.
I'd be willing to bet that someone with enough cleverness and free time could come up with a 'credit card virus' that could compromise specific vulnerable payment systems/credit card processing devices when swiped. For all we know, there may already be such exploits out there now. At least in the case of credit card processing, it's financial code so hopefully there are some stringent security processes along with multiple layers of verification, but still - pretty scary to think about.
using namespace slashdot;
troll::post();
Brockman: Big game fever is reaching a fever pitch as the
fevered rivalry between Springfield U. and
Springfield A&M spreads like wildfever. [looks
offstage] This is writing?
Intern: I'm sorry Uncle Kent; I lost my thesaurus.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
As much as I distrust RFIDs, and as much as I detest the way they are being used, this is a problem of the backend, not the RFID itself. It's an ancient problem of databases with data injection that has been used for years now, on the internet, to inject data into online databases or to mess with them generally.
It's not really new news either. I think I remember that report from about a year ago when RFIDs in our passports became an issue and Tanenbaum raised those concerns. So is this something new or do the old news get repeated for a lack of anything new?
Must be summer, all the politicians are on holiday...
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
I think the point of the research is that many RFID tags are read by closed or theortically isolated systems like inventory control devices and pet identity scanners that probably have not been examined for the kinds of vulnerabilities that we (theoretically) look for Internet accessible servers.
While we have a mediocre system for updating Internet-based applications in the face of vulnerabilties, the prospect of updating piles of non-Internet accessible devices is indeed an issue.
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
davecb@spamcop.net
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.
Oh, a lesson in history from Mr. I'm my own grandpa.