a CCTV installer in Nigeria.
Is he a prince who's fallen on hard times?
Xiongmai, the vendor behind many Mirai-vulnerable DVRs, has earned the consternation of security watchers once again. The vendor's 2017 list of superuser passwords for certain DVRs – designed only for CCTV installers to access customer installations – appears to have leaked online. "If the creds are what we think they are, …
Is he a prince who's fallen on hard times?
Someone did not give him their bank details so he could transfer it to the UK (other locations may have been available) so yes he had to resort to getting a job.
I'm really really hoping that those are passwords to a SaaS of some sort account and not actually passwords to CCTV systems that change daily due to some sort of algorithm...
edited: oops... maybe I should have read the article better...
Do these work like alarms? Engineer code that the installer changes so you are tied to them for maintenance (unless you get the reset instructions off the internet and change it yourself).
That would be the sensible option rather than a hard coded password that all installers know. Why would you even need a hard coded password? Surely if you had physical access then a reset to default would be all you need.
Unless of course the hard coded passwords were at the request of government.
I'm thinking that the passwords rotate so that service personnel can access customer equipment while they are employed by the installer, but if they leave, they lose all access.
I would assume that the password would be kept in a secure location where someone accessing customer equipment would have to call-in, prove their identity and cite a specific work order before the current day's password is given.
As to what these passwords go to, I would assume that they would be for connecting to remote diagnostics interfaces or getting into manufacturer interfaces.
that was far from perfect. Remote access was allowed to the provider to sort out various issues that arose. This was a DOS based thing that ran on a Novell server. Buggy software and poor transaction logs/no software checking as to why it was not closed gracefully etc. Meant locked files and EOF markers not being written after Windows crashed. I eventually worked out how to fix all this myself.
However the the point being... I changed the password every time they connected, fixed and logged out. They were never very happy about having to ask me for the password each time they logged in.
A CCTV system may or may not be as high risk as a payroll system (depends where the cameras face). Still, why can't engineers ask for the password so they can login to fix? No one should have admin access to any system except the administrator.
I am old school, I will die old school.
Just a guess here - these DVRs are for shops who DON'T have a DVR specialist on staff, so the passwords are for the hired-in CCTV contractors (who, in my experience, generally only have the slightest of ideas about how networks work to start with). So instead of rolling a truck for every call, the CCTV guys can remote-in and check on things or fix/change things in the DVR. Fairy-magic it is.
It's not like Rosie the Florist can figure out how to change the admin password in her DVR every time she needs Joe Bob's Fire Alarm and CCTV Shop to login to her DVR and update the camera names.
But like I said, that's just my guess. I could well be wrong. I'm not saying you're wrong, just that these may be aimed at a lower-tech target audience.
You assume that the end users know the admin password.
Having default passwords isn't a bad idea if there was a set procedure required to enable their use. i.e. if you had a CCTV DVR you needed to have the installer get in and look at something, he tells you "hit that black button recessed on the side" and it enables the ability for an installer to login using that password for the next x hours. Then if the list escapes into the wild, who cares?
Why on earth not something specifically tied to the box such as a MAC address or the like suffixed to a fixed pass phrase? To have one single password "for installers" differs from a backdoor only in the bull and spin in the explanation and excuse...
No one is leaking the Sky PVR master passwords ... Rupert Murdoch is untouchable .. so good at spying others and there is no law an justice for him and his gang.
It's surprisingly common in the CCTV world. Many different brands have hidden (and often unchangeable) admin credentials.
Five minutes on Shodan and a bit of easily discoverable info makes you never want to connect one of these devices to the internet. Ever.
My system ended up being air-gapped by accident. We pulled Cat-5e cable everywhere with a set of cables for the CCTV so we could run analog video and audio over it while only needing a single installer to come in and pull cable. Fast-forward several years and we started converting the cameras to PoE+Video over TCP/IP. Eventually just replaced the DVR with a file server, a 48-port PoE switch, and a multi-monitor desktop. We also added in a fairly large, dedicated UPS system so that we can keep recording several hours after power has failed. The cameras stream their audio and video using RTMP, the file server records the stream with the server running stream-recording software as well as RTMP proxy software to convert it to an HTTP stream to be consumed by the desktop.
Yeah, its a bit hacky, but at least we don't run the risk of it being exploited despite having handed over piles and piles of cash for a "Professional" system.
Back in the days of yore I used to support a DOS application called Ulti-Sales, an excellent POS program (no, not a POS :p)
Anyway, the first couple of versions had hardcoded master passwords. Programmer decided that was not good enough, so he changed the password algorithm to be time-based.
Which meant anytime a techie need to change some settings (or do stuff) the support line need to be called, the time and date on the workstation in question be given, so that support could work out the password, and give it to the techie.
A much better solution for everybody - but unfortunately not for the techies who do support after-hours for their own benefit...
So. The suggestion is that programmers for IoT (and other frippery stuff) implement something like this algorithm. Drawback is if the algorithm can be reverse-engineered, or even "leaked" then it's back to the drawing board...
"Sharing superuser account credentials with installers and expecting them not to leak is asking for trouble," Munro said.
"Having a superuser account at all is asking for trouble" I said
Installed DVR for client (Firewalled appropriately with no access to/from low security zones) only to have said client change the admin password and then forget what the new password was...
Called the vendor who asked what date the DVR was showing and obtained a "daily" password that could be used to log into the DVRs console via a "hidden button" on the login prompt. This priv level could change the admin password and configure/control all "advanced" DVR functions.
Questions to said vendor about security practices, 3rd party code audits and software updates were laughable in the early 90s. Today they appear to be par for the course.
Anon, because RESEARCH ongoing . ;-)
However compared to master passwords, that seems like a really good idea, since once you have physical access to the device, you could as well just pull out the harddisks from the RAID and read the data that way.
There's no need for non-unique default master passwords ever.
I combine my own password with the S/N of the device, and a hash of that gives me the device password. I set the device to that password, write it down, and give it to the user, I don't keep a copy. If the user wants to change that password, they can do so. If they don't want to, i.e., they want me to retain remote access, they tell me the serial number of the device and I can recreate the password I generated when I installed it for them.
I honestly think rule 1 of Internet-connected devices is that no two devices should be shipped with the same default password.
Biting the hand that feeds IT © 1998–2017