DEF CON 29 - Vivek Nair - Time Turner Hacking RF Attendance Systems To Be in Two Places at Once

00:07 - Our story begins in the spring of 2020 with an unnamed 18-year-old computer science undergrad student.

00:14 - With just two requirements left, he’s about to become the youngest ever computer science graduate from his university.

00:20 - Unfortunately, as he’s registering for his final semester of classes, he realizes that his two remaining courses are both scheduled that basically the same time.

00:30 - But surprisingly, he was able to register just fine.

00:33 - At the time, the scheduling system only checked whether classes were at the exact same start time, not whether they overlapped at all.

00:40 - So he registered for both classes, and thought, “Problem solved, I’m in. ” The student may, or may not have actually been attending his classes regularly anyways, so how one can be present in two simultaneous classes was not at top-of-mind.

00:54 - And a quick look at the course syllabi revealed that between 10 and 15% of the points were for attendance.

01:00 - This means that missing half, or even all of the lectures shouldn’t have been the end of the world.

01:05 - It wasn’t until the week before classes started that he decided to look more closely, and he was surprised to find a new policy that students with more than six unexcused absences would not be allowed to pass the course.

01:17 - They would have to retake it. Well, this was an issue, because he was so close to graduating, and he was about to set a record after all.

01:25 - So he started thinking about how these courses actually enforce their attendance policies.

01:30 - What do these large universities use to keep track of attendance for thousands of the students? Well, it turns out that this is what they use.

01:38 - It’s an RFID-based polling system that has become increasingly popular at universities due to the ease of conducting attendance for even large classes with hundreds of students.

01:49 - Every student in the course will be assigned one of these, a remote with a unique identifier linked to their student account.

01:55 - Then throughout the lecture, instructors will ask multiple choice questions, and have students respond by pressing the corresponding button on their remote.

02:04 - The remote will then broadcast their answer along with their student ID back to the base station, so that after class instructors can generate a list of students in attendance, along with the answer they chose.

02:16 - So it actually serves a dual purpose, both enforcing attendance by requiring students to actually show up with their remote, but also serving as a small quiz each lecture to make sure students are paying attention.

02:28 - Well, it would seem that this system should make it impossible to attend two lectures at the same time.

02:34 - Even if a student were to give his remote to a classmate to answer for him in one of the lectures, he then wouldn’t have the remote to answer with himself in another lecture.

02:44 - So if he’s gonna make this work, he better get creative.

02:47 - What he could do is try attending one class, then attending the other class, alternating which one he attends and which one he misses, but that only gets him ‘til the end of February until he’s used up all his drops, so that doesn’t exactly work.

03:01 - Okay, but maybe he could try clicking in in one class, then sprinting across campus to the other lecture, and clicking in there, then sprinting back before the next question starts.

03:12 - But our mystery student isn’t exactly Usain Bolt, so that one might not work either.

03:18 - What he really needed was a Time-Turner. It’s this magical device from the “Harry Potter” series that the students used to take two classes at the same time by time traveling.

03:30 - Now, without the luxury of magic, he would need the next best thing, which is of course, hacking, specifically hacking this system, the one that actually enforces his attendance.

03:40 - If he can get this system to mark him present in both classes, he would in effect be in two places at once.

03:49 - Well, the bad news is that this remote uses completely proprietary hardware and software to communicate with the base station.

03:57 - The good news is that hackers exist, so of course, it was quickly reverse engineered by some colleagues of mine at Cornell.

04:05 - I’ve added some links here to their original paper, and it’s definitely worth a read, but for now, I’m going to outline the techniques they used to approach reverse engineering this system, and then I’ll explain what they found, and how it could be exploited by our hypothetical student.

04:21 - This is actually a fairly simple device with only two significant ICs, the first being an eight-bit micro-controller manufactured by NXP, and the second being a 915-megahertz ISM transceiver manufactured by Semtech.

04:37 - All one has to do to monitor the communications between these two components is tap into the data pins for the SPI bus here, which is exactly what my colleagues did to sniff the data in transit between the two ICs.

04:51 - It’s important to note that the manufacturer of this device prevented the firmware from being directly analyzed by burning the security program fuse.

05:01 - They didn’t, however, do this on an earlier version of the device, so that firmware is now available online.

05:08 - Another thing my colleagues did was just packet sniff the RF signals to see what the device was emitting directly.

05:14 - A waterfall plot for the answer A is shown here.

