November 30, 2003

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.

Posted by SilverStr at 11:53 AM | Comments (6) | TrackBack

November 29, 2003

Truth About AntiVirus Vendors?

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

Posted by SilverStr at 02:06 AM | Comments (1) | TrackBack

November 28, 2003

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!

Posted by SilverStr at 11:25 AM | Comments (4) | TrackBack

November 27, 2003

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.

Hash: SHA1

GnuPG's ElGamal signing keys compromised


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 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.


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.


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.


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

This revocation certificate should then be imported into
GnuPG using:

gpg --import mykey.asc

gpg --keyserver --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


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,


[1] To get a fresh key you might want to consult the keyservers or get
it from using "finger wk at" or "finger dd9jn at".
[2] See .
[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: .
Version: GnuPG v1.2.3 (GNU/Linux)


Posted by SilverStr at 11:35 AM | TrackBack

November 26, 2003

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!

Posted by SilverStr at 03:59 PM | Comments (3) | TrackBack

Empower Program for ISV Update


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!

Posted by SilverStr at 11:44 AM | Comments (3) | TrackBack

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.

Posted by SilverStr at 11:32 AM | TrackBack

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)

Posted by SilverStr at 09:32 AM | TrackBack

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);

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";

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.

Posted by SilverStr at 09:23 AM | TrackBack

November 25, 2003

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.

Posted by SilverStr at 10:03 AM | Comments (9) | TrackBack

November 24, 2003

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!

Posted by SilverStr at 10:05 PM | TrackBack

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.

Posted by SilverStr at 09:39 PM | TrackBack

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?

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

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.

Posted by SilverStr at 03:35 PM | TrackBack

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)

Posted by SilverStr at 03:28 PM | TrackBack

November 23, 2003

Trusting Certification Authorities

Today joat talked about 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, 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.

Posted by SilverStr at 09:15 AM | Comments (6) | TrackBack

November 21, 2003

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!

Posted by SilverStr at 01:08 PM | TrackBack

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 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!

Posted by SilverStr at 12:41 PM | Comments (1) | TrackBack

November 20, 2003

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!

Posted by SilverStr at 08:33 PM | Comments (1) | TrackBack

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!

Posted by SilverStr at 06:12 PM | TrackBack

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.

Posted by SilverStr at 06:05 PM | TrackBack

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.

Posted by SilverStr at 09:20 AM | TrackBack

November 19, 2003

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:

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.

Posted by SilverStr at 02:28 PM | TrackBack

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.

Posted by SilverStr at 07:36 AM | Comments (1) | TrackBack

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.

Posted by SilverStr at 07:12 AM | Comments (2) | TrackBack

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.

Posted by SilverStr at 12:02 AM | TrackBack

November 18, 2003

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.

Posted by SilverStr at 06:50 AM | TrackBack

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)

Posted by SilverStr at 06:42 AM | TrackBack

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.

Posted by SilverStr at 06:33 AM | TrackBack

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.

Posted by SilverStr at 06:27 AM | TrackBack

November 15, 2003

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:

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.

Posted by SilverStr at 11:53 AM | TrackBack

November 14, 2003

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.

Posted by SilverStr at 08:55 PM | TrackBack

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??) :)

Posted by SilverStr at 11:16 AM | Comments (1) | TrackBack

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.

Posted by SilverStr at 10:45 AM | TrackBack

DevCon:Static Driver Verifier

Ok, its the last day, and I only have one session left, titled "Static Driver Verifier" (SDV).

All I can say is WOW. They have been doing some neat work in Microsoft Research on a neat new tool that can find bugs in device drivers at compile time. It can even find bugs that Driver Verifier and Prefast will miss. (I will talk about prefast in another post)

SDV will look through all possible paths in a driver that are excercied by the OS model. The only drawback is the requirements. To run the tool, they are wanting about half a gig to a gig of ram! And what sucks more... we can't HAVE it yet. GRRRRRRRR.

SDV is a really interesting tool. The analogy I liked was that "SDV is like having Adrian Oney together with a logician checking your code at compile time". SDV basically knows how the interfaces should be used. It provides a set of interface usage rules that the driver should obey. When it doesn't, you find out about it.

Because SDV knows the OS internals, it can attempt to find a correctness proof. This correctness proof is found using abstraction search and symbolic model checking. If a bug is found, it shows you the path through your driver to the bug. This will significantly increase the quality of drivers that use it. Its a heavy hammer so to speak, and is a welcomed additional tool that will be part of a future DDK.

Posted by SilverStr at 10:16 AM | TrackBack

10 tips for improving security inside the firewall

ComputerWorld has published an article that illustrates 10 ways to address the security challenges of large, active internal networks. Additionally, since they involve defensive tactics, they provide a game plan for improving the security of a large enterprise network.

They could have went into greater detail, but to sum it up, the 10 tips are:

  1. Remember that internal security is different from perimeter security.
  2. Lock down VPN access.
  3. Build Internet-style perimeters for partner extranets.
  4. Automatically track security policy.
  5. Shut off unused network services.
  6. Defend critical resources first.
  7. Build secure wireless access.
  8. Build secure visitor access.
  9. Create virtual perimeters.
  10. Justify security decisions.

As I look at this list, I think this is too generic. (It makes more sense if you read the article). The defense of one's network is going to be different in each individual scenerio. Risk mitigation is not something that can be designed by following a checklist without first analysis of what needs protecting. The last bullet really needs to be near the top. Its to easy to throw money at technology to solve "security problems". This call to action to "bolt" on security after the fact is ineffective. Security is not a technology problem! It is a business ones, and will be different in every scenerio.

