All in all, it was a pretty quiet day on the Internet. Still we had some interesting items: More scanning and exploits attempts for the CA BrightStor ARCserve Backup vulnerability, a discussion of whether your IDS/IPS might be dead, and one option for setting up a persistent Linux/UNIX Netcat listener.




***CA BrightStor ARCserve Update***



A handful of people sent us packet captures associated with TCP port 41523, the target of interest with the recent CA BrightStor ARCserve Backup vulnerability. Thank you to Andreas, Klaus, and Mark S for their wonderful data on this. So far, we are seeing scanning for the open port, as well as some attempted exploits against honeypots listening on the port. Each of these exploit attempts appears to be based on the exploit code from k-otik, specifically the Metasploit component.



Also, CA has released additional information on fixes for various products with this vulnerability. If you are running any of the following in your environment, you better patch soon, before the kiddies come a-callin'!



BAB r11.1 Windows (repost):
http://supportconnect.ca.com/sc/solcenter/solresults.jsp?aparno=QO64538&startsearch=1

BAB r11.0 Windows:
http://supportconnect.ca.com/sc/solcenter/solresults.jsp?aparno=QO64539&startsearch=1

BEB 10.5 Windows:
http://supportconnect.ca.com/sc/solcenter/solresults.jsp?aparno=QO64540&startsearch=1

BAB 9.01 NetWare:
http://supportconnect.ca.com/sc/solcenter/solresults.jsp?aparno=QO64541&startsearch=1

BAB 9.01 Windows:
http://supportconnect.ca.com/sc/solcenter/solresults.jsp?aparno=QO64542&startsearch=1

BAB r11.1 NetWare:
http://supportconnect.ca.com/sc/solcenter/solresults.jsp?aparno=QO64543&startsearch=1

BEB 10.0 Windows:
http://supportconnect.ca.com/sc/solcenter/solresults.jsp?aparno=QO64544&startsearch=1




***Killing Me Softly With Your Sploit... Is your IDS or IPS Really Alive?***



We received a report from one of our diligent and wonderfully paranoid readers expressing concern that his IPS hadn't detected any alerts lately. This gent was afraid of the quiet before the storm. While many of us are happy with a bit of quiet, this e-mail brought up a really good point. If your IDS and/or IPS sensors seem a little too darn quiet, it might be a good idea to fire some freakazoid packets at them to see if they are still running. It's possible that they have simply died, or perhaps have been purposely disabled by an attacker.



Two months ago, I was having a conversation with an IDS researcher whose name may or may not rhyme with "Pike Moor" about the concept of killing an IDS in a stealthy fashion. The idea here is that we all know that on occasion an IDS or IPS tool has an unfortunate buffer overflow in a packet parser. However, if an attacker exploits it carelessly, the IDS/IPS crashes, and the incident response team of the target organization usually finds out pretty quickly. But what if the evil bad guy (that's the worst kind, by the way) sends specially crafted buffer overflow packets designed to make the IDS/IPS crash so that it goes into an endless (and rather alive-looking) loop? The response team of the target would be none-the-wiser, while the evil bad guy could go about his business unfettered by pesky handlers. Such an attack would be far more insidious than just crashing the IDS.



For this reason, if you've got an overly quiet IDS or IPS, you might want to test it with some real evil packets, such as a Metasploit hit just to make sure it is lovingly protecting your network. Of course, please make sure you get appropriate permission before conducting such an exercise!



***Persistent Netcat Listeners for Honeypots***



The other day, we asked readers to set up honeypot listeners using Netcat to capture some of the malicious code trying to hit TCP port 41523. Now, one of the problems with the most popular Linux/UNIX implementation of Netcat (that is, Hobbit's original) is that it does not create a persistent listener. Unlike the Windows version of Netcat (with its -L option for "Listen Harder"), the original UNIX/Linux version doesn't do this. Once one client connects and drops, the listener dies.



There are many ways to get around this problem, such as using a different version of Netcat. However, one of my favorite simple ways to deal with this is to set up the Netcat listener in a while loop as follows:



$ while [ 1 ]; do echo "Started"; nc -l -p 41523 >> capture.txt; done



This will listen on TCP 41523, append whatever it receives to capture.txt, and then start listening again.



If you'd like to go further and actually log out while keeping this thing running, you can simply dump this while line in a file, called honeypot.sh. Then, chmod it so that it is executable (chmod 555 honeypot.sh). Finally, invoke it as follows:



$ nohup ./honeypot.sh &



Then, logout and go watch some TV. Take a nap. Run naked through the park. Do whatever it is that you do...



Come back, and your little Netcat buddy will be running with its results stored in capture.txt. To kill it, you could simply kill the pid of the nc listener itself. Thanks to Don Smith for the nohup idea. Note that Don did NOT suggest the park idea.



That's it for now!



Have a great weekend--

--Ed Skoudis

ed (at) intelguardians.com