Drupal CSRF Exploit reported on packetstorm
Heine —Fri, 2012/03/09 - 11:06
Update: The Drupal security team just published an official, detailed response.
On March 2nd 2012, security researcher Ivano Binetti published an advisory on Drupal 7 anti-CSRF measures. He/She rightly identified the long standing Logout CSRF annoyance (#144538), but the rest of his/her advisory is not helpful.
Form Build ID
Contrary to what's said in the advisory, Drupal 6 and 7 do not use the form-build-ID to protect against CSRF. The build-ID is used to fetch state from a database table during certain operations.
Anti-CSRF token system
In accordance with OWASP CSRF recommendations Drupal uses the field form_token to protect against CSRF with a challenge token that is tied to the current user's session and the form's form_id (not form-build-ID). The form_token has to remain secret.
Defeat the anti-CSRF token system
There are several ways for the anti-CSRF challenge token system to be defeated:
- When the site has a Cross site scripting (XSS) vulnerability.
- When traffic between an authorized user agent and the server can be sniffed.
- When traffic between an authorized user agent and the server can be intercepted, changed and send on in a Man In The Middle attack (MITM).
The token challenge system was not designed to cope with these issues as the defenses were either pointless or impossible. As an example; When traffic can be sniffed or intercepted, an attacker can in typical cases simply extract the authorized user's password or session ID and use these to get access to the site.
The proposed HTTP_REFERRER check in 2.4 is also not very helpful. It fails just like the challenge token system when the site has an XSS vulnerability. In addition, user-generated content on the same site can also bypass the check by design.
Defenses
In order to prevent a bypass of the anti-CSRF system, Drupal developers or site administrators should use appropriate defenses:
- Prevent sniffing and MITM with HTTPS.
- Prevent XSS by using the appropriate APIs.
Summary
Apart from the Logout link, the advisory does not identify an exploitable CSRF issue in Drupal 7.
This is not an official security team response. I've stepped down as team lead.
Comments
Thank you Heine, that all
Submitted by Anonymous (not verified) on Fri, 2012/03/09 - 14:33Thank you Heine, that all makes sense. Has Mr Binetti's exploit (3.1) been tested?
Yes.
Submitted by Heine on Fri, 2012/03/09 - 14:54Yes.
It works (if modified to be correct) if you can get an authorized user to visit a page containing this HTML provided you know the anti-CSRF form_token that is valid for this user's session.
My Reply to Heine considerations
Submitted by Ivano Binetti (not verified) on Fri, 2012/03/09 - 17:59Dear friends, please read my reply to Heine's considerations.
http://ivanobinetti.blogspot.com/2012/03/more-about-drupal-712-csrf-expl...
Your packetstorm 'advisory'
Submitted by Heine on Fri, 2012/03/09 - 18:14Your packetstorm 'advisory' contains the following sentence, which makes it clear you think form_build_id is a CSRF defense.
The rest of your advisory was indeed handled in my post. I argue that your proposed solutions would do nothing to contain the problem and that you should defend against these scenarios with proper, proven technology such as HTTPS, not some hacked-up, unproven tech that has similar failures.
My friend, you still don't
Submitted by Ivano Binetti (not verified) on Fri, 2012/03/09 - 18:27My friend, you still don't consider the main problem: "form_token" security flaw.
Reading my Advisory effectively might seems that "form_build_id" is an anti-CSRF parameter but I've explained better my opinion in my latest post in my blog:
"I've noticed as is possible to use any Drupal compatible form_build_id instead of the right one - specifically create for that operation - in order to use my exploit and add an Drupal admin.
You said that form_build_id is used "to fetch state from a database table during certain operations." Do you think that is normal that I can modify a parameter as I want and Drupal does not care about it?"
Then please elaborate
Submitted by Heine on Fri, 2012/03/09 - 18:39As I said and explained above; There's no relevant scenario where your claimed "form_token security flaw" operates. You can repeat yourself over and over, but it might be more productive to elaborate on your concern and what attack scenarios are involved.
Update: After some back and forth, I understand that you feel that the form_token must be unique for every operation on the site. As said above, I disagree. In none of the attack scenarios you described would this make a difference for the exploitability of the site. Taping some scotch over the safe's door doesn't make it less prone to break-in when there's a gaping hole in the side.
Yes, I consider form_build_id handling by design and appropriate.
Ok the scenario is the
Submitted by Ivano Binetti (not verified) on Fri, 2012/03/09 - 19:05Ok the scenario is the following:
a lamer (internal attacker o attacker who gained an internal client control) is sniffing you network. He could simply (with very low level skills) sniff your "form_token" parameter and use my CSRF exploit - also CSRF exploit is very simple to use - to modify (delete pages, create new admin, and so on). In my opinion to make session control through Session ID is more complicated but I've indicated you a simple scenario in order to exploit "form_token" flaw.
Instead of flooding my Twitter account, and ask me what could be attack scenario you should focus your attention to the source of the problem and sanitize "form_token" parameter. There are many and many attacks scenarios. You should only have more imagination.
Ok, I guess we can consider
Submitted by Heine on Fri, 2012/03/09 - 19:09Ok, I guess we can consider this conversation as concluded. Silly me!
If you want to discuss with the Drupal security team, security@drupal.org is but a mail away.