FlexCMS Multiple CSRF Vulnerabilities

FlexCMS 3.2.1(latest version) suffers from multiple CSRF vulnerabilities which could allow an attacker to change any parameters when an authenticated user/admin browses a special crafted web page. In this Advisory I’ve only demonstrate how to change settings of user “demo” (is default user of demo page) and also I’ve created a new web page.

To read more about them you can download my Original Advisory.

MITRE CVE Numbering Authority assigned me CVE-2012-1901 for this vulnerability,

Other related publications:

Offensive Security Exploit-DB
NIST – National Vulnerability Database
Packet Storm
Secunia Advisory SA48451
Kaspersky Lab Advisory
IBM X-Force

Sitecom WLM-2501 Change Wireless Passphrase

Yesterday I’ve discovered new CSRF vulnerabilities in Sitecom WLM-2501 300N wireless modem/router which allow an attacker to change a lot of device parameter and, most of all, to change wireless passphrase.

To know more about these vulnerabilities please read my Original Advisory.

MITRE CVE Numbering Authority assigned me CVE-2012-1921 and CVE-2012-1922 for these vulnerabilities.

Other sources have published my Advisory:
Secunia Security Advisory 48840
Packet Storm
Offensive Security Exploit-DB
IBM X-Force
Security Focus

More about Drupal 7.12 CSRF Exploit

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:

“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.

Webfolio <= 1.1.4 Multiple XSS

WebfolioCMS 1.1.4 (and lower) is prone to multiple XSS vulnerabilities in “webfolio/admin/users/edit/<used_id>” path  – where <used_id> = 1….n – due to an improper input sanitization.

To download my Original Advisory:
Webfolio <= 1.1.4 Multiple XSS

Other publications: