There was a posting just this week on a job site for a "Sr. Software Engineer, Backend Drupal" at Tesla. Putting together pieces like a leaked .gitignore file, job postings, etc. is social engineering in action.
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.
Drupal is pretty powerful and there is a large talent pool for it, so it can probably handle all their CMS needs just fine. And that would be smart not to roll their own.
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.
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.
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.
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.
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.
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 :)
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.
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.
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.
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
> 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 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?
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).
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).
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?
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.
I wonder whether he’s just taking revenge upon the employees for mocking him buying it for 3x its revenue. “SEC wants me to buy it whole because I have 9%? Employees and board are happy to force my hand? Ok.”
Being suicidal and ready to lose everything to make a point, is probably another facet of the same character trait.
Nec audiendi qui solent dicere, Vox populi, vox Dei, quum tumultuositas vulgi semper insaniae proxima sit.
And those people should not be listened to who keep saying the voice of the people is the voice of God, since the riotousness of the crowd is always very close to madness.
Huh. Is there a name for when a widely quoted sentence fragment is used for the rhetorical opposite of the full original sentence? I feel like I’ve seen this happen before, but I can’t place where.
(Also, my favourite Latin to quote at anyone who quotes Latin: quin tu istanc orationem hinc veterem atque antiquam amoves?)
I'm almost certain that TVTropes has a trope for the more general case of quote use without considering the context, but I can't find it now.
My favourite is "neither a lender nor a borrower be", which gets trotted out as sage advice. It's a quote from Polonius in Hamlet, who is depicted as being an idiot.
We seem to have bottomed-out reply depth, but, to answer if there are other examples, the commonly misquoted "the proof is in the pudding" is the opposite of the correct one: "The proof of the pudding is in the eating."
My favorite "a few bad apples" is not a problem, which leaves out the second half: "ruin the bunch".
Especially when applied to police - the fact that the "boys in blue" turn a blind eye to the bad apples is what ruins the bunch. It's unintentionally accurate.
It's almost as if he's a world-class grifter who continually lies and whose entire net worth is predicated on keeping up an illusion of his own competence. The dude doesn't even have a physics degree, it's pure bullshit.
I come here to get away from the Reddit crowd. The last thing I want to see is for this site to turn into... that dumpster fire. It's not about being above anyone, it's about setting a tone for a community.
So basically you run an endless script to fetch https://www.tesla.com/sites/default/settings.php and hope that some day there will be a minor nginx config error which lets you download the php source instead of executing it.
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 :-)
Yeah, but if a gitignore tells you where to look for, and it isn't even blocked by a WAF / rule, it makes an interesting target, esp. one of the largest companies out there.
You shouldn't even be able to execute settings.php
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
How is it a good sign of anything like that? File upload to disk is a completely unrelated concept that depends on how php is invoked by the web server.
Sure, I'm just saying it makes an executable file upload more likely. Because if a file like settings.php is executable by Apache, it implies that (at least in this directory) any .php file is executable by Apache, rather than a single whitelisted index.php or some wsgi setup.
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.
This comment transported me back to 2010 or thereabouts when this happened to Facebook. I remember being surprised at the simplicity of the code and making a lot of jokes about "build a facebook clone" ads on freelance websites.
Except that you'll find that error long before the cybertruck ships. Heck, you'll probably see the rebirth of NFTs and BTC over US$40000 before the cybertruck ships.
The gitignore explicitly called out where the sensitive settings file is, so presumably that makes it a lot easier to figure out where to start injecting bad code
This shows that the teams in charge of code deployment have relatively weak quality control.
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.
I'd be pretty surprised if the marketing / landing site was remotely connected to the user portal. Most companies have a marketing-friendly CMS for public content, disconnected from the actual customer-facing portal.
What makes you think that there is some "substantial risk"? You seem to be mixing together git repos and site deployment rules. I don't see the big deal here with some CMS leftovers being deployed, but yes from a perspective of correctness this is not something that needs to be deployed.
It's leaky because it's globally accessible and provides information that isn't otherwise readily apparent.
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'm gonna give my counter take. Information disclosure is something that the DevSecOps(tm) crowd spends a disproportionate amount of time on for little benefit. The number of security professionals who don't know how to code, but learned Nessus or CrowdStrike and criticize others is too damn high.
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.
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.
> 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
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.
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?
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.
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.
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 a bit of an information leak, but probably not a particularly serious one. It just gives some information about what tech stack they're using, which isn't really public but also not that hard to find out, and maybe a bit about where an attacker would want to look for other sensitive stuff. Pretty minor really, on its own.
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.
you could theoretically social engineer until you find something to exploit
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
At least https://www.tesla.com/.git/config is not accessible but still. This should never happen to a company that considers itself a software company first and a car company second.
No. You never checkout a site directly from git to begin with.
You don't let other people know what files are ignored from git doesn't mean people cannot access them. :/
It doesn't even mean it's not in source control. It just means that IF it's not in source control it won't be added to a change set automatically. gitignore has no effect on files which are already tracked, and even files which are not currently tracked can be explicitly added.
You're joking of course, but that likely won't do anything useful.
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.
I do not trust Tesla because of the apparent instability of its owner, but not because its website does not use the most bleeding edge web technology. The website works and I see no information of any security flaws. This is what matters.
Does Elon personally drive every Tesla? Or do you think Tesla engineers will follow an insane directive knowing it would put peoples lives at risk and not push back or straight up walk off the job?
> Or do you think Tesla engineers will follow an insane directive knowing it would put peoples lives at risk and not push back or straight up walk off the job?
By this logic, it's actually impossible for a company to ever do anything wrong.
I mean, in fairness, if you're not getting enough rest (which seems to be what "hardcore engineering" means) then maybe you're more likely to screw up the nginx config.
Not to defend the Twitter situation, which is foolhardy by almost any measure, but it's extremely uncommon for any company's main landing page to relate in any way to their software engineering team.
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.
Nobody (sane) is saying this is a security vulnerability or the like (especially as it seems to be a default Drupal gitignore). It's just a funny mistake from a "software first" company.
100%. Tacking on to this, the last few places I've been the public facing site was usually managed by the marketing or design team, and often was used as a project to get them to touch _some_ code. Engineering rarely ever got involved with this if ever. If not them; probably a third-party firm.
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.
Yeah. WordPress, Drupal, Joomla, Laravel, vanilla php. Together they power almost 45-50% of the web. So PHP is still extremely relevant. The most relevant you might be able to say.
314 comments
[ 2.0 ms ] story [ 330 ms ] threadI'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.
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.
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.
Being suicidal and ready to lose everything to make a point, is probably another facet of the same character trait.
Nec audiendi qui solent dicere, Vox populi, vox Dei, quum tumultuositas vulgi semper insaniae proxima sit.
And those people should not be listened to who keep saying the voice of the people is the voice of God, since the riotousness of the crowd is always very close to madness.
(Also, my favourite Latin to quote at anyone who quotes Latin: quin tu istanc orationem hinc veterem atque antiquam amoves?)
My favourite is "neither a lender nor a borrower be", which gets trotted out as sage advice. It's a quote from Polonius in Hamlet, who is depicted as being an idiot.
Especially when applied to police - the fact that the "boys in blue" turn a blind eye to the bad apples is what ruins the bunch. It's unintentionally accurate.
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.
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
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
By 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.
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?
- 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:
- https://www.tesla.com/.editorconfig
- https://www.tesla.com/profiles/README.txt
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.
Yes PHP is still relevant!