Immutable Security

OSSEC is one of those tools that continues to surprise me with its ability to perform low-level and important security tasks. In fine Unix tradition, individual parts of OSSEC can often be persuaded to do your bidding in ways not previously conceived. Put another way, it’s nice to hack. :)

Today, I’m going to show you how to use OSSEC to detect sensitive info within flat files. This example will demonstrate American social security numbers, but the same logic could be used to detect clear-text credit card numbers (a violation of the PCI DSS standard), or other personally identifiable information which should not be in clear-text.

We’re going to rely on the rootcheck functionality of OSSEC. Rootcheck does all kinds of nifty things, one of which is to scan within files for patterns. Normally, you would expect to look for things like insecure system configuration settings. We’re going to use it to find possible social security numbers.

First, create a test file containing a properly formatted SSN in a location that OSSEC is monitoring:

echo 123-45-6789 > /var/www/html/example.com/www/customer_data

Next, add the following to /var/ossec/etc/shared/system_audit_rcl.txt:

# Detect possible SSNs
[Possible Unencrypted Social Security Number Detected] [any] []
d:$web_dirs -> r:^\. -> r:\d\d\d-\d\d-\d\d\d\d;

Now, let’s create an alert so we get a heads up on what OSSEC finds (change the rule ID as needed):

<rule id=”100024″ level=”12″>
<if_sid>516</if_sid>
<match>Unencrypted Social Security Number</match>
<description>Possible Unencrypted Social Security Number Detected</description>
</rule>

Restart OSSEC:

/var/ossec/bin/ossec-control restart

Finally, we’ll initiate a scan on the local system:

/var/ossec/bin/agent_control -r -u 000

And here is what the resulting alert looks like:

OSSEC HIDS Notification.

2010 Jan 12 18:25:43
Received From: hostname->rootcheck
Rule: 100024 fired (level 12) -> “Possible Unencrypted Social Security Number Detected”
Portion of the log(s):

System Audit: Possible Unencrypted Social Security Number Detected. File: /var/www/html/example.com/www/customer_data.

–END OF NOTIFICATION

One of the nice things about the alert above is that it doesn’t actually include the contents of the file, so you don’t have to worry about clear-text data traversing your mail server.

There are also a few caveats to keep in mind.

First, it is slightly prone to false-positives. Since the OSSEC regex library is designed for speed, rather than full regex support, it’s not possible to use something like \b to define a word boundary. This means that while the regex will match SSNs like 123-45-6789, it would also match something like 00123-45-678911. It also wouldn’t match a delimiter other than the dash. You might be able to mitigate some of these risks if you’re sure how the data would be formatted (but then again, if you’re sure you have clear-text data on the server why do you need this :) ?)

Second, it won’t find data in databases, which is probably where it is likely to be stored. It’s really only useful against flat-files.

Finally, there’s currently no facility to save this change when upgrading, such as you can already do with local_rules.xml. Make sure you have a backup of system_audit_rcl.txt handy that you can restore.

Despite these shortcomings, if you are already using OSSEC then this can be an excellent way to quickly add some rudimentary data checking to the OSSEC scans. It shouldn’t be relied on exclusively and the absense of an alert doesn’t necessarily mean you’re safe, but for a 5-minute change and in the absence of a budget for a more robust tool, this might lead to quite a surprise!

Thanks to Daniel Cid for help in getting this working, and of course for the excellent tool that OSSEC is.

I have observed a trend recently that has me internally debating the ethics of the practice. Security professionals are probing public web sites for vulnerabilities, then going through a “responsible” disclosure process with the owners of the site. Then they blog about their exploits and how responsive the owner was to being notified.

How is this different than traditional hacking by the bad guys? Does the disclosure process make it any better? Does the fact they do security for a living and write for security journals make it more ethical? And what of the applications that are vulnerable to routine exploits? What does one do with a successful SQL injection query that just gave you a table full of social security numbers?

On the surface, it seems unethical to me. Attempting to break access controls, even if they are weak, is unethical and maybe illegal. Doing something untoward against another computing resource for which you do not have authorization is treading on thin ice.

But there’s another side to the story here. Applications are moving more towards the software-as-a-service, or SaaS model. Whereas once you would have been able to download the software and legally and ethically reverse-engineer it, now the application is only hosted on another computer. This changes things in a big way, since you’re working on someone elses computer now.

The argument could be made that since the application is public, then there is an expectation that it wil be poked and prodded, so it might as well be the good guys who do it. The bad guys aren’t going to go through a responsible disclosure process, so by the good guys testing the application and making the flaws known to the application owner, everyone benefits (as long as they actually fix it). It can also be said that for security to continually improve, we have to continually test it. If the world is moving towards a web-centric model, we have to move with it.

Honestly, I can see both sides; yet, I am still left with the feeling that, in many cases, it’s nothing more than the security guy trying to have some fun and make a name for himself. If that’s the case, he should carefully consider what that name may be.

In the June 2009 issue of the ISSA Journal, I wrote about my experiences setting up utilities and other essential services after a cross-country move. I detailed how I was able to not disclose my social security number after only some gentle persuasion. I had another success today. A visit to my new otolaryngologist (ear, nose and throat doctor) was  successful in not disclosing my SSN. Now, both of us are protected from the liability of having to handle this information. Although they still have serious responsibilities to protect my PHI, at least that’s one less thing both of us have to worry about. It makes one wonder why the information is requested in the first place. Like many business processes, I suspect it’s simply something that works and therefore, they haven’t had a strong incentive to change.

You can help to change these types of practices. The next time someone asks for your SSN or other sensitive information, cheerfully discuss what other options may be available to you. You may be surprised to learn that it’s not really necessary, but a simply a formality from days past.