Nissan code leaked after bitbucket repo set-up with defaults admin/admin | Hacker News Reader

Nissan code leaked after bitbucket repo set-up with defaults admin/admin

zdnet.com

145 pointsnucatus63 comments

Open articleView on HN

From the screenshot the torrent name is nissan-na-gitdump-EXCONFIDENTIAL.

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...

fyi: should probably download this using a vpn

Why?

1. copyright infringement

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.

If you want to learn more about IP legal disputes, visit http://nissan.com

Really.

For those who don't want to click this link, this is Nissan Computer's website which are unrelated to the car company.

Wonder what's going on with this now. I heard that Uzi Nissan (The original site owner) has passed away.

https://jalopnik.com/uzi-nissan-internet-domain-owner-who-fo...

From the law point of view, magnet link could be argued to be an equivalent to a torrent file.

Hypothetical question: Should readers of driverdan comment be worried?

https://git.rip/exconfidential is official.

What "defaults"? There's no BitBucket default to make the admin account "admin/admin", someone did this intentionally.

Which makes this even worse

Should I be waiting for the usual press communiqué "We were the target of a very complex Cyberattack" from Nissan?

a highly sophisticated threat actor if you will ...

A state actor. Likely China or Russia.

North Korea about to enter EV market...

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.

While this practice is OK, I am not sure if Jenkins with its billions of trivial vulnerabilities in every other plugin is a poster child for security.

https://www.jenkins.io/security/advisories/

Which is totally irrelevant in the context of this discussion (which is on default passwords).

https://hdivsecurity.com/owasp-broken-authentication

"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)

Even routers these days have a random password assigned to them.

There are no default credentials in Bitbucket[0]. An admin manually set these at some point.

[0] https://confluence.atlassian.com/bitbucketserver/install-a-b...

You can try as hard as you want, but users will always find a way to bypass your precautions and shoot themselves in the foot.

There's also a danger that if you try to do this, then your product turns into a UX nightmare.

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.

Yes but in this case there was no auth and the user setup admin/admin. This was a human.

I tend to make a default passphrase of "Please change me." and require a password change on first login.

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.

Readable link: https://archive.ph/Q9bKf

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.

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.

Lol I'm more amazed that they have 1 repo, for pretty much everything, than I am that they forgot to change the default passwords. It's a nightmare.

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.

Well that makes sense. The article indicated otherwise, which made me wonder.

Mono-repo is not that unusual. Most of google is 1 repo.

So how ‘open’-source is that car now? This actually might make Nissan more attractive to some people.

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.

If you read any write up on reverse engineering cars ECUs you will pray that your car get hacked and opensourced asap.

I mean, it will be better and safer coded by amateurs, but it might not pass emissions anymore ;)

A car ECU programmed by amateurs will not be better or safer than the one flashed by the OEM.

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

Interesting, thanks for clarifying. Those do seem like big challenges.

> ECU programmed by amateurs will not be better or safer than the one flashed by the OEM

did you take on my suggestion to ready any reverse engineer post?

I have read some before, they are quite fun. But I also work on the actual OEM software itself =)

@geohot

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.

That's not for Nissan only, it is quite standard for an automotive company to get software components from tens of partners.

Default passwords and not enforcing strong passwords are bad idea by design. I thought we learned that 10 years ago.

Their production source code has the salt for the encryption algorithm hard coded as the (presumably H1B worker's) name "Amalesh"

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.

"dude, just name the project something, it doesn't matter, we'll change the name if it get accepted"

(been there, done that a few times.... there's nothing more permanent as a temporary solution)

I disagree with this, here's why:

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.

Reply on news.ycombinator.com