RFID Chips and Viruses

Of course RFID chips can carry viruses. They’re just little computers.

More info here. The coverage is more than a tad sensationalist, though.

EDITED TO ADD (3/16): I thought the attack vector was interesting: a Trojan RFID attacks the central database, rather than attacking other RFID chips directly. Metaphorically, it’s a lot closer to biological viruses, because it actually requires the more powerful host being subverted, and there’s no way an infected tag could propagate directly to another tag.

Tags: computer security, databases, malware, RFID, smart cards

Posted on March 16, 2006 at 6:55 AM • 34 Comments

Comments

Clive Robinson • March 16, 2006 7:19 AM

I guess by now that it’s no little supprise that any micro based system can carry viruse or other malware code.

What is still surprising is the “technology first” rush about getting a product to market place without taking due precaution to prevent malware getting into a product with a programable micro built in…

The thought occurs about SmartCard / RFID Pasports and other ID card systems, after all whats to stop a virus getting in that makes everybody “Joe Doe” of “1600 Penselvania Ave”…

MathFox • March 16, 2006 7:55 AM

I am not aware of anything that will stop the destruction or modification of information on the RFID chip in a passport.

The obvious fall back method of having an immigration officer perform a visual inspection of the document has been working for decades.

kashmarek • March 16, 2006 8:14 AM

Why would an RFID chip need to be writable? It should be programmed once, and then only output its information thereafter. By making it writable (or having the ability to be changed), you make it worthless for its intended purpose.

Dave Engberg • March 16, 2006 8:18 AM

I think that “little computers” is a red herring. An RFID tag can carry a virus in the same way that a floppy disk can carry a virus. Some tags have persistent read/write storage, and this can carry data. Poorly written apps (NOT running on the RFID tag itself) could process this data incorrectly in a way that causes that app to execute it as code.

Of course, a paper 2D bar code could trigger the same virus, but this is too retro for newsworthy kneejerking.

stacy • March 16, 2006 8:28 AM

“Of course, a paper 2D bar code could trigger the same virus, […]”

RFID does make it easier; I can build an RFID transmitter with a high gain antenna and inject the virus from a distance. You can’t do that with bar code. The proposed British RFID number plate system comes to mind as a prime target.

Jim Hyslop • March 16, 2006 8:38 AM

@Clive:

Why do you find that surprising? We’re in a free-enterprise system, where the main goal (some would say only goal) is to make money. You can’t make money if someone else gets their product out first.

The dominance of marketing over technology has proven that point again and again.

Clive Robinson • March 16, 2006 8:58 AM

@Stacy

Actually the Transport For London Oyster card strikes me as a realy good target. As far as I am aware it is still the worlds largest MIFare card system in actual deployment (uses the 13.56 ISM band RFID’s speced by SchlumbergerSema etc).

As it is used for buying and using transport tickets the RFID has to be modifiable at all times (otherwise the off line hand held units would not work) TfL are also pushing it for Newsagent and other Kiosk type sales.

Now if you put a time delayed virus in your card and went through every major London Railway Station in one day (there’s around 14 you would need to visit) then just about every commuter with an Oyster card would be infected over the next day or to…

It could make life in London hell for the 6-7 million journes made each day

Clive Robinson • March 16, 2006 9:05 AM

@Jim Hyslop

For exactly the reason given by you.

This behaviour is so endemic and has been repeatedly questioned in the ordinary press as criminally stupid, that I cannot see any company standing up in a court and saying they where not aware of the problem. So they are not performing due diligence, and their product is likewise not fit to market.

Only problem is how do you get them into court and get a good result (for the consumer).

Maybe Insurance companies should refuse to give them product liability cover which should make quite a few companies think twice.

Kees Huyser • March 16, 2006 9:08 AM

Geoff Marshall holds the official world record for shortest time to visit every station on the Tube network -18 hours and 35 minutes. Just infect his RFID card 🙂

1915bond • March 16, 2006 9:14 AM

@kashmarek:

