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.


36

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


19

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


15

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 two ideas to help with this problem. There are tools and services you can use to look for brute force attacks. The security review module and droptor tools both look in your watchdog (at Administer > Reports > Recent log messages) to see if you have a lot of failed logins for one user. You can also do that manually. In Drupal 7 the "access rules" ...


14

These kinds of probes are very common across the internet. There are a few things you can potentially do to block this problem and reduce the success of an attacker. First, I recommend everyone use Two Factor Authentication so that even if the attacker guesses your username and password they still can't login. There was a bounty for $500 to break TFA and ...


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


13

First, you need to know which input text filter you have enabled where the images are not showing. For the sake of this answer, let's say it's the "Basic HTML" input filter. Go to the configuration for this input filter, such as /admin/config/content/formats/manage/basic_html Scroll down to "Enabled Filters" and look for: "Restrict images to this site" ...


12

As you can see in the code, the function user_login_final_validate register a flood event. That means if a same IP try to connect a user/login password many times we will be "banned" for a while. This is one of the protections that Drupal offers. Another one, and I think if its happens to your web site you will notice it very fast, it's the CSRF token that ...


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

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

Here is the security vulnerability reason to avoid giving this permission to your users if you don't want your non-admin users to modify the db directly. <?php echo file_get_contents(dirname(__FILE__)."/../sites/default/settings.php"); ?> Hacking the Drupal db credentials


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

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)


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


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

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

Only full releases get the security shield. Your screenshot only shows a dev version. I don't think the shield was removed from your module, as it wouldn't have had one in the first place since you don't have a full release. To get the security shield, you'll need to release a full version (one not suffixed with -dev, -alpha or -beta). ** EDIT ** I have ...


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

Drupal file uploads (in core or modules) should use file_save_upload which itself also calls file_munge_filename. Together those two functions should ensure that even if a file contains php it is not named in a way that a typically configured webserver would execute them. They also have protection against pl|py|cgi|asp|js files which can often contain code. ...


8

The upgrade advice is the same as for installations. http://drupal.org/upgrade/finished The last step in an upgrade is to delete or move the following files from your site: install.php CHANGELOG.txt INSTALL.txt INSTALL.mysql.txt INSTALL.pgsql.txt LICENSE.txt MAINTAINERS.txt UPGRADE.txt


8

Here's my take on it: The PHP docs says about eval: Its use thus is discouraged It is always, let me emphasize that again, always, bad to use the PHP module (technically eval, but the PHP module makes a dangerous language feature much worse). Details discussed in this question: What are the downsides of using PHP Filter code in blocks, nodes, views-...


8

This is better solved at the Apache level. The industry standard method for doing this is to create a honeypot directory, make it off-limits to bots in robots.txt, then logging the IP-address of those who still go there, and block it. For an example of this, see the this page: http://www.kloth.net/internet/bottrap.php. You can set up this on shared hosting ...


8

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


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