Hashing user_activation_key in the database

[Harry Metcalfe]

Hello all,

During a recent penetration test, the tester found an SQL injection in a
plugin. He used that injection to identify an administrative account,
then requested a password reset using the form, and then used the
injection to retrieve the user_activation_key. Because the key is not
hashed, he was able to immediately log in, without having to spend any
time trying to break the password hash.

Without finding an SQL injection or arbitrary code execution
vulnerability, this is not too much of an issue. But having found one of
those things, WordPress generating and setting an unhashed password for
the account (which is what it boils down to) makes obtaining
unauthorised access very much easier.

I think this is a straightforward enough thing to fix, and I'm happy to
jump in and do it. But I thought it might be sensible to consult this
list before I go and spend time making a patch for a trac ticket.

What do people (and in particular, core committers) think about this? Is
a sensible patch likely to be accepted?

Cheers,

Harry

[Harry Metcalfe]

PS: I tried to write a plugin to fix this in the interim but suitable
filters do not exist. That might also be a good thing to consider
adding, or making pluggable.


On 13/06/13 12:05, Harry Metcalfe wrote:
> Hello all,
>
> During a recent penetration test, the tester found an SQL injection in
> a plugin. He used that injection to identify an administrative
> account, then requested a password reset using the form, and then used
> the injection to retrieve the user_activation_key. Because the key is
> not hashed, he was able to immediately log in, without having to spend
> any time trying to break the password hash.
>
> Without finding an SQL injection or arbitrary code execution
> vulnerability, this is not too much of an issue. But having found one
> of those things, WordPress generating and setting an unhashed password
> for the account (which is what it boils down to) makes obtaining
> unauthorised access very much easier.
>
> I think this is a straightforward enough thing to fix, and I'm happy
> to jump in and do it. But I thought it might be sensible to consult
> this list before I go and spend time making a patch for a trac ticket.
>
> What do people (and in particular, core committers) think about this?
> Is a sensible patch likely to be accepted?
>
> Cheers,
>
> Harry
> _______________________________________________
> wp-hackers mailing list
> wp-***@lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers

[Mika Epstein]

If the injection came via a plugin, can you also email the plugin name and details to plugins AT Wordpress.org please?

On Jun 13, 2013, at 4:06 AM, Harry Metcalfe <***@dxw.com> wrote:

> PS: I tried to write a plugin to fix this in the interim but suitable filters do not exist. That might also be a good thing to consider adding, or making pluggable.
>
>
> On 13/06/13 12:05, Harry Metcalfe wrote:
>> Hello all,
>>
>> During a recent penetration test, the tester found an SQL injection in a plugin. He used that injection to identify an administrative account, then requested a password reset using the form, and then used the injection to retrieve the user_activation_key. Because the key is not hashed, he was able to immediately log in, without having to spend any time trying to break the password hash.
>>
>> Without finding an SQL injection or arbitrary code execution vulnerability, this is not too much of an issue. But having found one of those things, WordPress generating and setting an unhashed password for the account (which is what it boils down to) makes obtaining unauthorised access very much easier.
>>
>> I think this is a straightforward enough thing to fix, and I'm happy to jump in and do it. But I thought it might be sensible to consult this list before I go and spend time making a patch for a trac ticket.
>>
>> What do people (and in particular, core committers) think about this? Is a sensible patch likely to be accepted?
>>
>> Cheers,
>>
>> Harry
>> _______________________________________________
>> wp-hackers mailing list
>> wp-***@lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
> _______________________________________________
> wp-hackers mailing list
> wp-***@lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers

[Harry Metcalfe]

Yup, that was done at the time.

H


On 13/06/13 13:58, Mika Epstein wrote:
> If the injection came via a plugin, can you also email the plugin name and details to plugins AT Wordpress.org please?
>
> On Jun 13, 2013, at 4:06 AM, Harry Metcalfe <***@dxw.com> wrote:
>
>> PS: I tried to write a plugin to fix this in the interim but suitable filters do not exist. That might also be a good thing to consider adding, or making pluggable.
>>
>>
>> On 13/06/13 12:05, Harry Metcalfe wrote:
>>> Hello all,
>>>
>>> During a recent penetration test, the tester found an SQL injection in a plugin. He used that injection to identify an administrative account, then requested a password reset using the form, and then used the injection to retrieve the user_activation_key. Because the key is not hashed, he was able to immediately log in, without having to spend any time trying to break the password hash.
>>>
>>> Without finding an SQL injection or arbitrary code execution vulnerability, this is not too much of an issue. But having found one of those things, WordPress generating and setting an unhashed password for the account (which is what it boils down to) makes obtaining unauthorised access very much easier.
>>>
>>> I think this is a straightforward enough thing to fix, and I'm happy to jump in and do it. But I thought it might be sensible to consult this list before I go and spend time making a patch for a trac ticket.
>>>
>>> What do people (and in particular, core committers) think about this? Is a sensible patch likely to be accepted?
>>>
>>> Cheers,
>>>
>>> Harry
>>> _______________________________________________
>>> wp-hackers mailing list
>>> wp-***@lists.automattic.com
>>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>> _______________________________________________
>> wp-hackers mailing list
>> wp-***@lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
> _______________________________________________
> wp-hackers mailing list
> wp-***@lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers

