Tesla.com/.gitignore
tesla.com
tesla.com
This will happen some day, so invest 5 bucks per month to exploit Tesla at a certain point, so maybe you can be first in line for the Cybertruck :-)
You shouldn't even be able to execute settings.php
So maybe the same configuration applies to a user upload directory. If you find a way to upload a .php file to a web directory on the same server, there is a possibility you can execute it - with higher success probability than if you did not know about settings.php being executable.
I used to keep a hall of shame on my main site, because looking for "settings.php" or "global.asa" on a Zope site was just silly.
- https://www.tesla.com/.git/info/exclude
- https://www.tesla.com/.git/index
README.txt 403s too. https://www.tesla.com/README.txt
edit: just going to add files I've found here:
If you're going to down-vote me, down-vote me because I mentioned Elon is a human being, with human flaws and human strengths and not the resurrection of Supply-Side-Jesus.
Ffs, a tech forum should be better than this
I think the person you were replying to was not playing down the thing that happened, but explained exactly what the cartoon said. It not being important for the general public does mean it's not a probable fact.
No pre-compiling is required, so you just ship the files. Especially true for anything that offers an Apache module (like mod_php).
I can tell you it's not the case with Python.
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.
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.
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.
So yeah, not exactly a secret.
Haven't seen Drupal in the wild for years. Good on them!
For some reason, a considerable number of people don't seem to think twice about adding sensitive paths to robots.
also sometimes what's in robots.txt becomes invisible to the corporation as well and abviously bugs creep in
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.
I regularly see bad pentesters fall for this.
from autopilot import *It's far from "full" self driving.
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.
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?
.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?
What is your basis for this standard? Was there a mailing list agreement I missed?
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.
I look forward to meeting the Tesla engineers who work on their core tech and also their webpage.
Relatively common to find sensitive or embarassing links singled out in robots.txt
Especially in old large organizations, like universities.
I wonder if these are some of the same people that Musk brought in to refactor Twitter.
I accidentally ordered my model 3 with a free reservation, not the one I actually paid for.
Everyone uses git for source control, of course you check out a site with git.
All you are telling people with a .gitingore is what is _not_ available.
It means exactly that people can not access them if your site is a checkout, because they aren't there.
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.
In those cases a build process is usually trivially easy to put together, and has benefits, so while not necessary it's still beneficial.
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.
(Partly joking)
If it's tracked, then ignore has no effect. If it's not tracked, then you might as well use .git/info/excludes which is pretty much the same thing but not tracked, or you can use a global excludes file, like ~/.gitignore is common (you have to configure git to point at it, iirc).
It _could_ make sense to ignore the .gitignore if some other tool is parsing and using that file, but that pattern is...troublesome so I hope not.
> Git ignores .gitignore with .gitignore in .gitignore
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
So, not very surprising and probably doesn't really tip anyone towards anything particularly special.
Otherwise, it's not much of a leak.
In practice, it means that if the gitignore file is leaked, that there is a substantial risk that they accidentally leak the .git folder someday.
The .git folder indirectly contains downloadable copies of the source-code of the website, which could very likely lead to credentials leak or compromised services.
Your life can depend on Tesla.com services.
Even if you are the pedestrian side.
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.
FTFY. Little of Tesla's software is whatever they're using on the website. That'd be like judging Apple OS software by their website source.
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.
There is no guarantee that an exposed .gitignore (or other exposed files, like .htaccess, robots.txt, etc) will be exploitable, but they aid in the discovery process and may help adversaries uncover exploitable vulnerabilities they might have otherwise missed.
At the extreme, I've seen paths of backups of the production database listed in a publicly readable .gitignore, and that database backup was publicly accessible, too.
Most of the time, nothing sensitive is revealed, but defense in depth suggests it's better to not upload files like these to your web server unless they're being used by the webserver (like .htaccess) or crawlers (like robots.txt), and if you do, they ought to not be publicly readable (unless intended, like robots.txt), but even then, you'd want to make sure nothing sensitive is in any file like that which is publicly readable. Even if there's nothing sensitive in them now, there's no guarantee that nothing sensitive will ever be added.
I had to work with a security team in a FAANG for several years. They were so high and mighty with their low sev vulnerabilities, but they never improved security, and refused to acknowledge recommendations from the engineers working on systems that needed to be rearchitected due to a fundamental problems with networking, security boundaries, root of trust, etc. Unsurprisingly, their "automated scanner" failed to catch something a SRE would have spotted in 5 minutes, and the place got owned in a very public and humiliating way.
When I see things like this it brings back memories of that security culture. Frankly I think Infosec is deeply broken and gawking over a wild .gitignore is a perfect example of that.
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.
Absolutely this. Security often has a different perspective as to how systems may be exploited together to create a systemic issue where none exists independently. Of course, this is often also where security fails in communicating exactly why these low severity issues must be corrected and facilitating an engineering discussion as to how the attack chain can be effectively disrupted and detective controls implemented elsewhere in the chain such that attempts to exploit are detected.
In short, the failure isn't in finding the threat but in dictating solutions without getting everyone involved in engineering the interaction in the room, so to speak.
I would be ideal to have security engineering as an embedded function representing red and blue team findings as systems requirements and acting as a single point contact in regards to security issues such that mutual trust and respect may be developed.
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?
It is a bit embarrassing because most web servers (and deployment setups) shouldn't be publishing/serving dot files anyway (files with names beginning with dot). But it's not necessarily a problem as long as they have some protection to avoid the _really_ sensitive stuff leaking, it's just kind of funny.
ie, if the file said to ignore "/site/adminpasswords.txt" then you could go to /site/adminpasswords.txt and reveal admin passwords. this is obviously a simple eli5 explanation but i hope it helps
however, i doubt the tesla.com website is where they keep any important code that relates to actual tesla software like we would see used in cars. that would be like the army having their real code for their software/systems at goarmy.com lol
Yes PHP is still relevant!
https://www.tesla.com/robots.txt
Disallow: /taxonomy/term/*
# Ignore configuration files that may contain sensitive information.
sites/*/settings*.php
# Ignore paths that contain user-generated content.
sites/*/files
sites/*/privateBy this logic, it's actually impossible for a company to ever do anything wrong.
Have you seen what remains of Twitters engineers? All of them are fanboys that think Musk can do no wrong. Of course they’d do whatever the man says.
I have to imagine the same is true for Tesla.
$ curl -si https://www.tesla.com/ | grep generator
x-generator: Drupal 9 (https://www.drupal.org)
$ curl -si https://www.tesla.com/authorize.php | grep generator
x-generator: Drupal 7 (http://drupal.org)
The webroot appears to be a Drupal 7.x installation and Apache is serving that content directly (e.g. https://www.tesla.com/MAINTAINERS.txt same as [2]) and trying to run some of it (authorize.php), while happy-path requests are being reverse-proxied to a Drupal 9.x installation.
[1] https://github.com/drupal/drupal/blob/7.x/authorize.php
[2] https://github.com/drupal/drupal/blob/7.x/MAINTAINERS.txt
https://www.tesla.com/careers/search/job/sr-software-enginee...
A server crashing implies that the server program or process itself has terminated, and is not able to handle further requests. This usually manifests as a 503 error by an upstream proxy server (nginx/apache/CDN/etc.).
IME they're almost always completely separated from the "real" systems that engineers are working on / managing. A compromise wouldn't go far, in the backend. Something like XSS would be worse.
Always seems to come from some push to "running a website isn't our 'core focus' so we should vendor that" … or something. I've also encountered immense push-back on eng-managed corp websites: all those pesky best practices get in the way of just shoveling "content" (i.e., PR) out. And so it ends up separated from eng.
Usually these marketing sites are running a CMS (this one looks like Drupal) which is owned and operated by either an internal team who report to the CIO / IT department (vs the Product/Engineering group) or a totally external third-party marketing firm.
As long as the "real" product uses different subdomains, certificates, proper HSTS, cross-origin protection, and secure cookies (a tall order, yes, but something that would be an issue no matter what the marketing site is doing), security issues in the "marketing" site aren't as bad. Of course a marketing site takeover is still worrying, as it's a prime entry point for spearphishing and horizontal movement through social engineering, but these usually aren't the same engineers or security team at all.
What are you expecting here?
Saved version:
TypeError: Cannot read property '0' of null
at forceFontAssetSource (/app/routes/middleware/moduleVersion.js:89:32)
at Layer.handle [as handle_request] (/app/node_modules/@tesla/design-system-tools/node_modules/express/lib/router/layer.js:95:5)
at trim_prefix (/app/node_modules/@tesla/design-system-tools/node_modules/express/lib/router/index.js:317:13)
at /app/node_modules/@tesla/design-system-tools/node_modules/express/lib/router/index.js:284:7
at Function.process_params (/app/node_modules/@tesla/design-system-tools/node_modules/express/lib/router/index.js:335:12)
at next (/app/node_modules/@tesla/design-system-tools/node_modules/express/lib/router/index.js:275:10)
at cors (/app/node_modules/cors/lib/index.js:188:7)
at /app/node_modules/cors/lib/index.js:224:17
at originCallback (/app/node_modules/cors/lib/index.js:214:15)
at /app/node_modules/cors/lib/index.js:219:13https://www.snopes.com/news/2022/11/17/elon-musk-emerald-min...
> Here's a summary of our findings: We located reporting from as far back as 2009 and 2014 that said when Elon Musk ("Elon" herefafter) was a child in South Africa in the 1980s, his father ("Errol" hereafter) at some point owned "a stake in an emerald mine" near Lake Tanganyika in Zambia, not South Africa. Beyond that, we were unable to find any evidence that showed money generated from his father's involvement in the mine helped Elon build his wealth in North America.
I'll add that it's also well known that while Elon's father was certainly well off compared to the average population in South Africa, they were not fabulously rich. They were also anti-apartheid. His father's personal income was primarily from being an engineer, not a mine owner.
Hence why they are commenting and screaming everyday at Elon, letting him reign in their minds rent free; which I find quite hilarious on this site, Twitter and elsewhere.
I'm just laughing at the entire chaos being covered 24/7, and especially laughing at the angry 'dorks' attempting to escape it all; which they are unable to.
This isn’t about Musk, and it’s not about Twitter-actual. It’s about Twitter-meaningful, which is to say a way since 2008 or so of controlling messages.
Elon makes a bunch of moves and posts that all revolve around pruning the company. And it’s become “omg he wants code printed, he’s so stoopid!”.
If I was going to prune a company, I would do the exact same thing to immediately weed out the people that came (figuratively) empty handed. They know they’re done and it would save me the time.
I'd have figured that they would have rolled out their own custom headless CMS or something really complex. I mean, not that it doesn't make sense for them to use a bog-standard CMS tool, but my biases (halo effect?) would have made me think that they use something more more unique.
But among people who do this kind of thing for a living, there's a belief that every action you take (like copy a .gitignore file to the directory from which static files are served) should have an intent which can be traced to a specific requirement.
It's crazy to believe some product manager sat down and put "serve up a .gitignore file" in their PRD. Some people are therefore taking the existence of the .gitignore file in Tesla's public webspace to demonstrate a lack of care when it comes to matching requirements with behaviour.
But as people have pointed out, maybe this isn't a Tesla failing as much as it is a failing for one of their providers. And sure, on the list of failures, this is pretty minor. And if you can find a web host that ties behaviour to explicit requirements, I would LOVE to hear about it. Web hosting is a low margin business which doesn't pay premiums for detail oriented staff. To be sure, there are some AMAZING people working for web hosting outfits, but my point is they are working at web hosting firms in spite of their technical capabilities, not because of them.
To say Tesla is a crap-fest because they left a .gitignore in their public web-space is laughable. Tesla is a crap-fest because their stock is in the toilet, they often blow past promised delivery dates (cybertruck, anyone?) and are extracting cash from the rubes who believe "full self driving" means your car will drive itself in more than the most contrived of contexts.
Elon Musk is not an idiot because you can read a .gitignore from tesla.com. Having done business w/ Mr. Musk, I can assure you he is not an idiot. But he's also did not impress me as the super-genius many seem to make him out to be. He is not playing 4D chess. He's a reasonably intelligent guy who won the lottery (rich parents, older brother who cut him in for a percentage, met the right people just as the USG wanted to buy more launch capability and state and federal governments subsidizing electric cars.) If anything, he's uncanny in his ability to identify opportunity. Maybe that's even better than the Sili Valley execs whose skills extend to being white, pretty and GSB educated. (If you downvote me, please downvote me for the slight on the Haas School this last comment was intended to be.)
To recap... serving a .gitignore in your public web-space doesn't mean you're a dolt. It also means you're probably taking less care than you could. But maybe we don't need to take such care on a static web-site. But it does make me wistful for the days when competence was more obviously exhibited.
Elon Musk is considered a jerk because of his behaviour, not because someone in one of his companies left tesla.com/.gitignore in the public web-space. Tesla is not god's gift to American industry. It is a bit of a goose up the backside of entrenched incumbents, and for that I will always have a soft spot for it. Except for the bits where they seem to be a lightning rod for controversy which always seem to be unforced errors.
Good Day To You, Sir!
I think this is the lens the OP wanted readers to view this post through.
Now imagine what Elon would tweet if he discovered the same mistake on a Twitter subdomain.
News about Tesla's security seems vaguely wanting, I do not know what this .gitignore file is about, but it is quite alarming enough to draw conclusions from.