Security Enabled Network

I have been doing a lot of reading lately about the history of security research and the issue of full disclosure. It is a huge debate issue and it was something that before I started getting into security, I was completely unaware of. It isn’t something that hits the news often and when a vulnerability makes the news, the background issue about the disclosure of it is usually so controversial that nobody touches on it in the mainstream.

So what is it exactly? Well it is in regard to when a security vulnerability is discovered, the debate revolves around whether or not knowledge of that vulnerability should be open to the public. Some people say that making sensitive information like that public only put the customers and general public more at risk by releasing that information out into the wrong untrusted hands. Others say that untrusted individuals already had that information and that releasing it to the public will help speed up the process of getting a proper fix for the vulnerability out to the people that need it.

No matter where you stand on the issue, both sides seem to agree that one of the greatest issues is communication. There are generally two parties involved with the issue. One being the vendors that make the software at risk, the others being the security researchers that initially discovered the vulnerability. These parties must communicate in such a way that is in the public’s best interest. However, poor communication between the two can deteriorate relations and can lead to the disclosure of sensitive vulnerability information. Vendors typically claim that they are not given enough time to get a fix properly release. The security researches sometimes claim that waiting too long to get a patch to the general public is putting the public at an increased risk with each day that goes without a proper patch.

There have been many disclosure policies that have been developed over the last decade that are aimed at helping develop proper communication between all parties involved such as RFP, OIS, and ZDI. Many of these are just guidelines and are there just out of general respect for both sides. Neither side, however, is obligated to follow those guidelines. They do help give each side of the fence a certain set of expectations. If one side is following a specific policy and staying within the guidelines set, then the other side will know what to expect. It also helps open lines of communication that may not have been there before the policies were put in place. Many times, when a security researcher discovered a flaw in a piece of software, they’d have no idea where to turn to to get the flaw fixed.

After reading more and more about the history of this issue, when I see events that happen, like the DNS vulnerability that Dan Kaminsky and the associated vendors handled, it really amazes me how well everyone involved were able to communicate and help get the issue resolved. Without open lines of communication from both sides, we just won’t be prepared enough to handle wide spead isssues properly when they arise.

There has been a lot of buzz lately about the Conficker worm that has been circulating and has now infected nearly 12 million Windows computers worldwide. But, not all the news regarding the Conficker worm is doom and gloom. Experts in the field have discovered a security flaw in the virus that will allow security administrators to isolated infected computers.

When the Conficker worm infects a computer, it applies its own version of the Microsoft patch that was released last October that fixes this vulnerability so that when the computer is scanned for patches, the vulnerability goes undetected. However, security researcher Dan Kaminsky said a research group found that it was far easier to distinguish a computer patched with the Conficker worm from a computer patched with Microsoft’s patch due to a flaw in the Conficker code.

From this, they have been able to create scanning tools that can help distinguish whether or not specific computers are infected with the Conficker worm or not because of the the Conficker flaw they found.

The problem with this type of resolution though is it could possibly give some criminals an opening into the botnet to create new worms that will allow them to take control of sections of the botnet.

Such an “anti-worm” might well be more destructive than the Conficker worm itself, Kaminsky said. “You would have to build something that is as virulent as the current worm, and be willing to become the kind of monster you’re trying to fight,” Kaminsky said. “No one can play counter-worm very well.”

If one good thing has come out of the Conficker flaw it is the discovery that it highlights weaknesses that can be found in almost all third-party security patches. Usually the security industry would release seperate security patches and scanners pertaining to a particular virus or worm to provide protection until a complete update is able to be released. But, those updates are generally produced by people who do not have access to the source code, thus not providing a 100% guarantee on patch success or not. The Conficker flaw has shown that systems really can’t be purged until they have a full cleaning with an updated scanning software made from the source code.

I wanted to quickly post on a topic I was reading about this morning. There were several posts I came across that I found important to take note on. They are about a growing trend in attacks in 2009. Infrastructure attacks have been on the rise since January and it is a large concern for many because of the way that most professionals handle their core infrastructure.

In a recent post by Dan Kaminsky he talks about the growing trend of infrastructure attacks in 2009. He mentions the need for better security across the infrastructure. Network devices need to be easier to update. Current generation appliances require cumbersome update processes that often result in needing schedule outage periods. Not to mention the fact that there is always a risk of bricking the hardware during a firmware upgrade. There is a growing need for an automatic update process much like the kind desktops use in order to stay current with the trends of infrastructure attacks.

Infrastructure attacks like the one that Ryan Naraine talked about in his blog post. There is a psyb0t worm that affects embedded Linux devices like ADSL modems and the like. This means there are hundreds of thousands of home routers that are vulnerable and there is an estimated 100,000 already infected.

