[HN Gopher] Nissan code leaked after bitbucket repo set-up with ...
___________________________________________________________________
Nissan code leaked after bitbucket repo set-up with defaults
admin/admin
Author : nucatus
Score : 121 points
Date : 2021-01-07 13:14 UTC (9 hours ago)
(HTM) web link (www.zdnet.com)
(TXT) w3m dump (www.zdnet.com)
| mikestew wrote:
| What "defaults"? There's no BitBucket default to make the admin
| account "admin/admin", someone did this intentionally.
| robotnikman wrote:
| Which makes this even worse
| deno wrote:
| So how 'open'-source is that car now? This actually might make
| Nissan more attractive to some people.
| that_guy_iain wrote:
| 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.
| elwell wrote:
| @geohot
| wizzwizz4 wrote:
| 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.
| gcblkjaidfj wrote:
| 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 ;)
| waiseristy wrote:
| A car ECU programmed by amateurs will not be better or
| safer than the one flashed by the OEM.
| livueta wrote:
| 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.
| waiseristy wrote:
| 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
| gcblkjaidfj wrote:
| > 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?
| driverdan wrote:
| 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:36cc1d89f8d5155bb08d05d0ed67a0e861f7
| b536&dn=nissan-na-gitdump-EXCONFIDENTIAL
|
| Torrent tracker:
| https://newtrackon.com/api/stable?include_ipv6_only_trackers...
| bb010g wrote:
| https://git.rip/exconfidential is official.
| xyst wrote:
| fyi: should probably download this using a vpn
| paulie_a wrote:
| Why?
| TheDong wrote:
| 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.
| jmt_ wrote:
| 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.
| interestica wrote:
| If you want to learn more about IP legal disputes, visit
| http://nissan.com
|
| Really.
| Karawebnetwork wrote:
| For those who don't want to click this link, this is
| Nissan Computer's website which are unrelated to the car
| company.
| olyjohn wrote:
| 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...
| NullPrefix wrote:
| 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?
| encom wrote:
| Readable link: https://archive.ph/Q9bKf
| flr03 wrote:
| Should I be waiting for the usual press communique "We were the
| target of a very complex Cyberattack" from Nissan?
| jessmay wrote:
| a highly sophisticated threat actor if you will ...
| throwaway4good wrote:
| A state actor. Likely China or Russia.
| YinglingLight wrote:
| Russia will always be blamed. Too many financial
| connections with China and fallout. Solarwinds + China =
| huge deal. Solarwinds + Russia = nothingburger.
| mattlondon wrote:
| 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.
| blacksmith_tb wrote:
| 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.
| tonoto wrote:
| 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.
| adenadel wrote:
| 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).
| stretchcat wrote:
| 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.
| davidrm wrote:
| 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
| ajsnigrutin wrote:
| "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)
| [deleted]
| throwaway889900 wrote:
| 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.
| chenxiaolong wrote:
| 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.
| 0dmethz wrote:
| 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.
| gretch wrote:
| 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.
| darth_avocado wrote:
| 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.
| Stephen304 wrote:
| 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.
| darth_avocado wrote:
| Well that makes sense. The article indicated otherwise, which
| made me wonder.
| brianwawok wrote:
| Mono-repo is not that unusual. Most of google is 1 repo.
| outworlder wrote:
| 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.
| jsight wrote:
| 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.
| mikestew wrote:
| 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.
| that_guy_iain wrote:
| 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.
| orev wrote:
| 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.
| tiborsaas wrote:
| 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.
| orev wrote:
| 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.
| gabereiser wrote:
| Yes but in this case there was no auth and the user setup
| admin/admin. This was a human.
| tracker1 wrote:
| I tend to make a default passphrase of "Please change me."
| and require a password change on first login.
| ericcholis wrote:
| Even routers these days have a random password assigned to
| them.
| Mg6yDfjp5U wrote:
| 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.)
| bob1029 wrote:
| 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.
| isbvhodnvemrwvn wrote:
| 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/
| JosephRedfern wrote:
| Which is totally irrelevant in the context of this
| discussion (which is on default passwords).
| tlarkworthy wrote:
| 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)
| bberenberg wrote:
| 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...
| dzhiurgis wrote:
| 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.
___________________________________________________________________
(page generated 2021-01-07 23:01 UTC)