The start/stop at the bottom makes that look like it's come canned with a CMS and they've just tacked on what they needed to. It's 90% boilerplate.

It's hardly a secret tesla.com is Drupal -- both that gitignore and the robots.txt shouts it quite loudly, to be fair. One of the larger Drupal agencies, Lullabot includes them in their clients list: https://www.lullabot.com/our-work and they are looking for a sr backend Drupal engineer https://www.tesla.com/careers/search/job/sr-software-enginee... which I would take if the company were not lead by Musk.

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.

And for the lay man: https://builtwith.com/tesla.com .

Haven't seen Drupal in the wild for years. Good on them!

Probably you have, lots of websites still using Drupal, heavily customised of course. Search for "websites made with Drupal" and have your jaw dropped, as probably a website or two you visited recently will show up :)

Then you aren't visiting too many US government sites , most of the are on Drupal.

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

You can compare it to the current version of the same file in the most recent Drupal release https://github.com/drupal/drupal/blob/9.5.x/core/MAINTAINERS...

D10 will be out soon :)

Is this a normal Drupal practice? You just deploy the Git repo?

I think, generally speaking, it’s a PHP standard practice and more broadly a scripting language practice, though it doesn’t really apply to Node.

No pre-compiling is required, so you just ship the files. Especially true for anything that offers an Apache module (like mod_php).

Ship the files sure, ship the top-level folder not really. Most sites will have a "public" subfolder or equivalent, so the READMEs, scripts, sources etc don't get served. Either way, a professional would remove those files or block them at the HTTP server level.

Ehhh, I don’t know if I agree that most will have anything.

> more broadly a scripting language practice,

I can tell you it's not the case with Python.

Interesting, because that and mod_python were what I was thinking of aside from PHP. What’s the workflow there like?

Well, I mean, that might have been somewhat standard practice with mod_python the last time anyone used mod_python, which I would assume was about 15 years ago.

Looks like it's been dead since 2010: https://en.wikipedia.org/wiki/Mod_python

In practice, I think modern Python webapps usually use WSGI or similar, where you wouldn't be just dumping a bunch of files somewhere.

Modern PHP apps also would be using Nginx and phpfpm, but it ends up being the same - copying files over.

So the unusual thing about PHP (and, historically, mod_python, and CGI for that matter) is that it's normal to have the code actually under the web server's content directory tree. That is, if your content root is /var/www, then you put your code at /var/www/thing.php, so a deployment involves copying stuff into /var/www, and if the server is misconfigured, going to "https://example.com/thing.php" will actually show you the code.

For, say, Java or Ruby web apps, your code is more likely to live elsewhere (people love to fight over exactly _where_...), and run its own web server; nginx or apache or whatever will then proxy requests to that webserver. No matter how it's configured, you're never going to show the end-user the code, or extraneous files like .gitignore. Python's a bit of a corner-case (or at least it used to be last time I worked with Python webapps about a decade ago); it's customary to use WSGI or similar rather than a proper web server, but the effect is much the same.

That is very much not standard practice for PHP since about 10 years by now. Applications have a designated web root directory and an entry point that boots the application - as php is serverless by design - which is sometimes placed inside the web root by convention, but that is neither a requirement nor a security risk.

By now, stateful application servers are also powering modern php deployments: They also listen to a socket, and keep parts of the application in memory, next to an event loop.

Generally very much like Rails with a running process that could be standalone or with a web server interface module depending traffic or other requirements.

I don’t know, my servers are generally configured to serve nothing more than the index.php file and anything in the /public directory. I don’t serve up the entire content repository.

Do you deploy confidential information into the repo ? That would be the root problem.

Things don't have to be confidential to be an issue. Leaking the actual maintainer's names (as opposed to the Drupal list), for instance, would not necessarily be considered confidential, but still an issue if it showed up.

Usually passwords or keys are stored in a config file, and that is stored in a place outside the repo.

And the bumph at the top - crawlers run by Yahoo! and Google - lol

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

If that's all the dirt that thousands of vengeful fired Twitter ex-employees could find, then Tesla must have excellent security.

Yeah this screams complete and utter desperation. Like, I get that hating Elon is what all the cool kids at school are doing this month but do we really need this immature garbage on the front page of HN all day?

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.

Honestly, all the Twitter acquisition has shown is how irrelevant to Twitter’s success the management team was. Twitter has gone from a sophisticated, large organization with 8000 employees to 700 guys following the direction of a random guy making crucial business decisions off Twitter polls (lmao), and if anything it’s become slightly more popular and successful

