Mr. Szymanski

By Craig Szymanski

While doing forensics this week to determine where the MacDefender malware was coming from I noticed one thing that was distinct to all the requests for this malicious package. When it was downloaded the mime type for the file request was “application/download” when searching through the logs I noticed that this was a mime type that I would want to know about anyways and that generally there are not a lot of requests associated with this mime type. So I would not be overwhelmed with notifications.

So how do I monitor this? I’ve been using the OSSEC IDS system (https://www.ossec.net/) for a few years now. It is an excellent tool and completely customizable. To get OSSEC to monitor my squid log first I added the /var/log/squid/access.log to the list of monitored files in the /var/ossec/etc/ossec.conf file and restarted the service.

  <localfile>
    <log_format>squid</log_format>
    <location>/var/log/squid/access.log</location>
  </localfile>

Now, the problem I found with adding this is if you have a pretty busy network with a lot of different clients (Macs, Linux, PCs) then you are going to get some odd traffic that will trigger alerts based on multiple errors found in the squid access log. To monitor this it would be a good idea to shut off active response for a while and then gather some exceptions that you can put into the local_rules.xml file on the OSSEC server. Below is the rule I used to detect application/download.

<group name="squid-custom,">
  <rule id="100400" level="6">
   <if_sid>35000</if_sid>
   <match>application/download</match>
   <description>Application downloaded via squid proxy. Check URL to determine malware.</description>
 </rule>
</group>

I have I have email notifications set for level 6 and up and active response to 7 or greater. This way internal hosts will not lose there internet connection abilities when downloading a legitimate program. Below are some of the exceptions that I had to add to the local_rules.xml to make sure that certain requests did not add internal hosts to the hosts.deny file.

  <rule id="35057" level="0">
   <if_sid>35057</if_sid>
   <match>secars.dll</match>
   <description>False Positive. Symantec Endpoint client going through proxy.</description>
 </rule>
  <rule id="35009" level="0">
   <if_sid>35009</if_sid>
   <match>secars.dll</match>
   <description>False Positive. Symantec Endpoint client going through proxy.</description>
</rule>
  <rule id="35008" level="0">
   <if_sid>35008</if_sid>
   <match>secars.dll</match>
   <description>False Positive. Symantec Endpoint client going through proxy.</description>
</rule>

There will probably be a few more things to add. Just monitor your alerts carefully and you will have it smoothed out in short order.

As I was about to leave work today I received an alert from OSSEC that looked like what you see below. I’ve edited out the internal information and the bad URL’s host.

OSSEC HIDS Notification.
2011 May 27 14:49:17

Received From: (MyProxy) IPaddress ->/var/log/squid/access.log
Rule: 100400 fired (level 8 ) -> "Application downloaded via squid proxy. Check URL to determine malware."
Portion of the log(s):

1306522093.290    620 <InternalHost> TCP_MISS/200 47939 GET http://VeryBadHost.com/files/a6930dd67bda35bd60e694db3a40ec58d3875a870e2210c7.zip DIRECT/<BadIPAddress> application/download

 --END OF NOTIFICATION

I blocked the IP on my network, checked the host that downloaded the package and then submitted the bad ip address to the Google Safe Browsing Report here:

Category: Computer Security, Macintosh, Phishing, fake-antivirus, ids, MacDefender, MACProtector, MACSecurity, ossec, squid