-----BEGIN PGP SIGNED MESSAGE----- __________________________________________________________ The U.S. Department of Energy Computer Incident Advisory Capability ___ __ __ _ ___ / | /_\ / \___ __|__ / \ \___ __________________________________________________________ TECHNICAL BULLETIN Operation of the Sinit/Calypso Worm Nov. 15, 2004 20:00 GMT Number CIACTech05-001 ______________________________________________________________________________ PROBLEM: Large numbers of udp packets are being detected directed at port 53 (DNS) on random systems. PLATFORM: Any Windows platform. ABSTRACT: Many sites have detected large numbers of udp packets directed at the DNS port (53). These packets contain a lot of structure and there is concern that they are exploit or remote control packets. It turns out that they are “discovery” packets being sent to random IP addresses by the Sinit/Calypso worm. They are invalid DNS packets and should be ignored by DNS servers. ______________________________________________________________________________ LINKS: CIAC BULLETIN: http://www.ciac.org/ciac/techbull/CIACTech05-001.shtml OTHER LINKS: http://www.lurhq.com/sinit.html SINIT writeups: http://www.securiteam.com/securityreviews/6J0022A95E.html ______________________________________________________________________________ Many sites have noticed a large number of udp packets targeting the DNS port (53) on apparently random IP addresses. The packets are invalid DNS packets and are generally ignored by the DNS system. The packets themselves are not random and have a definite structure. Security managers were worrying that they might be associated with some sort of an attack so we investigated the source of these packets. We have since determined that the packets are from the Sinit or Calypso worm and are not a risk in themselves. The packets are udp packets like that shown below (tcpdump output). You can easily see the structure as the packet body is broken into 6 byte blocks. The contents of the packets were unknown and some speculated that they were commands for some kind of a backdoor or BackOrifice like remote control program. 10/20-07:40:01.718339 0:60:3E:D:C0:40 -> 0:B:FC:D5:86:4A type:0x800 len:0x198xxx.xxx.xxx.xxx:19487 -> yyy.yyy.yyy.yyy:53 UDP TTL:112 TOS:0x0 ID:8148 IpLen:20 DgmLen:394 Len: 366 01 02 00 07 D1 86 3F C3 26 14 01 3B 44 0F FB 90 ......?.&..;D... 35 00 D1 2C 91 F0 35 00 D8 57 49 F4 35 00 D1 C0 5..,..5..WI.5... CA A4 35 00 D5 19 FE 84 35 00 C3 29 07 B6 35 00 ..5.....5..)..5. 41 45 69 6D 35 00 40 3B D3 DB 35 00 44 77 D8 E4 AEim5.@;..5.Dw.. 35 00 D3 13 A1 68 35 00 40 73 8C 68 35 00 3D 0B 5....h5.@s.h5.=. 1A 8E 35 00 D0 39 2C CB 35 00 43 56 64 B6 35 00 ..5..9,.5.CVd.5. C3 29 07 D1 35 00 C1 FB 14 0C 35 00 3E A8 77 44 .)..5.....5.>.wD If you align the data portion of the packets in 6 byte blocks you can easily see the structure. 01 02 00 07 D1 86 3F C3 26 14 01 3B 44 0F FB 90 35 00 D1 2C 91 F0 35 00 D8 57 49 F4 35 00 D1 C0 CA A4 35 00 D5 19 FE 84 35 00 C3 29 07 B6 35 00 41 45 69 6D 35 00 40 3B D3 DB 35 00 44 77 D8 E4 35 00 D3 13 A1 68 35 00 40 73 8C 68 35 00 3D 0B 1A 8E 35 00 D0 39 2C CB 35 00 43 56 64 B6 35 00 C3 29 07 D1 35 00 C1 FB 14 0C 35 00 3E A8 77 44 ... Another thing we noticed is that the first 10 bytes of the data portion of the packets were identical across all the samples we had. This made it possible to create a snort signature that we could use to alert on these packets to get an idea how widespread the problem was. alert udp any any -> any 53 (msg:"CIAC Odd DNS"; content: "|01 02 00 07 D1 86 3F C3 26 14|"; sid:4000013; rev:1; ) The table below shows packet counts for a little over two days at 14 different sites. If you normalize the data to the number of IP addresses owned by the sites, the data becomes a constant, indicitative of a random process. For example, site 2 has about 6 class B networks, site 3 has 1, site 5 has 2, site 6 has 1, sites 8 and 9 have 4 each. These are very rough numbers but they show that the scanning process appears very random. Site Nov. 1 Nov. 2 Nov. 3 Total Hits 1 129 1570 1393 3092 2 549 6181 5581 12311 3 74 1101 890 2065 4 3 31 25 59 5 348 2243 2092 4683 6 108 1601 1363 3072 7 1 21 19 41 8 437 4814 4441 9692 9 397 4848 4446 9691 10 81 2042 1841 3964 11 1 12 8 21 12 0 9 6 15 13 0 1 1 2 14 8 2091 2196 4295 After a lot of searching and questioning colleagues around the net, we were able to determine that these packets were caused by systems infected with the Sinit worm. A very good writeup on the operation of this worm is at, http://www.lurhq.com/sinit.html A lot of the material contained in this report comes from this article. A P2P Worm ========== Many of the recent worms and viruses have the capability to phone home after an infection to get new or updated software to install. A drawback the virus writers noticed right away was that it was easy to figure out where home was and to block it. Even when a worm checked an intermediate site to get a list of homes to go visit, those intermediate sites were also easy to block. The sinit worm gets around that problem by not having any home or intermediate sites to go to. Instead it operates in a strictly peer to peer fashion. After an infection, the worm starts sending udp packets to port 53 on random IP addresses. Most likely it uses port 53 to hide these packets among normal DNS traffic. The packets have a hex 0x01 as the first data byte. Other systems infected with this worm listen to port 53 and when they see port 53 traffic with a 0x01 as the first byte they send back a udp packet to the sender with a 0x05 as the first byte, telling the sender that he has found another infected system. If the sender or replier knows about other infected systems he includes the addresses of those systems in the udp packets. Thus the structure in the packets we were seeing were an IP address followed by a port number and a null byte for a total of 4 + 1 + 1 = 6 bytes as shown below. 01 02 00 07 D1 86 3F C3 26 14 01 53 C1 3A C3 04 35 00 C3 9A 1E 97 35 00 = 195.154.30.151 port 53 C8 29 2A A3 35 00 = 200.41.42.163 port 53 D8 67 4A DE 35 00 = 216.103.74.222 port 53 ... According to the securiteam article, there are 6 different types of udp packets controlled by the first byte of the data portion of the packet. First Byte Description (hex) 0x01 This is a discovery packet, searching for other infected systems. 0x02 This is a status packet used with file transfers. 0x03 This packet is part of a file transfer 0x04 This is a file request packet to request a file from another system. 0x05 This is a discovery response packet to tell the sender he has found an infected system. 0x06 This signals the end of a file transfer. When an infected system finds another infected system, they compare their software versions. If a system finds that it has a newer version of the worm software, it sends its software to the other system. It apparently uses a cryptographic signature to authenticate the software so only software approved by the author is installed. If that were not the case, you could create a new version that would spread for a while and then die, eliminating the worm. The worm also implements a simple web server on port 53 and on a random, high numbered port that can serve up one file named kx.exe. Running the following command against an infected system will usually get you a copy of kd.exe which is just the executable version of the worm. wget http:///kx.exe Using this method, we were able to capture several copies of the worm for analysis. There are several versions of the worm on the net. Some are compressed with the upx utility and others use Aspack. The executables on the system install in the \Windows\System32 folder as svcinit.exe or svcpack.exe. They add a value to the Winlogin registry key to restart the worm whenever Windows is started. Key: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogin Value: userinit=C:\winnt\system32\userinit.exe, C:\winnt\system32\svcpack.exe Note that the worm adds only the second value (svcpack.exe) to the key. The first one (userinit.exe) is normal. In most cases, the worm can be eliminated by running the task manager and killing the svcinit or svcpack process, finding and deleting the worm files, and removing the value from the run registry key. It also created the key, Key: HKLM\software\Microsoft\Direct Plugin Value: EngineName=C:\winnt\system32\DirectPlugin.installed There is no file in the system32 directory, so we do not know what that is for. We have also seen it try to turn on autodial but there was no modem on the tested system. Removing Sinit ============== Removing sinit is actually very easy as it does not try to hide. Start the task manager and find the worm process. It will be either svcinit or svcpack, the names of the installed files. Kill that process, find and delete the files, and remove the value from the registry. When editing the registry, be sure to remove only the second half of the value (after the comma) as the first half is required. _____________________________________________________________________________ CIAC wishes to thank Roger Suppona and Jim Hutchins for helping to unravel this mystery. _____________________________________________________________________________ CIAC, the Computer Incident Advisory Capability, is the computer security incident response team for the U.S. Department of Energy (DOE) and the emergency backup response team for the National Institutes of Health (NIH). CIAC is located at the Lawrence Livermore National Laboratory in Livermore, California. CIAC is also a founding member of FIRST, the Forum of Incident Response and Security Teams, a global organization established to foster cooperation and coordination among computer security teams worldwide. CIAC services are available to DOE, DOE contractors, and the NIH. CIAC can be contacted at: Voice: +1 925-422-8193 (7x24) FAX: +1 925-423-8002 STU-III: +1 925-423-2604 E-mail: ciac@ciac.org Previous CIAC notices, anti-virus software, and other information are available from the CIAC Computer Security Archive. World Wide Web: http://www.ciac.org/ Anonymous FTP: ftp.ciac.org PLEASE NOTE: Many users outside of the DOE, ESnet, and NIH computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Your agency's team will coordinate with CIAC. The Forum of Incident Response and Security Teams (FIRST) is a world-wide organization. A list of FIRST member organizations and their constituencies can be obtained via WWW at http://www.first.org/. This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or the University of California, and shall not be used for advertising or product endorsement purposes. LAST 10 CIAC BULLETINS ISSUED (Previous bulletins available from CIAC) P-191: KDE Image File Format Reader Vulnerabilities P-192: OpenOffice.org Buffer Overflow Vulnerability P-193: Mozilla Security Bugs P-194: Buffer Overflow in “sharutils” P-195: CVS Vulnerabilities P-196: HP OpenView Radia Management Portal and Agent Vulnerability P-197: PHP Security Bugs P-198: HP OpenView Network Node Manager (OV NNM) Remote Unauthorized Privileged Code Execution, Denial of Service (DoS) P-199: HP OpenView Event Correlation Services (OV ECS) Remote Unauthorized Privileged Code Execution, Denial of Service (DoS) P-200: Apple Security Update 2005-005 -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQCVAwUBQnk7oLnzJzdsy3QZAQEJLwQArW6P+dQol3bZoGQv850boNrIBZdqrWiU GUOLJ3qNBeXmshdkcQCQn/UWxNkw90ivyHuyHgLSYg6P8L1AYZxaEonCpG1qOrnL 3cMg9nJmamjGd6jEcGIeJwLqE7kJrxTs3jIxRsWWS35wkkD45Qv4WLeC4NTClZcS KUTWOIOSMew= =ymBE -----END PGP SIGNATURE-----