[Sandia's] Thunderbird supercomputer will periodically run a million virtual machines all at once, all with botnet client software. By setting this large network of systems into operation, the researchers, Ron Minnich and Don Rudish, hope to better understand how botnets operate.

It's a cool idea, and could probably keep me busy forever. The only issue I have with this project is that the time and money would be better spent on trying to improve the fundamental security issues of our computing model, rather than just learning about a symptom (in this case, botnets). Still, it sounds like fun, and will hopefully produce some actionable knowledge in a year or two.

via Sandia to boot behemoth botnet -- Government Computer News.

Rather than rehash what's already known about Conficker.C, I'll just point readers to an excellent Q&A post from F-Secure. Question number one:

Q: I heard something really bad is going to happen on the Internet on April 1st! Will it?
A: No, not really.

If that's not enough information for you, read the rest of their post, and stop freaking out.

Update: I just read an interesting post on this topic from Verizon Business Security (Risk, Group Think and the Conficker Worm), which I saw thanks to TaoSecurity.

If we are going to go down the path of starting over, why not go right to the root of the problem, and fix our hardware? Now that we know what kinds of vulnerabilities exist in our existing designs (based on the von Neumann architecture), we could create a new hardware platform that has security and privacy protections built in. This would naturally lead to a new kind of software, which could take advantage of the new hardware features and architectural decisions, to keep itself secure. Since the Internet is just a collection of networking hardware and software, it would obviously also benefit.

In fact, by rethinking the very basic underpinnings of computer design, we can propagate the results throughout the entire CPU-based world, not just the Internet. Trying to fix only one part of the problem, such as by creating "a 'gated community' where users would give up their anonymity and certain freedoms in return for safety" would be a disaster. Not only would it quickly be broken and misused, like every other attempt to do something similar, but it would eliminate one of the best features of the Internet that caused it to thrive in the first place.

Sadly, I doubt we will ever be able to "start over" on something like this (IPv6, anyone?). I mean, there are so many aspects of life that could use the benefit of hindsight and a redesign, like politics, tax law, health care... but they are too entrenched in society to be replaced by better systems. That makes for good job security for those of us in the computer security field, as long as we can put up with the feeling of continuous frustration, knowing that a true alternative is possible, but we are essentially powerless to pursue it.

Obama plans to keep his BlackBerry
There will be plenty of security and legal hurdles. Here's one already: "The security question was inadvertently highlighted on Friday as Obama's BlackBerry tumbled from his belt as he exited his limousine and got onto his plane..."

Widest night/day megapixel lens without distortion for the security industry
This is cool for those into physical security or surveillance: "Theia leveraged their patented Linear Optical Technology platform with all-optical barrel distortion correction to provide a nominal 110 degree horizontal field of view..." The article has a picture showing the difference from a regular wide angle lens.

Frankly Speaking: What would really make software more secure
Not a bad idea, although I'm not sure how I feel about yet another expensive software certification process: "...SANS says some state governments are already thinking about requiring software suppliers to certify in writing that their code is free of the errors on the list." Hasn't the federal government already tried similar approaches?

This post on the SANS ISC Hander's Diary is a great resource to get you started on the process of pinpointing which hosts on a network are still compromised, and need to be carefully reviewed. Since a large network with many servers is assumed, the easiest way to begin is from the network level, working your way down to host-based solutions.

You can read the post for all the details, but the basic tools and techniques mentioned are:

• log all DNS queries
• store netflow data
• log accepted firewall connections
• deploy IDS with relevant EmergingThreats rule sets
• use BotHunter
• carefully monitor DNS traffic for anomalies
• monitor web traffic for unusual activity
• virus scan as many hosts as possible using good heuristic software
• check for root kits on critical systems, using something like RootkitRevealer
• scan for suspicious executables, using something like Red Curtain

Yes, this is a long list of actions, and it can take quite a while to implement. Unfortunately, the longer it takes, the more time your adversary has to reinfect your network, especially if you haven't figured out and closed the hole he used in the first place.

This is why being prepared ahead of time is always a huge advantage. If IDS is already deployed and working, and if you know what your network traffic looks like normally, it becomes a lot easier to detect anamolies when something goes wrong. Hey, if all else fails, you could always unplug the company from the Internet for a few days, right...?

Some of the problems this approach is trying to solve are browser-dependent obfuscated JavaScript, plug-in dependencies (like Flash), multiple redirects, etc. All of these issues make malware analysis more complex and time consuming, so any automation you can get away with is a big help. The demo at the end is pretty cool, but he glossed over how the information from the automated analysis is presented to the user. I'm guessing it's not (yet) in a pretty report format. Either way, you still need someone with the right knowledge to analyze the output and decide what to do with it to help defend your network.

The researchers' new approach, called CloudAV, moves antivirus functionality into the "network cloud" and off personal computers. CloudAV analyzes suspicious files using multiple antivirus and behavioral detection programs simultaneously.

In general, that's not a bad idea. It might save a few CPU cycles on your local workstation by not having to directly virus scan files. Then again, you have to use network resources uploading each file to the cloud, where it is scanned for you.

Each time a computer or device receives a new document or program, that item is automatically detected and sent to the antivirus cloud for analysis.

The privacy concerns here are obvious. Would you trust CloudAV to receive a copy of every file you want to virus scan? How sure can you be that they don't use the contents for something else, or accidentally leak private information?

I think this idea has more merit as an internal virus scanning system for a large organization. That way sensitive data doesn't have to leave the corporate boundary, or be sent to a third party. The benefit is that you have a more thorough and updated virus scanning engine, possibly using several different products at once.

Researchers develop next-generation antivirus system.

• Techworld
• Ruby Inside
• ZSFA
• Matasano Chargen

The list of CVEs created to track these bugs:

• CVE-2008-2662
• CVE-2008-2663
• CVE-2008-2725
• CVE-2008-2726
• CVE-2008-2664

The funny thing is, these vulnerabilities were created in the run-time implementation of Ruby, which is itself written in C. So it's really not all that surprising, considering how hard it is to write secure, large, bug-free C programs.

This is a cut and dry example of why the insider threat is such a major issue. I guess some companies need to learn the hard way: Disable all accounts belonging to terminated employees; if it's an admin (or the IT director), change all the root passwords as well. Of course, this implies that a company has to keep track of all the accounts an employee might have, which is not easy. The important thing to remember is that this is more of a people/policy challenge than a technical one.

This article by Ed Skoudis lists a few of them, with handy examples of how the commands might be used in a security investigation. He mostly talks about wmic, openfiles (which I had never heard of before), and netstat. Unless you've done recent Windows administration work, you've probably never had to use wmic, but it's really powerful, with tons of options. Also, be sure to check out the second part of his article, which goes into more advanced command line tricks - like "for" loops and querying the registry.

A more comprehensive list, although less detailed, was published by Kevin Beaver. There is overlap, but Kevin mentions a few addiontal commands.