Vigilante: EndtoEnd Containment of Internet Worms

1
Vigilante End-to-End Containment of Internet
Worms

• By MS Research_at_Cambridge, UK
• Presented by Zhen ZHU

2
Introduction of Worms

• Definition and history about computer worm
• A computer worm is a self-replicating computer
  program.
• It uses a network to send copies of itself to
  other nodes (computer terminals on the network)
  and it may do so without any user intervention.
• Unlike a virus, it does not need to attach itself
  to an existing program.
• Worms always harm the network (if only by
  consuming bandwidth), whereas viruses always
  infect or corrupt files on a targeted computer.

3
Introduction of Worms

• The name 'worm' comes from The Shockwave Rider, a
  science fiction novel published in 1975 by John
  Brunner. Researchers John F Shoch and Jon A Hupp
  of Xerox PARC chose the name in a paper published
  in 1982 The Worm Programs, and it has since been
  widely adopted.
• The first implementation of a worm was by these
  same two researchers at Xerox PARC in 1978.
• Shoch and Hupp originally designed the worm to
  find idle processors on the network and assign
  them tasks, sharing the processing load, and so
  improving the 'CPU cycle use efficiency' across
  an entire network. They were self-limited so that
  they would spread no farther than intended. (the
  idea of BOINC)

4
Computer Internet Worms

• Types of computer worms
• Email Worms (embedded code or links)
• Instant messaging worms (links)
• IRC worms (links)
• File-sharing networks worms (like in P2P)
• Internet worms (only part of the worm family!)
• The first 4 types are passive, the worm is not
  clever, rather sometimes people can be stupid.
• Internet worms are active, they find vulnerable
  codes in the computer services (like IIS, RPC and
  SQL server, usually in MS systems. Generally,
  worms only do harm to the network, but they can
  carry extra malicious code , the Payload, to do
  damage to the computer hosts)

5
Real World Internet Worms

• Famous/infamous Internet Worms
• Slammer (0530 UTC on January 25, 2003, targeting
  MS SQL server, causing DoS of the SQL server,
  also called SQL slammer)
• CodeRed (July 13, 2001, targeting MS IIS, execute
  arbitrary code.
• GET /default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
  NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
  NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
  NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
  NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNu9090u
  6858ucbd3u7801u9090u6858ucbd3u7801u9090u68
  58ucbd3u7801u9090u9090u8190u00c3u0003u8b00
  u531bu53ffu0078u0000u00a HTTP/1.0)
• Blaster (August 11, 2003, attack Windows DCOM
  RPC service)

6
Properties of Internet Worms

• Three general types of attack
• Arbitrary Execution Control (to run some control
  function that are not permitted to common users.
  The code is actually part of the target system,
  e.g. STOP SERVICE in SQL server)
• Arbitrary Code Execution (the code is not part of
  the target system! It is suppose to be stored as
  data in the memory, however it is interpreted as
  instructions and thus gets executed)
• Arbitrary Function Argument (if the targeted
  system can call the OS function exec, the worm
  can use such function call to format the disk if
  it pass format D as argument to the function)

7
Properties of Internet Worms

• For the first two types, usually, buffer overflow
  bugs are existed in the system. In most cases
  buffer overflow will only cause crashes, but if
  designed carefully, we can do the following
  thing

8
Properties of Internet Worms

• The return address of the Drawline function is
  changed! It can be redirected into a memory
  address which is supposed to store data! And the
  malicious code are now interpreted as program
  flows.
• Usually, the system need to load two or more
  function consecutively, so that they have
  adjacent spaces. If you know the function memory
  allocation and where the vulnerable part is, you
  can also directly overwrite another function s
  context with your own code so they get executed
  (direct insertion, not changing the return
  address).
• The third type can be either caused by overflow
  (overwrite the parameter spaces) or simply the
  lack of security check of the program.
• Usually the worms are sent as ASCII messages like
  text, so we can also call them attack messages.

9
Properties of Internet Worms

