Nuff said… 😉

Editor note: Now intentionally disabled. You get the picture…

A few weeks ago I ran across this project, called GreenSQL. It is an open source database firewall to help organizations mitigate application vulnerabilities due to common SQL attacks like SQL injection and such.

It is a list-based heuristic proxy firewall that you can use to filter SQL traffic between the web server and the database server. This is a pretty powerful tool, even being list-based. As this project evolves, perhaps it will also include more powerful approaches such as anomaly-based analysis.

For now though, black listing, white listing and their approach to transaction risk weighting is a very powerful approach and much better than nothing.

That said, MSI has has not tested the application or performed any formal review, we just liked the idea that they were working on. Perhaps, in the future we will donate some lab cycles to a review and some testing, but we wanted to help them at least get the word out about their project.

If you are using MySQL for your web-based applications, it might be a good thing to spend some time looking at this project and testing the capabilities of the tool for your environment. Eliminating SQL attacks from web-applications will reduce a significant amount of risk from their deployment. By some estimates, that risk could be as high as 25% of the aggregate risk an application causes. No matter the metrics, this project is certainly a step forward.

This usually goes without saying, but trusting the wrong people, organizations of mechanisms can seriously bite you.

Take for example, the current situation with ORDB.org. They are one of the older spam blacklists and they have been around a while. So long in fact, that when they shut down in 2006 few people took notice. But, we should have.

It turns out that a few organizations and a few vendors used the blacklist provider as another source for spam prevention. Since the project was shut down, the list was un-updated since the end of 2006. Mostly, that is no harm – no foul – unless you happened to have inherited one of those IP addresses on the list, then you might be a little mad…

But, as of this week, the ORDB list suddenly changed behavior for an as-of-yet-unknown reason. All of a sudden the blacklist started to block ALL IP addresses!

Now many folks would say, if the list shutdown in 2006, why do we care? Well, it turns out that a lot of vendor products and a few careless admins had left the list in their systems. They were still trusting the contents of the blacklist as a spam prevention tool. As you might imagine, what has ensued is a TON of blocked e-mails, a few mad customers and some bewildered troubleshooting technicians…

But, this is just that same old IT problem. Often, we build systems with trusts, configurations and dependencies that exist today. Maybe (most likely) they will not exist in the future. What happens when/if they don’t? Usually, things break. Maybe, if you are lucky, they break in big ways so that people notice. But, if they break in some small way, say in a subtle way that goes unnoticed, they could have dire affects on confidentiality, integrity and availability. As a quick example, what if you were scraping financial data from a website for use in a calculation – maybe an exchange rate. What happens if no one is checking and that website stops updating? Could your calculations be wrong? How would you know? If the exchange rate didn’t vary grossly, but only had small changes over time, what would the effect be? You see, even small issues like this could have HUGE impact. In this scenario, you could lose, mis-bill or the like by millions of dollars over time…

Trust for abandoned projects also raises another security issue. It is pretty likely that projects, systems and applications that are abandoned could become lack on being patched or maintained. If this were to occur and you are still dependent on the data – what would happen if an attacker took control of the project or system hosting it? I am not saying this happened at ORDB, but suppose it did. It seems to me that attacking and compromising old abandoned projects that people might still be dependent on is a pretty creative approach to causing some amount of chaos.

I guess the big question that the ORDB situation raises is; what other things like it are out there? What other abandoned projects or technologies are we dependent upon? How might this mechanism come to be used against us in the future?

We are pleased to announce the general availability of the slides and audio of our presentation from March 25, 2008.

The event was focused on three strategies for application security.

You can download the slides and audio MP3 from the links below.

PDF of the slides:

http://microsolved.com/files/3AppSecMustDo.pdf

MP3 URL:

http://microsolved.com/files/3AppSecMustDos032508.mp3

** Please Note: the audio MP3 did not come out as well as our others due to a mic issue. The problem has been resolved, but please remember to lower the volume on your MP3 player as the clip is overly loud and a bit “clipped”. We apologize for the issue.

OK gang, after a conversation last night helping a client keep track of changes in domain accounts, here is a quick and easy way to do so for domains or local machines.

