Friday, May 27, 2011

Thank You QuiteTall for your post!

It was the top Google hit when I searched on the error I found in my Console system log, and did the trick. Thanks!

I Found This Useful: Error message in OSX Console - Can't create kext cache under / - owner not root

Looks like an interesting blog, from someone using OSX (like me), interested in security (like me), and who has a Synology product (like me) - and this is just from reading his last few posts. I think I'll Follow! :)


[edit 5/27/2011 11:40 AM]
in case the blog ever disappears, the command I needed to run on the root of my OSX drive, to fix the fact that I was the owner, was:
sudo chown root:admin /

Tuesday, May 17, 2011

Protecting 4410 from malware Win32/FakeRean

Thank goodness for FBWF! A user caught this malware over the weekend, and the majority of its effects were mitigated by a reboot.

However, I'll need to lock out more than just HKCU\Software\Microsoft\Windows\CurrentVersion\Run, since as Microsoft explains, this one also takes over HKCU\Software\Classes\.exe, and \exefile or \secfile.

The randomly named file it installed was cnb.exe at %AppData%, and it was set to launch every time you ran any executable. Sneaky!

I've decided that I need to keep the user's registry excluded with FBWF so it can be updated and retained - Acrobat Reader loves adding things to the registry (those files again are NTUSER.DAT and NTUSER.DAT.LOG). So just before I'm ready to create an image, I'll
1) elevate permissions for my one user account to administrator
2) login as that user and get into regedit
3) right click the following key and change the user's permissions to Deny
4) add the following three keys since they don't normally exist, and change the user's permissions to Deny

5) lower permissions back to Power User

Hopefully this, along with denying write permissions to the root of %AppData% (Documents and Setting\username\Application Data), will greatly reduce the malware my users are catching.


Monday, May 16, 2011

Make sure your Mac always has these folders

I realized Friday, when I was finishing my Leopard image for the Ad Layout designers, that there weren't any messages in the console! No system logs or anything.. I also noticed weird files showing up at the root of the system volume, some with no names (must have been spaces) and some named like '%B0%B1' and other weird naming structures. They looked like temp files of some sort, but they weren't plain text.

I use the awesome Carbon Copy Cloner to create my Mac images after they are configured - I save them as disk images for later imaging to an empty partition on the destination Mac. I had been working on this particular configuration off and on for a couple of months - taking an image after substantial work so as not to lose it. (Good thing, too, since I needed to roll out my build Mac quickly one day two weeks ago and grab another one to work on. :)

I must have something mis-configured in my CCC settings.. so I installed a fresh copy of Leopard and immediately imaged it, then blasted that image back. Same symptoms - I've definitely got something wrong.

I'm slightly obsessive about having a clean system, although I try not to break anything with my cleaning! In this case, I took the suggestion from this Knowledge Base article about what additional folders I could exclude from my new image, and added a custom entry after communicating with CCC's developer at this forum post. The first three lines are the suggestion, and the fourth is my addition:

- Library/Caches
- /Library/Logs
- /private/var/log
- /private/var/folders

It turns out that the folders 'log' and 'folders' weren't being copied at all, which makes sense. However these are located in a locked down area of the system, where you need to issue commands with sudo - OSX couldn't create the folders! Thus no system logs, and no folder for certain temp files and caches, including a system font cache.

So I adjusted my entries to copy over the folders but not the contents, and my Mac image is much happier (and I am too!). The new entries look like this:

- Library/Caches
- /Library/Logs
- /private/var/log/*
- /private/var/folders/*


Sunday, May 15, 2011

4410t thin client update, and FBWF

Well that took a little longer to write than I thought. :)

This is a follow-up and expansion on my post of 11/18/2009.

Nice laptop, good laptop..

For the most part, I've been pleased with the HP 4410t thin client laptop. It has a tendency to go into a deep sleep and not come out - you have to pull power and the battery and try to turn it on to fully drain any leftover power. But I haven't found any more major design flaws.

It is time for me to create an updated build from scratch, instead of iterating on the previous build with small changes. It will have all the latest security updates, updated HP components and other software, and any tweaks I feel are necessary after using the laptops for 18 months.

In that time, I've had three users catch malware. In one case, the malware was installed into the user's area - somewhere in their 'Documents and Settings' folder structure. I had chosen to open up the entire user folder including registry so they could personalize firefox, save things to the desktop, etc., so the malware wasn't being deleted by restarting the laptop. In another case the malware installed itself somewhere in C:\Windows, which gets reset back to its initial state after reboot by the FBWF. In both cases, the malware set itself to be started at boot with an entry in the registry at HKCU\Software\Microsoft\Windows\CurrentVersion\Run. The first user had popups everywhere, the second a message that software was missing (from the Run entry).

I've also had several users with corrupted SYSTEM registries, causing the laptop to not boot with the message: 'Windows XP could not start because the following file is missing or corrupt: \Windows\System32\Config\SYSTEM'. I think it may be due to a registry key being written to when the power goes off - the SYSTEM file contains the registry from HKLM\System. I've found it easiest to take 20 minutes to reimage the laptop and reconfigure wireless, bluetooth mouse, and dropbox.

I can't help but think - 'Is there a way to improve my image to stop these problems?'

The malware problem

My first thought is to be more selective in the files I'll let stick around across reboots with FBWF. By opening up the Desktop, My Documents, Firefox settings, and maybe one or two others, hopefully any malware installed to the user's area will disappear on restart.

My second thought is to ignore changes to HKCU\Software\Microsoft\Windows\CurrentVersion\Run so malware installed in the user's space cannot start after a reboot. I figure that one way to do this would be to selectively retain certain user registry keys and let the rest go back to their initial state on reboot.

My journey to retain HKCU registry settings

In addition to using FBWF to retain entire files across reboots, I learned that Windows Embedded Standard (from XP forward) has the ability to retain specific registry keys across reboots. It is called the Registry Filter service (Regfilter), and it works like this: determine what you want to retain, and configure it in a specific area of the registry. The service will monitor the specified key for changes, if there are any it'll both keep them in memory and write them in a specific way to c:\regfdata (I'll go into this later). From then on, any system call to read or write to that key will instead be reading from and writing to the key in memory and in c:\regfdata. In fact, if you were to turn off the service and look at the key in the registry, you would find it to be the original setting from when you began - since it is never being written to. The final thing you need to do is to add c:\regfdata to your FBWF exclusion list so it is retained across reboots.

Keep in mind that I didn't know all of the above when I started researching.. there isn't much that I could find on the web explaining this. Mostly I found instructions to change this or that in your embedded image's configuration and use Target Designer (WES tool) to make a new image. I however am using an image provided by HP so this is not possible. What I wanted to do is called 'changing at runtime'.

I learned that c:\regfdata is a file used to store a RAM disk for the Registry Filter service, and that each key being monitored has an .rgf file here. I learned how to mount the volume (see below), but I couldn't figure out how to create the .rgf file with the key's initial state, or even blank. I tried copying another, naming it, and specifying this name in Regfilter's config key, but it didn't work. I researched programs with an .rgf file extension but this wasn't fruitful. From my reading it looked like the regfdata file might be created at first boot of a newly created image, but I couldn't change the image.. I tried installing Target Designer and the rest of the embedded tools to figure out how it all worked, but this didn't get me anywhere.

After another dead end, I checked the System Event Viewer and found there was an error on startup 'The registry class name is incorrect or unsupported'. I was trying to retain a key in HKCU since I read that it should work, although unsupported. Then I found a Microsoft MSDN post - a Microsoft employee (Milong Sabandith) stated 'I think the problem is the user hive is not loaded when regfilter initializes. Regfilter will not persist the key if it cannot find it during initialization.' After all of this, it turns out you cannot persist User keys across reboots! If only I had started testing Regfilter with a key in HKLM.. the service works very well for this!

Since I'm doing all of this at runtime, I initially thought that I needed to create a blank .rgf file for it all to work. Nope, this is part of the Regfilter system. Just configure a key for monitoring and reboot. When/if the monitored key changes, an appropriate .rgf file will be created in the regfdata backed RAM disk. The reason I got confused in the first place was because I started off using HKCU, thus didn't see the .rgf file being created, thus thought I needed to create it myself, etc...

Aside: how to mount the RAM disk being backed up by c:\Regfdata

Regfilter's RAM disk is an unmounted drive/volume, but you can mount it with the mountvol command.

Type the command without any parameters to see what the volume's GUID is. You'll be returned all of the possible volumes - those mounted will have drive letters, and one will not. Mark and copy the entire line (you don't want to type it!) for the unmounted volume, it'll look like this:

Type the command again and assign a drive letter, like so:
mountvol x: \\?\Volume{bbf71292-a819-11da-9fcb-806d6172696f}\

Be sure to unmount it when you are done!
mountvol x: /D

Aside: how to configure Regfilter to monitor keys

Create your own entry in the following registry location by incrementing the number by one (3 in this example), and then create subkeys like the following. Note that you'll need to escape your backslashes when they are in quotes. Hint: if there are any there already, export one, modify it in Notepad, and import it with your changes. :)

"RelativeKeyName"="Software\\Your Program Settings"

What I've decided to do

Well, I haven't yet - I need to do more testing. Since I can't selectively retain individual keys in HKCU, I'll have to either retain (or not) the entire user registry across reboots. If the apps I want the users to be able to configure don't write to the registry, then I won't retain it. If they do need the registry, then I'll exclude it with FBWF and deny permissions to the Run key for that user. (I'm definitely going to be more selective about which folders in Documents and Settings\username I allow across reboots).

[for the truly geeky with some extra time, I thought of the following: create your own method of persisting user registry keys across reboots. If at logoff you wrote the contents of the key you want persisted to a file at a specific location (the file would be excluded in FBWF) you could then restore it on logon. Not trivial, but also not impossible with registry commands or scripting.]

The corrupt SYSTEM file problem

Since I've been retaining the SYSTEM file across reboots with FBWF, any power issue can corrupt it. If however I can figure out what exact keys need to be retained, and save just them, then Regfilter will be the only thing getting changed and the SYSTEM file can't get corrupted! I'm going to reread the link referenced in my 11/18/2009 post and do some testing.

Much of the above information I made sure to add to threads online, but they are a little scattered. With this post I'm self-documenting the thoughts and methods I used, and I hope someone else will find it helpful as well!


Saturday, May 14, 2011

Where has the year gone?

Lately I've been thinking of posting again, and finally made some time this afternoon. The fact that it has been exactly 1 year since my last post? Totally a coincidence.. honest!