[Sinan]

How much people download that plugin? Dont say name. I just wanna know is
it popular plugin.


2013/6/13 Harry Metcalfe <***@dxw.com>

> Yup, that was done at the time.
>
> H
>
>
>
> On 13/06/13 13:58, Mika Epstein wrote:
>
>> If the injection came via a plugin, can you also email the plugin name
>> and details to plugins AT Wordpress.org please?
>>
>> On Jun 13, 2013, at 4:06 AM, Harry Metcalfe <***@dxw.com> wrote:
>>
>> PS: I tried to write a plugin to fix this in the interim but suitable
>>> filters do not exist. That might also be a good thing to consider adding,
>>> or making pluggable.
>>>
>>>
>>> On 13/06/13 12:05, Harry Metcalfe wrote:
>>>
>>>> Hello all,
>>>>
>>>> During a recent penetration test, the tester found an SQL injection in
>>>> a plugin. He used that injection to identify an administrative account,
>>>> then requested a password reset using the form, and then used the injection
>>>> to retrieve the user_activation_key. Because the key is not hashed, he was
>>>> able to immediately log in, without having to spend any time trying to
>>>> break the password hash.
>>>>
>>>> Without finding an SQL injection or arbitrary code execution
>>>> vulnerability, this is not too much of an issue. But having found one of
>>>> those things, WordPress generating and setting an unhashed password for the
>>>> account (which is what it boils down to) makes obtaining unauthorised
>>>> access very much easier.
>>>>
>>>> I think this is a straightforward enough thing to fix, and I'm happy to
>>>> jump in and do it. But I thought it might be sensible to consult this list
>>>> before I go and spend time making a patch for a trac ticket.
>>>>
>>>> What do people (and in particular, core committers) think about this?
>>>> Is a sensible patch likely to be accepted?
>>>>
>>>> Cheers,
>>>>
>>>> Harry
>>>> ______________________________**_________________
>>>> wp-hackers mailing list
>>>> wp-***@lists.automattic.**com <wp-***@lists.automattic.com>
>>>> http://lists.automattic.com/**mailman/listinfo/wp-hackers<http://lists.automattic.com/mailman/listinfo/wp-hackers>
>>>>
>>> ______________________________**_________________
>>> wp-hackers mailing list
>>> wp-***@lists.automattic.**com <wp-***@lists.automattic.com>
>>> http://lists.automattic.com/**mailman/listinfo/wp-hackers<http://lists.automattic.com/mailman/listinfo/wp-hackers>
>>>
>> ______________________________**_________________
>> wp-hackers mailing list
>> wp-***@lists.automattic.**com <wp-***@lists.automattic.com>
>> http://lists.automattic.com/**mailman/listinfo/wp-hackers<http://lists.automattic.com/mailman/listinfo/wp-hackers>
>>
>
> ______________________________**_________________
> wp-hackers mailing list
> wp-***@lists.automattic.**com <wp-***@lists.automattic.com>
> http://lists.automattic.com/**mailman/listinfo/wp-hackers<http://lists.automattic.com/mailman/listinfo/wp-hackers>
>



--
Sinan İŞLER
sinanisler.com <http://www.sinanisler.com>
fb.com/sinanisler

[Phillip Lord]

I'm just wondering about the semantics of plugin names for wordpress; in
particular if I change the capitalisation of the my plugin name, will it
have any implications for the plugin on http://wordpress.org/plugins?

[Shea Bunge]

The plugin name in your readme.txt file can be anything you like. You can change it as much as you want, but your plugin will still live on the same page at http://wordpress.org/plugins, will use the same SVN repo, and will reside in the same folder name on WordPress installations and continue to recieve auto-updates. This is because it's the plugin slug that matters ( http://wordpress.org/plugins/plugin-slug ), not whatever you name the display name set in readme.txt or as 'Plugin Name:' in your plugin PHP file.