Although its easy to say things like "shut off network services" and "defend critical resources first", one has to evaluate WHAT is expected of the network. By applying the principles of least privilege when setting policy, you restrict the network with only those services needed, and then shore up and provide defense in depth layered security to critical business resources, based on its perceived value (each person in an organization will rank their stuff more important, so this process has to be more objective, and done by a bigger group).

This is one of the fundamental reasons so many Windows environments had the huge worm debocle this summer. After the first strain of RPC type vulnerabilities were attacked, policy should have been modified to secure this type of communcation from going on in the network. Simply "patching" the hole was not enough. They should have placed strict access control to RPC/DCOM ports and reduce the attack surface of each Windows host/server. If this was done, the secondary strains (there were what 3 different ones) would have been totally ineffective.

I could go on for hours, but you get the point. Information security is more about mitigating risks by learning from your mistakes (and those of others), and implimenting policy correctly. Technology is an enabler, not the solution.

Posted by SilverStr at 07:17 AM | TrackBack

November 13, 2003

DevCon:How To Make Devices Secure

You heard of Palladium? Well its now called Next Generation Secure Computing Base (NGSCB), and this session is completely about that.

I am not allowed to blog about this one yet. I'll respect that. I've blogged the public information already in the past, so you can read that to get the most up to date public info, which basically is this session, but at a much higher level. This is the nitty gritty technical details for us kernelmode coders.

I will say this is an interesting idea. But a LOT more information has to become available to me before I can make any real sense of it, and really understand the attack vectors this can eliminate.

Posted by SilverStr at 04:38 PM | TrackBack

DevCon:WinDbg Advanced Debugging

Without a debugger, you are nothing. Ok, maybe not... but it sure makes your life easier.

I have always found gdb a great tool when on Unix (or even cygwin), but think Visual Studio's debugger is way easier to work with on Windows. It's one of the few saving graces for Visual Studio. However, its useless for kernelmode development.

That is what WinDbg is for. And in this session, I am learning what it can really do!

First off, if anyone from Microsoft is listening... make WINDBG work in Visual Studio! (Just my opinion of course) You have a really good app level debugger, why not do the same for kernelmode developers like me?

Just learned something interesting about COM port debugging. You need to disable legacy USB support in the BIOS of the target machine if it doesn't connect right. Maybe this is the problem I am having in my VMWare sessions. I will have to check that out when I get back.

You can use Microsoft's new symstore tool to build you own symbol server. It can easily be scripted, and can run as part of the build process. This is really useful when you need to manage all the different updates for a given kernel.

Looks like Longhorn has a new native assertion failure. Instead of an asm int 3; you will now trigger a __asm int 0x2c; which gives you more control and handling of the software interrupt.

Some interesting Windbg commands:

  • .formats: Converts numbers to timetamps
  • bu: Use to save breakpoints
  • Pseudo registers: $threat - current thread, $ped - current ped (user mode), $ra - return address
  • lm: Detailed info about loaded images
  • .enable_unicode: Show ushorts as chars
  • .enable_long_status: Show signed int as hex
  • .frame: Switch the current frame on a stack
  • .kdfiles: Allows debugger to transfer updates versions of drivers over serial port, to replace the current version installed on the target. DOesn't work for boot drivers. In that case, you need to use the special boot loader with debugger enabled
  • .pcmd: Allows additional debugger info to be shown at each prompt

Lots of neat tips here. I really need to read the updated docs.

Posted by SilverStr at 02:23 PM | TrackBack

DevCon:Windows Core Testing Best Practices

I have been looking forward to this session. I really want to expand on our testing best practices and thought it would be nice to see how others are doing it.

Especially when it comes to configuration and use of the kernel debugger (WinDbg). I also would like to learn how to better use the software in the DDK to accomplish much of this. From what I am hearing, I am at the right session!

And it begins...

Its neat to see what Microsoft uses. They use special serial paddles that can host 16 machines to the debugger machine. And they can host 2 paddles for each multiport PCI card. So you can see they can debug a lot of machines via serial really quickly.

Note to self, check slides for neat script on launching KD sessions with proper Symbols

Hmm, neat switches for configuring Windows for debugging. I like the /noguiboot option. Will need to check that out. This presenter is really engaging. He not only knows his stuff, but he really can deliver how to use a tonne of unknown/undocumented features (well they are documented on the slides now). He is the guy that does all the testing here, and getting info from his experience is awesome.

Just learned an excellent way to enable driver verifier with a hack to the Hivesys.inf. Man is that a sweet hack! Check it out:

HKLM, "SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management", "VerifyDriverLevel", 0x00010001, 251

HKLM, "SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management", "VerifyDrivers", 0x00000000, "mydriver.sys"

You can obviously modify that during setup using regedit, but the fact you can do it before could make automated scripting work really easy, especially with my VMWare stuff. Should be fun.

I need to download the updated HCT Kit. These tests are just awesome, and are what WHQL uses as part of the test harness for the logo program. Many driver developers are NOT doing this correctly, and as such, is why some drivers have so many issues on the Windows platforms. These are free, just not always being used.

Posted by SilverStr at 11:23 AM | TrackBack

DevCon:Longhorn Graphics and User Experience

New day, new experiences.

This morning I am attending the DevCon Longhorn track that is talking about the new graphics and user experience. More to the point, we are learning about the new graphics architecture that drive the new Longhorn platform.

Ahhh, and it comes with slick demos.

Microsoft has finally admitted that the mechanisms for painting in Windows sucks. Which is why they wrote the new desktop composition engine (DCE). Its kinda kewl hearing about their approach. Each application basically now uses its own double buffering (the whole desktop is therefore double buffered) allowing for neat effects and huge speed increases. (3D texture rendering on the fly, FAST transparency, pixel shading etc)

