May 29, 2004

Comment Spam Sucks

Ok, so I come to my blog this afternoon and find over 1200 comment spam messages in about 4 hours. Not good. My saving grace was Jay Allen's MT-Blacklist plugin, which basically cleared it all out in about 2 passes.

If by some chance a real comment got deleted, I'm sorry. Around they 800 mark I started more skimming the list of spam, and may have missed a real entry or two. Hopefully I got the right regex in place to block the be*stiality and family-r*pe crap out of my system.

If much more of this occurs, I might have to disable comments or something. I would prefer not to do that if I can! If you know the jerks that are doing this spam, please make sure you beat them senseless for me. Thanks.

Posted by SilverStr at 05:21 PM | Comments (4) | TrackBack

May 28, 2004

A .NET Developer's Guide to Windows Security

On the heels of discussion about some good least privilege text that Keith Brown has written (see comments under Longhorn: Adopting a least privilege stance for users), Shawn has pointed out that much of the content of Keith's book The .NET Developer's Guide to Windows Security is still online in an abridged version here.

I would suggest if this topic interests you that you go pick up a copy of Keith's book today! If you are unsure of the content, check out the online content to see the wealth of knowledge it contains!

Posted by SilverStr at 04:08 PM | TrackBack

Book Review - The Product Marketing Handbook for Software

Thought I would change up the entry today and provide a review of a book I just finished reading, Entitled "The Product Marketing Handbook for Software (4th Edition)", it is an indispensable book if you are building or are part of an ISV and want to maximize your sales and marketing efforts.

I quite enjoyed the book. It was a relatively easy read and reinforced a lot of experiences I have learned "the hard way" over the years. I only wish I would have bought this book sooner, as my ROI would have been met many times over in the prevention of stupid mistakes I allowed us to make in the last company I built. More importantly, I now know the "right" questions to ask when wanting to measure results of programs we will execute through our marketing plan at the new company I am building, allowing me to better invest my monies in building both the top and bottom line revenues of the business.

The only complaints I have about the book are on the editing and actual physical delivery of product. I知 not sure a lot of effort was placed in actually editing this book. In NO WAY should I even criticize anyone else's writing since mine can be so poor, but it's my blog so I will :)

I consistently would find incorrect wording throughout the document. The thing was definitely put through a spell checker, but actual grammatical syntax errors kept popping up. I found that this provided for a disjointed read as I would have to reread some sections from time to time to grasp what it was that was being said. For a book in its forth edition, I am only hoping that this was in areas of new content, and not in stuff that has been published for a while.

The second complaint is on the actual delivery and the physical product. I convinced Muckhead to also buy the book and we both got the books in somewhat poor condition. Muckhead's copy was so badly damaged the CD was cracked; the book was torn and quite frankly looked like it was used. Mine was in a little better shape, but not by much. We contacted Rick (the author) and he basically deflected it as an issue with Canada Post. I知 sorry, but I order at least 1 book a month, and this is the first time EVER that I got a book in this condition. The reality is the book should be sent in a protected box, not in an envelope.

All and all, those are pretty petty complaints in comparison to the actual content. I can overlook the condition of the book and even the grammar as I still learned so much from the content. If you are even considering building an ISV that will be selling software, you should buy this book.

So whats next to read? I ordered Coder to Developer: Tools and Strategies for Delivering Your Software last week and hope to start reading it this weekend (assuming it arrived today). Don't worry... I'll post a review :)

Posted by SilverStr at 01:10 PM | TrackBack

May 27, 2004

Making Strings more Secure in Whidbey

Shawn posted an interesting piece on making strings more secure under Whidbey. Using the System.String class has never been considered secure because it was always quite easy for the data to move in memory, potentially leaving a footprint of sensitive data such as passwords in various parts of memory.

In Whidbey, Microsoft has introduced a new object called SecureString that does just that. Using the Data Protection API (DPAPI) the string will be held in memory encrypted until which time it is used, making it much more difficult to read. Further to this the data is pinned, preventing multiple copies to be scattered around in different memory locations. Shawn does a great job of explaining how this all works, so I will leave the excercise of learning just how to use this to you... by reading his post on SecureString.

Posted by SilverStr at 07:56 PM | TrackBack

Longhorn: Adopting a least privilege stance for users

Recently I was talking with Robert Scoble about Longhorn and I brought to his attention some thoughts I had on least privilege for users in Longhorn. He suggested that I post to Channel 9, which I did. Didn't go over well. No one wanted to talk about it.

