{"id":1692,"date":"2013-07-23T15:04:42","date_gmt":"2013-07-23T12:04:42","guid":{"rendered":"http:\/\/www.void.gr\/kargig\/blog\/?p=1692"},"modified":"2013-07-23T15:04:42","modified_gmt":"2013-07-23T12:04:42","slug":"another-day-another-hacked-website","status":"publish","type":"post","link":"https:\/\/www.void.gr\/kargig\/blog\/2013\/07\/23\/another-day-another-hacked-website\/","title":{"rendered":"Another day another hacked website"},"content":{"rendered":"

Yesterday morning, phone rings to notify my of a new sms. Someone could not access his website on some server that I am root\/administer.
\nI tried to ping the server and got 1 reply every 10-15 packets so my initial thought was that the hosting provider had fucked up. I pinged other machines in the “neighborhood”, they replied just fine. So the problem lied in my server. I got console access through IPMI, you know…the ones with the cipher zero bug<\/a>, and I managed to login. An apache2 process was constantly using 100% of a core and the machine sent gazillion packets towards a certain destination.<\/p>\n

Since I wanted to investigate what exactly this process did, I put an iptables entry in my OUTPUT chain to block packets towards that destination. The machine became responsive again, though the apache process still ran at 100%. Since I run my vhosts using apache2 mpm_itk module<\/a>, I knew through the apache2 PIDs’ username which site had been hacked. I grepped the logs for any POST, but I couldn’t see anything. Unfortunately the logs only go back 2 days (NOT<\/strong> my policy! and a very bad one actually…but anyway). <\/p>\n

strace -p PID<\/em><\/strong> did not yield anything interesting, just the process trying to create sockets to send packets towards the destination.
\n

socket(PF_NETLINK, SOCK_RAW, 0) = 417\nbind(417, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0\ngetsockname(417, {sa_family=AF_NETLINK, pid=11398, groups=00000000}, [12]) = 0\nsendto(417, "\\24\\0\\0\\0\\26\\0\\1\\3\\233\\323\\354Q\\0\\0\\0\\0\\0\\0\\0\\0", 20, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20\nrecvmsg(417, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"0\\0\\0\\0\\24\\0\\2\\0\\233\\323\\354Q\\206,\\0\\0\\2\\10\\200\\376\\1\\0\\0\\0\\10\\0\\1\\0\\177\\0\\0\\1"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 588\nrecvmsg(417, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"@\\0\\0\\0\\24\\0\\2\\0\\233\\323\\354Q\\206,\\0\\0\\n\\200\\200\\376\\1\\0\\0\\0\\24\\0\\1\\0\\0\\0\\0\\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 128\nrecvmsg(417, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\\24\\0\\0\\0\\3\\0\\2\\0\\233\\323\\354Q\\206,\\0\\0\\0\\0\\0\\0\\1\\0\\0\\0\\24\\0\\1\\0\\0\\0\\0\\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 20\nclose(417) = 0\nsocket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 417\nfcntl(417, F_GETFL) = 0x2 (flags O_RDWR)\nfcntl(417, F_SETFL, O_RDWR|O_NONBLOCK) = 0\nconnect(417, {sa_family=AF_INET, sin_port=htons(4883), sin_addr=inet_addr("X.Y.Z.W")}, 16) = 0\nfcntl(417, F_SETFL, O_RDWR) = 0\nsendto(417, "\\207\\25\\312P\\322t\\0#\\317}jf\\2(W\\374\\375\\232h\\213\\220\\31\\355\\277)\\320[\\255\\273\\276\\221\\374"..., 8192, MSG_DONTWAIT, NULL, 0) = -1 EPERM (Operation not permitted)\nclose(417) = 0<\/code2><\/pre><\/p>\n
lsof -n -p PID<\/em><\/strong> output had hundreds of open log files and a few connections. Grepping out the logs I noticed one that was quite interesting, it went towards another server at port 5555.
\napache2 11398 XXXXXXX 416u IPv4 831501972 0t0 TCP A.B.C.D:59210->B.C.D.E:5555 (CLOSE_WAIT)<\/code><\/p>\n
I run tcpdump there, and of course it was an irc connection. I started capturing everything.<\/p>\n
lsof also revealed this:
\napache2 11398 XXXXXXX  cwd    DIR                8,7      4096    2474373 \/var\/www\/vhosts\/XXXXXXX\/httpdocs\/libraries\/phpgacl<\/code>
\nwhich I could have have also seen it doing ls \/proc\/PID\/cwd\/<\/em><\/strong> …but anyway.<\/p>\n
Looking inside that dir I found a file named gacl_db.php. It was base64 encoded. Well actually it was multiple times base64 encoded and obfsuscated by using character substitutions, so I had to de-obfuscate it. It was quite easy using php and some bash scripting.<\/p>\n
This is the original base64 encoded\/obfuscated file: Original gacl_db.php<\/a>
\nThis is the final result:  Deobfuscated gacl_db.php<\/a>
\n(I have removed the irc server details from the deobfuscated file, it’s still there in the original file for whoever wants it though)<\/p>\n
It’s just an IRC bot containing a perl reverse shell as well. It has commands to flood other servers, and that’s what my server was doing.<\/p>\n
I joined the IRC server and at that time there were more than 90 bots inside. Right now that I’m writing this blog post there are less than 50. Every bot joining the channel outputs a text like this:<\/p>\n
 [uname!]: FreeBSD a.b.c.d 8.1-RELEASE-p5 FreeBSD 8.1-RELEASE-p5 #10: Fri Sep 30 14:45:56 MSK 2011     root@a.b.c.d:\/path\/to\/to\/to\/sth pl#27 amd64 (safe: off)
\n<\/botname> [vuln!]: http:\/\/www.a-vhost-name.TLD\/libraries\/phpgacl\/gacl_db.php
\n [uname!]: Linux x.y.z.w 3.2.0-43-generic #68-Ubuntu SMP Wed May 15 03:33:33 UTC 2013 x86_64 (safe: off)
\n<\/botname2> [vuln!]: http:\/\/www.another-vhost-name.another-TLD\/libraries\/phpgacl\/gacl_db.php<\/botname2><\/botname><\/p><\/blockquote>\n
So if you run servers or websites, do a locate gacl_db.php<\/em><\/strong>. <\/p>\n
Since all the bot\/servers entering post a [vuln!] message about phpgacl, my guess is that the original vulnerability that allowed the attacker to gain access is right there. I haven’t had time to look into it yet, but I’ve warned my clients to remove this library from their websites as a precaution. You should probably do the same.<\/p>\n","protected":false},"excerpt":{"rendered":"
Yesterday morning, phone rings to notify my of a new sms. Someone could not access his website on some server that I am root\/administer. I tried to ping the server and got 1 reply every 10-15 packets so my initial thought was that the hosting provider had fucked up. I pinged other machines in the […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ep_exclude_from_search":false,"footnotes":""},"categories":[5,3,8],"tags":[326,182,554,33,553,231,552,595,277],"class_list":["post-1692","post","type-post","status-publish","format-standard","hentry","category-internet","category-linux","category-networking","tag-apache","tag-apache2","tag-ddos","tag-debian","tag-flood","tag-hack","tag-hacked","tag-linux","tag-php"],"aioseo_notices":[],"views":19481,"_links":{"self":[{"href":"https:\/\/www.void.gr\/kargig\/blog\/wp-json\/wp\/v2\/posts\/1692","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.void.gr\/kargig\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.void.gr\/kargig\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.void.gr\/kargig\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.void.gr\/kargig\/blog\/wp-json\/wp\/v2\/comments?post=1692"}],"version-history":[{"count":14,"href":"https:\/\/www.void.gr\/kargig\/blog\/wp-json\/wp\/v2\/posts\/1692\/revisions"}],"predecessor-version":[{"id":1711,"href":"https:\/\/www.void.gr\/kargig\/blog\/wp-json\/wp\/v2\/posts\/1692\/revisions\/1711"}],"wp:attachment":[{"href":"https:\/\/www.void.gr\/kargig\/blog\/wp-json\/wp\/v2\/media?parent=1692"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.void.gr\/kargig\/blog\/wp-json\/wp\/v2\/categories?post=1692"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.void.gr\/kargig\/blog\/wp-json\/wp\/v2\/tags?post=1692"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}