Longhorn is going to have a new graphics programming library for application development. They are doing this via managed API or even through markup. You might have seen this on some other people's blogs. Its the new XAML stuff (Did you see that Hello World demo Don Box did?)

The presenter is really pumped about the fact they can now use those gaming cards to do kewl stuff on the desktop. I have had the same wish for years. Now only wish my laptop had a gaming video card! Course it will be to slow to run Longhorn anyways, so thats a moot point.

Speaking of performance and hardware, the hardware requirements are pretty high. I just heard that to run the new Aero Glass, it has a recommendation of 128 MB on the graphics card! I only have 192 MB (damn you Toshiba on your stupid design) in my entire laptop. *shutter*

Demo time! Lets just say the first demo.. well.. um.. didn't work. Hey, its a demo.

New person with a differnet laptop. We are now getting a sneak peak of the new Aero Glass experience. All I can say is "Wow, thats pretty". There are neat subtle animations that make the experience seem kinda kewl. And that is on top of the neat transparency affects to make the new "glass" look. Oops, he hung the demo on a logout/login action. Ahh, demo over now.. both demo machines toast. :(

All and all it looks sweet, but needs a LOT of work. Every one of their demos crashed or hung, but what I did see beforehard was pretty good. There is a lot of promise in what they are doing. And, this will in turn allow application developers to make a richer user experience. And thats a good thing.

Posted by SilverStr at 10:16 AM | Comments (4) | TrackBack

Serious flaws in bluetooth security lead to disclosure of personal data

There was a post on bugtraq that included a paper on some serious flaws in bluetooth's authentication and/or data transfer mechanisms.

Firstly, confidential data can be obtained, anonymously, and without the owner's knowledge or consent, from some bluetooth enabled mobile phones. This data includes, at least, the entire phonebook and calendar.

Secondly, it has been found that the complete memory contents of some mobile phones can be accessed by a previously trusted ("paired") device that has since been removed from the trusted list. This data includes not only the phonebook and calendar, but media files such as pictures and text messages. In essence, the entire device can be "backed up" to an attacker's own system.

If you have a device using bluetooth, you might want to look into this!

Posted by SilverStr at 01:48 AM | TrackBack

November 12, 2003

DevCon:Common Driver Security Bugs

Well, we are currently into the session I came to see.

The presentor is a software engineer with the Kernel platform group, and he really knows his stuff. Unfortunately, his presentation skills seems kinda boring/dry, and he is second guessing himself. I think he would be more interesting if he used some good examples/stories to go along with the presentation. And it doesn't help when he has glaring errors in the slides. Poor guy. Atleast he caught it himself before we said anything.

Besides the normal arithmetic over/under flows, buffer overflows, and the like, he is showing some interesting things you don't normally think about, including neat ways to watch for alignment issues(which can bugcheck).

Some notes:

  • Any kernel copy (RtlCopyMemory etc) of untrusted data must be fully verified
  • Length check all buffers
  • Handle arithmetic over/underflow, negate (2s compliment), Zero size, divide by zero
  • Avoid race conditions.
  • Do not use try/except blocks when you don't need to. This should only be around access of user-mode address space
  • Verify alignment. x86 in't a big problem, but on 64-bit CPU it will crash!
  • Lock/guard data to ensure state doesn't change
  • Don't double fetch data. Malicious intent may take advantage of this data change
  • Usermode address space is the MOST untrusted area of data
  • Do not touch user memory at elevated IRQL
  • If you need to create a HANDLE, make sure you use OBJ_KERNEL_HANDLE flag in HandleAttributes (ie: ObOpenObjectPointer() ) so the user can not modify/manipulate the handle
  • Watch for information disclosure issues in which user mode can read a handle of a kernel mode driver
  • Use actual AccessMode in IRP->RequestorMode when calling ObReferenceObjectByHandle(), not explicit KernelMode. You may circumvent access checks
  • Do not confuse handles with objects. The Object you have won't go away, but the handle could!
  • Kernel handles are trusted, where user mode are not. Make sure you pass OBJ_KERNEL_HANDLE to InitalizeObjectAttributes()
  • Never pass a user mode handle to ObRef with KernelMode
  • Handles can be duplicated across processes!
  • Wrapping a possible NULL pointer exception in a try/except block HIDES a potential security bug from being found. It is safer to fail and BSOD then to simply let it pass in the except block.
  • Don't rely/trust on name or process ID. Do proper access checks.
  • Watch for zero length or MaximumLength of UNICODE_STRING
  • Watch for buffer underrun when trying to null terminate a UNICODE_STRING (str.Buffer[str.MaximumLength/2) -1] = L'\0'; // WRONG)
  • Watch for odd length UNICODE_STRING (ie: if( str.MaximumLength & 0x1 ) { bail } )

When its all summed up, basically the most dangerous habits are:

  • Untrusted pointers
  • Usermode address space
  • Shared view with usermode address space
  • Complex buffer structures, even if buffered. K.I.S.S.
  • Usermode handles
  • Zw API's (Their previous mode was KernelMode, so it will pass access checks unless you force it with the right flag)
  • Opening objects by "name"
  • Error paths. Make sure all error paths clean up properly.
  • Don't assume that a null pointer derefence causes an access violation and can be caught in a try/except block. A hacker will just map to the 0 based address
  • Returning a kernel address as a context could be dangerous
  • Use the driver verifier and associated tools, but don't trust them to find all your bugs

Posted by SilverStr at 03:36 PM | TrackBack

DevCon(sorta):Talking with Michael Howard

Some of the tracks were kinda dry this morning, and I decided to hook up with Michael Howard from the Secure Windows Initiative at Microsoft. He is a colleague I respect highly, and I have always enjoyed his writings. One of my favorite books is his Writing Secure Coding book, and I thought it would be good to get together with him for a bit.

He's a busy guy, and I was happy to get a chance to hook with him for the rest of the morning. Had a great time. Really enjoyed talking about some of the education initiatives at Microsoft as well as the test harnesses that they are working with for code audits. (Verifier now FAILS if you use a NULL in the security descriptor. I only hope they move that to Driver Verifier).

Its good to know they have people like Michael at Microsoft. His experience and work he is distilling into the foundation of Microsoft will ultimately effect everything they do. The training they did when they froze development at Microsoft way back when will finally be shown when Longhorn is released (although some was exposed with the reduction in the attack surface in Windows Server 2003) . Unfortunately, Longhorn is still four years away.

Posted by SilverStr at 02:17 PM | Comments (2) | TrackBack

DevCon:Technical Preview on Filter Manager

Well, its a new day. I rearranged my schedule since I found out Neil was doing a technical presentation on the new Filter Manager this morning. Its not on the DevCon agenda, which means this presentation was unexpected, but welcomed.

It also came with a bunch of goodies (including a new IFS kit and GREAT technology docs) under the NDA. Means I can start porting my new mini-filter driver as soon as I install the new 2003 SP1 beta in I got at the conference into VMWare.

The more I hear about the new filter manager, the more I like it. Microsoft is removing huge amounts of complexity, and have caused a cascading effect of code reduction in the new filters that should increase the stability and quality of all minifilters. Although this means every filter driver (anit-virus, encryption etc) will need to be ported, it seems this process should be relatively painless.

In porting to the mini filter architecture, it will work natively in Longhorn. (Well the filter manager was originally written for Longhorn after all :) ) They are backporting it, which means it should work on WS2K3SP1, XPSP2 and W2KSP5. This means there is a tradeoff. Move a filter to the new filter manager, you lock yourself into technology not even released yet. *sigh* Obviously a large tradeoff for compatibility for existing clients with a legacy driver. Of course, any time you can reduce the lines of code in your master sources, the more you reduce the attack surface of the application and reduce the amount of potential bugs.

