The Archives

Security, Technology
Need help: Removing old certificate revocation lists in Windows
July 9th, 2009 (8 months ago) by Jeff | Permalink | Dump Core
I have a bit of a quandary that’s got me effectively stuck on a task at my day job. Thus far, Google and every other resource I’ve searched have been little help. In the unlikely event somebody out there that reads this blog (or at least gets the update notices via RSS, Twitter, or the other various feeds) can help me, I’m going throw this out and hope it garners some feedback.

I’ll try to keep this as short as possible. Our production Web site, built in ASP.NET and C# and running in IIS on Windows Server 2003, recently added authentication via client certificates stored on users’ smart cards. We allow users to attach their smart card certificates to their existing account, then authenticate them by verifying their certificate, looking up the user account by that certificate’s fingerprint, and loading their profile. These certificates are signed by a trusted third-party certificate authority (CA) owned by the client and every morning we download the latest certificate revocation lists (CRLs) so we can reject certificates as they are revoked by the CA. My download process is working fine and dandy, so that’s not the problem; neither is the actual import process, as I know the command line options for Microsoft’s certutil command that will import the CRLs.

My problem stems from removing the old CRLs, which so far I haven’t been able to accomplish without going into the Microsoft Management Console and clicking through the GUI. We’ve had problems with the size of the certificate store, as the CRLs tend to be very large and we have to remove the old ones before the new ones can be imported. I’ve tried the few suggestions I’ve found online that haven’t seemed to work, such as a command-line switch for certutil that’s supposed to overwrite the old CRL with the new one (it just imports the new one and leaves the old one in place). We want to automate this process into a scheduled task, so it can run early in the morning when our users aren’t on the system and without human intervention.