• Spread of the worms
• Internet worms are spread much faster than other
  worms due to their active probing strategy.
  Slammer, in its breakout period, the infected
  machine doubled in 8.5 second (fastest worm of
  all nature) !!! Such spread speed will cause a
  huge network overhead and hence lead to DoS in
  network.
• We can use the model of human virus (flu) to
  describe it.

10
Vigilante

• MS research proposed a end-to-end containment
  system to the internet worms.
• Vigilante literally means one who takes or
  advocates the taking of law enforcement into
  ones own hand. (so you can imagine this should
  be a self protecting system, lets not depend on
  MSs patches!)
• A decentralized scheme, parties dont need to
  trust each other. Its an alarm and protecting
  system. It can cooperate with all kinds of detect
  engine.

11
The Big Picture of Vigilante

• Some nodes have the detection engines or are
  dedicated to detection. Once they find the new
  attack, they generate report about the attack as
  well as the vulnerable part of the victim.
• It then broadcast to all its peers and the host
  upon receiving such alert, verify the
  vulnerability of themselves.
• If such vulnerability exists, the host then
  generates a filter to protect itself from the
  attack message.

12
Components of Vigilante

• Self-Certifying Alerts (SCAs)
• The primary job of this system is send alerts of
  a newly detected worm to the potential vulnerable
  nodes before there is any official patches!
• There is 3 types of alerts corresponding to the 3
  types of attack.
• They use a common format
• An identification of the vulnerable service
• An identification of the alert type
• Verification information to aid alert
  verification
• A sequence of messages with the network endpoints
  that they must be sent to during verification
  (most worms only contain 1 message for efficiency
  reason. However some might contain 2 or more,
  e.g. blaster has 2).

13
Components of Vigilante

• Sample of the SCA message
• The verification information varies depending on
  the alert type. Message data contains the attack
  message (here 376 bytes message used by Slammer
  worm).

14
Components of Vigilante

• The verification information for an arbitrary
  execution control SCA specifies where to put the
  address of the code to execute in the sequence of
  messages (e.g., in which message and at which
  offset.)
• The information for arbitrary code execution SCAs
  specifies where to place the code to execute in
  the sequence of messages.
• Arbitrary function argument alerts have
  information to specify a critical function, a
  critical formal argument to that function, and
  where to put the corresponding actual argument
  value in the sequence of messages.

15
Components of Vigilante

• Verification System (in a sandbox)
• The sandbox is indeed a virtual machine, it has
  the same setting as the physical host. After each
  verification, the virtual machine immediately
  restarts with a clean copy which was saved
  earlier.
• The virtual machine should always stand ready for
  verification. Since time matters!
• The detector node also contains the verification
  system. SCA needs to be verified within the
  detector node before broadcast.

16
Components of Vigilante

• The architecture of the verification system

17
Components of Vigilante

• The host runs the SCA verifier which communicates
  with the verification manager inside the virtual
  machine
• The virtual machine runs an instrumented service
  (a very smart trick)
• We dont know what would be the result after the
  malicious code being executed. However, we can
  tell whether they will be executed or not!
• Load a new library with a function Verified. If
  we receive a AEC alert, we replace the address in
  the message data with the address of the Verified
  function. If we receive a ACE alert, the code for
  call Verified will be replaced in to the attack
  message.
• Wrap critical function call (such as exec). The
  wrappers call Verified if actual value of a
  critical argument matches the description in the
  SCA. Otherwise they call the original function.

18
Components of Vigilante

• The verification is simple and generic, dont
  need to modify any existing services.
• The verification is fast (depending on VM)
• No false positive (once verified, thats a
  vulnerability without doubt)
• May have false negative
• When the target address, code, and argument
  values are not transferred verbatim in the
  sequence of messages. Pieces are transformed by
  the vulnerable service before being used together
  later.
• SCAs might not be able to replay the attack
  situation if the bug needs certain order of
  thread/process execution to be exposed(not yet
  the case for the known worms).

19
Components of Vigilante

