Tesla.com/.gitignore

Ah good old bobby tables :)

It's a good sign there might be an exploitable file upload vulnerability, if you can find an endpoint that uploads files to a directory that's served by Apache with the same configurarion as the directory of the executable settings.php

I was agreeing with the person I replied to. Most of the rest of the thread is implying this affects self-driving somehow

Not to mention a lot of the subsequent requests when loading https://www.tesla.com/ contains the HTTP header+value "x-generator: Drupal 9 (https://www.drupal.org)"

So yeah, not exactly a secret.

More to that point, see https://www.tesla.com/MAINTAINERS.txt

It’s the default drupal robots.txt it seems. https://api.drupal.org/api/drupal/robots.txt/5.x

Yep, it seems like most of the posters here in this thread don’t do much software engineering from the looks of it. Or are being purposely obtuse here. There is no security vulnerability here in any of the links we’ve seen so far minus some unnecessarily deployed boilerplate. The gitignore file is not the same file your deployment tool uses when publishing a website. If there’s an API endpoint that is public opposed to some static asset, that would be a problem. Nothing we’ve seen here indicates that.

This is not an issue and just means that their wwwroot probably comes from a repo. Anyone who judges an engineer who made this decision poorly is silly.

I’d say it’s closer to good thing than bad thing due to simplicity.

It's barely a vulnerability. Many open source projects have theirs public. It might be a problem if the company's system was terrible and relied on security through obscurity; but maybe they don't care. The engineers who think it's a big deal may have tunnel vision. That can happen if you spend years in a very narrow area.

https://xkcd.com/932/

I look forward to meeting the Tesla engineers who work on their core tech and also their webpage.

Robots.txt is a web standard, if it lists routes to actual sensitive data then hosing those sensitive paths is the issue, not robots.txt.

I regularly see bad pentesters fall for this.

that's defense in depth, right ? /s

also sometimes what's in robots.txt becomes invisible to the corporation as well and abviously bugs creep in

I would rather that the paths be secure themselves. Security by obscurity is not a good idea. Anyways there are not that combinations of paths even when you consider all the different cms defaults

Not the case here tho is it

edited to hide my horrific lack of HN text formatting skills

What makes it fake? Just today my car drove me from my house to the grocery store with no intervention.

Hm, did not know that had a default, thanks.

Many of us have a build process that converts the contents of a checkout into a deployable site (a.k.a. "build artifact").

The build process can trivially skip .gitignore files (and all other files that are strictly for dev environments).

You then deploy the build artifact to production, with exactly the set of files which ought to be there.

Nope.

Paths in .gitignore means git ignores them. Doesn't mean the file doesn't exist. It means it's not in source control.

An example is a .env file. It may very well be _required_ in many PHP or node projects but it's going to be ignored.

I spent around 3 years working with Drupal 7 and and about a half a year with Drupal 8.

For D7:

* The frontend and backend are too tightly coupled.

* The views system was awful to design custom, complex queries for. Documentation was scarce

* No dependency management

* Lots of weird hacks to do standard things, like the Features module

* The hooks system can result in a lot of complex, unclear logic

I've since moved onto the python/js ecosystem and it's much easier to build sites in

I'm a professional red teamer at a FAANG company, for reference. There are plenty of times where I find several low severity vulnerabilities, none of which are exploitable alone, but which can be chained together to produce a functional exploit with real impact.

There's no guarantee any of your testers will find every issue, and there's no guarantee that a seemingly innocuous finding can't have a greater impact than might readily be apparent.

That said, there are a ton of charlatans in security exactly like you describe - folks who can't read code (let alone write it) who just know how to click "scan" on their GUI tools and export the report to a PDF. A lot orgs have a QA-level team running those automated scans, which get passed on to a penetration testing team, who have more experience, but a limited time window for testing, and then finally on to red teams, who, along with some appsec / product security folks who are embedded directly on product teams, tend to have the most expertise, and the most time to really dive deeply into a service or application.

Also, keep in mind that those gawking over this probably aren't security folks, and the competent security folks here may not be gawking at the file itself (or others) - just taking part in the discussion.

I work in .gov so I have a lot of experience with that kind of security “engineer” but I’d take a more moderate position. This stuff is super-easy to resolve so you should spend a couple of minutes closing it and then focus on more complex things, with the reason being that when something like log4j happens you aren’t making it so easy for attackers to know whether you’re vulnerable – passively telling them makes it easier to avoid things like WAF blocking rules which will block IPs which actively prove.

There's no need to minimize or explode this; We need to put this into proportion. An information leak by itself is nothing, but it must be reported and taken seriously (by default, it should be fixed).

I'm not disappointed this happens at tesla.com; I expect as much. But to many people, this is a top-notch brand. You don't expect this on google.com or nsa.gov or fbi.gov either, do you?

Personally I'd not deploy these files. Although that would be more to do with not having to discuss it yet again with auditors or pentesters than it would for actual security.

It's not an arbitrary thing, and any kind of vulnerability (including this one) is potentially a step in a chained exploit. I wouldn't be suprised if we see a hack before Tesla fixes this. And yes, they will fix it because it's a security issue.

This is customer control panel, which directly leads to car APIs behind that are using the same credentials.

On the same domain there is also the Tesla SSO.

It would be bad if this gets compromised as there would be direct impact in the physical world, not just a static landing somewhere.

Tesla.com seems to be more than marketing, at least customers can sign-in there to do cars operations,.

If you can grab credentials from there you can do quite some things already.

See https://www.teslaapi.io/authentication/oauth (and this is in the case you don't trick an employee).

But I agree, that normally at some point they would catch it.