Global scan – exposed .git repos | Hacker News Reader

Global scan – exposed .git repos

lynt.cz

62 pointsBedon29240 comments

A similar issue I've found before on live sites: people exposing the source of php of files through backup files named with the ~ suffix produced by editors like Emacs or vim. In a standard LAMP stack, files with names ending in ".php" get executed and don't have their raw contents exposed, but files with names ending in ".php~" get no special treatment. If the admin uses Emacs or vim to edit any php files directly on the server, then ".php~" files will be produced which will be accessible by default. If a page has a URL like example.com/foo.php, then example.com/foo.php~ may be accessible and expose the source code (and possibly database credentials, etc).

"After sending the emails, I exchanged about 300 additional messages with affected parties to clarify the issue. I have received almost 2,000 thank-you emails, 30 false positives, 2 scammer/spammer accusations, and 1 threat to call the Canadian police," Smitka said.

> 1 threat to call the Canadian police

Fairly good hit rate. People have been jailed for performing "unsolicited pentesting" before. And @malwaretech is currently stuck in the US indefinitely for intervening in the WannaCry command-and-control system.

(fixed handle, sorry)

Can you elaborate or give some links about that malwarebytes statement? I'd really like to read up about that.

Wrong name, sorry. https://www.wired.com/story/wannacry-malwaretech-arrest/

That article contradicts your claim that he was arrested "for intervening in the WannaCry command-and-control system".

Upon his arrest, the Department of Justice unsealed an indictment against Hutchins, charging that he created the Kronos banking trojan, a widespread piece of malware used to steal banking credentials for fraud.

Ah I knew about that. I thought you meant the actual company malwarebytes was like stuck in the US and couldn't go overseas or something.

Its @malwaretech/malwaretechblog, not malwarebytes.

https://twitter.com/MalwareTechBlog

>malwaretech is currently stuck in the US indefinitely for intervening in the WannaCry command-and-control system.

Utter nonsense. Who told you this?

Not sure why your getting downvoted. GP is spreading FUD.

I got one of his emails. Send a thank you email and some beer money as a thank you. Funny to see it on HN now.

Internet wache performed similar analysis in 2015 - https://en.internetwache.org/dont-publicly-expose-git-or-how...

I performed similar research in April - https://blog.hivint.com/exposed-git-repos-on-the-ipv4-addres...

I get the feeling this problem isn't going away any time soon...

Haha, maybe I should have written this article.

I ran into this on a couple of legacy CodeIgniter applications that I was rewriting for a small Swedish company and had such a visceral level of shock and disgust when I realised all the production servers contained a publicly accessible ".git" folder.

Worst of all, people had been committing database details. So, not only was the source code for all the applications public, all the user data effectively was too (and, let me tell you, those passwords were NOT hashed properly!).

it was so much fun when I discovered this same thing* at an earlier job and ops pushed back on it being a problem at all. to me it was insane to begin with to use "git pull on a cron job" as a "deployment" mechanism.

* even down to the "DB credentials + hostname/port to an Internet-exposed mysql server committed to the repo" detail

Why would you ever want to put a git repo on a production server in the first place? Unless you're using the production server for development (gasp) it sounds like a waste of space and (as pointed out here) a major security vulnerability.

This question basically restate the problem. It's not that people want to do that, they just don't know better

