Date: Wed, 29 Oct 2014 08:48:44 -0400
From: Scott Arciszewski <scott@...iszewski.me>
To: Nahuel Grisolía <nahuel.grisolia@...il.com>
Cc: fulldisclosure@...lists.org
Subject: Re: [FD] Go Home WP-API, You're Drunk...

Yes, you're absolutely right. When I said it's "almost the ideal situation"
I probably should have clarified what I meant.

I meant to say that in both WP-API's code and in textbook examples of hash
constructs specifically vulnerable to length extension attacks involve
concatenating the data you are intending to authenticate with a
cryptographic secret. While their particular order is not known (to me,
anyway) to be as easily exploited, concatenation then passing to an unsafe
hash function like MD5 is a bad practice that should be avoided.
(Interestingly, the Keccak designers claim it's perfectly safe to do this
with hash function.)

Thanks for pointing out my lapse in clarity.

Scott
Hi! I believe that what you're saying in number 2 is not completely true.

I agree that an hmac is safer. Correct me if I'm wrong but $secret should
be at the beginning of the string in order to run a lenth extension attack.

Cheers,

Nahu.-


On Tuesday, 28 October 2014, Scott Arciszewski <scott@...iszewski.me> wrote:

> ... or more accurately, asleep at the wheel!
>            _______________________________________________________
>  _________/ STORY TIME (feel free to skip this if you don't care)
> \__________
> |
>   |
> | Recently, I made a quick analysis of all of the public projects listed
>    |
> | on HackerOne. https://gist.github.com/sarciszewski/04ee71ad2bcddc9c33b9
>   |
> |
>   |
> | If you scroll to the bottom, I listed several projects in the "sweet
>    |
> | spot": open source AND a minimum bounty. Outside of the Internet Bug
>    |
> | Bounty project, there are only two projects listed: WP-API and Ian Dunn
> (a |
> | WordPress developer who has many projects).
>   |
> |
>   |
> | In the past three weeks, I have opened a handful of bug reports for
> other  |
> | projects using the HackerOne platform, and they all responded
> immediately. |
> | Joola.io, for example, had a fix ready within a day of being notified.
>    |
> | Concrete5 asked me to send a pull request to fix the issue I raised.
> Both  |
> | projects, in my opinion, deserve further scrutiny and assistance.
> Srsly.   |
> |
>   |
> | WP-API, however, still has yet to even acknowledge the bug report
> sitting  |
> | in the issue tracker for 17 days (and counting). Even when pressed for
> a   |
> | simple "We got your report, here's an estimate on when we can get to
> it,"  |
> | I was met with complete radio silence. I sent one last update to my bug
>   |
> | reports asking to respond before 8 PM or I will post on Full Disclosure
>   |
> | everything I have found (which, while not exactly the most impressive
> bugs |
> | anyone will see on this list this month, are at least deserving of some
>   |
> | sort of response).
>    |
> |
>   |
> | So here we are.
>   |
>
> |____________________________________________________________________________|
>
> I. WP-API/Key-Auth
>
>
> https://github.com/WP-API/Key-Auth/blob/f9b74b3e4df667cfb44baba556eafde65fa3aec9/key-auth.php#L50
>
> https://github.com/WP-API/Key-Auth/blob/f9b74b3e4df667cfb44baba556eafde65fa3aec9/key-auth.php#L65
>
> This is pretty much a textbook example of "How Not to Implement Signature
> Verification." Let's count the things wrong with it!
>
>   1. json_encode() can return FALSE and there is no error checking
> employed (I
>      am pretty sure an attacker can trigger this condition easily).
>
>   2. md5($arbitrary . $secret) is almost the ideal situation for length-
>      extension attacks.
>
>      hash_hmac('sha256', $arbitrary, $secret) would be considerably safer.
>
>   3. Signature not compared in constant time (while timing attacks are not
> the
>      most trivial attack to perform, and are noisy as all hell, it's still
>      problematic for authentication code to not provide this protection).
>
>   4. Signatures are compared with a non-strict != operator.
>      PROTIP: https://eval.in/108854
>
> II. WP-API/OAuth1
>
>
> https://github.com/WP-API/OAuth1/blob/45197eca2925f5022192903d3639decd0ae1811c/lib/class-wp-json-authentication-oauth1.php#L290
>
> https://github.com/WP-API/OAuth1/blob/45197eca2925f5022192903d3639decd0ae1811c/lib/class-wp-json-authentication-oauth1.php#L562
>
> Same as point 3 from Key-Auth with regard to timing attacks. However, this
> is
> not an isolated incident. Many OAuth1 and OAuth2 libraries have the exact
> same
> problem. In fact, feel free to reuse a solution I submitted to one of these
> projects to patch it.
>
> * https://github.com/bshaffer/oauth2-server-php/pull/480
>
> If I were a betting man, I would wager that most OAuth server
> implementations
> fail to take the necessary precautions when handling cryptographic
> signatures.
> Which is sort of funny when you think about the fact that that's their
> entire
> reason for existing.
>
> Point being: I don't blame WP-API for this one, considering how many
> OAuth1/2
> server implementations I've seen with similar weaknesses, and also
> considering
> that there aren't many (any?) botnets spawned from timing attacks. Yet.
>
>
> #============================================================================#
>
> If the WP-API team would like to still honor their bounty, I encourage them
> to instead donate it to the PayPal 14, whom are being sentenced tomorrow.
>
>                       http://www.gofundme.com/Paypal14
>
> That's all from me. Hopefully someone can kick the right person in the ass
> to
> prompt the maintainers into action to actually respond to reports on
> HackerOne
> for a change.
>

_______________________________________________
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists