And we thought the Guinness Brewery breach was bad...

CSO Online posted its top 10 security breaches of 2007. Not surprisingly at #1 was the "but isn't WEP secure?" incident at a major retailer...

WEP has been proven to be so insecure that any business who even thinks about using it should seriously question their security standards. With the advent of tools such as aircrack-ptw, it is now faster then ever to gain the encryption key from a packet capture.

How fun this might be!

Posted to Slashdot yesterday...Christmas day the Pen Testers cometh!

Quick restaurant plug

Anyone in the Park Slope neighborhood of Brooklyn should check out a great restaurant called Applewood. They have a great menu and the food is outstanding. Go, now!

NOOOO!!!!

Found this article today on Bruce Schneier's blog and wanted to share it:
-----------------------------------------------------------------------------

ireland.com - Breaking News - My goodness, thief drives off with 450 kegs

http://www.ireland.com/newspaper/breaking/2007/1129/breaking41.htm

-----------------------------------------------------------------------------
Sounds easy doesn't it? I wonder how many other breweries have such lax security standards...

To my dismay...

None of the spare Linksys units I have at home are supported with OpenWRT. After a bit of browsing I found the units I have are really REALLY old and the CPU is an ARM S3C4510 (manufactured by Samsung). Oh well, guess I'll have to by some WRT54G's! Hope the wife understands... :)

Time off

Well, after some time off (got married, had honeymoon) I'm slowly getting back into the swing of things. Work has been busy too, and end of year is typically crazy. This year is no different.

I hope to start hacking away at some old Linksys devices I found lying around my apartment. OpenWRT is a great choice for loading up on embedded devices. The guys from the PaulDotCom podcast recently wrote a book regarding hacking such devices and I plan to pick up a copy and get moving.

No postings of late

Obviously there's been no postings from me in a while...my firm has just opened a new office in the UK so I've been there a couple of times, plus I'm getting married in a few weeks so its been a rather crazy time of late. I'm going to try making some short posts more frequently, and hopefully I'll get back on track with my vision of how my blog should be.

Social Networking sites

I wanted to make a quick Blog posting based on something I took notice of recently. I read an interesting post from Martin McKeay on the Network Security Blog a few weeks back and wanted to offer my two cents. I agree wholeheartedly with Martin's posting. For a while now I've had friends use the words MySpace and Facebook as nouns and verbs. Just as Google has been used in the last 7 or 8 years, phrases like "I have her Facebook", or "He MySpace'd me yesterday" have become the norm. Let's face it, email as a social communication medium is dieing (if not already dead) when speaking in terms of the youth of today.

While these social networking sites are incredibly popular and can serve as a valuable resource to people, if you choose to create an account for one of these sites always take care when signing up and posting information about yourself online. Posting to publicly accessible websites means exactly that; its public.

There are also inevitable technical problems with these systems. Recently Facebook's source code was leaked. Leaked source code means bad guys find vulnerabilities with the website and exploit them to steal enormous amounts of information. Your personal information.

So I encourage anyone who wishes to sign up for these social networking sites to err on the side of caution, and thoroughly query every step you take.

SMB shares and DNS CNAME aliases

Every corporate Active Directory (or dare I say NT...) network, even most home networks, have Microsoft Windows SMB shares lurking somewhere. SMB (Server Message Block), re branded as CIFS (Common Internet File System), is the application level protocol used primarily with file shares, but also used for print shares.

Recently I was required to move an SMB share to another server, but needed to keep the original server name the same. Seems pretty straightforward, right?

1. Create and permission the share on the new server
2. Migrate the data
3. Shutdown the old server
4. Remove the DNS host record for the old server
5. Remove (or disable) the old server object from Active Directory
7. Create a DNS CNAME alias for the old server to point to the new server
8. Test the share

After performing these steps I tried connecting to the share, and received the following obscure message:

System error 52 has occurred
A duplicate name exists on the network

Weird. I triple checked DNS records, looked for IP conflicts, file share permissions, but everything checked out. What next? Time to ask Google...

After about 15 minutes or so of research, the issue was apparent. Windows Server 2003 Service Pack 1 removed the ability to access SMB/CIFS shares via DNS CNAME aliases. By adding this 'feature', the LanmanServer service does not answer requests other then those to its NetBIOS name. So any SMB requests to its CNAME alias will be ignored and the user will receive the error message above. Microsoft have, however, made available a workaround to enable SMB/CIFS access via CNAME aliases. The following registry key must be added:

HKLM\SYSTEM\CurrentControlSet
\Services\LanmanServer\Parameters

Value name: DisableStrictNameChecking
Data type: REG_DWORD
Base: Decimal
Value data: 1

Once I applied this registry key I was able to successfully attach to the share and access the data.

I've not really found out why Microsoft introduced this with SP1 as I can't find any obvious security implications with it. If anyone has an ideas on this then please comment on this post or email me directly. Good practice, however, is to make sure your share permissions are tight. By default the Everyone group has Read access to shares as they are created, so I recommend removing this and explicitly adding the group(s) who will be accessing the share.

For more information on this, read the following Microsoft knowledgebase article:

http://support.microsoft.com/kb/281308

***NOTE: I accept no responsibility for your systems upon making any changes ***

