The key technical question here is: How can one put an exploit or virus on a tiny batteryless tag with less than 1 Kilobits of memory? On this page, we will explain the concept of RFID middleware and show the crucial role it plays in allowing (or preventing) RFID malware attacks. We will then give two examples of RFID middleware bugs that can allow attacks to happen as examples of how attacks work.
An RFID system consists of hardware, including RFID readers, and software. The software runs on ordinary PCs or servers and consists of middleware, which contains the logic of the RFID application, and a backend database system (e.g., Oracle, SQL Server, Postgres, MySQL) for storing information about the tags. Typically, the tags contain an identification number and possibly some item-specific information. For a supermarket application, the checkout scanner might simply read the ID number and look it up in the database to see how much the product costs. However, in an airport baggage application the system might write the passenger’s ticket number and the final destination for the bag onto the tag at check-in time (because the next airport the bag visits may not have access to the originating airport’s database). When the bag is later scanned, the middleware could then just ask it where it is supposed to go.
To boil our result down to a nutshell, infected tags can exploit vulnerabilities in the RFID middleware to infect the database. Once a virus, worm, or other malware has gotten into the database, subsequent tags written from the database may be infected, and the problem may spread.
As a first example, suppose the airport middleware has a template for queries that conceptually says:
“Look up the next flight to <x>”
where <x> is the airport code written on the tag when the bag was checked in. (To make these examples understandable for people who don’t know SQL, we will not discuss actual SQL on this page; subsequent pages will give actual SQL examples.) In normal operation, the RFID middleware reads the tag in front of the reader and gets the built-in ID and some application-specific data. It then builds a query from it. If the tag responds with “LAX” the query would be:
“Look up the next flight to LAX”
It then sends this query to the database and gets the answer. Now suppose the bag has a bogus tag in addition to the real one and it contains “JFK; shutdown”. Both tags will be seen and processed. When the bogus one is processed, the middleware will build this query:
“Look up the next flight to JFK; shutdown”
Unfortunately, the semicolon is a valid character in queries and separates commands. When given this query, the database might respond:
“AA178; database shutdown completed”
The result is that the attacker has shut down the system. Although this exploit is not a virus and does not spread, merely shutting down a major airport’s baggage system for half an hour until the airport officials can figure out what happened and can restart the system might delay flights and badly disrupt air traffic worldwide due to late arrival of the incoming aircraft.
The countermeasure the RFID middleware should take to thwart this type of attack is to carefully check all input for validity. Of course, all software should always check all input for validity, but experience shows that programmers often forget to check. This attack is known as a SQL injection attack. Note that it used only 12 of the 114 bytes available on even the cheapest RFID tags. Some of the viruses use a more sophisticated form of SQL injection in which the command after the semicolon causes the database to be infected.
As a second example, suppose that the application uses 128-byte tags. Naturally, the programmer who wrote the application will allocate a 128-byte buffer to hold the tag’s reply. However, suppose that the attacker uses a 512-byte bogus tag or an even larger one. Reading in this unexpectedly large tag may cause the data to overrun the middleware’s buffer and even overwrite the current procedure’s return address on the stack so that when it returns, it jumps into the tag’s data, which could contain a carefully crafted executable program. Such an attack occurs often in the world of PC software where it is called a buffer overflow attack. To guard against it, the middleware should be prepared to handle arbitrarily large strings from the tag.
Thus to prevent RFID exploits, the middleware should be bug free and not allow SQL injection, buffer overflow, and similar attacks. Unfortunately, the history of software has shown that making any large and complex software system bug free is easier said than done. Thus although we have not listed any specific vulnerabilities on this website, they probably exist although we have no proof at this time.
