BOEING PROJECT MEETING
November 11, 1998
3083 ENG II
2:00-4:00 pm

In attendance:
Karl Levitt, David Klotz, Jeff Rowe, Jason Schatz, and Chris Wee

Topics:
David's Host-base API
Response
Chris's Fire Wall
Jeff's Scenarios
How to Proceed


    1) David to drop the cost model – Jeff and Jason to pick it up

    2) David’s Host-based API – have David generate interest for the Host-Based API system
            a) Implementing (non research)
            b) Research – what kind of host based responses are there and how effective?
            c) Processes to deal with: files - devices, processes, network connections
            d) Key objects are keys on a host and trust – if you can compromise the system, you gain the trust of other systems
                    i) Breaking into a host subverts host on a web of trust
                    ii) Model idea of trust
                    iii) Steal communication bandwidth
                    iv) Keys – stepping stone to ultimate goal
            e) Response
                    i) Make resource unavailable to attackers
                    ii) Response at application level in addition to CPU level
                    iii) Respond at various levels or abstractly
                    iv) Intrusion Detection systems – revoke keys when host is compromised
                    v) Object Oriented view – defining objects in relation to others; keys, databases, processes
                    vi) Write API with authentication
                    vii) Response at one level can affect the hierarchy at other levels
                    viii) Minimize encryption problem
                    ix) Converge kill on system closest to source- host-based is the best way to do it.

    3) Chris Wee has implemented a firewall capable of doing delays and has one machine behind it.
            a) Dummynet at firewall
            b) Next step:  Able to modify application so he can register dissatisfaction and keep logs
                    i) Implement logging server and disk capacity and syslog messages to CD Writer -- multiple cards on the inside/outside
            c) Every packet held (delayed) and forwarded.  TCP has a bunch of algorithms congestion controlled –vary delay too much triggers a threshold that TCP will try to react to.
            d) Response could cause problems throughout the entire network, not just applications.  Chris Wee doesn’t think it should have any complex effects because the system is so simple.  He can vary delay by surface by port.

    4) Scenarios (see handout notes)
            a) Responses
                    i) Turn back clock – interesting idea, but screws up applications and other unknowns.
                    ii) Averaging instead of synchronization
                    iii) NTB Server
                    iv) Hook up to time clock at NIST
                    v) Rules to examine time zones
                            (1) Look for simultaneous attacks or time-triggered attacks
            b) Missing from scenarios – what has it done to disrupt the network?
                    i) Kills INET B on all machines.

    5) How to clean up multiple machines from the Security Lab attack
            a) Check system binary for any Trojans
            b) Run trip wire
            c) Wire machines clean and reinstall (not easy to do with NT)
            d) Take captured tools/attack and run on a machine to see the actual damage
            e) Reload machines from backup that don’t change

    6) What is our reaction to that damage?  Our manual/automated response?
            a) Remote boot and remote loading
            b) If the server is attacked as its reloaded – major denial of service
            c) We’re lacking a way to measure when a system has been compromised.  Applications may be fine for the user.

    7) Increase number of network connections – an equally valid response to blocking
            a) SMART cards – when things get bad, automatically boot yourself up
            b) Chris Wee suggests no bandwidth wireless channels (justification for getting wireless nodes)
                    i) Bill Arbaugh – Oakland conference 1997 – check every step of boot processing.
            c) Watchers type thing – neighbors have information
            d) Routers require cooperation.  We don’t have to diagnose each other.

    8) How to Proceed
            a) Protocols – Chris Wee
            b) Build a general framework (CYC), useful tools
            c) Modeling
            d) Classifying attacks (into a tree chart) – gives you certain ideas for responses
                    i) Take taxonomies of attacks and annotate them with responses

    9) Next Meeting:
            a) Dissect scenarios
            b) Firewall – router filtering same
            c) Josh Goodman paper



Handout notes:
Scenario 1:  Malicious worm propagating across multiple enclaves.

The attacker has designed a worm that propagates via four different methods:

1) a sendmail buffer overflow,
2) an ipop server exploit,
3) telnet using weak passwords,
4) trusted hosts using rsh/rlogin.
The worm propagates itself to target machines that have recently connected to the infected hosts and kept in its arp cache. Once the worm has transferred itself to a target host, it installs a Trojan horse version of one of the setuid root binaries.  The worm is unleashed and manages to infect large numbers of hosts across multiple enclaves. Later, the attacker will signal his Trojan horse to bring the machine down, thus disabling enough of the victim's critical machines to compromise the entire mission.

This is a difficult attack to detect and respond to automatically with current technology.  First, detectors must correlate the worm's use of four separate and logically unrelated methods of propagation.  Second, although detectors exist that pinpoint the installation of Trojan horse programs (e.g. tripwire) they are typically not run continuously on each machine in the network, and additionally, the installation of the Trojan horse will not be correlated with the activity of the worm.


Scenario 2:  Worm propagates via sendmail, infecting many machines across multiple enclaves.

A typical attack scenario illustrating our method of response is a distributed, coordinated attack that is self-propagating.  In particular, consider a malicious worm that propagates via a buffer overflow exploit in the sendmail demon. The worm is mailed through the firewall and is set loose in the internal network. On each successfully infected host, the worm installs rootkit and starts a process attempting to obtain root access on the machine. Once root is broken, malicious Trojan horse versions of frequently used system binaries are installed for later use.  The worm then attempts to transfer itself to other machines that its current host frequently communicates.  In this way, malicious code can be installed on numerous hosts behind a firewall creating an extremely dangerous threat to the current mission.  The malicious code simply waits for a signal, or for a predetermined time to execute and wreak havoc throughout the network, and across multiple enclaves.

Manually responding to this type of attack is extremely tedious and time-consuming.  Firewalls and routers must be reconfigured to suppress worm propagation across inter-enclave boundaries.  Then, all infected hosts in the network must be protected from further worm attack, have their rootkit-installed Trojan horse binaries located and removed; clearly a tedious job when done manually.  Furthermore, during the considerable time required for a manual response, the as yet unprotected hosts in the network remain vulnerable to infection (or reinfection) creating an ever increasing list of task for the human operator to perform.