Slashdot Log In
Virus Jumps to RFID
Posted by
Hemos
on Mon Jul 17, 2006 10:30 AM
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.'"
Related Stories
[+]
Ask Slashdot: Would You Trust RFID-Enabled ATM Cards? 214 comments
race_k2 asks: "As a regular Slashdot reader I've followed the development and implementation of RFID devices in many ubiquitous areas such as clothing, passports and even people. Given that our environment is becoming increasingly tagged, often without our knowledge or consent, and can be monitored or hacked by anyone with the proper hardware, skills and motivation, I viewed the recent arrival of two new ATM cards containing RFID chips with skepticism. While this feature may bring the increased convenience of speedy checkouts, it is not something I am completely comfortable using and decided that the safety of my personal data was more important than the ability to buy things quickly. The vulnerable nature of RFID security coupled with recent, though unrelated, reports of a Possible Security Flaw In ATMs make me seriously question whether the marriage of wireless data transfer with personal finance is a wise application of technology." So race's question basically boils down to: How safe and secure are the RFID chips that are being embedded in debit and credit cards? To add another issue on to the fire: Would you trust RFID technology on your cards?
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
FUD? (Score:5, Insightful)
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)
Re:FUD? (Score:5, Insightful)
Parent
Re:FUD? (Score:4, Interesting)
The trouble with RFID is that anyone scanning can pick up your tag without you knowing about it. This includes secure and non-secure software. If 99% of software reading these tags are secure, there is still that 1% that isn't and you wouldn't know that it picked up your personal info until you get the bogus credit card bills in the mail.
Parent
Re:FUD? (Score:4, Informative)
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
Parent
Re:FUD? (Score:2)
Re:FUD? (Score:5, Informative)
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)
Parent
Re:FUD? (Score:2)
In java (and hey, could be similar with RoR, etc), you write your web tier stuff to a middleware layer. There, we use Hibernate and HQL. That sort of crap 'just wouldn't parse' in HQL or criterion queries, as it would not be a valid parameter for "?".
Heck, even writing SQL, why aren't you writing parameterized prepared statements? Doesn't that also make you immune to this sort of crap?
"Select * from customers where Code = ?"
setParam(1, myCraptasticUntextedVariable)
Like the JPEG "virus" (Score:5, Interesting)
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.
Parent
Re:Like the JPEG "virus" (Score:4, Insightful)
How's about "programmer dumbass attack"? Seems quite apt, to me. Any programmer worth his salt knows that he has to check for invalid data, yet so many software developers (both open source and closed source) let code go to production levels that fails to perform even the most basic of validations.
Maybe we need to send a bunch of programmers back to basic training! "Security boot camp"! Only let's make it real tough: make them all write basic currency conversion programs and for every piece of invalid data that makes it through without being validated, that program's author loses a finger! That'll teach 'em!
Parent
Re:Like the JPEG "virus" (Score:5, Insightful)
Inert data can certainly be a virus: that's especially true in biology, where the entire virus metaphor arose in the first place. After all, virus is an piece of inert genetic data. When in contact with a live host, it alters the behaviour of the host; but without a host system to carry it, viruses are inert. Some people like to characterize them as the boundry case between "living" and "non-living": they're an inert substance that alter living beings in a self-replicating way to make more of themselves; in that sense, they "reproduce", despite not being "alive".[1]
As for your original point, you're right that it's probably not correct to call RFID tag exploits "viruses": but not because viruses are inert. It's because the RFID virus is not being copied on by the host system it contacts; although, it sounds like it should be possible to craft a virus that does, assuming you could infect the RFID code writing software.
--
AC
[1] People debate terms like "alive", "dead", "reproduce" for hours on end, until they realize they're arguing over definitions, which by definition is pointless....
Parent
Re:Like the JPEG "virus" (Score:3, Funny)
No it isn't.
Re:Like the JPEG "virus" (Score:4, Insightful)
How about "poison" instead of "virus", since its presence may cause illness or death but does not self replicate. As in "attackers injected poison RFID tags into system, which is now inoperable until repairs are made."
Parent
Re:FUD? (Score:2, Insightful)
Re:FUD? (Score:5, Insightful)
"We ask the RFID industry to design systems that are secure"
If the "RFID industry" creates the reader software as well, and if the vulnerability is in that reader software (which is what it sounds like), then the criticism is perfectly valid.
FTA:
""Everyone working on RFID technology has tacitly assumed that the mere act of scanning an RFID tag cannot modify back-end software and certainly not in a malicious way. Unfortunately, they are wrong," wrote the trio in their research paper."
and
"The researchers urged companies working on RFID systems to start thinking seriously about security measures to protect against future threats."
No one's really saying the tags are inherently insecure, any more than they might say that a floppy disk or a CD are insecure. If the reader software currently has many vulnerabilities, no matter how obvious it might seem in hindsight, this seems like valuable research to me.
Parent
Re:FUD? (Score:3, Insightful)
If the reader software currently has many vulnerabilities, no matter how obvious it might seem in hindsight, this seems like valuable research to me.
No hindsight required. Any programmer not validating input, particularly from an untrusted source, is simply incompetent.
This isn't "research" as such, merely exposure of incompetents.
The fact that RFID is the vector is irrelevant. Though if the programmers and testers were this incompetent with something as simple as RFID data I hate to think how badly
Re:FUD? (Score:2, Insightful)
Who said the lookup code had to be invalid? Simply broadcasting a valid signal for a product would be sufficent to corrupt the database. You can trick inventory systems into thinking they have 500,000 razor blades, when they only have 100,000.
Is it data, or is it code? (Score:2, Insightful)
The minute you start interpreting data you have to treat it as potentially hostile. This goes for computers AND people. There's not much difference between a "hostile" data-set that the attacker knows will be interpreted as SQL code that he can use to corrupt an automated-supply-ordering system, a hostile data set that the attacker knows will be interpreted as a false we-are-low-on-inventory-order-more or we-ha
Re:Is it data, or is it code? (Score:2)
If you merely store and read data - ANY DATA - and do not interpret it, it cannot carry a virus.
Storing is enough to enable a buffer overflow, which is enough to make the payload active
Re:FUD? (Score:2)
Good thing this was not in the US (Score:3, Insightful)
They could have been sued for violation of the DMCA. We don't want any weaknesses exposed by researchers in the early stages... we'd rather have them exposed maliciously after its too late!
http://religiousfreaks.com/ [religiousfreaks.com]Re:Good thing this was not in the US (Score:3, Interesting)
While I doubt that anyone would have been charged for this in the USA, I agree that the DMCA hampers some meaningful research. To be fair, however, all this project did was prove something that most of us could have figured out on our own: GIGO!
Correction on the University name (Score:3, Informative)
Re:Correction on the University name (Score:2)
Makes me kind of glad (Score:2, Interesting)
I, for one, would rather not have electronics malfunctioning in my body. Sometimes I have a hard enough time just k
Erm (Score:5, Informative)
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.
Re:Erm (Score:2)
#1 - "Virus" implies code that can be executed to create a security breach.
#2 - Incorrect Data (what you're talking about). There are ways around this problem, but the article is talking about using the very small amount of data that can be stored on RFID chips as a vector for attack on the software/database it is stored in, and the above comment applies to this.
#ERROR (Score:4, Informative)
Noooooooooooooooooo!!!
read only (Score:4, Informative)
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 (Score:3, Informative)
"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 [rfidvirus.org] (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.
oh no!! (Score:3, Funny)
Re:oh no!! (Score:2)
I'm sorry Uncle Kent; I lost my thesaurus (Score:4, Funny)
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.
Parent
What about other forms of external data? (Score:4, Insightful)
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.
oh no! (Score:3, Informative)
Not a RFID problem, more a database flaw (Score:4, Insightful)
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...
A mere 127 bytes? If only they had more (Score:2, Insightful)
Re:A mere 127 bytes? If only they had more (Score:3, Funny)
Considering Andy Tannenbaum is involved, I imagine they would probably port Minix to it.
No expects an RFID tag to send a SQL injection... (Score:3, Interesting)
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.
The full article -- it's legit (Score:5, Informative)
There is a PDF and also a complete discussion at http://www.rfidvirus.org/virus.html [rfidvirus.org], 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
Maybe they're trying to hide the real problems (Score:3, Interesting)
The real security issue is that it's trivial to clone an RFID tag. Using it for identification is like using a piece of paper that can be photocopied, except that the attacker doesn't have to swipe the paper to copy it. But if people only think about the non-fundamental and insignificant flaws with RFID, they can be distracted from the fact that it's entirely inappropriate in the first place.
Where can I get one of these? (Score:2)
I really want to know, though, where can I get just such a "viral" RFID tag to stick to the inside cover of my passport?
I just need to wrap the real passport in a modified tinfoil beanie, put the fake one on the outside of the beanie, and laugh heartily as people scan me and then go white in horror at the realization of what they just did to themselves. Bwa-hahahah!
/ only half kidding - I'd do this in a heartbeat if I had the hardware to program my own tags.
Completely Innacurate (Score:4, Informative)
First off this is basically a dupe of http://it.slashdot.org/article.pl?sid=06/03/15/132 4233 [slashdot.org]. 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.
"The" Andrew S. Tannenbaum (Score:2, Insightful)
Personally, I would not have posted that article without attaching these links. Tannenbaum is a key player in modern computer science research and education.
Check out his homepage [cs.vu.nl]
and his Wiki [wikipedia.org] biography.
Not really possible on modern RFID systems. (Score:2, Informative)
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
How to hack the system (Score:2)
Sorry, I do not care if you say who you are. The computer who checks the RFID in your passport is telling me to put you under arrest and transport you to Guantanamo. Yes, I know that the same happend to anybody with a passport that has an RFID.
Tag data no different than web input boxes. (Score:2)
The Java application I work on uses prepared statements, and according to the Java specs, input data are checked for invalid SQL...therefore code injection is not possible.
I assume other frameworks will offer similar techniques.
Just think of all of the evil things you could do. (Score:2)
Re:Old News... (Score:2)
Re:Hillarious (Score:2)
This may explain why I keep finding Petsmart price lists and my Phidgets RFID Kit next to the cat food bowl.
Re:Bad news (Score:2)