Wolfcms <= 0.75 Multiple Vulnerabilities

Wolfcms 0.75 (and lower) is prone to multiple CSRF vulnerabilities that allow to delete admin/user, delete web pages, delete “images” and “themes” directory, force logout  when an authenticated admin/user browses a special crafted web page.
This cms is also affected by XSS vulnerabilities in “wolfcms/admin/user/add” pages due to an improper input sanitization of “user[name]”, “user[email]” and “user[username]” parameters passed via POST http method.

To view my Original Advisory:
Wolfcms 0.75 Multiple Vulnerabilities (CSRF-XSS)

Other related publications:
Inj3ct0r
Packet Storm
Secunia
Kaspersky Lab
Offensive Security DB
IBM X-Force Wolfcsm XSS
IBM X-Force Wolfcms CSRF
OSVDB
NIST – NVDB

 

Sitecom WLM-2501 new Multiple CSRF Vulnerabilities

The web interface of this router is affected by multiple CSRF vulnerabilities which allows to change the following device’s parameters:

    • Disable Mac Filtering
    • Disable/Modify IP/Port Filtering
    • Disable/Modify Port Forwarding
    • Disable/Modify Wireless Access Control
    • Disable Wi-Fi Protected Setup
    • Disable/Modify URL Blocking Filter
    • Disable/Modify Domain Blocking Filter
    • Disable/Modify IP Address ACL
    • Change Wireless Passphrase
    • Enable/Modify Remote Access (also on WAN interface)

To view my Original Advisory:
Sitecom WLM-2501 new Multiple CSRF Vulnerabilities

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

Other related publications:
Secunia Advisory SA48840
Inj3ct0r
Packet Storm
Offensive Security DB
Security Focus
IBM X-Force
OSVDB
http://packetstormsecurity.org/files/111941/Secunia-Security-Advisory-48840.html

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
Inj3ct0r
Packet Storm
Secunia Advisory SA48451
Kaspersky Lab Advisory
OSVDB
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
Inj3ct0r
IBM X-Force
Security Focus
http://packetstormsecurity.org/files/111941/Secunia-Security-Advisory-48840.html

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

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:
http://packetstormsecurity.org/files/110524/Webfolio-CMS-1.1.4-Cross-Site-Scripting.html
http://1337day.com/exploits/17634
http://www.securityfocus.com/bid/52335
http://osvdb.org/show/osvdb/80218

Drupal CMS 7.12 (latest stable release) Multiple Vulnerabilities

Drupal 7.12 – latest stable release – suffers from multiple vulnerabilities which could allow an attacker to gain access to the management interface.

Poor Session Checking (CSRF to change any Drupal settings)
Drupal, to secure changes made by administrators or users through web management interface, uses “form_token” parameter which is sent inside any http POST request. There is a security flaw inside the logic with which this parameter is generated, as is used the same parameter for for similar operations  (the same “form_id”) 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).
Another flaw is inside “form_buid_id” parameter, which is used “to fetch state from a database table during certain operations”. This parameter is generated different for any operation an admin/user performs, but Drupal allows to use any other Drupal generated “form_buid_id” parameter
(like this: “form-0iFqLlofT1uuJ_uwXPNdVlc_J9KL20oZE15dK9hxuQ8”) to make changes to Drupal settings through web management  interface. So, even if Drupal  creates a different “form_buid_id” for any operation you can use another “form_buid_id”compatible with Drupal instead of that generated by Drupa for that specific operation.
These flaws can be used by an attacker who 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
in order to makes any Drupal changes (add administrator, delete administrator, add web pages, delete web pages, ….) when a Drupal administrator
or User browses that crafted web page.

Poor Session Checking (CSRF to Force administrator logout)
There is another vulnerability – always related to poor session checking / improper input validation – in “<drupal_ip>/user/logout” which allows an attacker to create a crafted web page an force logout of Drupal administrator/users at web management interface. This vulnerability – forcing administrator logout – will aid an attacker to sniff authentication credentials when a “Man in The Middle Attack” is performed.

Poor Session Checking (POST and GET method)
Drupal does not check “GET” or “POST” http method allowing, even though normal logout is made via http GET request, to exploit the above vulnerability using http POST method.

Poor Session Checking (Http Referer)
Drupal, furthermore, does not perform “http referer” checking, allowing to exploit all above described vulnerabilities.

To download my Original Advisory:

Drupal 7.12 (latest stable release) Multiple Vulnerabilities

Other web sites that have published my Advisory:
CVE-2007-6752
http://osvdb.org/show/osvdb/80665
http://secunia.com/advisories/cve_reference/CVE-2007-6752/
http://xforce.iss.net/xforce/xfdb/73674
http://packetstormsecurity.org/files/110404/drupal712-xsrf.txt
http://www.exploit-db.com/exploits/18564/
http://1337day.com/exploits/17611
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2007-6752
https://bugzilla.redhat.com/show_bug.cgi?id=807859
http://security-tracker.debian.org/tracker/CVE-2007-6752
http://images.redhatmagazine.com/security/data/cve/CVE-2007-6752.html
http://people.canonical.com/~ubuntu-security/cve/2007/CVE-2007-6752.html
http://en.securitylab.ru/nvd/422373.php
https://cert.inteco.es/vulnDetail/Actualidad/Actualidad_Vulnerabilidades/detalle_vulnerabilidad/CVE-2007-6752

Furthermore MITRE CVE Numbering Authority, considers that:

  • Sections 2.1 and 3.1  – Poor Session Checking (CSRF to change any Drupal settings) – would be a Drupal’s “Security Improvement”.
  • Section 2.3 – Poor Session Checking (POST and GET method) – and section 2.4 – Poor Session Checking (Http Referer) – would be Drupal’s “Potential Security Improvements”.

 

 

WebfolioCMS <= 1.1.4 CSRF (Add Admin/Modify Pages)

Today I’ve discovered a new CSRF vulnerability which affects WebfolioCMS 1.1.4 (and lower) and which allows to modify any parameter. In my Advisory I’ve demonstrated how to add a new administrator account and how to modify a published web page.

Download my Original Advisory

Some other pubblication related to this vulnerability:
http://packetstormsecurity.org/files/110294/WebfolioCMS-1.1.4-Cross-Site-Request-Forgery.html
http://www.exploit-db.com/exploits/18536/
http://osvdb.org/show/osvdb/79658