[SecurityRatty] tag: solaris

Dumb Luck IS a Strategy!

Thu, 18 Sep 2008 05:38:00 +0000

While still at GOVCERT.NL, I've attended a fun little presentation, describing a penetration test (I cannot provide any more details as it was a "No Press" presentation - this post is not about it, but rather was inspired by it!)

In any case, if you do pentests, think about all the RECENT cases where you break in to a major corporation through:

a Solaris system with Internet-exposed telnet with a guessable password OR a telnet vulnerability (circa 1994!)
an exposed VPN appliance with a manufacturer's administrator password
a router with default "enable" password
or, something else entirely - but something that rivals the above example in its unparalleled, unbelievable, abysmal, deep idiocy.

Indeed, many of my pentesting friends still report plenty of such cases (one was also featured in the presentation mentioned above). Whenever I hear about it from a pentester, I always ask:

Do you think "somebody bad" had already passed through the hole you just discovered?

Maybe an hour ago, a day ago - or a year ago?!

I cannot see how the answer can be "no."

Even though pentesters usually don't focus on forensics (no time for this), it is not uncommon to notice "your predecessor's" intrusion traces while you break through systems, "plant flags", change screen backgrounds [for the admins to notice that you've been there...], etc.

Let's think what this situation really means? Here are the choices I see:

Nobody discovered the hole - a law of large numbers (aka "dumb luck") have "shielded" the company from an incident. Yes, Virginia, dumb luck IS a security strategy for some companies... AND it works for them.
It was discovered, but not used/abused by the attacker - maybe he was busy hacking other systems, or saved this for later and never came back due to his ADD. Congratulation, you win! The immense power of dumb luck wrapped you in a protective "security" blanket ... again :-)
It was discovered; the attacker went in, looked around and compromised a few others systems, but found nothing of interest (no low hanging fruits) - and he was not a bot herder. Again, you win. Next time you are in Vegas, bet on "00."
It was discovered; the attacker went in and deployed a bot on "your" system - given how many botnets are there, this situation is clearly acceptable to many organizations. In this case, dumb luck strategy, apparently, still work: so they use your box to spam and phish somebody else ... big deal!
It was discovered; the attacker went in and stole all your credit card information (it is now for sale) - even in this case, the user of "the dumb luck strategy" still "wins" (in some perverse sense)! Unless and until the stolen information IS tracked back to you OR a friendly neighborhood PCI auditor come and jams a broomstick up your ..., you can still continue to be stupid at your leisure and ignore basic security practices.
It was discovered; the attacker went in and stole your CEO's Inbox, including the email related to his affair (it is now on CNN) - now, in this case, you lose AND it is time to stop being stupid! Welcome to the "0wned world." Time to launch (relaunch?) your security program and get serious.

What does this teach us about RISK? The lesson here is important:

For a security professional, an Internet-exposed system with "root/root" is an obvious HUGE risk!
For your boss's boss's boss, it is NOT!

This is exactly why I think that the most critical problem in security today is METRICS. Metrics that a) work AND mean something to decision makers and b) can be clearly communicated to said decision makers [BTW, a) and b) are two separate problems.] Metrics that cover not only threats and vulnerabilities we face, but also the effectiveness of security countermeasures we deploy. Metrics you can act on - and ones your boss (and his boss) will act on. Metrics that lead to correct decisions about which risks to accept, which to mitigate (all while knowing with what efficiency such mitigation occurs) and which to transfer.

Until that time, the dreaded "C-word" (compliance) will trump "the other C-word" (common sense) as a driver for security ... and we will continue to live in the "0wned world."

Possibly related posts:

Risk vs Risk

Adapting to Shelf Life

Thu, 04 Sep 2008 06:22:34 +0000

Dan Pritchett blogged about Architectural Shelf Life - "The duration that a collection of patterns and technology are applicable when starting a new system design." He argues that this changes about every 5 years which is pretty fast when you think about it. Our story on the security is measured in decades not years. Kerberos, certificates, RSA, and other workhorse technologies are relatively unchanged since the 70s and 80s. So we security folk are multiple iterations behind developers.

Out of this comes the need for two things - one we need to innovate at a much higher rate, but equally important, we need better deployment models. The primitives we have that actually work need to be engineered better to form fit to the rapidly changing software side. Its not good enough to say "we have it all figured out", we have to apply the stuff that works to real software architectures. Why is the a dab of firewalls and SSL still our answer after all these years?

Two case studies of where security technologies were adapted to technical realities to provide effective security mechanisms in the real world are SAML, which learned a lot from Kerberos and then applied it to the Web and XML; WS-Trust/STS, which owes a lot to SDSI/SPKI and applied it to Web services/XML plumbing.

Software security is starting to grow as an industry. But a lot of the answers I hear and see in the field are predicated on "we want to reengineer the entire SDLC", etc. sometimes what is really needed is evolution not revolution, and an easy to use adapter that ships in a few weeks...I remember Brian Snow's talk at black hat several years ago when he talked about how the NSA putting certificate checks in all calls to the Solaris kernel. Its not all about new primitives, its also about finding the art of the possible of what we can do with what we already have. Chief among these is adapting to technical realities.

More Log Management Questions - Answered!

Fri, 23 May 2008 12:04:00 +0000

I did this VERY fun webcast with WhiteHatWorld this week and a lot of good questions about log management came up. I am answering them here for my readers. BTW, LogLogic product-specific questions can be found on LogLogic website; I am not answering them here.

Q1: Is a preferred log management program to consolidate the log data and then allow us to review them?