I concur. While it may be convenient to alter the info on an RFID, it would be better to just replace it. Class 0 (Read Only) is for pre-programmed tags, and Rewritable Class 0 (Class 0+) is for those who want to program the tags themselves (from http://www.impinj.com/page.cfm?ID=rewritableClass0). Kinda reminds me of all the insanity surrounding Y2k and embedded systems.

Janne Jalkanen • March 16, 2006 9:17 AM

If I read the article correctly, they wrote specific middleware that is vulnerable to SQL Injection attacks, and then put simple ASCII text on the tags, and showed that their badly-designed middleware is susceptible to these attacks. Then they proceeded with the logical leap that this means that RFID systems in general can carry viruses. To me that is setting up a straw-man argument, especially considering the fact that they are not able to point to a single real-world implementation that would be vulnerable to this attack.

This is exactly like saying that “URLs can carry viruses”, since there is a remote possibility that someone writes bad middleware that just treats the query string as something to be directly inserted into an SQL sentence. There is nothing RFID-specific in this particular attack.

Of course there are stupid, bad and dangerous implementations out there. But saying that it’s RFID’s fault is exaggeration, and just riding on the “RFID is evil” -wave.

There are real issues involved in deploying RFID, and this is not helping in figuring those out…

1915bond • March 16, 2006 9:19 AM

I would add that IMO the real threat is as stated: injecting malicious code into middleware via a rogue tag.

stacy • March 16, 2006 9:21 AM

@Clive Robinson

“As it is used for buying and using transport tickets the RFID has to be modifiable at all times (otherwise the off line hand held units would not work)”

Stored value RFID? Combine that with the information that came out about Kinko’s stored value card (http://www.schneier.com/blog/archives/2006/03/fedex_kinkos_pa.html) and what do you get? Free transit. I sure hope they have some fraud detection built into the online part of the system.

Davi Ottenheimer • March 16, 2006 10:20 AM

“You can’t make money if someone else gets their product out first.”

Are you serious? That’s a bit counter-intuitive since you might not make the same amount of money in the same time-frame, but as someone who improves on something you can certainly make some money.

Some might say you can even make more money if you release your product later, but with better marketing and less overhead (e.g. fewer flaws and retrofits). The iPod, for example, certainly was not the first personal MP3 player to hit the market, and Apple would have made even more money had they resolved the quality issues prior to launch.

SayWhat • March 16, 2006 10:25 AM

I agree with the previous posters that rewrittable RFID is ridiculous. Its no wonder we have insecure systems, the people designing them are idiots!

RFID tags are used as “throw away” (write once read many) devices in all the implementations I have seen (i.e. inventory, passports, etc.). There is no reason the RFID would ever need to be rewritten after it is originally programmed. In fact, in all these applications, being able to rewrite an RFID after it is initially programmed would compromise the integrity of the data the RFID is representing. In these applications, why would you ever need the RFID to be rewrittable. It should be write once read many, period.

This is especially true for applications like a passport. Having a rewrittable RFID in a passport is like having the ID information on the paper part of the passport written in pencil and the picture as a removable sticker. Just like the paper part, the RFID must be unalterable after it is programmed. If changes are needed, a new paper passport document with new write-once-read-many RFID must be issued.

Now, on the original post, write-once-read-many RFIDs won’t protect against poorly written middleware from getting infected from malicious RFIDs, but it would prevent other RFIDs from getting modified and infected from corrupted middleware.

Seems simple.

Bob • March 16, 2006 10:30 AM

“You can’t make money if someone else gets their product out first.”

The early bird may get the worm, but the second mouse gets the cheese.

Just because you are first in doesn’t mean you will reap the reward!

Davi Ottenheimer • March 16, 2006 10:37 AM

“Why would an RFID chip need to be writable?”

Cost. You can save money if you can alter the data instead of replacing the chip, although this obviously has to be weighed against data integrity control issues.

Functionality. RFID can be a very convenient way to keep records with an item such as checkin/out, maintenance, status, etc. and potentially less prone to error than human/manual entry.

Incidentally, someone once told me a story about the first US military-issue chip-based badges that were issued. They had a write-once strategy but included a user email address on the chip. Unfortunately this meant a new badge had to be issued every time an email address changed, which turned out to be far more often than anyone expected and so budgets were thrown way off the mark as the write-once cards were in a constant state of change/destruction.

Fred Page • March 16, 2006 11:02 AM

Odd that you don’t link to the paper:

“Is Your Cat Infected with a Computer Virus?”

http://www.rfidvirus.org/papers/percom.06.pdf

Davi Ottenheimer • March 16, 2006 11:19 AM

@ Fred

Interesting paper, but Bruce discusses squid, not cats.

I noted that their recommendations were similar (if not identical) to the usual suspects in app security:

1) boundary checking
2) input validation
3) turn-off unnecessary services
4) least-privilege / role-based access
5) parameter binding (see #2)
6) isolate the servers (see #4)
7) code-review