Here are the tools available to me:
- As previously stated, certutil (part of Microsoft’s Certificate Services package);
- Windows PowerShell;
- Anything I can throw into a .NET assembly and build an executable out of (preferably C# code);
- Good old fashioned batch files.
I’ll tell you, I’m pretty frustrated and exhausted by this task. It’s not that I can’t do the research and figure it out for myself; I have done the research, and everything I’ve read applies to certificates and not CRLs, and they’re not exactly a direct swap in usage. I’d prefer not to provide much more detail than this for security reasons.

For the time being, I’ve been manually removing the old CRLs through MMC and then running a batch script to do the import every morning as my first task. That’s working fine for now, when I’m in the office every morning, but I’ll be taking some vacation time soon that will start to cause problems. I swear, if this was OpenSSL and Apache on Linux, I’d have this solved in a heartbeat (or at least an afternoon). If you have any suggestions, please feel to post a comment or shoot me a direct e-mail at the usual address.
Internet, Technology
set_bugs = 0;
February 10th, 2009 (1 year ago) by Jeff | Permalink | Dump Core

This week an couple errors were reported in the custom CMS application I built at work a couple years ago. I haven’t touched this code in at least a year, so it took me bit to swap some mental virtual memory and recall how everything worked. I’m not sure if these “bugs” were something new that had manifested themselves after a recent platform upgrade or design flaws that had been there since the beginning only to be recently noticed. None of that really matters for the sake of this post, however. Suffice it to say there were two problems, one of which was likely to be entirely my fault but relatively easy to fix with a little bit of C# hacking.

The other problem was a bit obscure. The application is built in ASP.NET 2.0 and written entirely in C#. It also makes use of Microsoft’s AJAX Toolkit for ASP.NET to “pretty up” some of the interface interactions. Unfortunately, one particular user began to experience problems with the system recently. Since she’s the project manager, needless to say the problem was escalated to top priority with little to no delay. To make things more difficult, the problem was especially cryptic. In true Microsoft fashion, the pop-up JavaScript error dialog offered little to no useful information:

Sys.WebForms.PageRequestManagerServerErrorException: An unknown error occurred while processing the request on the server. The status code returned from the server was: 500

Google, of course, is my friend and found no shortage of pages where this turned up. The odd thing was that none of the purported causes for the error were anything that I was using.

After much searching, I finally happened upon this site. It seems Ted Jardine hit the same problem I did. He had narrowed it down to something to do with the .NET session, which he wasn’t really using but I was using extensively. What I found most interesting was his solution:

So, based on one of the comments in one of the above posts, even though I’m not touching session on one of the problem pages, I tried a hack in one of the problem page’s Page_Load:

Session["FixAJAXSysBug"] = true;

And lo and behold, we’re good to go!

I followed the various links he provided—as well as Googling for “FixAJAXSysBug” itself—and found lots more anecdotal evidence to support its usefulness. I applied this “fix” to the common header of the application to make sure it took affect everywhere and, so far, all reports seem to indicate its success.

Needless to say, I was instantly reminded of this GPF strip from the crossover with Help Desk. I can’t remember now if that joke was my idea or Chris Wright’s. It doesn’t matter now, really… it audacity is as brilliant now as it was eight years ago. The idea of setting a simple Boolean flag to “turn off bugs” is something I will always find hilarious.

Now if only all Microsoft bugs were so easy to fix….
Software, Technology
WinHasher 1.3
June 30th, 2008 (1 year, 8 months ago) by Jeff | Permalink | Dump Core
For both of you out there who care, WinHasher has now been bumped to version 1.3. The changes are very minor, so there’s no need to upgrade unless you find the following two new features useful:
- There’s now a drop-down box to choose between hexadecimal output and Base64 (RFC 2045, although without line wrapping). I personally like using Base64 because it’s more compact than hex and more “obscure-looking”; even non-coders are familiar with hex, seeing it in error messages all the time, but are less familiar with Base64, which looks more like “random noise”. The default output is still hex, so you only need to switch modes if you really find Base64 more useful.
- There’s now a tab in the GUI to hash arbitrary text. I added this feature because there was an extension to Firefox that I used all the time to do this—which I used frequently to generate “random-looking” passwords by hashing simpler plain text and using the hash as the “real” password—but the extension hasn’t been updated in forever and is no longer working in Firefox 3. So to keep myself from getting locked out of the accounts where I used hashed passwords, I threw this feature in WinHasher. The backbone was already there, so all that needed to be added was a GUI. There’s also an encoding drop-down box that lets you change the text encoding if you so desire/need. To be honest, I don’t think it’s really necessary because I think .NET uses Unicode internally all the time, but it does have a nice side-effect: if you enter text in one encoding and change the encoding setting to something radically different (say you enter Western European Windows text but change the encoding to IBM EBCDIC Japanese), you’ll end up with a very different hash than you would have had if you used the “right” encoding. This isn’t encryption by any means as it could be easily reverse engineered if you knew what encodings were used, but it does significantly scramble things to the point that it makes it much harder to figure out exactly what you did.
I had originally started adding support for HMAC signed hashes but have abandoned that for now. If there’s anyone out there who might actually find that useful, drop me a line and I’ll revisit the code to see what I might be able to add. Downloads can be found at the first link above.
Software, Technology
WinHasher 1.2
November 30th, 2007 (2 years, 3 months ago) by Jeff | Permalink | Dump Core

I just can’t leave well enough alone. I’ve been mildly annoyed with the “hash in progress” and progress dialogs in WinHasher 1.1. The original idea was to use System.ComponentModel.BackgroundWorker to easily multi-thread very large hashes (say of CD or DVD ISOs or uncompressed video files). This had two benefits: (1) it allows the user to cancel a hash in progress and (2) gives us an opportunity to update the GUI while the hashing takes place in the background, meaning we can inform the user of the progress. Unfortunately, I couldn’t find a method right away to determine the progress of an individual hash. System.Security.Cryptography.HashAlgorithm.ComputeHash() by default takes a byte array or file stream and chugs the whole thing at once, spitting out the hash as a result. There’s no way with this method to determine how far along you are.

However, if you look at the guts of ComputeHash(), you’ll find it reads in chunks of bytes into a buffer, then calls two methods: TransformBlock() for every chunk but the last, and TransformFinalBlock() to hash the last chunk and finalize the hash. The result can then be obtained from the HashAlgorithm.Hash property. If we bypass the convenience of the single ComputeHash() method call, you can read chunks of bytes from the buffer, feed it to the Transform...() methods, and keep track of how many bytes have been read so far. Since we already know how big the file is from the start (System.IO.FileStream.Length), it’s trivial to calculate a percentage complete. Want the progress of a multi-file comparison? Sum the lengths of all files in the batch, then keep track of the total number of bytes hashed along the way.

I’ve bumped WinHasher to version 1.2. It should be available on the official site by tomorrow morning.
Software, Technology
WinHasher 1.0 and Mandelbrot Madness! 2.0
September 26th, 2007 (2 years, 5 months ago) by Jeff | Permalink | Dump Core

I’m not sure if anyone cares, but I’ve been doing a tiny bit of dabbling in releasing Open Source software lately. Since I don’t particularly care to announce them on the GPF News (it isn’t, after all, GPF news), I’ll announce them here. For those of you who might complain that working on these has taken precious time away from the comic, fret not. The tiny bit of time I’ve been able to squeeze in here and there to work on these have been during periods when working on the comic would be impossible, so there’s no way for there to be any conflict.

The first one I’ll announce is the most recent. WinHasher is a Microsoft .NET Framework 2.0 application for generating cryptographic hashes of files. It is both a Windows GUI applet and a console (command line) program, and it operates in two possible modes. The first mode generates the hash of a single file, which you can then use to verify a download or check to see if a file has been tampered with. The second mode takes the hashes of multiple files and compares them; in this way, you can see if two or more files have the same binary contents regardless of their names, locations, and time stamps. The Windows app supports drag-and-drop functionality, and the installer lets you also build shortcuts in your Windows Explorer “Send To” context menu so you can just right-click a file and get its hash.

So why did I build this? Well, the full details are on the site, but the quick version is that I’ve grown tired of not being able to validate the hashes of downloaded files because Windows doesn’t have a built-in hashing program. Linux and the other free UNIX clones have OpenSSL; heck, even Mac OS has OpenSSL under the hood. Not Windows… of course. So instead of downloading a file on a Windows machine, copying it to the Linux box, validating the hash, and moving it back (or worse, just not even validating the hash at all and taking my chances), I hacked together this little program. Then I thought it might be useful enough to share, so I did. If you find it useful, please let me know.

For the really technically inclined out there, most of the hashes are built-in to .NET 2.0, so this was obscenely easy to implement. In fact, 2.0 has an abstract hash algorithm class (System.Security.Cryptography.HashAlgorithm) that all of the built-in hashes implement. The two non-standard hashes, Whirlpool and Tiger, were taken from the Legion of the Bouncy Castle Crypto API, which is actually .NET 1.1 based. I (rather crudely) ported these classes to be subclasses of HashAlgorithm, so they can technically be used as a drop-in replacement of any .NET 2.0 hash. I plan to add additional hashes over time, provided that (a) the original source code is free and (b) I can port it to be a HashAlgorithm subclass.

The second program to mention is actually a bit of an oldie now. (I actually released it back in June.) The Windows version of Mandelbrot Madness! is back, also in a .NET 2.0 edition. I wrote the original in Visual C++ 4.x, but have long since lost the source code. Then the Java version came into being and rapidly surpassed the Windows version, leaving it to suffer from bit rot. Both eventually languished as I lost time to work on them. Well, in December of 2005, I released the not-quite-complete-but-close-enough 4.0 version of Mandelbrot Madness JAVA!, declaring it abandoned. It always bugged me that I never went back and revisited the Visual C++ code, but without the source I was stuck.

Well, to make a long story short, my new job had me learning a new programming language: C#. That had me programing Web sites, but I knew you could also do Windows GUI apps in it as well. So somewhere down the line I got a wild hair and started the agonizing work of porting the Java code from the last version of MMJ! to C#. Actually, Java and C# are similar enough that the porting work wasn’t all that hard. Not only is MM! 2.0 now pretty much identical in functionality to MMJ! 4.0, but I introduced a number of new features that I hope to eventually port back to the Java version. While I still prefer the platform independence of Java, I’ll readily admit that the .NET version is a lot faster on Windows. I think that anyone on that platform that has actually bothered to play with the Java version (both of you) should make the switch. Anyone still using the decrepit old 1.0 version of Win32 MM! should enter the 21st century and upgrade too.

Both programs have been released under version 2 of the GPL (haven’t had time to really review version 3 yet), so the sources are also available. If you have any suggested changes, feel free to pass them along and I might incorporate them into the official builds (giving you credit, of course).