Exchange 2010 SP1 Beta this June

Service Pack 1 of Microsoft’s flagship collaboration product, Exchange Server 2010, will be available to beta-testers this June, and the general public later this summer. Based on the quick release of Exchange Server 2010 Rollup Pack 1 and Rollup Pack 2, it is not surprising that Microsoft will roll-out this service pack less than a year after its original RTM.

From the Exchange Team Blog:

SP1 will include fixes and tweaks in areas you’ve helped us identify, including a roll-up of the roll-ups we’ve released to date. I also wanted to flag some of the feature enhancements we’re excited to bring to you with SP1 including: archiving and discovery enhancements, Outlook Web App (OWA) improvements, mobile user and management improvements, and some highly sought after additional UI for management tasks

Although a comprehensive list of changes hasn’t been released, making admins lives simpler, there a number of GUI updates, both to the Exchange Management Console (EMC) and Exchange Control Panel (ECP.)

Continue reading Exchange 2010 SP1 Beta this June

Unpatched Flaw in Internet Explorer Allows Remote Code Execution

Just hours after Microsoft announced yet-another flaw in Internet Explorer we receive word of that flaw being detected in the wild by McAffee. Just as quickly, we receive word that it has already been integrated into the MetaSploit framework, so admins using MetaSploit for IDS signatures can at least defend their networks.

To avoid this problem, Microsoft’s recommended fix is to “upgrade” to Internet Explorer 8 (which is not affected by this flaw.) My recommendation would be upgrade to something else entirely and sidestep the well-documented dangers of closed-source browsing.

Remind me: Why does a browser need to be proprietary?

Question Convention: VLAN 1 Vulnerability to VLAN Hopping

Packet Life has a great reminder why we shouldn’t automatically accept “conventional wisdom” and “best practices” in our work, using the long-held conventional nugget that VLAN 1 and user traffic don’t mix because it leaves the network vulnerable to VLAN hopping attacks as a prime example.

Specifically, network engineers have been preaching for years that allowing user traffic on VLAN 1 could lead to a scenario where a malicious attacker could send traffic to (or capture traffic from) VLANs he wasn’t supposed to have access to. We all know the evils of malicious traffic captures including: stolen passwords, personal information, and compnay secrets. Using his trusty Catalyst 3550, Wireshark, and a few other simple tools, Stretch shreds that chestnut:

If the VLAN hopping attack theory is valid, we should observe our frame exiting S1′s FastEthernet0/13 onto the trunk with an 802.1Q tag specifying VLAN 10. However, by monitoring eth1, we can observe that this frame is not switched out onto the trunk. Rather, because S1 detected an 802.1Q-tagged frame ingress on an access port, the frame was discarded. (Interestingly, though, the receipt of such a frame does not increase any interface error counters.)

I’ve tried crafting the malicious frame in several ways, including swapping the order of the headers and sending only one header, but none of my attempts were successful in getting a tagged frame onto the trunk in any VLAN, even the native (untagged) VLAN. Only by transmitting the frame without any 802.1Q header was it successfully switched onto the trunk (untagged). These observations suggest that VLAN hopping attacks are not effective against modern switches (or at least the Catalyst 3550 running 12.2(44)SE2), in contrast to the findings of an @stake security assessment (PDF link) performed in 2002.

As has been pointed out subsequently by others, this vulnerability is still present in older versions of IOS, but a good workaround would be to force tagging of all traffic on trunks using the command:

vlan dot1q tag native

If your SmartNet has lapsed, this is a possible workaround. But if you have an active contract for your gear and you use trunks with VLAN 1 untagged (which includes “user” traffic) you need to upgrade as soon as possible.

Chuck Norris Karate Chopped Me in the Firewalls


The Czechs were the first ones to notice the network of infected devices that became known as the Chuck Norris bot-net. What makes this bot-net noteworthy for us networking types is not the number of devices infected (although the number is astonishing) but rather which devices are being targeted, compromised, and used to nefarious purposes, chiefly routers, firewalls, and gateway devices.

And that is unique: Most bot-nets attack workstations, compromise them, and use them to send spam, conduct DDoS attacks, or commit other crimes, and that’s about the extent of it. Chuck Norris uses network devices not only to commit crimes, but to compromise workstations on your private network and prime them for infection with other malware.

That’s right folks, Chuck Norris has gone berserk–he’s no longer just a butt-kicking Texas Ranger who beats up the bad guys, makes the ladies swoon, and wears a very expensive hat, now he’s after your firewall!

Continue reading Chuck Norris (Bot-Net) Karate Chopped Me in the Firewall

How-To Disable Google Buzz

GMail and Google Apps users please take note: Google Buzz may have already revealed what you’re reading to any Gmail user you’ve ever contacted through your Google account, and has definitely already created a “Social networking” profile–whether you like it or not.

If this seems like deja vu from the Facebook debacle last year, you’re not alone–the parallels are clear: A big organization gets users to entrust it with an array of personal information, then changes the “terms of service” quietly and begins sharing that information with others, without your informed consent.

To disable Google Buzz and permanently remove your “Google Public Profile” follow these steps:

  1. Login to your Google account.
  2. Click “Settings” in the upper-right hand corner.
  3. Click the “Buzz” tab.
  4. Click the “Disable Google Buzz” link on the lower third of the page.