Using ZAP to find .git/, .svn/

[Louis Dion-Marcil]

Hi list,

So recently I've been trying finding lots of git and svn repos on my clients websites. I'd like to get ZAP to report those for me. Right now I'm using ZAP as a daemon and I configured the spider to look for svn and git repos, combined with the Application Source Code Disclosure plugin. However that's not exactly what I want...  It seems this setup will warn me only when source code has been found but not when actual repositories are found. I would an active scanner to look for repos and warn me when they have been found. Right now I am using python to check the JSON at http://zap/JSON/core/view/sites and look for .git folders, which is really a hack that I don't trust entirely. So has anyone gotten around doing an active scanner looking for various repos such as git, svn, bazaar, cvs, etc?

Thanks

Louis Dion-Marcil

[Visser, Dale]

Does this need to be active because you're looking for repositories that aren't necessarily linked to?
________________________________________
From: zaproxy...@googlegroups.com [zaproxy...@googlegroups.com] On Behalf Of Louis Dion-Marcil [made...@gmail.com]
Sent: Tuesday, July 22, 2014 10:41 AM
To: zaproxy...@googlegroups.com
Subject: [zaproxy-develop] Using ZAP to find .git/, .svn/

--
You received this message because you are subscribed to the Google Groups "OWASP ZAP Developer Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zaproxy-devel...@googlegroups.com<mailto:zaproxy-devel...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.

[Louis Dion-Marcil]

Right, I want ZAP to look for them manually rather than find links pointing to them. I think this would be considered an active scan?

You received this message because you are subscribed to a topic in the Google Groups "OWASP ZAP Developer Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/zaproxy-develop/yrZjA17Ug8s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to zaproxy-devel...@googlegroups.com.

[Colm O'Flaherty]

Hi,

While you're asking about source code repos, this is very closely related to Source Code Disclosure. Zap looks for Source Code Disclosure in a couple of different ways.

1) Passively, by looking at the responses, and matching against signatures for different programming languages.

2) Actively, at URL level, using the Git / SVN Source Code Disclosure scanners (as well as a couple of other techniques such as WEB-INF information disclosure, and Java class file decompilation).

There is also the Git and SVN options in the Spider, which causes the spider to spider through all the URLs noted in the Git/SVN metadata.

The presence of a Source Code disclosure vulnerability with either SVN or Git, or the fact that the Spider has spidered the SVN/Git metadata means that either a working copy, a pristine copy, or a repo is present.  For the purposes of Source Code Disclosure, it doesn't really matter which.  Do you need more information on what precisely has been found, or what is it that you feel is missing in this case? Or perhaps you haven't been using these active scanners at all? Can you clarify?

Bazaar, CVS, Mercurial, and repo types other than Git or SVN are currently not supported in any form in Zap (or other scanners, to my knowledge).  It's possible, of course, but it's down to effort.  Some of the repo types (Git being a prime example) require a lot of low level manipulation and parsing (at the bit level) to parse the repo metadata and various (versioned) data formats, so the development effort is not trivial (understatement). These other repo types are also a lot less common than the more modern systems such as Git, so the cost/benefit tradeoff just means the effort is not worth it.

Having said all of that, if you have any test cases for other repo types that the owning organisation would allow me to test against, I'd be happy to take a look, of course :)

Colm

--

You received this message because you are subscribed to the Google Groups "OWASP ZAP Developer Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to zaproxy-devel...@googlegroups.com.

[Louis Dion-Marcil]

I see. I got confused... I saw the "Source Code Disclosure" in the passive scan policy tab and failed to see it in the "Information Gathering" tab... This is exactly what I needed! Sorry for wasting your time, guys.

--
You received this message because you are subscribed to a topic in the Google Groups "OWASP ZAP Developer Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/zaproxy-develop/yrZjA17Ug8s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to zaproxy-devel...@googlegroups.com.

