Make WordPress Core

Opened 17 years ago

Closed 16 years ago

#4627 closed defect (bug) (wontfix)

Link manager exploit?

Reported by: cbdilger's profile cbdilger Owned by: pishmishy's profile pishmishy
Milestone: Priority: high
Severity: normal Version: 2.2
Component: Security Keywords:
Focuses: Cc:

Description

I think someone has found a way to add links using /wp-admin/link-add.php without authentication -- today I found a new link (spam, of course, of the casino variety) and three accesses to the above address from one IP address.

I deleted the link, but I would not be surprised to see it return...

Let me know if I can provide more information; I have shell access to the machine in question (hosted on Dreamhost). I'm running WP 2.2. Thanks.

Attachments (4)

4627.diff (736 bytes) - added by DD32 17 years ago.
4627.2.diff (938 bytes) - added by DD32 17 years ago.
just moved a few things around, Blank document this way if user accesses it directly.
4627.3.diff (2.4 KB) - added by DD32 17 years ago.
wp2-linkmanager.patch (2.8 KB) - added by snakefoot 17 years ago.
WP2 Link Manager Patch

Download all attachments as: .zip

Change History (30)

#1 follow-up: @JeremyVisser
17 years ago

Can you grep your access logs for link-add.php? Might reveal something.

Oh, and upgrade to 2.2.1. 2.2 has known security flaws.

#2 @foolswisdom
17 years ago

  • Milestone set to 2.4 (future)

#3 in reply to: ↑ 1 @cbdilger
17 years ago

Replying to JeremyVisser:

Can you grep your access logs for link-add.php? Might reveal something.

Only three instances::

access.log.2007-07-06.gz:87.126.31.177 - - [06/Jul/2007:05:24:49 -0700] "GET /cbd/wp-admin/link-add.php HTTP/1.0" 200 12447 "-" "Opera/9.01 (Windows NT 5.0; U; en)"
access.log.2007-07-12.gz:87.126.31.177 - - [12/Jul/2007:06:56:22 -0700] "GET /cbd/wp-admin/link-add.php HTTP/1.0" 200 12447 "-" "Opera/9.01 (Windows NT 5.0; U; en)"
access.log.2007-07-12.gz:87.126.31.177 - - [12/Jul/2007:06:56:24 -0700] "POST /cbd/wp-admin/link.php HTTP/1.0" 200 0 "http://wrecking.org/cbd/wp-admin/link-add.php" "Opera/9.01 (Windows NT 5.0; U; en)"

Oh, and upgrade to 2.2.1. 2.2 has known security flaws.

Will do.

#4 @pishmishy
17 years ago

  • Owner changed from anonymous to pishmishy
  • Status changed from new to assigned

I don't appear to be able to replicate this bug. Have you had any problems since upgrading? Otherwise, without further logs or evidence Id be tempted to close this report.

#5 @foolswisdom
17 years ago

  • Milestone 2.4 (future) deleted
  • Resolution set to invalid
  • Status changed from assigned to closed

Closing as invalid for now b/c of lack of similar reports and inability to identify any likely clause.

#6 @auxesis
17 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

I'm able to reproduce this. I'm getting an avalanche of blogroll link spam every night. The links appear to be pointing to other compromised wp instances.

I set up an alert so i'd get notified when my blog was compromised. The exact time was 2007/10/15T04:16-1000. The apache log fragment is as follows:

holmwood.id.au 195.5.116.246 - - [15/Oct/2007:04:06:19 -1000] "POST /~lindsay/wp
-admin/link.php HTTP/1.0" 500 1383
holmwood.id.au 195.5.116.246 - - [15/Oct/2007:04:06:21 -1000] "POST /~lindsay/wp
-admin/link.php HTTP/1.0" 302 -
holmwood.id.au 195.5.116.246 - - [15/Oct/2007:04:16:10 -1000] "POST /~lindsay/wp
-admin/link.php HTTP/1.0" 500 1383
holmwood.id.au 195.5.116.246 - - [15/Oct/2007:04:16:14 -1000] "POST /~lindsay/wp
-admin/link.php HTTP/1.0" 302 -
holmwood.id.au 195.5.116.246 - - [15/Oct/2007:04:18:24 -1000] "POST /~lindsay/wp
-admin/link.php HTTP/1.0" 500 1375
holmwood.id.au 195.5.116.246 - - [15/Oct/2007:04:18:26 -1000] "POST /~lindsay/wp
-admin/link.php HTTP/1.0" 302 -
holmwood.id.au 195.5.116.246 - - [15/Oct/2007:04:26:59 -1000] "POST /~lindsay/wp
-admin/link.php HTTP/1.0" 500 1379

