OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Russ (Russ.CooperRC.ON.CA)
Date: Mon Aug 13 2001 - 13:46:29 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    -----BEGIN PGP SIGNED MESSAGE-----

    Russ - if you post this, please do not identify my company. Thanks.
    (RC:one of many Fortune 1000 reports I've received)

    Last week, we spent a fair amount of effort combating the effects of
    Code Red and Code Red II. Here is a brief discussion of what we
    found.

    Background:

    We operate a global network with in excess of 300 sites. Officially
    supported Windows NT and 2000 servers are located at nearly all
    sites. We also have Extranet segments (separated from both the
    Public Internet and our internal network by firewalls) and a server
    attached to the public network.

    In July and on August 1, we saw some difficulties with our public
    Internet connectivity due to excessive traffic. We believe this was
    related to Code Red. None of our internal servers, extranet servers,
    nor our external server was affected directly. We added
    configurations to our firewalls to prevent this traffic from causing
    issues.

    To deal with the threat, we had taken two actions:

    1. Packaged and applied the Windows 2000 hotfix to most production
    servers. We also removed the mappings for the .ida and .idq
    extensions.
    2. Investigated our NT 4 servers and identified the very few with the
    .ida and .idq mappings. Instructed the people responsible to remove
    the mappings ASAP while we tested the NT 4 hotfix.

    Detection:

    On August 8 we began having problems with our extranet firewalls
    again. A few machines were generating a large number of failed TCP
    connection attempts, which bogged down the firewalls. An analysis of
    the logs indicated that this time the traffic was coming from inside
    our private network. We discovered that the machines involved were
    running Windows 2000.

    We ran a script to examine the IIS logs from all of our supported
    servers, and identified 12 IP addresses that were definitely sources
    of attack. Of these, only one was an officially supported server,
    which had been missed when we applied patches. It was running Code
    Red II. The majority of the other machines involved belonged to
    contractors, or were installed by other organizations than the ones
    in charge of running Windows servers.

    Infection:

    When we examined the IIS logs, we discovered that the earliest
    internal attacks came from addresses associated with our VPN
    connection for remote workers. 4 separate attacks were registered
    from this address range. It seems likely that this was the infection
    vector. We were able to identify the users based on date, time, and
    IP address and found they did indeed have IIS 5 installed. We took
    steps to make sure their machines could not be re-infected.

    Key Lessons:

    1. Despite taking all necessary action on our firewalls, servers on
    our extranet, and servers exposed to the public Internet, we were
    still vulnerable through our VPN.
    2. Despite the fact that 99.97% of our production supported servers
    were immune, we were still vulnerable - primarily through
    non-supported servers and workstations.
    3. Only 12 - 14 computers were actually infected; however, this
    caused severe problems with our firewalls.

    -----BEGIN PGP SIGNATURE-----
    Version: PGP Personal Privacy 6.5.2

    iQCVAwUBO3gghRBh2Kw/l7p5AQEevgP6A+ikfA2BRXAwdAq9USDvCGQC8Zxl4AkV
    DR/tsuv994ku076Be8Az32WbsDzrkak+PlMOxzE+TcvB06kbE/zlob3mUwWIKOZs
    LD/kWLXU5YEiym9tOrSP3WbmcbzkiBaelM89FbX1IcgE6W61Eim6aBkEOiuUbrge
    3tObe8sxumY=
    =jCgJ
    -----END PGP SIGNATURE-----

    ============================================================================
    Delivery co-sponsored by Trend Micro, Inc.
    ============================================================================
    TREND MICRO SCANMAIL FOR EXCHANGE 2000 -- SECOND to NONE

    If you are worried about email viruses, you need Trend Micro ScanMail for
    Exchange. ScanMail is the first antivirus solution that seamlessly
    integrates with the Microsoft Exchange 2000 virus-scanning API 2.0. ScanMail
    ensures 100% inbound and outbound email virus scanning and provides remote
    software management. Download a FREE 30-day trial copy of ScanMail and find
    out why it is the best:
    http://www.antivirus.com/banners/tracking.asp?si=8&BI;=240&UL;=/smex2000
    ============================================================================