@CyberForge

A New Beginning...

Mon, 23 Feb 2004 23:41:01 GMT

"It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness, it was the epoch of belief, it was the epoch of incredulity, it was the season of Light, it was the season of Darkness, it was the spring of hope, it was the winter of despair, we had everything before us, we had nothing before us, we were all going direct to heaven, we were all doing direct the other way--in short, the period was so far like the present period, that some of its noisiest authorities insisted on its being received, for good or for evil, in the superlative degree of comparison only." - Charles Dickens

It is a time for endings and beginnings.

An Ending - After more than 12 years with my current employer, I gave my notice today. I am looking forward with excitement to what the future brings!

A Beginning – Please join me over on my new weblog (SecureCoder @ http://CyberForge.com/weblog/aniltj/ )

- Anil John

Going Dark....

Tue, 24 Jun 2003 00:05:47 GMT

This weblog is done.... for now.

May I suggest the following resources as alternatives to feed your Secure Coding and Secure Admin Habits:

For those who have become regular readers to learn about security in the Microsoft world, my sincere apologies.

For those who read for other reasons... Y'know, once upon a time, I probably would have had some vitriolic comment here, but these days my kids think that I am the greatest Dad in the world, and their opinions trump yours EVERY time! :-)

- Anil John

Determining an Image's CLR Version

Sat, 21 Jun 2003 00:33:31 GMT

To get it programmatically, from managed code, use Assembly.ImageRuntimeVersion. From unmanaged, use mscoree.dll’s GetFileVersion(). (From the command line, starting in v1.2, ildasm.exe will show it if you double-click on "MANIFEST" and look for "Metadata version".) Those will give you the CLR version that the image claims it wants. However, that’s not necessarily what it was actually built against (compilers can be configured to put any string there).

Also, the CLR version that will be run by an exe is not necessarily the same as what’s in its image runtime version. The chosen version can also depend on its hosting application’s choice, a config file, environment variables, and registry settings. If you need to override those, you can set the supportedRuntime/requiredRuntime in the app.config for the process exe.
[Suzanne Cook's .NET CLR Loader Notes]

Not strictly security related BUT the security capabilities of the .NET CLR is tied to which version you are running. For example, Code Access Security (CAS) is available for ASP.NET applications starting in version 1.1 but is pretty much turned off (runs with FullTrust) in version 1.0. So it would be nice to programmatically find out version of the CLR your server is running :-)

Immutable Laws of Security (and Security Administration)

Fri, 20 Jun 2003 22:48:09 GMT

I came across these again on TechNet. They've been around for some time, but we can all use a reminder now and then.

The Ten Immutable Laws of Security by Microsoft Security Response Center

If a bad guy can persuade you to run his program on your computer, its not your computer anymore.
If a bad guy can alter the operating system on your computer, its not your computer anymore.
If a bad guy has unrestricted physical access to your computer, its not your computer anymore.
If you allow a bad guy to upload programs to your web site, its not your web site any more.
Weak passwords trump strong security.
A machine is only as secure as the administrator is trustworthy.
Encrypted data is only as secure as the decryption key.
An out of date virus scanner is only marginally better than no virus scanner at all.
Absolute anonymity isn't practical, in real life or on the web.
Technology is not a panacea.

The Ten Immutable Laws of Security Administration by Scott Culp (MS Security Response Center)

Nobody believes anything bad can happen to them, until it does.
Security only works if the secure way also happens to be the easy way.
If you don't keep up with security fixes, your network won't be yours for long.
It doesn't do much good to install security fixes on a computer that was never secured to begin with.
Eternal vigilance is the price of security.
There really is someone out there trying to guess your passwords.
The most secure network is a well-administered one.
The difficulty of defending a network is directly proportional to its complexity.
Security isn't about risk avoidance; it's about risk management.
Technology is not a panacea.

Microsoft Product and Technology Security Centers and Security Topics

Fri, 20 Jun 2003 02:19:03 GMT

I was browsing TechNet today and came across these Product/Technology specific Security Centers where you can ".. get in-depth information information about implementing and maintaining security on your server or network."

In addition, there is also a list of Security Topics where you can "... find in-depth information on security issues"

Enjoy!

Good Name

Fri, 20 Jun 2003 01:40:32 GMT

"Regard your good name as the richest jewel you can possibly be possessed of - for credit is like fire; when once you have kindled it you may easily preserve it, but if you once extinguish it, you will find it an arduous task to rekindle it again. The way to gain a good reputation is to endeavor to be what you desire to appear."
[Socrates]

Hacking Bluetooth

Thu, 19 Jun 2003 22:47:53 GMT

... the range is short (2 meters roughly), but how long of a range do you need on a crowded subway? The fine folks at @Stake have released the first known tool specifically targeting Bluetooth. Dubbed "RedFang", the tool is merely a brute-force method of discovering non-broadcasting BT devices. In most cases, the fact that the device is not broadcasting its address is the sole security enabled from the factory, and with RedFang, you can blow right past that. Take for example, the Compaq iPaq, that is set to share out its entire storage subsystem to anyone who knows the Bluetooth address. The article about the project is up on SecurityFocus. It's an interesting read, albeit short. I think we're about to see a big push to test the various security options of Bluetooth. Bluetooth can be secured rather effectively, but we're seeing a lot of implementations that are insecure right out of the box. Have we learned nothing from the "Secure by default" debates?
[bmonday(dot)com]

Scary, considering that a lot of folks synch up their business and personal email as well as contact information and notes with their Bluetooth enabled mobile device without giving any consideration to security. With Microsoft jumping on the Bluetooth bandwagon as well, this technology is poised for wider adoption, which means security needs to be addressed ASAP.

Securing Wireless Networks

Thu, 19 Jun 2003 05:02:39 GMT

There was a question recently posed on one of the security mailing lists that I am on about how best to secure Wireless networks. If you are looking for a Microsoft solution, do check out the following Patterns and Practices guide:

Microsoft Solution for Securing Wireless LANs
http://go.microsoft.com/fwlink/?LinkId=14844

"The Securing Wireless LANs solution provides Planning, Implementation, Operations and Test guides, as well as additional resources including installation scripts, security templates, monitoring scripts, and implementation planning resources.

This solution provides an overview of Microsoft's Solution for Securing Wireless LANs. The solution focuses on Microsoft's approach of using 802.1x authentication, RADIUS and public key infrastructure (PKI) to provide a robust, highly secure answer to the problems of current wireless LAN deployments for organizations ranging from several hundred to many thousand users. It will aid the IT Professional in understanding the design, installation, and ongoing management tasks involved. Topics include: secure authentication of wireless clients using 802.1x, EAP-TLS and Internet Authentication Services, tackling weaknesses in WEP, deploying a PKI with Microsoft Windows Server 2003 Certificate Services, integration with Active Directory and Group Policy, configuration of Windows XP clients, and monitoring and management of these components."

What Matrix Persona Are You?

Thu, 19 Jun 2003 04:30:53 GMT

You are Agent Smith, from "The Matrix." No one would ever want to run into you in a dark alley. Cold as steel, tough as a rock, things are your way or the highway.

What Matrix Persona Are You?

Had to put this in.... :-)

