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