First, use the command line “net user” while logged in as an admin or “net user /domain” for the domain accounts. Once you see the output and have a chance to be familiar with it, you can watch for changes pretty easily.

Use the “net user /domain >> output_date.txt” command to redirect the output to a file. You should replace date with the numeric date just as a reference. Once you have this file created, you can create a new one as often as you like. Once you have one or more, simply drop them into your favorite text editor and use the file compare or diff functions to spot any changes between versions.

I suggest you use the editor Context for Windows, but there are a ton of freeware and open source tools to compare files – so choose the one of your liking.

If you wanted to get clever with this approach, you could automate it with a batch file that used command tools and run it as routinely using task scheduler on your security monitoring system or workstation. Advanced users might even add in email alerting using some command line mailer – why, the ideas are endless for automating often tedious user account monitoring with this approach.

If you haven’t played with the net commands in a while in Windows, now might be a good time for a quick refresher. You might even find some more quick and dirty things you could monitor in this manner. Who knows, you might just automate so many items that you get to actually take a vacation once a year again. That, truly, would be worthwhile… 😉

Drop us a comment if you have any other “quick and dirty” monitoring tricks that you use to keep an eye on your organization.

Virtualization is really a hot topic. It is gaining in popularity and has moved well into the IT mainstream. Of course, it comes with its challenges.

Virtual network visibility was/is a big challenge. Typical network security and troubleshooting tools are essentially blind to traffic that occurs on virtual switches and between virtualized machines. Several vendors have emerged in this space and appliances and enhancements to the virtualization products are likely to minimize this issue in the next 12 months for most organizations. There are already several mechanisms available to observe virtual network traffic, repeat it or analyze it in place. As long as systems and network engineers take this into consideration during design phases, there should be little impact on security architecture. Of course, that may take a few gentle reminders – but overall this seems to be working for the majority of companies embracing virtualization while maintaining tight controls.

The second issue is ensuring that virtualized systems meet established baselines for configuration, security and patching. This is largely a process issue and as long as your policies and processes follow the same flows for virtual machines as real hardware-based systems then there should be few unusual issues. Here the big risk is that an attacker who gains access to one “guest” virtual machine may (MAY) be able to attack the hypervisor that is the “brain” of the virtualization software. If the attacker can break the hypervisor, they MAY be able to compromise the whole real machine and potentially ALL of the virtual systems that the real system hosts or manages. These are conditional statements because the risk exists, but to a large extent, the threats have been unrealized. Sure, some proof of concepts exist and attackers are hard at work on cracking huge holes in the virtualization tools we use – but far, wide and deep compromises of virtualization software and hypervisors have still not emerged (which is a good thing).

I have been asked on several occasions about hypervisor malware attacks and such. I still think these are very likely to be widely seen in the future. Malware can already easily detect VM installs through a variety of mechanisms and attackers have gotten much better at implementing rootkits and other malware technologies. In the meantime, more and more attack vectors have been identified by researchers that allow access to the hypervisor, underlying OS and other virtual guests. It is, in my opinion, quite likely that we will see virtualization focused malware in the near future.

Another common question I get is about the possibilities of extending anti-virus and other existing tools to the hypervisor space for additional protection. I am usually against this – mostly due to the somewhat limited effectiveness of heuristic-based technologies and out of fear of creating yet another “universal attack vector”. Anti-virus exploits abound, so there is no reason to believe that hypervisor implementations wouldn’t be exploitable in some way too. If that were to be the case, then your silver bullet hypervisor AV software that protects the whole system and all of the guests, just turns into the vector for the “one sploit to rule them all”.

I truly believe that the options for protecting the hypervisor should NOT lie in adding more software, more complexity and more overhead to the computing environment. As usual, complexity increases come with risk increases. Instead, I think we have to look toward simplification and hardening of virtualization software. We have to implement detective mechanisms as well, but they should like outside of the hypervisor somehow. I am not saying I have all of the answers, I am just saying that some of the current answers are better than some of the others…

What can you do? Get involved. Get up to speed on VM tools and your organization’s plans to deploy virtualization. Evangelize and work with your IT team to make sure they understand the security issues and that they have given security the thought it deserves. Share what works and what doesn’t with others. Together, we can all contribute to making sure that the revolution that virtualization represents does not come at the price of severe risk!