"more successful" how? Because Elon said so? If it's just about raw page impressions/activity, then perhaps for while since most of the western press is reporting and often directly linking to Twitter right now but what will happen once the media and their audience is bored of the drama and jumps to the next fad?

Do you really believe Twitter will become more profitable under Musk than before when even the new CEO already prepped the workers for a possible bankruptcy, a fat pending debt repayment date coming closer and advertisers running away?

> if anything it’s become slightly more popular and successful

Twitter made $5bil in 2021. Do you really think this or the next quarter, post-Musk acquisition, post-him running off big name advertisers, will even approach any of the worst quarters from the last 3 or 4 years under previous management?

He has all the data. We know for certain Musk would be shouting from the rooftops if that brief burst of Twitter Blue subs made any real dent in revenue.

More than that, Twitter not has an extra $12 billion in debt, and $1b in interest payments due, which almost exceeds their quarterly revenue.

Well, I'd personally at least find some hilarity in being a Twitter engineer fired by one of those 10x Tesla engineers while they're publishing their .gitignore files via HTTPS (which probably means that their Nginx configuration is fucked).

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.

Not parent you are answering to, and I don't have a dog in this "elon is a god"/"elon is the devil" fight, but let's stay factual: while the .gitignore is not an issue at all, serving dot files should virtually never be done

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

Unless they intended to publish their .gitignore, I'd say it's closer to a bad thing than to a good thing to have random files from your repository open to the public.

The simplest S3 permissions is to allow "*" publically too, but simple doesn't make it better.

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.

It's standard practice not to serve any hidden files (starting with .) over HTTP. The fact that .gitignore is served can indicate they don't block .paths, so lots of other things could slip through (.aws for instance).

Is that a standard now? Who's going to tell the guys using .well-known?

It has always been standard, it was the #1 thing to do when setting up Apache back when Apache was the standard and nginx was still this obscure Russian porn web server.

.well-known is much more recent and an exception. Can you think of any other .file or .folder which is wise to be exposed publicly?

I was around back then and uploading websites, (version controlling on svn, not git), and I do not recall it being a standard. The closest standard I can think of is .htaccess files (which we did upload) for various vhost specific settings.

What is your basis for this standard? Was there a mailing list agreement I missed?

That is an apacheism to avoid serving .htaccess which can include hashed passwords. It's not a general thing.

.plan

Mastodon actually uses .well-known for Webfinger stuf.

Are you sure it isn't .ht* that's blocked? That's what the default config is on my system.

People are just having some fun.

This looks like a default file from a Drupal installation: https://api.drupal.org/api/drupal/robots.txt/7.x

Really doesn't leak much, and robot.txt is supposed to be accessible from the internet.

Yes, it's meant to be public, but you need not disclose all of what is contained inside of it. I've been on many pentests where paths provided by robots.txt, that I wouldn't have obtained any other way, led to exploitable vulnerabilities.

For some reason, a considerable number of people don't seem to think twice about adding sensitive paths to robots.

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

You're correct that the resources themselves should be secured and that security through obscurity is a bad practice (and an oxymoron, as obscurity doesn't actually provide security).

That said, avoiding security through obscurity doesn't preclude you from giving away less information than is being given away here, nor does it make the act of removing that information entirely pointless. While this isn't the only way that the Drupal version can be identified, it is one, and there's no guarantee your adversary will find it via other avenues. Also keep in mind that with absolutely nothing changing on Tesla's end, this may go from secure to vulnerable, should, for instance, a remotely exploitable vulnerability in the running version of Drupal be discovered and published in the future.

Not the case here tho is it

Well, we don't really know. Maybe there's some easy-to-guess text file in /misc/ that contains a password for something. We don't know what we don't know. We do know that there's considerably more information exposed here than zero - the question is whether any of that information could lead to sensitive information, not whether or not it constitutes sensitive information by itself.

How does someone on pentests not know it's the default robots.txt that comes with Drupal and hence does not leak anything except that it's Drupal?

Comparing it to Drupal's default robots.txt

Did an inventory based on my crawler data a while back.

Relatively common to find sensitive or embarassing links singled out in robots.txt

Especially in old large organizations, like universities.

Apparently Tesla is FOSS, see https://www.Tesla.com.

Where can I get the FSD (Fake Self Driving) source code?

edited to hide my horrific lack of HN text formatting skills

you forgot to

    from autopilot import *

Is that a route that you do often and it happened to have no unpredictable events today?

Its just random cms bs. Nothing to hate elon about