MisUse Cases for the Grid

1
(Mis)Use Cases for the Grid

• Dane Skow
• Fermilab
• September 29, 2004

2
Who is the audience for this talk ?

• Software and service developers
• Appropriate controls and recovery mechanisms need
  to be designed in.
• System and service administrators
• Timescales are much reduced and demands greater
• Managers
• Grid brings new threats and costs

3
Who will misuse the Grid ?

• Criminals looking to exploit resources and/or
  hide their tracks
• Curious people experimenting
• Intended users trying to game the system to
  their advantage
• Intended users making mistakes

4
How will they do it ?

• Probably the same patterns as general Internet
  attacks.
• The Grid is under attack today (eg. OS).
• First specific channel likely is credential
  hijack
• Next are probably grid versions of current attack
  methods (code vulnerability exploits, code
  injection, )
• Also may utilize grid management/forensics tools
  directly and/or develop their own tools

5
Consider a Grid Worm

• A worm is a piece of software which is aware of
  its environment and tries to automatically
  exploit available resources.
• Sounds like an opportunistic Grid job.
• Users are expected to have automated agents
  acting on their behalf to manage long/complex
  jobs.
• Agents and/or job elements are expected to be
  able to discover resources available to perform
  jobs.

6
Lifecycle of a Worm

• Birth
• (Executable Insertion)
• Growth
• (Privilege Acquisition)
• Reproduction
• (Propagation)

7
Executable Insertion

• Executable is somehow inserted into a grid job
  submission.
• Today most likely exploits a common application
  (eg. OS, web browser, etc.) vulnerability
• Increasing use of trojan weblinks
• We do see cases of worms including password
  sniffers and automatically following users
• Spread of these so far has been limited
• One user uses relatively few machines
• User communities dont frequently share resources
• The grid will reduce both of those limitations.

8
Detection and Defense

• Network Security
• IDS can help spot attacks. (Beware false
  positives)
• Developers
• All applications which accept input need to
  validity check the input and protect against
  input replacement.
• Working files need to be protected against change
• Applications which accept executable input should
  allow for a trusted scanning service
• Have some method of input flood control
• Sysadmins
• Dont run unnecessary services
• Minimize trust in services to avoid jumping

9
Lifecycle of a Worm

• Birth
• (Executable Insertion)
• Growth
• (Privilege Acquisition)
• Reproduction
• (Propagation)

10
Privilege Acquisition

• Initial toehold usually not enough
• May need to gain access to local privileged
  account (eg. Get root)
• May need to create new execution environment (eg.
  Fork a shell)
• May need to collect some data (eg.credentials,
  targets, etc.)
• The worm may use local exploits to do this.
• This phase may be long running and independent of
  the propagation phase

11
Detection and Defense

• Developers
• Check all inputs and error returns !
• Assume uncertain environment. Contain threats
• Separate functions (particularly privileged ones)
• Protect your working data
• Remove no longer needed data
• Create and protect logs
• Allow for throttles and/or alarms on overuse
• Sysadmins
• All attempts to use privileged accounts should be
  logged.
• Dont neglect patches for local exploits
• Be alert for unusual network connections
• Be alert for unusually long running processes
• Protect your logs from unauthorized reading and
  tampering

12
Lifecycle of a Worm

• Birth
• (Executable Insertion)
• Growth
• (Privilege Acquisition)
• Reproduction
• (Propagation)

13
Propagation

• To spread, worms must propagate to new hosts
• Propagation method may differ from insertion
• Often includes multiple attack methods
• May be driven by data collected from Privileged
  Acquisition phase
• Overly aggressive propagation destroys the host
  environment
• The electronic parasites are learning this too
• May or may not be their goal

14
Detection and Defense

• Network Security
• Consider active network defenses (in and
  outbound).
• Consider authorized network channel provisioning
• Developers
• Build in throttle control points and/or alarms on
  overuse
• Avoid temptation to multiplex on few clear
  channels
• Sysadmins
• Be alert for unusual network connection frequency
• Be alert for unusually long running processes
• Consider IPSEC where possible
• Protect your logs from unauthorized reading and
  tampering

15
Lifecycle of a Worm

• Birth
• (Executable Insertion)
• Growth
• (Privilege Acquisition)
• Reproduction
• (Propagation)
• Death ?
• (Eradication)

16
Eradication

• Currently not possible
• The Internet carries a load of parasites
• Old worms just overshadowed by next release
• Attacks always get better
• Rapid (re)infections will kill the weak
• Must break the propagation cycle
• Developments in rapid quarantine perhaps not
  enough

17
Grid Implications?

• Most destructive worms are greedy.
• Need to harden discovery service against flooding
  DOS
• Brokering services should include some sort of
  flooding feedback.
• Credentials may be automatically collected.
• Need method of dealing with large scale
  compromises quickly enough
• Proxy exploitation may be rapid enough to be
  sustaining

18
More Grid Implications

• Transparency of sources may be difficult.
• The source of the executable has to be
  determined.
• Currently this involves examination of the
  compromised machine, system logs and local
  network logs
• Resources downstream in the attack may be
  obscured by brokers, etc.
• Transparency of action may be difficult
• the actions of the executable have to be
  determined
• The next step in the action may not be the next
  target directly.

19
More Misuse Cases

• The Grid Filez server
• Bad guys scour the net looking for resources
  available to host their software (including the
  Filez service itself)
• Capacious disk and network connections are valued
  and preferentially used.
• The Grid Doorknob rattler
• Bad guys probe the grid cataloging the Grid
  services and vulnerabilities

20
Conclusions

• Incident response will be required.
• Controls must be put in place to contain spread.
• Prepare for the likely cases.
• We can predict early types of abuses
• We need to instrumentation to look for them
• We need controls to contain them.
• Avoid the tragedy of the Commons
• Requires the ability to effectively assert
  authorization controls.

21
Backup Slides
22
What is misuse ?

• Trivial definitions are not useful
• Unauthorized merely pushes problem down a level
• Unintended use hampers exploration and
  serendipity
• Im going to focus on use which causes harm to
  either the resource owners or the general public

23
Why study misuse ?

• Rigorous security is usually expensive and
  usually inconvenient
• Need to understand likely misuse in order to
  prioritize investments
• Controls need to be designed in beforehand to
  respond quickly to changes in attacks.
• Have responsibility to do professional job with
  the publics trust

24
(No Transcript)