Today Alan posted a link to what I thought was a ridiculous comment that the disadvantage of running Windows is how infected you get. I am paraphrasing here, as the actual comment was something like "Friends shouldn't let friends run Windows" with a screenshot of Ad-Aware showing a huge number of infections. This is of course ludicrious, as you CAN run Windows securely. Using the same tool I can show my system is free from any crud, and I would bet I am more exposed to hostile code than the original poster ever is.

But it does get back to part of the conversation Alan and I had, which gets back to my comment to Robert about Longhorn. Normal people don't typically run Windows securely. And we need to change that.

When I posted to Channel 9, I basically had a question for the Longhorn crew that relates to user accounts. I am fully in support of the aspect that we should take a stance of least privilege, and run as a normal user whenever we can. Actually, I have been preaching this for a long time (especially for developers as noted in my CodeProject article on developing with least privilege a year ago), and welcomed the approach taken in XP, hold that to some personal gripes on failures in the way runas works. (Which I have blogged about enough here and here)

In Longhorn I would have thought things would be different. Yet over the weekend during a fresh install of Longhorn I came across something that surprised me. Why is it after a fresh install, while logged on as "Administrator" do we feel compelled to make the first user in the system a member of the Administrator group as well? You have no choice.. you MUST make the first normal user an admin. In a client-based desktop, do we REALLY need to have a second "Administrator" account? If we apply the Pareto Principle (80/20 rule) here, in environments where there may only be one user, they will be FORCED to be an Admin, and chances are they will run with those privileges unaltered. In other words, they will be forced to higher privileges than they need right off the first install, and chances are will not make a second account to log in as. Why? Because they haven't been trained otherwise. They won't know any better. And that exposes the computing environment to more risk than is needed.

Might I suggest we rethink this? Why not use secure defaults and make ANY user being added be set to a limited user by default? When we use runas it defaults to "Adminstrator" anyways, so we have the right exposure to elevate privileges when we need to. I can't quite understand what the reasoning is to have another account.

In unix environments we don't have "root" and then "userroot" and then "user". Why do we feel compelled to do this on Windows?

The reality is, until we get people to run as normal users by default, we will continue to see desktops infected through these common attack vectors. Ad-Aware will continue to barf huge numbers of infections until we make it extremely difficult for suspect code and data to even attach to systems that your mom and dad use. It is possible to fix, I just can't understand WHY its not being done.

Posted by SilverStr at 01:18 PM | Comments (15) | TrackBack

Understanding Threat Modeling

I recently stumbled across a couple of resources via some mailing lists describing different aspects of threat modeling. Having it for future reference, I figured I would blog it for everyone:

Posted by SilverStr at 09:21 AM | Comments (5) | TrackBack

Secure programmer: Minimizing privileges

David Wheeler has written a good article on using least privilege in applications. The article discusses how to minimize privileges by minimizing the privileged modules, the privileges granted, and the time the privileges are active. The article discusses not only some of the traditional UNIX-like mechanisms for privileges, but some of the newer mechanisms like the FreeBSD jail(), the Linux Security Modules (LSM) framework, and Security-Enhanced Linux (SELinux).

Minimizing privileges is an important defense against a variety of security problems. Take some time to check out the article and see how that relates to your own work.

Posted by SilverStr at 08:20 AM | TrackBack

May 24, 2004

Microsoft releases new Threat Modeling Tool

I have been waiting patiently for a few months now for Microsoft to release a book written by Frank Swiderski on Threat Modeling.

Imagine my surprise when I heard that Frank has written an actual tool to make the process of working on threat model documents easier!

The Threat Modeling Tool allows users to create threat model documents for applications. It organizes relevant data points, such as entry points, assets, trust levels, data flow diagrams, threats, threat trees, and vulnerabilities into an easy-to-use tree-based view. The tool saves the document as XML, and will export to HTML and MHT using the included XSLTs, or a custom transform supplied by the user.

This looks like a great tool. Time to go download it now!

Posted by SilverStr at 08:15 PM | TrackBack

May 23, 2004

Process Rights Management: Why Whitelists will always trump Blacklists

First off, I apologize for the lack of posts lately. I have been quite swamped rewriting parts of my kernel code and porting some of the backend to Longhorn. Everything seems to be working well, hold that to a phantom bug relating to laptops with the suspend feature, but it is keeping my hands busy in the process.

Anyways, I thought I would give an update on some of the research I am doing, mostly to bring some of my friends up to speed on why I have been hunting for different hardware for different platforms, and stackable multiport KVMs to keep my desktop clean.