Virtual machines in WSUS

With it being patch Tuesday, I thought I'd post about a problem we dealt with recently regarding virtual machines and WSUS.

Microsoft Windows Server Updates Service (WSUS) is a Microsoft patch management tool which allows SysAdmin's to distribute security updates to Windows servers, clients, and various Microsoft applications. Our shop uses the web based 2.0 version as we've not yet scheduled the testing of its successor, 3.0, which apparently has a richer administrative interface (it's MMC based).

Recently we've been pushing to migrate Windows based applications running on legacy hardware into virtual machines, using VMware as the hosting environment. These servers, of course, need to be monitored for Microsoft updates. VMware allows the use of Templates to deploy Windows servers in a very efficient manner. A Template is essentially an image of a server you have customized to your specifications (patch level, service packs, security policies, etc) from which you can deploy multiple servers as needed (licensing permitting, of course). The deployed servers are uniquely configured using Sysprep. This eliminates the need to perform server installations from scratch. I'll get into that in a later posting.

I came across an issue recently when deploying Windows servers from one of our Templates. When a new virtual server gets deployed it is added to a WSUS management group and subsequently inherits any patch approvals. However, what I noticed was that each time a server was deployed, the server which was deployed before it vanished from WSUS! Initially I thought maybe something had gone awry when the servers were joined to the domain, however having checked Active Directory all the new server deployments seemed fine. Each new server had an associated object in the domain tree and was assuming a DHCP address before being assigned a static address. What I discovered was that the Windows Update client (which comes by default with a Windows Server installation) obtains a unique SUSClient ID for the server, when under WSUS management. Unfortunately, when each server was deployed from our pre-configured VMware Template, although they successfully joined the domain (using Sysprep) and obtained their own domain SID, the SUSClient ID remained the same. This ID is maintained in the registry key:

HKLM\Software\Microsoft\Windows\
CurrentVersion\WindowsUpdate\SusClientId

(this text has been wrapped due to formatting constraints)

In order to remedy this, I had to use the following procedure for each server:

1. Stop the Automatic Updates Service
2. Browse to the registery key above and delete it
3. Start the Automatic Updates Service
4. Click Start, Run, and enter 'wuauclt /resetauthorization /detectnow'

Each virtual server then showed up individually in the WSUS management console. I'll be working on remedying this in our Templates in the near future.

Happy patching!

RSA SecurID for Blackberry

I've found RSA to be a pretty solid company in my few years of dealing with them as a vendor, even after the buy out from EMC. I've predominantly used their RSA ACE/Server offering for two-factor authentication for remote access via Citrix. Their management interface is a little medieval looking, with the screen that cannot dock to maximize your desktop, and the 'have to close the current window to do any other management activity' feature. Also I've had trouble getting the RSA Agent Host running in a WLBS environment. Having said that its usable, and I'm pretty tolerant of interface inadequacies.

We typically distribute SecurID hard tokens which, in conjunction with a username, password, and a user created PIN, our users can log into their Citrix portal remotely. We've deployed a few SecurID software tokens which entails a software install on their Blackberry devices. This has worked great for most of our users, specifically those who travel and invariably forget their hard tokens (they cling onto their Blackberries more so then their wedding rings). With RIM releasing the Curve, or 8300, through AT&T recently, we had to perform some reinstalls on users devices. Normally its not a problem as we define per user software configuration policies on our BES, so when a user gets a new device the software just gets downloaded and installed on that device and we push the license to the device from the BES.

After deploying the software to a couple of 8300's there appeared Java exception errors when attempting to launch the software on the device. Normally this means resetting the device firewall and rebooting the device; the usual RIM troubleshooting procedure. Unfortunately that didn't work for this issue. The version of the SecurID application we've been using, and that has to date been the only available version from RSA, is 2.0. We found that when the BES tries to push this version to the device, we received a messaging saying 'Downgrade Required', but it was not clear exactly what needed to be downgraded. It turned out that a version of the SecurID supporting library (SecurIDLib.cod) comes pre-loaded on the 8300. This library is version 2.1. As mentioned, we are installing version 2.0, as given to us from RSA. So, conclusively, the BES was telling us the SecurIDLib component on the device needed to be downgraded before the version of the SecurID application we were trying to install would work. Using a test device, we manually connected the device to a Windows XP desktop running Blackberry Desktop Manager 4.2, explicitly removed the 2.1 version of the SecurIDLib component, rebooted the device, installed our downloaded 2.0 version, rebooted the device again, and finally allowed the application access through the devices firewall. After this hoop jumping exercise, the software worked without a problem.

Afterwards I called RSA and asked for an explanation. The engineer I dealt with offered me a patched version of the software, however this version was NOT documented to fix this particular issue and its version was 2.0.1. I've not yet tried it but suspect it will not fix the problem.

What a project that was! Hopefully others will not have to go through the same troubleshooting pain I did.

First post

Today is my first venture into the blogosphere. The general idea around this blog is much like most other tech blogs. I plan to waffle about general tech stuff I come across in my day to day activities as a Sys Admin in the Hedge Fund industry. I have a keen interest in Virtualization and InfoSec, so hopefully I'll make some sensible postings about these two areas and generate some interest.

Hope to see your traffic soon!