I'm running a newly upgraded 2.3.

#7 follow-up: @JeremyVisser
17 years ago

Lindsay, could you modify link.php so it dumps the contents of $_POST to the error log so we can see how the exploit is run?

Something like...

if ( 'POST' == $_SERVER['REQUEST_TYPE'] ) {
    error_log(print_r($_POST, true));
}

Then, tomorrow, take a look at your PHP error log.

#8 @ryan
17 years ago

  • Milestone set to 2.3.1

Setting milestone to 2.3.1 in case we find something.

#9 in reply to: ↑ 7 @auxesis
17 years ago

Replying to JeremyVisser:

Lindsay, could you modify link.php so it dumps the contents of $_POST to the error log so we can see how the exploit is run?

No worries. I'll post what I get tomorrow.

@DD32
17 years ago

#10 @DD32
17 years ago

After playing around with it and leading down the wrong paths too many times...

Subscribers can access the add and save code branches, Neither check for valid user premissions, only that the user is logged in(handled by admin.php).

Attached a patch which throws a current_user_can() call into both branches.

If we look at the logs above
the 500 error is wp_die presenting the user with a nonce.
Then the 302 is the bot sending back the nonce and adding the link.

I cant think of anything that would fail the additional user checks.

@DD32
17 years ago

just moved a few things around, Blank document this way if user accesses it directly.

#11 @ryan
17 years ago

I think each case needs the same capability check. Perhaps put one current_user_can() check at the top and die early?

#12 @DD32
17 years ago

Perhaps put one current_user_can() check at the top and die early?

Allright, I'll do that.

While i'm looking at it, the move case does nothing, Doesnt look to have been touched since the start of 2006.. I cant see anything in WP-admin refering to either move or deletebookmarks.

#13 @DD32
17 years ago

scratch that, found the deletebookmarks code, Its just move thats orphaned.

@DD32
17 years ago

#14 @westi
17 years ago

I guess we need to check all admin pages for checks on user_level.

#15 @ryan
17 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

(In [6255]) Add current_user_can() checks to link.php. Props DD32. fixes #4627

#16 @ryan
17 years ago

(In [6256]) Add current_user_can() checks to link.php. Props DD32. fixes #4627 for 2.3

#17 @Nazgul
17 years ago

  • Milestone changed from 2.3.1 to 2.0.12
  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening for 2.0.12 consideration.

@snakefoot
17 years ago

WP2 Link Manager Patch

#18 @Otto42
17 years ago

Some users are reporting that this fix is not working.

http://wordpress.org/support/topic/138934

I'm not able to find the problem. Has anybody been able to reproduce the actual spam inputs?

#19 @Otto42
17 years ago

  • Priority changed from normal to high

#20 @DD32
17 years ago

Some users are reporting that this fix is not working.

I've posted a message into that thread for them to get in touch with me for more debugging if needed.. Unless a user has a Editor or Admin role on the blog i cant see how they're posting the spam.(If its coming via the WP admin pages that is)

#21 follow-up: @ryan
17 years ago

hmmm, add_link()/edit_link() already did a cap check, so I think our patch didn't really change anything.

#22 in reply to: ↑ 21 @westi
17 years ago

Replying to ryan:

hmmm, add_link()/edit_link() already did a cap check, so I think our patch didn't really change anything.

Agreed.

I noticed those first when I went to look at branches/2.0
From what I can tell from reading through both the ajax and non-ajax routes you need a user with manage_links to achieve adding a link.

This is beginning to feel like someone has either stolen then cookies from a high level user _or_ found a way to create a high level user - I can't see any vector for that from the code reviewing I have done.

#23 @sjmurdoch
17 years ago

An attacker used the vulnerability described in #5367 to post spam links on my blog. Could that be it?

#24 @pishmishy
17 years ago

The discussion on the support forums at http://wordpress.org/support/topic/138934/page/2 suggests that the problems were due to public access to wp-config.php, leading to access to the database.

#25 @pishmishy
17 years ago

If someone can capture a link being added in their MySQL logs so we can start to trace where this is happening that'd be useful. Otherwise, tempted to close in a few days as a duplicate of #5367.

#26 @pishmishy
16 years ago

  • Milestone 2.0.12 deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed

Closing as won't fix. No evidence presented to make us believe this wasn't due to another, resolved vulnerability.

Note: See TracTickets for help on using tickets.