Webhacking with CVS

Webserver CVS (In)Security [50% paper, 50% advisory]
by methodic@libpcap.net

A lot of people use CVS to manage their web content. It's a great way to
keep track of changes, and makes updating and rollbacks a very easy
thing to do.

..BUT (there's always a but) this can be a _huge_ security risk.

When I finally decided to manage my web content with CVS, I noticed
something about the directory layout (after running a `cvs up`) of my
website; there were a bunch of CVS directories with files in them. I
always knew they were there when working with CVS (those files are the
way CVS keeps track of versions and what not), but I never paid any mind
to them.. until today.

I opened up Mozilla and went to my website with a /CVS appended to the
URL. Since I have Apache setup to disallow directory listings, I didn't
get anything. Then I added /CVS/Entries to the URL. Two words came to
mind: Uh-oh. The Entries file gave a complete listing of my webroot. It
was like having ls(1) running on my webserver. The Entries file showed
all the files and directories people normally wouldn't be able to see or
even scan for. It would seem that having the directory listing option
disabled in my httpd.conf didn't matter anymore.

I had never thought of this type of attack, even when I was employed as
a pen-tester. I did a quick search on the SecurityFocus.com mailing
lists BUGTRAQ, VULN-DEV and PEN-TEST. Nothing. Then I did a quick grep
on whisker (very popular web-auditng tool), versions 1.4 and 2.1. Again
I came up empty. I'm almost certain this is something some people already
know about, but it seems like those people are few and far between.

In my quest on Google, I was able to find some pretty interesting stuff.
I came across database usernames and passwords in files which appeared
to be include files used for dynamic content. I even came across one
website that had all their content in a nice packaged zip file, a file I
wouldn't have known existed if it hadn't been for the Entries file.
Pretty scary stuff if you ask me.

There are other files in the CVS directory that allow for disclosure of
the server. The file named Root tells you where the CVS repository is
located. The other file, Repository, tells you the name of the project
it's referred to in the CVS repository. Not as devistating as the Entries
file, but still valuable information (directories, valid account names).

In the end I chose to delete all CVS directories and files in my webroot
with this command: find /www -name CVS -type d | xargs rm -rf which I
have in a shell script that pushes the CVS site live. I didn't need them
around and I didn't feel like messing around with httpd.conf. I'm not
sure why people would want to keep them around.. maybe there's a tool
that performs some sort of statistics. If that's the case, you should
write a regex in your webserver's config file (if it has that option) to
deny CVS and anything below it.

To webdevelopers: Please take this paper into consideration if you're
using CVS to manage your websites.
To administrators: Always be aware of activity on your server. Your
webserver shouldn't return a 200 on /includes/db_auth.inc, right? :)
To security developers: Please take this paper into consideration in
your auditing tool (add checks for /CVS AND /CVS/Entries).