SHA-1 broken

Bruce Schneier is reporting that the SHA-1 hash algorithm has been broken:

The research team of Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu (mostly from Shandong University in China) have been quietly circulating a paper describing their results:

• collisions in the the full SHA-1 in 2**69 hash operations, much less than the brute-force attack of 2**80 operations based on the hash length.
• collisions in SHA-0 in 2**39 operations.
• collisions in 58-round SHA-1 in 2**33 operations.

This attack builds on previous attacks on SHA-0 and SHA-1, and is a major, major cryptanalytic result. It pretty much puts a bullet into SHA-1 as a hash function for digital signatures (although it doesn't affect applications such as HMAC where collisions aren't important).

DoS attacks against BlackBerry devices

From the "I hate it when that happens" department: there's a vuln in the BlackBerry software (at least in the 7230 model) that can be used to cause the device to reboot on demand. The problem is triggered by >128Kb of text in the "Location" field of a meeting request. As RIM points out, Outlook limits that field to 255 characters, so you'd have to hand-craft attack messages. However, these messages don't do permanent damage; they just cause annoying reboots.

RIM confirms that they've already fixed this for version 3.8 of the handheld software, and that they will be adding a filter on their server-side software versions to keep these messages from getting to the device in the first place. It does raise the interesting question of what other vulns might exist in the RIM devices (as well as those from Good, Palm, and Microsoft).

Security Tuesday: new vuln in OWA 5.5

This month's Security Tuesday only includes one bulletin: 04-026. It fixes a cross-site scripting/script injection vulnerability in Exchange 5.5's Outlook Web Access component. If you're using OWA 5.5, a) you should get this fix and b) you should probably be upgrading.

That's not just because I like new shiny things; it's because OWA 2000 and 2003 have a number of security features that either require third-party add-ons or can't be implemented at all in 5.5. Attachment blocking, freedoc control, and support for S/MIME are my three favorites, but chapter 14 of my book discusses all of the new features in much more detail.

New IE fix released

Microsoft has taken the unusual step of releasing a security fix outside of their normal release cycle. The bulletin, MS04-025, is a cumulative update that addresses three separate vulns in IE: CAN-2004-0549, CAN-2004-0566, and CAN-2003-1048.

Because the MSRC has rated the bulletin as "critical", you should download and install it on affected machines immediately.

Security Tuesday: MS04-015

It's Security Tuesday again. This month, we get MS04-015, which covers a vuln in Help and Support Center on XP SP1 and Windows 2003 RTM (32- and 64-bit versions), and updates to MS04-014 (pretty much everyone) and MS01-052 (NT4.0 TSE SP6 and Windows 2000 SP2). Happy patching!

Security Tuesday: four new critical bulletins for April

Well, it's the second Tuesday of the month, so it must be time for the latest crop of Microsoft security bulletins. The summary is here. There are four bulletins (MS04-011, MS04-012, MS04-013, and MS04-014), and all of them are rated "critical". Patch now.

Plaxo considered insecure

I've never been much on centralized contact managers like Plaxo. Why would I want to outsource all of my contacts to some company in the naïve hope that they won't hose me? Turns out that this may have been a legitimate concern; this describes a trivial script injection attack against Plaxo that lets an attacker 0wn your contact data. Oops. So, if you're using Plaxo, you should probably stop.

Important new security update released There's a major security vulnerability that affects practically every retail outlet in the US. See the description here.

E2K3 security flaw? Sort of

Microsoft announced a security flaw in Exchange 2003. Basically, if you install Windows SharePoint Services (WSS) on an Exchange 2003 back-end, you may be allowing OWA users to access other users' mailboxes. This occurs when Kerberos authentication gets turned off; to fix things, you should make sure that Kerberos is turned back on. You can also turn off connection reuse to fix the problem. The number of affected users is quite small, and it's certainly understandable that MS didn't test this particular configuration, but it's still embarrassing.

Crack passwords in seconds! Not.