Nothing surprising, really. And I did not see anything that said RFID should be restricted to WORM (pun not intended).

Fred Page • March 16, 2006 11:40 AM

@Davi

Sorry; I’ll ask Rieback, Crispo and Tanenbuam to keep that in mind for their next paper next time I chat with them 🙂

Clive Robinson • March 16, 2006 11:50 AM

If anybody is interested in the Transport For London Oyster Card and how it came to be have a look at,

http://rfid.idtechex.com/knowledgebase/en/casestudy.asp?freefromsection=122

The last part about Stored Value Card (SVC) should make ripe pickings for fraudsters if the system is allowed to be used “off line” as it would appear the only security for lost/stolen cards is to send out a revocation list of stolen IDs (a bit like the old Credit Card Hot list).

Clive Robinson • March 16, 2006 11:56 AM

@Davi

IF done properly then there is no reason for the cards to be Read Only.

However it then falls down to flexability of the system. If you asume a central write authority with secure machines then any authentication system (within reason) should be sufficient.

However if you have either OffLine or machines where the security is not gaurenteed then you do have problems. And that’s when it starts getting expensive to implement properly, and cost cutting starts taking over, usually without a Risk/Benifit analysis…

Ho Hum I guess the accountants will inherit the earth 😉

another_bruce • March 16, 2006 12:11 PM

in the coming era of automated checkout when shoppers will take goods past an rfid reader for an automatic debit to their bank card, a crook will be able to take a reader into a store and infect those tags so that every one carried past the store’s reader results in an automatic credit to the bank card instead. this will put a whole new face on shoplifting.

1915bond • March 16, 2006 12:29 PM

@Clive

Not that it is pertinent to the discussion, but I find it amusing that the source photo associated with the Transport for London Oyster card UK is clearly from an American roadway.

kashmarek • March 16, 2006 3:33 PM

When they made RFID cards writtable, they failed to put into place the protections that should go with such change. This puts all existing use at risk, including our soon to be federal ID card, passports, and incantations of RFID in credit/debit cards. Cost cutting measure…ha! Wasted investment. Who is going to fix this, or worse yet, pay for the mistake?

kashmarek • March 16, 2006 3:34 PM

Roger • March 16, 2006 7:30 PM

@Davi:

Unfortunately this meant a new badge had to be issued every time an email address changed,

They hadn’t heard of .forward ?!?

@Jim Hyslop:

You can’t make money if someone else gets their product out first

Actually, this is a common myth, or at least misunderstanding. The so-called “first mover advantage” only works for truly innovative products that are developed in secret and presented as a completely tested, wholly new product without a competitor. Like, say, the iPod. When you have significant competitors in place who have some idea what you’re doing and will release their competing versions soon after, it is quite common for the first mover to make less money than the competition who waited a few more weeks.

@MathFox:

I am not aware of anything that will stop the destruction or modification of information on the RFID chip in a passport.

If you meant destruction or modification by a malicious third party, there are two things:
a) some new passports — US ones at least — will have an RF absorbing jacket, so they can’t communicate at all when closed.
b) all of them, US and otherwise, require a long random password before they will receive commands.
Neither of these protections are foolproof (for example, it has already been discovered that in at least the Netherlands, the method of generating the password has much lower entropy than previously thought), but should make it fairly difficult, especially if the user takes reasonable care.