I have been spending a lot of time recently working on understanding how my intrusion prevention system for Windows could be improved. I have taken some of the profiling and learning algorithms and played with them in an effort to really understand how to trace the behaviour of applications. Now its time to explain why.

Over the last two years I have been quite perturbed at the the turn around time from patch to exploit. What used to take months (in many cases years) for a response, we are now seeing lazy attackers simply waiting for a patch to come out, disassemble that to find what has changed and then go to town making the next attack pattern. In some cases, we are talking less than 3 days.... way to short of a time period for most organizations with complex patch management roll out strategies.

Patching is only effective when its done, and done so on a timely basis. There are some great companies working on better automatic patching solutions, but they just don't always work in the processes some IT infrastructures have. It is difficult to roll out when it is frowned upon to touch stable servers with untested patches in environments where criticial business resources rely on said servers to stay up.

Tie this issue together with the fact that other tools like anti-virus are only as good as their signature databases, we begin to see that new blended threats are propogating with more complex hydra like hostility, and they need to be repelled differently.

This isn't new. I have discussed the use of infosec principles like least privilege to be used to confine the damage that may be caused by exploited processes, and it was the very principle used when I designed my intrusion prevention system. However, about a year ago when I presented to a group about behaviour based anomaly detection based on whitelists I never expected Microsoft to pick up on it, and announce similar findings to be investigated and installed into future operating systems like Longhorn.

Well, Longhorn is to far off. And people need solutions now. More importantly, users need a concise strategy that is focused on infosec principles that will work now and in the future, across all devices, on different operating systems.

Hence my dungeon work. I have been working on better ways to trace code execution paths and expose just what an application really needs by way of access rights. From files and registry to network access, we need a cleaner way to map the "whitelist" of what applications, services and operating systems do. By properly understanding what an application is supposed to do, we do not have to fear what its NOT supposed to do. When in violates a given behaviour, it can be considered suspect, possibly even hostile, and can thus be blocked.

In other words, the next time an exploited process decides to download a backdoor, we can immediately block this activity from occuring, ensuring the integrity of the system by denying the malicious code from even executing, and take further action to terminate, isolate or investigate the breach.

In this way, we can increase the time for administrators to effectively deploy their patches to vulnerable software and operating systems. It turns the timeline back in favour of the defender, giving us more time to fix buggy software and allowing security companies time to profile new attack vectors and build signature patterns for their IDS, anti-virus engines etc.

Where next? Well, the idea of process rights management comes into play. We can define what an application is allowed to do at runtime, and force those constraints on executing code in any environment. As I continue to work on this it will provide some interesting hooks to operating systems like XP, WS2K3 and Longhorn... exciting stuff for you to see! And now you realize why I haven't had much time to blog much :)

Now please, stop emailing me asking if I am dead. I'm not. I've never felt more alive.

Posted by SilverStr at 11:34 AM | Comments (5) | TrackBack

May 18, 2004

New e-book on Advertising on Google

If you recall way back in January I had a post about an AWESOME resource over at on advertising on google, an excellent resource for a number of the people who read here are also building software startup companies.

Well, Rich announced today that he is publishing a FREE ebook on the topic... but the first edition is going to be in limited quantities, in an effort to get some feedback on it. If it is anything like his online resources, it would be well worth the effort to drop him a line and see if you can get a copy.

I'll do a review once I get a copy myself!

Posted by SilverStr at 10:26 PM | Comments (5) | TrackBack

Microsoft Slide Decks: Updates on NGSCB

In case some of you were not able to attend WinHEC to get the real skinny on the progression of NGSCB (It was funny to watch media spew forth such garbage of it being dead when it truely was not... it was just redefined), Microsoft has now released a bunch of slide decks relating to it.


Posted by SilverStr at 08:33 AM | TrackBack

May 12, 2004

Microsoft Security eLearning Courses

I noticed Michael mention some new e-learning clinics on security that Microsoft is hosting. I was kinda interested in the developer focused one which is Clinic 2806: Microsoftョ Security Guidance Training for Developers.