ASP replacement for ISM.DLL (IIS 4 and IIS 5) available

Thu, 19 Jun 2003 03:53:08 GMT

Recently posted to the NTBugTraq list by Michael Howard (Microsoft)

In an effort to provide customers with greater defense in depth, Microsoft has released an Active Server Pages (ASP) replacement for the Internet Information Server 4 and Internet Information Services 5 change password capability, ISM.DLL. This new script code no longer runs as SYSTEM, therefore reducing the attack surface of the Web server. Note that IIS 5.1 and IIS6 do not ship ISM.DLL, they both use the updated ASP functionality.

This package has been tested and approved for use with Microsoft Exchange versions 5.5 and 2000 running Outlook Web Access (OWA).

If you use the password change functionality of IIS, it is HIGHLY recommend you use this new package.

Full details can be found at http://support.microsoft.com/?id=331834

Extending .NET Cryptography with CAPICOM and P/Invoke

Tue, 17 Jun 2003 04:21:10 GMT

Michel Gallant's crypto article is the new feature on the MSDN Security Developer Center. Check out Extending .NET Cryptography with CAPICOM and P/Invoke. Good stuff!
[Brian Johnson]

Nice! As noted in the article, the .NET framework does provide rich crypto support. More information can be found in an earlier article "Protect Private Data with the Cryptography Namespaces of the .NET Framework"

