Hacking Oklahoma State University’s Student ID Cards

[Sam] took an information security class at Oklahoma State University back in 2013. For his final project, he and a team of other students had to find a security vulnerability and then devise a theoretical plan to exploit it. [Sam’s] team decided to focus on the school’s ID cards. OSU’s ID cards are very similar to credit cards. They are the same size and shape, they have data encoded on a magnetic strip, and they have a 16 digit identification number. These cards were used for several different purposes. Examples include photo ID, physical access to some areas on campus, charges to an online account, and more.

[Sam] and his team analyzed over 100 different cards in order to get a good sample. They found that all cards started with same eight digits. This is similar to the issuer identification number found in the first six digits of a credit card number. Th analysis also showed that there were only three combinations used for the next two digits. Those were either 05, 06, or 11. With that in mind, the total possible number of combinations for card numbers was mathematically calculated to be three million.

OSU also had a URL printed on the back of each card. This website had a simple form with a single field. The user can enter in a 16 digit card number and the system would tell the user if that card was valid. The page would also tell you if the card holder was an employee, a student, or if there were any other special flags on the card. We’re not sure why every student would need access to this website, but the fact is that the URL was printed right on the back of the card. The website also had no limit to how many times a query could be made. The only hint that the university was aware of possible security implications was the disclaimer on the site. The disclaimer mentioned that usage of the tool was “logged and tracked”.

The next step was to purchase a magnetic card reader and writer. The team decoded all of the cards and analyzed the data. They found that each card held an expiration date, but the expiration date was identical for every single card.  The team used the reader/writer to copy the data from [Sam’s] card and modify the name. They then wrote the data back onto a new, blank magnetic card. This card had no printing or markings on it. [Sam] took the card and was able to use it to purchase items from a store on campus. He noticed that the register reached back to a server somewhere to verify his real name. It didn’t do any checks against the name written onto the magstripe. Even still, the cashier still accepted a card with no official markings.

The final step was to write a node.js script to scrape the number verification website. With just 15 lines of code, the script will run through all possible combinations of numbers in a random sequence and log the result. The website can handle between three and five requests per second, which means that brute forcing all possible combinations can be completed in roughly two days. These harvested numbers can then be written onto blank cards and potentially used to purchase goods on another student’s account.

[Sam’s] team offers several recommendations to improve the security of this system. One idea is to include a second form of authorization, such as a PIN. The PIN wouldn’t be stored on the card, and therefore can’t be copied in this manner. The primary recommendation was to take down the verification website. So far OSU has responded by taking the website offline, but no other changes have been made.