The layout of the course is pretty good. A quick review of the modules in the course may be in order:

  • Clinic Introduction
  • Essentials of Application Security
    • Welcome to Essentials of Application Security
    • The Importance of Application Security
    • Secure Application Development Practices
    • Security Technologies
    • Secure Development Guidelines
    • Summary

  • Writing Secure Code - Best Practices
    • Welcome to Writing Secure Code - Best Practices
    • Secure Development Process
    • Threat Modeling
    • Risk Mitigation
    • Security Best Practices
    • Summary

  • Writing Secure Code - Threat Defense
    • Welcome to Writing Secure Code - Threat Defense
    • The Need for Secure Code
    • Defending Against Memory Issues
    • Defending Against Arithmetic Errors
    • Defending Against Cross-Site Scripting
    • Defending Against SQL Injection
    • Defending Against Canonicalization Issues
    • Defending Against Cryptography Weaknesses
    • Defending Against Unicode Issues
    • Defending Against Denial of Service
    • Summary

  • Implementing Application Security Using the Microsoft .NET Framework
    • Welcome to Implementing Application Security Using the Microsoft .NET Framework
    • .NET Framework Security Features
    • Code-Access Security
    • Role-Based Security
    • Cryptography
    • Securing ASP.NET Web Applications
    • Securing ASP.NET Web Services
    • Summary

  • Clinic Summary
  • Clinic Evaluation

As you can see this is a well rounded course, well suited to educate the principles of secure programming to many a developer. Almost all of this is covered off in Microsoft's security webcasts, but this structured format might make for more focused instruction for those who don't grasp the concepts that easily.

Well done Microsoft. Education is key when it comes to security, and I like to see offerings like this... especially when its free. Whats this mean to you? It means you should probably go take the course if you are even considering touching code! Knowledge is power and all that. Never say no to free education. And even if you know these concepts... its nice to see how others are presenting the topic... allowing you to learn from the experience and pass it along to your teams.


Posted by SilverStr at 03:05 PM | TrackBack

One Man Star Wars Trilogy Production

Wim was telling me about this awesome one man show where a guy by the name of Charles Ross that is doing a one-hour, high energy, nonstop blast through the first three Star Wars films. The catch is, there's only one cast member... him.

His website can be found over at I found a really good 8 minute "demo" of his triolgy here. Was quite funny. Loved the Jabba the Hut sequence.

Apparently he is working on a One man "Lord of the Rings" show, which could be just as interesting. He is in Vancouver right now performing the Star Wars Trilogy... wish I would have known sooner to try to get tickets. Could be fun.

Anyways, thought I would pass it along. Was worth a quick chuckle.

Posted by SilverStr at 12:01 PM | TrackBack

May 10, 2004

PowerPC Virtual Emulator!

Wow, did I find a cool thing on Sourceforge today. There is a new PPC emulator in development called PearPC that is an architecture independent PowerPC platform emulator capable of running most PowerPC operating systems. That means that you might even be able to run Apple's OSX on a different platform like x86 under Linux or Windows. From the screenshot, they are already doing just that!

I have been looking at the possibility of porting a part of my intrusion prevention and process rights management code to OSX, but don't own a PPC system with enough power to run it. If this project continues to be as successful as it is... I might get a chance in the future.

It's not ready to handle such critical work yet, as the author even admits that there are still unimplemented instructions, mysterious bugs and missing features. There is even a warning to no use it on important data, as it WILL destroy them sooner or later!

Just a matter of time. Damn I wish I had a few extra cycles to help this project out. This would be a kewl project to work on.

Posted by SilverStr at 06:39 PM | TrackBack

May 05, 2004

MSDN Security Slidedecks

If you have followed all the MSDN seminars I have attended, I have tried to keep you up to date with the slide decks. Today Microsoft released 4 of them cleaned up, and in a single place. They are all extremely well done, and something you should take a look at if you have the time.

Posted by SilverStr at 07:27 AM | TrackBack

Comparing W2K and W2K3 vulnerabilities.

During WinHec today Bill Gates showed an interesting slide comparing the vulnerability count between Windows 2000 Server and Windows Server 2003 in the first 365 days. Verdict? 42 for W2K, 13 for WS2K3.

Michael also posted an update on the Windows Server 2003 vulnerability count. Michael says that in the days of Windows 2000 Microsoft only had three ratings: Critical, Moderate and Low; and during the Windows XP and later timeframe they introduced a fourth level - Important, which sits in between Critical and Moderate. When they calcualted the Windows 2000 stats, they applied the same rules as they would have applied if all four levels were in place. In short, they re-evaluated the Windows 2000 bulletins in that time period and determined if each issue was critical, important, moderate or low. No trickery. No fun and games. Just an objective analysis using the same Windows Server 2003 rules.

So there you have it. No conspiracy theory here. And from Bill Gates' slide you can see the difference since Microsoft introduced SD3+C into their operating systems.

