COMMAND

    CodeRed worm

SYSTEMS AFFECTED

    Those with IIS unpatched

PROBLEM

    There are many reports of  a new worm going around  which purports
    to  abuse  the  vulnerability  discussed  in  MS01-033,  a  buffer
    overflow in Microsoft Index Server.  Some reports have it  causing
    web services  (http/ftp/smtp) to  stop and  restart, while  others
    state there's a defacement and  then the "worm" launches from  the
    afflicted IIS machine  and out in  search of other  vulnerable IIS
    boxes.

    The signature:

        /default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a

    is likely to be  found in your IIS  logs or IDS systems.   You can
    also run a NETSTAT on the box and look for:

        216.99.52.100

    in the list of sites connected to by your system.

    Remember, this worm cares not whether the box its attacking is  an
    IIS box or  a router.   Reports on SecurityFocus'  Bugtraq mailing
    list indicate  that some  routers are  experiencing problems  when
    sent the worm attack string.

    Further,  reports  Russ  Cooper  have  received  as  well  as some
    personal  experience  with  infected  machines (not mine) suggests
    that  the  worm  may  not  be  effective  against  IIS  4.0 boxes.
    Instead, when  the URL  is received  the web  services stop.   Its
    reasonable to assume that the  very small shellcode it uses  might
    not work properly across all vulnerable platforms.  So if you  are
    experiencing web services stopping repeatedly, its likely  because
    of the worm.

    The  following  Cisco  products  are  vulnerable  because they run
    affected versions of Microsoft IIS:
        * Cisco CallManager
        * Cisco Unity Server
        * Cisco uOne
        * Cisco ICS7750
        * Cisco Building Broadband Service Manager

    Other Cisco products may also  be adversely affected by the  "Code
    Red" worm.

    Other  Cisco  products  may  be  indirectly  affected  by  the IIS
    vulnerability (this is not an exhaustive list):
    * Cisco 600 series of DSL  routers that have not been patched  per
      the Cisco Security Advisory,

        http://www.cisco.com/warp/public/707/CBOS-multiple.shtml

      will stop forwarding traffic  when scanned by a  system infected
      by the "Code  Red" worm.   The power must  be cycled to  restore
      normal service.

    * Cisco Network Management products are not directly affected  but
      might be installed on a Microsoft platform running a  vulnerable
      version of IIS.

    The "Code Red"  worm exploits a  known vulnerability in  Microsoft
    IIS  by  passing  a  specially  crafted  URI  to  the default HTTP
    service, port 80,  on a susceptible  system.  The  URI consists of
    binary instructions which cause the infected host to either  begin
    scanning other random  IP addresses and  pass the infection  on to
    any  other  vulnerable  systems  it  finds,  or launch a denial of
    service attack  targeted at  the IP  address 198.137.240.91  which
    until very recently was  assigned to www.whitehouse.gov.   In both
    cases the worm replaces the  web server's default web page  with a
    defaced page at the time of initial infection.

    The worm does  not check for  pre-existing infection, so  that any
    given system may be executing as  many copies of the worm as  have
    scanned  it,  with  a  compounding  effect  on  system and network
    demand.

    As a side-effect, the URI used  by the worm to infect other  hosts
    causes Cisco 600 series DSL routers to stop forwarding traffic  by
    triggering a previously-published  vulnerability.  Any  600 series
    routers scanned  by the  "Code Red"  worm will  not resume  normal
    service until the power to the router has been cycled.

    The nature of  the "Code Red"  worm's scan of  random IP addresses
    and the resulting sharp increase in network traffic can noticeably
    affect Cisco  Content Service  Switches and  Cisco routers running
    IOS, depending  on the  device and  its configuration.   Unusually
    high CPU utilization and memory starvation may occur.

    Marc Maiffret from eEye provided following is a  detailed analysis
    of the "Code Red"  .ida worm that was  reported on July 17th 2001.
    This analysis was performed by Ryan Permeh and Marc Maiffret.  The
    disassembly (complete with comments)  was done  by Ryan "Shellcode
    Ninja" Permeh.

    On Friday July 13th eEye received packet logs and information from
    2 network administrators that  were experiencing large amounts  of
    attacks targeting the recent .ida vulnerability that eEye  Digital
    Security discovered on  June 18, 2001.   After reviewing the  logs
    sent to them they determined  that in fact someone had  released a
    worm into the Internet that was spreading rapidly through IIS  web
    servers.

    The  full  analysis  of  the  .ida  "Code  Red"  worm has provided
    numerous  new  details  as  to  the  functionality  and  method of
    propagation  of  this  worm.  For  instance  this  worms   purpose
    ultimately  seems  to  be  to  perform  a denial of service attack
    against www.whitehouse.gov.  Also it  has been found that only  US
    English Windows NT/2000 systems will show the defaced ("Hacked  by
    Chinese !") web page.

    As stated earlier the .ida "Code Red" worm is spreading throughout
    IIS  web  servers  on  the  Internet  via the .ida buffer overflow
    attack that was published weeks ago.  The following are the  steps
    that the worm takes once it has infected a vulnerable web server.

    1. Setup initial worm environment on infected system.
    2. Setup a 100 threads of the worm
    3. The first 99 threads are used to spread the worm (infect  other
       web servers).

       The worm  spreads itself  by creating  a sequence  of random IP
       addresses.  However, the  worm's randomization of IP  addresses
       to attack is  not all together  random. In fact  there seems to
       be a  static seed  that the  worm uses  when generating  new IP
       addresses to try to attack.  Therefore every computer  infected
       by this worm is going to go through the same list of random  IP
       addresses to try  to infect.   The "problem" with  that is that
       the worm is  going to end  up reinfecting systems  and also end
       up crossing  traffic back  and forth  between hosts  to end  up
       creating a denial of service type affect because of the  amount
       of data that will be  transferred between all the IP  addresses
       in the sequence  of random IP  addresses.  The  worm could have
       done truly random IP generation and that would have allowed  it
       to infect a  lot more systems  a lot faster.   We are not  sure
       why  that  was  not  done  but  a  friend  of  ours did pose an
       interesting idea... If the person who wrote this worm owned  an
       IP address that was one of the first hundred or thousand etc...
       to be scanned then they  could setup a sniffer and  anytime and
       IP address  tried to  connect to  port 80  on their  IP address
       they would know that the IP address that connected to them  was
       infected with  the worm  and they  would therefore  be able  to
       create a list of the majority of systems that were infected  by
       this worm.

    4. The 100th thread  checks to see if  it is running on  a English
       (US) Windows NT/2000 system.

       If the  infected system  is found  to be  a English (US) system
       then  the  worm  will  proceed  to  deface the infected systems
       website.  That means... the local web servers web page will  be
       changed to a message that says Welcome to http://www.worm.com!,
       Hacked By  Chinese!.   This hacked  web page  message will stay
       "live" on the  web server for  10 hours and  then disappear and
       never appear  again unless  the infected  system is re-infected
       by another host.

       If the system is not a English (US) Windows NT/2000 system then
       the 100th worm thread is also used to infect other systems.

    5. Each worm thread checks for c:\notworm
       -If the file c:\notworm is found, the worm goes dormant.
       -If the  file is  not found  then each  thread will continue to
        attempt to infect more systems.

    6. Each worm  thread will now  check the infected  computers time.
       If the time is  between 20:00 UTC and  23:59 UTC then the  worm
       will proceed to use  this thread to attack  www.whitehouse.gov.
       The attack consists of  the infected system sending  100k bytes
       of data to port 80 of www.whitehouse.gov therefore  potentially
       performing    a    denial    of    service    attack    against
       www.whitehouse.gov.

       If the time is below 20:00  UTC then this worm thread will  try
       to find and infect new web servers.

    In  testing  eEye  have  calculated  that  the worm can attempt to
    infect roughly half a  million IP addresses a  day and that was  a
    ruff estimate made from using a very slow network.

    As of writing this document (July 18 6:49pm) eEye have had reports
    from  administrators  that  have  been  probed by over 12 thousand
    unique hosts.   That basically  means at  least 12  thousand hosts
    have been infected by this worm.

    In  testing  eEye  have  seen  that  sometimes  the  worm does not
    execute correctly  and will  continue to  spawn new  threads until
    the infected machine crashes and has to be rebooted.

    The following  is a  very detailed  analysis of  what the  worm is
    doing  at  each  step  of  its  infection.  Full  disassembled and
    commented worm code is available at eEye website at:

        http://www.eeye.com/html/advisories/codered.zip

    1. Initial infection vector (i.e.  host is vulnerable to the  .ida
       attack and gets hit with this worm).

       The initial infection starts to  take place when a web  server,
       vulnerable to the .ida attack,  is hit with a HTTP  get request
       that contains  the necessary  code to  exploit the  .ida attack
       and uses this worm as its payload.

       At the time  of the .ida  overflow a systems  stack memory will
       look like the following:

        <MORE 4E 00>
        4E 00 4E 00 4E 00 4E 00
        4E 00 4E 00 4E 00 4E 00
        4E 00 4E 00 4E 00 4E 00
        92 90 58 68 4E 00 4E 00
        4E 00 4E 00 4E 00 4E 00
        FA 00 00 00 90 90 58 68
        D3 CB 01 78 90 90 58 68
        D3 CB 01 78 90 90 58 68
        D3 CB 01 78 90 90 90 90
        90 81 C3 00 03 00 00 8B
        1B 53 FF 53 78

       EIP  is  overwritten  with  0x7801CBD3  which an address within
       msvcrt.dll.  The code at 0x7801CBD3 disassembles to:

        call ebx

       When EIP is  overwritten with call  ebx it then  causes program
       flow to divert back to the stack.  The code on the stack  jumps
       into the worm code that's held in the body of the initial  HTTP
       request.

    2. Sets up some initial stack variables

        CODEREF: seg000:000001D6 WORM

       At this point  we are executing  the initial code  of the worm.
       The first thing to happen is that the worm sets up a new  stack
       for its own use.  The new stack is 218h bytes, filled with CCh.
       The worm  code then  moves on  to initialize  its function jump
       table.

       The entire worm heavily uses  an EBP stack based memory  offset
       system.  This means that all variables are referenced as  EBP-X
       values.  On our website we have a document called  worm-ebp.txt
       that attempts  to track  stack usage  throughout the  course of
       the worm code.

    3. Load functions (create the "jump table")

        CODEREF: seg000:00000203 DataSetup

       The  first  thing  the  worm  code  does  is reference the data
       portion of the exploit code  at EBP-198h.  The worm  then needs
       to setup  its internal  function jump  table.   A function jump
       table is a stack based table used to store function  addresses.
       It allows the  worm to generate  the function addresses  at run
       time (This  makes the  worm have  a better  chance of executing
       cleanly on more systems).

       The  technique  used  by  this  worm  is  what is called an RVA
       (Relative  Virtual  Addresses)  lookup.   Basically  this means
       that all functions,  or specifically GetProcAddress,  are found
       within IIS itself.  For more details on RVA please consult  any
       good PE  (Portable Executable,  the executable  file format for
       Microsoft  platforms)  documentation,   or  read  through   the
       assembly code of this worm.

       In a nutshell,  RVA techniques are  used to get  the address of
       GetProcAddress.   GetProcAddress  is  then  used  to  get   the
       address  of  LoadLibraryA.   Between  these  two  functions all
       other functions  that the  worm may  need can  be easily found.
       The  worm  uses  these  two  functions  to  load  the following
       functions:

        >From kernel32.dll:
         GetSystemTime
         CreateThread
         CreateFileA
         Sleep
         GetSystemDefaultLangID
         VirtualProtect
        >From infocomm.dll:
         TcpSockSend
        >From WS2_32.dll:
         socket
         connect
         send
         recv
         closesocket

       Finally the worm stores the base address of w3svc.dll which  it
       will later use to potentially deface the infected website.

    4. Check the number of threads the worm has created.

        CODEREF: seg000:00000512 FUNC_LOAD_DONE

       Here  the  worm  seems  to  perform  a WriteClient (Part of the
       ISAPI Extension API), sending "GET" back to the attacking worm.
       This possibly could  be a way  of telling attacking  worms that
       they have successfully infected a new host.

       Next  the  worm  code  will  count  the  number of worm threads
       already  in  action.   If  the  number  of  threads is 100 then
       control is shifted to the Worm hack web page functionality.

       If the number of threads is  below 100 then the worm creates  a
       new thread.  Each  new thread is an  exact replica of the  worm
       (Using the same code base).

       The worm now continues its path of execution.

    6. Checks for the existence of c:\notworm

        CODEREF: seg000:0000079D DO_THE_WORK

       There seems  to be  a to  be built  in "lysine deficiency" (See
       Jurassic Park, or Caesar's  paper on this at  www.rootkit.com).
       A "lysine  deficiency" is  a built  in check  to keep malicious
       code from spreading further.

       In  this  case  the  "lysine  deficiency"  is  a  check for the
       existence of  the file  c:\notworm.   If this  file exists then
       the worm will become dormant.   This means it will not  attempt
       to make connections out to other IP addresses to try to infect.

       If this file  does not exist  then the worm  continues onto the
       next step.

    7. Check the infected systems time (computer clock)

        CODEREF: seg000:00000803 NOTWORM_NO

       The worm  will now  check the  infected systems  local time (in
       UTC).   If the  hour is  greater then  20:00 UTC  then the worm
       will  proceed   to  goto   the  first   step  of   the   attack
       www.whitehouse.gov functionality.

       If the time is less than  20:00 UTC then the worm will  attempt
       to continue to try to infect new systems.

    8. Infect a new host (send  .ida worm to a "random" IP  address on
       port 80).

       At this point the worm  will resend itself to any  IP addresses
       which it can connect to port 80 on.  It uses multiple  send()'s
       so  packet  traffic  may  be   broken  up.   On  a   successful
       completion of send, it closes the socket and goes to step  6...
       therefore repeating this loop infinitely.

    Worm hack webpage functionality is called after a hundred  threads
    are spawned within the worm.

    1. Check if local system default language is English us then  goto
       step 6 of core worm functionality.

        CODEREF: seg000:000005FE TOO_MANY_THREADS

       The first thing  the worm does  is get the  local codepage.   A
       codepage specifies  the local  operating system  language (I.E.
       English (US), Chinese,  German etc...).   It then compares  the
       local  codepage  against  0x409.   0x409  is  the  codepage for
       English (US)  systems.   If the  infected system  is an English
       (US) system  then the  worm will  proceed to  deface the  local
       systems webpage.   If the  local codepage  is not  English (US)
       then  this  worm  thread  will   goto  step  6  of  core   worm
       functionality.

    2. Sleep for 2 hours.

        CODEREF: seg000:00000636 IS_AMERICAN

       This worm thread  now sleeps for  2 hours.   We anticipate that
       this is to  allow the other  worm threads to  attempt to spread
       the infection before making  a presence known via  defacing the
       infected systems webpage.

    3. Attempt to modify infected systems webpages in memory.

        CODEREF: seg000:0000064F HACK_PAGE

       This worm  uses an  interesting technique  called "hooking"  to
       effectively  deface  (alter)  an  infected  systems   webpages.
       Hooking is modifying code in  memory to point to code  that the
       worm provides.   In this case  the worm is  modifying w3svc.dll
       to  change   the  normal   operation  of   a  function   called
       TcpSockSend.  TcpSockSend is  what w3svc.dll (IIS core  engine)
       uses to  send information  back to  the client.   By  modifying
       this, the  worm is  able to  change data  being written back to
       clients who request web pages of an infected server.

       To perform hooking, first the worm makes the first 4000h  bytes
       of  w3svc.dll's  memory  writable.   In  a normal situation the
       memory  for  w3svc.dll  (and  basically  all  mapped  dll's) is
       read-only.  It uses  the function VirtualProtect to  change the
       memory of w3svc.dll to be  writable, saving the old state  to a
       stack variable.

       It then uses  the saved codebase  of w3svc.dll (from  step 3 of
       core worm functionality) as a start point to search the  import
       table (again see  PE header documentation)  for the address  of
       TcpSockSend.  Once the  address for TcpSockSend is  located the
       worm  then  replaces  TcpSockSend's  actual  address  with   an
       address within the worm.

       The address that TcpSockSend now points to is a function within
       the worm that will  return the  "Hacked by  Chinese !" webpage.
       The  CODEREF    for    this   function    is    seg000:00000C9A
       FAKE_TCPSOCKSEND.

       This thread of the worm now sleeps for 10 hours. During this 10
       hours all web requests to the  infected server  will return the
       "Hacked by chinese !" webpage.

       After the 10 hours is up  this thread  will return w3svc.dll to
       its original state, including re-protecting memory.

       Execution  after  this  proceeds  to  step  6  of the core worm
       functionality.

    Sooner or later  every thread within  the worm seems  to shift its
    attacking focus to www.whitehouse.gov.

    1. create socket and connect to www.whitehouse.gov on port 80  and
       send 100k byes of data

        CODEREF: seg000:000008AD WHITEHOUSE_SOCKET_SETUP

       Initially  the  worm  will  create  a  socket  and  connect  to
       198.137.240.91   (www.whitehouse.gov/www1.whitehouse.gov)    on
       port 80.

        CODEREF: seg000:0000092F WHITEHOUSE_SOCKET_SEND

    If this connection is made then  the worm will create a loop  that
    performs 18000h single byte send()'s to www.whitehouse.gov.

        CODEREF: seg000:00000972 WHITEHOUSE_SLEEP_LOOP

    After 18000h send()'s the worm will  sleep for about 4 and a  half
    hours.  It will then repeat the attack against  www.whitehouse.gov
    (goto step one of Attack www.whitehouse.gov functionality).

    It  looks  like  there's  two  sets  of  worms  out there.  One is
    scanning large  contiguous netblocks  in an  obvious fashion,  the
    other is hunting and pecking about random IP addresses.

    In following text, we will be refering to the original "Code  Red"
    worm as CRv1  and the second  generation "Code Red"  worm as CRv2.
    This does  not preclude  further generations/varioations  still in
    the wild, it is just an analysis of the worms we have access to.

    This information is not currently public.  Well, sort of is  (eEye
    published the disassembly of CRv1,  so CRv1 targeting info may  be
    known), but  the existance  of CRv2  with different  targeting has
    not been verified until now as far as we know.

    The CRv2 worm has the following charecteristics: second:milisecond
    randomness added to ip selection process removal of web page  hack
    display (no notice to the end users via a defaced page).

    All  other  parts  of  the  worm  are  the  same.  (still  attacks
    whitehouse.gov (but the IP address has been blackholed), has  time
    limits/definitions of attack, notworm lysine).

    The  worst  part  about  this  means  that  our  original tracking
    methodology  (sensors  early  in   the  sequence)  is  no   longer
    accurate, since CRv2  infected hosts do  not contact early  hosts,
    nor  reliably  contact  any  point  (other  than the blackholed IP
    address that  use to  point to  whitehouse.gov).   This means that
    potentially ALL(ie:  global,  coprehensive) ids/logs data must  be
    organized and sorted to find infected hosts.

    It  has  13  or  so  pertient  bytes  changed, adding a time based
    randomness factor  and disabling  page defacement.   The code  had
    been there all  along.  It  had intentially (we  must assume) been
    disabled  in  CRv1,  then  reenabled  near  the  end of the cycle.
    There has been discussion that  this was a natural progression  of
    the worm code, however, we do not beleive this is the case.   From
    analsysis of CRv1, there seems to be no distinct way to shift  the
    nessecary bytes to generate CRv2.  Hence, it is guess that this is
    a modified worm,  rereleased.  It  has been posited  that the CRv1
    was a  target aqusition  mechanism, gathering  data on  infectable
    hosts  to  gain  a  high  initital  base  for  the  following CRv2
    infection.

    The second difference between CRv1 and CRv2 is that CRv2 does  not
    deface the webpage of an infected system.  It does this by  having
    12 bytes different from CRv1.

    When TcpSockSend is hooked(this  still happens), CRv2 points  this
    to a  basic redirect  that performs  harmless actions  and returns
    without  actually  changing  any   content.  Crv1  pointed  to   a
    replacement, CRv2 points to basically a donothing function.

    What is happeinging is that the label "PADDING_BYTES" actually  is
    padding bytes in  CRv1(the code does  not disassemble to  any sane
    code).

    CRv2  fufills  numerous  questions  that  we  had noticed in early
    analysis of  CRv1, such  as the  nessecity of  the self  modifying
    code in CRv1.  Although CRv1  did modify it's own code, it  didn't
    ever  really  touch  the  modified  code,  CRv2  makes use of this
    feature to implement the bypass.

    Both worm have a timeline like this (day of the month):

        1-19: infect other hosts using the worm
        20-27: attack whitehouse.gov forever
        28-end of month: eternal sleep

    To download CodeRed Scanner go to:

        http://www.eeye.com/html/Research/Tools/codered.html

    This worm is  killing JetDirect cards.   The HP JetDirect  Card on
    HP LaserJet 4000N  will steadily crash  as infection attempts  hit
    it; the result  is that, every  ten to thirty  minutes or so,  the
    printer itself crashes, dumping a page of exception data from  the
    card and freezing with an "EIO 2 ERROR" message.  A hard reset  of
    the printer is required to make it operational again.

    Similar  printer  problems  are  seen  with  Xerox  Docuprint  N32
    printers.  It appears to be yet another example of a badly-written
    embedded web server.

    3Com lanmodems, single channel are affected by this as well.

    Remember, each host can  be infected multiple times,  meaning that
    a single host can send 410MB * # of infections.

    The CAIDA folks  have posted an  extensive analysis of  the spread
    of the code.red worm.  These  are the same folks that brought  you
    the  "backscatter"  analysis  of  world-wide  DOS  attacks.    The
    infection rate was astounding, they have IP addresses for  375,000
    infected hosts, which is a *lower* bound on the infection.   There
    are graphs that  show the change  in infection rate  when CRv2 was
    released,  as  well  some  amazing  animations.   At one point the
    infection rate was at least 2000 hosts per minute.

        http://www.caida.org/analysis/security/code-red/

SOLUTION

    Do make sure you have patched your systems:

        http://oliver.efri.hr/~crv/security/bugs/NT/iis103.html
        http://oliver.efri.hr/~crv/security/bugs/NT/iis104.html

    Cisco is providing the same patch at

        http://www.cisco.com/cgi-bin/Software/Tablebuild/doftp.pl?ftpfile=cisco/voice/callmgr/win-IIS-SecurityUpdate-2.exe&swtype=FCS&code=&size=246296

    with documentation at

        http://www.cisco.com/cgi-bin/Software/Tablebuild/doftp.pl?ftpfile=cisco/voice/callmgr/win-IIS-SecurityUpdate-Readme-2.htm&swtype=FCS&code=&size=4541

    Cisco Building Broadband Service Manager is documented  separately
    at

        http://www.cisco.com/univercd/cc/td/doc/product/aggr/bbsm/bbsm50/urgent.htm

    The most effective way of stopping the worm instantly is to remove
    the mappings  for .ida  and rebooting  the box.  I'm working  on a
    scriptable way to remove the mappings (help would be appreciated).
    MetaEdit isn't runnable from a command line, so some other  method
    is required to modify the Metabase.

    Placing the C:\NOTWORM  file (any file  called NOTWORM should  do)
    will  stop  the  worm  processing,  but  this  won't  prevent your
    machine from stopping the web services or being infected by  other
    worm attacks.

    Applying the MS01-033 patch is equally important because the  .ida
    and  .idq  mappings  may  be  re-instated  if  you  add  or remove
    programs associated with IIS.

    If you think you have the patch applied, re-apply it and reboot at
    the first opportunity, just to be sure.  You can also double-check
    the details  of IDQ.DLL  to ensure  its 5.0.2195.3645  or above on
    W2K, 5.0.1781.3 on NT 4.0.  Whatever you do don't rely on anything
    that  simply  looks  in  the  \WINNT  directory  for  an uninstall
    directory  or  the  registry,  neither  of  these  methods provide
    complete assurance the right version is in place.