
Global scan – exposed .git repos - Bedon292
https://lynt.cz/blog/global-scan-exposed-git
======
AgentME
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).

------
NickBusey
_" 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
> 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)

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

Utter nonsense. Who told you this?

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

------
C_Sto
Internet wache performed similar analysis in 2015 -
[https://en.internetwache.org/dont-publicly-expose-git-or-
how...](https://en.internetwache.org/dont-publicly-expose-git-or-how-we-
downloaded-your-websites-sourcecode-an-analysis-of-alexas-1m-28-07-2015/)

I performed similar research in April - [https://blog.hivint.com/exposed-git-
repos-on-the-ipv4-addres...](https://blog.hivint.com/exposed-git-repos-on-the-
ipv4-address-space-61cf8838e424)

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

------
Assadi
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
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

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

~~~
ktpsns
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-l...](https://stackoverflow.com/questions/160608/do-a-git-export-like-
svn-export)), but nevertheless "git pull/push" is an easy way to keep the
production server code synced. It is certainly not the best.

~~~
wongarsu
>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
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.

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

~~~
jolmg
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.

~~~
pjc50
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)

~~~
jolmg
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.

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

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

------
bdcravens
Article now redirecting to a different unrelated article.

cached:

[https://webcache.googleusercontent.com/search?q=cache:wIEQNW...](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)

~~~
dang
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...](https://www.scmagazine.com/400000-websites-vulnerable-through-
exposed-git-directories/article/793787/).

