Document Sample
Intro Powered By Docstoc
					  Chapter 5

 Allviruses self-replicate
 Anti-anti-virus means it’s “openly
  hostile” to AV
 Anti-anti-virus techniques?
  o Aggressively attack AV software
  o Make analysis of virus difficult
  o Try to avoid being detected using
    knowledge of how AV works
         Anti-Virus Virus?
 Anti-anti-virus   versus “anti-virus virus”
  o What the … ?
 Thischapter is about anti-anti virus
 Aside: What is an anti-virus virus?
  o Virus attacks other viruses, or
  o AV software that propagates virally, or
  o Software that drops a virus, then offers
    to remove it for a fee
 Also  known as “anti-antivirus viruses”
 Virus with active defense
 What techniques are used?
 Kill AV (and related) processes
  o Virus lists active processes
  o Kills things like Avgw.exe, Scan32.exe,
    Navw32.exe, Regedit.exe, Zonealarm.exe
  o Might also do this for processes run at
 Example:   Ganda virus
 Kills running AV-like processes
 Examines processes run at startup
  o If it appears to be AV-related…
  o …replace 1st instruction with “return”
 Stealthier?
  o Starve AV software by lowering priority
  o Prevent AV software from connecting to
    company database, etc.
   Entry Point Obfuscation
 Viruses   often hijack usual entry point
  o But this is fairly obvious
 Set    entry point at random location?
  o Probably not a good idea --- why?
 Find   calls to ExitProcess API?
  o Used by Simile and Ganda
 Look   for known code sequences?
  o Compilers produce stereotypical code
       that emulation is used for AV
 Recall
 How can virus defeat emulation?
  1. Outlast
  2. Outsmart
  3. Overextend
 AV   solution to 2 & 3 is better emulator
  o Of course, this comes at a price…
   Anti-Emulation: Outlast
 How   to “outlast” an emulator?
1. Lots of (disguised) do-nothing code
2. Only be malicious, say, 1/10th of time
  o Then AV might mark code as safe
  o Subsequently, virus has a free hand
3. Entry   point obfuscation
  o Emulator might assume virus will appear
    early in execution of infected code
  Anti-Emulation: Outsmart
 Try to counter dynamic heuristics
 Example: In some cases, decryption is
  a good dynamic heuristic
 To counter this, virus could…
  o Spread decryption throughout code, not
    all in one loop
  o Then emulator might never reach its
    “decryption” threshold
 Anti-Emulation: Overextend
 How    to push emulator to the limit?
1.   Use undocumented instructions
     o If not handled correctly, it’s emulated
2. Bugs   in CPU
     o If handled correctly, it’s emulated
3. Exhaust or abuse memory
4. Check for differences between
   system calls, e.g., check “time” twice
     o Emulator might return fixed value
Anti-Emulation: Overextend
 How  to push emulator to the limit?
5. Import obscure libraries
6. Use external resources, e.g., web page
  o Almost impossible to emulate external
7. Emulator-specific   checks
  o E.g., a known interface to outside
 “Armor”   virus --- make analysis more
 Two types of techniques used:
1. Anti-debugging
  o Examples?
2. Anti-disassembly
  o Examples?
 Look   for inserted breakpoints
  o Like error detection/correction
 Look   for single-stepping
  o Interrupt pushed onto stack after every
    instruction… so push then immediately
    pop, or
  o Time the execution, or
  o Dynamically modify next instruction,
   since processors usually pre-fetch
 Last   2 also anti-emulation techniques
 If   all else fails, ask:
  o IsDebuggerPresent()
   Linux, request to trace a process
 In
 more than once fails
  o How can virus take advantage of this?
 Speaking of threads…
 Interlocking and deadlocking threads
  o Only small part of code appears
  o Different parts each time
 Fairly   strong for anti-debugging
  o Improved software activation using multithreading
      be even more effective if
 Could
 combined with encrypted code
  o Project, anyone?
 Anti-disassemblymentarianism?
 Goals
  1. Disassembly cannot be automated
  2. Code not available until it executes
 For   1, one idea is to mix code and data
  o Once mixed, separating is unsolvable
 Mixing   code and data can result in
 false disassembly

 Disassemblers   not so easily confused…
 How   to make code unavailable for
   static analysis?
1. Dynamically generate code at runtime
2. Self-modifying code
  o A red flag for heuristic analysis
     the environment to “construct”
3. Use
 code at runtime
  o How’s that?
 Constructed code?
 Hash stuff and extract “code” bits…
  o Perhaps combine with buffer overflow?
  o Project, anyone?
 Encrypted   code
  o Decrypt in parts as needed
  o Flush plaintext when done
  o Combine with anti-debugging
  o Watch for MiM type of attacks
 My startup company did all of this
 Might do similar things with threads
  o Intentionally “delicate” timing
 Virus   traces system functions it uses
  o To be sure they “go to” the right place
  o If not, code is being monitored
 How   to trace code?
  o Static heuristic or emulation
  o Just like the AV stuff…
 Can’t   tunnel into kernel on modern OS
  o But still might be useful technique
 AV  software can hide from tunneling
 if it’s installed in the kernel
  o Unless virus is in the kernel too…
 But,virus in kernel would be bad for
 lots and lots of other reasons
 Integrity Checker Attacks
 How   to avoid integrity check?
  o Integrity check can detect any change
 Stealth   virus might hide
  o But only from weak integrity check
 Infect  when legitimate change to file
 In one infamous case…
  o Delete integrity check database and all
    checksums recomputed
 Hide in places not searched
 Possibilities include
  o USB key, floppy
  o Some types of files
  o New type of packer
  o Etc.
 Pretty   lame…
 Read   this paper:
 Do   the following:
  o Provide a summary of the paper
  o Pick one topic in the paper and discuss in
    some detail