A1: The answer is "Yes!" for a vast majority of use cases consolidating logs work better than the silo'ed approach. Also, this will be answered in longer dedicated post within a few days (link TBA).

Q2: Is it feasible to use a log management tool to try to determine whether application events / failures are being caused by infrastructure issues?

A2:Wow, fantastic! The answer to this is "Yes, if you have the right logs collected." In most cases, to get to the bottom of such issues requires having BOTH application (e.g. PeopleSoft or Oracle) and infrastructure logs (e.g. Windows or Solaris).

Q3: What the typical retention schedule for logs which might be required logs for compliance issues?

A3: I wish I can give a simple answer for this, but there is none. Well, PCI DSS makes it simple: 1 year for logs from in-scope systems. Other regulations are not as clear and the numbers, or - more often! - guesses at such number range from 90 days to 7 years and more. 90 days to 1 year is a common retention policy for security (on the longer side of this range) and operationally (on the shorted side of this time range) useful logs. Check this out for a few ideas for long long you might need the logs.

Q4: Once you have logged the events, what do you do with them?

A4: Well, I was about to laugh it off since it truly opens up a Universe of questions, issues, challenges, etc. But here is my attempt at a short answer (like, less than a book :-)): a) you collect the logs and now you can search thru them in case you need to b) you summarize them and notice the trends - overall know what is going in your environment c) you analyze them in real time to trigger alerts on "critical" log messages - failures, attacks, etc. See this slide deck for some useful pointers.

Q5: Why do I create a log policy?

A5: Log policy is a clear and simple document that show what you log on each system (and why): it helps you to configure logging across all the systems as well as helps to know what information you have in your environment (should an auditor ask, for example). A log policy also defines log retention, log review practices, etc. NIST 800-92 Guide to Security Log Management [PDF] is a good source of info on this subject.

Enjoy!

Technorati tags: log management, logging

Quest homes in on Unix password management

Sun, 27 Apr 2008 20:00:00 +0000

Overall, QPM requires moderate Unix administrative skills to both install and use. It doesn't, of course, cover Windows, but does cover Solaris and HP-UX (not tested). It's very highly configurable, and puts reasonably strong barriers in place to prevent undesired privileged access.

Fun Log-reading

Mon, 21 Apr 2008 17:24:00 +0000

Now, some of you are on the verge of saying "Anton! Stop reading (and posting links) - start writing already..."

I will, I will :-)

But for now, here is some fun log-related stuff, in one enjoyable pile:

Logs and security (clouded) by BeastOrBudda. Good content on tracking activities thru various logs and HOT video link (here)
Is It Better To Leave Some Logs Behind? (full text) Good discussion on whether "collect everything" (every log) is the right strategy in all cases. Sadly, but yes, some logs are so poorly done (Solaris BSM anyone? :-) [some of the logs there are worth dumping...]) that they are truly useless for most conceivable purposes and can be thrown away with no loss of useful information whatsoever.
"Description of security events in Windows Vista and in Windows Server 2008" - read it if you are into sort of thing :-)

Enjoy!

Failure to patch flaw exposes data on 60,000 at Antioch

Fri, 04 Apr 2008 09:00:00 +0000

Antioch University's failure to patch a Solaris flaw exposed data on more than 60,000 individuals.

Limiting Process Privileges Should Be Easier

Fri, 09 Nov 2007 07:00:00 +0000

I was reading DJB's retrospective on 10 years of qmail security and while I'll comment on a few of his thoughts in a separate post, one thing that struck me was his discussion of how to create a relatively effective process sandbox for a process:

Prohibit new files, new sockets, etc., by setting the current and maximum RLIMIT_NOFILE limits to 0.
Prohibit filesystem access: chdir and chroot to an empty directory.
Choose a uid dedicated to this process ID. This can be as simple as adding the process ID to a base uid, as long as other system-administration tools stay away from the same uid range.
Ensure that nothing is running under the uid: fork a child to run setuid(targetuid), kill(-1,SIGKILL), and _exit(0), and then check that the child exited normally.
Prohibit kill(), ptrace(), etc., by setting gid and uid to the target uid.
Prohibit fork(), by setting the current and maximum RLIMIT_NPROC limits to 0.
Set the desired limits on memory allocation and other resource allocation.
Run the rest of the program.

If doing all of the above steps seems like a bit much, then perhaps what you're sensing is that the architectural model that makes it hard for a process to drop privs, restrict what it can do, etc. is simply wrong in most operating systems.

What strikes me about the above example is that it ought to be a lot easier for a developer/administrator to define the policy for a given process and its run environment, without having to know this much arcana about exactly how to do it.

Luckily, there are a few OS-supplied solutions to the problem that while not perfect and still tricky to implement, are at least a step in the right direction.

Solaris

Sun has a couple of nice blueprints on how to limit the privileges for a process/service. I think it still isn't quite to the default-deny and allow only what you want stage, but interesting nonetheless.

Windows Server 2008

Microsoft has introduced service hardening and reduced privileges in Server-2008.

Security Configuration Wizard

Based on what I can tell their new wizard and SCM in general are structured more around least privilege than some of the other operating systems. At least from an ease-of-use standpoint.

Linux

On Linux we have several options.

SELinux
AppArmor

I haven't looked extensively at either of them yet but I'll try to look into whether their policy model is better/worse than the options above.

MacOS

Leopard introduces a new process sandboxing mechanism. Unfortunately the details are a bit sketchy. The Matasano guys have a writeup of it, but I haven't seen any details on the exact mechanisms and/or configuration.