Xavier's Security Post
Interaction with *nix-based botnet channel
in my last post I quickly briefed on the idea of a possible mambo-based worm -- and these days, thats a very trivial task; since there are several templates of worms written with the task of exploiting several holes.
the other night I discovered an automated worm in the process of attacking my personal server. I grabbed the binary used in an attempted code inclusion, and discovered it was a basic kaiten.c
binary. it had a default password of "bleh" from the original code, its servers pointed to undernet, and the channel "#uid0".
so, I joined the channel and noticed that there were several high profile machines up there, including ***.*** (which I've tried to contact but to no avail). the worms were going at full blast, for many machines a minute were logging into the channel. all kaiten. now usually when I find a kaiten channel, I tend to be evil and make the bots quit with a simple command. it's actually very trivial to do:
but the channel was in +m (moderated) mode.
I noticed a user on the channel, who had operator status, was running commands on a bot. I whois'd the bot and discovered it was an ***.*** machine. I contacted the user and asked him if he knew that trespassing onto the machine (in much simpler terminology) was illegal. I doubt he cared.
upon further questioning, he revealed the worm they used was running on C++, attacked xmlrpc, ekinboard, phpbb, and a few other web-based vulnerabilities (including mamboserver). he wouldn't show me the source, but I really didn't care anyway.
just another day in the neighborhood..
my prediction (concerning Mambo/PHP flaw)
as some of you may know, recently there has been a surge of high profile defacements, specifically on servers running Mambo atop versions of PHP that allow for $GLOBALS arrays to be overwritten. I haven't noticed a big surge of media-whoring yet, but during my research on clients its apparent that there are a big percentage of machines affected.
the flaw in PHP basically allows for attackers to overwrite the $GLOBALS array, and with some special crafting an attacker is very much capable of inserting arbitrary data, in the case of Mambo; remote execution in the form of remote inclusion. Stefan Esser of Hardened-PHP
disclosed the vulnerability on October 31st. check out the advisory here
the flaw in Mambo is simply a remote inclusion attack (or local if safemode is on), and is all thanks to it's globals.php globals emulation. the variable that is left vulnerable after the $GLOBALS overwrite is "mosConfig_absolute_path", thanks to the following code:
require_once( $GLOBALS['mosConfig_absolute_path'] . '/includes/HTML_toolbar.php' );
the vulnerablity in Mambo was disclosed by "peter MC tachatte" aka firstname.lastname@example.org, which btw is a cool dude, as far as our one-email communication goes. the disclosure happened on November 16th.
since then, there has been some major defacement and penetrations going on in several high profile networks -- it was surely bound to happen.
to cut the bullshit, I predict some worms have been written already, or are in the process of being written, and they will attack this vulnerability fiercely. let me just add, that thus far I've seen a high rate of vulnerable servers out there, thanks to this combination of flaws. so pull out your popcorn and tin foil (not aluminum) hats, and enjoy the show.
for the last few days I've been data mangling vulnerabilities for the Open Source Vulnerability Database
. and I must say, although now I have the hang of it -- at first it was a bit stressing -- simply because you don't want to be the person to really mess up on an advisory post.
on one of the first vulnerabilities I mangled. the discloser sent an email to Full Disclosure with a theoretical vulnerability -- as if he knew the flaw in question could be exploited, but he didn't make mention of specific details.
when I received the vulnerability in my queue, I could tell there were a few problems just by reading the original 'advisory'. so, I researched the bug on my own and found four seperate variables that allowed for XSS injection.
I also found more XSS bugs in other parts of the application, which I didn't add because it had nothing to do with his advisory.
the point is, it's not as easy as it looks. and the people involved in the project are actually pretty cool, and put a lot of time into it. much props to Jericho and the rest of the moderators/data manglers.
so, which was the first vulnerability that popped my cherry? well, here it is: HP-UX envd Unspecified Local Privilege Escalation
I have some advisories coming up this week, so be on the look out!
F-Secure Internet Gatekeeper for Linux local root
I discovered a hole in the F-Secure's Internet Gatekeeper for Linux software package. It takes some special conditions to allow for the attack to be successful. They go as follows:
1) you need local user access to the machine with FSIGK
2) you need executable permissions to the SUID binaries in question
3) you need to have access to a writable directory, in order to create an arbitrary file.
And those are usually trivial conditions to achieve. Here's a link to the Advisory
. The exploit is within the advisory, in GnuPG format. Do check on the Tigerteam.se
website for the password.