C|Net (and others, but I'm picking on them because their reporter should know better), are breathlessly reporting an allegedly new approach to breaking Windows passwords. The article conveniently ignores the fact that trading space for time is a well-known technique for lots of applications, and it presents without comment the claim that this is a major vuln. It's not. Here's why:

• The attack depends on breaking the LM hash, which is known to be weak. You don't have to store it (read up on the NoLMHash setting); even if you have Win9x clients, you can install the directory services client and use NTLMv2. In fact, if you follow MS' recommendation of using >15-character passphrases for critical accounts, you'll find that no LM hash is stored for those passphrases.
• The space/time tradeoff doesn't scale. Even if you just use upper case, numbers, and symbols, you will get somewhere around 3.37134E+14 different 8-character passwords on a standard US keyboard-- you'll get more if you include Unicode characters, which MS has been recommending for a while. Storing the hashes for that many passwords takes about 5.4 petabytes of space. Even if you manage to store that many password hashes on a disk, it is pretty unlikely that you will find a system fast enough to compare that many passwords in a matter of seconds. The problem still boils down to weak passwords, not to the fact that you can crack weak passwords in 13.6 seconds instead of 1 minute and 41 seconds. Weak passwords are still weak, regardless of how fast you can crack them.
• The only way to mount this attack is to grab the password hashes.
  • If you gain physical access to the box, the stored hashes are effectively salted by syskey, so they're not directly vulnerable.
  • If you mount an online attack, you must either be admin or be able to get admin privileges to get the hashes from the LSA so you can attack them. If an attacker can get admin privileges, you have bigger problems than weak passwords.

Buffer overflow in IIS WebDAV: Patch it now!

Microsoft has MS03-007 out. The bulletin describes a buffer overflow vulnerability in the WebDAV component of IIS 5.0 on W2K; Windows 2003 and Windows XP aren't affected. The practical effect of this vuln is that an attacker can run code of her choice on your server (at which point it's not really your server anymore.) The worst part is that an exploit for this problem is already circulating.

There are several ways to avoid this problem:

• If you were already running URLScan, you're in good shape. Its whole purpose is to block malformed or bogus requests before IIS ever gets them. If you're not running URLScan, well, why not?
  
• Go to the download page and download the patch. It's a self-installing executable; after installing it, stop and restart the W3SVC service. You don't need to reboot.
  
• Go to
  Windows Update and scan for the patch. The Windows Update installer may prompt you for a reboot.
  
• Use the Automatic Updates client to download and install the patch. Unfortunately, this route will prompt you for a reboot, although you can sneak by by killing its process and bouncing the W3SVC service.
  
• Disable or remove IIS. Obviously you can't do this for your Exchange servers, but other servers may not need IIS. See KB article 321141 for details.
  
• Disable WebDAV only. This is easy to do.
  
• Download the URL Buffer Size Registry tool and use it to set the MaxClientRequestBuffer value. Microsoft recommends setting MaxClientRequestBuffer to 16K, but in the same sentence they warn that doing so may break "some programs." In my testing, a setting of 16K didn't seem to interfere with OWA or Exchange, but your environment may have a different mix of requests. I've asked MS for a definitive statement on this; in the meantime, you can either use a larger value or use URLScan, which has templates for OWA. (Side note: of course, by reading KB article 816930 you could make this change yourself, but the tool can scan multiple machines to find those that haven't had this limit applied).
  
• If you choose to apply MaxClientBufferSize, you should probably also use a group policy setting to apply the registry key and you're in business.
  

What about long-term solutions? Well, you should definitely be using IIS Lockdown on all your Windows 2000 servers. If you combine that tool with reasonable attention to patches, you will be in relatively good shape. You should aggressively follow up with MBSA scans to check for correct patch installation. In almost all cases, your life will be easier if you deploy the Software Update Service (SUS) to pull patches and stage them for mass installation. When I get a free minute, I'll be writing an article here describing exactly how to use SUS.

In the meantime, if you read and follow the recommendations in chapters 6 and 14 of the book, you can relax.

New post-SP3 rollup for Exchange 2000

Technically, this isn't a security alert, but Microsoft has released the first post-SP3 rollup fix for Exchange 2000. KB article 813840 links to the list of fixes.

There's a companion set of fixes for the Active Directory Connector. KB article 815452 contains its list of fixes.

UPDATE: Microsoft has pulled the downloadable update, citing mismatches between the rollup binaries and the associated symbol files. They haven't yet provided an ETA for restoring the download, although the KB articles are still there.