[Colm O'Flaherty]

No worries at all. Let us know if you see any cases where it doesn't work for you.

[Louis Dion-Marcil]

After toying around for a bit, I noticed that the Source Code Disclosure - Git and Source Code Disclosure - SVN do not make use of the Attack Strength. I tried setting it to "Low" and "Insane" and the output was the same. I think that Attack Strength set to "Low" should only look for low hanging fruits, such as $ROOT/.git/config and $ROOT/.svn/entries and $ROOT/.svn/wc.db. Right now the SVN scanner is using the spider content to check _every single file_ for possible source code in the repository... even spidered files that returned 404s. This creates a flood of (mosty) useless requests. This type of active scanning for SVN source code should only be done when the Attack Strength is explicitly set to High / Insane. That's my opinion anyway.

As seen in my httpd logs:

127.0.0.1 - - [22/Jul/2014:17:07:33 -0400] "GET /.git/.svn/text-base/index.svn-base HTTP/1.1" 404 1000
127.0.0.1 - - [22/Jul/2014:17:07:33 -0400] "GET /.svn/text-base/.svn.svn-base HTTP/1.1" 404 1000
127.0.0.1 - - [22/Jul/2014:17:07:33 -0400] "GET /.svn/text-base/.git.svn-base HTTP/1.1" 404 1000
127.0.0.1 - - [22/Jul/2014:17:07:33 -0400] "GET /.svn/.svn/text-base/entries.svn-base HTTP/1.1" 404 1000
127.0.0.1 - - [22/Jul/2014:17:07:33 -0400] "GET /.svn/.svn/text-base/wc.db.svn-base HTTP/1.1" 404 1000
127.0.0.1 - - [22/Jul/2014:17:07:33 -0400] "GET /.svn/text-base/robots.txt.svn-base HTTP/1.1" 404 1000
127.0.0.1 - - [22/Jul/2014:17:07:33 -0400] "GET /.svn/text-base/index2.php.svn-base HTTP/1.1" 404 1000
127.0.0.1 - - [22/Jul/2014:17:07:33 -0400] "GET /.svn/text-base/a.php.svn-base HTTP/1.1" 404 1000
127.0.0.1 - - [22/Jul/2014:17:07:33 -0400] "GET /.svn/text-base/a.php.svn-base HTTP/1.1" 404 1000
127.0.0.1 - - [22/Jul/2014:17:07:34 -0400] "GET /.svn/text-base/abc.svn-base HTTP/1.1" 404 1000
127.0.0.1 - - [22/Jul/2014:17:07:34 -0400] "GET /abc/.svn/text-base/foo.csv.svn-base HTTP/1.1" 404 1000
127.0.0.1 - - [22/Jul/2014:17:07:34 -0400] "GET /abc/.svn/text-base/foo.php.old.svn-base HTTP/1.1" 404 1000
127.0.0.1 - - [22/Jul/2014:17:07:34 -0400] "GET /.svn/text-base/foo.php.svn-base HTTP/1.1" 404 1000
127.0.0.1 - - [22/Jul/2014:17:07:34 -0400] "GET /.svn/text-base/index.php.svn-base HTTP/1.1" 404 1000
127.0.0.1 - - [22/Jul/2014:17:07:34 -0400] "GET /.svn/text-base/index2.php.svn-base HTTP/1.1" 404 1000

Other than that, the scanner works perfectly.

Louis

[Colm O'Flaherty]

Good observations! 

The logic doesn't use $ROOT/.git/config at all, because there was nothing useful in there from the point of view of extracting the source code.

Re only scanning $ROOT/.svn/entries and $ROOT/.svn/wc.db at "Low" attack strength, IMHO it only really makes sense to use those files to extract the source code from the repo/working copy, because the scanners are Source Code Disclosure scanners, after all.  Do you have a different perspective on that?

Re scanning URLs that returned 404, I totally agree.  In that case, the scanners are looking for source code for a file that the webserver says doesn't exist, which on the face of it, seems completely non-sensical.  The only case that I can think of is if there is a dead link somewhere in a HTML file to a file that used to exist (ie, was deleted on the webserver, for instance), but which still exists in the repo.  It may be appropriate to scan for that case at High or Insane strength attacks, but not by default.  I'll make that change for the SVN and Git Source Code disclosure scanners tomorrow morn.

Thanks for the constructive feedback, by the way.  These are scanners that have served me well in the real world, but which have not been extensively real-world tested by others.

Colm

[Colm O'Flaherty]

Committed, as discussed.