Anatomy of a DoS attack that exploits WebDAV vulnerability in Apache Web server
Hi there,
It has been sometime since I haven’t posted anything at the blog and finally got a chance to do so.
Recently I helped a colleague of mine to investigate a “Windows server connects to unknown destinations” problem. Our customer reported that they were unable to use their internet connections when they start up a certain Windows 2003 server in their network. After some troubleshooting at their side, they concluded that Windows 2003 server was generating excessive UDP activity towards random IP addresses at random times and they were asking for help with finding out the relevant process on the Windows 2003 server side that was generating that traffic.
We asked them to collect a network trace while the problem was visible. As the problem happened very frequently, it didn’t take them long to collect such a network trace. After analyzing the network trace collected, I found out the process that was source of the excessive traffic. Now let’s walk it through together:
a) First of all I tried to identify the excessive UDP traffic. It was like below:
...
303 16:19:48 10.08.2011 0.0000000 33.9062500 20.0.0.1 192.168.1.105 UDP UDP:SrcPort = 2976, DstPort = 10647, Length = 8200 {UDP:48, IPv4:47}
304 16:19:48 10.08.2011 0.0000000 33.9062500 20.0.0.1 192.168.1.105 IPv4 IPv4:[Fragment, Offset = 1480] Src = 20.0.0.1, Dest = 192.168.1.105, Next Protocol = UDP, Packet ID = 814, Total IP Length = 1500 {IPv4:47}
305 16:19:48 10.08.2011 0.0000000 33.9062500 20.0.0.1 192.168.1.105 IPv4 IPv4:[Fragment, Offset = 2960] Src = 20.0.0.1, Dest = 192.168.1.105, Next Protocol = UDP, Packet ID = 814, Total IP Length = 1500 {IPv4:47}
306 16:19:48 10.08.2011 0.0000000 33.9062500 20.0.0.1 192.168.1.105 IPv4 IPv4:[Fragment, Offset = 4440] Src = 20.0.0.1, Dest = 192.168.1.105, Next Protocol = UDP, Packet ID = 814, Total IP Length = 1500 {IPv4:47}
307 16:19:48 10.08.2011 0.0000000 33.9062500 20.0.0.1 192.168.1.105 IPv4 IPv4:[Fragment, Offset = 5920] Src = 20.0.0.1, Dest = 192.168.1.105, Next Protocol = UDP, Packet ID = 814, Total IP Length = 1500 {IPv4:47}
308 16:19:48 10.08.2011 0.0000000 33.9062500 20.0.0.1 192.168.1.105 IPv4 IPv4:[Fragment, Offset = 7400] Src = 20.0.0.1, Dest = 192.168.1.105, Next Protocol = UDP, Packet ID = 814, Total IP Length = 820 {IPv4:47}
309 16:19:48 10.08.2011 0.0000000 33.9062500 20.0.0.1 192.168.1.105 UDP UDP:SrcPort = 2976, DstPort = 10647, Length = 8200 {UDP:48, IPv4:47}
310 16:19:48 10.08.2011 0.0000000 33.9062500 20.0.0.1 192.168.1.105 IPv4 IPv4:[Fragment, Offset = 1480] Src = 20.0.0.1, Dest = 192.168.1.105, Next Protocol = UDP, Packet ID = 815, Total IP Length = 1500 {IPv4:47}
311 16:19:48 10.08.2011 0.0000000 33.9062500 20.0.0.1 192.168.1.105 IPv4 IPv4:[Fragment, Offset = 2960] Src = 20.0.0.1, Dest = 192.168.1.105, Next Protocol = UDP, Packet ID = 815, Total IP Length = 1500 {IPv4:47}
312 16:19:48 10.08.2011 0.0000000 33.9062500 20.0.0.1 192.168.1.105 IPv4 IPv4:[Fragment, Offset = 4440] Src = 20.0.0.1, Dest = 192.168.1.105, Next Protocol = UDP, Packet ID = 815, Total IP Length = 1500 {IPv4:47}
313 16:19:48 10.08.2011 0.0000000 33.9062500 20.0.0.1 192.168.1.105 IPv4 IPv4:[Fragment, Offset = 5920] Src = 20.0.0.1, Dest = 192.168.1.105, Next Protocol = UDP, Packet ID = 815, Total IP Length = 1500 {IPv4:47}
314 16:19:48 10.08.2011 0.0000000 33.9062500 20.0.0.1 192.168.1.105 IPv4 IPv4:[Fragment, Offset = 7400] Src = 20.0.0.1, Dest = 192.168.1.105, Next Protocol = UDP, Packet ID = 815, Total IP Length = 820 {IPv4:47}
315 16:19:48 10.08.2011 0.0000000 33.9062500 20.0.0.1 192.168.1.105 UDP UDP:SrcPort = 2976, DstPort = 10647, Length = 8200 {UDP:48, IPv4:47}
...
There were thousands of such UDP packets without meaningful data being sent to the very same target
NOTE: I deliberately changed the public IP address targeted to 192.168.1.105
b) After that, I tried to track back the starting point and I found the following in the network trace:
302 16:19:48 10.08.2011 21.7031250 33.9062500 httpd.exe 172.16.10.5 20.0.0.1 HTTP HTTP:Request, GET /webdav/shell.php, Query:act=phptools&host=192.168.1.105&time=120&port=3074 {HTTP:46, TCP:45, IPv4:20}
NOTE: I deliberately changed the source public IP address to 172.16.10.5 (from where the attack was initiated)
Note: I was lucky here as Network Monitor easily identified the relevant process. If you cannot see the process easily, you may want to try other methods given at the following post:
c) After some research, I found out that this was a vulnerability with Webdav within Apache Web server
https://www.apachefriends.org/f/viewtopic.php?f=5&t=45534 [SOLVED] httpd.exe maxing internet connection...
https://www.opensc.ws/off-topic/11895-webdav-link-crawler-ip-scanner.html
So the attacker was using the customer’s Windows 2003 server as a victim to start DoS (Denial of service) attacks to other hosts...
d) After the customer upgraded the Apache Web server version to the latest one, the issue was resolved J
Long story short, always keep your all software up to date, not just the OS and its services running
Cheers,
Murat