Posted by SilverStr at 12:39 AM | Comments (5) | TrackBack

May 04, 2004

A conversation with Bruce Schneier - A Free Webinar

I got an interesting invitation in the email today, followed by a posting by Gary on SC-L about Bruce being interviewed by Software Development Magazine and its going to be broadcast on the web tomorrow. Entitled "Homeland Security and Other So-Called Solutions: A Conversation with Bruce Schneier", it is sure to be an interesting interview.

Here is the original information if you are interested in registering and listen in:

Homeland Security and Other So-Called Solutions: A Conversation with Bruce Schneier

Editor in Chief Alexandra Weber Morales interviews security and cryptography expert Bruce Schneier, author of Applied Cryptography, Secrets and Lies and, most recently, Beyond Fear: Thinking Sensibly About Security in an Uncertain World.

If you're looking for a tech insider's take on homeland security, cryptographer and consultant Bruce Schneier combines an encyclopedic knowledge of security, engineering, history and culture with insight into multiple domains. In this one-hour live interview, Schneier will discuss his five-step process for dissecting security solutions, and then apply that analysis to the FAA's controversial Computer-Assisted Passenger Profiling System, national ID cards, FBI and CIA-level data collection and mining, Terrorist Information Analysis, e-voting and the Department of Homeland Security itself. But that's not all: Schneier will spend much of the program answering your questions in real-time, be they related to application development or geopolitics. Don't miss this special program of fresh and uncompromising insight from the nation's go-to security expert!

May 5, 2004
11 a.m. Pacific


Posted by SilverStr at 02:32 PM | TrackBack

Easter Egg in the software of the BMW M3

Popular Science reports that there's a cheat code in the software running the BMW M3's sequential manual gearbox (SMG): Press the right buttons in the right order and the car will launch you from a stop after revving the engine to 5,000 rpm. But don't look for a how-to in the owners' manual葉his feature is undocumented, an inside joke of sorts.

This is apparently the first easter egg in an automobile. What scares the hell out of me is that this is even in there in the first place. If its software, it can be accessed and exploited. Which means it can be abused. Apparently if you use this cheat more than 15 times, you void the warrently. How do they track that? In flash... which can be tapped.

So what next? The guys over at wonders if we may need Trusted Computing Base for onboard automobile controllers. What do you think?

Posted by SilverStr at 07:54 AM | Comments (6) | TrackBack

NIST releases Draft for Security Considerations for VoIP

NIST has released a draft of Special Publication 800-58 covering security considerations for Voice over IP (VoIP) Systems.

Being over 90 pages in length I will not regurgitate the contents here, but will make the point that its good to see them actually completely thinking it through. I particularly liked seeing that they spent more time assessing the threats of VoIP... and coming to such good realizations such as the fact special considerations should be given to E-911 emergency services comms over VoIP, because E-911 automatic location service is not available with VOIP in most cases. (A very important tool needed in the 911 system if you ask me)

I quite enjoyed more of the end of the document when they profile the attack vectors and give some recommendations on how to defend against it. I would be interested to see what sort of threat modelling they used to come to some of these realizations, as I wasn't aware that similar to ARP cache vulnerabilities there exists the potential of a IP Phone netmask vulnerability by assigning a subnet mask and router address to the phone crafted to cause most or all of the packets in transit to be sent to an attacker's MAC address. Combine that with some funky IP forwarding this would be undetectable and become a passive tap for an attacker or even for law enforcement.

Anyways, its an interesting read if you are considering the security of a VoIP deployment . Enjoy.

Posted by SilverStr at 07:33 AM | TrackBack

May 03, 2004

Why 'Sasser' does not affect Win2003

Michael had a quick blurb on his blog on the fact that with the latest 'Sasser' worm, Windows Server 2003 was not infected. Why? As he says, "Because the RPC interface, which is accessible to anyone (ie; anonymous) on Windows XP and Win2000, was changed in Win2003 so that it requires a local admin to access. Not a remote admin, a local admin using the server's keyboard."

Here is where Microsoft's change in stance in applying infosec principles to the design, defaults and deployment of their operating systems start to show real benefits. The rule of least privilege applies a harness to the RPC interface and lessens the attack surface by explicitly knowing the difference between local and remote admins and confining the abilities of such foreign bodies of code. In this way, attack patterns built into Sasser are useless against Microsoft's latest OS. This is where their policy of "Secure by Default" limits new unknown attack vector such as this.

Are we beginning to see a change? Time will only tell.

Posted by SilverStr at 08:55 AM | TrackBack