This is the area for research on the "Iraq Oil" worm being
directed by myNetWatchman,
and it's where I'm parking the things I find. Collaborators are Lawrence
Baldwin, Philip Sloss, and Steve Friedl me.
We believe that Lawrence's advisory was the first public announcement
of the details of this worm, and it shows the benefits of distributed
intelligence-gathering such as provided by myNetWatchman.
More detailed analysis of the packet behavior and distribution of
this worm can be found in the
NetWatchman Research Alert, and it was first released publicly in the
Reports Security Forum.
There are a few "holes" in the C++ code when I simply ran out of available
time to reverse engineer this worm. It's unlikely that I'll pick up on it
much beyond what's here now. This page first went up Sunday night, 15 Dec 2002
(MD5: 6fe6ce9373d784bcc5f65ab5cee39010) -- original binary
that is UPX compressed: this was the file that was captured over the
net. 16,896 bytes (renamed from .EXE to .BIN to avoid self-execute
NOTE: file removed, contact me by email if you need it.
(MD5: 345a5df8919fefd52053711535bf8c31) -- the worm binary after
uncompressing. 40,960 bytes (also renamed from .EXE to .BIN).
NOTE: file removed, contact me by email if you need it.
- iraqworm.cpp -- C++ pseudocode from my
An important note on the pseudocode in iraqworm.cpp: only the standard library
functions have standard names, the rest are all made up by S. Friedl. And
the code is not designed to compile or *exactly* match the actual code -
it's meant to mainly convey the purpose without getting bogged down in
details. We're using C++ just for some of the "better C" features.
I'll release my IDA Pro .idb file of the binary once I get
my work mostly finished.
- The worm as captured was UPX compressed, but was unpacked
for analysis. The disassembled version has no references to any
kind of compression.
- This worm doesn't appear to talk to the registry or the
local filesystem in any way.
- The binary itself doesn't provide any clues as to its origin
or of why the name "iraq_oil.exe" was chosen.
- The code uses the rand() function to generate IP addresses,
but it does so badly: this function returns values 0..0x7FFF, so
the IP addresses are random only to 30 bits. But because of host/net
word order differences, the 0x7F byte is in IP address octets 2 and 4.
This suggests, and Philip Sloss's packet captures confirm, that if the
second or fourth octet of your IP address is in the range 128..255,
you'll not see any scans from this worm: it turns out that my IP network
at home ( 64.170.X.X ) immune.
- The code seems to make no provisions for skippin obviously
bogus IP addresses, such as 0-dot-anything or 255-dot-somthing. It
seems that it could even trip across address 127.0.0.1 and would
therefore infect itself. It's dumb.
- There are 100 threads spawned that do attacks and there is
no provision for stopping, shutdown, or avoiding
other similar worms being installed on the same host. There is no
sunset provision where it stops propogating after a certain date.
- The attack code first tries to do a connect() to the
target's port 445/tcp, and it waits up to five seconds for
it to complete. If it does, then the more in-depth probing
using the Win32 "Net" functions is attempted. This is clever in that
the "Net" functions don't seem to provide this level of timeout control,
so the worm can bang through address ranges much more quickly without
getting hung by machines that aren't around.
- The code does have some bugs, where the wrong sizes of
buffers are declared and the like, but I don't see any obvious
ways to exploit them. There is at least one memory leak. In
general, the code is written poorly.
- The executable ("iraq_oil.exe" in our captures) is statically
bound to three DLLS:
KERNEL32.DLL, MPR.dll, and WSOCK32.DLL,
and it uses LoadLibrary to load NETAPI32.DLL
- This worm is almost certainly limited to the NT-based
Windows systems (Win2000, XP) and not the personal systems
(95/98/ME). This is because the ADMIN$ and C$ shares are not
typically present on the personal systems, and they also do not
support the "at" task scheduler protocol the same way. It would
not be a surprise if this only infected servers. I
believe that NT4 doesn't expose 445/tcp.
Rough program flow
The details can be found in the disassembly, but this is the broad
flow of the program:
- Do a bit of initialization, including loading NETAPI32.DLL
- Launch 100 worker threads, and the main thread sleeps forever
- Worker thread generates a random, 32-bit IP address
- Attempts a connect() to 445/tcp, waiting up to five seconds
- If no connection, it moves onto the next one
- If a connection was made, it tries to make an anonymous connection
to the IPC$ share point on the target machine, via the \\ipaddress\IPC$
resource. It's done with an anonymous connection.
If this anonymous connection is made, it enumerates every user and
attempts to brute-force each one with a small (and odd) set of built-in
passwords. Passwords are attempted in this order:
blank 123 1 asdfgh !@#$%^&
admin 1234 !@#$ !@#$% !@#$%^&*
root 123456 asdf !@#$%^ server
Without a successful connection, it moves on to the next user.
- With a successful connection, it attempts to copy itself
(name obtained by GetModuleHandle()) to the target system:
it stops once any copy has been successful:
COPY myFileName \\remoteIP\\Admin$\system32\iraq_oil.exe
COPY myFileName \\remoteIP\\c$\winnt\system32\iraq_oil.exe
- Once the target has been copied, it obtains the system's remote
time clock in order to schedule a job for execution by the "at" service.
It tries to schedule the job 2 minutes into the future, though due to
the odd math used, it's possible that servers in time zones east of
Grenwich may get scheduled incorrectly.
- Once the remote server has been infected, it moves on to the
next random IP.