05:18 - It seems like the device is just broadcasting a single short packet for each response using 2-FSK modulation at a bit rate of 152 kilobits per second.

05:29 - The base station then sends back a single acknowledgement packet, although this is less important for our use case.

05:36 - The base station and the remote appear to negotiate a single fixed frequency for transmitting and one for receiving, depending on what channel they’re set to use, although in practice, it’s almost always just AA.

05:49 - Now, knowing the frequency and the encoding scheme, the researchers simply pressed each of the buttons A through E, and observed what the contents of the resulting answer packet were, which are shown here.

06:02 - Surprisingly, the packets that the remote sends to the base station are just five bytes long, which is just barely enough space to encode a device serial number and an answer with maybe a checksum, so there can’t be that much more than that going on.

06:17 - Additionally, only the final two bytes of each packet actually change when the answer changes, so this must be the portion of the message which encodes the selected answer.

06:27 - The first three bytes of the packet are always the same, which must mean that this is the portion that encodes the device ID, so let’s look at this part first.

06:35 - It turns out that what’s happening here is just a basic transposition cipher that shuffles the bits of the device ID according to a predetermined and easily reversible system.

06:45 - It also turns out that the device IDs, which have eight hexadecimal digits, contain a rudimentary built-in checksum, whereby the fourth byte is just the xor of the first three bytes.

06:57 - Just by reversing the process in this table, we can now construct the first part of the answer packet for any valid device ID.

07:05 - Now, let’s look at the last two bytes of this message.

07:08 - The fourth byte of the message just encodes the answer choice according to a predetermined table, and the fifth and final byte is a checksum of the entire message according to this algorithm.

07:19 - We now have everything we need to reconstruct the entire protocol, which is shown here.

07:25 - All that’s left to do is to build a device that can emulate the legitimate remote, and it turns out that this $25 Adafruit Feather M0 board has all of the hardware necessary to accomplish this.

07:38 - The firmware that I wrote to emulate the polling system is linked here along with a tutorial for how to set it up.

07:45 - The entire firmware compiles down to less than 10 kilobytes and can comfortably reside in the Arduino’s built-in flash storage.

07:53 - But enough talking about it, let’s see it in action.

07:56 - All right, now for a brief demo. On my left is the legitimate polling system, and as always, if I select an answer on my remote, it’ll be broadcast, and received by the base station.

08:07 - On my right is an Arduino running the custom firmware and initialized to a random serial number.

08:13 - It’s connected to my laptop right now with the USB, so I can manually send it commands, and if I instruct it to broadcast an answer as if it were a remote, right now it’ll look to the base station as though another student is submitting an answer using their remote.

08:29 - Now, let’s try this again, but this time I’m going to set the Arduino to the same serial number as my remote.

08:36 - Now, if I click in with the remote as normal, and then instruct the Arduino to broadcast an answer, it appears to the base station as though the same student is simply changing their response.

08:55 - In effect, these two devices are acting as if they are the same remote.

09:00 - As it stands though, this only addresses half our problem, because although our student would now be able to transmit answers as if he were using a real remote, he still wouldn’t know which answer choice was correct without being physically present, and frankly, even then it’s questionable.

09:15 - Luckily, by reverse engineering this protocol, it becomes as easy to emulate a base station as it is a remote, simply by setting the packet radio on the M0 to receive mode, rather than transmit.

09:28 - This would then allow him to see what other students are answering, and simply choose the most popular response.

09:34 - Okay, same demo as before, except this time, my Arduino is set up to emulate a base station.

09:40 - So when a student submits an answer, it’s overheard not just by the legitimate base station, but also by the Arduino, which can then nicely display all of the student selections on my laptop.

09:51 - All right, well, obviously we don’t want to have to keep manually controlling this device.

09:56 - Luckily, if we combine the last two demonstrations, it’s not hard to imagine a fairly basic protocol for automating this process.

10:03 - We should start by instructing the device to remain idle until the expected start time of the class.

10:09 - Then it should turn on, and start emulating both a base station and a remote.

10:14 - It should wait until a flurry of radioactivity occurs, indicating the likely start of a new question.

10:21 - It should then use the base station emulator to determine what the most popular student response is, at which point it should use the remote emulator to broadcast that same response.

10:32 - It should repeat those steps until the expected end time of the class, thereby answering every question, and most of them correctly.

10:40 - So now we’re getting somewhere, but this is not exactly a practical solution.

10:44 - It has to remain tethered to a PC and manually controlled.

