Re: CRIME FW: @Stake pulls pin on Geer: Effect on research and pu blication (fwd)

From: Duane Nickull (duane@private)
Date: Mon Oct 06 2003 - 18:16:32 PDT

  • Next message: Crispin Cowan: "Re: CRIME FW: @Stake pulls pin on Geer: Effect on research and pu blication (fwd)"

    While this is possible, I would argue that it is illogical to write a 
    virus that way.  Given the level of sophistication (IP aware, able to 
    scan and block other ports, able to run as a process un-detected by the 
    O/S and existing AV software etc.) the beachhead code would require, I 
    do not see the advantage to a two stage attack.  In fact, it would be a 
    poor architecture for no or little benefit.
    
    Like any military attack, a two stage attack with a rest in between 
    gives the enemy (Victim) a chance to re-group and fight back.
    
    I would advocate an architecture of blitzkrieg (lightening war for those 
    not familiar with German).  Speed is an asset.  Infect as many as 
    possible in as little time as possible.  
    
    The only benefit I could see is if there is a chance infiltrate a system 
    with a sole purpose to determine it's ability to be infected.  If it is 
    ascertained that the victims system cold be easily infected, then an 
    activation to pull the malicious code in could be made (a simple 
    algorythm could determine this).  If the system was detected to be too 
    strong to infect, yet a chance existed to propogate the beachhead code 
    to other machines, then the virus would appear to jump nodes making it 
    harder for AV software to track.
    
    I once came up with an idea of such a system using a combination of 
    Bhezium theorum, Chaos theorum and AI.  A process could be fed a set of 
    instructions making it essentially a sentient (yet virtual) being able 
    to make decisions based on a set of logic and it's environmental 
    surroundings.  In effect, it could determine that full infection is too 
    risky, yet mimic the other processes running on a machine by morphing 
    its' own process name to trick the users into thinking it was a 
    benevolent process.  By posing as another application, an advanced 
    virus-entity could trick the user into giving it usernames and passwords 
    to gain privileges to do other things like open pipes to import new 
    code, communicate with other instantiations of itself etc.  Such a 
    system could even screen scrape and mimic other systems???
    
    The key would be to give the code a base DNA with a cryptographic key 
    that it can use to morph its' signature.  That would allow 
    instantiations of it to recognize each other while thwarting AV 
    signature detection algorythms.
    
    Such a virus would certainly re-define the way humans think about 
    fighting malicious code.   Hopefully no one is thinking (or working) on 
    something like this yet.
    
    Anyone ever thought of how to fight such an animal?
    
    Duane Nickull
    ******************
    Editor, Co-Chair - ebXML Technical Architecture
    Project Team Lead - United Nations CEFACT eBusiness Architecture
    http://www.yellowdragonsoft.com
    ******************
    
    
    Crispin Cowan wrote:
    
    >>>
    >> In this case, the injector portion that comes by through the exploit 
    >> tells
    >> the machine to download the more complete virus.  When that download
    >> happens, we detect the file coming down, and block it.  And thus the 
    >> machine
    >> does not get infected.
    >>
    >> However, a stub of code sits at that RPC vulnerability.  But it 
    >> believes it
    >> has satisfied its job and just sleeps.
    >>
    > Interesting. So staged worms that first hack a small beachhead and 
    > then download the rest of the rootkit can be blocked by AV. To bypass 
    > this, the beachhead has to be sophisticated enough to disable AV 
    > before hitting the file system, which is difficult, and probably not 
    > portable across AV defenses.
    >
    > Crispin
    >
    



    This archive was generated by hypermail 2b30 : Mon Oct 06 2003 - 18:49:39 PDT