> From: ***@newcastle.ac.uk
> To: wp-***@lists.automattic.com
> Date: Fri, 14 Jun 2013 09:39:03 +0100
> Subject: [wp-hackers] Semantics of plugin name
>
>
>
> I'm just wondering about the semantics of plugin names for wordpress; in
> particular if I change the capitalisation of the my plugin name, will it
> have any implications for the plugin on http://wordpress.org/plugins?
>
> _______________________________________________
> wp-hackers mailing list
> wp-***@lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers

[Phillip Lord]

Where is the plugin-slug defined, then? It doesn't come from the source?

Phil

Shea Bunge <***@bungeshea.com> writes:
> The plugin name in your readme.txt file can be anything you like. You can
> change it as much as you want, but your plugin will still live on the same
> page at http://wordpress.org/plugins, will use the same SVN repo, and will
> reside in the same folder name on WordPress installations and continue to
> recieve auto-updates. This is because it's the plugin slug that matters (
> http://wordpress.org/plugins/plugin-slug ), not whatever you name the display
> name set in readme.txt or as 'Plugin Name:' in your plugin PHP file.
>
>
>> From: ***@newcastle.ac.uk
>> To: wp-***@lists.automattic.com
>> Date: Fri, 14 Jun 2013 09:39:03 +0100
>> Subject: [wp-hackers] Semantics of plugin name
>>
>>
>>
>> I'm just wondering about the semantics of plugin names for wordpress; in
>> particular if I change the capitalisation of the my plugin name, will it
>> have any implications for the plugin on http://wordpress.org/plugins?
>>
>> _______________________________________________
>> wp-hackers mailing list
>> wp-***@lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
> _______________________________________________
> wp-hackers mailing list
> wp-***@lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
>

--
Phillip Lord, Phone: [phone]
Lecturer in Bioinformatics, Email: ***@newcastle.ac.uk
School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower, skype: russet_apples
Newcastle University, twitter: phillord
NE1 7RU

[Sinan]

it is come from your title folder name

Your Title Here
your-title-here


2013/6/14 Phillip Lord <***@newcastle.ac.uk>

>
> Where is the plugin-slug defined, then? It doesn't come from the source?
>
> Phil
>
> Shea Bunge <***@bungeshea.com> writes:
> > The plugin name in your readme.txt file can be anything you like. You can
> > change it as much as you want, but your plugin will still live on the
> same
> > page at http://wordpress.org/plugins, will use the same SVN repo, and
> will
> > reside in the same folder name on WordPress installations and continue to
> > recieve auto-updates. This is because it's the plugin slug that matters (
> > http://wordpress.org/plugins/plugin-slug ), not whatever you name the
> display
> > name set in readme.txt or as 'Plugin Name:' in your plugin PHP file.
> >
> >
> >> From: ***@newcastle.ac.uk
> >> To: wp-***@lists.automattic.com
> >> Date: Fri, 14 Jun 2013 09:39:03 +0100
> >> Subject: [wp-hackers] Semantics of plugin name
> >>
> >>
> >>
> >> I'm just wondering about the semantics of plugin names for wordpress; in
> >> particular if I change the capitalisation of the my plugin name, will it
> >> have any implications for the plugin on http://wordpress.org/plugins?
> >>
> >> _______________________________________________
> >> wp-hackers mailing list
> >> wp-***@lists.automattic.com
> >> http://lists.automattic.com/mailman/listinfo/wp-hackers
> >
> > _______________________________________________
> > wp-hackers mailing list
> > wp-***@lists.automattic.com
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> >
> >
>
> --
> Phillip Lord, Phone: [phone]
> Lecturer in Bioinformatics, Email:
> ***@newcastle.ac.uk
> School of Computing Science,
> http://homepages.cs.ncl.ac.uk/phillip.lord
> Room 914 Claremont Tower, skype: russet_apples
> Newcastle University, twitter: phillord
> NE1 7RU
> _______________________________________________
> wp-hackers mailing list
> wp-***@lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>



--
Sinan İŞLER
sinanisler.com <http://www.sinanisler.com>
fb.com/sinanisler

[Shea Bunge]

Nope. It is built from the plugin name you enter when you submit the plugin to the WordPress.org repo, much in the same way a permalink is built from a post title in WordPress. After then it can't be changed.


