13 ms·

Global scan – exposed .git repos

62 points by Bedon292 8y ago

Assadi 8y ago
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!).
- tomjakubowski 8y ago
  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
NickBusey 8y ago
"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.
- pjc50 8y ago
  > 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)
  - Rotdhizon 8y ago
    Can you elaborate or give some links about that malwarebytes statement? I'd really like to read up about that.
    - pjc50 8y ago
      Wrong name, sorry. https://www.wired.com/story/wannacry-malwaretech-arrest/ https://www.wired.com/story/wannacry-malwaretech-arrest/
      - yorwba 8y ago
        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.
      - Rotdhizon 8y ago
        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.
  - bradstewart 8y ago
    Its @malwaretech/malwaretechblog, not malwarebytes. https://twitter.com/MalwareTechBlog https://twitter.com/MalwareTechBlog
  - ryanlol 8y ago
    >malwaretech is currently stuck in the US indefinitely for intervening in the WannaCry command-and-control system. Utter nonsense. Who told you this?
    - baby 8y ago
      Not sure why your getting downvoted. GP is spreading FUD.
- halotrope 8y ago
  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.
C_Sto 8y ago
Internet wache performed similar analysis in 2015 - https://en.internetwache.org/dont-publicly-expose-git-or-how-we-downloaded-your-websites-sourcecode-an-analysis-of-alexas-1m-28-07-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-address-space-61cf8838e424 https://blog.hivint.com/exposed-git-repos-on-the-ipv4-addres... I get the feeling this problem isn't going away any time soon...
bdcravens 8y ago
Article now redirecting to a different unrelated article. cached: https://webcache.googleusercontent.com/search?q=cache:wIEQNWhJWn0J:https://www.scmagazine.com/400000-websites-vulnerable-through-exposed-git-directories/article/793787/+&cd=2&hl=en&ct=clnk&gl=us https://webcache.googleusercontent.com/search?q=cache:wIEQNW...
- dang 8y ago
  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-through-exposed-git-directories/article/793787/ https://www.scmagazine.com/400000-websites-vulnerable-throug....
ktpsns 8y ago
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/apache2/trusty/view/head:/debian/config-dir/conf.d/security https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/... which mentions it (1) only for svn and (2) has it commented out.
- jolmg 8y ago
  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.
  - judge2020 8y ago
    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)
  - ktpsns 8y ago
    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.
ashton314 8y ago
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.
- nooyurrsdey 8y ago
  This question basically restate the problem. It's not that people want to do that, they just don't know better
- ktpsns 8y ago
  An answer for Subversion would be: Because "svn update" (http://svnbook.red-bean.com/en/1.8/svn.ref.svn.c.update.html 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 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-like-svn-export 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.
  - wongarsu 8y ago
    >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.
    - icebraining 8y ago
      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.
megous 8y ago
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.
AgentME 8y ago
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).

62 points by Bedon292 8y ago

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!).

tomjakubowski 8y ago
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

NickBusey 8y ago

"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.

pjc50 8y ago
> 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)
- Rotdhizon 8y ago
  Can you elaborate or give some links about that malwarebytes statement? I'd really like to read up about that.
  - pjc50 8y ago
    Wrong name, sorry. https://www.wired.com/story/wannacry-malwaretech-arrest/ https://www.wired.com/story/wannacry-malwaretech-arrest/
    - yorwba 8y ago
      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.
    - Rotdhizon 8y ago
      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.
- bradstewart 8y ago
  Its @malwaretech/malwaretechblog, not malwarebytes. https://twitter.com/MalwareTechBlog https://twitter.com/MalwareTechBlog
- ryanlol 8y ago
  >malwaretech is currently stuck in the US indefinitely for intervening in the WannaCry command-and-control system. Utter nonsense. Who told you this?
  - baby 8y ago
    Not sure why your getting downvoted. GP is spreading FUD.
halotrope 8y ago
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.

C_Sto 8y ago

Internet wache performed similar analysis in 2015 - https://en.internetwache.org/dont-publicly-expose-git-or-how-we-downloaded-your-websites-sourcecode-an-analysis-of-alexas-1m-28-07-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-address-space-61cf8838e424 https://blog.hivint.com/exposed-git-repos-on-the-ipv4-addres... I get the feeling this problem isn't going away any time soon...

bdcravens 8y ago

Article now redirecting to a different unrelated article. cached: https://webcache.googleusercontent.com/search?q=cache:wIEQNWhJWn0J:https://www.scmagazine.com/400000-websites-vulnerable-through-exposed-git-directories/article/793787/+&cd=2&hl=en&ct=clnk&gl=us https://webcache.googleusercontent.com/search?q=cache:wIEQNW...

dang 8y ago
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-through-exposed-git-directories/article/793787/ https://www.scmagazine.com/400000-websites-vulnerable-throug....

ktpsns 8y ago

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/apache2/trusty/view/head:/debian/config-dir/conf.d/security https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/... which mentions it (1) only for svn and (2) has it commented out.

jolmg 8y ago
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.
- judge2020 8y ago
  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)
- ktpsns 8y ago
  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.

ashton314 8y ago

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.

nooyurrsdey 8y ago
This question basically restate the problem. It's not that people want to do that, they just don't know better
ktpsns 8y ago
An answer for Subversion would be: Because "svn update" (http://svnbook.red-bean.com/en/1.8/svn.ref.svn.c.update.html 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 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-like-svn-export 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.
- wongarsu 8y ago
  >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.
  - icebraining 8y ago
    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.

megous 8y ago

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.

AgentME 8y ago

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).