39 thoughts on “Hacking Oklahoma State University’s Student ID Cards

    1. It was indeed a particularly good and clear write up for this site. Kudos to rick and hope they figure out a secure method to handle this.
      My nephew has a similar school id setup but they seem to have straight up VISA accounts thru the school that function as debit only and require (as mentioned) a pin number for purchases. He claimed that a kid was performing mitm clone card updating at a network hub in his dorm but that could all be “Ferris passed out in 31 flavors” kinda hearsay. I can’t imagine visa wouldn’t figure it out at some point though and then you have the problem of committing credit fraud on a state computer system, which will give your local D.A. a chubby with dollar signs in his eyes. I’ll have to double check the next time I see the ‘phew :)
      I cannot recall the name of our card system when I was there. It came at the very end and was only for printing and grad student account things. I am pretty sure at this point it was taken over by a Blackboard type system last time I visited 8 years ago. Those were kinda hole-y too iirc.
      Anyway it was a fun read and brought back some memories and the write up was good so thumbs up all around.

    2. Awesome writeup. I certainly hope you got an A for this course, not just because this is very solidly A material (well written, well thought out, thoroughly documented), but because the university owes you an A.

      I enjoyed the write-up (although I will admit to just skimming over the tech breakdown), and hope you keep up the good (white hat) work.

    1. I built one of these once too! I remember I brought it to school and used it to emulate my own credit card and purchase candy from a machine. It was pretty fun. I always wanted to update it to add brute forcing capabilities for things like hotel room keys but I never got around to it.

    1. They were likely approved by someone pitching an identification system, which this is a pretty good fit and works perfectly and flawless for that purpose.
      Later someone else who did/does not understand the difference between “identification” and “authorization” decided to repurpose it for things that need authorization, such as access control and purchasing features.

      Of course I don’t actually know in this case, it could easily have been one very confused individual mixing those two functions up from the start.

      But you are correct, whomever repurposed an identification only system to use for authorization is fully to blame for the current situation.

  1. You don’t put the PIN on the card, you put the hashed PIN on the magstrip and have the same hashing algoritm in the keypad firmware. If the hashes match, the PIN is accepted. The secret is the hashing algorithm, which is [supposedly] secure in the keypad (because it is in RAM which goes away when the keypad is disconnected or something)

      1. If the Algo is public, then I can take the account part off another card, and then put the Hash of my desired (new) pin on the card.
        Real card as 123456 9897 <-9897 being the hashed pin "1234"
        I decide I like 4567 as the pin on my fake card. I run it thru the algo, and make a card with: 123456 1345 <– 1345 is hash of 4567

        Heading on down to the store, I put in 4567…. the Hash in the POS device runs… and I make my purchase

        1. Then that’s a bad security system. Ideally if your card required a pin, it would be input at the terminal hashed and sent to the server over a secure connection for verification. The server would say yes/no not the terminal.

          1. actually that’s why in europe they did this system. not all shops & places have internet to query an outside server. the benefit is this can run anywhere and is a lot faster than the US system which has to dial out.

            i give this system a couple years in the US market before we have some great write-ups on how to bypass it.

      2. I have read many times in many places that Bruce Schneier recommends public algorithms and private keys. Because security through obscurity is failure by design.

        Kerckhoffs’s principle – A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

  2. With a swipe card door access system, your biggest security hole is simply human behavior. If you closely follow someone entering the building, 9 times out of ten, they either hold the door for you or look the other way when you grab the door before it latches again. They just assume you are supposed to be there.

    And even those that will go the extra step and make sure you have an ID/badge, they will not look at it closely enough.

    1. It’s true. Technically I could get fired for allowing someone to “tailgate” on my badge. I did work at a place that used a revolving door with a weight sensitive floor. It would stop and reverse if two people tried to get in on one swipe. Embarrassing though it would also refuse entry if you gained to much weight since you started.

      1. I worked at a place where they paid a guard to watch and make sure everyone swiped their card correctly on their way in AND OUT. Also they had your photo on file and they would put it up on a screen when you swiped your card, so only you can use your card.

  3. Thanks for the article.

    Since both my daughter and my income goes to OSU, It’s good to know it’s a broken system.

    I agree with a previous commenter about the Identification -> authorization. When I was there the cards were basically library cards. Now they not only are used for purchases, but for unlocking the dorm entrance. Luckily, they are still using physical keys for dorm rooms.

  4. “[Sam’s] team offers several recommendations to improve the security of this system. ”

    Yeah I’ve got a great and simple way to improve the security of the system: make it well known that anyone who gets caught hacking into the system will be charged with felony computer fraud. It’s just not worth 20 years in prison for stealing bad cafeteria food.

  5. I work for the the campus center of University of Hawaii at Hilo and we are experiencing the exact same thing. I work with the organization that is in charge of the student IDs and the student ID numbers are encoded on a mag strip and I pointed out that it is a security flaw because mag stripes can be altered. Before taking my position I thought of cloning the single magstrip track that is used for printing stations and laundry machines. I quickly realized that the raw data on the single track magstrip was used to store the credits for print stations and laundry machines in an unencrypted format. For our food credits the student ID is stored on a 3 track magstrip in an unencrypted format and a central server looks up their balance and adjusts it when a purchase is made. I informed the organization after they brought me on and right now we are looking at switching to a RFID system with more security protocols.

    1. RFID can be remotely cloned. With a large enough antenna an RFID device can be activated from several feet away. With a card in a hip pocket, a person with a close range antenna and a small SBC like a RasPi or Beagle Bone can get close behind most people as they walk then snag their card data without them ever being aware of it.

      Even if the data the RFID device transmits is encrypted it can still be copied then taken to a powerful system to decrypt.

      I’d stick with a system that requires physical contact to read the data.

      1. “Even if the data the RFID device transmits is encrypted it can still be copied then taken to a powerful system to decrypt.”

        Not if it’s encrypted _properly_.

        The real issue is that encryption alone doesn’t solve the problem; you don’t have to be able to read the data in order to clone it. More sophisticated and secure RFID based systems use a challenge/response system, relying on a secret key stored in the card and on the server to verify the card’s physical presence.

        1. my universiy access card (RFID based and with a nice scorch from where I accidently set it on fire) appears to use a challenge/response system with a rolling code. usig various android apps to rip he contents of the tag shows some sectors of it are in fact encrypted and the non encrypted sectors change after each usage of the card for either car or lab access.
          I havent invested any further time or research into it yet. Have only confirmed that duplicating the readable sector alone onto a new RFID tag of the same type causes the new tag to be rejected without it being reprogrammed (original still works, plan if dupe worked was to “redupe” the fake tag back to original to restore the updated code onto original and continue usage that way).

          We also use a seperate university ID card. It definitely triggers my phones NFC events although I havent attempted reading its contents yet. Also has a magnetic swiper that is used at the store without any verification… However we still normally pay cash/CC at the store and the card is for logging reward points, reward points can be spent from the card directly though, just a matter of working out who has a huge balance saved up (I have 5 pence).

          1. It’s possible the tag isn’t smart, and it’s simply having some of its data rewritten each time it’s scanned. A system like that wouldn’t prevent you from cloning it, but it would ensure that the first card scanned after cloning (clone or original) would immediately become the only valid card – it’s replay attack prevention, effectively.

  6. Here in portugal authorization/identification is based on rfid, or phisical cooper chip when high security is needed (like cc having a challange/response system).

    But most common is just a rfid tag card to get door access (univesity). School from my 14-18 years old had implemented also a rfid card and that had a school system money associated. I bet they use only the card id to check balance account.

    I have thought sometimes over this but i didn’t cheked it because i’m no aware of any “blank” rfid card that i can program the card id and change it over time at a decent cost. I know there is one making out to crowdfunding one of this days… I will wait for it to try…

    And i don’t have any rfid card reader also, but that i bet its cheap..

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.