> From: ***@newcastle.ac.uk
> To: wp-***@lists.automattic.com
> Date: Fri, 14 Jun 2013 11:08:18 +0100
> Subject: Re: [wp-hackers] Semantics of plugin name
>
>
> Where is the plugin-slug defined, then? It doesn't come from the source?
>
> Phil
>
> Shea Bunge <***@bungeshea.com> writes:
> > The plugin name in your readme.txt file can be anything you like. You can
> > change it as much as you want, but your plugin will still live on the same
> > page at http://wordpress.org/plugins, will use the same SVN repo, and will
> > reside in the same folder name on WordPress installations and continue to
> > recieve auto-updates. This is because it's the plugin slug that matters (
> > http://wordpress.org/plugins/plugin-slug ), not whatever you name the display
> > name set in readme.txt or as 'Plugin Name:' in your plugin PHP file.
> >
> >
> >> From: ***@newcastle.ac.uk
> >> To: wp-***@lists.automattic.com
> >> Date: Fri, 14 Jun 2013 09:39:03 +0100
> >> Subject: [wp-hackers] Semantics of plugin name
> >>
> >>
> >>
> >> I'm just wondering about the semantics of plugin names for wordpress; in
> >> particular if I change the capitalisation of the my plugin name, will it
> >> have any implications for the plugin on http://wordpress.org/plugins?
> >>
> >> _______________________________________________
> >> wp-hackers mailing list
> >> wp-***@lists.automattic.com
> >> http://lists.automattic.com/mailman/listinfo/wp-hackers
> >
> > _______________________________________________
> > wp-hackers mailing list
> > wp-***@lists.automattic.com
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> >
> >
>
> --
> Phillip Lord, Phone: [phone]
> Lecturer in Bioinformatics, Email: ***@newcastle.ac.uk
> School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord
> Room 914 Claremont Tower, skype: russet_apples
> Newcastle University, twitter: phillord
> NE1 7RU
> _______________________________________________
> wp-hackers mailing list
> wp-***@lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers

[Phillip Lord]

Ah, this is all fine then. I can change the name a bit and no one will
be affected.

Phil

Shea Bunge <***@bungeshea.com> writes:

> Nope. It is built from the plugin name you enter when you submit the plugin to
> the WordPress.org repo, much in the same way a permalink is built from a post
> title in WordPress. After then it can't be changed.
>
>
>> From: ***@newcastle.ac.uk
>> To: wp-***@lists.automattic.com
>> Date: Fri, 14 Jun 2013 11:08:18 +0100
>> Subject: Re: [wp-hackers] Semantics of plugin name
>>
>>
>> Where is the plugin-slug defined, then? It doesn't come from the source?
>>
>> Phil
>>
>> Shea Bunge <***@bungeshea.com> writes:
>> > The plugin name in your readme.txt file can be anything you like. You can
>> > change it as much as you want, but your plugin will still live on the same
>> > page at http://wordpress.org/plugins, will use the same SVN repo, and will
>> > reside in the same folder name on WordPress installations and continue to
>> > recieve auto-updates. This is because it's the plugin slug that matters (
>> > http://wordpress.org/plugins/plugin-slug ), not whatever you name the display
>> > name set in readme.txt or as 'Plugin Name:' in your plugin PHP file.
>> >
>> >
>> >> From: ***@newcastle.ac.uk
>> >> To: wp-***@lists.automattic.com
>> >> Date: Fri, 14 Jun 2013 09:39:03 +0100
>> >> Subject: [wp-hackers] Semantics of plugin name
>> >>
>> >>
>> >>
>> >> I'm just wondering about the semantics of plugin names for wordpress; in
>> >> particular if I change the capitalisation of the my plugin name, will it
>> >> have any implications for the plugin on http://wordpress.org/plugins?
>> >>
>> >> _______________________________________________
>> >> wp-hackers mailing list
>> >> wp-***@lists.automattic.com
>> >> http://lists.automattic.com/mailman/listinfo/wp-hackers
>> >
>> > _______________________________________________
>> > wp-hackers mailing list
>> > wp-***@lists.automattic.com
>> > http://lists.automattic.com/mailman/listinfo/wp-hackers
>> >
>> >
>>
>> --
>> Phillip Lord, Phone: [phone]
>> Lecturer in Bioinformatics, Email: ***@newcastle.ac.uk
>> School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord
>> Room 914 Claremont Tower, skype: russet_apples
>> Newcastle University, twitter: phillord
>> NE1 7RU
>> _______________________________________________
>> wp-hackers mailing list
>> wp-***@lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
> _______________________________________________
> wp-hackers mailing list
> wp-***@lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
>

