Why SIM's are cool

One of the things I've wanted to blog on - and one of the things I want this blog to sort of 'be about' - is the technical and operational sides of SIM systems. So instead of coming up with a big idea article on SIM and why it's cool, I'll give you an example from today that made my day.

At work, our security team uses a SIM to do lots of things, and one of the more important ones is incident response and investigation. Today I was watching events from McAfee ePO and stumbled across the following event:

Name: 'JavaScript security violation detected and blocked'
Destination Address: XX.XX.36.92
File Name: 'Script executed by IEXPLORE.EXE'
String1: 'JS/Exploit-BO.gen'
String2: 'trojan'

This is a detect/block message for a generic JavaScript exploit that was detected while the user was in Internet Explorer. There's no good way to tell what was actually going on here. The possibility is that there was exploit code there and that it was blocked. There is also the possibility that there was other exploit code present that was not blocked. So I searched for firewall events using this filter:

((source_address = "XX.XX.36.92") AND
((request_url EndsWith ".js") OR
(request_url EndsWith ".htm") OR
(request_url EndsWith ".html")))

(Note: I did not have to type this all out. It was a short series of mouse clicks in the SIM GUI.)

And it took no time at all to find the firewall log event I was looking for:

Name: accept
Source Address: XX.XX.36.92
Destination Address: XX.XX.121.99
Request Url: http://XX.XX.121.99:80/incs/sfhover.js

So, it took less than 2 minutes to track back to a URL and get a look at the JavaScript code. Fire up a shell and:

