- I started the day in Bruce Schneier's keynote. Bruce's talk was interesting but plauged by audio problems (not his fault). Bruce reiterated his ideas of the "security consumer" who asks "is it worth it?" when deciding whether or not to wear a bullet-proof vest when walking out his front door. Bruce seems to have changed his mind about the evils of "security theater," because he said "security is a feeling and a reality," and sometimes security theater is needed to right imbalances between the feeling and the reality. This imbalance can come about when citizens watch television, which impairs their availability heuristic by making rare and catastrophic events seem common and personal.
Bruce focused on psychology, stating people, on average, are risk-seeking when facing losses but risk-adverse when facing gains. In other words, they are more likely to take a chance to avoid a loss than they are to take a chance to acquire a greater gain. Bruce published a paper describing his views at The Psychology of Security. Pay attention to the five aspects of the security trade-off.
- Jim Hoaglund from Symantec presented my first technical talk of the day. He described the new Windows Vista TCP/IP stack and emphasized the role of tunnels for IPv6. It's probably best just to read the papers behind the talk, namely Windows Vista Network Attack Surface Analysis (.pdf), The Teredo Protocol: Tunneling Past Network Security and Other Security Implications (.pdf), draft-ietf-v6ops-teredo-security-concerns , Microsoft's Objectives for IPv6, and Jim's blog post. Jim said "stacks are complex entities that take years to mature." Jim discussed stack vulnerabilities found in beta versions of Vista. I was very interested in hearing about the new fragmentation reassembly standard used in Vista, which differs from previous versions. (Hello trouble for IDS/IPS/etc, good news for stack fingerprinters.)
Jim spent a lot of time talking about Teredo, documented in RFC 4380. Teredo is designed as an IPv6 transition mechanism "of last resort." I've documented my tests with Miredo, a Unix implementation. What struck me about Jim's comments were his revelation that Teredo was designed without visibility or control. This directly contradicts my idea of Security Application Instrumentation. Essentially, unless an inspection product analyzes every UDP packet, it is not possible to control Teredo. It is possible to "starve" Teredo traffic by blocking outbound to Teredo servers on UDP port 3544, but that is not a complete solution. Also, Jim claimed that in some cases Teredo "may be preferred even over native IPv4." He recommended that Teredo not be deployed on "managed networks," which is just about anywhere that matters.
- Nick Harbour of MANDIANT discussed basic, intermediate, and advanced ways to hide malware. He talked about hook injection to hide malware in existing processes, library injection (the most common attack) via CreateProcessThread() to hide in libraries, and direct injection, where code is inserted directly into processes. He mentioned registry tricks like Image File Execution Options to launch malware as a "debugger" that calls a legitimate process. Nick said he would release Malvm and his Executable Toolkit on nickharbour.com soon.
- I watched almost all of Gadi Evron's talk about the Estonia "information war," but I felt like he took over an hour when probably 20 minutes would have sufficed.
- One of the best talks on the second day was delivered by Tom Ptacek and Eric Monti who described vulnerabilities and exposures in extrusion detection and related products. Because they could not name the products they had tested, they profiled a "fake" product called PlugBoy. Basically, these products are nearly worthless, except for the value they deliver in demonstrations to executives and the launch pad they provide for intruders. They focused on host-based systems instead of those that sit inline or offline.
Tom and Eric said "evasion is a given." For example, you can trivially bypass their filters using any number of techniques at layers 3, 4, or higher. It could take as simple a technique as changed text in a word document to bold or adding a space between every character of the document. The problem with these products is that they need to do some sort of file format decoding in order to have a prayer of making sense of a document's contents. Unfortunately, by introducing file format dissection decoding, they are incredibly vulnerable (think of Wireshark's security history with protocol dissectors and recent file format fuzzing exploits.)
Here's another problem with extrusion products on the host: they tend to communicate what they find in the clear to their management platforms. (Zlib compression doesn't count as "encryption.") So, think of this: you have a product sitting between a remote SSL-enabled site, inspecting and grabbing sensitive content, then retransmitting a subset of that content in the clear to the management server. Who designed this train wreck? Furthermore, these products tend to have application, service, and kernel components. This means you have a piece of code that by design has access to everything you consider sensitive sitting in the kernel.
Tom and Eric said this code is rife with vulnerabilities. They described how sending a malformed AIM packet would root the agent and therefore the kernel and therefore the box. Returning to agent to manager communications, this channel is unauthenticated. This means anyone could spoof traffic or send traffic to the management console. That content tends to be rendered in a Web application viewable by the administrator. Now you can send traffic to the management console (think XSS or other file rendering attacks) and own it.
In case you didn't put all these steps together, here they are: 1) Web browser with ED agent visits malicious Web site; 2) Web site attacks and owns ED agent; 3) Owned ED agent attacks ED manager; 4) Owned ED managed attacks and owns all ED agents on all hosts; Game Over.
In brief, the host-based ED products Eric and Tom reviewed are "latent botnets" in addition to all their potential violations of PCI and other regulations protecting data.
I managed to briefly talk with Tom and Eric prior to their presentation, which was cool. They reminded me I need to try their tools, like Black Bag, which is "Netcat on steroids."
- I finished the day watching my friends Keith Jones and Rohyt Belani present three case studies on insider attacks. Keith talked about the Duronio case. Rohyt described a wireless exploit at a retail company and a law firm document management system abused by an administrator.
I had the following thoughts after watching these talks.
- We cannot eliminate the probability of compromise of the general Internet population. This is another way to say "prevention eventually fails." We can reduce the probability of compromise by applying costing countermeasures or drastically limiting exposure. You could think of this situation as the difference in the lives between the President and his Secret Service vs Joe Sixpack. The President can try to venture outside if protected by agents, but Joe is a sitting duck. His best bet is to stay home if he feels threatened. This deserves more thought, so I will probably address it later. A digital equivalent is hiring a team to build your own special Web browser or using a text-based Web browser and living a more monastic life.
- Modern countermeasures applied to reduce vulnerability and/or exposure in many cases increase both vulnerability and exposure. This is certainly the case with so many agents (see Matasano is Right About Agents.)
- Developers continue to ignore history by reintroducing old vulnerabilities and exposures. Tom and Eric talked about how so many products ship old vulnerable versions of Gzip libraries, as one example.
- As assets are increasingly managed, it becomes easier for intruders to exploit vulnerabilities in them and assume management of those assets. Eric and Tom noted that monolithic agents are being placed on assets of all types for purposes of managing them (if operating system homogeneity weren't enough of a problem). These agents are not coded to the standards found in the OS (props to Microsoft for getting its act together in recent years). The problem with these agents is that they open a brittle window for takeover by malicious parties.
- Firewalls are channel restriction products, not compromise prevention products. As the number of channels proliferates, the firewall is increasingly irrelevant. Inspection products (which include detection and filtering devices) are caught in a quandry. Application-unaware (think content matching alone, maybe via regex) inspection and filtering systems are less able to understand content and counter attacks. Application and protocol awareness would seem to be the answer, but those dissectors are directly targted by intruders and are heavily vulnerable to protocol and file format attacks. (Previously the content inspectors were mainly vulnerable if their content-matching system [think regex library] had a flaw.) No one wins.
I'm really rushed here so I may revisit this post to fix a few thoughts. I will post my overall defensive recommendations in a future post.