• An Alert Distribution Mechanism
• Once the alert is generated, it needs to be
  spread out as fast as they can. It is a race with
  the worm. If we detected the worm in the early
  stage (the slow start phase), we can limit the
  worms damage.
• The distribution of SCA should be reliable and
  secure. because the growing number of hosts
  compromised by the worm can launch attacks to
  hinder distribution and the number of detectors
  sending an SCA for a particular vulnerability can
  be small.
• To meet these requirements, Vigilante uses a
  secure Pastry overlay to broadcast SCAs.
• Flooding are used to broadcast the SCAs. Since
  the overlay is always ready, no time for probing,
  thus run faster than the worms.
• The alerts are allowed to contain a lot of false
  positive, since the verification step will
  eliminate them. However, by doing so, we increase
  the overhead both to hosts and network.

20
Components of Vigilante

• Automatic Filter Generator
• A filter should be generated automatically when a
  node verified the vulnerability (this is to give
  instance protection).
• Messages that look like an attack will be ignored
  by the filter (the SCA contains the functional
  part of the attack message).
• This is a temporary solution, patches are still
  needed, however it will significantly reduce the
  damage caused by the worm.
• Two or more filters can be generated and used to
  reduce false negative results.

21
Advanced Topic

• The idea is simple and elegant, however the
  difficulty lies in the part of worm detection and
  filter auto-generation.
• How can we make them happen?

22
Advanced Topic

• Detection Engine
• The detection engine is independent of the
  Vigilante system. It can be integrated with any
  engines as long as theyre working.
• Coverage is proportional to the overhead for the
  detection engine.
• Two extreme cases are described here
• Non-executable pages (NX pages) low coverage
• Dynamic dataflow analysis high overhead

23
Advanced Topic

• NX Pages
• Put data into NX pages, if the program try to
  execute things on the NX pages, exceptions are
  thrown out.
• Once there is the exception, the detector
  traverses the message log searching for faulting
  instruction (codes)/address to faulting
  instructions. Upon locating, candidate SCA is
  generated.
• Candidate SCA needs to be verified within the
  detector first before broadcasting.

24
Advanced Topic

• Pros and Cons for NX pages
• Pros
• Negligible overhead, emerging hardware support
• Very fast for detection of code insertion! When
  the worm is embedded in only one attack message
  (in most cases), its easy to find and verify the
  attack message (usually the most recent one)
• Cons
• Need more complicated protection technology for
  AEC type of attack. If the return address is
  overwritten and redirected to an address on the
  executable page, no exception.
• If the worms consist several messages, than the
  process of searching candidates becomes more
  complicated.
• Hard to deal with more complicated buffer
  overflow attacks.
• Cant deal with AFA attack

25
Advanced Topic

• Dynamic Dataflow Analysis
• This is a more generic detection method, can deal
  with all 3 types of attack.
• Introduce the concept of dirty data, if data is
  received from some particular sources, its
  marked dirty (i.e. from the network).
• Every dirty bytes will be assigned with a
  sequence number for the convenience of generating
  the candidate messages later.
• Whenever data copy/move takes place, if the
  source is dirty, then the destination is marked
  dirty, otherwise its clean.

26
Advanced Topic

• To implement this, low level assemble
  instructions need to be instrumented (e.g. RET,
  CALL, JMP, MOV, MOVS, PUSH, POP) in order to keep
  track of the dirty data and their sequence
  number.
• Whenever the dirty data is going to be loaded
  into program counter (dirty address value),
  executed (dirty code), or passed as argument
  (only critical arguments for critical functions),
  an alert raises.
• Backtracking to find the candidate SCA is very
  easy since we have the sequence number of
  faulting data! Even for multi-message worms, its
  still the same.

27
Advanced Topic
28
Advanced Topic

• Automatic Filter Generation
• When the SCA is verified by the host, the host
  first suspend the vulnerable service, and then
  begin to generate the filter.
• The filter is generated using more advanced
  data-flow analysis of the attack.
• A lot of low level stuff involved, just too
  advanced for a network management class.