$ wget http://XX.XX.121.99:80/incs/sfhover.js
--13:12:40-- http://XX.XX.121.99/incs/sfhover.js
=> `sfhover.js'
Connecting to XX.XX.121.99:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 751 [application/x-javascript]

100%[====================================>] 751 --.--K/s

13:12:40 (4.75 MB/s) - `sfhover.js' saved [751/751]
$ cat sfhover.js
...
for (var i=0; i
elemsArray[e][i].onmouseover=function() {
this.className+=" sfhover";
}
...

It was an onmouseover call that set McAfee off, and in this case, it's benign. Two minutes to run down a possible exploit with code and get back to work. Sorry, but that's just cool.

March GRSec - It's On Like Donkey Kong!

There definitely will be a March GRSec meetup!

Probably downtown Grand Rapids. If you have an opinion on the venue, now's the time to speak up. I'll have to make arrangements and announce our destination by Friday the 16th.

How You Know It's Spring in Michigan

Well, you sure can't tell by the weather. :-)

But you know Spring is here when the first batch of Bell's Oberon arrives in stores. Two weeks from now - Monday, March 26th - it will officially be Spring in Michigan.

Who Names These Things?

Yesterday, the SEC launched Operation Spamalot to combat pump-n-dump stock fraud that utilizes spam to artificially 'pump' some penny stock price. Aside from thinking that the name is atrocious and feeling sorry for Eric Idle, I think this is a good idea. Pump-n-dumps are an old trick, only the spam part is new.

So starting today, if your stock symbol shows up in spam, the SEC will suspend trading of your stock. They've already suspended 35 companies.

Aviram Jenik at Securiteam is concerned that this could be used to perform DoS attacks against bigger stocks. While technically possible, it's unlikely for a number of reasons. First, unlike firewalls receiving shun commands from IDS sensors, there will be people making these decisions. Second, if you look, it's pretty easy to see a pump-and-dump on paper. I collected some examples from stock spam I got this morning for you to look at. I'll bet you can see one way to differentiate them from the big boys right off the bat. The trading history tells the rest of the story.

LVCC.PK
CEOA.PK
NNCP.PK

February Catch Up

Here's some random stuff I've been meaning to post up here as follow-ups to posts from February. I've been pretty busy with work and am late on these. Sorry.

Python code: I've improved on my original, first Python program by adding the ability to create a whitelist file full of regular expressions. This makes it easy to isolate only those hostnames you want to find without knowing what they are. In case you're wondering, being able to do fast PTR record lookups against your DHCP ranges looking for things you don't know about is the poor man's NAC (oh, you thought EAP was the poor man's NAC?). Most Windows machines will announce their FQDN and register with Windows DHCP/DNS making them findable by doing reverse DNS lookups. Use the whitelist to exclude the stuff you know about like 'myinternaldomain.local'. Link here.

Nepenthes and ops: In this post, I mention that Tim Crothers presented on an easy way to work honeypots into network security ops. And then I totally neglected to describe how that works. Just to be clear, this is Tim's idea, not mine. I'm reposting it without permission. Hopefully he's cool with that.

Step 1. Build a VMWare image as similar to your corporate workstation image as possible. Specifically, keep it at the same patch level and run the same anti-virus or other security software with the same signatures.
Step 2. Install Linux on some old computers. Now install and configure Nepenthes on these as well.
Step 3. Deploy the Nepenthes boxes where they can collect malware: on a DSL/cable connection with no firewall, on a darknet, on a workstation network, outside the corporate firewall.
Step 4. Regularly (or automatically) review nepenthes.log and check the binaries directory for captured malware.
Step 5. Carefully transfer malware (via password-protected ZIP, for example) to the VM built in step 1.
Step 6. Disconnect the VM from the corporate network and unleash the malware. See if your AV tools detect it. Use SysAnalyzer to see what it does.
Step 7. If AV doesn't detect it, send a sample to AV vendor asking for emergency update. Deploy emergency update.

The thing I like about this is the simplicity of it. And being proactive on malware definitely won't hurt you. This stuff changes so fast it's difficult for AV vendors to keep up.

Accept Additional Risk: Cancel or Allow?

At my current place of employment, there has been a push to (and a push back against) adopt Mac OS X as a supported platform. Apparently Mac's are no longer just for indie musicians and graphic designers. In addition to graphic designers, we have programmers and UNIX admins and other random hipsters interested in toting around a new MacBook.

I recently discussed this issue in depth with my boss, the CISO. He worked with the desktop guys during the XP roll-out to reduce local admins, implement group policy security measures, turn off services, and basically harden the desktop image to where it is fairly resilient. The concerns about Mac's are that they still lack the spiffy security policy lockdown stuff that XP has and that they are now very much on the list of platforms actively being analyzed for vulnerabilities. The whole x86 CPU (and therefore x86 shellcode) thing doesn't help, either.

Once you separate this issue from the nerd jihad, Mac OS X isn't so bad. In fact, a little bit of additional work, some means of centralized software management and an AV client is enough to bring it into alignment with the XP machines and make it a reasonably low risk venture. The TCO/ROI and in-house support stuff is someone else's problem.

After stopping to think about what it takes to bring a new OS into the security fold, it's not Mac's that worry me. It's Windows Mobile on phones. Single-user OS, barely-there authentication, and when it's in a cradle and the EVDO data link is up, it's a potential back door into your network around your firewall and IDS.

Damn. Cuz I don't care what you say, the Treo 700 is way more nerdtastic than a 17" MacBook.

Channel Certs

Much like this blog, I'm a few weeks behind on this one, but I haven't seen it anywhere else besides Channel Insider, so I'm going to bring it up. I'm glad to see Symantec kill their VAR certification requirements, but disappointed at the same time.

In case you don't know, VAR's and other channel resellers are typically required to have some number of people complete some number of certification exams for their products in order to gain various levels of partner status. What you may also not know - but probably want to know if you are a VAR customer - is that these are not the same exams that you or your employees can train for and take. They're much easier. And they're not proctored - typically delivered via web site, it's easy to cheat or have someone else take the exam for them.

I used to work for a VAR and I acquired an even dozen of these things. Bigger vendors like Microsoft and Cisco make partners get the real sit-down certs because they can, and that's a good thing. Of course, Symantec is a BIG vendor, but outside of Win32 AV, their market share in any single infosec product space is smallish. I understand their decision to pull their channel cert program because they need all of the channel help they can get for their SGS appliances (formerly [C]Raptor) and the like. But I wish they, and other companies that have VAR channels, would hold their partners to stricter standards. It hurts everyone, but mostly VAR customers, when a vendor lauds a VAR as a 'Name Brand integration specialist' and in reality the VAR sends someone out to install your new, brightly-colored 2U appliance who has read the product PDF's and has a direct line to Tier-3 support, but has never actually installed one before.

Some customer must be that engineer's first install. How do you know it's not you?