With the growing trend of infrastructure attacks this year I suspect there will be a new trend to combat it. People will begin to re-evaluate how they handle their infrastructure. We may start to see network appliance manufactures implement auto-update features for their devices. We’ll just have to wait and see.

In a Microsoft Security Bulletin released late last week, 12 new security updates have been planned for release this Tuesday. Seven of those updates have been labeled as critical and the rest are labeled as important. This bulleting came at the same time of the Black Hat conference.

During last week’s Black Hat conference, researchers Mark Dowd and Alex Sotirov discussed ways to bypass Windows Vista memory protection techniques like DEP. They use several browser functionality methods to do so. They don’t exploit any software vulnerabilities which means these flaws will be much harder for Microsoft to correct. Microsoft has yet to comment on the findings.

Email is a part of everyday life in the business world. Even small companies will see thousands of emails pass through their servers each day. This means there is plenty of opportunity for attack against your mail server. So here are 5 good tips to help keep your email secure.

1) Change your SMTP banner: Most mail servers accept connections of port 25 for use with SMTP. If you telnet on port 25 to a mail server that is opened up on port 25, you will receive a response from that server. This response is called the SMTP banner. Usually by default (with Exchange) this banner will not only display the actual server name and domain, but it will also show the version number and software that is running on that server. This is crucial information that an attacker can utilize when planning an attack. It is important that if your server accepts connections on port 25 that you mask this banner with a canned message that doesn’t display sensitive information like that. For more information on changing this banner with Microsoft Exchange, read this Microsoft article: Changing your SMTP Banner

2) Enabled Relay Restrictions: This is usually set by default on mail servers so that only authentication or specified servers are allowed to relay email through your mail server. But, it is a good security measure to take to ensure that your mail server is not an open relay. If there are no restrictions set, spammers will have a field day with your server. Not only can this really cripple your server if not taken care of promptly, but it can also get your server blacklisted. Once blacklisted you will need to score which blacklists you are on and request to be removed once you prove to them that you are no longer spamming from your server. This can take weeks or months depending on which list you are on. If you aren’t sure if your server is an open relay, you can use this tool to check: Open Relay Checker

3) Make sure your server is up-to-date: Because your mail server is constantly in touch with connections to the outside world, it is crucial that your mail server is always up-to-date. A lot of IT professionals will ensure that their servers have the latest Windows Updates run on their servers, but don’t forget about Exchange updates and service packs as well. Automatic updates won’t keep that up-to-date and many times the security vulnerabilities needed to be patched with Exchange are more critical than your typical Windows update. While there is no excuse for an out-of-date server, if installing updates is something that takes up too much of your time, then look into a patch management solution. Microsoft offers a free solutions for all their software systems called Windows Server Update Services.

4) Protect your mail server with a front-end server: Another good idea for security is to set up a front-end server to act as either a proxy or relay between the mail server that stores your mail databases and the internet. The front-end server will handle all HTTP and SMTP requests for your main mail server. All emails will then be relayed from this front-end server to your main mail server. What this allows you to do is close off port 25 to your main mail server so that it is hidden behind your firewall. Many companies will even provide this service for you. Having your server behind a firewall and accepting connections from only internal mail clients and the front-end server will greatly increase the security of your server.

5) Spam and Virus Protection: I’ve listed both spam and antivirus under the same number here because I think we are at the stage where they both go hand in hand. It is important that you maintain antivirus and antispam software on your network. I recommend using a seperate appliance for spam as this will help catch spam emails from even reaching your mail server. If your mail server processes a lot of emails everyday, then this will help eleviate some of the strain that it carries. Making sure that both systems are up-to-date with the latest signatures goes without saying.

These are only 5 tips for helping maintain security on your mail server and there are a ton more. Hopefully these will get you on the right track and taking email security serious.

So there has been a lot of talk lately about Kaminsky’s DNS Poisoning Vulnerability. What is it and why is it such a hot topic, yet kept so secret at the same time. Well I can’t tell you exactly what the issue is. If I could then I’d probably be directly in touch with Dan Kaminsky and would be at Defcon with him at the end of the week. But there is a little bit of information out about the severity of it and why it is kept such a huge secret. There was a design flaw found with DNS that allows an attacker to poison the cache on a DNS server with invalid entries.

What poisoning is refered to in IT is when entries in a cache system are replaced with fake or incorrect entries on purpose from an attacker. With DNS what this results in if someone were to take advantage of it is the attacker could revert any traffic to any particular website hosted on the compromised DNS server to any other web server on the internet. This means the attacker could place a phishing web page at the new destination. Email could also be compromised by poisoning MX records and then having confidential emails redirected to another email server on the internet. Basically the internet would become compromised.

But, thanks to a collaboration of some of the best minds in the industry, this issue has been kept secret and has given everyone hopefully enough time to patch the vulnerable systems. Here is a little more information on the DNS vulnerability at hand.