WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 7 years ago

#7710 closed defect (bug) (fixed)

admin account exploit

Reported by: jeremyclark13 Owned by:
Milestone: 2.6.2 Priority: high
Severity: critical Version: 2.6.1
Component: Security Keywords: milworm exploit
Focuses: Cc:

Description

It looks like milworm has an exploit for 2.6.1.
Link : http://www.milw0rm.com/exploits/6397

It looks like they can register an admin account then use the lost password function to have the password changed.

Change History (6)

comment:1 @Otto427 years ago

  • Milestone set to 2.6.2

Supporting info:
http://www.suspekt.org/2008/08/18/mysql-and-sql-column-truncation-vulnerabilities/

Basic problem: mySQL will consider "admin" = "admin(55 spaces)x" because it doesn't do binary comparisons on the data when the column is a string type, so the spaces are truncated off (as is the x, due to the length limit on the column).

Looks like ALTER TABLE wp_users DROP INDEX user_login_key , ADD UNIQUE user_login_key ( user_login ) would prevent it, to me. With a unique index, the insert of the new "admin(spaces)x" user would fail because of the comparison as well. And the user_login name should be unique anyway.

comment:2 follow-up: @g30rg3x7 years ago

This problem was already addressed in changeset 8748 (for 2.6.x) and in 8704 (for trunk).

comment:3 in reply to: ↑ 2 @Otto427 years ago

Replying to g30rg3x:

This problem was already addressed in changeset 8748 (for 2.6.x) and in 8704 (for trunk).

Bah. I liked my solution better. ;)

However, that change is post-2.6.1, so the current latest released version is still vulnerable to this attack. 2.6.2 should get pushed out quickly because of this flaw, IMO.

comment:4 @g30rg3x7 years ago

:P

2.6.2 should be released ASAP (IMHO), cause it not only address that bug, it also address this bug and unfortunately it was only matter of time before someone point out this flaws (before the release of 2.6.2) and releases his "exploits" to the public.

comment:5 @mrmist7 years ago

+1 to having a unique index on the column anyway, although probably in conjunction with a user-side error when trying to add a non-unique name.

The "add user" page really should be picking up on and preventing it.

comment:6 @ryan7 years ago

  • Milestone changed from 2.7 to 2.6.2
  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.