Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Exploiting authorization by nonce in WordPress plugins

nowotarski.info

Post reply on HN
Print view View original

21–30 of 45 posts

Re: Exploiting authorization by nonce in WordPress plugins

#21

Post by exe34 »

SketchySeaBeast wrote: post #19
savolai wrote: post #12

Earlier quoted context omitted.

It can indeed be incredibly confusing for users if that is not disclosed, bordering on hostile. It is a common pattern to reregister i.e. when in a hurry so you end up with multiple ids. If you also have userids in addition to email addresses, it can easily become a hard problem in itself to solve/remember which email/pw corresponds to which userid. Obfuscating user/password error messages can make this much worse. T…

It makes it so much easier for attackers - they then can know that a user has an account there too, and can then use that information to find that user's other known passwords. It's offering up information the attacker might not have.

all it has to say is "if you have an account with us, check your email address you just used"

Re: Exploiting authorization by nonce in WordPress plugins

#22

Post by nightpool »

I'm not sure I really understand the weight this article gives to "nonces"—from an outside perspective, it seems like writing an titled "Exploiting authorization via cookie on Google.com" when you've found a simple XSS. In each case, the problem isn't the nonce itself, but rather the fact that developers are 1) allowing arbitrary file uploads with insecure sanitization, 2) embedding a secret value in frontend JSON blobs that any user can read, or 3) a completely unrelated SQL injection vulnerability.

For #3 especially, it's pretty confusing to single out nonces as especially vulnerable. Any secret defined in wp_config would have been similarly exposed by this exploitation method. For example, the SECURE_AUTH_KEY or the LOGIN_KEY. If you had found an installation that put those values in the database (probably common for multiuser installs), would you have instead written an article that claimed "Wordpress logged in sessions should never be used for authentication"? Or that wordpress auth sessions are "often misused by developers"? Similarly with #2, you make a haphazard effort to tie the improperly sanitized uploaded files back to nonces by saying "a nonce is required to acces the uploaded file", but that really doesn't have anything to do with the vulnerability itself—many users on wordpress installs are required / expected to upload publicly visible files, or files visible to their own user. Or even files visible to the administrator! The method of authenticating access to the files has nothing to do with the vulnerability itself, it was only a small piece of trivia required to properly exploit it in this specific plugin in some cases.

Re: Exploiting authorization by nonce in WordPress plugins

#23

Post by nightpool »

nightpool wrote: post #22

I'm not sure I really understand the weight this article gives to "nonces"—from an outside perspective, it seems like writing an titled "Exploiting authorization via cookie on Google.com" when you've found a simple XSS. In each case, the problem isn't the nonce itself, but rather the fact that developers are 1) allowing arbitrary file uploads with insecure sanitization, 2) embedding a secret value in frontend JSON bl…

After some thinking: I think a large part of the blame here also falls on the Wordpress documentation. It says that nonces should "never be used for authentication, authorization or access control", but it doesn't explain why. In actuality, nonces seem like they could be a very useful way to authenticate certain actions when a classic authentication session is not available (for example, when sending a user an email that allows them to take an action that they may view on another device or without an existing session, like a "password reset" form, or when authenticating a webhook callback). The fact that plugin developers aren't given enough info to reason through the security implications themselves makes these kind of mistakes more likely, and it also leads to this "cargo cult" security mindset you see in the article where any use of the nonce value magically makes your plugin less secure, regardless of the context. Instead of reasoning through what actually caused the 3 vulnerabilities found, the author just blames the problem on nonces.

And another thing, if Wordpress developers really only want nonces to be used for CSRF prevention alone, why are they so complicated and so exposed to the developer? A more simpler and less "security by complexity" based approach would be to just e.g. use a cookie with a random value and a hidden field with a random value and expect them to match, like Rails does. If these nonces didn't have all of this "hash the user's ID and session token and the current action and add in a 12 hour lifetime" complexity, then developers would be much less tempted to use them for authentication. Additionally, why is the "verify" function exposed to developers at all, instead of being part of a higher level function like "register ajax route" or "register post route"? These are all weaknesses in architecture that make the misuse of nonce values for things beyond CSRF tokens more likely. It's not enough to just write a few lines of documentation and say "There we go, I've secured everything now!". You need to actually figure out what use-cases people are using these functions for and then figure out more secure-by-default ways to address those use-cases, otherwise you're not going to make any progress.

Re: Exploiting authorization by nonce in WordPress plugins

#24

Post by dec0dedab0de »

bubblebeard wrote: post #8

This reminds me of an article in which brute forcing the WP admin panel was discussed. The problem was that when supplying inaccurate user credentials you would get an error message telling you which was wrong. Their dev stated this was a design choice, that you needed to balance security and user friendlyness. Security in WP seems more like an afterthought to me, which is a shame to say the least.