An answer for Subversion would be: Because "svn update" (http://svnbook.red-bean.com/en/1.8/svn.ref.svn.c.update.html) runs faster then "svn export" (http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.export.html).

For git there is not even an "export" option anymore (cf. https://stackoverflow.com/questions/160608/do-a-git-export-l...), but nevertheless "git pull/push" is an easy way to keep the production server code synced. It is certainly not the best.

>It is certainly not the best.

What is the better alternative? Git checkout makes reverting to a previous version fast and convinient, and git's protocol seems more efficient than transmitting the files via scp or similar since most of the files are already there.

I guess I could have a build server rsync the files over, but that seems like a lot of complexity for little gain.

Git doesn't ensure the checkout process is atomic; it might leave you with an unfinished mess if it fails for some reason.

Also, it means that everything you ever committed on the release branch will be available on a more exposed server.

>What is the better alternative?

This is a bit complicated to do by hand, but this is probably the best way. I would suggest using existing software to handle this though

Create a file that just has "2" with no quotes in it. Create a directory called 1. Create a symlink that points to that directory. Have the webserver use the symlink instead of the actual code directory.

When you want to update code lock the file that has the number in it. Read in the contents of the file. Replace the contents of the file with the next number. Unlock the file. Create a directory with whatever number you read in. Git clone in that new directory. Do whatever else you need to do (compilation or whatever). If all goes well then change a symlink to point to the new directory.

If you need to revert then change the symlink to the old directory. You could also delete old directories as well to save some space.

Using git pull (or some equivalent) to update a production environment is fragile and just asking for trouble.

I've seen someone SCP a local git repo to an Amazon EC2 (obviously not best practice) for a manual deployment.

You can go a long way toward avoiding the security issue by making good use of the GIT_DIR and GIT_WORK_TREE environment variables.

Certainly disabling access to directories like .git, .svn or .hg should be default in any webserver. It is a pity to see this option not active by default in a Debian/Ubuntu Apache2 installation, c.f. https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/... which mentions it (1) only for svn and (2) has it commented out.

I feel that'd be like shoemakers putting metal plates on top of their shoes to prevent bullets from penetrating when customers shoot themselves in the foot. It's silly. Those same customers could shoot themselves in the leg (another software they misuse and expose .git/ from), or hurt their foot via some other method that the plate can't protect from (expose other non-git sensitive information via the webserver; i.e. the webserver can't predict all ways it can be misused).

However, now I see you said it should be Ubuntu and not Apache that should do this default configuration. I guess that'd make a little more sense as Ubuntu could be interpreted in this analogy as the vendor of the boot, pants and gun, and is generally geared toward beginner cowboys.

The real solution, though, would be for the customers to learn to use the gun properly. If they shoot themselves, then that's valuable experience they can learn from. If you put the metal plate, they might go on without realizing they're shooting themselves.

The difference being in this situation, shooting yourself in the foot can cause loads of confidential user information to be stolen by someone exploiting this (when storing DB credentials in SCM)

In fact Debian ships Apache with a decent default setup which also allows further Debian packages to seamlessly hook into the configuration (with directories likes /etc/apache2/conf.available and /etc/apache2/conf.enabled and softlinks inbetween). Apache itself does not have any "default" configuration at all, it most likely also starts fine with an empty configuration file.

Of course "fixing" security problems at the level of the web server feels like adding a firewall to your server instead of avoiding daemons listening on public ports. It feels wrong. But it can be seen as another layer of security.

This kind of anti-safety sentiment isn't based on a real consideration of user needs, just a victim-blaming machismo. Reminds me of mongodb shipping exposed to the internet by default.

(You can of course buy shoes with metal plates in them to prevent injury, they're called "safety boots" and are mandatory in some workplaces)

I'm not anti-safety, I'm anti-bad safety design. I clarified the point of the analogy in a reply to another reply.

EDIT: You can't substitute gun safety knowledge with legislation that requires all things (and I mean all) to protect against gun misuse.

Defense-in-depth is not bad design, it's good design.

Uh.... steel toed boots are a very common thing?

It would be more like car makers building cars that won’t engage the starter motor if the transmission isn’t in Park, garage door openers reversing if they encounter too much resistance, or lawn mowers that won’t run if you don’t hold down a safety bar.

Which is to say, anti-footgun measures are extremely common anywhere foot-shooting is.

The difference here, and the main point of my analogy is that webservers and git are completely unrelated things like shoes and guns are. That all webservers should guard against misuse with another random piece of software is like having all shoes have protections specifically against a random product that's completely unrelated to shoes. Also, to take the analogy further, the original suggestion was to guard against specific directories .git, .hg, etc. That's like having all shoes protect against only specific models of guns and not others.

The point here is that if you want to take this methodology for security, then you'll have to come with an enumeration of all ways the user hurt himself and implement a safety measure for each. That's neither effective nor efficient. Think of all pieces of clothing being required to be bullet-proof, cut-proof, stab-proof, acid-proof, hunger-proof, suffocation-proof, smash-proof, etc. You can't have everything protect the user from everything else via having a safety mechanism for each model-specific thing.

How is that different from my examples where they protect against certain common dangers but don’t even attempt to protect against all the ways you can hurt or kill yourself with them?

That the safety mechanisms in your examples depend only of knowledge of the object's own mechanisms or generic "other things". For example, your garage door opener reverses when it encounters resistance from anything. It's not that it only reverses when there is one of a specific list of car models that are in its way, and continues to try to close when there is a human in its way or some other type of vehicle or thing. It'll work even if a new type of thing that never existed before gets in its way.

It's also different in that it doesn't limit the products functionality when it thinks that you want to make an exception to its primary purpose. A garage door opener is not going to refuse to open when you're trying to come in with a vehicle on fire.

A webserver serves files, and inside .git/ are files. You ask it to serve them, then its going to serve them. That you didn't realize you were coming into the garage with a vehicle on fire is no reason for the garage door opener to be required to implement a security mechanism for that very specific thing when there's loads more you could do without realizing.

I still don’t see the difference. Consider a lawnmower. Its purpose is to cut things. It doesn’t care whether it’s grass or hoses or feet. A common failure mode is to cut the user’s hands or feet. The safety bar helps prevent this. It doesn’t stop you from cutting other people’s hands or feet, and it’s easily bypassed if you want to cut your own, but it’s still a valuable safety feature because this particular accident is so common.

Likewise, serving .git is a common problem. Not serving it by default would prevent it. Why is that bad?

It's interesting to compare this behaviour against IIS. If Apache can't identify the MIME type of the requested file, it will serve it without a Content-Type header. IIS will return a 404 instead.

There's something to beig able to review/glance at website's code before commiting to using the website...

Just saying. There are other perspectives than the website owner's one.

Article now redirecting to a different unrelated article.

cached:

https://webcache.googleusercontent.com/search?q=cache:wIEQNW...

That's probably good since the article was basically blogspam of the original work. We changed the URL to that from https://www.scmagazine.com/400000-websites-vulnerable-throug....

Reply on news.ycombinator.com