March 31, 2005
SBS MVPS Community Groups Outreach - Canadian Workshops Tour 2005
This just in...
The Canadian SBS MVPs invite resellers and consultants who want to understand solutions for small business customers to join together for an evening of presentations and discussion. The local chapters of SBS and Windows professional groups across Canada are joining together with sponsorship by Microsoft to bring a group of Microsoft Small Business Server "Most Valuable Professionals" to meet with you. Each of the SBS MVPs appearing on this tour is an experienced resellers and a community leader. You can expect the same no-nonsense expertise on SBS and related technology applications you read in the newsgroups to be brought to this discussion.
You will have a unique opportunity to speak informally or ask technical questions from some well respected MVPs from across North America, including our special guest, Jeff Middleton SBS MVP (US). For this event series (except Toronto), Jeff will be explaining how his Swing Migration method for SBS and Windows server upgrades ends working on weekends or extensive business shutdown.
This is awesome. Just talked with Jeff and he is coming up to present to us in Vancouver for sure. I will have to make sure I make some time to meet with him and the rest of the SBS MVP. Susan, you should be getting your butt up here too :P
Make sure you register today!
March 29, 2005
Security of Windows vs Linux in a Web Server Role
Security Innovation has just released an interesting paper taking a critical look at the Web Server role, where a platform must serve a dynamic web application. Specifically, they compare two technology platforms fulfilling this role: Microsoft Windows Server 2003 running Microsoft Internet Information Services 6.0 (IIS 6.0), the Microsoft SQL Server 2000 database server and the ASP.NET application platform versus Red Hat Enterprise Linux 3.0 (RHEL 3.0) running the Apache web server, the MySQL database server and the PHP application platform.
I will let you judge the report on its own merits. However, I though this section of the findings were interesting:
The cumulative days of risk and the vulnerability counts illustrate that the number of vulnerabilities on the Windows Server 2003 platform is considerably less than the number for the Red Hat server. Aside from beliefs over the relative "security" of the closed versus open source development paradigms, another important contributing factor is that Microsoft develops and releases all of the components in their web server stack. This allows Microsoft more control over release cycles and vulnerability disclosures than the distributed development model.
The average days of risks calculations across all vulnerabilities show that Windows Server 2003 has a lower average for days of risk. Furthermore, examination of outliers shows that there are fewer bugs in the very dangerous 90+ days of risk category. This is important, as the longevity of a flaw is directly related to its likelihood of targeted exploitation. Another factor which helps Microsoft in terms of average days of risk is that Microsoft strongly encourages a "responsible disclosure" policy – that is, the company attempts to carefully coordinate vulnerability announcement with fix announcement and actively build relationships with new security researchers. Red Hat data shows evidence of leveraging a responsible disclosure policy as well, with 15 zero day fixes. This helps drive down averages in a way that directly reduce customer risk.
Interesting research. I am sure this is going to drive a new set of conspiracy theories on both sides of the fence. However, if you cut through that sort of politics and look at the facts, you see one thing clearly... the work Microsoft did in reducing the attack surface of Windows Server 2003 and the new SD3+C methodology on secure software development is working.
March 28, 2005
Hacker Contests: Why they are Useless
Ok, this bugged me enough that I figured it was worth blogging about.
Recently Symantec released a report in which they said:
"It is now clear that the Mac OS is increasingly becoming a target for the malicious activity that is more commonly associated with Microsoft and various Unix-based operating systems."
In retaliation for such comments Mac and iPod peripheral maker DVForge Inc. sponsored a US$25,000 prize to be awarded to the first hacker who could infect two Macintosh computers owned by the company. Less than a day later the company announced the cancellation of the contest, citing legal concerns.
This is just nuts. Do people live in a vacuum? Absolute security is a myth. It doesn't exist. A determined adversary with enough resources and a reason to compromise a target will do so. Point of fact. The trick is understanding what "enough resources" is. It's probably not the script kiddie next door that a contest like this would attract. But it could be the signal intelligence community of a foreign government. Or a corporation probing for competitive intelligence. Knowing your attacker is the first step in understanding the real risks you are exposed to in the digital divide.
And here is the kicker. When it comes to this level of espionage, the adversary is NOT going to show you it can be done for $25K. Or $500K. Why? Because at this very moment any new vulnerabilities that can be used as an attack vector will stay quiet. The Window of Exposure will continue to impact on the potential attacks until which time someone of a higher interest steps in.
And who would that generally be? A security researcher who wants his name in lights for finding the 'next greatest hole'. He doesn't typically do it for contest money. He does it for fame, in turn giving him access to money. Now don't get me wrong, I think researchers who follow proper disclosure methods are a god send. They are a vital part of the information security industry. And many of them are part of good research teams (like Symantec) who have the authority to talk about such things. So in the end, all Campbell did was drum up some publicity for himself and his company. He did nothing to help the security industry... except maybe to make more people aware that OSX is not immune to vulnerability.
Now, I am not taking side on the OS flameware debate. I could care less. But OSX has a base of BSD. And like all of its sisters, it too has vulnerabilities.
So stop fretting about it and making useless challenges that are meaningless. That not only goes for fans of any particular operating system but for security vendors as well. Just because a security product functions properly does not mean it's secure. Just because no one has shown you to be vulnerable does not mean you are not. (Wow lots of double negatives there). On top of that, as the NSA pointed out years ago, security failures in it's area of interest are due to failures in implementation, not failure in the algorithms or protocols. In other words, the weak link here is the human factor which can make something intended to be secure to be anything but.
So here is a real challenge. Grab yourself a white towel, hack the electronics of my HHGTTG book and I will give you a gargleblaster. That's all contests like this are worth anyways.
March 27, 2005
Remote Web Workplace: So close... yet so far away
Oh man what a disappointment this weekend.
I have been working to integrate two factor authentication into my network for a while now, and decided it was time to actually make it drive the whole SBS experience for my remote users. Was I disappointed when I found out that RWW doesn't actually support Radius. *sigh*
For those of you that don't know, Small Business Server has one of the most amazingly simple yet powerful features I have ever seen for users. It is a web portal through which users can be authenticated for access to Remote Desktop and Terminal Services behind it, Outlook Web Access and the corporate intranet with Sharepoint. An AWESOME tool for remote users.
However, it is rendered virtually useless to me, since I cannot offer it to my employees. Why? Because I do not, and cannot trust the machines they are connecting in from. I cannot risk a keystroke logger on an Internet kiosk in a Kinkos. Or a web access workstation at an airport. Or a pay-as-you-go Internet system at a local coffee shop. I could reduce this risk by using OTP (one time passwords) with two factor authentication tokens. This is how we offer Outlook Web Access now. However RWW doesn't offer this same latitude. According to Microsoft's webcast on Remote Web Workplace, Radius is NOT supported in the tool. That's really too bad.
If you know anyone who has found a way around this, PLEASE LET ME KNOW. I would love to offer this service to my employees, but do not wish to do so until I can tie two factor auth to the logon.
In the meantime, I am going to see if there is some way I can hack radius support into RWW. If you happen to be an expert in RWW and know the in's and out's, why not drop me a line and let me know. Maybe I can make a solution that can help all SBSers out there.
March 23, 2005
Restricting Brute Force Attacks through Resource Metering
NGS Security has released a paper on Anti Brute Force Resource Metering. The premise of the document is that it is possible to restrict web-based application brute force guessing attacks through resource metering.
The authors believe resource metering through client-side computationally intensive tasks provide an alternative strategy in defending web-based application authentication processes against brute force guessing attacks. The premise is that this technique is designed to restrict repetition frequency of data sumissions to an application or host system. By forcing the client to compute a hash that is computationally intensive, you can slow down the attack.
An interesting approach. Happy reading!
March 21, 2005
Using Image File Execution options as an Attack Vector on Windows
Today I was discussing a previous entry I wrote on why using CreateProcess is better than ShellExecute when I was informed by tenfour that I am missing a critical piece of the puzzle. That even with CreateProcess, you can EASILY redirect an executable and use misdirection threats just as you could with shell file extensions. In other words, you can't actually trust where an executable is starting up from, and if its the right executable in the first place.
I will leave the actual usage of this attack vector up to the reader, as I really don't wish to provide working code for the script kiddies out there. On top of that, for this vector to be exploited you must have Administrator privileges already. Yet another reason why you should run as a normal user on your system.
Anyways, the trick for redirecting a process loading is to attach it to the Image File Execution options within the Windows registry. By simply mapping the executable name to a different debugger source, you can actually load something else entirely.
Let me give you a proof of concept:
Now to be fair, this isn't going to elevate your privileges or expose you to any more risk relating to malicious code that couldn't already be executed on your account. But with that said, this has the potential of SERIOUS effects for social engineering hacks and hostile code start points. As an example, spyware doesn't have to worry about trying to hide and start execution in the Run/RunOnce keys when they could simply tag to a common exe that starts up, and on startup spawn the real executable after doing its bidding. I will leave that to the reader to think about.
This is one of the reasons I control application startup behavior in the kernel using a digital fingerprint (an MD5 checksum actually). You don't have to worry about the reparse point of the startup location, and you can simply STOP the execution of applications that have no right to start up. Once attackers start thinking about ways to exploit this, it could get pretty interesting.
So what have we learned here? Well first off, its difficult to trust security by path. Secondly, you should be running as a normal user so this sort of attack vector cannot be started. (The DACL on this registry hive would prevent a normal user from touching it). Thirdly, the complexity in behind Windows exposes us to risk when we least expect it. I never even knew about this execution path. Even though my threat models show why its better to use CreateProcessAsUser over ShellExecute, it never even CONSIDERED this.
I learn something new every day. Hope you do too.
March 19, 2005
Microsoft's Security Development Lifecycle
In the past decade it has been easy to slag Microsoft for their stance on security. It has appeared that the drive for profits have always trumped the safety and security of the code. When Microsoft decided to STOP development and retrain the ENTIRE development group about secure programming, many in the industry brushed it off as a PR stunt. But as I pointed out early last year, if we look at what Microsoft has been doing as of late, we can see that they have made significant changes to build a foundation for a more secure computing experience:
It is an excellent document providing real insight on what is going on with Microsoft's own security development lifecycle. Well worth the investment in time to read and learn from. (Anyone who is arrogant enough to believe they know everything and cannot learn something from Microsoft's experience here really shouldn't be in this industry)
So check out Microsoft's Security Development Lifecycle. Happy reading!
March 18, 2005
BOFH at it again
Going into the weekend, we need a little humor in our life.
Simon and his PFY are at it again. This time with a hydrogen-based explosive device. Made me laugh. Made my day. Hope it does for you too.
Using scoring metrics to define complex code and identify areas to refactor
Mark Miller wrote an interesting article on source code metrics and offers an interesting idea on a scoring mechanism to define complex code and provides for a new way at looking at code analysis. By looking at the code complexity by the ops usage itself, he believes you can zero in on code that needs refactoring. Very interesting idea.
This is a neat idea. As he points out, the currently available software metrics out there are pretty weak at quickly calculating the complexity, and hence the cost of maintenance of the software we create is much higher than it needs to be. His approach to solve this 'pain' is quite interesting.
I downloaded DXCore and the CRPlugins DLLs, but I couldn't get it to work in my C# solution. I keep getting a MissingMethodException for DevExpress.CodeRush.Core.CommandServices.Execute. Not sure what to make of it. However, in Mark's article, he does show how the output SHOULD look. Perhaps you will have better luck than I did.
Great article. Happy reading.
March 17, 2005
The Taxonomy of a Gray Hat Hacker
I read an article today and shook my head. NetworkWorldFusion has an interview with Holy Father, a hacker who wrote the Hacker Defender rootkit.
You know when I talked about the ethics of being an information security professional and the minefield of hiring a hacker? The attitude shown by Holy Father in this article is EXACTLY what I was talking about. It starts out as a curiosity in the technical challenge of writing a rootkit, and turns into the unethical assistance of creating a new attack vector for any script kiddie out there.
He doesn't shy away from turning a profit on his work, and claims that demand in the malicious code writing underground is high for custom rootkits that are completely undetectable and can evade detection for long periods of time.
I guess I shouldn't be surprised. After all, that's why I am in this business. To protect the information of my customers' who are faced with these sort of attackers. I just wish he would use his talents for more business productive pursuits that BENEFIT the infosec industry. I think he is doing more harm than good.
Now don't get me wrong. I think this sort of RESEARCH work is beneficial to the industry. I think we NEED to explore new attack vectors and can only do that by trial and error. But providing said code to the blackhat community is just wrong. We cannot dirty our whitehats, turning them a dull gray for the benefit of profit. We cannot go to the dark side. We must prevail.
In the end though, profiling the attackers show this won't change any time soon. We will be faced with more and more attack vectors built thanks to curiosity, egos and icons. Crossing the line, changing hats (or worse yet simply dirtying your white one) does more damage to the industry than it does good. Remember that when you are faced with crossing that line.
Windows NT Security in Theory and Practice
Although these were published in 1995, I have always found them to be a good resource dealing with the CORE security aspects of the Windows system. If you want a nuts-and-bolts approach to the security driving Windows, this is the resource for you. Of course due to its age, it won't be covering the newer stuff in the server platform. A lot has changed in Srv03 and should be considered when reviewing this content.
Here's a tip for you. There is a LOT of other interesting security resources to read about at the save level on MSDN. In other words, check out the other articles on the left hand TOC NAV side. You will find many of those resources interesting to read.
March 14, 2005
Know your Enemy: Tracking Botnets
Ever been interested in how botnets work?
The Honey Project has released an interesting paper entitled Know your Enemy: Tracking Botnets. In the research, they discuss the tools, tactics, and motives of attackers who run botnets.
A botnet is a network of compromised machines that can be remotely controlled by an attacker. Due to their immense size (tens of thousands of systems can be linked together), they pose a severe threat to the community. With the help of honeynet's wealth of data logged, it is possible to reconstruct the actions of attackers, the tools they use, and study them in detail. In this paper the authors take a closer look at botnets, common attack techniques, and the individuals involved.
Interesting stuff. Happy reading!
March 11, 2005
Keeping the noise down in your security log
Eric posted an interesting article on how to cut down the noise of the security log in Windows Server.
He points out a lot of interesting tidbits. I don't agree with them all, but that's just me. I'd rather wrestle with a little more noise on a hardened server and have too MUCH logs rather than not enough when doing a forensic audit. Of course, most people aren't even LOOKING at their logs, so its a moot point.
Overall though, a very useful article on how to cut down the noise in your security logs on some areas of the system which are not that beneficial for you. Worth checking out.
March 04, 2005
SMB Nation ISV Summit - Day 2
Day 2 of the ISV Summit was much shorter, and much more intimate. About 50% of the people had early flights and didn't attend much. I argue that the nice weather, combined with a Friday afternoon makes it difficult for even myself to sit in a chair. The only thing that kept me there was an EXCELLENT presentation by Harry.
It was very interesting in seeing the disconnect from the marketing coming out of Microsoft and what Harry is actually seeing. The most interesting stat? That Microsoft says that on average, resellers are selling 2 SBS installations a month. From Harry's hands-on research while touring the world and actually talking with the resellers? They are lucky to sell one a quarter! That means there are a LOT more resellers out there than originally thought, and a lot less exclusive SBS-integrators than I was lead to believe.
All and all, well worth the investment in time in coming to the ISV Summit. A lot of eye-opening information on how to work with SBSers, and more importantly understanding the needs of the space. If you are an ISV looking at coming into this space, do yourself a favour and attend the next ISV Summit. You won't be disappointed.
Many thanks to Harry and HP for asking me to come down. I really appreciate it.
March 03, 2005
Cooking and SBS... they have more in common then you think
Harry sure knows how to have a good time. He sent over a town car and took us out to The Blue Ribbon Cooking School where we got to learn the fine art of culinary cooking. We actually prepared and cooked the meal we ultimately ate. And during the process we learned that they actually use Small Business Server 2003 (SBS) themselves!
During discussions with the head chef, I made some interesting corrilations between cooking and how to run SBS efficently. You have to think about your 'ingredients' and get them together before you start cooking. When you begin the cooking process, be patient and ensure you follow the recipe. The result is something you thoroughly enjoy.
But what if you skip a step? Well then things just don't "taste" right. In this case, I am referring to some experiences they have had in the past with their implementation. Quite frankly, it sounds like the "chef" (aka VAR) that did the installation decided not to follow up and see if his "cuisine" was prepared and served correctly. In this case at one point they found they were missing 16 patches, including 7 security patches that weren't even installed on their system. Of course, they took care of that.... but my question is... why didn't the VAR do that in the first place (or at least turn on auto updates)? Automated patch management (with reporting) ISN'T that hard. Why wasn't the free version of Shavlik's HFNetChkPro installed? Heck, the VAR could make incremental revenue streams by having the reports sent to them, and then ensuring that the updates occur on a regular basis.
SBS is a GREAT recipe for many small businesses. But if you forget even a single ingredient, you might find it doesn't taste very well. The VARs in the field managing these systems need to remember that as the chefs, its up to them to ensure the recipe is followed.
Harry, thanks for a great evening. It was a thoroughly enjoyable experience.
SMB Nation ISV Summit - Day 1
So I am down in Seattle attending the SMB Nation ISV Summit. Harry was nice enough to invite me down (thanks to support from HP) and I am very appreciative of the opportunity. My goal is to finally get the answers I have been looking for as it relates to the unit and geographical regional sales numbers of SBS2003 in North America.
At the end of day one, I still don't have the answers. The actual unit number is being side stepped again and again as we talk about the opportunity. I confronted both Microsoft and the Yankee Group (who were presenting their research on this space) on this, to no avail. Actually the Yankee Group wants that number themselves. Come on Microsoft, help us out here. :)
Kinda hard to weight the feasability of the market opportunity when you won't actually tell us what the market size is, and what its REALLY made up of.
The general consensus of the group is that there is approximately 300,000 to 400,000 SBS2003 installs world wide. Where that is broken down is unknown, but there is an expectation the primary areas of density are Austin, Boston and San Francisco in the USA. Of course, no one has any supporting research to back that up.
Outside of that, the day went very well. It was informative, useful and interesting. I can't wait to hear Harry talk tomorrow... since a lot of items brought up were consistantly answered with "I will talk about this in my presentation tomorrow". I can't wait.
I was impressed with how HP is handling the SMB space. I really respect the approach and the attitude they seem to be taking in working with SMB customers, and more importantly, how they work with their development partners to fill that market need. I was REALLY impressed with their DSPP program, especially on how it relates to joint marketing efforts in lead generation. I will have to look into that in more detail.
Well, we are off to enjoy a fun night together where I am sure a lot more interesting discussion will insue. Should be fun. I should get going. Will blog a summary again tomorrow when it ends.