I think that is a valid stance to take by default, and maybe have the option to change it.

If you force good passwords it really shouldn’t matter too much if the usernames can be enumerated.

Re: Exploiting authorization by nonce in WordPress plugins

#25

Post by chgs »

bubblebeard wrote: post #8

This reminds me of an article in which brute forcing the WP admin panel was discussed. The problem was that when supplying inaccurate user credentials you would get an error message telling you which was wrong. Their dev stated this was a design choice, that you needed to balance security and user friendlyness. Security in WP seems more like an afterthought to me, which is a shame to say the least.

Yes it is a choice and security is a balance. You could encase the server in lead and drop that to the bottom of the sea, but that would be an extreme on the “security” side. You could do away with user authentication completely, that would be an extreme the other way.

Re: Exploiting authorization by nonce in WordPress plugins

#26

Post by wongarsu »

SketchySeaBeast wrote: post #19
savolai wrote: post #12

Earlier quoted context omitted.

It can indeed be incredibly confusing for users if that is not disclosed, bordering on hostile. It is a common pattern to reregister i.e. when in a hurry so you end up with multiple ids. If you also have userids in addition to email addresses, it can easily become a hard problem in itself to solve/remember which email/pw corresponds to which userid. Obfuscating user/password error messages can make this much worse. T…

It makes it so much easier for attackers - they then can know that a user has an account there too, and can then use that information to find that user's other known passwords. It's offering up information the attacker might not have.

Most applications end up disclosing that anyways either by a success message in the password reset flow, or a "email already in use" message in the registration flow. Obscuring who has an account is a major commitment for the design of any unauthenticated api, one that's both difficult and often user-hostile. And if you trip up once you have a worst-of-both-worlds where you've both made your website worse for your users and attackers can still easily check if someone is a user.

Wordpress takes almost the opposite approach: They consider the fact that you are an author on a page public information. There is even the /wp-json/wp/v2/users api to enumerate them At least they don't show email addresses, but you can also login with the username. ([1],[2] for examples in the wild).

Of course as a wordpress admin you can decide differently: extensibility is one of the core pillars of wordpress. Security arguably is placed behind extensibility and user-friendliness.

1: https://quebec.ubisoft.com/en/wp-json/wp/v2/users

2: https://www.rollingstone.com/wp-json/wp/v2/users

Re: Exploiting authorization by nonce in WordPress plugins

#27

Post by dawnerd »

The problem isn’t with Wordpress, it’s with it being so accessible that the lowest bar dev shops spit out code as quick and cheaply as possible. Best way to avoid security issues is to not use third party plugins or themes without auditing them.

Even popular plugins don’t do the bare minimum like escaping output.

Re: Exploiting authorization by nonce in WordPress plugins

#28

Post by bubblebeard »

throwaway2016a wrote: post #18
bubblebeard wrote: post #8

This reminds me of an article in which brute forcing the WP admin panel was discussed. The problem was that when supplying inaccurate user credentials you would get an error message telling you which was wrong. Their dev stated this was a design choice, that you needed to balance security and user friendlyness. Security in WP seems more like an afterthought to me, which is a shame to say the least.

It's not quite so clear cut. Close. Even OWASP acknowledges there are trade offs: > The problem with returning a generic error message for the user is a User Experience (UX) matter. A legitimate user might feel confused with the generic messages, thus making it hard for them to use the application, and might after several retries, leave the application because of its complexity. The decision to return a generic error…

I think this is a valid point. At least for frontend usage I can see how less generic messages might make sense. I would still opt for generic messages, but I’m also a little paranoid ;)

Re: Exploiting authorization by nonce in WordPress plugins

#29

Post by mikrl »

francis-io wrote: post #2

Unfortunate naming... https://dictionary.cambridge.org/dictionary/english/nonce

The preferred spelling of nonse is n-o-n-S-e although c-e is an acceptable ethnic variant.

Source: originally come from a time and place where you call your friends one for a laugh (and shout it at actual ones you know from cars)

Re: Exploiting authorization by nonce in WordPress plugins

#30

Post by bubblebeard »

chgs wrote: post #25
bubblebeard wrote: post #8

This reminds me of an article in which brute forcing the WP admin panel was discussed. The problem was that when supplying inaccurate user credentials you would get an error message telling you which was wrong. Their dev stated this was a design choice, that you needed to balance security and user friendlyness. Security in WP seems more like an afterthought to me, which is a shame to say the least.

Yes it is a choice and security is a balance. You could encase the server in lead and drop that to the bottom of the sea, but that would be an extreme on the “security” side. You could do away with user authentication completely, that would be an extreme the other way.

That’s true and I see your point. Personally I do not understand this choice in contrast to an admin panel though.
Post reply on HN