Posted by SilverStr at 09:13 AM | TrackBack

November 11, 2003

Microsoft releases network port info

This is a great find for all the firewall administrators out there!

Microsoft released a spreadsheet today which documents all the network ports utilized by the Microsoft Windows Server System products.

Check your hots-based access control policies and see if they match up!

Posted by SilverStr at 10:50 PM | Comments (2) | TrackBack

DevCon:Driver Signing

Last session of the day. My brain hurts from that last one. Way to fast, covering way to much stuff. Thats definitely not a complaint, just an observation. Walking to this session I watched the hordes stuff themselves with a buffet of gummy bears and cheese nips. Would sucks to be on a low carb diet/lifestyle in this place if you have no self control. Free pop all over the place, as well as little goodies like candies, cakes and junk food. Luckily I have no real cravings and I was smart enough to bring my own carb-free snacks.

Now to the driver signing.

Windows Server 2003 takes the foundation of digital signatures for drivers in XP (the WHQL signature) and expand on that with new Authenticode mechanisms for drivers that don't fit into a WHQL logo program. This presentation take a lot of the information I heard in the "How to Logo a new Cool Invention" presentation I listened to in the morning and re-enforce it. And it should, it was the same presenter.

You know, I now have a lot more respect for the "Designed for Windows" logo that some drivers have. I never understood the quality assurance tests and requirements needed to get that thing. Its a really good seal of quality for products that adhere to the requirements Microsoft has for compatibility with their operating systems. I just thought it was kind of a cash-grab for Microsoft... you send some money with your driver and you get a signed driver back. WRONG. Its much more than that, and I am glad. It's hard sometimes to use the words quality and Microsoft in the same sentence, but I was pleased to see how much effort Microsoft puts into the WHQL.

There was an excellent demo on how to properly get a driver signed. This was refreshing compared to all the sessions, since I actually got to see someone do it instead of just show the output in Powerpoint. They built a driver on stage, then used some pre done tests/reports to show how to use the output to submit the proper information to WHQL.

Kinda nice.

Posted by SilverStr at 05:27 PM | TrackBack

DevCon:Windows Driver Performance

