Be advised that windowsupdate.com may be acting slowly.
We have historically filtered most of these ports into our system
although this does not prevent the spread from an inside
compromised host.
Taking a quick look, UM hosts I see as possibly infected currently
sourcing scans on port 135. There are probably many more.
Admins responsible for the machines, please repair them.
See notes below - check for Mblast.exe running as a process.
130.111.8.49
130.111.74.61
130.111.73.94
130.111.73.35
130.111.69.113
130.111.50.42
130.111.226.149
130.111.223.80
130.111.204.76
130.111.164.62
130.111.164.208
130.111.155.172
130.111.147.22
130.111.146.82
130.111.145.112
130.111.133.121
130.111.131.27
130.111.12.40
130.111.105.130
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> CERT Advisory CA-2003-20 W32/Blaster worm
>
> Original issue date: August 11, 2003
> Last revised: --
> Source: CERT/CC
>
> A complete revision history is at the end of this file.
>
> Systems Affected
>
> * Microsoft Windows NT 4.0
> * Microsoft Windows 2000
> * Microsoft Windows XP
> * Microsoft Windows Server 2003
>
> Overview
>
> The CERT/CC is receiving reports of widespread activity related
> to a new piece of malicious code known as W32/Blaster. This worm
> appears to exploit known vulnerabilities in the Microsoft Remote
> Procedure Call (RPC) Interface.
>
> I. Description
>
> The W32/Blaster worm exploits a vulnerability in Microsoft's DCOM
> RPC interface as described in VU#568148 and CA-2003-16. Upon
> successful execution, the worm attempts to retrieve a copy
> of the file msblast.exe from the compromising host. Once this
> file is retrieved, the compromised system then runs it and
> begins scanning for other vulnerable systems to compromise in the
> same manner. In the course of propagation, a TCP session to port
> 135 is used to execute the attack. However, access to TCP ports
> 139 and 445 may also provide attack vectors and should be
> considered when applying mitigation strategies. Microsoft has
> published information about this vulnerability in Microsoft
> Security Bulletin MS03-026.
>
> Lab testing has confirmed that the worm includes the ability to
> launch a TCP SYN flood denial-of-service attack against
> windowsupdate.com. We are investigating the conditions under
> which this attack might manifest itself. Unusual or
> unexpected traffic to windowsupdate.com may indicate an infection
> on your network, so you may wish to monitor network traffic.
>
> Sites that do not use windowsupdate.com to manage patches may wish
> to block outbound traffic to windowsupdate.com. In practice, this
> may be difficult to achieve, since windowsupdate.com may not
> resolve to the same address every time. Correctly
> blocking traffic to windowsupdate.com will require detailed
> understanding of your network routing architecture, system
> management needs, and name resolution environment. You should not
> block traffic to windowsupdate.com without a thorough understanding
> of your operational needs.
>
> We have been in contact with Microsoft regarding this possibility
> of this denial-of-service attack.
>
> II. Impact
>
> A remote attacker could exploit these vulnerabilities to
> execute arbitrary code with Local System privileges or
> to cause a denial-of-service condition.
>
> III. Solutions
>
> Apply patches
>
> All users are encouraged to apply the patches referred to in
> Microsoft Security Bulletin MS03-026 as soon as possible in
> order to mitigate the vulnerability described in VU#568148.
> These patches are also available via Microsoft's Windows Update
> service.
>
> Systems running Windows 2000 may still be vulnerable to at
> least a denial-of-service attack via VU#326746 if their DCOM RPC
> service is available via the network. Therefore, sites are
> encouraged to use the packet filtering tips below in addition
> to applying the patches supplied in MS03-026.
>
> It has been reported that some affected machines are not able to
> stay connected to the network long enough to download
> patches from Microsoft. For hosts in this situation, the
> CERT/CC recommends the following:
> 1. Physically disconnecting the system from the network
> 2. Check the system for signs of compromise.
> + In most cases, an infection will be indicated by the
> presence
> of the registry key
> "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVers
> ion \Run\windows auto update" with a value of
> msblast.exe. If this key is present, remove it using a
> registry editor.
> 3. If you're infected, terminate the running copy of
> msblast.exe
> using the Task Manager.
> 4. Take one of the following steps to protect against the
> compromise
> prior to installing the Microsoft patch:
> + Disable DCOM as described below
> + Enabling Microsoft's Internet Connection Filter (ICF),
> or
> another host-level packet filtering program to block
> incoming connections for 135/tcp
> 5. Reconnect the system to the network and apply the patches in
> the
> recommended manner
>
> Trend Micro, Inc. has published a set of steps to accomplish
> these goals. Symantec has also published a set of steps to
> accomplish these goals.
>
> Disable DCOM
>
> Depending on site requirements, you may wish to disable DCOM
> as described in MS03-026. Disabling DCOM will help protect
> against this vulnerability but may also cause undesirable side
> effects. Additional details on disabling DCOM and possible side
> effects are available in Microsoft Knowledge Base Article 825750.
>
> Filter network traffic
>
> Sites are encouraged to block network access to the following
> relevant ports at network borders. This can minimize the
> potential of denial-of-service attacks originating from outside
> the perimeter. The specific services that should be blocked include
> * 69/UDP
> * 135/TCP
> * 135/UDP
> * 139/TCP
> * 139/UDP
> * 445/TCP
> * 445/UDP
> * 4444/TCP
>
> Sites should consider blocking both inbound and outbound traffic
> to these ports, depending on network requirements, at the
> host and network level. Microsoft's Internet Connection Firewall
> can be used to accomplish these goals.
>
> If access cannot be blocked for all external hosts, the
> CERT/CC recommends limiting access to only those hosts that
> require it for normal operation. As a general rule, the CERT/CC
> recommends filtering all types of network traffic that are
> not required for normal operation.
>
> Because current exploits for VU#568148 create a backdoor, which is
> in some cases 4444/TCP, blocking inbound TCP sessions to ports on
> which no legitimate services are provided may limit intruder
> access to compromised hosts.
>
> Recovering from a system compromise
>
> If you believe a system under your administrative control has
> been compromised, please follow the steps outlined in
>
> Steps for Recovering from a UNIX or NT System Compromise
>
> Reporting
>
> The CERT/CC is tracking activity related to this worm as
> CERT#30479. Relevant artifacts or activity can be sent to
> [log in to unmask] with the appropriate CERT# in the subject line.
>
> Appendix A. Vendor Information
>
> This appendix contains information provided by vendors. When
> vendors report new information, this section is updated and the
> changes are noted in the revision history. If a vendor is not
> listed below, we have not received their comments.
>
> Microsoft
>
> Please see Microsoft Security Bulletin MS03-026.
>
> Appendix B. References
>
> * CERT/CC Advisory CA-2003-19 -
> http://www.cert.org/advisories/CA-2003-19.html
> * CERT/CC Vulnerability Note VU#561284 -
> http://www.kb.cert.org/vuls/id/561284
> * CERT/CC Vulnerability Note VU#326746 -
> http://www.kb.cert.org/vuls/id/326746
> * Microsoft Security Bulletin MS03-026 -
> http://microsoft.com/technet/security/bulletin/MS03-026.asp
> * Microsoft Knowledge Base article 823980
> -
> http://support.microsoft.com?kbid=823980
>
> Thanks
>
> Our thanks to Microsoft Corporation for their review of and input
> to this advisory.
> ___________________________________________________________________
> ___
>
> Authors: Chad Dougherty, Jeffrey Havrilla, Shawn Hernan, and
> Marty Lindner
> ___________________________________________________________________
> ___
>
> This document is available from:
> http://www.cert.org/advisories/CA-2003-20.html
> ___________________________________________________________________
> ___
>
> CERT/CC Contact Information
>
> Email: [log in to unmask]
> Phone: +1 412-268-7090 (24-hour hotline)
> Fax: +1 412-268-6989
> Postal address:
> CERT Coordination Center
> Software Engineering Institute
> Carnegie Mellon University
> Pittsburgh PA 15213-3890
> U.S.A.
>
> CERT/CC personnel answer the hotline 08:00-17:00 EST(GMT-5)
> / EDT(GMT-4) Monday through Friday; they are on call for
> emergencies during other hours, on U.S. holidays, and on weekends.
>
> Using encryption
>
> We strongly urge you to encrypt sensitive information sent by
> email. Our public PGP key is available from
> http://www.cert.org/CERT_PGP.key
>
> If you prefer to use DES, please call the CERT hotline for
> more information.
>
> Getting security information
>
> CERT publications and other security information are available
> from our web site http://www.cert.org/
>
> To subscribe to the CERT mailing list for advisories and
> bulletins, send email to [log in to unmask] Please include in
> the body of your message
>
> subscribe cert-advisory
>
> * "CERT" and "CERT Coordination Center" are registered in the
> U.S. Patent and Trademark Office.
> ___________________________________________________________________
> ___
>
> NO WARRANTY
> Any material furnished by Carnegie Mellon University and the
> Software Engineering Institute is furnished on an "as is"
> basis. Carnegie Mellon University makes no warranties of any kind,
> either expressed or implied as to any matter including, but not
> limited to, warranty of fitness for a particular purpose or
> merchantability, exclusivity or results obtained from use of the
> material. Carnegie Mellon University does not make any warranty
> of any kind with respect to freedom from patent, trademark, or
> copyright infringement.
> ___________________________________________________________________
> ___
>
> Conditions for use, disclaimers, and sponsorship information
>
> Copyright 2003 Carnegie Mellon University.
>
> Revision History
>
> August 11, 2003: Initial release
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 6.5.8
>
> iQCVAwUBPzhJFGjtSoHZUTs5AQEO6wP5AZuyr1OG/U9RjZDAAatFmJUuTO8SFhtd
> R+nfZ54ylZPGE8ewMiS0hiuKaaXsOyk46R+zcwuPfoKffaaQX7SvwkS5uVzRBU+E
> PEnECSv6O8qL0uGR6BO8zmDncOhd8YouyXWGwMCRqpvH4rMHLRB8CIgKHyEoqBpl
> r69lGr8lqtE=
> =3GAW
> -----END PGP SIGNATURE-----
>
> ----------------------------------------------------------------------
> -- To unsubscribe from netsec, send mail to [log in to unmask] with a
> body consisting of the words "unsubscribe netsec" -- without the
> quotes. For more help, send a message to [log in to unmask] with the
> word "help" as the body.
> ----------------------------------------------------------------------
> --
>
Garry Peirce [log in to unmask] 1-207-581-3539
============================================
== Network Analyst
== UNET Technology Services, Network Operations
== University of Maine System
============================================
|
