Drupal Login Security Module "Bug Fix" Actually Security Update
1 April 2011
The Drupal Login Security module (http://drupal.org/project/login_security) recently pushed out a "bug fix" update (http://drupal.org/node/1100502) to the 6.x version of their module. The module addresses a number of small bugs, but buried in the change notices is the rather astounding fix for the issue "#601846: uid 1 not being blocked." This is actually a pretty big deal. After noticing this little gem I hurried to test the older version of Login Security 6.x-1.0. Sure enough, if the module is set to block a user after a certain number of attempts it works correctly, unless the login attempts are made as the uid 1 user.
This situation is particularly worrisome because, well, first of all the module doesn't actually work as advertised. However, I can understand the developers' motivation for enabling this functionality in the first place. The developers probably didn't want to enable a situation where an outside attacker could block access to the site by locking out all the user accounts, and specifically the administrative user account (which is the uid 1 account). However, attackers brute forcing a site are most interested in gaining access to the uid 1 account. This account is the super user account, from which no privilege is blocked. Once an attacker can control the uid 1 account they can take control of the entire web server quite easily. Fortunately, Drupal doesn't provide a default username for the uid 1 account, it is specified by an operator during the install procedure. This means that attempts to brute force the uid 1 account must first identify the uid 1 account. While there are certain methods that can be employed to get listings of user accounts on a Drupal system (http://www.madirish.net/?article=465) it is often difficult, or impossible, to determine which account is the uid 1 account.
Unfortunately the flaw in Login Security version 6.x-1.0 allows an attacker to determine the name of the uid 1 account if the module is configured to lock user account on the administration screen located at ?q=admin/settings/login_security. By testing accounts and observing which account is not locked out after the specified number of login attempts it becomes apparent which account is the uid 1 account.
This is a case of a bug in a security related module actually being a security bug, rather than a simple function bug (such as a translation error). The Login Security module is classified by Drupal.org as "Module categories: Security, User Access & Authentication." It seems to me that any bug fixes to modules of this category should be carefully reviewed to prevent just this type of situation. For now, the update is merely marked as a bug fix, and unless administrators take the time to read through the actual bugs that are addressed, as well as understand the implications of the issue #601846 fix, they will understandably, but erroneously, believe that the update is non-critical. This release is a great example of the sort of lop sided risk analysis, that occurs with incomplete information, and is all too common in the field of information security.
I applaud the developers for updating the module, but without the appropriate designation many people may not even become aware that they have a security vulnerability in their deployment. Drupal security updates are tracked on a central page of Drupal.org (http://drupal.org/security/contrib), and there is a security mailing list where subscribers receive alerts of new security updates. The Drupal administrative interface also marks modules that are out of date due to a security update in glaring red to make them apparent. Because every update could cause issues and increases the risk of instability many enterprises choose only to deploy security related updates. Without this important designation it is probably that this update will not be applied in many environments.