RE: Opaserv Variant?

-See below

-----Original Message-----

From: cridley [mailto:cridley@drtel.net] Sent: Wednesday, November 20, 2002 5:47 PM To: focus-virus@securityfocus.com
Subject: Opaserv Variant?

Have found the following scenario on 7 client machines at two different small companies. Machines are Win98/XP.

Also, noticed the existence of two wininit.exe files, one in WINDOWS, one in WINDOWS/SYSTEM. The one in WINDOWS/SYSTEM was larger (65KB vs 41 KB) & created more recently than the one in WINDOWS. After comparing it to other 'normal' machines, I removed the files in WINDOWS/SYSTEM. Not sure if this plays into this scenario, but it is WININIT.EXE that makes and invokes the changes to WIN.INI, etc during software installs, config changes, etc.

-I don't believe WININIT.INI makes changes directly to WIN.INI. Normally,
it just copies, deletes, and renames files on the PC's next reboot. I also don't believe it works in XP...I think WININIT.INI modifications only work in 9x systems, but not on NT/2000 systems. NT/2000 systems use the registry to initiate changes on reboot. The WININIT.INI file may be present on NT/2000 systems from malicious placement, but it won't interact with WININIT.EXE to do anything.

A day later - off the network - but on dial up, Norton catches the same bug again in files Brasil, Marco.scr. It occurs when closing IE or disconnecting the dialup connection. Norton deletes files, clean again. Back on inet via dialup, same happens.
-Make sure machines are fully patched and that drive shares are
password-protected.

An interesting item is that
although Norton deletes the files, the tell tale entries to WIN.INI are already made and causes an error on reboot that Windows cannot find the specified file brasil.pif, etc.
-Not unusual.

Though there was no particular site that it occurred at, noticed something interesting in netstat, that after Norton detected the virus, the client had an nbsession to ip 66.130.9.147:1302, a cable modem address via Videotron, in Montreal CA.
-Your client apparently doesn't have a firewall, personal or otherwise. A
firewall should be installed to prevent ports 137-139 from going out of or into the LAN from the Internet.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

There is no reason any of these machines should have a session open to 66.130.9.147, it is not a web server, etc. Port scan shows only port 110 open on this address. Scanned clients for spyware, etc - clean. File sharing is enabled on the machines, but with password protection.
-Check out all the articles on the way XP does default file sharing. Not
pretty and not very secure.

I can accept that the ip address could be a server for Opaserv, but I am at a loss as to how these machines keep getting reinfected and what is initiating these client sessions with the ip 66.130.9.147 and the significance, if any, of port 1302. I found some ref to ReverServerApp on this port (a program that listens for incoming client connections), iana.org lists it as being assigned to ci3-software, a specialty software developer.

-Get a TCP/IP port enumerator so you can tie the program or process to the
port traffic. There are dozens of them on the Internet for NT and beyond machines (lots of them don't work on 98 machines). Goto www.winternals.com and download their "TCPViewer" program. Excellent port enumerator. You can use XP's netstat with the command line switch (I forget off the top of my head) to show the process id (PID) that you can then use the task manager to tie together to the malicious program.
-IANA port list general is not relevant for any uncommon port...i.e. it is
not unusual to have many programs share the same port numbers, reserved or not. IANA is a great starting point for port research, but it rarely really helps in most malicious code searches.

-Roger A. Grimes
Received on Tue Nov 26 12:32:04 2002