[wp-trac] [WordPress Trac] #45318: Security problem: Login Oracle

WordPress Trac noreply at wordpress.org
Fri Nov 9 18:54:18 UTC 2018


#45318: Security problem: Login Oracle
--------------------------+-----------------------
 Reporter:  d0rkpress     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  reopened
 Priority:  normal        |   Milestone:
Component:  Security      |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+-----------------------
Changes (by d0rkpress):

 * status:  closed => reopened
 * resolution:  duplicate =>


Comment:

 > The fact that WordPress usernames practically are public means that
 changing the login messages are futile at this point.

 As said this is a bad idea from the security standpoint. It has been 12
 years ago as the first bug was file in this matter. And IMO it's not
 futile. Start with something. Then move on. I have to confess that I knew
 the other places before, not this one. Mostly because peers and customers
 of mine are having additional measures in place anyway at the login.

 > Instead of sarcasms, start arguing why WordPress should migrate to
 regarding usernames as secrets, in addition to the passwords.

 Forgive my sarcasm but to me it is that obvious that the whole world seems
 to know this is not any good -- except Wordpress who refuse to acknowledge
 this. Others in this thread were not even considering this and just
 closing it without consideration. So thanks for getting back to me.

 The most important argument is above in pure technical means  -- forget
 for now about  the other places which allows user name enumeration, let's
 do a step by step approach.

 Again I am try to outline this time more easily what I filed initially.
 This is the classical approach....

 Suppose I am am attacker. I have a laaarge dictionary of potential user
 names. I also have a dictionary of passwords. If I feed them to my
 favorite tool both user name and password need to match for being
 successful. That is quite a challenge.

 The step by step approach which I can do at wordpress logins is way better
 for me. I just feed first my fav tool with user names and grep for the
 string "is incorrect". Let's say after 7200 tries I am successful. If I
 can submit 4 requests per second and the server answers in the same time
 it I have the first username in 7200/4=1800 seconds, equals 30 minutes.

 Next step is to find a password. I have this cool dictionary with
 passwords. Now I use the username and feed the list of passwords into my
 tool. Let's say I need 7200 tries here to guess the user name.

 Thus I needed in total 30min + 30min = 1 hour to guess a user name.

 A scenario where there's no leakage of the existence of the username would
 make my life way more hard, it would be really discouraging: The math
 would be ~7200x7200 tries = 51840000 tries . If I manage to get 4 request
 back from the server that would be 12960000 seconds equals 3600 hours
 equals 150 days.

 So bottom line is a security decision between 1 hour or 150 days for one
 hacked account in this simple white board scenario. Or to put it the other
 way round in 150 days in a two step approach I would be guessing
 150x24x3600 = 12,960,000 accounts -- mathematically.

 This is the reason why no web application tells nowadays anymore whether
 the user exists or not. Frontends try also to avoid mail addresses as the
 username if possible as they can be retrieved in the underground for very
 little money. Pros use anti-automation measures (captchas, deliberate
 delays, throttling or any other security control) on AuthN functions as
 this and session management is THE CORE of any web application
 (https://www.owasp.org/index.php/Top_10-2017_A2-Broken_Authentication)

 A server of mine (Google lists 128k links) has a quarter of its traffic to
 /wp-login.php or /wp-admin from random IPs. I barely see traffic e.g.
 trying to find a Typo3 backend or Drupal probes. Can't tell what the WP
 traffic is about. I do not have wordpress but the mere fact that there are
 so many probes to an authentication frontend probably means that criminals
 are actively looking for it in order to do something with it which is  not
 good probably.


 As said, I know from my professional experience that there are other
 places where usernames can be enumerated. But please start with this
 obvious one and then I would recommend seriously start closing the others.
 Don't take them as an excuse for this one. There is no real reason for
 this one.


 And please put this on the agenda for internal discussion.

 I am reopening.

 Thanks!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/45318#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list