Well, I can say with confidence that most driver developers CARE about performance in their code. How can I tell? Well, I think every friggin developer was in this session, squished like sardines all over the room. There wasn't a single seat, or space on the wall. Ok, so maybe it wasn't every developer, but this is a HUGE room (St. Helen's room in Building 33) and there is nowhere to sit. Thankfully it was the same room as the last presentation, so I am sitting pretty with power and a table.

This presentation is just awesome. The slide dec is 66 slides, which is huge for an hour of the session, but the presenter is managing by skipping slides to keep on topic.

There is SO much information to absorb here. Its hard to keep up. But every moment is chalk full of good information, supported by the slides which I have on hard copy to review later.

Some notes:

  • Syncro issue: lock data not code
  • Partition shared data by CPU or thread or natural data boundary
  • Improve behaviour of nested locks by using TryToAcquire
  • Limited spinning is better than blocking.
  • Interlock operations are least expensive
  • Keep code and data structures cache friendly
  • Context switching hurt cache locality!
  • A cache line is 32 bytes up to a P3, 64 bytes for P4.
  • A reference that crosses a cache line can pay a penalty of 10-20 cycles on recent systems!
  • In general, avoid threading in drivers.
  • Perfmon is an excellent starting point for evaluating basic system performance characterisitcs
  • Kernrate is a great profiler for tracking CPU utilization (part of resource kit)
  • Kernrate Viewer is a new tool from Microsoft that imports Kernrate data and plot and graph information for easier analysis.

Posted by SilverStr at 04:21 PM | TrackBack

DevCon:MS OTG Case Study Session

I decided I wanted to expand my depth of knowledge and take a tangent and go to one presentation that I had no real understanding or interest in, just to gain from the experience. I decided what would be better than listening to a Microsoft employee talk about the Operations Technology Group (OTG) and view a few case studies. Hey, its not often you get to listen to a Sr. Systems Engineer talk about whats really going on in the field.

Wow, it wasn't what I expected. Thats not good... or bad. Just different. The speaker unfortunately lacked any speaking training and it showed. He is easily losing my attention, not because of content, but presentation. Which is too bad. He seems extremely knowledgable on the topic.

Its really interesting to see a Crash Analysis over the past 6 months in the OTG. If you ever wondered what they did with the online crash reports, I can tell you that they are datamining that information and really getting to the heart of the problems.

Its neat to see via the case studies how some of these bugs come about, tracked and fixed. The bugcheck info has a lot of really useful information which can be utilized to find the line of offending code (in most cases) as well as show what was passed to it. Ya ya, I know this is known and boring to you. But its neat to see someone break down the bugcheck analysis and explain it technically; I learned a few new commands for WinDbg I never knew.

Posted by SilverStr at 03:45 PM | Comments (3) | TrackBack

DevCon:Improving the Device Driver Experience

Wow. Couldn't blog during the session because it was so full it was leaking out into the hallway! Way to many people for the session. They are going to run the session again tomorrow in a larger room, but I decided to stick it out and ended up sitting in the front instead of at a table.

Device driver installation is getting cleaner in Longhorn. Most of the compatibility and roll back issues that currently exist in Windows are going to be solved in Longhorn, and they have new tools to assist in the driver installation experience.

Longhorn is also going to have a new level of trust required during the installation experience. All drivers must be signed, but there are ways to sign a driver manually as administrator for a single machine. Can't discuss much more on that right now, but if you have access to some of Microsoft's people you can talk to them directly. (Assuming you have an NDA)

Well, gotta run to the next session. I am sitting stealing some power from some nice ladies in the hallway here and need to get to the next room.

Posted by SilverStr at 03:00 PM | Comments (2) | TrackBack

DevCon:Talking with Neil Christiansen

So I just got a chance to spend about an hour with Neil for lunch. Great guy to talk to, and quite bright. Spent a good portion talking about the new Filter Manager, and I have decided I will spend a day or two and port my driver to the new framework. The code reduction alone will make it worthwhile, but the fact normalized paths are native in the framework remove a HUGE burden I have had to deal with.

Note to Self: The HKLM hive SHOULD have a registry setting for systemroot. You can use that when normalizing the path.

Also spent some time discussing the fact he doesn't believe you can execute code through an alternate data stream on NTFS. I pointed him to the article I found and showed him how to do this. I expect he will be going over to some of the anti-virus crew and have them check it out. :)

If you ever get a chance to talk with him, I HIGHLY suggest you do so. I only wish I could have taken him for a beer and really got to talk!

Posted by SilverStr at 01:27 PM | TrackBack

DevCon:How to Logo a Cool New Invention

Writing neat new security stuff that doesn't "fit" with Microsoft's standard tests for logo requirements (ie: "Designed for Windows") means I am forced to figure out other ways to get "logo"ized. Fortunately Microsoft realizes this drawback for developers like me, and has created a session for this.

That's why I am here. Apparently its something others care about as well, since they got a BOAT LOAD of TV equipment taping it.

There isn't much to blog about here, since its really just discussion on what the requirements are to "classify" a device, as well as the process of "testing" it through WHQL.

There is a really kewl new prototype program called "Code Coverage" for certifying devices that require no hardware, and doesn't fit in the "anti-virus" or "firewall" category. I am not sure if I can blog about it, so will have to refrain until I can talk to someone in the know and who can tell me if I can talk about it.

Some notes:

  • Use a multi-processor (or Hyper-Threading) system for testing
  • Enable Driver Verifier while running all test tools
  • Don't leave KdPrint() statements in retail driver (personal note: I can relate to this... VMWare drives me nuts in WinDbg with their mouse KdPrints that shouldn't be there!)

Posted by SilverStr at 11:05 AM | TrackBack

Lest we forget

This is the first year since I was a kid that I have not visited the Cenotaph and paid my respect on this day. It seems the US does not share our respect on this day.

I am still paying my respects in my own way. Thank you to those who have fought for my freedom.

In Flanders Fields

In Flanders fields the poppies blow
Between the crosses, row on row
That mark our place; and in the sky
The larks, still bravely singing, fly
Scarce heard amid the guns below.
We are the Dead. Short days ago
We lived, felt dawn, saw sunset glow,
Loved and were loved, and now we lie
In Flanders fields.

Take up our quarrel with the foe:
To you from failing hands we throw
The torch; be yours to hold it high.
If ye break faith with us who die
We shall not sleep, though poppies grow
In Flanders fields.

Posted by SilverStr at 11:00 AM | TrackBack

DevCon:Filter Manager

Well, sitting in the first session at DevCon. Topic is on the new filter manager. Its being presented by Rajeev Nagar, the author of my favorite driver book "Windows NT File System Internals : A Developer's Guide".

Got a chance to talk to him a bit before the presentation, and talk about my issue with credential management in relation to authenticating IOCTL comms between ring3 and ring0. (Not all administrators should have access to these coms, but they do) He has the same thoughts as me about it, but he is going to introduce me to some other people on the team to discuss this.

This room is also holding the file system filter driver "Plugfest" where you can do interop testing with other vendor's drivers. Very useful since they have some Microsoft driver developers on site to help test and fix issues with you.

It looks like I can't really talk much about the content, as its pretty kewl and confidential through the NDA. (Although its really just the filter manager Microsoft has been talking about for the last year) However, this is a shot I just took of the sea of computers in the test lab. Lots of goodness with XP, WS2K3 and Longhorn machines to test on all the different platforms.

