Tuesday, July 03, 2007
More On 'Do Real "Hackers" Get Logged?'
While I like to state that every activity leaves trace somewhere (and the challenge is to find where) in the logs, many like to propagate the misconception that one can do something and leave no trace whatsoever. E.g. this CSO Online piece on anti-forensics tools says: "Diskless A-F is the state of the art; it avoids logging of activity all together" while in reality it should say "avoids logging of activity ON THAT SYSTEM, while leaving plenty of traces in other places: firewalls, routers, possibly other systems, etc" (at least on a well-managed network)
Subscribe to:
Post Comments (Atom)
Dr Anton Chuvakin
6 comments:
Ncovert, NUSHU, gray-world.net, et al say you're wrong.
I also say you're wrong. It's too easy to leave zero trace. The CSO Online article is correct. I saw Paul Henry give the presentation on Anti-Forensics at LayerOne in 2006. Vinnie Liu is one of the best and brightest security researchers, and I look up to him - especially on the topic of forensics. These guys know what they are talking about - and they take the network into account.
Last year, in your blog comments, I suggested that "call-home through call-home" could allow covert channels that are nearly impossible to detect. I can probably think of a few ways to do it, but as the CSO Online article suggested - for every forensic method there is at least one full-proof anti-method (and NOT vice-versa).
This is why I really dislike the approach that both you and Richard Bejtlich take on "Logs" and "NSM". You guys have great ideas (probably two of the brightest non-programming security professionals I read regularly), but holding on to the network and system data as if it's the only way (or the best way) to detect or prevent breaches... I'm going to have to say that this approach is simply doomed to fail at original concept.
>I also say you're wrong. It's too
>easy to leave zero trace.
So, what will happen to, say, firewall logs, router logs or (nod to Richard) flow records? Unless there is a major bug in network gear (not impossible for sure!), these will exist. Admittedly, they will be:
- voluminous
- messy
- possibly ambiguous and pointing in the wrong direction
but they will be there, won't they?
>I suggested that "call-home
>through call-home" could allow
>covert channels that are nearly
>impossible to detect. I can
True, but not because there won't be data: the record will look like something you have no way of interpreting correctly (as a backdoor), right?
>for every forensic method there
>is at least one full-proof
>anti-method (and NOT vice-versa).
Hmmm... let me think about it :-)
>system data as if it's the only
>way (or the best way) to detect
>or prevent breaches... I'm going
Well, it is limited, but we are trying to work with what most people actually have. In fact, even "Bejtlich-style" full packet capture is rarely available and we are stuck with just logs.
So, to paraphrase: logs aren't the best way, they are often the only way to work since no other data is available ...
So, what will happen to, say, firewall logs, router logs or (nod to Richard) flow records?
they will demultiplex to port 443 and nobody will be able to see anything
True, but not because there won't be data: the record will look like something you have no way of interpreting correctly (as a backdoor), right?
Correct. The packets could look exactly like regular Microsoft Windows Automatic Update packets coming from a Windows machine at the normal interval. The covert channel could be embedded as a hash of data inside, say, TCP sequence numbers. There could even be an identifier to pick up remote botnets in this way.
Well, it is limited, but we are trying to work with what most people actually have. In fact, even "Bejtlich-style" full packet capture is rarely available and we are stuck with just logs.
Full packet capture is pretty cool. It is readily available. I can make a tap out of $75 worth of parts from the local Graybar store. You can't completely rely on it, but it's better than everything else. Most routers and switches have some form of full packet capture if you're too lazy to build/buy taps.
So, to paraphrase: logs aren't the best way, they are often the only way to work since no other data is available
I do agree that log data and NSM data are good to collect, store, process, and work with for security purposes.
However, as an incident response tool - I find both logs and NSM data to be lacking the substance I need over 80% of the time.
My incident response strategy consists of the following:
1) Strike-back
2) Lock-down
3) Trace-back
4) Take-down
The order is very important.
Strike-back requires a certain level of knowledge of threats. You have to watch somebody attacking you in order to attack them back usually. 200 OK's with a malware twist and buffer overflows in exploit tools may be illegal and dangerous, so check with counsel first before doing this sort of thing. There are other ways besides outright attacks against your attackers - such as footprinting, google hacking, etc. Honeytokens work well for this. If you find your fake data somewhere where its not supposed to be, you can attack the target. Watermarking images and code can also lead you to a phished site, or other place to find stolen data. This has everything to do with "Know your enemy"... in the original meaning, which is not "Learn how to do things your enemy would do to you", or "Figure out what your enemy did after the fact". In order to stay one step ahead of the game, you have to actively identify your adversaries before they attack - and keep tabs on the threat until it is successfully removed. If what they want is data, give them data - fill their database full of random information that looks like real information. Via SQL injection if you have to. I normally don't subscribe to the whole "The best defense is a good offense" strategy, and I've seen this stuff backfire - but there are many reasons to consider it as the first move (like chess openings).
Lock-down requires that you do authentication and authorization to resources in your organization on a per-individual basis. After an account or machine has been compromised, don't "lock out" or completely "disable" the machine/user. Allow them to login, but watch what they are doing, verify that they are who they really are. If they aren't who they say they are - you've now identified a threat (and possibly a new vulnerability if you didn't already know about it) and probably can see their methods. Now you can strike-back.
Trace-back is the method that you and Betjlich seem to be obsessed with. Yep, logs and NSM data are important. But they are not the Holy Grail for incident response. Trace-back is best done through active co-ordination with everyone involved and where everyone has full information sharing and full-knowledge. Just make sure your counsel approves of these information sharing methods, especially if you want to involve a user that is in a customer-role (or anybody else outside of your company / organization). I also think this is best done by FIRST and "your ISP" or "your managed security service provider responsible for security monitoring" and not with just your resources alone.
Take-down is a simple concept that ties into Strike-back (it's the end-goal). You remove the threat(s). This usually involves arresting someone, or taking down a phishing drop site. Use a service such as CastleCops PIRT for the latter, and an organization such as the Secret Service for the former. Again, the problem with the third step (Trace-back) is that most of the evidence gathered isn't going to do anything except provide a way to get an easier confession. You can just as easily get a confession based on the circumstances under your Strike-back or Lock-down efforts against the adversary. Actually, most admissions of guilt happen very quickly for computer criminals.
Thanks for the fun comments! Indeed, if "classic" (in the Rainbow books sense) covert channels are used logging won't do much good as it will get logged as trivial stuff (e.g. Windows update)
BTW,
>My incident response strategy
>consists of the following:
>1) Strike-back
Well, strike-back as step #1 scares me ... you must be working for the govt :-)
Well, strike-back as step #1 scares me ... you must be working for the govt
Not directly, no. I work with NIST a little. Probably should work with MITRE a little. I really haven't done heavy information security management for a few years, maybe excluding a few high profile assessments. I work with developers now. I just do independent research in my spare time, mostly with/for OWASP.
What scares you about strike-back? Like I said, you have to clear this with your GC (general counsel) first if you're a company. They usually won't let you do this, but there may be certain things you can do like tracking down watermarked images, or honeytokens. I know of a few other ways, but I think they are patented. Look 'em up.
>clear this with your GC
Well, if you rephrase "strike-back" as "active response" of sorts, than sure, it makes total sense, since "going after attackers" might not automatically mean "launching an ICBM", but might simply be about deploying a honeypot (honeytoken). That's cool, I still suspect that this type of response can be done later during the incident response process when all the details (all the possible ones...) are uncovered...
Post a Comment