• Filters generated using such method have no side
  effects (no false positive). And should be able
  to block the attack that are identified in the
  SCA. Could even block more (such as variants of
  the worm)

29
Experiments Results

• Experiment Setup
• Experiments ran on Dell PrecisionWorkstations
  with 3GHz Intel Pentium 4 processors, 2GB of
  RAMand Intel PRO/1000 Gigabit network cards.
  Hosts were connected through a 100Mbps D-Link
  Ethernet switch.
• Evaluated Vigilante with real worms Slammer,
  Blaster and CodeRed.
• Experiments with CodeRed and Blaster ran on
  Windows 2000 Server and experiments with Slammer
  ran on Windows XP with SQL Server 2000.

30
Experiments Results

• Results for Alert Generation

31
Experiments Results

• Results for Alert Verification
• The overhead to keep the VM running is low a VM
  with all vulnerable services used less than 1 of
  the CPU and approximately 84MB memory.

32
Experiments Results

• Alert Distribution
• Experiment are done in simulation
• The simulations ran on a simple packet-level
  discrete event simulator
• Topology generated using the Georgia Tech
  topology generator. 5050 routers arranged
  hierarchically with 10 transit domains at the top
  level and an average of 5 routers in each.
• The delay between core routers is computed by the
  topology generator and routing is performed using
  the routing policy weights of the graph
  generator.
• Vigilante hosts are attached to randomly selected
  stub routers by a LAN link with a delay of 1 ms.

33
Experiments Results

• Totally 500,000 host in the simulation. Hosts are
  randomly selected to be susceptible because the
  run the same service.
• A fraction p of the susceptible nodes are chosen
  to be detector. Others are just vulnerable hosts.
• Simulate with the secure overlay.
• Measure the worm spread using the epidemic model
• Network congestion is considered, the percentage
  of packet drop increase linearly with the number
  of infected hosts.
• DoS attack on the Vigilante system itself is also
  simulated by assume infected nodes continuously
  send fake SCAs to slow down the distribution,

34
Experiments Results

• Parameters used in the simulation
• Here ßis the average infection rate. S is the
  number of total nodes simulated. Tg is the time
  for the detector to generate an SCA and Ta is the
  time for the vulnerable host to verify an SCA.
  Those values are based on real world observation.
• Initial with 10 infected nodes, infected nodes
  probe the network using the worms own strategy,
  when a vulnerable node is probed, it becomes
  infected. Whenever a detector node is probed, an
  SCA will be generated.

35
Experiments Results

• Results for Containment of Different Worms
• The results are average based on 250 runs with
  error bar to the 90th percentile value. Here the
  percentage is on the total vulnerable nodes NOT
  the total nodes!

36
Experiments Results

• Comparison Results
• Using different SCA verification time, infection
  rate and number of initial infected hosts under
  Slammer attack

37
Experiments Results

• Results for Filter Generation

38
Experiments Results

• Results for Overall Overhead
• Memory usage is small (primarily is for VM
  itself) so focus on CPU usage
• 3 experiments
• Only with socket interception
• Filters are involved
• Simulate filter working under attack (10
  probes/sec)

39
Experiments Results

• Real End-to-End Experiment
• 5 machines in a local network with Vigilante
• Record the time between a probing message is
  detected and SCA is generated and verified
• 79ms for Slammer, 305 ms for Blaster, 3044 ms for
  CodeRed
• After the vulnerability is verified, the service
  is suspended till the filter is generated and
  deployed.
• Filter deployment is fast, less than 400
  microseconds
• No further explanation on this result. Doesnt
  seem to be very convincing.

40
Conclusion

• From the experiment it seems that Vigilante works
  well. The percentage of the infected vulnerable
  host are impressively small.
• Only a good simulation results in which parameter
  choices and general assumptions (such as the
  topology) will affect the results a lot.
• The real problem is the VM. Its okay for
  machines running SQL server. But for end users of
  WinXP, to maintain a VM which has the same
  configuration as the physical host is not
  realistic at all. Can we do it out of the sand
  box?

41
Questions and Thoughts?