Anyways, time for notes on the presentation:

  • Wow, just heard an interesting stat. "On average, the user desktop has 4 filter drivers running concurrently." No wonder there are interop issues!
  • Current stack limit issues. You only have 12K. *shutter*
  • Expect legacy drivers to have problems with the new Transactional NTFS support that was announced at the PDC. (Hence why the new Filter Manager)
  • Deterministic load order with the filter manager!
  • Goal is to phase out legacy filter drivers and move to mini-filters SOONEST!
  • We can FINALLY load and unload drivers without having to reboot!
  • (note to self, take Raj for beer and discuss/debate "Altitude" assignment numbering)

Posted by SilverStr at 09:11 AM | Comments (2) | TrackBack

November 10, 2003

DevCon Itinerary

Well, my trip down to Seatlle was pretty uneventful. Except for some heavy rain it was a nice drive.

Scoble has been nice enough to let me crash at his place while I attend the DevCon, which is a great experience in itself. Wine and wireless, what can be better than that? He is madly typing at his laptop like he was rewriting some deity's bible... so I would gather he is webloging like mad. Guess I will do the same.

So, barring any unforseen legal issues (read: Microsoft beating me with the NDA I signed), I intend on blogging the DevCon as much as I can. Hopefully I can be vague enough and yet give some insight on some of the kewl security tid bits I can pick up. Here is a schedule of what I expect to be attending:


  • New Longhorn Filter Manager
  • How to Logo a Cool New Invention
  • Improving the Device Install Experience
  • Windows Driver Performance
  • Driver Signing


  • Windows CE .NET Device Driver Model and Windows CE Test Kit
  • When an Application Stops Responding: What drivers should do to help keep applications from hanging and to support recovery
  • Common Driver Security Bugs (The reason I came)


  • Driver Development and Testing Using Device Simulation
  • Windows Longhorn Graphics and User Experience
  • Windows Core Testing Best Practices
  • WinDbg Advanced Debugging
  • How to Make Devices Secure


  • Static Driver Verifier: Finding Bugs in Device Drivers at Compile-Time
  • Interactive Session: Using Static Driver Verifier

All and all, it should be lots of learning, burning and churning. I look forward to the 3 security sessions, as well as the advanced debugger and testing one. I will try to let you in on the latest and greatest that I am permitted to talk without disclosing anything confidential. Guess you should have registered before it sold out. :P

Posted by SilverStr at 10:35 PM | TrackBack

A Bounty for Bugs

SecurityFocus published an interesting article today on the idea of vendors rewarding individuals who responsibly find and report the security holes that make cyber attacks possible.

It goes further to recommend a strategy on how to do this. And it has some merit. But it requires a lot more thought (as the Mark admits himself). I see huge issues with conflict-resolution that would need to be addressed, especially when trying to determine the real risk associated with the bug, and if others have already reported it. Who would monitor the monitors that would watch this process?

All and all, its a neat idea, and I like it. I would love to see how this plays out, but I would gather there are few vendors in the industry that are willing to pay a bounty like this. Who knows.

Posted by SilverStr at 12:43 PM | TrackBack

The Dark Side of NTFS (Microsoft’s Scarlet Letter)

If you run on a Windows platform you no doubt have heard about NTFS. Its a fast, stable and secure file system that has worked great since the old NT 3.51 days.

This morning I read an excellent article on NTFS Alternate Data streams (ADs), and how they can be used as an attack vector to hide malicious code.

This isn't new, but I like how its described in the article. If you didn't know, you can hide alternate data in a NTFS file. This little trick has been used in the past for indexing files, store secondary data and even used to store particular security tag information (this was a very weak approach, which was quickly dropped).

There is a good example of how to create hidden ADs, so I won't bore you here. Instead I will comment on its use.

If you were to write out a malicious code segment into an ADs, the presentation layer of the operating system won't see it. Don't believe me? Watch this:

c:\> echo Alice knows Bob's secret > foo.txt
c:\> dir foo.txt
10/11/2003 08:25 AM 28 foo.txt

Ok, so we know its 28 bytes. Now watch this.

c:\> echo Alice know's Bob's secret > foo2.txt:hidden
c:\> dir foo2.txt
10/11/2003 08:26 AM 0 foo2.txt

Thats right you read that correctly. 0 bytes. The system doesn't see it. Can you see the possibilties here? You can easily hide an attack script in the ADs and execute arbitrarily later. The article shows a few examples where using the built in WSH scripting engine (on by default in XP BTW *shutter*) to do just that.