10:48 - The first step towards a completely self-contained solution is to attach a standalone input device, which I’ve done here by crudely soldering on a 128 by 32 pixel OLED screen with three input buttons.

11:00 - The really nice thing about using an ultra low power platform like Arduino is that this device, even with a display attached, has a peak current draw of about 20 milliamps, as you can see here, so this tiny 500 milliamp hour lithium polymer battery should last well over 24 hours on a single charge.

11:20 - If I connect this up, we now have something resembling a practical self-contained device.

11:26 - Here’s the same device, just with a little electrical tape added to hold everything together.

11:31 - This finished device is what I call my Time-Turner.

11:34 - It bears not much resemblance to the original, but it can achieve many of the same results.

11:38 - Let me show you. The most basic thing I can do with this Time-Turner device is just submit a vote as if I were using a legitimate remote.

11:47 - As you can see, the base station here still can’t tell the difference.

11:51 - Another thing I can do is view the votes of my classmates.

11:55 - It might be hard to see this screen, but no matter which option I choose on this legitimate remote, it is automatically displayed on the Time-Turner.

12:03 - Now, if I were more nefarious, what I could do is try to change the votes of my classmates.

12:08 - I’m going to restart the poll here. And this time, no matter what my classmate chooses, their vote will automatically be changed to B.

12:27 - Let’s try picking an answer. And no matter what I choose, it is automatically overwritten by the Time-Turner device.

12:36 - Now, a vulnerability that allows me to change someone else’s vote on a so-called polling system is a major oversight.

12:44 - But if I were more nefarious still, I could simply perform a denial-of-service attack.

12:49 - Submitting hundreds of votes per second will quickly overwhelm the host device, eventually causing it to crash, and making it impossible for a legitimate student to submit their vote.

13:00 - Let’s restart this poll one last time to show the most relevant type of attack, which is simply copying the most popular vote for any given question.

13:14 - So I’m going to restart the polling, and this time, the Time-Turner will just copy whatever the most popular vote is.

13:20 - So let’s say I vote for A as a legitimate device.

13:23 - The Time-Turner immediately copies that. If the most popular vote changes to something else, the Time-Turner will eventually change its vote, always making sure to stay within the majority.

13:35 - The idea is that with just a little adhesive putty the student can go in the previous night, and covertly attach this device to some surface in the lecture hall, and he can be sure that the next morning this device will attend class for him while he attends the other class the normal way.

13:51 - Of course, if he can do this, then he could just as easily build two devices and attach them both the surfaces in the lecture halls, and then these will both attend class for him, and he can catch up on homework, or sleep in.

14:05 - Now, I’m not gonna tell you if this student eventually just built these for all of his classes, but I’ll let you come to your own conclusion on that one.

14:13 - What I can tell you is that this device was pretty darn effective, and by mid-semester, the student had almost full points in both attendance and quiz correctness.

14:23 - So what does that tell us about this? First of all, it’s a great lesson about authentication.

14:30 - You may already know that an authentication mechanism should either be something you know, like a password, something you have, like a universal second factor key, or something you are, like your biometric data.

14:44 - These factors are all in theory unique to you, but this is just a polling device.

14:50 - It’s being used incorrectly to authenticate someone’s physical presence at a lecture, when in fact there is no real authentication happening here at all.

14:59 - It’s just broadcasting an answer and an ID number in plain text over a radio signal.

15:04 - Now, to their credit, hey did try to hide this by using a proprietary protocol that shuffles the bits around.

15:11 - But I mean, this is an obvious violation of Kerckhoffs’s principle, which states that a system should be secure, even if everything except the key is public knowledge.

15:21 - When using security through obscurity, it’s only a matter of time until someone completely reverse engineers your system, and what little security you had disappears.

15:31 - So now that the security flaws of this particular system have come to light, let’s talk about the various shortcomings of its design, and how they might be addressed.

15:40 - I think the flaws of this system map cleanly onto the three so-called CIA properties, which are Confidentiality, Integrity, and Availability.

15:51 - I’ll recount what I see as the core issues with this system, and then propose a simple way to fix each of them.

15:58 - First, with regards to confidentiality, there is none to speak of as I demonstrated when we were able to listen into other students’ answers.

16:07 - Next is integrity, and again, because I was able to build a device that could indistinguishably emulate my own, or anyone else’s remote, and even change other people’s answers, the integrity of the answers received by a base station cannot be assured.

16:23 - And finally, with respect to availability, I demonstrated a simple denial-of-service attack that would make it difficult for a legitimate remote to be heard.