If you meant, there is nothing to stop the user destroying or modifying the data, then actually there are, again, two things. The first is that the data is digitally signed so it will be practically impossible to find valid data other than by copying an existing valid record (which will have the wrong photograph embedded in it.) Secondly:

The obvious fall back method of having an immigration officer perform a visual inspection of the document has been working for decades.

Not so, this is forbidden, and for the obvious reason of preventing just such a “protocol rollback attack”. To be precise, the immigration officer can use visual inspection if he is working at a remote station which does not have an RFID reader. If he has an RFID reader but the passport’s RFID chip does not work or contains no valid data, then he does not fall back to paper; he confiscates the passport as “mutilated” and cancels your trip. You will need to contact your nearest consulate and apply for a new one to be issued, thus incurring replacement costs and significant delays. If it happens repeatedly, or they are able to prove you did it deliberately, you may also be fined.

Ilya • March 17, 2006 1:00 AM

Yeah, right. Write a pointless paper about trivial input validation in the server-side middleware is too boring – let’s put “RFID” and “viruses” there. Buzzword junkies.

cjunky • March 17, 2006 5:55 AM

I think people are overcomplicating this.

At the end of the day all we are talking about is a new, public facing interface.

Any time you have an interface to complex trusted systems that faces an untrusted public environment there will be risk.

Whether the attack is a complicated, self replicating script targetted at the soft underbelly of SQL orientated middleware, or a simple single packet/instruction DOS the risk of attack is always there.

The same can be said about infrared based systems.

Any time where simple posession is accepted as being sufficient to grant access to complex environments with little or no other authentication factors there will be a big risk of exploitation.

Its not particularly suprising. What is surprising however is how long some of these holes have been around with little or no exploitation. Perhaps thats why we continue to build new systems with the same flawed principals at heart.

The only difference is that with the newer systems, the more complex the middleware/backend is the greater the scope there is for exploitation.

I can hardly wait to see what happens when they are using these systems for payment validation and e-commerce 🙂

Oh and for the record dont get too hung up on the “writable not writable” debate. How hard do you think it would be to create something to interact with these interfaces from scratch or even just subvert existing hardware…

Anything man makes, man can break.

Andrew • March 17, 2006 11:42 AM

@ cjunky

Sure, for some unwritable chips you could design special hardware to write to them anyway. That isn’t the issue here.

If the standard reader hardware can write to the chip, you have the potential for a virus to spread from chip to chip by infecting the readers. But if the standard reader cannot write to the cards, special hardware could still infect the reader and cause problems, but it couldn’t spread.

Davi Ottenheimer • March 17, 2006 1:42 PM

@ Roger

“They hadn’t heard of .forward ?!?”

Funny. Well, it was just a story, but the point seemed to be that someone assumed things would never change when they went to chips, when in fact the system experienced constant change after implementation. Probably a thousand ways to skin that squid, but it was mentioned to show the risk of not aligning security designs/recommendations to functional requirements until after the fact.

Shirley B.Abloy • March 19, 2006 7:10 AM

Idea is fresh but is trusted hardly

Michael • March 22, 2006 5:36 AM

An excellent post giving an insight to the news and an excellent viewpoint.

Jids • June 4, 2008 6:12 PM

@ kashmarek

Think about it this way… writable tags can have fewer privacy issues when used properly. Let’s say you’re a sysadmin at a large company and you’ve got a writable tag with your login information on it (so that you’re able to access your computers/servers). Now, you don’t want anyone getting a hold of this tag so you take it home with you, but you want to make sure no one is able to read it from a distance on the bus or the train or whathaveyou. If you re-write the tag to store junk when you go home, and then re-write it to store your login info when you get back to work, then there’s no problem at all. All you need to do is to wave your tag in front of the reader on your computer (can use biometrics and a password here for security if needbe), and your tag is reconfigured, and there’s no chance anyone can get a hold of your info.

RFID Chips and Viruses

Comments

Leave a comment Cancel reply