What is worse is that most (read: All but 1 or 2 I believe) anti-virus products in the field do NOT scan ADs for malicious code, which means some meathead will eventually embed their virii within the alternate data stream. Yippe. :(

Today I placed a "Request for Engineering Change" order in my IPS for a next release. (Not the version currently in RC1) I think I am going to add a checkbox to "Deny all alternate data stream reads" and "Deny all alternate data stream writes" to prevent my clients from getting nailed by this. When I get back from my trip to Microsoft I will need to test this first and make sure the OS isn't doing some hidden stuff with ADs that may be compromised if I ship this enabled. If it all works out, I will stop this in kernel mode right at the I/O manager. Gotta love ring0!

Fun stuff. Enjoy the article.

Posted by SilverStr at 08:37 AM | Comments (2) | TrackBack

November 09, 2003

Westcoast Security Forum

Have you ever wanted to be engaged with experts in the field of information security at a conference small enough that you can actually talk to presenters and others in the field? Have you ever felt there was way to much commercialization at the bigger security conferences that it lost the focus of the event?

If so, consider coming to the Westcoast Security Forum 2003. The topic this year is "Caught between Cyber-Government and Cyber-Crime: Navigating the Legal, Moral and Technological Issues of Security.".

On Monday November 17, 2003 the 6th annual Westcoast Security Forum (WCSF2003) will bring leading information security speakers from industry and government to beautiful Vancouver, Canada. Come join us! There is still time to register.

Why would you want to attend this? Well here are a few of the things you will learn at the conference:

  • How to develop comprehensive Internet and E-business security programs and policies
  • The nature of the hacker threat through live demonstrations of actual attacks
  • How government and private-sector organizations deal with Information Security threats
  • How to sell security solutions to the Canadian and American Federal Governments
  • Disaster recovery and business continuity issues in a post 9/11 world
  • State of the art technological advances and tools for both cyber-attack and cyber-defense

And here is a BONUS. If you come to the event, say 'hello' to me and give me your business card, I will send you a free packaged copy of my new Host-based Intrusion Prevention System that provides mandatory access control for Microsoft Windows, which is being released next month. Thats over a $500 value right there, and gives you an IMMEDIATE ROI on the conference!

This year has some great speakers, and has been well organized. We even have Erik Pace Birkholz from Foundstone and Timothy Mullen of AnchorIS.Com coming to present the acclaimed session "Special Ops: LIVE! The Art of Attack and Penetration".

Don't miss out. Register today. See you there!

Posted by SilverStr at 11:50 PM | TrackBack

November 08, 2003

URL Encoding Attacks

On the tail of my last post, I found a paper on URL Encoded Attacks you might find interesting.

If you have ever wondered how some hackers can do their damage with simply a web browser, this article is for you. The site has a bunch of other interesting articles, which you can look through here.

Happy reading.

Posted by SilverStr at 01:04 PM | TrackBack

The Anatomy of Cross Site Scripting

Gavin Zuchlinski published a paper entitled "The Anatomy of Cross Site Scripting". The paper explorers the impact of cross site scripting attacks and goes beyond the normal drivel of the actual insertion mechanisms. If you want to learn more about XSS attacks, you might find this paper interesting.

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

November 06, 2003

Secure Coding: Spawning external processes securely in Windows

Today I thought I would give everyone a good secure coding tip as it relates to executing external processes programmatically under Windows. Recently I was reviewing different ways to do this through .NET for C#, and started digging deeper into the Windows API to follow the execution path of the various calls.

Most developers use ShellExecute. It seems harmless enough as in the docs it is explained as a wrapper around the CreateProcess() API call. But thats wrong. It might wrap the CreateProcess() call, but it does so in a way that exposes your code to the potential of tainted data injection, or more to the point misdirection threats.

ShellExecute() uses the built in file association data stored in the registry to determine which process will be passed to CreateProcess. So if you feed it *.DOC file and Word is installed, it will execute Word accordingly. The problem with this is that an attacker could modify the association and point it to their malicious program. In doing so, you increase the attack surface of your application as you have untrusted data determining your code execution path. Very bad. Very bad indeed.

A more secure way to do this is to call CreateProcess() directly. But I wouldn't even recommend that. What I would recommend would be to use the the CreateProcessAsUser() API. It is similar to CreateProcess() but you can force the new process to run in the security context of the user you truely want to execute as. You can create a security descriptor to tie this down even further, and even use a restricted token to ensure this new process has only the required access to do its task. Remember, all code execution should be ran with least privilege whereever possible. If you would like to learn more on how to do this, check out the CreateRestrictedToken() API.

If you need to spawn secondary processes in Windows, forget using ShellExecute(). Instead, use CreateProcessAsUser(). If yer in C#, you will need to P/Invoke this, but thats not all that hard.

Posted by SilverStr at 11:08 AM | Comments (3) | TrackBack

My brain hurts. I just watched Matrix Revolution

I need aspirin. Or a stiff drink. Just came back from seeing Matrix Revolutions with Arcterex and the gang, and I now have more questions then I did going into it from Matrix Reloaded. *sigh*

I won't spoil it, as its an experience unto itself. (Although I am NOT happy with how this ended. Or did it end? Am I in a matrix thinking I just saw this movie, or did I actually see it. Oh I need another drink)

Foz pointed out an EXCELLENT script that made me chuckle, and also helped to sooth the pain beating against my brain. I suggest you read it AFTER you see the movie. Makes it that much more funny.

And just for Neil, I decided to dig up and re-read Matrix Reloaded Explained after seeing the 'final' (or is it) installment of this story line. I found it quite interesting to see how many parallels matched up. Go see for yourself. Its uncanny.

All and all, I need to go lie down. I have a headache trying to understand what the hell I just watched. After falling through some HUGE plotholes (pssst... if you can have EMP on a ship, why can't you have tonnes of them in yer home base?), I realized Animatrix had more meaning to me than I thought. (Hmm, just thought of something interesting after reading the funny script.... why DIDN'T we use EMP pulses to kill all the machines instead of causing a nuclear winter that would cause Earth's destruction?)

All I can say is that the Matrix is now out of my system. I await redemption on December 17th when the king returns.

Posted by SilverStr at 12:09 AM | Comments (4) | TrackBack

November 05, 2003

How Apple Lost my Business Today

Today, Apple lost any chance of getting my business. What seemed to be a simple tech support experience ended up having me feel very uncomfortable and upset. I would have expected more from Apple, but if that is how they treat potential customers, forget it.

Maybe I should explain. Getting ready for my trip next week I decided I wanted to rip my Diana Krall and Chris Botti CDs to MP3. Alan recommended I should try iTunes as it apparently does it well. Sounded like a good idea, since I was looking to buy an iPod anyways, and may as well make sure all this software works together.

After installing iTunes and rebooting, I gave it a try. Nothing. Nada. iTunes does not seem to recognize my CDs. It plays MP3s fine, but it just doesn't seem to want to rip them. We scoured the newsgroups and found a few posts about others having issues, and was told that there was an update to fix it. Well, I am running 4.1.1 which seemed to be the newest, but just in case I tried to update. No new updates. Ok, so I am up to date with the software.

Alan found a good entry in which a few people had the same problem. Ok, so I am not alone. Thats good to know.. since Alan and the crew haven't had any difficulties and I thought it was just bad iTunes-foo. I tried all the suggestions in the posts, to no avail. In a last ditch effort, I called the Apple Support phone number that was in one of the posts.

The initial call was pleasant. The front line guy figured out I needed to go to the "iTune for Windows team" and passed me through. Seemed harmless enough... until I got to the next guy.

He started by taking my info. Then asked "So what is wrong with your iPod". I explained that I didn't own one yet, and that I was trying to get iTunes to work before I went and bought one. Silence. A dead silence. A sigh (you know the ones, where you think someone just died) and then the doozy... "you will have to go buy one first and use the complimentary 90 day telephone service. I need the serial number from the back".

Now on the surface, there is nothing wrong with that. I haven't actually purchased anything yet, so I can understand support is limited. (Well, non existant in this case) That didn't bother me; it was the way he said it, and the fact that I just told him I am looking to buy the iPod but wanted to ensure the software is going to work. If Apple wants to win me over, they should be trying to do everything to make sure the software runs. Or atleast be polite and cheerful and not make me, the customer who is going to potentially buys something, feel like I did something wrong.

When on the phone your tone of voice makes up more than 80% of how I will feel about the experience. Do it wrong, and you do not have a satisified customer.

I am so unsatisified that I am NOT only going to forget about buying the iPod, I am going to take the money I am saving up for my iBook and using it to buy something else, such as a TabletPC. Maybe Microsoft doesn't have the greatest software, but at least their pre-sales support WANTS to make me happy.

With my griping now done, I will go try to find some other Windows software that will rip CDs for me right to MP3 for free. If you have any suggestions, please let me know.

Posted by SilverStr at 12:36 PM | Comments (7) | TrackBack

November 04, 2003

Microsoft DevCon

Next week I am heading down to Redmond to stay on campus for a week and learn from Microsoft's best kernel engineers as I attend the Driver DevCon. There are a couple of tracks on driver security that interest me, and I can round that out with a few tracks on advanced kernel debugger (Windbg) and Static Driver Verifier hands on lab tutorials that should be fun.

I also plan to try to blog the event, assuming there is some reliable 802.11b signal as well as take a few digital pictures. I hope to do a better job then Scoble and the gang, but can't make any promises since the entire conference is under a special NDA.

If you live around the Redmond campus or Seattle area, and want to show yer Americian hospitality one evening, drop me a line. I know I am going out with Robert Scoble one night, and with Michael Howard another, but that leaves a few more nights to get together.

Posted by SilverStr at 11:32 AM | TrackBack

A kick in the Microsoft wallet may increase security?

Tim Mullens over at SecurityFocus wrote an interesting article in which he discusses how Microsoft has reported that security issues, or more appropriately insecurity issues, have directly affected their balance sheet in a negative way.

I like this quote from the article:

If this kick in the Microsoft wallet has the end result of increasing security, then it's ultimately a good thing.

I agree with him that if this is what it takes to really make a difference, so be it. The reality is that Microsoft continues to get better each passing day when dealing with security, but if history is to be our guide, they aren't yet doing enough. However when business economics come into play, that changes the entire ballgame.

Scoble has on numerous occassions spoke on how executives at Microsoft are now compensated based on their accountability and satisfaction to the customer. As more customers fret about security, this means insecurity in Microsoft products (perceived or real) will have a direct impact to their take home pay. Talk about a motivating factor in getting things done.

Now the only question is, will it be done right? We will just have to wait and see.

Posted by SilverStr at 06:42 AM | TrackBack

November 02, 2003

Combing a Inductive User Interface with Secure Interaction Design

This entry is more a link reference for myself then anyone who reads this, but you might have some use for it as well.

I am currently redesigning my user interface by combining Microsoft's Inductive User Interface Guidelines with that of the Secure Interaction Design principles I spoke of last month. Some people don't like the idea of an inductive user interface, but it provides a path of least resistance with clarity for the user that I am looking for.

I am excited by this new approach. Should be interesting to see how it ends up.

Posted by SilverStr at 09:13 PM | TrackBack

November 01, 2003

Security Benchmark and Scoring Tool

Today I found that The Center for Internet Security has released a new version of their Benchmarks and Scoring Tool for Windows 2000 and Windows NT. If you haven't heard of this tool before, its a tool that has compilations of security configuration actions and settings that "harden" Windows 2000 and NT operating systems. It wraps itself above Shavlik's HfNetChk tool and provides "Consensus Baseline Security Settings" for review.

The Scoring Tool provides a quick and easy way to evaluate your host systems and compare their level of security against the Benchmarks. Tool reports guide system administrators to harden both new installations and active production systems. The tool is also effective for monitoring systems to assure that security settings continuously conform with the Benchmark.

Its a neat tool, and something worth checking out.

Posted by SilverStr at 02:00 PM | TrackBack

Threats and Countermeasures: Security Settings in WS2K3 and XP

Microsoft has released an interesting guide on threats and countermeasures for Windows Server 2003 and Windows XP, which contains detailed information about relevant security settings that can be configured on said platforms. This guide details the different threats, potential countermeasures, and the potential impact of configuring these settings.

If you are admining any of these platforms, you really should take the time to read this.

Posted by SilverStr at 01:50 PM | TrackBack