It’s absolutely inexcusable that in 2021 we still have apps that come with default credentials like admin/admin. You can yell at users all you want, but history has shown that is not good enough. The blame here at least partially falls on bitbucket for making it so easy to set things up in an insecure way.
To all developers reading this: it is YOUR responsibility to do everything you can to prevent your users from shooting themselves in the foot like this.
Do you know of any resources describing this as a developer responsibility/best practice? I agree with you, but I'm looking for some independent resource that I can show to Business to convey to them the importance of this.
(Most resources I'm finding are only describing the importance of remembering to change the default password, rather than designing a system without a default password to begin with.)
Look at some practical implementations. E.g. Jenkins CI. When you first install it (the latest versions), it does not use default admin/admin credentials. What it does is produce a random password string that you have to go find on disk to perform the initial setup. At no point could someone without direct access to the machine get in before you are able to lock the door.
Defaults matter. There’s a huge difference between starting an account with a complex password and then the user intentionally weakens it, vs starting with a weak password with a note saying “pretty please change it”. It’s obvious that some set of users will not change it, so it’s better to start in a default secure state than an insecure one.
And yes, sometimes security and UX conflict, and users just need to deal with it.
Unrelated meta-side-rant: this leak exhibits one of the two types of naming conventions for internal tools that I really dislike:
- Unrelated historical/comic book/movie references, e.g. "Project Morpheus" or "X-37" or "Calligua", "Wolverine Project" etc etc. Meaningless.
- Things like this Nissan leak where everything is an acronym that is meaningless on its own. TTBA. SSKLR. URA. PIIY. What the hell?
Both are awful. Please please please if you are responsible for naming something at your work, please choose something descriptive.
E.g. instead of picking something "clever" or "cool" like "Boudicca Project" or "Skylark" or some useless acronym like "CTITT" please call your mundane CRM system something meaningful like "Customer Management Tools" or something understandable without knowing the backstory (e.g. "we called it Team Sofa because it replaced and old CouchDB instance, and everyone used to hangout on our sofa in our office when we did meetings - duh") and easily searchable.
Future users and engineers trying to figure things out will thank you.
I think you make really good points, but I thought that the main reason for using internal names like you describe are so that if the names aren't recognizable if they are used indiscreetly (i.e. to protect projects that are in development from being leaked inadvertently).
OEMs use codenames because they're often sending/receiving parts to/from external suppliers, e.g. when driveshafts go around random warehouses and logistics companies they have the codenames on the boxes and stickers. they impose the same rules on tier 1 suppliers in order to maintain secrecy and streamline communication, that way everyone is referring to the same project using the same naming convention while preventing incidental leaks
This is how battle tanks came to be known as 'tanks'. At the time, any german spy who overheard the wrong conversation would think the British were talking about containers for holding water.
100% agreed in general. In this particular case, that's likely the Bitbucket project name (or "slug" if you're looking at the API or backend database). On our old instance at work, it's all caps and has a short length limit, at least by default.
1. If you try to make the name descriptive, it could possibly be accurate, but lack precision. To take on your example "Customer Management Tools" - ultimately there's a whole host of things all over the stack that could be considered "Customer Management Tools". Some words even come with organizational _baggage_ where stakeholders immediately think "ah we've been waiting on this for years" and you have to explain, "no this doesn't do that at all"
2. Software can change in functionality or sometimes even purpose over the course of it's life time (let's say 2-4 years, or longer). While the name is typically easy to change in user facing parts of the product, repository names and URIs are the harder parts and typically get cemented after creation.
If you combine points 1 and 2, you get something that's worse than wrong or cryptic - you can get naming that is actively misleading
I've seen real examples where someone started a project called "promo renderer". 3 years later new ppl onboarding onto the project will say "this renders promos? where's the code that shows the promos?" and the answer will be "well this doesn't technically render the promos, it's a configuration system which helps decides which promos get rendered; the actual render is another system". Unfortunately, it was almost impossible for the day 1 dev to see that level of nuance/precision.
My final argument is not necessarily that detached names are better, but there are definitely sharp downsides which I've felt that you have not considered.
While future "users and engineers" might be thankful, other stakeholders might not. Project names serve a purpose of secrecy in situations where you have classified information or trade secrets and somehow end up in situations where you need to communicate about it out in the public. Security by obscurity that is rather discreet but effective.
You kind of have a point, but "Customer Management Tools" sounds like it could be absolutely anything. If that's the alternative I'd rather have a fun memorable name.
Isn't this a problem between naming for the purposes of project management (where a unique, even silly name may be a plus) and project maintenance (where, like you say, it's opaque and confusing)? I tend to err on the side of maintenance, since you only launch it once, but you have to live with it for a lot longer, but I can understand the impulse to label the project itself - it just needs to go away or be in some other channel from the get-go.
Acronyms are absolutely meaningful and descriptive usually, you just don't have the context. They're used and abused in corporations for exactly this sort of situation. If you have access to the source but not any context, it becomes increasingly difficult to copy what something is actually doing.
Not very. The car's core logic doesn't seem to have been affected – which is understandable; I wouldn't trust your average non-specialist to write that kind of software, and this code all looks like it's been written by generalists – if I'm guessing the kinds of project right from their acronym, anyway.
I dunno about that. I readily acknowledge that cars are a different bucket of fish, but the benefits of open-sourced firmware have been well-established in areas like routers.
It's also (hopefully) not a binary choice between OEM firmware and a clean-room from-scratch implementation. If it was I might agree, but the ideal scenario is that the OEM releases the firmware, then community members (okay, whatever, generalists and amateurs) get to fix bugs/do long-term support when the business has moved on. Complimentary rather than adversarial. For instance, even a generalist could throw some static analysis at some code and come up with a bunch of trivial (but useful!) memory correctness fixes or something like that.
The problem is that this is not the way the OEMs write the software. They are typically generated from some ecu/car/network system description using a code generator. So you get out this giant blob of optimized code which is essentially impossible to maintain, not to mention literally impossible to push to the upstream. On top of that, there are 10-30 ECU's in modern cars (often of 3-4 different SKUs), all with similar, but distinct code blobs. You would need a complete description of the cars network topology, the entire toolchain used to build the software and deploy it, the extremely expensive debug HW to debug it, and so on. The open source community does not develop software the same way OEMs develop software
From my dealings with Nissan quite a bit of their code is written by third parties. And those third parties have locked in the car manufactures to the point where they share hexadecimal logs that only the third party can read.
Russia will always be blamed. Too many financial connections with China and fallout. Solarwinds + China = huge deal. Solarwinds + Russia = nothingburger.
Downloading this torrent is willful copyright infringement of nissan's copyrighted code.
2. CFAA
If you live in the US, the CFAA is a very poorly worded law that can be abused by a company with over-eager lawyers.
Effectively, the law states that it's a crime to "exceed authorized access" of computer systems.
It's borderline, but it's possible nissan could take anyone who downloads this data to court claiming that they were not authorized to access the data on the git server, and knowingly downloading that data constitutes a CFAA violation.
I don't think it would stand up in court (other than the original hacker who guessed 'admin/admin', which was def a CFAA violation), but I also don't think most of us have enough money to spend on lawyers to defend ourselves.
Yep, and remember due to the peer-to-peer nature of torrents it's trivial for someone to monitor the IP addresses of the seeds and leeches. This is how people have gotten mean leaders from RIAA for torrenting music for example.
Apparently it's a whole collection of repos - each .bundle file in the torrent can be expanded with git clone to a full repo according to the readme, there are about 250 bundle files in the torrent.
Maybe people will be able to understand why their "Connect" apps are so horrible?
On my Leaf I can theoretically send a route to the car. And theoretically check things like state of charge. These might work. Or might not. Random API RNG seems to dictate that.
Theoretically or not, it was often the case that I could walk to the garage to turn on the heat more quickly than I could using the Nissan app. "Sure", you say, "your garage is probably, what, at most 10-12 meters from where you're sitting? Slow, sure, but not that bad."
No, not my garage at home, I was referring to the parking garage two blocks down the street. Which is why, when Nissan offered to do it for free, I had them rip out the GPRS cell radio that wasn't useful anymore when AT&T turned those frequencies off. As parent points out, it wasn't that useful to begin with; not if it's a crap shoot whether it works or not.
I've never understood why they couldn't make more of the process asynchronous with a retry or three. It would make so much of the process more seemless.
But these companies do not seem to value user experience in the same way that a software oriented car company (eg, Tesla) does[1].
[1] Yes, I know that this has consequences that are negative for Tesla too.
Possibly can be best thing for them as they don’t bother to make EV that lasts (failing to heat/cool batteries, but great cars otherwise). Someone might hack something good now lol.
Since Nissan and Renault are now one company, we could be seeing Renault code getting leaked soon too since they're 100% sharing code internally even if both Nissan and Renault both have projects to do the exact same thing with completely different suppliers.
I promise this was a newish hire who was given whiteboard softballs and put in charge of what use to be the job of several people as a cost saving measure from management.
You get what you pay for people and more importantly you get the people you pay for.
66 comments
[ 3.1 ms ] story [ 121 ms ] threadTo all developers reading this: it is YOUR responsibility to do everything you can to prevent your users from shooting themselves in the foot like this.
(Most resources I'm finding are only describing the importance of remembering to change the default password, rather than designing a system without a default password to begin with.)
https://www.jenkins.io/security/advisories/
"Do not ship or deploy with any default credentials, particularly for admin users."
Though I wish OWASP published this guideline too. (they do state this is a top 10 venerability, and the HDIV scanner looks for this to fix)
[0] https://confluence.atlassian.com/bitbucketserver/install-a-b...
There's also a danger that if you try to do this, then your product turns into a UX nightmare.
And yes, sometimes security and UX conflict, and users just need to deal with it.
- Unrelated historical/comic book/movie references, e.g. "Project Morpheus" or "X-37" or "Calligua", "Wolverine Project" etc etc. Meaningless.
- Things like this Nissan leak where everything is an acronym that is meaningless on its own. TTBA. SSKLR. URA. PIIY. What the hell?
Both are awful. Please please please if you are responsible for naming something at your work, please choose something descriptive.
E.g. instead of picking something "clever" or "cool" like "Boudicca Project" or "Skylark" or some useless acronym like "CTITT" please call your mundane CRM system something meaningful like "Customer Management Tools" or something understandable without knowing the backstory (e.g. "we called it Team Sofa because it replaced and old CouchDB instance, and everyone used to hangout on our sofa in our office when we did meetings - duh") and easily searchable.
Future users and engineers trying to figure things out will thank you.
(been there, done that a few times.... there's nothing more permanent as a temporary solution)
1. If you try to make the name descriptive, it could possibly be accurate, but lack precision. To take on your example "Customer Management Tools" - ultimately there's a whole host of things all over the stack that could be considered "Customer Management Tools". Some words even come with organizational _baggage_ where stakeholders immediately think "ah we've been waiting on this for years" and you have to explain, "no this doesn't do that at all"
2. Software can change in functionality or sometimes even purpose over the course of it's life time (let's say 2-4 years, or longer). While the name is typically easy to change in user facing parts of the product, repository names and URIs are the harder parts and typically get cemented after creation.
If you combine points 1 and 2, you get something that's worse than wrong or cryptic - you can get naming that is actively misleading
I've seen real examples where someone started a project called "promo renderer". 3 years later new ppl onboarding onto the project will say "this renders promos? where's the code that shows the promos?" and the answer will be "well this doesn't technically render the promos, it's a configuration system which helps decides which promos get rendered; the actual render is another system". Unfortunately, it was almost impossible for the day 1 dev to see that level of nuance/precision.
My final argument is not necessarily that detached names are better, but there are definitely sharp downsides which I've felt that you have not considered.
I mean, it will be better and safer coded by amateurs, but it might not pass emissions anymore ;)
It's also (hopefully) not a binary choice between OEM firmware and a clean-room from-scratch implementation. If it was I might agree, but the ideal scenario is that the OEM releases the firmware, then community members (okay, whatever, generalists and amateurs) get to fix bugs/do long-term support when the business has moved on. Complimentary rather than adversarial. For instance, even a generalist could throw some static analysis at some code and come up with a bunch of trivial (but useful!) memory correctness fixes or something like that.
did you take on my suggestion to ready any reverse engineer post?
Searching for that lead me to these. I haven't confirmed if they're legit:
https://git.rip/exconfidential/nna
Torrent: magnet:?xt=urn:btih:36cc1d89f8d5155bb08d05d0ed67a0e861f7b536&dn=nissan-na-gitdump-EXCONFIDENTIAL
Torrent tracker: https://newtrackon.com/api/stable?include_ipv6_only_trackers...
Downloading this torrent is willful copyright infringement of nissan's copyrighted code.
2. CFAA
If you live in the US, the CFAA is a very poorly worded law that can be abused by a company with over-eager lawyers.
Effectively, the law states that it's a crime to "exceed authorized access" of computer systems.
It's borderline, but it's possible nissan could take anyone who downloads this data to court claiming that they were not authorized to access the data on the git server, and knowingly downloading that data constitutes a CFAA violation.
I don't think it would stand up in court (other than the original hacker who guessed 'admin/admin', which was def a CFAA violation), but I also don't think most of us have enough money to spend on lawyers to defend ourselves.
Really.
https://jalopnik.com/uzi-nissan-internet-domain-owner-who-fo...
Hypothetical question: Should readers of driverdan comment be worried?
On my Leaf I can theoretically send a route to the car. And theoretically check things like state of charge. These might work. Or might not. Random API RNG seems to dictate that.
No, not my garage at home, I was referring to the parking garage two blocks down the street. Which is why, when Nissan offered to do it for free, I had them rip out the GPRS cell radio that wasn't useful anymore when AT&T turned those frequencies off. As parent points out, it wasn't that useful to begin with; not if it's a crap shoot whether it works or not.
But these companies do not seem to value user experience in the same way that a software oriented car company (eg, Tesla) does[1].
[1] Yes, I know that this has consequences that are negative for Tesla too.
You get what you pay for people and more importantly you get the people you pay for.