16:33 - And now, as promised, some proposed solutions, starting with availability.

16:38 - This one is pretty straightforward. Every single remote in a classroom is transmitting and receiving on the exact same frequencies.

16:46 - For the default AA channel, that’s about 916. 5 and 903 megahertz respectively.

16:53 - One would actually expect far more natural collisions and packet drops if each honest remote wasn’t broadcasting just five bytes at a time.

17:01 - But it does make this system particularly vulnerable to denial-of-service attacks as we saw.

17:07 - Perhaps a better idea would be to use FHSS, whereby the frequency used by a given remote rapidly changes in a way that is predictable to the base station, but not to any passive observer.

17:20 - Standardized protocols like Bluetooth already implement this by default, and that’s for a good reason.

17:26 - It’s still not impossible to jam, but it becomes much harder, and requires wide spectrum radio frequency jamming, which is very expensive, and very illegal.

17:36 - That’s not to say that any of these attacks are particularly legal if you’re not using your own system, like I am here.

17:43 - Next, confidentiality, which is also not too tricky, one way to address this would be for the base station and remote to perform an authenticated key exchange when they first establish a connection, and then use the symmetric session key to encrypt all communications moving forward.

18:01 - Something like mutual auth TLS could be used to do this in a standardized way.

18:06 - In fact, the chip used by this device already has built-in hardware support for AES encryption, but it was intentionally disabled for whatever reason.

18:16 - And again, standard protocols like Bluetooth would already do this by default, although the mechanism there is a bit more intricate.

18:24 - Finally, integrity, this is the trickiest problem to solve, but one idea might be to use a Physically Un-cloneable Function, or PUF, a laser-based design, as shown here, but silicon PUFs can be had for a few dollars, and it would make it nearly impossible for me to build another device that replicates the behavior of my remote, or the remote of any other student for that matter.

18:47 - This still doesn’t solve the broader problem of authenticating physical presence, due to the possibility of relaying answers from a legitimate device to one, or more remote locations.

18:59 - To combat this, you would need to add a challenge response mechanism with a tight time window, just large enough for devices in close proximity to submit a response, a matter of microseconds, but not nearly what it would take to actually relay a message over the internet, which would be at least a few milliseconds.

19:17 - A student, or at least their real remote, would therefore have to actually be in the room in order to respond to the challenges sent by the base station fast enough for their attendance to count.

19:30 - All right, let’s summarize. It’s hard to overstate how vulnerable this system is, and it’s even more shocking that this exact model is currently used at over 1,100 universities, and in nearly 100,000 classrooms.

19:45 - To summarize my security recommendations, if a new version of this system were released, they should consider using FHSS to avoid denial-of-service attacks, and use encryption in transit to protect confidentiality, bonus points if these first two problems are both solved by simply using an open source standard, which satisfies Kerckhoffs’s principle.

20:06 - Lastly, they should use a PUF with a time challenge response mechanism to produce what would then be an incredibly secure device, especially by comparison to its current form.

20:15 - Well, it turns out that the authentication problem may be even worse than it seems.

20:20 - That’s because in addition to the student remote, the same company also produces an instructor remote that allows teachers to start and stop polling, show and hide the poll results, switch slides on a PowerPoint presentation, and even select the correct quiz answer.

20:37 - Now, if these devices look similar, that’s because they’re actually identical under the hood.

20:42 - So it’s as easy to emulate this instructor remote as it was to emulate this student remote, and once one can do that, they can do everything from changing the slides on the instructor’s presentation to even selecting their own quiz answers as correct, which really emphasizes the need for a PUF, or some other hardware-based authentication mechanism.

21:02 - Now, it needs to be emphasized that PUFs and Bluetooth chips are already bulk-produced commodity hardware that cost a few dollars at the most.

21:10 - After all, this is a $54 device, so it’s hard to argue that there is a major cost barrier here.

21:18 - By the way, this one is about $30 if you already have a soldering iron.

21:24 - As for our canonical student, well, as I mentioned, all of this was taking place in the spring of 2020, and around the same time, another major world event was starting to unfold.

21:35 - So of course, midway through the semester, he ends up receiving this email, which among other things tells him that all of his classes have been moved online, and that all students will get full participation points.

21:47 - So while this didn’t end up being helpful, hopefully it at least made for an interesting DEF CON talk.

21:53 - As for these days, well, if a student wanted to attend two classes at once today, this is how they would do it.

22:00 - Thank you. .