66

In this case, it looks like you need to do drush rf # pm-refresh before you do drush up drupal This will refresh the list of available updates so Drush knows there is a new release for Drupal.


38

Worth mentioning is $ drush up --security-only Only update modules that have security updates available. That includes Drupal core.


29

If you're reading this article and hoping to check a Drupal 7 site more than a month after the exploit landed, your site quite likely already got hacked. Your best bet is to restore a backup from before the attacks commenced and work from there. There is a FAQ on SA-CORE-2014-005. How do I tell if my sites have been compromised? One way to quickly check ...


24

Some checks for common attacks are (this is not an exhaustive list, but are some of the attacks seen in the wild so far): Check your user 1 account to make sure its user name, email address or password are what you expect them to be. Also check any other user accounts that have high levels of permissions if possible. Check for new user accounts that look ...


20

Whats going on with 7.32 By checking the testing module. You can see the following test was added to 7.32; + + /** + * Test SQL injection via database query array arguments. + */ + public function testArrayArgumentsSQLInjection() { + // Attempt SQL injection and verify that it does not work. + $condition = array( + "1 ;INSERT INTO {test} ...


18

The company that found the bug has some examples on Advisory 01/2014: Drupal - pre Auth SQL Injection Vulnerability : Extract: The function assumes that it is called with an array which has no keys. Example: db_query("SELECT * FROM {users} where name IN (:name)", array(':name'=>array('user1','user2'))); Which results in this SQL Statement ...


16

The researchers who found the bug have a proof of concept. Others have developed proofs of concept as well. However, they are purposefully not posting them to try to reduce the likelihood that it will get widely exploited. We should respect that research and restraint and not post examples here. After some time has passed and sites get upgraded then it will ...


16

Drupal 8 (like Drupal 7) uses PDO to communicate with databases. With PDO, the DB API makes use of prepared statements, specifically to avoid SQL injection attacks. Practically, this means that you should use the database API methods. If you use the select, update, delete methods directly, you have a better chance of avoiding SQL injection as everything ...


14

I have migrated other CMS's to Drupal and had experience moving user accounts. Drupal's password algorithm is extremely good. The salt you are referring to in the settings.php is not used for passwords. The drupal_hash_salt salt is used for generation of things like cookies. Hence why it says you must keep it the same across all web servers if you are in ...


13

First, read up about these in the Drupal API: filter_xss check_plain So check_plain() encodes special characters that has special meaning in HTML (such as < and &) into plain text entities (i.e. &lt; and &amp; respectively) that will make these be rendered literally (not interpreted as HTML) when that string that is then displayed as part of ...


12

It will not, in any way shape or form protect you from injection. Quite the contrary, using the PHP filter is generally a horrible security problem, because it enables arbitrary code to be executed. Do not use the PHP module, at all. Greggles mentions the Paranoia module in his answer, which is awesome, consider using it. However, if you have enough ...


12

Here's some slides on automated security reviews using Drupal tools Here are some manual steps for a review You can try to improve password strength And to make all passwords stronger, Two Factor Authentication is helpful Security Review is a good call As is Paranoia And Cracking Drupal is a good resource (disclosure, I wrote it)


12

The specific vulnerability seems to be the ability of a requester to send one request path to the webserver, but use an HTTP header to make Drupal see a different path. The rewrite happens early, so the access layer in Drupal/Symfony runs as intended. But it bypasses path-based restrictions that happen earlier ("on higher level caches and web servers", ...


11

No, it very much will not! SQL injection prevention is something that needs to happen in the PHP code itself; the PHP filter won't alter your PHP, so it can't add protection to your code. I'd be very surprised if there's anything out there that can auto-magically take an arbitrary PHP script and save it from SQL injection. In fact, if you ever see ...


11

They see a blank 403 page with this message specifying that their IP address has been banned: The block is done at the application level. Drupal inserts a record into the blocked_ips table which is referenced upon bootstrapping; if a match is found the above page is shown. I've not heard a module that does this at the OS level. Considering the variety of ...


11

Sanitizing on output to avoid Cross Site Scripting (XSS) attacks Use Twig templates The Twig theme engine now auto escapes everything by default. That means that every string printed from a Twig template (e.g. anything between {{ }}) gets automatically sanitized if no filters are used. See Filters - Modifying Variables In Twig Templates for the ...


10

In Drupal 7, while all passwords are hashed (SHA-2 with 64-bit words) and salted, if your user's passwords have low entropy, brute-force password attacks are feasible. Image source: xkcd, explanation. Also note that the cartoon above assumes that an attacker tries to brute-force passwords over the web. As pointed out by @Damon in a comment: Readily ...


10

I think I would go with the advice drupal.org "You should proceed under the assumption that every Drupal 7 website was compromised unless updated or patched before Oct 15th, 11pm UTC, that is 7 hours after the announcement.". As Bevan said in this comment "Updating or patching Drupal does not fix backdoors that attackers installed before updating or patching ...


10

How can I tell if someone used this exploit to hack my site? Your Drupal 7 or 8 site can experience loss or theft of data, data can be removed, deleted or changed, wreaking havoc on the site in many different ways. See this Stack Exchange post for general information on checking to see if your website has been hacked. What can they do with this exploit if ...


9

drush up drupal Appending the project you want to update makes drush to only update that project.


8

Recommended file/directory permissions: Drupal webroot should be world readable (see: updater.inc): 0755 for public upload directories: 0755 or 0775 for private upload directories: 0750 or 0770 for public uploaded files: 0644 or 0664 for private uploaded files: 0640 or 0660 for .htaccess within upload directories (see: file_create_htaccess()): 0444 (default)...


8

Since a potential attacker got access to the database, and through the evil php module, could execute code, everything on the same server must be considered compromised.


8

What could happen I had a personal Drupal site hacked during Drupalgeddon, an exploit of similar severity (though of a different type). In terms of "what could happen," in that case the hacker put several "back door" files into my codebase (I knew very little about development at the time, and had no Git repository), from which he could send out spam email. ...


7

I'll start with your second question, "do contributed modules make Drupal less secure?" In general, yes, because contributed modules expand the attack surface of your site. When a module provides user interaction features it's another point an attacker could probe for exploits on your site. Additionally that module becomes another dependency in your system ...


7

The commerce_authnet module is using the PHP curl() functions to communicate with Authorize.net, and it does not explicitly requests the SSLv3 protocol in the curl options (see file commerce_authnet.module, lines 1163 to 1172). curl will therefore rely on the HTTPS handshake to determine the protocols and ciphers, and since the Authorize.net will not ...


7

Please also keep in mind there are '0-day' vulnerabilities out there, which can be used to compromise your website even before Drupal publishes a security advisory and corresponding patch. And that even if you use an automated update for Drupal core, there still will be a time window in which your site was vulnerable. The best way to deal with these kind of ...


7

I probably would guess, yes to this one especially if you have added the civicrm db to the drupal settings file and/or share the civicrm tables in the same drupal db. the primary reason for this is, drupal's db access layer (and code) can access the civi db the same way as the drupal db and hence any exploit in that code can be used against the civi db ...


6

It turns out that if you just set the value, Drupal will not display your HTML without converting your tags to entities. So the value <p>Foo bar</p> will be displayed literally in Views (and other areas) as &lt;p&gt;Foo bar&lt;/p&gt;. Rather than attempt to create a sanitized safe_value myself before calling set(), I found that ...


6

Here are some SQL queries that can be run against your site DB's to check for users with admin privileges, and which of those have accessed the site post 15th Oct. http://www.drupalden.co.uk/sql-queries-find-users-roles-admin-privileges-drupalgeddon-drupal-sa-core-2014-005


6

I downvoted Devaraj Johnson's answer because it suggests to check_plain() data before saving it to the database, which is wrong. The idea behind check_plain, filter_xss and filter_xss_admin is to prevent XSS attacks, which are related to the front end. When you handle database queries, use parameters and the DB API to prevent SQL injection attacks. ...


Only top voted, non community-wiki answers of a minimum length are eligible