Security Incidents mailing list archives

Re: Worm on 445/tcp?


From: Kyle Lai <aladin168 () hotmail com>
Date: 19 Dec 2002 21:06:28 -0000

In-Reply-To: <FC9A8983-1194-11D7-B8A8-000393C0D078 () xs4all net>

www.klcconsulting.net
www.kylelai.com

Now the Anti-Virus community started seeing the impact of port 445 
viruses, but port 445 virus/Trojans had attacked several times prior to 
this incident, and many times, the Trojans generated DDos attack 
zombies...  It's sad that it has to take another virus to generate the 
awareness...  Lioten worm / virus is just another proof that port 445 
virus and trojans can be very wild, dangerous and effective in compromise 
systems.  They are hard to control because many corporate and home users 
do not set strong passwords on their systems.

I am not sure what activities were on the log, but port 445 probing and 
attacks are not new at all.  You can see my Trojan Analysis on 
ocxdll.exe / taskmngr.exe (another port 445 mIRC Trojan that had swept the 
world several times) at 
http://www.klcconsulting.net/mIRC_Virus_Analysis.htm 

The SMB over TCP (port 445) Trojan I am familiar with are ocxdll.exe and 
its variants.  The first ocxdll.exe trojan came out around late August, 
2002, second wave was around middle to late October, 2002.  Each one of 
them infected a lot of systems around the world, and possibly tried to 
build a DDoS Zombies network for attacks.  Some of them were known to 
steal user account and password, and credit card info that saved on the 
computers.  Port 445 only effects Windows 2000 and XP, but what people 
don't really know is that when the a client is connecting to Windows 2000 
or XP shares (also Null Session), if port 445 is blocked on Windows 2000 
or XP, Windows tries port 139 as an alternate route.  If port 139 is 
blocked, then the SMB traffic can't get out.  This means port 445 and 139 
should be both blocked to effectively stop port 445 type of Trojans.  For 
more details on port 445, SMB over TCP, check 
http://ntsecurity.nu/papers/port445/