--
Phillip Lord, Phone: [phone]
Lecturer in Bioinformatics, Email: ***@newcastle.ac.uk
School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower, skype: russet_apples
Newcastle University, twitter: phillord
NE1 7RU

[Harry Metcalfe]

It's quite popular, but it's already been patched and a new version
released. So if you're up to date you'll be fine.

Harry


On 13/06/13 17:32, Sinan wrote:
> How much people download that plugin? Dont say name. I just wanna know is
> it popular plugin.
>
>
> 2013/6/13 Harry Metcalfe <***@dxw.com>
>
>> Yup, that was done at the time.
>>
>> H
>>
>>
>>
>> On 13/06/13 13:58, Mika Epstein wrote:
>>
>>> If the injection came via a plugin, can you also email the plugin name
>>> and details to plugins AT Wordpress.org please?
>>>
>>> On Jun 13, 2013, at 4:06 AM, Harry Metcalfe <***@dxw.com> wrote:
>>>
>>> PS: I tried to write a plugin to fix this in the interim but suitable
>>>> filters do not exist. That might also be a good thing to consider adding,
>>>> or making pluggable.
>>>>
>>>>
>>>> On 13/06/13 12:05, Harry Metcalfe wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> During a recent penetration test, the tester found an SQL injection in
>>>>> a plugin. He used that injection to identify an administrative account,
>>>>> then requested a password reset using the form, and then used the injection
>>>>> to retrieve the user_activation_key. Because the key is not hashed, he was
>>>>> able to immediately log in, without having to spend any time trying to
>>>>> break the password hash.
>>>>>
>>>>> Without finding an SQL injection or arbitrary code execution
>>>>> vulnerability, this is not too much of an issue. But having found one of
>>>>> those things, WordPress generating and setting an unhashed password for the
>>>>> account (which is what it boils down to) makes obtaining unauthorised
>>>>> access very much easier.
>>>>>
>>>>> I think this is a straightforward enough thing to fix, and I'm happy to
>>>>> jump in and do it. But I thought it might be sensible to consult this list
>>>>> before I go and spend time making a patch for a trac ticket.
>>>>>
>>>>> What do people (and in particular, core committers) think about this?
>>>>> Is a sensible patch likely to be accepted?
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Harry
>>>>> ______________________________**_________________
>>>>> wp-hackers mailing list
>>>>> wp-***@lists.automattic.**com <wp-***@lists.automattic.com>
>>>>> http://lists.automattic.com/**mailman/listinfo/wp-hackers<http://lists.automattic.com/mailman/listinfo/wp-hackers>
>>>>>
>>>> ______________________________**_________________
>>>> wp-hackers mailing list
>>>> wp-***@lists.automattic.**com <wp-***@lists.automattic.com>
>>>> http://lists.automattic.com/**mailman/listinfo/wp-hackers<http://lists.automattic.com/mailman/listinfo/wp-hackers>
>>>>
>>> ______________________________**_________________
>>> wp-hackers mailing list
>>> wp-***@lists.automattic.**com <wp-***@lists.automattic.com>
>>> http://lists.automattic.com/**mailman/listinfo/wp-hackers<http://lists.automattic.com/mailman/listinfo/wp-hackers>
>>>
>> ______________________________**_________________
>> wp-hackers mailing list
>> wp-***@lists.automattic.**com <wp-***@lists.automattic.com>
>> http://lists.automattic.com/**mailman/listinfo/wp-hackers<http://lists.automattic.com/mailman/listinfo/wp-hackers>
>>
>
>

[Andrew Nacin]

On Thu, Jun 13, 2013 at 7:05 AM, Harry Metcalfe <***@dxw.com> wrote:

> Hello all,
>
> During a recent penetration test, the tester found an SQL injection in a
> plugin. He used that injection to identify an administrative account, then
> requested a password reset using the form, and then used the injection to
> retrieve the user_activation_key. Because the key is not hashed, he was
> able to immediately log in, without having to spend any time trying to
> break the password hash.
> [...]
> What do people (and in particular, core committers) think about this? Is a
> sensible patch likely to be accepted?
>

I think the security team (a superset of the core committers) would have
some pretty interesting opinions on this. In the future, is best to email
***@wordpress.org to get initial feedback before posting to a public
forum. We'll thank you for responsibly starting a private communication
with us and direct you to a public forum as appropriate.

I would suggest that, while it is not a bad idea, such a vulnerability
could always be used to change the user's hash. Of course, there are
situations where a vulnerability will only result in reading data, not
writing it. Again, ***@wordpress.org in the future please, thanks.

Nacin