Tablet Coming From Apple?

Well, Kevin over at Lockergnome has posted an interesting blog entry about the possibility that Apple might be coming out with a Tablet PC. That could be very interesting... if Apple can make it as slick as the Inking API that Microsoft has.

On that note though... I am not sure how well the whole Tablet idea will work out. Scoble has always drank the MS Tablet Koolaid and spews a lot about it... but I can say first hand after spending a week with him, that it is unrealistic to tout the Tablet as an end all solution. Why do I say that? Because during the whole week I was with him, he didn't use his TabletPC once while I was around. Hell, it wouldn't even boot up when I tried it in his office at Microsoft. When I recommended that we blog while watching a movie (all hail Wireless Access Points!) I was politely told that he only blogs from his machine in his home office. (He has a special Thinkpad dedicated to it). When we were walking around he never carried it with him, even though I had my laptop with me always... and blogged everywhere. (Microsoft has wireless AP almost everywhere I was on campus, which was really nice) His reasonings for why he doesn't use his Tablet were sound.. in that he is never more than 30 minutes from a desktop computer, and he is more productive on those machines, especially due to screen real estate.

But you have to put that into context. He would prefer to be chained to a desktop than the freedom of the Tablet with wireless... because he is more productive on the desktop. And that makes total sense. Dual head 21 inch monitors will typically beat out a single 14 inch lcd for many people... especially when the CPU is slower than most people's regular laptops.

Now comes Apple into the mix. Alan tells me that Expose kicks total butt when it comes to Window management in OSX Panther.... which means that potentially, the workspace productivity hole may be plugged. Who knows. If Apple does come out with this in the new year, it will be interesting to see. I wonder if we would think of it as a Newton on steroids?

Here is a challenge for ANY TabletPC vendor out there that believes they have the end all solution. I write code quite a bit, as well as do security audits and forensic analysis on a regular basis. I take a lot of notes, write documents regularly, do tonnes of flow charting and code to the bone. Lend me a reasonably powerful machine that can handle the likes of Visual Studio .NET, Office XP etc... and I will use it for 1 quarter (3 months) as my primary system. I will blog about my experiences on a regular basis and show everyone an unbiased view on how productive it can be for regular technology power users like myself. It doesn't have to be the prettiest thing, and it doesn't have to be new. But it has to be what you are selling to customers like me.

Why the challenge? Because it is safe to bet no one will take me up on it. (That and I doubt any Tablet companies read my blog). If someone does, I would really like to put it through the paces... and possibly end with writing a few Inking apps that would be useful for me in my field of work. I know a few other information security professionals that have thought of using a Tablet during vulnerability assessments and site surveys... and what would be a better recommendation than from their peers?

If you want to take me up on my challenge, fire me an email. Please don't fire me emails if you are going to expect me to hail to the godliness of your TabletPC use... as I heard that already from Robert.... yet never saw him use it once. Proof is in the pudding. And I would prefer to eat my own.

Truth About AntiVirus Vendors?

Sometimes I wonder if there is any truth to that. :)

Cell Phone Security Weakness: DoS via SMS

Now here is something I haven't thought about until today. Apparently cell phone providers do not currently have a way to block SMS messages during an attack... which means you can launch a Denial of Service by flooding a cell phone with text messages. What is worse is that while these messages are coming in (and you try to clear them) your phone cannot be used for sending or receiving calls.

Security of handhelds are far too lax, and this is something I have been considering for a while now. My own Intrusion Prevention System could easily be ported to PocketPC, but I haven't figured out if anyone would actually BUY it. I am waiting till the main product launch before I do some market research to see what the market thinks. Sometimes I think the attack vector is huge with these things.... kinda like the old modem back doors in corporate networks. I beam you a trojan.. wait till you sync to your desktop... and then go to town.

So, if you have SMS... you might want to turn it off. Especially if you get billed for each incoming message. Nothing like being DoS'd and then getting a bill for $50 in messenging charges to boot!

GnuPG's ElGamal signing keys compromised

Well, if you haven't heard, GnuPG's method of signing keys with ElGamal has been compromised. This is a significant security failure which can lead to a compromise of almost all ElGamal keys used for signing. Note that this is a real world vulnerability which will reveal your private key within a few seconds. This ultimately means that if you used ElGamal.... consider all your secured emails, documents etc compromised... since we can get your private key within seconds.

I have checked my own keyring, and the 2 people on it that used ElGamal have been notified. You will find none of the keys I use are compromised, since I used RSA.

If you want to read the actual message sent to the world about this... read on.

----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

GnuPG's ElGamal signing keys compromised
==========================================

Summary
=======

Phong Nguyen identified a severe bug in the way GnuPG creates and uses
ElGamal keys for signing. This is a significant security failure
which can lead to a compromise of almost all ElGamal keys used for
signing. Note that this is a real world vulnerability which will
reveal your private key within a few seconds.

Please *take immediate action and revoke your ElGamal signing keys*.
Furthermore you should take whatever measures necessary to limit the
damage done for signed or encrypted documents using that key.