But ".... as a general recommendation for .NET developers building applications using cryptography, if the required functionality is not available natively in the core .NET classes, one should consider using CAPICOM as a first approach. If the functionality is not provided by CAPICOM, then one might consider using P/Invoke with CryptoAPI libraries directly to access the required feature."

Upcoming Security Related Microsoft Webcasts

Tue, 17 Jun 2003 03:49:23 GMT

Designing .NET Systems That Have Enhanced Security
Wednesday, June 18, 2003: 10:00 A.M. Pacific time (Greenwich mean time- 7 hours).
Learn best practices for designing .NET systems that have enhanced security. Hear the basic elements to be considered during the design stage. Get a list of checkpoints to improve architecture security. Learn how to develop assemblies with enhanced security.

Microsoft Data Access Components: Security Features in MAC 2.8
Thursday, June 19, 2003: 10:00 A.M. Pacific time (Greenwich mean time- 7 hours).
This Microsoft Support WebCast provides an overview of the main security features that are introduced in Microsoft Data Access Components (MDAC) 2.8

Writing Security Enhanced Code
Thursday, June 26, 2003: 10:00 A.M. Pacific time (Greenwich mean time- 7 hours).
Learn about writing security enhanced code. Hear about common techniques that hackers can use to compromise software systems. Find out about strategies and best practices to mitigate these threats. Learn about buffer overruns and cryptography hacking.

Encryption, Hashing, Salting, Oh My!

Mon, 16 Jun 2003 02:11:55 GMT

The .NET Framework provides rich support for cryptography via the following name spaces:

System.Security Cryptography - Core classes that provide crypto functions
System.Security Cryptography.Xml - Classes used to encrypt and sign XML documents
System.Security Cryptography.X509Certificates - Classes used to retrieve certificate information

Like anything to do with Security, the crypto field is full of jargon as well. So a few definitions are in order:

Plaintext or Cleartext is just that, something that is plain and has not had any crypto functions used on it.

Ciphertext is output of using some sort of a crypto function on plaintext.

Encryption is the process of smacking the data around so completely, using a specified key, that it basically looks like a big lump of apparently unrecognizable goo (ciphertext). Decryption is the process of taking that big lump of goo (ciphertext), stirring it with a key, and turning it back into the original data (There.. That should be scientific enough for ya!)

Symmetric encryption

The same key is used for converting plaintext to Ciphertext, and back.

Asymmetric Encryption

This is also known as public-key encryption. Instead of one key, you have a pair of keys (called a key pair) that are created at the same time. One key is called a public key and the other a private key. The interesting thing here is that the conversion to Ciphertext is done with the public key and the reverse can ONLY be done with the corresponding private key. There is no way that you can use a public key to decrypt the information. (UPDATE: This is not true, or the whole concept of digital signatures would fall down. It is more accurate to say that anything encrypted with one key can only be decrypted with the other one). So if you wanted someone to send you an encrypted message, you could very well advertise your public key and anyone could use that to send you a message. And you would be the only person who could decrypt that message, because you would have the only corresponding private key!

Hashing (also called a message digest) is a way of producing a fixed size representation of plaintext, which can be of any size. This is a one way process whereby you turn plaintext into unrecognizable Ciphertext! There really is no way to reconstitute the Ciphertext back into plaintext. A good place where you would use this would be for storing passwords. Instead of storing the passwords in plaintext, you could hash them into Ciphertext and store it. When you needed to verify a password, you would use the same hashing function to process the given plaintext password into Ciphertext and compare it to the stored value. If the hash values match, you are golden! If not, the wrong password was entered.

Salting the Hash comes in because hashing by itself has a vulnerability. Most people, when creating something like a password uses alphanumeric combinations that are memorable. (See my earlier entry about how truly bad most passwords are). Which means those passwords are vulnerable to a dictionary attack. A dictionary attack is an attack in which a cracker tries all words and word combinations in order to get a password match.

