How a Simple Security Bug Became a University Campus 'Master Key' (techcrunch.com) 73
An anonymous reader quotes a report from TechCrunch: When Erik Johnson couldn't get his university's mobile student ID app to reliably work, he sought to find a workaround. The app is fairly important, since it allows him and every other student at his university to pay for meals, get into events and even unlock doors to dorm rooms, labs and other facilities across campus. The app is called GET Mobile, and it's developed by CBORD, a technology company that brings access control and payment systems to hospitals and universities. But Johnson -- and the many who left the app one-star reviews in frustration -- said the app was slow and would take too long to load. There had to be a better way.
And so by analyzing the app's network data at the same time he unlocked his dorm room door, Johnson found a way to replicate the network request and unlock the door by using a one-tap Shortcut button on his iPhone. For it to work, the Shortcut has to first send his precise location along with the door unlock request or his door won't open. Johnson said as a security measure students have to be physically in proximity to unlock doors using the app, seen as a measure aimed at preventing accidental door openings across campus. It worked, but why stop there? If he could unlock a door without needing the app, what other tasks could he replicate?
Johnson didn't have to look far for help. CBORD publishes a list of commands available through its API, which can be controlled using a student's credentials, like his. But he soon found a problem: The API was not checking if a student's credentials were valid. That meant Johnson, or anyone else on the internet, could communicate with the API and take over another student's account without having to know their password. Johnson said the API only checked the student's unique ID, but warned that these are sometimes the same as a university-issued student username or student ID number, which some schools publicly list on their online student directories, and as such cannot be considered a secret. Johnson described the password bug as a "master key" to his university -- at least to the doors that are controlled by CBORD. As for needing to be in close proximity to a door to unlock it, Johnson said the bug allowed him to trick the API into thinking he was physically present -- simply by sending back the approximate coordinates of the lock itself. The vulnerability was fixed and session keys were invalidated shortly after TechCrunch shared details of the bug with CBORD.
And so by analyzing the app's network data at the same time he unlocked his dorm room door, Johnson found a way to replicate the network request and unlock the door by using a one-tap Shortcut button on his iPhone. For it to work, the Shortcut has to first send his precise location along with the door unlock request or his door won't open. Johnson said as a security measure students have to be physically in proximity to unlock doors using the app, seen as a measure aimed at preventing accidental door openings across campus. It worked, but why stop there? If he could unlock a door without needing the app, what other tasks could he replicate?
Johnson didn't have to look far for help. CBORD publishes a list of commands available through its API, which can be controlled using a student's credentials, like his. But he soon found a problem: The API was not checking if a student's credentials were valid. That meant Johnson, or anyone else on the internet, could communicate with the API and take over another student's account without having to know their password. Johnson said the API only checked the student's unique ID, but warned that these are sometimes the same as a university-issued student username or student ID number, which some schools publicly list on their online student directories, and as such cannot be considered a secret. Johnson described the password bug as a "master key" to his university -- at least to the doors that are controlled by CBORD. As for needing to be in close proximity to a door to unlock it, Johnson said the bug allowed him to trick the API into thinking he was physically present -- simply by sending back the approximate coordinates of the lock itself. The vulnerability was fixed and session keys were invalidated shortly after TechCrunch shared details of the bug with CBORD.
Re:Aaron Swarz found a good one for MIT security (Score:4, Informative)
Re: Aaron Swarz found a good one for MIT security (Score:2)
Except that's not how it works in academia. Academia has faults, but these kinds of insults do nothing to fix issues.
Re: god damn it (Score:3)
Re: (Score:3)
It should authenticate when you login and then maintain a session key that is sent with EVERY API request. Sounds like they weren't bothering to send the session key, just the user id
Session-handling. Don't roll your own! (Score:2)
In a sense it's a bit like encryption: the golden rule is "Don't roll your own"
Re: (Score:2)
Authentication may be basic, but it's not easy. Keeping the password in local storage to be able to send it with every request is a Bad Idea(tm), even if it is a hash, for example.
Setting up and managing a session, and keeping it as secure as needed without it becoming too much of a bother for the user, is difficult. There are a lot of things which seem like good solutions but which have severe drawbacks. It's very easy to build something which is as bad as having no security at all, or something which is s
Re: (Score:2)
Keeping the password in local storage to be able to send it with every request is a Bad Idea(tm), even if it is a hash, for example.
Why would anyone do that? What makes you think that's a common practice or even something you'd consider?
Setting up and managing a session, and keeping it as secure as needed without it becoming too much of a bother for the user, is difficult
Not really. This is a long-solved problem.
Re: (Score:2)
Why would anyone do that? What makes you think that's a common practice or even something you'd consider?
The comment I answered considered it.
Not really. This is a long-solved problem.
So is Quantum Mechanics. That doesn't mean it's not difficult. Just witness all the horrible user experiences from really badly made session management.
Re: (Score:2)
The comment I answered considered it.
No, they didn't. You just completely misunderstood their comment.
See, the summary implies that they did no authentication at all, just relying on the students' unique ids. They weren't checking passwords. The GP rather obviously says that they should. They then add a bit about a salted hash, which is also correct, as they should at least be storing passwords as a salted hash.
The only person who thought that the GP wanted the user to send their password on every request was you. You're right that it's a
Re: god damn it (Score:2)
Re: (Score:3)
Laziness is a common cause for bugs.But whatever you call it:
The sum of all the mistakes made here adds up to gross incompetence.
You might expect this sort of bumbling from a student project.
You can occasionally find it in custom production solutions, but it is not reallty forgiveable. Anyone making IT solutions for a living really ought to not know better, or that they need to ask someon who knows better.
But from a professional provider of access control and payemt solutions?
Absolutely unbelievable.
Trustin
Re: (Score:2)
But from a professional provider of access control and payemt solutions?
Absolutely unbelievable.
It's often the case where "professional provider" simply means someone that you paid in order to not know how something was done. Whether it was done poorly or well doesn't matter; as long as you can remain ignorant of the details you can pretend it was anything you want.
door locks need an public cloud? and no readers (Score:2)
door locks need an public cloud? and no local readers??
and why put your doors into an public multi client system controlled by an 3rd party vendor? vs some local network system?
Re: (Score:3)
Who do you think you are? Quit asking sensible questions.
Re: (Score:3)
Re: door locks need an public cloud? and no reader (Score:3)
Re: (Score:3)
To be fair, RFID and magstripe are both archaic in the sense that they can both be cloned surreptitiously with the right equipment - one of them even at a distance.
NFC is not very transparent. I don't know if any of the lock implementations actually offer a challenge-response protocol or just present a tag. The latter could be cloned. A door reader that can handle NFC on a phone would also still work with a card with NFC.
At least NFC shouldn't require a cloud connection to do the unlocking if you're doin
Re: (Score:2)
NFC is just the transport layer (the physical interface) and a very basic protocol that lets the phone decide what app to launch to handle the interaction. The security of the lock is down to the app that handles the lock protocol. It could be as simple as supplying a serial number that the lock checks against a list of authorized ones, very similar to RFID cards.
Re: (Score:2)
Yes. You repeated me very accurately. The point is, the product box will just say "NFC" and there's no way to know if it's a simple identifier that can be hit by a replay attack or a challenge-response with a shared secret.
Re: (Score:2)
Neither would a physical key.
But, hey, you know, mechanical things are considered bad by the young crowd, despite thousands of years of development.
What, exactly, does using your phone to unlock a door have over using a key?
Re: (Score:2)
Proper access control. If you leave a key lying around, someone can copy that too. And then put it back where they found it without you ever knowing.
Re: (Score:3)
Re: (Score:2)
Search youtube for lock picking lawyer. Everything sucks, it's just that some things suck more than others.
Like implementation in the OP.
Re: (Score:2)
Particularly his Christmas editions are magnificent.
And indeed, a lock is not to prevent a theft, but it is to ensure that the thing next to it is easier to steal.
Re: (Score:2)
Then students get a hold of the master key (or figure out how to make one) and they have access to all the doors with no log of entry.
Master Keys (Score:2)
I actually had a set of master keys for my university. Could get me into pretty much anywhere steam tunnels, biology labs, dean’s residence. The one place I verified I had no access to was the experimental nuclear reactor on the campus but that wasn’t really that interesting.
I don’t think an “api key reset” would have impacted it either.
Thank god social media wasn’t a thing back then!
Re: (Score:2)
the experimental nuclear reactor on the campus but that wasn’t really that interesting.
Are you sure??
Re: (Score:2)
I had a tour of it before it was decommissioned. It was very small, maybe 250kW. Experimental as in "for experiments," not innovative. It was part of the nuclear engineering program. It should have been decommissioned 15-20 years earlier.
Re: (Score:2)
What is so comical about a life preserver? It is next to a giant pool of water someone could fall into and need help getting out of.
Re: (Score:2)
The U of F reactor is still in operation. It is 63 years old, but was refurbished and returned to service in 2014.
Re: (Score:2)
Re: (Score:2)
Was this the University of Florida, Gainesville?
Re: (Score:2)
No; hopefully they don’t need steam tunnels, but what do I know.
Where doesn’t really matter, when is much more important to society. So happy it was pre-social media and pre cheap CCTV systems. The ability to do stupid things, survive, and not have it be a permanent black mark on your life is really important to growing up.
So, it's not a bug, it's a feature? (Score:2)
Microsoft oughtta sue for copyright infringement!
New technology, old bugs (Score:2)
The old Sniff and Replay attack (Score:2)
Cuckoo's Egg all over again. (Score:2)
Location check (Score:2)
Major test case gap (Score:2)
Re: (Score:2)
A get off my lawn moment (Score:3)
Back when I was in uni in the 90s we had these things called "locks" on the doors. If no one was in the labs they were locked. Wanted to buy a meal? Cash or card was your friend. Wanted to get into your room? Remember your key. What the fuck is this rush to app-ify everything even when its clearly impractical (bugs, phones can be lost/stolen, not everyone even amongst the young has or wants a smartphone) when there are simpler solutions that Just Work?
Re: (Score:3, Insightful)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Keys are easier to hack than phones. You can buy a key blank for most locks for dollars, file it down to a 'bump key', and it will unlock almost anything.
The most effective and secure way to do doors (besides a human guard) is:
1) an NFC reader lock with feedback confirming it opened,
2) The lock has a escalating time out for every false reading.
3) Have the NFC transmitter automatically change the combination every time it succesfully works. So if someone clones it, then either their clone will not work or
Re: (Score:2)
No lock is unpickable but magnetic keys can't be replicated using a standard blank so beyond the scope of 99.99% of students to make a dup.
Also you have to ask yourself if the electronics is worth the hassle and cost since few standard door locks can withstand a sledgehammer or even a well placed kick and if someone really wants to get in they will anyway.
Re: (Score:2)
You got a point about the kick. But the main use of locks is two fold a) discourage casual crime and b) inform you that a crime has been committed when you find the lock/door broken.
Also magnetic keys are mostly hype. Many of the so called magnetic locks can be opened with a refrigerator magnet. Some need to also throw in a bump key.
Re: (Score:2)
Back when I was in uni in the 90s we had these things called "locks" on the doors. If no one was in the labs they were locked.
Sounds like an actual security nightmare, or one of those archaic institutions which require students to be supervised at all times like little children.
I'm glad we're not in the 90s anymore having facility managers doing something as archaic as managing physical keys. What next, you complain about the fact we can send an email rather than have our receptionists type a letter for us as we dictate while smoking a cigar like the good ol' days?
There's a reason keys aren't used for access management at any faci
Re: (Score:2)
Back when I was in uni in the 90s we had these things called "locks" on the doors. If no one was in the labs they were locked.
Sounds like an actual security nightmare, or one of those archaic institutions which require students to be supervised at all times like little children.
Sigh. Typical slash-dotter "(reasonable thing to do) is ridiculous and oppressive because seems bad to me though I have not given it any thought at all" response.
Even the touching "absolutely all students are totally trust worthy and would never steal or break anything" faith (did you actually encounter many students in your life?) assumes that the entire building is locked with no access by walk-ins. Requiring everyone who might need to enter a building to have their own key (remember this is still mechani
Re: (Score:2)
Keys and wallets can be stolen, lost, or misplaced just like phones.
Not that those other systems were simpler either... Key management on the scale of something like a university is a pretty good sized job all on it's own. Ditto the cashiers in school cafeterias. It's not that the
Re: (Score:1)
There is some incentive to track things like who unlocked which doors when, and to be able to instantly revoke access to specific areas of campus under certain conditions (such as a lockdown). Keys don't do that. Moreover, keys present a security hazard that is difficult to address when they are lost or stolen -- especially when the keys allow access to a building rather than to a single dorm room.
The real question is whether locking or unlocking doors ought be done with a chipped student ID card (as is cur
Security licence (Score:2)
Re: (Score:2)
The entire security industry would likely fail this - go and look at the https://www.youtube.com/c/lock... [youtube.com] it shows that physical locks have not improved in 100 years and are quick and simple to open without a key ... ... they amazingly are less secure
The new Digital locks are laughed at and bypassed with tricks conventional locks mostly stopped 100 years ago but also new tricks
so much facepalm here (Score:4, Insightful)
It astounds me how anyone thought this was a good design to use.
It must have been designed entirely by a single person, because there's just no way even a small team could have looked at that and said, "yeah, thats secure." someone would have raided a hand and said "but couldn't just anyone do that?"
Re: (Score:2)
"but couldn't just anyone do that?"
I feel like hubris may speak to this. I've met an unfortunate number of programmers who think they are gods gift and that their abilities are something that objectively can't be replicated.
this is NOT a bug (Score:2)
"failure to authenticate" isn't a bug. It's a fundamental desgin flaw.
But unlike say, "forgetting to actually unlock the door", it's a failure that wasn't immediately obvious to the end users.
And I think that's a problem with security. We rarely SEE it in action, and just expect it to be there and doing its job. GOOD security is practically (or completely) invisible to the end user. Which makes it look exactly like bad (or non-existant) security, and allows it to go undiscovered for a long time before s
University education advancement (Score:2)
Buy schlocky products make students use them daily and watch creme of the crop emerge. Universities issue tuition to level up for next semester.
Reminds me of the line in Ocean's 11. (Score:2)
Require a cell phone for everything? (Score:2)
Wow. Requiring a cell phone to open doors? That's just stupid. Obviously consumertards love it.
So this is what they are teaching at schools these days - how to love toy cell phones?
Yeish.
Who's your guest? (Score:1)
Who's the guest in your room?
Back to the 1980s? (Score:1)
This sounds like a bug that I'd fix from the 1980s.
Same mistakes over and over again.