Regarding to ocxdll.exe (taskmngr.exe), Microsoft posted a knowledge base 
article (http://support.microsoft.com/default.aspx?scid=kb;en-us;Q328691) 
but failed to discuss the port 445 impacts.  I did expressed my concern to 
one of the Microsoft PSS Security Analyst, the department that released 
the KB article, but Microsoft and other anti-virus companies didn't seem 
to worry about the impact of that Trojan and port 445 activities…  The 
ocxdll.exe Trojan from late August, 2002 only guessed 4 administrator 
accounts and passwords because it only has 4 entries in the "password 
dictionary" file that was part of the Trojan, and yet it got into large 
number of corporate and home systems.  There have been several variants 
out since, and the variants, as well as the Lioten worm, have a lot more 
entries more entries in the “password dictionary”, which mean more systems 
with weak passwords will be compromised.  I believe that this is not the 
end of the port 445 types of viruses..., it may be just the beginning 
because these type of viruses were effective and there are still a lot of 
weak systems out there.

I have tracked several ocxdll.exe / taskmngr.exe variants from people that 
got infected (http://www.newbie.org/help/messages/2553.html), and I know 
this Trojan is still in the wild and infecting a lot of systems.

Many analysts mentioned removing Null session connections on Windows 2000 
and XP systems to solve this type of attacks, but they probably should put 
a Bigger Warning about testing the removal of  Null session before moving 
into the production environment.  Many corporations are not ready to 
unplug the Null sessions due to the mix of Windows OS platforms.

As we can see here, Port 445 viruses / Trojans / worms are wild, 
dangerous, and very effective in system compromises.  Not all port 445 
viruses are Lioten (Iraq oil) as you see; there are ocxdll.exe 
(taskmngr.exe) and others out there.  Hope the Windows 2000 and XP users 
can get the computer security message about harden their passwords, or get 
at least some message that someone could steal their credit card and 
personal info that's left on the computer if they don’t set hard-to-guess 
passwords on all their computer and web accounts.

I hope “Internet Security” is not an Oxymoron. 

/Kyle

Kyle Lai, CISSP, CISA 
KLC Consulting, Inc.
617-921-5410
klai () klcconsulting net
www.klcconsulting.net


Received: (qmail 5132 invoked from network); 17 Dec 2002 17:31:45 -0000
Received: from outgoing2.securityfocus.com (HELO 
outgoing.securityfocus.com) (205.206.231.26)
 by mail.securityfocus.com with SMTP; 17 Dec 2002 17:31:45 -0000
Received: from lists.securityfocus.com (lists.securityfocus.com 
[205.206.231.19])
      by outgoing.securityfocus.com (Postfix) with QMQP
      id 6E7488F2E5; Tue, 17 Dec 2002 09:10:57 -0700 (MST)
Mailing-List: contact incidents-help () securityfocus com; run by ezmlm
Precedence: bulk
List-Id: <incidents.list-id.securityfocus.com>
List-Post: <mailto:incidents () securityfocus com>
List-Help: <mailto:incidents-help () securityfocus com>
List-Unsubscribe: <mailto:incidents-unsubscribe () securityfocus com>
List-Subscribe: <mailto:incidents-subscribe () securityfocus com>
Delivered-To: mailing list incidents () securityfocus com
Delivered-To: moderator for incidents () securityfocus com
Received: (qmail 9387 invoked from network); 17 Dec 2002 07:31:29 -0000
Date: Tue, 17 Dec 2002 08:56:02 +0100
Mime-Version: 1.0 (Apple Message framework v548)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: Worm on 445/tcp?
From: Scott A.McIntyre <scott () xs4all net>
To: incidents () securityfocus com
Content-Transfer-Encoding: 7bit
Message-Id: <FC9A8983-1194-11D7-B8A8-000393C0D078 () xs4all net>
X-Mailer: Apple Mail (2.548)

Over the past two weeks or so I've been noticing a steady rise in what 
appears to be worm related traffic to the new unified smb over tcp port 
(445) on Microsoft Win2k and newer operating systems.

I haven't yet been able to properly identify what the culprit is; at 
first I thought a variation of OpaServ, and that hasn't been fully 
ruled out, but I'm not quite convinced of that either.  Anyone have any 
clues that might help pin this down further?

An infected machine seems to send the following:

1095 114.002629 src -> dst  SMB Negotiate Protocol Request
1105 114.363458 src -> dst  SMB Session Setup AndX Request
1106 114.774364 src -> dst  SMB Session Setup AndX Request
1107 115.168792 src -> dst  SMB Tree Connect AndX Request,Path: 
\\dst\IPC$
1110 115.330792 src -> dst  SMB NT Create AndX Request, Path: \samr
1112 115.652261 src -> dst  DCERPC Bind: call_id: 1 UUID: SAMR
1136 117.759036 src -> dst  SAMR Connect4 request
1137 118.299350 src -> dst  SMB Close Request, FID: 0x4000
1142 119.004483 src -> dst  SMB Logoff AndX Request
1150 119.375665 src -> dst  SMB Tree Disconnect Request

And another:

7.933416 src -> dst SMB Negotiate Protocol Request
10.958481 src -> dst SMB Session Setup AndX Request
13.654558 src -> dst SMB Tree Connect AndX Request, Path: \\dst\IPC$
13.926353 src -> dst SMB NT Create AndX Request, Path: \samr
15.231252 src -> dst DCERPC Bind: call_id: 1 UUID: SAMR
17.149345 src -> dst SAMR Connect4 request
20.405997 src -> dst SAMR EnumDomains request
23.579240 src -> dst SAMR LookupDomain request
25.341903 src -> dst SAMR OpenDomain request
25.891947 src -> dst SAMR EnumDomainUsers request
26.597393 src -> dst SAMR Close request
29.615040 src -> dst SMB Close Request, FID: 0x4000
30.048894 src -> dst SMB Logoff AndX Request
32.738878 src -> dst SMB Tree Disconnect Request


It appears as though there's a high degree of randomness to the 
destination IP addresses that are chosen by the worm as can be seen 
from this 1 second snapshot:


    121.33.1.48
  91.71.109.105
   76.123.46.27
  222.120.99.35
   124.72.254.8
  17.64.153.118
   27.23.33.121
  185.33.178.38
  151.49.213.31
  167.60.15.125
  132.86.243.68
  26.125.133.71
   1.104.130.21
   40.88.91.120
  48.101.140.21
    48.93.34.36
  193.60.220.48
   117.26.58.96
    27.2.15.114
    25.7.221.31


Note: the infected system's ip address is not within any of these 
network segments.

I've noticed others reporting similar increase in traffic, but so far 
haven't seen a definitive acknowledgment of precisely what it is that's 
responsible.

Any pointers gratefully accepted.




--------------------------------------------------------------------------
--
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management 
and tracking system please see: http://aris.securityfocus.com



----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management 
and tracking system please see: http://aris.securityfocus.com


Current thread: