sarciszewski · October 29, 2014 00:02
diff --git a/wp-api.txt b/wp-api.txt
 ... 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 honour 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.
	... 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 honour 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.