Please do not send private mail in response to this message as I won't
have the time to catch up with all the messages. The mailing list
gnupg-users at gnupg.org is the best place to discuss this problem
(please subscribe first so you don't need moderator approval [2]).

Note that the standard keys as generated by GnuPG (DSA and ElGamal
encryption) as well as RSA keys are NOT vulnerable. Note also that
ElGamal signing keys cannot be generated without the use of a special
flag to enable hidden options and even then overriding a warning
message about this key type. See below for details on how to identify
vulnerable keys.

This message is signed using the usual GnuPG distribution key[1]. I
apologize for this severe bug and all the problems resulting from it.


Background:
===========

For historic reasons [3], GnuPG permits creating ElGamal keys which
are usable for both encryption and signing. It is even possible to
have one key (the primary one) used for both operations. This is not
considered good cryptographic practice, but is permitted by the
OpenPGP standard.

It was not anticipated that these keys would still be used for signing
because they have several disadvantages: The signature is much larger
than a RSA or DSA signature, verification and creation takes far
longer and the use of ElGamal for signing has always been problematic
due to a couple of cryptographic weaknesses when not done properly.
Thus I have always dissuaded people from using ElGamal keys for
signing; however they are still used and about 200 keys per year are
generated and uploaded to the keyservers.

In January 2000, as part of version 1.0.2, the GnuPG code was changed
to create ElGamal keys which work more efficiently for encryption
(selecting a smaller x secret exponent and using a smaller k for
encryption). While making this change the problem with signing keys
was accidentally introduced: the same small k for encryption was also
used for signing. This can be used for a cryptographic attack to
reveal the private key (i.e. the secret exponent x) if a signature
made using that key is available. Such a signature is always
available for primary ElGamal keys because signatures created with
that key are used to bind the user ID and other material to the
primary key (self-signatures). Even if the key was never used for
signing documents it should be considered compromised.

Note that this weakness does not apply to the far more common
encrypt-only (type 16) ElGamal key as GnuPG does not permit signatures
to be issued by this key type. Only the ElGamal sign+encrypt key
(type 20) is affected and then only when used to make a signature with
a GnuPG version 1.0.2 or later.


Impact:
=======

All ElGamal sign+encrypt keys (type 20) generated with GnuPG 1.0.2 or
later must be considered compromised. Keys generated and used only
with prior versions might still be safe but should ideally be revoked
too. Note that even if an ElGamal sign+encrypt key was generated
before GnuPG 1.0.2, using that key in GnuPG 1.0.2 or later to issue
signatures will still compromise the key.

Again, ElGamal encrypt-only keys (type 16) from any version of GnuPG
are *not* affected.


Solution:
=========

Do not use *ElGamal sign+encrypt keys (type 20)*. Revoke all those
keys immediately. Consider all material signed or encrypted with such
a key as compromised.

Forthcoming GnuPG versions will remove the ability to create such keys
and the ability create ElGamal signatures.


How to detect ElGamal type 20 keys:
===================================

We have to distinguish between two cases: The primary key is ElGamal
sign+encrypt versus just a subkey is ElGamal sign+encrypt.

The first case requires immediate attention, like this one:

$ gpg --list-keys xxxxxxxx
pub 2048G/xxxxxxxx 2001-xx-xx Mallory

such a key might be followed with additional "uid", "sig" or "sub"
lines. Here an ElGamal sign+encrypt key is used and very likely
created with GnuPG >= 1.0.2. The capital letter "G" indicates a
ElGamal sign+encrypt key. REVOKE such a key immediately.

The second case is about subkeys. Here is an example:

$ gpg --list-keys 621CC013
pub 1024D/621CC013 1998-07-07 Werner Koch
uid Werner Koch
uid Werner Koch
sub 1536g/ADF6A6E1 1999-02-20 [expires: 2002-11-01]
sub 1536G/B5A18FF4 1998-07-07 [expires: 2002-07-06]
sub 1536R/23D2A63D 2002-07-30 [expires: 2003-12-31]

This my usual working key, which is a standard GnuPG key with some
additional subkeys added over time. It is a good example because one
subkey was created as type 20 signing and encrypt ElGamal key. It is
the second subkey:

sub 1536G/B5A18FF4 1998-07-07 [expires: 2002-07-06]

The capital letter "G" denotes such an possible compromised subkey
whereas the first subkey:

sub 1536g/ADF6A6E1 1999-02-20 [expires: 2002-11-01]

is a standard encryption-only subkey as indicated by the small letter
"g". That key is not affected.

The keys denoted with this capital letter "G" should be REVOKED unless
you are definitely sure those subkeys were never used to create a
signatures with GnuPG >= 1.0.2.


How to revoke a key:
====================

To create a revocation certificate for the entire key (primary and
all subkeys), you do:

gpg --gen-revoke your_keyid >foo.rev

If you have lost access to your passphrase, hopefully you have a
pre-manufactured revocation certificate (either on a floppy or printed
on a sheet of paper) which you may the use instead of the above
command.

This revocation certificate should then be imported into
GnuPG using:

gpg --import mykey.asc

gpg --keyserver subkeys.pgp.net --send-keys your_keyid


If your primary key is not an ElGamal key, you might need to revoke a
subkey. Note again that only type 20 ElGamal keys (denoted by a
capital letter "G") require revocation - the standard ElGamal
encrypt-only key (small g) is perfectly fine. Use gpg's edit command
like this:

$ gpg --edit-key xyzxyzxy

The key listing will be shown. Select the subkey you want to revoke,
using the command "key 2" (or whatever subkey it is) and then enter
the command "revkey" and follow the prompts. Continue then with an
export as described above.


How many keys are affected?
===========================

I can't tell for sure. According to the keyserver statistics, there
are 848 primary ElGamal signing keys which are affected. These are a
mere 0.04 percent of all primary keys on the keyservers. There are
324 vulnerable subkeys on the keyservers, too.

Some of the subkeys might have never been used for signing because for
some time in the past GnuPG created the encryption subkey as type 20
but didn't used it for signing because the DSA primary key was used
instead. It is better to revoke such keys nevertheless.

Note again that the standard configuration of GnuPG does not allow
creating the vulnerable sign+encrypt ElGamal keys and that neither DSA
(type 17), RSA (type 1) nor ElGamal encrypt-only keys (type 16) are
affected.


Thanks
======

Phong Nguyen [4] analyzed the implementation of GnuPG's cryptographic
parts and found this vulnerability. He also developed actual code to
mount the attack and was so kind to give me enough time to have a look
at his paper and to gather a list of known type 20 keys owners.


I am really sorry for this,

Werner


[1] To get a fresh key you might want to consult the keyservers or get
it from using "finger wk at g10code.com" or "finger dd9jn at gnu.org".
[2] See http://lists.gnupg.org/mailman/listinfo/gnupg-users .
[3] The patent status of DSA was not clear when I started to write
GnuPG back in 1997.
[4] Working at the French National Center for Scientific Research and
the Ecole normale superieure: http://www.di.ens.fr/~pnguyen/ .
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/xavwaLeriVdUjc0RAquhAJ9crSJ2j8EbqaAnbJGoXBsgERPLaACePwcP
70laYWsyhXkzVgqL2X4ELVk=
=xGWG
-----END PGP SIGNATURE-----

Powers of Regex() in C#

Well today has been a good coding day. I just refactored a section of my code from just over 900 lines to that of just under 100, thanks to C#'s Regex() class. I am so bloody proud of that I just had to tell the world.

Well more to the point, I wanted to blog it so others can learn from my mistakes.

I won't go directly into my code, but will quickly state that it was 900 lines of lexical analyzer goodness... or badness.. depending on who is reading it. I was reading in a custom configuration file and trying to break it down into smaller tokens so I can deal with it. The parser was huge... mostly because this code was ported from C where I HEAVILY used pointers to deal with the slide and compare routines.

Now enough about my code... and onto why C# Regex() rocks. I don't need to discuss WHY Regex() is important (I have done that before, and you got that you need to treat all input as malcious until validated otherwise RIGHT???).. but I want to teach you about a neat little feature that makes it a $DEITY send. It's called named groupings. With it, when the regular expressions are ran through... it will take the named group construct and capture substrings if and when they match. What is nice about this approach is that you can use it find an exact pattern match, and then break it down into its child substrings directly without having to parse it out. Pretty sweet if you ask me! Everything is stored in the resulting Match.Groups[] array, which can be queried by passing the named group. The construction of a named group is quite easy.... its just (?<named_group>expression).

Let me show you a simple example of how to use this. Lets say you want to parse out a simple line that holds a string value, and then a numeric ulong value which is in circle brackets. ie: foo(1)

Here is how you would do that:


string line = "foo(1)";
// I need to escape the brackets here
Regex pattern = new Regex( @"^(?<my_str>\S+)\(?<my_ulong>\d\)$", RegexOptions.IgnoreCase );
Match match = pattern.Match( line );
if( match.Success )
{
string parsed_str = match.Groups["my_str"].Value;
ulong parsed_num = ulong.Parse( match.Groups["my_ulong"].Value );
}


Ya ya ya... I should be catching the Parse() exception... but that was not added for clarity. You get the idea though. Within a few lines you got properly validated data directly through the Regex()!

Now... lets make this even easier. I found a sweet tool from Rad Software that is perfect for building these regular expressions with named groupings called RegEx Designer and its FREE! It allows you to quickly test different regex and see the results immediately. Thanks for the tool guys!

All and all this has made my day. Any time you can reduce the amount of code and thus reduce the potential bug surface... you are having a great day. Especially when I shrunk it by a factor of 9 times! And its quite easy to review and manage... which makes it all the more interesting.

So if you haven't had a chance to check it out... give it a try. Regex() and "named groupings"... a great combination!

Empower Program for ISV Update

HOLY CRAP.

I just noticed that as of yesterday, Microsoft has reduced its membership fee for the Empower program I talked about to $375 until the end of the year!

You have to pay the $795 up front, but they will refund you the difference within 6 to 8 weeks.

Way to go Microsoft!

Quote of the Day

"God invented SCO to give people a company to hate more than Microsoft."

You know... I can almost believe that. Now the theory is that they might wanna go after google.

Microsoft's ICF is getting a facelift?

Well rumour has it that Microsoft is giving their Internet Connectivity Firewall (ICF) that is part of Windows XP and new facelift... all part of the Springboard (XPSP2) release next summer.

For starters, Microsoft has instructed OEM partners to turn on the firewall by default on all new Windows XP-based system to guard against the spread of viruses. It's about time!

Apparently ICF will be updated to close ports when they aren't in use and to improve the user interface for configuration. Thats good to know.. the current UI sucks. Additionally, they are adding improved application compatibility when ICF is on, and enhanced enterprise administration of ICF through Group Policy. Thats a nice touch.

I'll reserve judgement till I see it... but if they actually do this... its a good thing. (Sorry Martha)

Security Hole in MoveableType

It was found today that MoveableType has a hole in mt-send-entry.cgi which allows an attacker to add multiple recipients... which means they can use your blog as a spam relay. Oh how quaint.

The fix:

Solution 1: Add the following code to only allow one recipient right after the unless() block in the eval function:


# davel fix: disallow multiple $to recipients
if ( ($to =~ tr/@//) > 1 ) {
print $q->redirect($redirect);
exit;
}


Solution 2: Add the following code right after the use strict; line to disable the script:


print "Content-Type: text/html\n\n";
print "Disabled for security reasons";
exit;


I haven't seen a fix yet from MoveableType, nor have I seen anyone do a code audit to check for similar attack vectors in other scripts. Keep alert, hopefully there will be a vendor patch soon for any and all holes relating to this.

Understanding Secure Computing Base

Today Alan was showing a bit of paranoia talking about how BIOS manufacturers are putting in new features that will create the first stages of the chain of trust for "trustworthy computing".

I would like to respond to his comments by explaining WHY the idea of the Next Generation Secure Computing Base (NGSCB) should be embraced and not frowned upon. Even if it is coming from Microsoft.

First off, let me be clear. Trustworthy Computing does not have to be looked upon as a Microsoft thing. The idea is being leveraged by many vendors. I had a chance to talk to one of the guys dealing with it at Seagate when I was at the DevCon presentation of NGSCB. Microsoft is just one of the first vendors that is actually making it part of the operating system in Longhorn.

Let me give you a practical scenerio of where Trustworthy Computing is vital to a secure computing environment. If you may recall from previous months, there was an attacker by the name of Juju Jiang who placed a software keystroke logger at various Kinkos in New York to hijack their passwords and other vital information. There have been other attacks who have done the same thing with hardware keystroke loggers at other public terminals (like libraries). These are hard to detect at times, and can be easily planted by attackers with very little experience or expertice.

Here is where NGSCB comes into play. Lets first talk about the problem with the existing system. If you can get code into the Windows kernel (a software driver as an example), the system can practically be owned at that point in regards to this. The reason is that pluggable kernel components can access literally any memory and scrape any data they want. What NGSCB can do is partition the execution environment by adding a mechanism (with the help of a new mode flag in the CPU) which can determine if access is trusted or not, and can set up memory so that it can ONLY be accessed by trusted components. If you don't understand what I mean, don't fret... let me take our example and follow it through.

Right now in existing operating systems, some sort of keyboard driver will translate the keystrokes coming down the wire into characters and pass it where it needs to be. Of course, anywhere between the driver and the keryboard can be compromised. It's not TEMPEST. You can tamper with the physical cable, between the cable and the keyboard port, or directly in the software. Now imagine this scenerio to fight this:

1. The keyboard and OS are NGSCB aware.
   
2. They have been configured to work together. (Leave the discussion for HOW that happens another day)
   
3. The keyboard will ENCRYPT all keystrokes and ensure the integrity of the data with a message digest and send the secure payload to the OS.
   
4. The OS kernel driver for the keyboard receives the data. The keyboard driver is untrusted, and can do nothing with the data except drop it. Ok. Denial of service if this is a rogue driver. But nothing else can happen. No information disclosure. It can't read the information. A proper keyboard driver would see this special payload and transfer it to the trusted environment through the use of a secure conduit transport. (Microsoft calls their particular environment Nexus, and have easy to use API to accomplish this)
   
5. Here the trusted computing base can pass the payload to the proper secure driver, in this case a secure keyboard driver that can verify the integrity of the data and unencrypt it. It can then determine what information can be passed back to the untrusted kernel. Microsoft calls these drivers agents, or more commonly NCA. In the case of password management, they can verify passwords securely on the trusted side, and just pass back particular results to the untrusted side.
   

At this point... both software and hardware keystroke loggers become useless. They can do very little but record the encrypted payload. (Of course they could try to brute crack this.. but a good design would account for this). It's actually quite a neat design... except that you have to trust the "trusted code base". Of course, you don't HAVE to. You could replace Microsoft's Nexus with your own. And from my understanding they are making provisions for that in Longhorn. But should I trust you any more than Microsoft?

I am over simplifing what the NGSCB is, but my point is that its actually a good thing. Imagine another scenerio. You have a secure application in which you do not wish rogue application to be able to "automate" or replay. Currently you can actually script with the Win32 API ways to automate button presses, keyboard input etc to completely act as a logged on user to perform actions... attacks which I HAVE seen in the field. One such example would transfer money from one bank account to another without the teller knowing. Anyways, you can write a video driver and a mouse driver that support NGSCB and have it so that when a mouse enters a particular region on screen (say, the region of the secure application window) that all mouse movements and actions (button clicks) are encrypted and cannot be seen by the base operating system. Now there is no way for any foreign access to the application. Moreover, the trusted window can be drawn differently to denote it (imagine if all trusted windows had a red border drawn by the video driver so you KNEW what information was classified as protected/secret or above? Kinda neat if you ask me.) You can do some pretty kewl stuff with this.

There is still work to be done on the NGSCB, and I hope it is audited by a third party, similar to how the security framework for .NET was reviewed. But all in all, you can take advantage of the new secure computing base with properly designed drivers. Of course, you can just install a different OS that ignores all this.... including the issues with the bios.

I only hope I get to take part in building some of these applications with the NGSCB. I think it will be a lot of fun... and can already imagine a few great applications for secure terminals for military and government operations. Dunno if the commercial world would buy them though. Guess time will tell how this all unwinds itself.

Secrets of Computer Espionage: Tactics and Countermeasures

I just finished reading an interesting book report on a book I haven't heard about before called Secrets of Computer Espionage: Tactics and Countermeasures.

Sounds like a really good book. Note to anyone who would like to buy me a christmas present. This would be a GREAT gift!

Navy Deploying Its Battle Plan: SAML

Just read an interesting article on how the US Navy is using the Security Assertion Markup Language (SAML) to implement single sign-on. If you recall, I talked about SAML last month, and it seems that implementations like this will go a long way to help the technology.

They claim they will be able to save over a billion dollars on their intranet alone with this approach. Now if that isn't an ROI... I don't know what is.

CERT issues Quarterly Summary of Top Incidents and Vulnerabilities

CERT issued its quartly report today to draw attention to the types of attacks reported to their incident response team, as well as other noteworthy incident and vulnerability information. The summary includes pointers to sources of information for dealing with the problems.

No real suprises. Here is a quick recap for those with their heads in the sand for the last quarter:

1. W32/Mimail Variants
   
2. Buffer Overflow in Windows Workstation Service
   
3. Multiple Vulnerabilities in Microsoft Windows and Exchange
   
4. Multiple Vulnerabilities in SSL/TLS Implementations
   
5. Exploitation of Internet Explorer Vulnerability
   
6. W32/Swen.A Worm (Personal note: I HATE this one)
   
7. Buffer Overflow in Sendmail
   
8. Buffer Management Vulnerability in OpenSSH
   
9. RPCSS Vulnerabilities in Microsoft Windows
   

Happy reading. Make a game of it... figure out how many of these impacted your office, and how much the associated costs were. Now imagine if you got 5% of that as a Christmas bonus. Sickening... isn't it?

Security At Microsoft

I know I talked about this a few weeks ago, but if you haven't had a chance, you should really read up on how Microsoft is dealing with security in their own organization.

Today I found a different copy of the paper that is more web centric.

It's a good read. Take some time and check it out.

Finance for Geeks

Eric just had a piece published on MSDN about Finance for Geeks. I like the way he writes, and he has a lot of good pointers.

If you are building your own ISV, you might find this article interesting. (/me looks at Arc and Muckhead)

Trusting Certification Authorities

Today joat talked about CACert.org and the fact they are an issuer of free SSL certificates. This is a topic that drives me batty, because anyone with a Linux box and OpenSSL can build their own root certificate and then blast out certs till they are blue in the face. Arc does this for ufies.org, which isn't a bad thing. Just pointless. No one outside of the ufies community will trust his root cert. But for his application and use, he doesn't care. Nor should he. It is an effective way to use OpenSSL and generate trust amoungst that community.

The problem about this sort of approach is trust. If you want to be your own CA, all the power to ya. If you admin the machines, you can add your own root server during install and have the level of trust that you want. Hopefully you have enough common sense to properly protect the private cert (you lose that and the whole chain of trust is toast) However, this isn't practical for most people that use digital certificates. Especially when driving ecommerce or secure web traffic (HTTPS).

Verisign has made big bucks on web identity trust. As they should... they cornered a market way back when and are now branded as the "SSL Cert Provider". What people don't realize is that there ARE alternatives that are just as trustworthy. Especially with the recent business practices Verisign has tried to do. Maybe you heard about it?

One of the Certificate Authorities I believe isn't getting the credit they deserve is The Comodo Group. They have earned the WebTrust Seal with auditors of KPMG, and have a root cert in almost every browser currently on the market, which means they have over 99.3% browser coverage. This result is that for almost every customer you will NOT have to install a root cert which is inherently untrusted... and makes a more seamless experience for your customers/employees.

Further to the fact you can trust this root cert more than home grown CAs, and the fact that it is ALREADY in the root cert pool in almost all your software, they come in at a reasonable cost. You can get a 2 year cert for $139. Compare that to the $1,595 you would pay Verisign (I am using a 2 year, 128bit SSL cert for a fair comparision)... you can significantly see the ROI by doing your homework. What is more interesting is that because Comodo automates a lot of the cert publication itself, you can further get that reduced if you know about their reseller program.

If you search around, you will find you can get a 1 year cert from places like InstantSSL for $49 a year. This is a 128bit SSL cert signed by Comodo, and is trusted in over 99.3% of the browsers currently on the market. It does not include the Site seal, but you can get that for another $20. I found a good price comparision chart to show their different services with costing... just so you can verify it for yourself.

So don't fret about Verisign gouging you... and don't trust weak certificate authorties like CACert. Spend some time, do the research and find a provider that is in the current root cert pool and check their credentials. After all, a CA is all about trust... you can't leave that to other people blindly.

Now, before I get bombarded with nastygrams from CACert lovers, let me be clear. I like what they stand for. And I appreciate the efforts. But as a security professional I must state that trust has to be earned and verified. Until you are vetting through an authority I will trust (start by gaining Browser vendor's trust by getting added as a root cert) I can't seriously recommend you as a service. Lets forget about the debacle on the front of your website where you do not trust your own content on your website and are telling everyone that because you can't trust your own stuff, you are taking it down. How can I trust you if you can't trust yourself? It is nice to see you take those actions (which was the responsible thing to do)... but they shouldn't have gotten there in the first place.

All and all, if you need a digital certificate, consider checking out Comodo. It's fast, secure, cost effective and above all... trusted.

Personal Firewall Day

Based on an idea driven at the NTBugtraq party (wish I would have been able to get there*sigh*) Paul Robertson has articulated his ideas and set a tentative data of January 15th, 2004 for Personal Firewall Day. He wrote a piece about it in Information Security Magazine's Security Wire Daily mailing list, which you can read here.

So join the fun, and help promote Personal Firewall Day!

Secure Coding: Using Restricted Tokens to execute a Process

Back at the beginning of the month I gave a tip on spawning external processes securely in Windows, and recommended that developers look at using the CreateRestrictedToken() API to restrict access of a process. I have received a couple of emails on this (why don't you guys ever want to comment on my blog?) with one email asking just how to do this using a restricted token.

I am frustrated with some of my own code right now (lets just say C# isn't all that its cracked up to be at times... I spend more time P/Invoking than anything else) and figured may as well be useful to someone and answer his question. So just for you Dennis.... here is a brief tutorial on using restricted tokens.

First off, lets set some ground work here. When possible, you shouldn't HAVE to run with elevated privileges to do things on Windows. If you are willing to accept this instead of fighting it... you will go a lot further. I met a couple of Microsoft employees at DevCon that continue to fight the idea that you need to be admin... and that runas sucks (well, they got me there.. the current implementation of runas DOES suck. I think I have bitched about that a couple of times.) The point is, you shouldn't have to settle for a weaker security posture cuz its easier. Learn how to use least privilege correctly. As a developer, you might want to read my old CodeProject article on how to develop code while running with least privilege, as this can give you some examples on how to debug issues you may have.

Anyways, with an open mind and a desire to run your code more securely, lets talk about restricted tokens. Since Windows 2000 Microsoft has given you the ability to take a user token and restrict its capabilities. (Michael Howard once called it "Dumbing down a process" which is right on the money). A process (or even an individual thread for that matter) that is running in the security context of a restricted token will be restricted in its ability to perform privileged operations, or access securable objects within the system. In this way, you can limit just what an application can do, even when launched in an elevated environment. Or better yet, lets reverse that.... you can launch in a lower security context and promote particular sections of code to run with elevated privileges (although restricted in its focus to only do what it needs to.. the whole point of least privilege). In this way, you reduce the attack surface of the application by limiting the context in which code can run.

As an example, if your application only ever needs to READ a particular key from a registry hive that requires admin privs.... why not give you just enough privs to do so... you don't NEED to write to it. (Lets ignore the fact you can apply an ACL to this particual key to give you this particular access for a moment). This is exactly what restricted tokens were designed to do.

So lets quickly look at the prototype of CreateRestrictedToken():

BOOL CreateRestrictedToken(
HANDLE ExistingTokenHandle, // Handle to Token. Usually easy to get with OpenProcessToken()
DWORD Flags, // Flags. We want DISABLE_MAX_PRIVILEGE
DWORD DisableSidCount, // Number of SIDs to disable
PSID_AND_ATTRIBUTES SidsToDisable, // The list of SIDS
DWORD DeletePrivilegeCount, // Number of privileges to disable
PLUID_AND_ATTRIBUTES PrivilegesToDelete, // The privileges we are going to disable
DWORD RestrictedSidCount, // Number of SIDs to restrict
PSID_AND_ATTRIBUTES SidsToRestrict, // SIDs to restrict
PHANDLE NewTokenHandle // Pointer to a HANDLE that we will get back
);

If you are asking yourself "what the heck is a SID", its a Security ID, which is used to uniquely identify users or groups. More technically, its really a variable length structure holding specific information about a user or a group.

In many instances, many of the fields can be set to 0 (more specifically, the 3rd through 8th field can be) if you don't care to use them. Each implementation will be different, based on what you are trying to accomplish.

Instead of blabbing any more, why don't I show you a brain dead example of how you would create a restricted token and create a new process using that (since that what Dennis asked for anyways):

HANDLE hProcessToken;
HANDLE hRestrictedToken;
// First step is to open the current process and grab its primary token
if( !OpenProcessToken( GetCurrentProcess(), TOKEN_DUPLICATE | TOKEN_ASSIGN_PRIMARY, &hProcessToken ) )
{
// Some witty error handling. GetLastError() holds why it failed
}
// Second step is to create the restricted token
if( !CreateRestrictedToken(hProcessToken, DISABLE_MAX_PRIVILEGE, 0, 0, 0, 0, 0, 0, &hRestrictedToken ) )
{
// Again, some witty error handling. GetLastError() holds why it failed
}
// Third step is to execute a new process with this restricted token.
// I am using fake vars for demo here... read up on this API call to see what
// they are for.
if( !CreateProcessAsUser( hRestrictedToken, path_to_exe, cmd_line_args, NULL, NULL, FALSE, CREATE_NEW_CONSOLE, NULL, NULL, &startupinfo, &processinfo ) )
{
// We are so witty, so witty, la la la. GetLastError() blah blah blah
}
// Last step, clean up your mess!
CloseHandle( hRestrictedToken );
CloseHandle( hProcessToken );


Thats it! When CreateProcessAsUser() executes, it will execute with a lower set of privileges than the parent process. To be useful, you would probably use the AllocateAndInitializeSid() function and modify the SID to use with CreateRestrictedToken(), (ie: Create a deny-only SID for the local account) but I don't want to do ALL the work for ya.

Hope this was helpful. Its just not that hard. Now go try it!

SOAP Data Injection Attacks

SPI has released a paper on attacking web services using SOAP, showing how to use injection techniques to taint workflow and attack weak implementations.

I have never liked SOAP (mostly because of its complexity wrapped up in XML) and papers like this show how data injection techniques are just as easy with SOAP envelopes as they are with traditional techniques.

Happy reading!

Firewall Forensics: How to Read your Logs

I just found an interesting article that is well detailed and broken down so you can understand just how to read your firewall logs.

To be honest, if you are somewhat new to firewalls and don't know a lot about ports, this is a great document for you. Not a lot of new info here for old hats, but its never a bad thing to refresh your mind!

Happy reading!

Step-by-Step Guide for Setting Up Secure Wireless Access in a Test Lab

Microsoft has released a white paper today describing how to configure secure wireless access using IEEE 802.1X authentication using Protected Extensible Authentication Protocol-Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MS-CHAP v2) and Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) in a test lab using a wireless access point (AP) and four computers.

For you wireless security folk, this might be of interest.

Gates Sets Schedule For Security Improvements

CRN reports (thanks to InformationWeek) that Bill Gates believes that businesses should see a 180-degree improvement in the security of their Windows software environments within eight months.

Although Microsoft's Trustworthy Computing initiative is a multiyear effort, Gates says bug-weary customers will get relief in months, not years.

During an interview with InformationWeek, Bill was even quoted as saying: "By the middle of next year, I think even our critics would say, 'Wow, they've really turned this patching thing around...This is night-and-day different. This is not a big problem for us'".

Guess we will find out... in 8 months.

Microsoft Security Webcast Week

In the first week fo December, Microsoft will be hosting 1 week chalked full of webcasts relating to security. They have a goal of training 500,000 in the coming year about security. The TechNet Security Webcast Week spotlights TechNet’s continuing webcast coverage of one of the hottest topics for IT professionals today.

You should check out some of the topics on the agenda:

• ShopTalk: IT Security Webcast
  
• Using Portable Handheld Devices in a Secure Manner
  
• Secure Network Access
  
• Designing a Secure - Reliable - and Usable Patch Management Infrastructure
  
• Securing Your Exchange 2003 Environment
  
• Effectively Using IIS Security
  
• Penetration Testing, Vulnerability Scanning, and Security Auditing
  
• Using the Microsoft Security Tools
  
• Safeguarding Information with Windows Rights Management Services
  
• Microsoft Windows Server 2003 Security Enhancements
  
• Software and Patch Management with Software Update Service, Windows Update and SMS
  
• Demystifying IPsec
  
• 10 Things Hackers Don’t Want You To Know
  

Education is a significant role of the security management life cycle, and its good to see Microsoft step up here. Since most news coverage is void of things Microsoft is doing right, I will applaud and say "it's about time".

If you have the time, check out some of the sessions.

SSL VPN Reviews

SecurityPipeline Magazine has published an article (courtesy of Network Computing) that breaks down some of the SSL VPN servers on the market and rates them.

If you haven't looked at this technology, you might want to. SSL VPNs eliminate nearly all the problems associated with IPsec and PPTP VPNs. The term SSL VPN is a bit of a misnomer, however. A VPN typically establishes the remote client as a node on the protected network; an SSL VPN extends secure access to protected resources for remote users.

With most firewalls allowing 443 (SSL) through their firewall, this is a great way to configure road warriors in the field. This article takes some steps to show the advances in this technology, and even recommends a few products based on your needs.

Computer Assocs Offers Free Anti-Virus for Windows

BizReport has posted an article in which they state that Computer Associates will supply a subscription to its eTrust EZ Armor software, a consumer version of its business-class anti-virus and computer firewall software, at no charge to Windows users for one year.

This is great news. It is hard to find an up to date and FREE anti-virus product for home users, so this should be well received. The only other free AV product that works on XP that I found was AVG from Grisoft. All the others are trailware and expire way to fast for most home users.

I applaud CA for their move to protect home users in this way. Now lets just hope people install it.

Authoritative Security Guidance for the Enterprise

While browsing around Microsoft's site I found an interesting launch page entitled Authoritative Security Guidance for the Enterprise. In it, you can find some excellent security guidance and information for the enterprise. Some topics included in this are:

• Perimeter Defenses
  
• Network Defenses
  
• Host Defenses
  
• Application Defenses
  
• Data Defenses
  

An organization can reduce the risks associated with many of today's security threats by intelligently assessing their current systems and implementing suitable countermeasures. This launch page is a great start if you have to deal with this in a Windows environment.

Microsoft educating Japanese students on Security

Infoworld reports that Microsoft has made an agreement with a Japanese university calling for cooperation in security training of computer software engineers.

Specific details of the training program are yet to be worked out, but it will include a course in Windows security, to be offered from April 2004, that will include a series of lectures given by Microsoft Japan engineers. The security lectures will deal with Microsoft's Windows platform and other lectures will deal with the structure of the Windows operating system, .Net programming and basic project management skills.

As part of the security management life cycle, education is key. It is interesting to see Microsoft take such an action in Japan, and I only hope they offer similar things in other countries. (Like their own perhaps???)

More education on secure coding practices, coupled with a better understanding on how to make security part of the software lifecycle can go a long way to further increase the security effectiveness of future software applications. And that's a good thing (sorry Martha), as that will make for a more secure and safe computing experience for us all.

Attack code surfaces for latest Windows vulnerability

Well this cycle was musch shorter from patch to exploit. ComputerWorld reports that two examples of "exploit" code for a buffer overrun in the Windows Workstation Service were posted to security-related Internet discussion groups on Friday and Saturday.

This is in relation to Microsoft's Security Bulletin MS03-049, which was released last last Tuesday. This service is turned on by default in Windows 2000 and XP systems and allows computers on a network to connect to file servers and network printers, Microsoft said.

This goes to show how the new secure coding and policy of least privilege principles at Microsoft have come into play. With such services turned off on Windows Server 2003 by default, the attack surface is significantly reduced, and I would bet is the reason it was not affected. (Although thats a wild ass guess here. Guess I should install WS2K3 in VMWare and check that)

NIST Releases new Wireless Network Security Guide

NIST has released a new Wireless Network Security Guide for 802.11, Bluetooth and Handheld Devices under Special Publication 800-48.

If you are working as an information security professional in the wireless field, this is 119 pages of NIST publication goodness for you. Happy reading.

Security At Microsoft

Microsoft is committed to sharing its internal IT security practices in order to help its customers successfully secure their environments. They released a paper that describes what Microsoft’s Corporate Security Group does to prevent malicious or unauthorized use of digital assets at Microsoft.

This asset protection takes place through a formal risk management framework, risk management processes, and clear organizational roles and responsibilities. The basis of the approach is recognition that risk is an inherent part of any environment and that risk should be proactively managed. The principles and techniques described in this paper can be employed to manage risk at any organization.

Its an interesting read, especially if you follow the OTG at all and wonder what they are up to. Happy reading.

Microsoft's new Security Update CD

Just read on NeoWin that Microsoft is working on a new beta for its Windows Update testers. The beta test includes downloading a 300 MB ISO of Microsoft's new "Windows Security Update CD". Apparently the CD contains most of Microsoft's recent security patches for W2K and WXP. I wouldn't be suprised if this will end up being a deployment mechanism for XP SP2 "Springboard" in the coming release.

Microsoft has also included a useful tool on the CD called Windows Security advisor. In some ways, its sort of a trimmed down version of Microsoft Base Line Security Analyzer (Which you should get here if you don't already have it). The program essentially turns on automatic updating (you can argue if this is a good thing or not elsewhere), and also enables the firewall built into Windows XP. Undoubtedly a good thing for all users.

The next question will end up being how will they get the CD to the end users. I don't know the answer to that, but hope the ISO itself is freely available for download. The fact that Microsoft is working on a CD at all is excellent news. There are even a few screen shots:

• Welcome Page
  
• Windows Security Advisor Screen
  
• Update Page
  
• End Page

From the screen shots, it still looks like it may be a ways off. (What does Winter 2004 mean?) As I said earlier, this could make it a perfect deployment vehicle for XP SP2 and W2K3 SP1.

We will just have to wait and see.

NIST Paper on Recommended Security Controls for Federal Information Systems.

NIST has completed the first draft of NIST Special Publication 800-53, Recommended Security Controls for Federal Information Systems. This draft guideline provides a recommended set of controls for low and moderate impact systems (based upon the security categorization definitions in FIPS 199 that I talked about previously). This guideline, when completed, will stand as NIST interim guidance until 2005, which is the statutory deadline to publish minimum standards for all non-national security systems.

Happy reading.

DevCon Wrapup

Well, for me atleast, DevCon is over. I hope I have been able to provide SOME insight through my blog on what has been going on. With my NDA, I have not been able to fully disclose what I have seen, heard and learned. I have over 1500 pages of presentation slides and documentation to wade through, which gives you a glimpse of how intense this conference was. Sorry I couldn't say more.

After reviewing my entries, I see that I truely can't give you a full understanding of just how much information has been provided by Microsoft to the kernelmode developers around the world. Maybe its a sign of the 'nicer, more open Microsoft' we hear about.

I know that I personally appreciate the efforts. I am one of those individuals that believes it is the right tool for the right job, and I have believed Microsoft wasn't doing enough to educate its kernelmode developers. After learning about the WHQL Test harnesses, tools like Driver Verifier, Prefast and SDV, and the amount of information disclosure being provided at this conference, I can say with certainty Microsoft is getting better.

Is it enough? I truely don't believe we will know until Longhorn. The amount of education that has been built into the foundation of thinking here on campus won't show the real results until they release a final product which has been architected with these fundamental principles in mind. We see a glimpse of it with the attitudes here, as well with the release of Windows Server 2003. If that is any indication, I look forward to Longhorn. The tools are progressing nicely, the security and QA training and education is up to date and the willingness to help developers is an asset. Hopefully that will translate into a safer, more secure computing experience for us all in the future.

I need to send a thank you to a few people:

• Robert Scoble: Thanks for letting me crash at your place and giving me the tour, WITHOUT making me drink any Koolaid. (Although the wine went well with the wireless)
  
• Michael Howard: Thanks for giving me some time in your busy schedule to talk to me about Microsoft's security posture, tools and experience (And for turning me onto the security tests in Prefast)
  
• Neil Christiansen: Thanks for EVERYTHING. I really enjoyed spending time talking with you about the new filter manager. And thanks for a great tutorial on prefast.
  
• Rajeev Nagar: Thanks for taking some time to discuss Microsoft's direction, and my company's plans to work with you. We didn't get to that beer, but we can do that in April!
  
• Darren: For entertaining my questions and pointing out the potential security hole in volume renaming issue in legacy drivers!
  

I have taken in sufficient enough Koolaid to believe Microsoft IS getting better. If you know me, you know that is saying a lot. I look forward to applying what I learned here to my own code base, and will use all the nice swag I got at the conference to do so. Lets just say I have every CD I will ever need from Microsoft when it comes to kernelmode development. Although I do think the stack of IA64 CDs will be coasters. (Just what WOULD I do with Windows Server 2003 on IA64... play Solitaire faster??) :)

DevCon:Powers of PreFAST

Well, the last session was over that I wanted to attend, so I thought I would go say bye to Neil and the gang. Had a great conversation, which got onto the topic on if I learned everything I wanted to. I expressed that I did, hold that to this tool called "prefast" that everyone was talking about.

Well, to my suprise I was taken to a terminal and given a one on one training session on using the tool by Neil! Now THAT was nice. But even nicer, was seeing this AWESOME tool. If you don't know, PreFast is a static analysis tool that can find defects in your code during compile time, and has some great security tests built right in. It slows down the compile considerably, but is worth its weight in gold. Prefast finds errors such as memory leaks, corruption of memory, and null pointer references.. and has a nice UI to view the results, view your code... and more important tell you WHY its wrong and suggest how to fix it. With any luck, the application development teams will learn from this and make a similar tool for .NET.

I am going to mandate that any code being checking in MUST first go through and pass Prefast, returning with zero errors and warnings. For false postives (which can easily occur since this can't do really deep analysis), pragmas will need to be used WITH COMMENTS to explain why a line of code will be supressed.

This will be a useful addition to our master build, and should challenge the quality of our codebase at all times.