New Advisory related to a new CSRF vulnerability in RazorCMS 1.2.1 and lower.

Other publications:
Offensive Security Exploit-db
Packet Storm Security

This morning I’ve received a tweet from Heine – who “provide free Drupal support on the Drupal.org forum” –  who invite me to read his article (Heine’s article) about my security advisory related to latest stable version (7.12) of Dupal cms.

In his article Heine said that I’ve “rightly identified” a CSRF vulnerability which allows to force logout administrator, but he does not refer to the main problem which I’ve identified in my advisory:  form_token (anti-CSRF) security flaw, as you can read in my security advisory:
http://ivanobinetti.blogspot.com/2012/03/drupal-cms-712-latest-stable-release.html

“form_token” (anti-CSRF) security flaw
As reported in my Advisory:

“In “form_token” parameter there is another security flaw inside the logic with which this parameter is generated, because is used the  same parameter for for similar operations  in the same session (for example for article’s creation Drupal assigns the same “form_token”, for admin/user
creation Drupal assigns the same “form_token” and so on). This flaw can be used by un attacker which  knows the values of “form_buid_id” and “form_token” parameters (for example an internal attacker performing a “Man in The Middle Attack” or an external attacker that controls an internal client by an client-side exploit, an external attacker that controls directly a Drupal admin by a client-side exploit and son on. There are many possibilities to create an “ad-hoc” crafted web page that allows to performs any Drupal changes (add administrator, delete administrator, add web pages, delete  web pages, and so on) when a Drupal administrator or User browses that crafted web page. ”

This means that the anti-CSRF “form_token” parameter is not unique for any operations but is the same (in the same session obviously) for similar operation. An attacker – also with low knowledge of Man in the Middle attack – can sniff  anti-CSRF parameter and – without make a rewrite rule in order to modify the traffic in real time (this might require some more skills) – could use sniffed  “form_token” parameter to change Drupal settings.
This is the main flaw which I’ve described and which Heine did not mention in his article.

“form_buid_id” parameter 
As you can read in my advisory I’ve never said that “form_build_id” is an anti-CSRF parameter but I’ve noticed as is possible to use any Drupal compatible form_build_id instead of the right one – specifically created  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?


Http Referer
I confirm you that if you would make void my exploit Drupal have to:

• use “http referer” check , which is not in contradiction with form_token check, but  it can only increase Drupal’s security level. 
•  fix “form_token” flaw.

HTTPS protection
Drupal default installation does not provide default http to https redirection.

p.s. I think that Drupal is a great cms and may be I’ll use it in my blog.