This wonderful set of utilities gsecdump and msvctl have allowed me to test the hash injection attack that has been around for some time now. The utilities don’t work on vista and 2008, but my XP workstation was an easy target.

There is some general scrambling about now and there is a lot of emphasis on “everyone panic!”

In an environment as large and heterogeneous as the one I currently work in, there is complete disparity between practice and theory. This is on multiple levels and particularly on security. I felt that from the start security was a bit of a joke consider the lack of firewalls, proxies, and patching that happens. The nonchalance about keeping antivirus up-to-date and utilizing the management tools that *are* available to at least keep a watchful eye on things. I sighed a bit of relief when I met one of the security engineers here. He’s a young guy in his 20’s or 30’s and generally types at mach 1 via a bash shell. He likes his mac and I suspect he is a paranoid mofo and doesn’t keep a single worthwhile thing on his computers. Unfortunately this guy is extremely busy configuring the few firewalls we do have and generating security certificates. This pretty much leaves a group of very brilliant but exhausted windows admins trying to do the best we can.

So one of us found a “hack” that has been apparently well known enough over the last few years that we all completely missed this one.

Windows by default keeps the NTLM hash available on a local system after a user logs on. If a domain admin logs onto a system it stores the NTLM hash in the local SAM database.

So any local administrator on this server can run the gsecdump utility and get a list of all NTLM hashes that are left lying around in the SAM. You can use that hash as a parameter to msvctl and run an application using the credentials of that compromised account. Pretty quick to figure out that the domain is a wide open sea of green for any with a desire to cruise on through.

I forgot how much I enjoyed a logical discussion with other geeks about the best way to approach an encompassing and very serious issue.

I spent close to an hour this morning trying to understand the watermarking features of the Gallery2 module, but ended up finding a bug in the modules ability to process .PNG images.  I also found the related thread on their forums: http://gallery.menalto.com/node/84808.

This may not actually be a bug in the Gallery2 module and could possibly be the way my hosting server addresses the .PNG file itself. I don’t suspect that however, and believe it to be the module’s handling of the file. I followed the thread and modified the SQL values, which did allow me to modify the placement of the watermark and apply it to images. Once I set the watermark to be the default for all uploaded images, I noticed that any new images I added were now showing up as broken photos, and I quickly became disinterested in worrying about fixing someone else’s software.

To work around the issue I used a .GIF with transparency instead. I am losing some of the nicer features I had with the PNG, like the drop shadow and embossing. I am however gaining the ability to move along with the project. I am not entirely sure why I am redoing the watermarking process, and moving away from Irfanview, but I suspect it has a lot to do with knowing that if I don’t do it now, it is only going to become one more thing I want to do later.

After a planned restart this morning, a few (NOT ALL) users were experiencing trouble sending out from their Blackberry’s, and were unable to do name lookups from their handhelds.

In the application log on the BES were multiple event ID 20482

---

Event Type: Warning
Event Source: BlackBerry Messaging Agent ZYKLON Agent 1
Event Category: None
Event ID: 20482
Date: 1/14/2009
Time: 2:19:26 PM
User: N/A
Computer: CEY
Description:
ResolveNamesMAPI ResolveName(1) succeeded, but list does not contain EntryID for all items

---

A quick search of the MAGT logs for the BES showed the following errors

[40210] (01/14 07:58:02.862):{0x1278} Failed to Resolve Name in ScanGAL. user: (USERNAME), hResult: <8004010f>

It seemed reasonable that all of these errors related to all users that were reporting problems.

A quick search of google led me to the Blackberry Forums:
http://www.blackberryforums.com/bes-admin-corner/102832-some-users-unable-send-due-invalid-addresses.html

And a restart of the server did solve this problem. Issue solved.

---

The most likely cause of this from reading the article is due to the way we restarted this morning. We restarted the CAS servers for Exchange in very close to the same window as restarting the BES, thus taking the GAL offline completely while the BES was cycling.