In October, 2014 Sektion Eins company has discovered vulnerability which affects all branches of Drupal 7 versions. It allows performing any SQL-request to database even without having permissions in the system. The security risk was recognized as highly critical. The corresponding core update was released on October, 15. It upgraded the core to 7.32 version and eliminates this vulnerability. And now we’ll talk about some other kinds of vulnerabilities.
The vulnerability, found by Sektion Eins company was in the function, processing the values for SQL request. While processing this array for SQL function IN, it is presumed, that it is not an associative array and the keys participate in forming the name of placeholder. If the associative array with specially generated keys is transferred to those function, it is possible to intrude to the SQL-request and change the password for the superadmin of the system (Drupal user whose ID = 1), or change the passwords for any user or system...
The matter of security is the most important for the users. That’s why so much websites are built with Drupal, as it is one of the safest CMS: a lot of famous companies and important governmental institutions use Drupal for their websites. So that’s why we’ll discuss other security matters.
Performing websites testing at InternetDevels, we try to find as many bugs, influencing the customer’s vision of the website or the quality of its work all in all, as it is possible. On the sites we explore we were looking for the problems with code, which could lead to damaging the website: looking for the pages open for the anonymous user… And we found such! That is a serious developers’ mistake, but still not critical.
And what about other Drupal websites? There’s thousands of websites and probably the same quantity of such open pages. And what if…? No, that’s impossible! Although… What if there are some pages available for anonymous users and editing rights? And even including a possibility to make serious changes, like PHP code input. As you know, the pages of nodes’ editing in Drupal look like this: site.com/node/id/edit, where id is a numerical node identifier.
That’s how we conducted our search:
- The URL (address) of the page should include “node” and “edit”;
- The text on the page should contain the phrase “You may post PHP code” (in any language, available on drupal.org).
Or input: inurl:node inurl:edit “You may post PHP code”, press “Enter”.
We see few pages from live websites in Russian which were hacked before. In English there’s few dozens of such pages (hacked not so long ago and for scientific purposes).
So what do we have now? The page on a website which is open for web indexing and includes possibility to post PHP code. Its understandable, why wasn’t it closed for web indexing, but why there still is a possibility to post PHP code for unregistered users? Remember the special Drupal modules for adding the code to the page (for example Code Filter). Developing the website we should impose the restrictions on such input type: only superadmin should have such rights. But the search proved, that there’s some websites, built by careless developers. So what should be done? Simple as that: go to such pages, choose PHP input format and write something like:
<?php db_query("drop table {system}");?>
Save the changes and… we “killed” the table System. It has a key meaning, the website wouldn’t work without it. If the developers hadn’t made any backup, too bad for them. The main aim of hackers is to access the database and make some changes: create new user with admin permissions, output the passwords for users etc.
Inattentiveness or carelessness of developers can significantly harm your website. Even if the node is open for editing and web indexing, but doesn’t give permissions to post PHP code, it is still very dangerous. There is a text input format “Full HTML” allowing to input such tags as:
<script>
var iframe = window.getElementsByTagName( "iframe" )[ 0 ];
alert( "Frame title: " + iframe.contentWindow.title );
</script>
<iframe src="http://www.fsb.ru" width="600" height="1000">
<p>Your browser does not support iframes.</p>
</iframe>
The result is to be seen soon.
But you can easily prevent this:
1) Impose restrictions to use PHP code on everyone, except Admin;
2) Restrict the access to all pages. Even if the possibility to edit the page remains, disable all text input formats except “Plain text” and “Filtered HTML”, or create your own format with specific tag set, like for example:
<a> <p> <span> <div> <h1> <h2> <h3> <h4> <h5> <h6> <img> <map> <area> <hr> <br> <ul> <ol> <li> <dl> <dt> <dd> <table> <tr><td> <em> <b> <u> <i> <strong> <del> <ins> <sub> <sup> <quote> <blockquote> <pre> <address> <code> <cite> <param> <strike> <caption> <tbody>;
3) Only allow web indexing for the key pages of the website.
In fact, you can prevent all problems of such kind by keeping an eye at security while developing your website. There’s no point in coding, if you open all opportunities to harm the website by yourself. Keep calm and code wisely.
P.S.: all hacked English-speaking resources have eliminated the possibility to post PHP code, the “System” table was restored (despite the fact that web indexing of such pages didn’t stop). Russian-speaking resources have just left.
The information about this vulnerability appeared in Drupal bug tracker more than 11 months ago, but the Security Team haven’t received it. Now the developers would have to explain, why did it happen and what have they done to minimize the risk of such situation in future. Considering the fact, that around 1,1 mln websites are built on Drupal worldwide, and more than 932 thousands use 7.x version, there is a possibility that not everyone has managed to update the core.