Security
Arbitrary PHP code execution in modx 1.0.0 via CSRF
Heine —Tue, 2009/09/08 - 23:32
When someone mentioned that modx was the new Drupal, I got curious and decided to see for myself.
The cursory exploration got a little more involved when I noticed that, by default, modx doesn't enable any protection against Cross site request forgeries (CSRF). I discovered this by using CSRF to get the administrator password changed. Turns out this is already known since 2008.
After some more digging, I found ticket MODX-206 (registration required), where an HTTP_REFERER check was added as a form of protecting against CSRF.
This option is disabled by default; you need to visit Tools - Configuration :: Site tab to enable the setting Validate HTTP_REFERER headers?. (Note: This can prove to be painful when you run ZoneAlarm, or something else that strips referrers from headers). The setting appears to be documented on a forum post only.
Unfortunately, the HTTP_REFERER check only checks whether the modx site url is part of the referrer. That means that the referrer http://evil.example.com/payload.html?s=http://vulnerable-modx.example.com/ passes the check.
I've spoken with a number of modx developers and they told me a number of 'forms' react to GET requests as well. That means that even when the referrer check is fixed, a modx 1.0.0 site is still vulnerable to CSRF when users are allowed to post URLs on your site as they could post a URL to your own site. If you happen to follow one such URL while being logged in as manager, the referrer checker receives a correct HTTP_REFERER and takes the unintended action.
Until a list of GET-able actions is compiled, it is hard to estimate the impact of this issue.
Beware that malicious users can make it less obvious that you target your own site by using tinyURL or a custom (less obvious) 301 redirector.
A full solution (works with GET, works for people without HTTP_REFERER) would be to add a token to every form and GET request (taking an action), then check those on the actual GET and POST requests.
Due to the way modx 1.0.0 ("Evolution") is build, that is a monumental task and not something the developers are interested in or have time for. They are working hard on the next installment of modx ; Revolution.
Considering the situation with Evolution, I can only advise you to wait until Revolution is released before starting with modx on internet-facing servers.
If you are already using modx 1.0.0, you are in a tight spot. I urge you to deploy and enable the referrer check fix asap after it is released. Do not allow users to post URLs or images on your site (depends on your site configuration) and upgrade to Revolution when it comes out.
If you want, you can try the attached patch for modx 1.0.0.
IMO, and I'm sure in the opinion of the modx developers too, the Evolution code base cannot die quickly enough.
Security theater #1 - Using SSL for login
Heine —Fri, 2008/08/22 - 17:56
Update September 24, 2008 - Added a link to CVE-2008-3661 and "Fun Snags with Drupal Cookies"
Security theater consists of security countermeasures intended to provide the feeling of improved security while doing little or nothing to actually improve security.
A quite popular activity among Drupal site owners and extension developers (drupal, firefox) is to make sure certain page requests happen over a secure HTTPS connection, whereas the majority of requests is still done over an unencrypted HTTP connection. User logins are typically the target of this effort.
Now, unless your really value your password (because you happen to be Ben Bernanke and use the same password for the documents holding the future interest rate), this is only going to give you a false sense of security. I know, it is still a very warm and comfy feeling, but it won't be so comforting when some clown sees Mike Perry's presentation and takes away your site.
# 8 on the Vendors with Most Vulnerability Disclosures list
Heine —Tue, 2008/07/29 - 17:45
Every year Drupal tends to end up in a few Top 10s, making us happy and proud. The latest Top 10 we appear in is not something to gloat over however: The Top 10 vendors with the Most Vulnerability Disclosures (source: X-Force 2008 Mid-Year Trend Statistics). We are number 8, just after Cisco (7) and just before Wordpress (9) with being responsible for 1.2% of all tracked disclosures.
Access denied - Are you sure?
Heine —Fri, 2008/03/21 - 05:23
It is surely not my intend to discuss each and every security announcement, but the recent Live announcement (SA-2008-021) deserves to get some attention as this particular drupal_access_denied &
Update UID 1 password via JS
Heine —Mon, 2008/01/14 - 09:08
A simple proof of concept (without <script> tags) to reset to the Administrators' password via a cross site scripting attack (XSS). Did you think XSS was harmless?
Input formats - the quickest way to make your site insecure
Heine —Sun, 2007/12/30 - 23:15
In a desperate attempt to balance my karma at the end of the year, a small public service post about the most popular way to make your site insecure. This is aimed at website administrators and developers. There will be no code (promise).
Security: A $_POST from the past
Heine —Mon, 2007/12/03 - 10:16
A code construct that surprisingly survived for a long time since the initial 4.7 release is still haunting us. I'm talking about the use of confirmation forms, limping behind the times, ever since the rise of the glorious Form API (ahem). Let's see to it that this coelocanthian code becomes extinct in the next few months.
Though it's not so much the confirmation forms, as it is the way confirm_form is used:
Drupal 5.2 and 4.7.7 released
Heine —Thu, 2007/07/26 - 23:18
It was a difficult delivery, but Drupal 5.2 and 4.7.7 have finally been released. As you can read in the release announcement, several vulnerablities were fixed.
There are two advisories:
IN (%s); a security vulnerability waiting to happen
Heine —Tue, 2007/06/19 - 00:14
I've written before about (ab)using %s in IN clauses such as:
