[prev in list] [next in list] [prev in thread] [next in thread] 

List:       full-disclosure
Subject:    Re: [FD] Go Home WP-API, You're Drunk...
From:       Scott Arciszewski <scott () arciszewski ! me>
Date:       2014-10-29 12:48:44
Message-ID: CAPKwhwuaVwaw3X3a9erqJr_OJEw2nuBN0Qn-Wbx=DA15Bu57Og () mail ! gmail ! com
[Download RAW message or body]

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@arciszewski.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/


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic