Slashdot Mirror

← Back to Stories (view on slashdot.org)

400,000 Websites Vulnerable Through Exposed .git Directories (scmagazine.com)

Posted by msmash on from the security-woes dept.

Open .git directories are a bigger cybersecurity problem than many might imagine, at least according to a Czech security researcher who discovered almost 400,000 web pages with an open .git directory possibly exposing a wide variety of data. From a report: Vladimir Smitka began his .git directory odyssey in July when he began looking at Czech websites to find how many were improperly configured and allow access to their .git folders within the file versions repository. Open .git directories are a particularly dangerous issue, he said, because they can contain a great deal of sensitive information. "Information about the website's structure, and sometimes you can get very sensitive data such as database passwords, API keys, development IDE settings, and so on. However, this data shouldn't be stored in the repository, but in previous scans of various security issues, I have found many developers that do not follow these best practices," Smitka wrote. Smitka queried 230 million websites to discover the 390,000 allowing access to their .git directories. The vast majority of the websites with open directories had a .com TLD with .net, .de, .org and uk comprising most of the others.

35 comments

  1. .htaccess by Anonymous Coward · · Score: 0

    # protect git directories
    RedirectMatch 404 /\.git

    1. Re:.htaccess by MidSpeck · · Score: 2, Informative

      ^/.*/\.git/
      Protect git repositories in all subdirectories as well.

    2. Re: .htaccess by Anonymous Coward · · Score: 0

      Four hundred thousand websites isnâ(TM)t that many

    3. Re: .htaccess by Anonymous Coward · · Score: 0

      Just one server at some hosting companies. ;-)

    4. Re: .htaccess by Anonymous Coward · · Score: 0

      None of those sites probably even use git and moved on to something else a long time ago.

    5. Re:.htaccess by jrumney · · Score: 1

      Why stop there? Are there any dot files/directories that need to be served over HTTP?

    6. Re: .htaccess by spongman · · Score: 2

      Why doesn't Apache block all '.'-prefixed directories by default?

  2. https://slashdot.org/.git by Anonymous Coward · · Score: 0

    https://slashdot.org/.git

    Yeah, I was surprised...

    1. Re:https://slashdot.org/.git by ls671 · · Score: 3, Informative

      Slashdot is still using CVS try https://slashdot.org/CVS/

      you will see, it works! :)

      --
      Everything I write is lies, read between the lines.
  3. Your central git repo ... by Qbertino · · Score: 0

    ... belongs behind ssh or, at least, behind http access and SSL.
    If I catch you doing otherwise for anything other than FOSS software I'll smack you. Hard.

    --
    We suffer more in our imagination than in reality. - Seneca
    1. Re:Your central git repo ... by Anonymous Coward · · Score: 0

      ... belongs behind ssh or, at least, behind http access and SSL.
      If I catch you doing otherwise for anything other than FOSS software I'll smack you. Hard.

      “Distributed” - look it up.

      The correct answer is to block access via permissions/web server directives.

    2. Re:Your central git repo ... by tlhIngan · · Score: 3, Informative

      ... belongs behind ssh or, at least, behind http access and SSL.
      If I catch you doing otherwise for anything other than FOSS software I'll smack you. Hard.

      And it probably is. The thing is, the website owners are using git to version control and deploy their website (not a bad idea). So they develop their web site, push it to the central git repo, and whenever they need to go live, they just do a "git pull" on the webserver and it'll pull down the latest version of the website.

      Problem is, they forget about the hidden .git directory git makes that stores all sorts of useful information and with a little persistence, allow you access to the raw source code since you can access the individual git objects. (Or maybe even clone it using git).

    3. Re:Your central git repo ... by jrumney · · Score: 1

      I do this, it is very convenient for deploying updates to the site. But I always put the web interface into a subdirectory, and only configure the web server to see that so the .git directory is not visible over HTTP. And dotfiles and directories are blocked in the webserver config for extra protection against accidental inclusion of invisible files.

  4. Visual source safe by Anonymous Coward · · Score: 0

    I use visual source safe so I don't have to worry about .git files.

  5. reheating yesterday's food by Tsolias · · Score: 2

    just an article from 2015 https://en.internetwache.org/d...

    I can give you also next year's article about .file vulnerabilities. (spoiler alert) https://en.internetwache.org/s...

    1. Re: reheating yesterday's food by Anonymous Coward · · Score: 0

      meh, I wrote about this exact thing in 2009 in svn and updated for git and hg in 2013.

  6. Only morons by Anonymous Coward · · Score: 0

    copy/paste from source to target, or even worse directly edit in the target

    Thats what you get on hiring those bootcamp "graduates"

  7. KKK by Tsolias · · Score: 1

    Thats what you get on hiring those bootcamp "graduates"

    Kode w/ Karlie Kloss, like it or not.

  8. Here yourz mess shell scriptz by Anonymous Coward · · Score: 0

    for g in $(grep '.git$' mylist.txt) ; do git clone $g ; done

  9. Alternate headline: 99.8% websites are OK by jmichaelg · · Score: 1

    230 million websites. 400k poorly configured. 4*10^5/2.3*10^8 is less than 0.2% of websites surveyed screwed this up.

    400k is a big number but it's good to know most developers aren't that stupid on this issue.

    1. Re:Alternate headline: 99.8% websites are OK by Anonymous Coward · · Score: 0

      Except:

      • The summary say he only looked at Czech websites, so your 230 million should be lowered to count(Czech websites)
      • You calculate the git-screw-ups against the total amount of websites, not against the amount of websites using git - so it does not tell anything about the percentage of stupid developers
  10. yarn dist by Anonymous Coward · · Score: 0

    who pushes their .git to production?

    1. Re: yarn dist by TimMD909 · · Score: 1

      ... Equifax types for free security tests from 3rd parties and press coverage, presumably...

  11. So? by cshark · · Score: 1

    An open git directory will be everything you need to reconstruct the site, more often than not from the same server you're targeting. Scary. Database servers are rarely open. Short of some serious hacking, there isn't a lot you're going to be able to do with this stuff once you've obtained the information you're waving around here.

    Until such time as I see hackers actually logging in with this information and defacing github, I'm going to remain unconvinced of the severity of this one.

    --

    This signature has Super Cow Powers

    1. Re:So? by OrangeTide · · Score: 1

      My website's .git directories are open intentionally. Makes for convenient mirroring and viewing of archives without having to hope and pray wayback machine picked up my obscure website.

      I'm not too worried. It's just data on the filesystem, it's not executing programs. And the data is not supposed to contain any secrets. If it ever does then I better rewrite my git history.

      --
      “Common sense is not so common.” — Voltaire
    2. Re:So? by Anonymous Coward · · Score: 1

      The most likely actual security implication is hard coded keys to 3rd party APIs.

      Not that this is an inevitable threat, itâ(TM)s just something I could see being inadvertently exposed and useful without much additional effort.

    3. Re:So? by jonwil · · Score: 1

      What about if that .git folder (and the website's source code) included private keys for stuff. Or credentials/API keys for 3rd party services. Or credentials for database and other servers.

    4. Re:So? by Orrin+Bloquy · · Score: 1

      itâ(TM)s

      Clear something up, are you typing curly quotes/apostrophes on purpose or do you have your browser configured to automatically do that.

      --
      "Made up/misattributed quote that makes me look smart. I am on /. and I must look smart."
    5. Re:So? by Anonymous Coward · · Score: 0

      Not just rewrite your git history, but purge the offending files from the git directory. That's the tricky part - many people probably don't realize that git doesn't delete "unreachable" commits immediately; it keeps them around (for 30 days, IIRC) in case you change your mind.

      Depending on the circumstances, you'd need to be sure that not only are the offending files themselves deleted, but also any references to their SHA-1 hashes.

      I'm sure there are git commands to do these things, but I wouldn't know how to do so in a hurry.

    6. Re:So? by OrangeTide · · Score: 1

      obviously I would 'git gc'. Not my first rodeo.

      --
      “Common sense is not so common.” — Voltaire
  12. Boss says "NO MORE GIT!" by Anonymous Coward · · Score: 0

    You know this is coming...

  13. Web Sites Gone Wild! by Anonymous Coward · · Score: 0

    Exposed websites? That's hottt.

  14. I feel like porn. by MJhasHIV · · Score: 0

    Had something to do with this somehow....

  15. No need to have .git folders in webroot by Anonymous Coward · · Score: 0

    I'm using git for site backups via --git-dir and --work-tree. In my case, the git directories are located on a completely different (NAS) mountpoint.

    For deployment I use git archive in a one-liner that builds a tarball, uploads it to the site, unpacks it, deletes old files and removes said tarball.

    For bonus points you can shove that into a cron job that automatically checks out master and you never need to worry about it (I have it in a Makefile).