A salt is a cryptographically strong random number that is combined with the hash to create the final Ciphertext. So in order to compare the given password to the stored Ciphertext, you also need to provide the salt, which makes dictionary attacks a whole lot harder.

Security And Design

Sun, 15 Jun 2003 17:44:38 GMT

This last week I had the pleasure of wandering around Florida speaking with Dan Sandlin and David LeBlanc at a series of Microsoft architecture councils. For those who don't know the name David LeBlanc wrote the very popular book Writing Secure Code with Michael Howard. At each of the session I would do a talk / q&a on P of EAA (which got a JavaWorld award this week) and David would follow on security.

One thing that interested me was that several people found the combination odd - implying that few people would be interesting in two such diverse topics. I think this is at the heart of problems about security in the industry. Security is seen as some separate topic area which sits in its silo. Yet security isn't something you can just add to an application by putting in a few encapsulated classes here and there. Security thinking should pervade a whole team - particularly on applications that are available on the internet or a large corporate intranet.

To be fair there's room for people to focus on security issues. There's a lot of stuff to know about on security. But everyone should have a reasonable knowledge about it. As David points out: many eyeballs don't lead to secure code - you need many educated eyeballs. One of the things I like about David's attitude is that educating developers is a key part of the picture, with less emphasis on review steps with security groups.
[Martin Fowler's Bliki]

Right On! Security should not be something that is bolted on but should be part of the application lifecycle from the start.

BTW, for those not familiar with the name, Martin Fowler is the author of two amazing books, "Refactoring" and "Patterns of Enterprise Application Architecture". And David LeBlanc is the co-Author of "Writing Secure Code"

FxCop 1.2 posted (Security)

Sun, 15 Jun 2003 17:06:12 GMT

Fairly significant update to FxCop was posted today... check it out... Lots of new rules and bug fixes...http://www.gotdotnet.com/team/fxcop/
[Brad Abrams]

Indeed.. Just a recap that "FxCop is a code analysis tool that checks .NET assemblies for conformance to the Microsoft .NET Framework Design Guidelines. It uses reflection, MSIL parsing, and callgraph analysis to inspect assemblies for more than 200 defects in the following areas: naming conventions, library design, localization, security, and performance. The package includes both GUI and command line versions of the tool, as well as the SDK to create your own rules."

To see the list of Security related rules see http://www.gotdotnet.com/team/fxcop/docs/rules/SecurityRules.aspx

Microsoft's Next-Generation Secure Computing Base (NGSCB)

Sat, 14 Jun 2003 18:51:35 GMT

NGSCB Spells Better Security for Windows - eWeek's evaluation of the-technology-formerly-known-as-Palladium, based on stuff Microsoft has published. They point out just how much new hardware will need to be developed to make the scheme work.
[Larkware News]

More information from Microsoft can be found @

Sample Code and Security Awareness

Sat, 14 Jun 2003 14:54:39 GMT

All too often when people are demonstrating sample code, whether you are doing this online or during a presentation, they have a tendency to take the easy way out and use insecure coding for their samples. I've been guilty of that in the past as well. All too often, the the audience may not be aware of the possible security breaches that could occur if they simply copied and pasted our code. I know that Michael Howard of "Writing Secure Code" fame is on a mission to eliminate insecure sample code from both presentations and online samples. From a story that was posted recently by Brian Johnson, it would appear that this awareness is very much alive within MSDN as well. Excellent!

In short, when we give demo's, even though it may be easy or we may think that this is just sample code, just take the extra time to make sure that the sample code is as secure as possible. We cannot judge the security awareness of the audience, so it is better to demonstrate good Secure Coding practices in every piece of code that we show.

Architect Security for Web Services

Sat, 14 Jun 2003 14:20:12 GMT

Take a look at the security challenges of Web services and how to address them with security architecture, including what it can offer going forward when XML traverses firewalls.
[FTPOnline]

Web Services at present are used to a great extent within the Firewall for Application Integration. One of the challenges that need to be addressed to move to a Service Oriented Architecture than spans disparate systems across public networks is the issue of Security. A lot of vendors, particularly Microsoft and IBM are working on this to make this a reality.