第1页 / 共9页
第2页 / 共9页
第3页 / 共9页
第4页 / 共9页
第5页 / 共9页
第6页 / 共9页
第7页 / 共9页
第8页 / 共9页
毕业论文外文文献(外文).doc
Know Your Enemy: Worms at War
The Not so Friendly World of Cyberspace
Honeynet Project
http://www.honeynet.org
Last Modified: 9 November, 2000
This paper was born out of pure curiosity. Our Honeynet was being
pounded with UDP port 137 and TCP port 139 scans. The network was
getting scanned 5-10 times a day on these ports, something was
up. The goal was to learn what these scans were all about. What was
out
in the Internet causing all of this activity? Based on the ports, we
assumed that the scans were looking for Window's based
vulnerabilities. The plan was to setup a Win98 honeypot, sit back and
wait. We didn't have to wait long. A continuation of the Know Your
Enemy series.
The Setup
During a one month period (20 Sep - 20 Oct) we confirmed 524 unique
NetBoss scans on our Honeynet network. These scans consisted of UDP port
137 (NetBIOS Naming Service) probes, usually followed by TCP port 139
(NetBIOS Session Service). That is large number of scans probing for a
specific service, something was up, we decided to find out what. The Honeynet
network does not advertises itself to the Internet. We just put the systems on
our network and sit back and wait. That means that the majority of scans we
receive are random scans that are most likely probing most of the
Internet. These are the same threats your systems face. As these scans are
probing Windows based systems, they are most likely focusing on the common
homeowner with a DSL or Cable connection to their house. We are not
talking about corporate espionage or web defacing, we are talking about
simple homeowners as the target here. We were curious, who was doing
these scans, what was their purpose, and why the vast number of
scans? Was this a coordinated effort, were these worms? Lots of
questions. So, we decided to find out and added a Windows98 honeypot to
our collection. We did a default installation of Windows98 and enabled
sharing of the C: drive. A Windows98 honeypot may not sound glamorous,
however there are several things to be gained from setting up such a system.
1. Windows98 represent a huge number of systems connected to the
Internet, and this number is growing fast. Typically, these are the
systems with the weakest security, as homeowners are the ones using
these systems. What people do not realize is the risk these systems
are exposed to, as many of them have dedicated connections to the
Internet.
2. This was our first crack at a Microsoft based honeypot. The plan was
to start off simple and learn from there.
On October 31, the system was installed, sharing was enabled, and connected
to the Internet. We then sat back and waited, the wait was not long.
It found ours and began querying it.
If first began by getting the
The First Worm
Less then 24 hours later we received our first visitor. The system
216.191.92.10 (host-010.hsf.on.ca) scanned the network looking for Window
systems.
system name and determine if sharing was enabled. Once it determined that
sharing was enabled, it then probed for specific binaries on our system.
goal was to determine if a specific worm was installed, and if not, then it would
install itself.
In this case, the specific worm was not installed. The worm is
known as the " Win32.Bymer Worm ". The purpose of this worm is to take
advantage of your CPU cycles to help an individual win the distributed.net
contest. Distributed.net is group that uses the idle process of distributed
computers for various challenges (such as cracking RC5-64
challenge ). People are awarded prizes if the crack the challenge. The more
computers and CPU cycles you have under your control, the better of your
chances of winning.
installing the worm on our system.
In our case, someone "volunteered" us for the project by
Its
An individual (in this case, bymer@inec.kiev.ua ), created a self replicating
worm that would find vulnerable Window systems and install the distributed.net
client on unsuspecting systems. Once installed and executed, the worm
utilizes your CPU cycles in attempt to help the author win the
contest. Meanwhile the worm begins probing for other vulnerable systems it
can take over. The goal is to have access to as many computers and CPU
cycles as possible. This process grows exponentially as more systems are
compromised. Lets take a look at the attack using packet captures of the
network traffic (in this case, we used the IDS sniffer snort ). For more
advanced analysis of the NetBIOS protocol, you may want to use a protcol
analyzer, such as the free utility Ethereal. Throughout the sniffer traces below,
the system 172.16.1.105 is the IP address of the honeypot.
The worm begins by first checking to see if the file dnetc.ini is on the system. This is
the standard configuration file for the distributed.net client. This configuration file
tells the main server who should get credit for all the CPU cycles. This is also the
person that most likely created the worm. Here we see the packet trace where the
remote system (NetBIOS name GHUNT, account GHUNT, domain HSFOPROV)
copies the configuration file to our honeypot.
11/01-15:29:18.580895 216.191.92.10:2900 -> 172.16.1.105:139
TCP TTL:112 TOS:0x0 ID:50235 DF
*****PA* Seq: 0x 12930C 6 Ack: 0x66B7068 Win: 0x2185
00 00 00 5B FF 53 4D 42 2D 00 00 00 00 00 01 00 ...[.SMB-.......
00 00 00 00 00 00 00 00 00 00 00 00 00 C 8 57 1C ..............W.
00 00 82 D1 0F FF 00 00 00 07 00 91 00 16 00 20 ...............
00 DC 1C 00 3A 10 00 00 00 00 00 00 00 00 00 00 ....:...........
00 00 00 1A 00 5C 57 49 4E 44 4F 57 53 5C 53 59 ..... \WINDOWS\SY
53 54 45 4D 5C 64 6E 65 74 63 2E 69 6E 69 00
STEM\dnetc.ini .
Below we see the actual file transfer of the configuration file dnetc.ini . Notice who is the point
of contact for this, bymer@inec.kiev.ua . This is the individual that receives the credit for the
CPU cycles, and most likely the author of the worm attacking us.
11/01-15:29:18.729337 216.191.92.10:2900 -> 172.16.1.105:139
TCP TTL:112 TOS:0x0 ID:50747 DF
*****PA* Seq: 0x1293125 Ack: 0x66B70AD Win: 0x2140
00 00 01 11 FF 53 4D 42 0B 00 00 00 00 00 01 00 .....SMB........
00 00 00 00 00 00 00 00 00 00 00 00 00 C 8 57 1C ..............W.
00 00 02 D2 05 00 00 E1 00 00 00 00 00 E1 00 E4 ................
00 01 E1 00 5B 6D 69 73 63 5D 20 0D 0A 70 72 6F
....[misc] ..pro
6A 65 63 74 2D 70 72 69 6F 72 69 74 79 3D 4F 47 ject-priority=OG
52 2C 52 43 35 2C 43 53 43 2C 44 45 53 0D 0A 0D R,RC5,CSC,DES...
0A 5B 70 61 72 61 6D 65 74 65 72 73 5D 0D 0A 69 .[parameters].. i
64 3D 62 79 6D 65 72 40 69 6E 65 63 2E 6B 69 65 d=bymer@inec.kie
76 2E 75 61 0D 0A 0D 0A 5B 72 63 35 5D 0D 0A 66 v.ua ....[rc5]..f
65 74 63 68 2D 77 6F 72 6B 75 6E 69 74 2D 74 68 etch-workunit-th
72 65 73 68 6F 6C 64 3D 36 34 0D 0A 72 61 6E 64 reshold=64..rand
6F 6D 70 72 65 66 69 78 3D 32 31 37 0D 0A 0D 0A omprefix=217....
5B 6F 67 72 5D 0D 0A 66 65 74 63 68 2D 77 6F 72 [ogr]..fetch-wor
6B 75 6E 69 74 2D 74 68 72 65 73 68 6F 6C 64 3D kunit-threshold=
31 36 0D 0A 0D 0A 5B 74 72 69 67 67 65 72 73 5D 16....[triggers]
0D 0A 72 65 73 74 61 72 74 2D 6F 6E 2D 63 6F 6E ..restart-on-con
66 69 67 2D 66 69 6C 65 2D 63 68 61 6E 67 65 3D fig-file-change=
79 65 73 0D 0A
yes..
The next file to be transferred is the actual distributed.net client,
dnetc.exe . This is a valid executable, it is not malicious in nature. We
confirmed this by taking an MD5 signature of the client found on the honeypot.
We then downloaded the client from distributed.net and took an MD5 hash of
the dnetc.exe client. The MD5 hashes were identical (d0fd 1f 93913af70178bff
1a 1953f 5f 7d), indicating that this code is not the worm. This is the binary that
uses your CPU cycles as part of the distributed.net challenge. However, the
worm intends on using this binary without your permission nor knowledge, all
for the author's gain.
Ack: 0x66B 71C 0 Win: 0x202D
11/01-15:34:09.044822 216.191.92.10:2900 -> 172.16.1.105:139
TCP TTL:112 TOS:0x0 ID:33084 DF
*****PA* Seq: 0x 129341A
00 00 00 5B FF 53 4D 42 2D 00 00 00 00 00 01 00 ...[.SMB-.......
00 00 00 00 00 00 00 00 00 00 00 00 00 C 8 57 1C ..............W.
00 00 04 26 0F FF 00 00 00 07 00 91 00 16 00 20 ...&...........
00 FE 1D 00 3A 10 00 00 00 00 00 00 00 00 00 00 ....:...........
00 00 00 1A 00 5C 57 49 4E 44 4F 57 53 5C 53 59 ..... \WINDOWS\SY
53 54 45 4D 5C 64 6E 65 74 63 2E 65 78 65 00
STEM\dnetc.exe.
Next we see the actual worm being transferred, msi216.exe . This is the
self-replicating worm that randomly probes for vulnerable systems and copies
itself. This is the worm that is most likely causing a great number of the scans
we are receiving.
Ack: 0x 66C 248B Win: 0x20B2
11/01-15:37:23.083643 216.191.92.10:2900 -> 172.16.1.105:139
TCP TTL:112 TOS:0x0 ID:40765 DF
*****PA* Seq: 0x 12C 146A
00 00 00 5C FF 53 4D 42 2D 00 00 00 00 00 01 00 ...\.SMB-.......
00 00 00 00 00 00 00 00 00 00 00 00 00 C 8 57 1C ..............W.
00 00 02 F 3 0F FF 00 00 00 07 00 91 00 16 00 20 ...............
00 C 0 1E 00 3A 10 00 00 00 00 00 00 00 00 00 00 ....:...........
00 00 00 1B 00 5C 57 49 4E 44 4F 57 53 5C 53 59 ..... \WINDOWS\SY
53 54 45 4D 5C 6D 73 69 32 31 36 2E 65 78 65 00 STEM\msi216.exe .
Last, the worm first modifies then uploads a new win.ini file. The worm does
this so the system will execute the worm upon reboot. Remember, it can be
difficult to remotely execute a file on a Win98 system, so this is the worm's
method of getting it executed It does this by adding itself to the boot up
configuration file c:\windows\win.ini and has itself loaded during the boot
process. The new win.ini file is then uploaded to our compromised system.
11/01-15:38:55.352810 216.191.92.10:2900 -> 172.16.1.105:139
TCP TTL:112 TOS:0x0 ID:1342 DF
******A* Seq: 0x 12C 6F 55 Ack: 0x 66C 95FC Win: 0x1FBF
00 00 0B 68 FF 53 4D 42 1D 00 00 00 00 00 01 00 ...h.SMB........
00 00 00 00 00 00 00 00 00 00 00 00 00 C 8 57 1C ..............W.
00 00 02 F 9 0C 0D 00 61 19 00 00 00 00 00 00 00 .......a........
00 00 00 00 00 00 00 00 00 2C 0B 3C 00 2D 0B 00 .........,.<.-..
5B 77 69 6E 64 6F 77 73 5D 0D 0A 6C 6F 61 64 3D [windows].. load=
63 3A 5C 77 69 6E 64 6F 77 73 5C 73 79 73 74 65 c:\windows\syste
6D 5C 6D 73 69 32 31 36 2E 65 78 65 0D 0A 72 75 m\msi216.exe ..ru
6E 3D 0D 0A 4E 75 6C 6C 50 6F 72 74 3D 4E 6F 6E n=..NullPort=Non
65 0D 0A 0D 0A 5B 44 65 73 6B 74 6F 70 5D 0D 0A e....[Desktop]..
57 61 6C 6C 70 61 70 65 72 3D 28 4E 6F 6E 65 29 Wallpaper=(None)
0D 0A 54 69 6C 65 57 61 6C 6C 70 61 70 65 72 3D ..TileWallpaper=
31 0D 0A 57 61 6C 6C 70 61 70 65 72 53 74 79 6C 1..WallpaperStyl
65 3D 30 0D 0A 0D 0A 5B 69 6E 74 6C 5D 0D 0A 69 e=0....[intl]..i
That's it. The Worm is now complete and the honeypot has now been
infected. All that needs to happen now is the system to reboot and the Worm
will take effect. Once it takes effect, several things happen.
1. The distributed.net client begins, using the CPU cycles in the contest.
2. The Worm begins searching for other vulnerable systems to replicate
itself to. This is what is causing all the UDP 137 and TCP 139 scans.
3. The worm may add the following keys to the registry.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run\
Bymer.scanner
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunS
ervices\Bymer.scanner
One may think that having to wait for a system to reboot is an unreliable way to
execute. Keep in mind, the targets are Windows desktop systems. How
often do you reboot your Windows desktop?
The Second Worm
It is a busy week, and our second worm comes the next day. This worm is a
similar variation to the first worm, its purpose is to gain control of your CPU
cycles to help an individual in the distributed.net contest. The only difference
with this worm is that all the files are combined in one single executable,
wininit.exe . Default installations of Windows98 already have a binary
c:\windows\wininit.exe installed on their system. This worm calls itself the
same in an attempt to obscure itself, but installs itself in
c:\windows\system\wininit.exe .
across the binary, the author hopes they will assume it is part of the operating
system and not a worm. This is a very common tactic amongst the blackhat
community. Once executed, the worm acts just as the previous worm
does. Below we see our honeypot being infected with the second worm,
wininit.exe . The remote systems has the NetBIOS name WINDOW, account
WINDOW, domain LVCW.
If anyone should happen to stumble
Ack: 0xCE6736B Win: 0x2185
11/02-21:41:17.287743 216.234.204.69:2021 -> 172.16.1.105:139
TCP TTL:113 TOS:0x0 ID:38619 DF
*****PA* Seq: 0x21CC 0AC
00 00 00 5D FF 53 4D 42 2D 00 00 00 00 00 01 00 ...].SMB-.......
00 00 00 00 00 00 00 00 00 00 00 00 00 D0 4F 1F
00 00 84 EE 0F FF 00 00 00 07 00 91 00 16 00 20 ...............
00 20 BB 01 3A 10 00 00 00 00 00 00 00 00 00 00 . ..:...........
00 00 00 1C 00 5C 57 49 4E 44 4F 57 53 5C 53 59 ..... \WINDOWS\SY
53 54 45 4D 5C 77 69 6E 69 6E 69 74 2E 65 78 65 STEM\wininit.exe
00
..............O.
Once the worm has installed itself, the remote system then modifies the win.ini
file to ensure it is executed on reboot. Notice how this executable adds to the
already modified c:\windows\win.ini file, which has an entry from our
previous worm.
11/02-21:41:48.538643 216.234.204.69:2021 -> 172.16.1.105:139
TCP TTL:113 TOS:0x0 ID:21212 DF
******A* Seq: 0x 22021C 9 Ack: 0xCE68EC7 Win: 0x1FA3
00 00 0B 68 FF 53 4D 42 1D 00 00 00 00 00 01 00 ...h.SMB........
..............O.
00 00 00 00 00 00 00 00 00 00 00 00 00 D0 4F 1F
00 00 84 F 4 0C 0F 00 7F 19 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 2C 0B 3C 00 2D 0B 00 .........,.<.-..
5B 77 69 6E 64 6F 77 73 5D 0D 0A 6C 6F 61 64 3D [windows].. load=
63 3A 5C 77 69 6E 64 6F 77 73 5C 73 79 73 74 65 c:\windows\syste
6D 5C 77 69 6E 69 6E 69 74 2E 65 78 65 20 63 3A m\wininit.exe c:
5C 77 69 6E 64 6F 77 73 5C 73 79 73 74 65 6D 5C \windows\system\
6D 73 69 32 31 36 2E 65 78 65 0D 0A 72 75 6E 3D msi216.exe..run=
0D 0A 4E 75 6C 6C 50 6F 72 74 3D 4E 6F 6E 65 0D ..NullPort=None.
0A 0D 0A 5B 44 65 73 6B 74 6F 70 5D 0D 0A 57 61 ...[Desktop]..Wa
Upon reboot, this worm, like the previous one, will start up and begin the same
processes. The thing to keep in mind is that the remote systems attacking us
are most likely not evil blackhats out to own the world. More likely the remote
systems are innocent bystanders who were compromised. The owners have
no idea there is a worm running on their system, nor any idea their computers
are being used to scan for and exploit other vulnerable systems on the
Internet. However, their systems have dedicated connections to the Internet,
making them primary targets. Even systems that dial-up to the Internet are at
risk for such attacks. There is a 'war' going on as automated worms seek out
and compromise other systems. They then use these systems as launching
points to gain control of other systems, such as our honeypot.
The Day After
The next day, other variations of the same worm probed our honeypot. They first determine if
sharing is enabled, and if so, they check if the same version of the worm is already installed.
In
both cases for this day, the worm was already installed, so the remote systems left us alone. The
first remote system checked to see if the wininit.exe worm was installed. Later on that day,
another system checked to see if the worm msi216.exe was installed.
11/03-04:42:11.596636 210.111.145.180:2341 -> 172.16.1.105:139
TCP TTL:115 TOS:0x0 ID:12574 DF
*****PA* Seq: 0x 2345C 04 Ack: 0xE65CC94 Win: 0x2171
00 00 00 5D FF 53 4D 42 2D 00 00 00 00 00 01 00 ...].SMB-.......
00 00 00 00 00 00 00 00 00 00 00 00 00 D8 B5 1D ................
00 00 81 3E 0F FF 00 00 00 07 00 91 00 16 00 20 ...>...........
00 3A 26 02 3A 10 00 00 00 00 00 00 00 00 00 00 .:&.:...........
00 00 00 1C 00 5C 57 49 4E 44 4F 57 53 5C 53 59 ..... \WINDOWS\SY
53 54 45 4D 5C 77 69 6E 69 6E 69 74 2E 65 78 65 STEM\wininit.exe
00
.
Remote system, NetBIOS name MATTHEW, account MPYLE, domain MPYLE
The fun beings the following day, on November 04th. First,
it begins with the system
207.224.254.206 (dialupF206.sttl.uswest.net, NetBIOS name SOCCERDOG, account SCOTT,
domain RONS) checking to see if dnetc.ini is installed on our honeynet. It determines that the
binary is already installed and leaves the honeypot allone. That makes a total of 5 system probing
our honeypot for this worm in 3 days. Later on that day our honeypot initiates a http connection
to the system bymer.boom.ru. This connection was most likely initiated by the worm and is
attempting to update the master server. The system bymer.boom.ru was most likely at one time
the master controller for this worm. However, the system name bymer.boom.ru now resolves to
an RFC 1918 IP address, 192.168.0.1. Most likely an attempt by the domain owner to stop the
worm. Also, for the worm to execute like this, the system would need to have been rebooted at
some time. That is the one thing we have not figured out, if the system was rebooted, and if so,
how. One of the drawbacks of a Windows based honeypot
is the limited availability of
information, due to nonexistent logs.
Below we see the honeypot initiating a connection to
bymer.boom.ru, most likely the master server for the worm.
11/04-23:56:38.855453 172.16.1.105:1027 -> 192.168.0.1:80
TCP TTL:127 TOS:0x0 ID:65300 DF
**S***** Seq: 0x17AF8D 9A
TCP Options => MSS: 1460 NOP NOP SackOK
Ack: 0x0 Win: 0x2000
Immediately following this the dnetc.exe client connects to the distributed.net
server and begins a data transfer. This is part of the the distributed.net client
and not part of the worm replication process. However, this is the end
purpose of the worm, to burn CPU cycles and upload the results to
distributed.net.
11/04-23:56:40.286898 172.16.1.105:1029 -> 204.152.186.139:2064
TCP TTL:127 TOS:0x0 ID:1301 DF
*****PA* Seq: 0x17AF 8F 47 Ack: 0xBE445ED3 Win: 0x2238
AE 23 E2 77 F 6 42 91 51 3E 61 3F EE 86 7F EE 8B .#.w.B.Q>a?.....
CE 9E 9D 28 16 BD 4B C5 5E DB FA 62 A 6 FA A8 FF ...(..K.^..b....
EF 19 57 9C 37 38 06 39 7F 56 B4 D 6 C 7 75 63 73 ..W.78.9.V...ucs
0F 94 12 10 57 B 2 C 0 AD 9F D1 6F 4A E 7 F 0 1D E7 ....W.....oJ....
30 0E CC 84 78 2D 7B 21 C 0 4C 29 BE 08 6A D8 5B 0...x-{!.L)..j.[
50 89 86 F 8 98 A 8 35 95 E 0 C 6 E4 32 28 E5 92 CF P.....5....2(...
71 04 41 6C B9 22 F 0 09 01 41 9E A6 49 60 4D 43 q.Al."...A..I`MC
91 7E FB E0 D9 9D AA 7D 21 BC 59 1A 69 DB 07 B7 .~.....}!.Y.i...
B 1 F 9 B6 54 FA 18 64 F 1 42 37 13 8E 8A 55 C 2 2B ...T..d.B7...U.+
CF 32 45 19 1A 93 1F 65 62 B1 CE 02 AA D0 7C 9E .2E....eb.....|.
C5 46 78 29 F 0 13 97 04
.Fx)....
Once the upload is complete, the worm kicks into high gear and begins
searching the Internet for other vulnerable system to replicate and spread itself.
It randomly selects IP addresses and begins scanning those systems on ports
137 and 139. The worm identifies vulnerable systems (similar to our honeypot)
and the replicates itself to the remote system. Compromised systems like
these are one of the reasons for the high number of scans we have
seen.
Keep in mind, the Honeynet environment is designed to block any
malicious traffic initiated by a compromised honeypot, so these scans never
reach the Internet. The Honeynet is kind of like the 'roach motel'.
It lets the
bad guys in, but won't let them out. Below you see the worm attempting to
find other vulnerable systems.
11/04-23:58:05.946299 172.16.1.105:137 -> 39.202.248.187:137
UDP TTL:127 TOS:0x0 ID:30485
Len: 58
0E 94 00 10 00 01 00 00 00 00 00 00 20 43 4B 41 ............ CKA
41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
41 41 41 41 41 41 41 41 41 41 41 41 41 00 00 21 AAAAAAAAAAAAA..!
00 01
相关推荐
2023年江西萍乡中考道德与法治真题及答案.doc
2012年重庆南川中考生物真题及答案.doc
2013年江西师范大学地理学综合及文艺理论基础考研真题.doc
2020年四川甘孜小升初语文真题及答案I卷.doc
2020年注册岩土工程师专业基础考试真题及答案.doc
2023-2024学年福建省厦门市九年级上学期数学月考试题及答案.doc
2021-2022学年辽宁省沈阳市大东区九年级上学期语文期末试题及答案.doc
2022-2023学年北京东城区初三第一学期物理期末试卷及答案.doc
2018上半年江西教师资格初中地理学科知识与教学能力真题及答案.doc
2012年河北国家公务员申论考试真题及答案-省级.doc
2020-2021学年江苏省扬州市江都区邵樊片九年级上学期数学第一次质量检测试题及答案.doc
2022下半年黑龙江教师资格证中学综合素质真题及答案.doc
