Many webmasters use SVN not only as a version control system during website development, but also as a deployment tool for easily synchronising the development environment with the production server. A serious flaw has been uncovered in the system that many are unaware about, and that poses a significant security threat, allowing a potential attacker to gain access to source codes and configuration files. To understand that flaw, we must understand a little about how the SVN system works.
In every folder that is managed with SVN, it creates a hidden .svn subdirectory. In it, a list of all files and subdirectories in that folder are stored, together with technical information about their history as well as every file itself. The file .svn/entries contains a list of all files and directories in the folder where .svn is located, and the directory .svn/text-base contains the recent revisions of all files, with .svn-base added as an additional extension.
project
|- index.php
|- config.php
|- dir
| |- .svn
| | |- entries
| | '- text-base
| | '- file.ext.svn-base
| '- file.ext
|- .svn
| |- entries
| |- text-base
| | |- index.php.svn-base
| | '- config.php.svn-base
| '- ...
'- ...
Now, normally the .svn is hidden, and doesn’t bother anyone much. However, with default settings, the webserver will treat the files inside it just like any other file – if requested directly, those files will be served. Using the entries file, a list of accessible files can be obtained – among which there might be configuration files or others containing confidential information. And since the files in the text-base directory have their extension changed they will not be processed by, for example, PHP – the sourcecode will be shown as it is.
This vulnerability was discovered some time ago by a group of Russian programmers. They did a scan of a large amount of websites, including some fairly big names in the .com, .de and .ru zones, and the results were staggering. Owners of hundreds of websites were notified of the vulnerability, and after it was closed, some details were disclosed on a large Russian IT blog Habrahabr.
There are multiple ways of securing against the vulnerability. Among the most simple and efficient are:
- Blocking web access to the .svn directory altogether using, for example, the .htaccess file for Apache.
- Using the svn export command instead of the usual svn checkout does not produce the .svn directory in the first place.
While those solutions might seem obvious (and they really are), I was very surprised when I did a simple check among a few websites from my bookmarks list. So webmasters – if you haven’t yet known about this, beware.