Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

One in every 600 websites has .git exposed

jamiembrown.com

Post reply on HN
Print view View original

181–190 of 214 posts

Re: One in every 600 websites has .git exposed

#181

Post by leftnode »

juliangregorian wrote: post #158
vog wrote: post #145

Earlier quoted context omitted.

You seem to imply this is a novel attack vector. But it's really just an instance of a very old mistake: Don't use the root of your app as document root! It's really as simple as that. Almost all modern apps have a subdirectory "public/" or similar. That one is meant to be used as document root. You only have to ensure there are no sensitive files in there . If you fail to introduce such a directory, you'll have a ga…

Great point. How much do you want to bet most of these are PHP, where it takes special discipline not to make your top directory web-accessible?

Very simple setup. You have:

    .git
    web/index.php
    src/*.php
Make the document root /full/path/to/web/index.php.

Edit: Also use a deployment tool like Capistrano which removes the .git directory as well.

Re: One in every 600 websites has .git exposed

#183

Post by [deleted] »

pmx wrote: post #172
juliangregorian wrote: post #158

Earlier quoted context omitted.

Great point. How much do you want to bet most of these are PHP, where it takes special discipline not to make your top directory web-accessible?

It takes very little effort in php. You simply have your index.php and any public assets in the document root and then use index.php as a bootstrap to bring up your application. Everything else goes outside of the document root.

[deleted]

Re: One in every 600 websites has .git exposed

#184

Post by vog »

leftnode wrote: post #181
juliangregorian wrote: post #158

Earlier quoted context omitted.

Great point. How much do you want to bet most of these are PHP, where it takes special discipline not to make your top directory web-accessible?

Very simple setup. You have: .git web/index.php src/*.php Make the document root /full/path/to/web/index.php. Edit: Also use a deployment tool like Capistrano which removes the .git directory as well.

Yes, it is easily avoided. But it is still violated by lots of PHP projects, including well-known projects with large userbases:

    * Wordpress
    * Tiki
    * ... and so on.
I don't think this is by accident: This technique is too old and well-known to be ignored by large projects. Rather, they conciously don't do that to cause less hassle for the occasional admin: Those can simply dump it into some directory and don't have to setup a proper docroot or anything. And extra work for those who want a more secure setup.

This is clearly a usability versus security issue, resolved in the unfortunate, usual way.

Re: One in every 600 websites has .git exposed

#185

Post by err4nt »

Negitivefrags wrote: post #117
phantom_oracle wrote: post #30

Imagine you implement every type of possible security... Keeping your entire server-stack up-to-date, making sure you have SSL, using strong encryption for logging-in, hashing the passwords, making sure your server can only be reached via SSH, adding firewalls, filters, etc. etc. Then some hacker in Eastern Europe comes along (or some beginner at the NSA/GCHQ) and finds out that your .git is exposed and somehow gains…

This is the asymmetric nature of security in general. You only need to make a single mistake and you are hosed. Your attacker can fail an arbitrary number of times and only needs to succeed once. If you are 99.9% likely to make the right call on anything that could have a security impact then you only need to make 1000 decisions before you probably screwed one up and have a hole. Some would say this means true securi…

As humans are fallible, it's inevitable we will make mistakes carrying out even what we intend to do, when we know it and are actively trying to do the right thing.

Sometimes our mistakes are not recognizing the right thing to be done, or not recognizing anything at all.

I think the view that true security is impossible is true if security is up to one person. What about a system with multiple layers of sign-off, or an automated system that can help test the security of what you're doing and alert/prevent dangerous behaviour without specific reasons.

Re: One in every 600 websites has .git exposed

#186

Post by err4nt »

ForHackernews wrote: post #101
nostrademons wrote: post #51

Earlier quoted context omitted.

You probably should revoke all your existing credentials and replace them with fresh ones as soon as you pull them out of the VCS. That way, your attackers have the credentials, but they don't work anymore.

We've left test keys in our git repos. They don't work for anything except a virtual machine used for local development, but I always thought it would be amusing if a hacker grabbed them and got frustrated trying to use them.

So you leave them in as a kind of poisoned honeypot. They'll go right to the wrong info....

I'm sure you've daydreamed of the facial expression of the scriptkiddie the moment he stumbles across your fake keys illicitly, only to be disappointed hours of unfruitful hacking later :)

Re: One in every 600 websites has .git exposed

#187

Post by err4nt »

cddotdotslash wrote: post #109
dangero wrote: post #68

Earlier quoted context omitted.

Where is the right place to store db passwords, api keys, etc? What is best practice in this area?

I use AWS for a number of applications, so I've started doing the following: 1. Create a JSON file containing encrypted secrets (DB pass, etc.) 2. Upload the file to a secure S3 bucket with fine-tuned permissions and server-side encryption 3. For the instance that is launching, include the permission in the IAM role that allows it to "S3:GetObject" on the specific JSON file you uploaded. 4. Deliver decryption keys to…

This system is truly beautiful, I think one of the best suggestions in the thread (definitely the best self-rolled solution not using other tools)

I have a question about redundancy or "What happens if your gatekeper EC2 instance goes down"? If you have multiple gatekeepers could they be set up this way:

- let's say you have five different web apps using a gatekeeper to hold their secrets

- let's say you have n gatekeepers (let's say 3) and each of the apps knows the address of all three gatekeepers.

- If the primary gatekeeper is unreachable, all five apps would try to contact the secondary gatekeeper, but that gatekeeper would only (ever) respond in the event that the secondary gatekeeper also found the primary gatekeeper unreachable.

It's like a sleeper cell - at any given moment you have multiple replacement gatekeepers ready and waiting to serve, but each of them is unable to respond unless the one above it in the list stops responding. In this way you could lose gatekeepers (even permanently) and build a little bit of resilience into the apps depending on it while you're able to sort out what happened and restore normal behaviour.

Is this a good idea?

Re: One in every 600 websites has .git exposed

#190

Post by jbeales »

vog wrote: post #184
leftnode wrote: post #181

Earlier quoted context omitted.

Very simple setup. You have: .git web/index.php src/*.php Make the document root /full/path/to/web/index.php. Edit: Also use a deployment tool like Capistrano which removes the .git directory as well.

Yes, it is easily avoided. But it is still violated by lots of PHP projects, including well-known projects with large userbases: * Wordpress * Tiki * ... and so on. I don't think this is by accident: This technique is too old and well-known to be ignored by large projects. Rather, they conciously don't do that to cause less hassle for the occasional admin: Those can simply dump it into some directory and don't have t…

I don't have insight into the decision-making at WordPress, but they probably do this because they want to be compatible with as many web hosts as possible, and so many super-cheap shared hosts just give you a public directory that you're supposed to dump everything in.

It's possible to set it up properly on most of these hosts, but it's much more difficult, and if you ever have issues the support team says you're using a "non-supported configuration." At least WordPress lets you move your config file one level above the webroot and will find it automatically.

Post reply on HN