A couple of months ago we (  2Tovarischa  and  Anton Isaikin  ) vulnerability was discovered, inherent in most large Internet projects (such as the Rambler, Mail, Yandex, Opera, etc.). Unable to access file structures of known sites (a total of 3320 sites) and in some cases their full source code.

It would seem that in the XXI century is hard to find a similar vulnerability. It seems that everything has already been found, and what is not found, sitting somewhere very very deep. It turned out that the root of evil today is quite casual thing. Probably every one of you ever had to deal with version control system SVN. SVN is an advanced tool for organizing the joint development of dozens or even hundreds of developers. Because of the architecture, SVN stores in each directory of the project their metafiles, neatly folded in a hidden directory . svn . In one of the files under the name of entries is a list of all files and directories located in the same folder as the . svn . Also there is information about the location of the repository, file size, date of change and user logins working on the project. It is not bad, right? Let me explain, it turns out, if the project is being developed with the help of SVN, then looked at draftcopy.ru / .svn / entries we will see the file structure of the root of the project with the authors, the latest changes, referring to the mainline repository etc. But we can go further. In the same folder . svn is director of the text-base , in which lie the latest versions of all files in the repository. Complements the picture as well and that the files are not a standard extension (eg. Php), which allows them to immediately send the interpreter, and an additional extension . svn-base , thanks to which the file is given to the person requesting it "as is", ie . bare source code! draftcopy.ru / .svn / text-base / base-index.php.svn It should be noted that this picture is perfect and even though she was so in most cases, though a large percentage of the source code could not be obtained by one reason or another. For the first time realized that the discovered vulnerability is inherent in most projects the past nine years, it was decided to scan to see what ðóíåò live Internet projects and get an interesting statistic. But before the story of how it was necessary to tell gray admins how to defend against this ...



Source were obtained 3300 Global Internet Project_第1张图片







Protection against vulnerability


The vulnerability can be avoided in several ways. The path on the forehead - block access to SVN metadirektoriyam 80th port, ie, means of a web server.

The solution for nginx
Location ~ /. svn / {
    deny all;
}

Global lokeyshenov in nginx `e do not, so will have to sign for each server region. To rule took effect, you must download it to other lokeyshenov the regular expression. Universal way - the first lokeyshenom.

The solution for Apache

    Order allow, deny
    Deny from all
    Satisfy All


Then a little easier, we finish it in httpd.conf and all projects are running apache read from the directory. svn is not available.

The decision means SVN
Protection of vulnerable web server means - disease treatment. Any doctor will tell you that prevention is simpler, easier and less costly than treatment. So the best solution would be the absence of these metadirektory most fundamentally a project. This can be achieved by means of  svn export  from the main branch. Information taken from twocomrades.ru




History of research


As already mentioned, it was decided to scan the entire ðóíåò on the existence of such vulnerability. Were raised by the proxy server, write a parser and get the latest base domains in  RU  .The first version of the script worked for two weeks, getting a site for the site in one thread. By the end of scanning, the database consisted of over 3,000 vulnerable sites and took more than a hundred gigabytes of source code. skanirovniya first problem was that download all sortsy indiscriminately, regardless of whether they gave the 200 or 500 code, as well as graphics and pumped js scripts. And as is often the web server was configured in such a way to give 200 code, even if the file is missing things. The second version of the script was already nimble, has worked in several streams with two server machines and correctly distinguish the contents of the received response codes pages. We went around the ðóíåò for 4 days.Future plans was the dot-com base. It became obvious that with the current resources would be made ​​bypassing at least a couple of years (zone com now has more than 700 million domains (compared with 2 million RU )). By the Minister was involved other than B-programmer Andrew Saterenko , who wrote a quick demon who could have a couple of times to reduce our time spent. But, unfortunately, by this time the summer ended, navalililas work. Ambitious plans have been agreed to roll. Before you post publicly information about the vulnerability, it was necessary to notify all affected. The first letters were sent to the giants (yandex.ru, rambler.ru, mail.ru, opera.com, rbc.ru, 003.ru, bolero.ru, habrahabr.ru, a total of 19 addresses), then, tonight, received a letter the other 3000 + sites. Release of this article has been detained while waiting for opera.com closes vulnerability in all its servers.











Some statistics:

Crawled Domain:  2253388 Vulnerable: 3320 Statistics on alerts yet, maybe it will be published in a couple of weeks. Of the major portals, six responded. Yandex was the most expeditious, by sending an e-mail Sunday night. Ten projects did not have responded to our letters, three projects have closed the vulnerability without thanking. We are not vindictive, we write their names ...





A few interesting facts:

  1. Cybersquatters to love SVN, as well as optimizers;
  2. CSS for a single calendar Yandex is collected from a dozen CSS sredstami $ make from the console 0_0;
  3. On projects use the services of Yandex Rambler 0_0, files were found "proof of the domain" for Yandex services;
  4. RBC uses and services of Yandex and services of Google and are very fond of "complex" passwords;
  5. Opera respects the MySQL, but the site they have to bare with the actual html directories and subdirectories;
  6. Blonde respects CodeIgniter;
  7. PostgreSQL respected engine wikimedia => PostgreSQL MySQL ;-) respect errors ;-(
  8. All projects Futuriko (and Leprosy) are written in perl.
  9. About 10 sites with the words in the domain of type «hack» and «secure» vulnerable;
  10. Many believe that naming a directory phpmyadmin about «__xpma123uff__» but to save the password in the configuration, it is a good defense;
  11. Many still keep in config inc files with no extension. Php, which opened as a text in your browser.


You tried  2Tovarischa  (  mobilz  ) and  Anton Isaikin  (  oowl  ,  TWI  ). 
We are willing to cooperate;) PS In order to avoid conflicts all sources received during the study were raspechatanny and burned :-) PSS two points:


  • absolutely everything, who could suffer, received warnings about the vulnerability of the exact date of publication in advance .
  • No source code in any way will not be published or sold. It is not necessary to write to us about it.

PPPS Thank you for helping habrapolzovatelyu  oowl  . 
PPPPS No sortsov most search engine Yandex has been received, but were obtained by the roots of the muzzle of some Web resources. Nesting, xmlapi, xsl templates etc. Nothing serious, except that all IP addresses of repositories, developers etc logins. Kukuts, Bobuk, relax. Igor Sysoev , a leading administrator of Rambler , a developer known for its ease of a web server nginx responded to a couple of our questions:


  • Q: Why do so many well-known projects at once ignored such elementary leakage? A: The reasons why I think a lot - someone said that. svn is all the same, affordable and without. svn. Someone probably just did not know or forgot about. Svn.

     
  • Q: Do you plan to make to the possibility of globally nginx redirect URL (before the directive server, so you can immediately block when setting up a potentially dangerous addresses)? A: No. I believe that the global setting in the end lead to a configuration that each time more and more difficult to maintain.