On April 11, 2006, as part of Microsoft’s regular "Patch Tuesday," Redmond released MS06-013, a cumulative security patch for Internet Explorer. The patch fixes ten vulnerabilities, some with active exploits in the wild. It also contains a functionality update or change in ActiveX that users who patch via Microsoft Update or Windows Update might not have seen.
This article takes a quick look at the functionality changes in MS06-013, and then discusses the new types of deployment decisions that are being made within enterprise environments in light of this critical Microsoft security patch.
Changing how ActiveX controls work
The functionality update in MS06-013 modifies the way ActiveX controls are handled by Internet Explorer. It’s a direct response to a $521M patent dispute with Eolas, a patent which covers plugins in Web pages that show multimedia content. There is a thread on Bugtraq that does a great job of explaining the background behind this dispute.
While the majority of users will not read the vulnerability announcements, Microsoft did include a reference to one of their Knowledge Base articles that detailed the potential issues after installing the update. KB9212812 states that there will be issues with ActiveX plugins – such as QuickTime, Macromedia, and even Java. Furthermore, some components of enterprise-class software are also impacted. Home users having to jump through an extra hoop to play a video is one thing – core business operations being impacted is quite another. There are many cases where enterprise applications may use these technologies in various ways.
Realizing the potential difficulties, Microsoft further released another Knowledge Base article, KB917425. This one is known as the "Internet Explorer ActiveX compatibility patch." The patch reinstates the expected functionality of ActiveX controls, but requires an additional system reboot in order to take effect. Eventually, in order to comply fully with the patent dispute, the new ActiveX functionality will have to be restored by Microsoft. There is no time frame given, but rest assured it will happen at some point.
While home users are left confused about the changes, enterprise administrators are faced with nothing but bad choices:
Deploy the patch across all systems without the compatibility patch
Deploy the patch across all systems and selectively deploy the compatibility patch
Deploy the patch across all systems, including the compatibility patch
Selectively deploy the patch
Do not deploy the patch
Security is only effective if it is implemented using risk management principles applied in the context of keeping the business running. In other words, no business = no revenue = no company = no need for security. With that in mind, security administrators at companies across the globe had to recently make one of the above choices. As we prepare for future situations like this, let’s do a short analysis of each of these choices:
Deploy the patch across all systems without the compatibility patch
The first option is to do what most security professionals would like to do – patch all vulnerable systems. This is the cleanest approach since it covers the vulnerability and keeps all impacted systems at the same patch-level. It makes managing patch deployments very straightforward and should provide for the least disruption.
However, it may not be realistic to patch all systems in an enterprise without the compatibility patch. It will break certain functionality and could cause a flood of helpdesk calls for any business applications that are affected. The possibility of a disruption in normal business operations is present, however at least all systems will be safely patched.
Deploy the patch across all systems & selectively deploy the compatibility patch
This choice is a bit harder to make. It first requires a decision on whether to identify systems which will be impacted or just exclude all systems potentially impacted – in this case, Windows XP SP2 and Windows 2003 SP1. These are not exactly uncommon operating systems at many organizations. Once that decision is made, the IT department then needs to have the correct infrastructure tools in place to identify these systems and selectively deploy the patch. This means time, money and resources that should be spent supporting real business IT needs will be spent tracking selective patch deployments.
Another side effect of this approach is that a process needs to be put into place to define these deviations in the event that issues arise as a result of the second patch, expending yet more time, money and resources.
Finally, in the case of this particular second patch, there will need to be two reboots per system deployment causing more than just the usual user frustration.
Deploy the patch across all systems, including the compatibility patch
This option has all of the problems of the previous one, but also increases the likelihood of encountering issues associated with the compatibility patch. While the additional patch was supposed to restore functionality, there is always the potential of modified code to cause problems as well as fix issues. IT/Security departments should ideally test both patches prior to deployment.
Selectively deploy the patch / Do not deploy the patch
While mixing and matching compatibility patch deployments can be challenging, there is a real security risk involved with only deploying the main patch to a subset of systems - or even not deploying it at all, especially when it is mitigating known, active exploits on the Internet.
IT/Security departments faced with this alternative are not left completely vulnerable, however. There are a number of desktop and server-based firewall, anti-virus and intrusion prevention components that can defend against known exploits and malicious behaviors. However, these programs are meant to be deployed in a layered security solution, with patching of desktops and mobile systems being the foundation of any good security strategy. Relying solely on the ability of security vendors to stay ahead of the attackers is an unenviable position to be in.
The norm instead of the exception
While IT/Security departments have not faced this situation too often, there is real evidence to suspect that this type of debate will become the norm as opposed to the exception, as software patents generate more litigation and require more remediation.
In the case of the ActiveX patch, Microsoft took advantage of the need for users to fix vulnerabilities in order to satisfy a legal issue with the least amount of cost and administrative overhead as possible, while also getting as widespread a deployment as possible.
It is important for IT/Security departments to be ready for this emerging trend by ensuring some fundamental things are in place:
A comprehensive asset management system to ensure complete knowledge of what’s on the network (and ideally, when new devices are added to the network).
Robust, platform independent patch management tools to make it easier to customize complex deployments
Solid risk management processes and procedures to allow for fast response to vulnerability announcements and threats
A layered security strategy on systems and networks to help mitigate risk while tough decisions need to be made
Conclusion
Most organizations are just getting comfortable with regular vulnerability patch management and now have to adjust their thinking yet again. With the right tools and processes in place, however, the decisions may not have to be so quick or as painful as they no doubt were this time.
In this brief article we’ve looked at some lessons learned from Microsoft’s latest MS06-013 security patch. The patching, monitoring, and deployment of Windows security releases in an enterprise environment is already a significant cost, and the new choices IT/Security departments are faced with will only take these costs higher.
Source : http://securityfocus.com
Thursday, August 23, 2007
Lessons learned from Microsoft's MS06-013 patch
Default Root Password in Infrant (now Netgear) ReadyNAS "RAIDiator"
Authors:
Brian Chapados : brian (at) chapados (dot) org [email concealed]
Felix Domke : tmbinc (at) elitedvb (dot) net [email concealed]
Timeline:
Jul 25, 2007 - discovery
Jul 29, 2007 - vendor notification
Aug 6, 2007 - vendor releases fix (ToggleSSH)
Aug 8, 2007 - vendor releases "advisory" [1]
Aug 13, 2007 - public release of this advisory
Severity:
Critical (Remote Root)
Vendor:
Infrant (now Netgear)
Systems Affected:
ReadyNAS devices with RAIDiator 3.01c1-p1, 3.01c1-p6, possibly more
Systems Not Affected:
ReadyNAS devices with RAIDiator 4.0, which disables the SSH-daemon
by default, and lets you change the root password when enabling it.
Overview:
The ReadyNAS is a Network-Attached-Storage (NAS) device based on Linux
2.4.20 and debian-sparc with a custom frontend for management. Out of
the box, the user cannot log in into a shell on the device. There are
two enabled users, one called "admin" (with the default password
"infrant1", which is documented), and another one, "root", which is not
documented. The user "admin" does not have a shell assigned, so it
cannot log in interactively. It is used only for the web frontend.
The root password is generated on each boot with a hardcoded algorithm,
using a hash of the unique Ethernet MAC-address, the software version
number and a shared secret. The root password cannot be changed
permanently, it will be "restored" after each bootup.
The secure shell daemon (sshd) is enabled by default, and cannot be
disabled. The vendor states that this is required to be enabled for fix
problems remotely, in case the user lost its web password, and that
it is not a security risk because the user must first forward access to
port 22 on his router[2]. The latter of course is only true if a.) the
attacker comes from the internet, and b.) the NAS is behind a NAT router.
Technical details:
The ReadyNAS-devices employs a proprietary embedded SoC design, based on
the Infrant NSP IT3107, which is based on a Leon SPARC processor design.
The device boots from its internal flash. The Linux kernel and
initrd-image is contained in flash (and also downloadable from the
Infrant website in order to upgrade devices), but are encrypted with an
on-chip 3DES-based encryption algorithm. Without knowing this key, or
having access to the device, it's not possible to change the initrd image.
The initrd image will look for installed harddisks, and initialize them.
If an uninitialized harddisk is found, it will be added to the RAID
array, and a part of the harddisk will be used for a root filesystem,
which is initialized from a tarball stored in flash.
After the rootfs has been mounted, some consistency checks are done, and
several important configuration files will be "backed up" from encrypted
versions. That means that it's not possible to change arbitrary files,
for examples by mounting a harddrive externally, because they will be
replaced by their backup version on the next boot. The backup files are
encrypted, so they cannot be changed without being able to encrypt these
files.
A part of the /linuxrc file from the initrd image, which is executed
first on bootup, is:
- -------------
SEED1=`/sysroot/sbin/ifconfig eth0|grep HWaddr|sed -e 's/.*HWaddr //'
- -e 's/ //g'`
SEED2=`cut -f2 -d= /sysroot/etc/raidiator_version |cut -f1 -d,`
[*EDIT*: removed SEED3 as friendly requested by vendor]
echo "root:`echo \"$SEED1 $SEED2 $SEED3\" | md5sum | cut -f1 -d' '`" |
chpasswd
# TAKE ME OUT!!
[ -s /sysroot/.os_passwd ] && echo "root:`/sysroot/usr/bin/head -1
/sysroot/.os_passwd`" | chpasswd
###############
/sysroot/bin/mv /etc/passwd /sysroot/etc/passwd 2>$ERR
rm -rf /sysroot/etc/hosts_equiv /sysroot/root/.rhosts
/sysroot/root/.ssh/* 2>$ERR
- -------------
This means that the root password will be initialized with the md5sum of
the following components:
a.) MAC address, as extracted from ifconfig,
b.) the software version number, read from /etc/raidiator_version,
c.) a shared secret string contained in SEED3.
Even if the root password is unique per device (due to the MAC address
being part of the hash), it cannot be considered as secret. First, if
the NAS device is on the local LAN, one can easily query the MAC address
with an ARP request. Second, the default hostname, which is also
displayed in the https-based interface (even for non-authorized users),
is "nas-xx-yy-zz" where xx,yy,zz are the last 3 octets of the MAC address.
Finally, the software revision can be easily determined using a
brute-force approach.
Knowing this, an attacker can login into remote ReadyNAS devices, and
access all data on the system.
Vendor Status:
After contact with the vendor, the vendor released a fix in less than a
week, together with the beta of RAIDiator 4.0, which allows a user
to enable root access with a changable password.
The vendor also released an advisory [1].
Recommendation:
Use the 'ToggleSSH'-addon released by the vendor to disable SSH access.
[1] http://www.infrant.com/forum/viewtopic.php?t=12313
[2] http://www.infrant.com/forum/viewtopic.php?t=3366&start=30
Source http://securityfocus.com
Monday, August 20, 2007
Black Hat and Defcon 2007--
>> A Multi-Perspective View of the Information Security Landscape
In early August, Las Vegas was home to two world-renowned IT
security conferences, Black Hat USA 2007 and Defcon. These
back-to-back conferences bring together the many diverse groups
that comprise the information security industry, including IT
security professionals, vulnerability researchers, so-called
"feds," and computer hackers. This unique blend of participants
offers a comprehensive, unparalleled look at the information
security landscape.
Black Hat, considered by many to be the more mainstream of the
two gatherings, was founded in 1997 by Jeff Moss to provide
advanced education for security professionals in both the
commercial and federal spaces. Today, the conference features
new, cutting-edge research from the foremost technologists in the
world. A few days of security training is followed by a week of
briefings covering all the latest threats, threat vectors,
security solutions, and more. In addition to the Las Vegas
conference, Black Hat hosts annual events in Singapore, Tokyo,
and Amsterdam. Working with corporations and governments around
the world allows Black Hat's security experts to stay abreast of
global security trends. The recent Black Hat conference held in
Las Vegas has grown considerably since its inception. This year,
it reports an estimated 4000 attendees--a 10 percent gain over
2006 numbers.
Defcon, which immediately follows Black Hat in Las Vegas, has
been around since 1992. Also founded by Jeff Moss, Defcon is
considered to be one of the largest underground hacking events in
the world. While many Black Hat attendees also attend Defcon,
the conference is geared more toward the hacker community.
Defcon is well-known for its casual atmosphere--no ties
required--and it costs a mere $100 to attend. This year, Defcon
generated some media buzz when a Dateline NBC reporter was
exposed and forced to leave the conference for allegedly filming
attendees of a session by noted hacker H.D. Moore. Not
surprisingly, the hacker community frowns on cameras.
Black Hat and Defcon cover a vast array of information security
topics. Following are just five of the hot topics discussed at
this year's conferences.
>> Wi-Fi Traffic Sniffers
Users should think twice before sitting down at the local Wi-Fi
hotspot to access the Internet. According to a paper presented
at Black Hat by Robert Graham, CEO, Errata Security, Web
applications that exchange account information with users pose
serious security risks when accessed via Wi-Fi. Typically, Web
sites use encryption to protect passwords. However, it is common
for other account information exchanged between a browser and a
Web site to not be encrypted.
Using a packet sniffer, a tool used to intercept or log wireless
traffic exchanged between a wireless router and a computer,
cookies can be collected while a user is accessing a Web site via
Wi-Fi. Cookies consist of data sent to a browser by a Web site
that remember certain information about users, such as when they
last logged in. Cookies also include session identifiers--another
type of unique information generated when users log into their
accounts. With the cookie information, the attacker is able to
import the information into another Web browser and use it to
access the user's account. This enables a hacker to read email,
create blog postings, and the like. To combat the risks
associated with Wi-Fi, researchers at Black Hat recommended users
refrain from accessing their accounts unless a virtual private
network (VPN) or secure socket layer (SSL) is used.
>> Web 2.0--AJAX Vulnerability
At Black Hat 2007, a presentation addressing the AJAX application
design flaw--which included live demonstrations of the potential
exploits--generated a great deal of interest among conference
attendees. While Web 2.0 is an exciting and revolutionary
development in online computing, it exposes consumers and
businesses to a broad spectrum of Web threats. Web 2.0
technologies, such as asynchronous Javascript and XML (AJAX),
expand both the attack surface and the security gaps available to
cyber criminals, while the communal interaction premise of Web
2.0 renders users more susceptible to social engineering
techniques. These developments challenge security solutions to
expand protection beyond the traditional client-server endpoints
of online computing. With many more threats unfolding "in the
cloud" of the Web, which in the Web 2.0 paradigm is coming to
function as a dynamic and exploitable operating system,
next-generation security solutions must pay increasing attention
to defense mechanisms that secure Web sites.
The potential consequences of neglecting Web 2.0 protection are
significant. Given the rush to architect Web 2.0 applications to
meet demand, coupled with the underlying security weaknesses of
AJAX, the Web 2.0 ecosystem remains disturbingly vulnerable to
attack. Web developers are not sufficiently ameliorating the
security problem. Interest in AJAX is sky-high and only continues
to grow. Unfortunately, far too many developers rush into AJAX
development without giving proper consideration to security
issues.
>> Botnets
True to form, Botnets emerged as a hot topic at the recent Black
Hat conference in Las Vegas. The use of botnets-networks of
compromised machines infected with malicious programs-remains a
common tool for nefarious Web activity. A bot--sometimes
referred to as a bot worm--is an automated software program that
operates as an agent for a user or another program. While bots
can be used to perform mundane tasks online (e.g., check stock
quotes, compare prices, or collect and index documents), they are
increasingly used for malicious purposes. Malicious bots are
created covertly using a computer virus or worm to install a
backdoor program--such as a Trojan horse (a malicious program
disguised as, or embedded within, legitimate software) or a
drive-by downloader (which exploits Web browsers, e-mail clients,
or operating system bugs to download malware without requiring
any user intervention)--that leaves a PC Internet port open.
Controllers, or botmasters, search for PCs with open ports and
use those ports to install their bot programs. Security experts
call these bot-loaded PCs zombies, because the botmaster can wake
them on command. When bots are installed on multiple PCs, the
network of compromised machines (the botnet) is commanded to
perform an extensive range of malicious activities, including
spam distribution, phishing schemes, keystroke logging, and
distributed denial of service (DDoS) attacks.
>> Voice over IP (VoIP) Exploits Enable Data Theft
VoIP vulnerabilities received considerable attention at Black Hat
this year. While not new to the IT security threat arena, VoIP
exploits are becoming increasingly alarming. For a time, VoIP
vulnerabilities were a nuisance that primarily threatened
service. Today, cyber criminals can use VoIP attacks as a
vector for accessing data and stealing information. During a
VoIP session at Black Hat, researchers from security firm Sipera
demonstrated a technique that could allow a hacker to gain remote
control of a PC running VoIP and the session initiation protocol
(SIP)--an application-layer signaling protocol used for IP-based
communications. By leveraging the flaws in VoIP and SIP, the
demonstration showed how attackers are able to access data stored
on a compromised computer.
According to researchers, a hacker is able to insert a small
script, or code, into a SIP message. When the phone receives the
message, the code executes. This opens up a connection on the
computer that enables access to the data stored on the machine.
Given the evolution of VoIP threats, enterprises, service
providers, and consumers need to become more aware of security
threats to their fixed and mobile VoIP infrastructure.
Protection mechanisms including increasing robustness of phone
protocol implementations, employing VoIP security best practices,
and securing critical network nodes are key to combating VoIP
threats. Additionally, consumers should take proactive steps to
protect data at rest on computers running VoIP applications.
>> Advanced Gaming Consoles
Today's next-generation gaming consoles that offer Internet
connectivity coupled with large hard disk storage and advanced
operating systems, are likely targets for cyber criminals looking
to create botnets, pirate games, and steal personal information.
Today, a virtual world in which console gamers can play with each
other adds another dimension to games. Recently, the big three
in the video gaming industry (Nintendo, Sony, and Microsoft)
released the latest powerful new gaming console technology: Wii,
PlayStation 3, and Xbox 360 respectively. Each is capable of
Internet connectivity, data storage, and use of a third-party
operating system. The processing power and various capabilities
of these new consoles pave the way for more realistic,
interactive, and fun gaming. They also create an appealing
threat vector for malicious attacks.
At present, these game consoles can be used for more than just
gaming, and all three consoles can connect to the Internet via
broadband. This means that content can be downloaded from the
Internet and stored on the on-board hard drive, enabling zombie
game console botnets-especially since many consoles now support
third-party operating systems.
Another consideration is information theft. Massively
multiplayer online games (MMOGs) and user accounts in Xbox Live
and PlayStation Network are prime targets for future spyware.
Keyloggers can be downloaded to console hard drives and
surreptitiously operate in the background. Spyware may not be as
significant a threat to console gaming as it is to other
computers, however. In most normal situations, trade secrets and
sensitive information are rarely stored on game consoles.
For information on how to combat today's complex threats, visit
www.trendmicro.com
http://newsletters.trendmicro.com/servlet/cc5?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VSW
. And stay tuned to the next issue of the FLOD
Newsletter for an in-depth look at these and other topics
emerging from Black Hat and Defcon 2007.
References
Black Hat USA 2007 (http://www.blackhat.com)
http://newsletters.trendmicro.com/servlet/cc5?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VSY
Kirk, Jeremy. (2007, August 01) Researchers: Webb Apps Over Wi-Fi
Puts Data at Risk, InfoWorld,
http://newsletters.trendmicro.com/servlet/cc5?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VSA
http://newsletters.trendmicro.com/servlet/cc5?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VSA
Hickey, Andrew. (2007, August 07) VoIP Vulnerability Threatens
Data, SearchVoIP.com, http://searchvoip.techtarget.com
http://newsletters.trendmicro.com/servlet/cc5?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VSB
White Hats Expose VoIP Security Threat, ZDNET.co.uk, (2007,
August 07)
http://newsletters.trendmicro.com/servlet/cc5?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VSC
http://newsletters.trendmicro.com/servlet/cc5?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VSC
************
Quick Links
************
>> View the Latest Threats
http://newsletters.trendmicro.com/servlet/cc5?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VT
>> Get Product Updates
http://newsletters.trendmicro.com/servlet/cc5?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VW
>> View this issue online
http://newsletters.trendmicro.com/servlet/website/ResponseForm?mgLEVTTA_TBUA_.40ev.2eEmhLrHgnPLIlpmLFRHohhDJhDpK
>> Read the Malware Blog
http://newsletters.trendmicro.com/servlet/cc5?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VC
>> Forward to a Friend
http://newsletters.trendmicro.com/servlet/ff/c?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VgVTYDYSW
************
Free Security Tools
************
>> Scan Your PC for Viruses and Spyware
http://newsletters.trendmicro.com/servlet/cc5?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VD
>> Surf Securely with TrendProtect(TM)
http://newsletters.trendmicro.com/servlet/cc5?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VSR
************
Security Resources
************
>> Common Threats to Your PC
http://newsletters.trendmicro.com/servlet/cc5?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VST
>> Threats in the Enterprise
http://newsletters.trendmicro.com/servlet/cc5?lgLQTWRRQDVlhLsHgnOLIkplLxPHohhQJhQpKV2VSU
************
Quotables
************
>> Using a packet sniffer, a tool used to intercept or log
wireless traffic exchanged between a wireless router and a
computer, it is possible to collect cookie information while a
user is accessing a Web site via Wi-Fi.
>> Given the rush to architect Web 2.0 applications to meet
demand, coupled with the underlying security weaknesses of AJAX,
the Web 2.0 ecosystem remains disturbingly vulnerable to attack.
>> Today, cyber criminals can use VoIP attacks as a vector for
accessing data and stealing information.
>> Content can be downloaded from the Internet and stored on the
on-board console hard drive, enabling zombie game console
botnets-especially since many consoles now support third-party
operating systems.
Source : http://trendmicro.com
Efficient Registry Cleanup
How to script a registry cleanup or modification for all user profiles on a given computer.
This article will demonstrate how to script a registry cleanup or modification for all user profiles on a given computer – for instance to do a virus sweep. We will also see how this approach can be used together with a computer startup script within a computer Group Policy Object to modify all user profiles in the domain, site or OU. Yes, we can actually modify user registry settings by using a computer startup script…
In some cases you can be required to delete, add or modify some part of the registry – for all users on a computer at once. In most cases we would prefer to use a Group Policy Object (GPO) on the users to add or modify a given value, but when it comes to removing values we sometimes have to use scripts (unfortunately, you might say). Also, sometimes we want to perform a cleanup task in a single process without having to wait for all users to log on. This article will show how to do this in a fairly easy way.
We will see how it is possible to do the registry modification by using a very efficient registry script – and to combine this with a GPO on the machine level (startup or shutdown), instead of using a GPO on the user object (logon or logoff).
Why would I want to do this?
So, why is that a smart approach? Well, maybe you want to do the “cleanup” during the night, you might want to make sure that a certain value is modified (deleted, added or changed) by the next morning – typically the ‘Run’ or ‘RunOnce’ keys in the user part of the registry after a virus attack - so combined with a Wake-On-Lan (WOL) procedure you can be ready to go home in no time!
In other cases the user might not have the required privileges to perform the cleanup or modification task. The registry key you want to change might be protected by a security permission, making it impossible to use a user GPO (as it will run in the user context). The great thing is that computer startup scripts execute in the context of the System account – that can be very useful to keep in mind in many situations!
Warning!
The code presented in this article is produced for testing purpose only – use in production is at your own risk. The included code is simplified a bit to be easier to understand and read. Please be sure you confirm the script functionality in your test environment before implementing this in production. You can include additional error handling, logging and additional functionality – modify as you want!
I am not saying the code does not work, just making sure you understand that execution is at your own risk.
The background
Before we take too deep a dive into the code, a few things about the registry must be perfectly clear.
It is very common that people think the HKEY_USERS part of the registry is a place where you can see all local profiles on a given computer. However, this is not the case. The HKEY_USERS lists profiles that are currently loaded on the machine, so to speak the profiles that are active in memory. As soon as a user logs on to a computer, an entry will be visible in this part of the registry.
Figure 1
As shown in Figure 1 you will normally be able to see a few profiles loaded – even though only one user is logged on to the console. When a user logs off, the Registry Hive is unloaded and is no longer visible under HKEY_USERS. Here is a short explanation on the loaded hives:
“.DEFAULT” is the default user profile – NOT something that all users will see (like a Public or All Users profile) and NOT a registry profile that is copied to all new users on the computer (these are common misunderstandings). This is however the standard profile in use, even when nobody is logged on – hence the startup profile (loaded before you even reach the desktop). By setting values in this profile you can change options such as desktop background during the logon screen (Ctrl+Alt+Delete), the initial Num/Caps Lock settings etc.
"S-1-5-18” is the “System” Security Identifier (SID)
"S-1-5-19" is the “LocalService” SID
"S-1-5-20" is the “NetworkService” SID
A profile or SID starting with "S-1-5-21-" and ending with "-500" is the SID of the built-in Administrator account. The ‘real’ and active user profiles are all other entries in the HKEY_USERS part of the registry. In the script examples included in this article the above specified profiles are NOT touched – only ‘regular’ users are touched - you could change that easily by deleting a few lines in the code.
Load My Hive…
So, what if I want to modify a profile of a user that is not currently logged on? Well, we have at least two options:
1 - to manually load the hive in Regedit
2 - to create a script that loads the hive dynamically.
Let us look at the first option first. If you open Regedit (Start > Run > Regedit) and browse to the HKEY_USERS entry (you have to click or mark it), then go to the File menu, you should now be able to choose “Load Hive…” (see Figure 2)
Figure 2
At this point we are prompted to enter a path to an NTUSER.DAT file (see Figure 3).
Figure 3
The NTUSER.DAT file is located in the user profile folder. Above, we can see the NTUSER.DAT file of the user ‘test2’. That file is located right below the “C:\Documents and Settings\test2\” folder - on Windows Vista, user profiles are typically stored below the “C:\Users\” folder.
If you cannot see the NTUSER.DAT file as we can in Figure 3, you should go to Tools > Folder options and select “Show hidden files and folders”.
When loading a hive temporarily we need to give it a name – make your own choice. In Figure 4 and the script examples we are using the name: ‘TmpLoadHive’.
Figure 4
Click OK and the hive hierarchy should be visible, and expandable, as shown in Figure 5.
Figure 5
In Figure 5 ‘TmpLoadHive’ has been expanded to show the structure of a loaded user hive – it should look exactly like any other user registry. It is identical to what the user will have in his or her HKEY_CURRENT_USER (HKCU) when logged on to the machine.
When done, remember to unload the user hive again by marking the ‘TmpLoadHive’ hive and going to the File menu > “Unload Hive…” as in Figure 6.
Important!
If you do not unload the hives, you cannot load that hive again until after a reboot, because you cannot load an already loaded hive (this also goes for logged on users – including Fast User switching users). This will also make the script ‘fail’ loading the hive.
Figure 6
That procedure would be very annoying if you had to do it for all user profiles on all computers in your domain, right? Luckily we have another method by using our good old friend REG.EXE.
An old friend to the rescue
The REG.EXE command has two very useful parameters: LOAD and UNLOAD. They do exactly the same stuff as we did manually above. We just have to specify the temporary hive name and a full path to the NTUSER.DAT file we want to load into memory.
You want a script example? Ok, to set the background for the Default User profile we could run the following code:
REG.EXE LOAD HKU\DefU "C:\Documents and Settings\Default User\ntuser.dat"
REG.EXE ADD "HKU\DefU\Control Panel\Desktop" /v Wallpaper /d "C:\Windows\Wallpaper.bmp" /f
REG.EXE UNLOAD HKU\DefU
The above code will first LOAD the hive for the Default User profile into a temporary hive called “DefU” in the “HKEY_USERS” part of the registry database. Then it will set a registry value for the desktop background for the Default User profile, which is the profile that is copied automatically when new users are created (the first time they log on). Finally, it will UNLOAD the temporary hive.
So how can I find the Ntuser.dat files in a script?
When we want to load hive for all users on a given machine we would want to find all user profiles on that machine as safely and easily as possible. We could of course just “browse” through the folders below “Documents and Settings” - or “Users” on Vista/Windows Server 2008 in the code – but we have a better approach that is more accurate.
In the following registry value:
“HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\XXX\ProfileImagePath”
you will find the correct profile folder path for all local users. XXX is the SID of the user, so by going through all of these keys we will have the full paths for all local NTUSER.DAT files.
I have written a VB Script function that lists the user profile folders on a given computer (in a single string separated by pipe “|” characters) – it being local or remote. The functions exclude profiles of the Systemprofile, LocalService, NetworkService and the Local Administrator account – in most cases these are not required in a cleanup, but the ElseIf statements can easily be excluded if required. The function is called “GetUserProfileDirsFromRegistry” and can be found right here.
And what about Roaming profiles you might ask? Well, the NTUSER.DAT files are all we need, so if you want to modify the roaming user profiles instead just go ahead and write a script that ‘browses’ through that roaming profile network location you have...
Delete this value or key…
Well, now we know how to load (or ‘mount’) a user hive within a script, now we just need to change something within that hive. You could probably come up with hundreds of cool things to do, but I have only chosen to use two functions – both of them are for deleting stuff within the loaded registry hive. Here is an explanation:
After a virus attack you might have to do a cleanup of the ‘Run’ key:
“HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run” for all local users. Maybe some piece of malware created an entry that you need to get rid of – for that purpose I created the DeleteSingleValueFromTmpLoadHive sub routine. This routine can delete a single value in the registry.
You might also want to delete an entire registry key, including subkeys and values, eg. “HKEY_CURRENT_USER \Software\Windowsecurity.com”, for that purpose I included the DeleteKeyAndSubsFromTmpLoadHive sub routine.
The golden combination
When combining what we have learned here, and performing some good old VBS scripting, we have a script that performs the following tasks:
1. Find all profile folders on the local computer by reading the registry values mentioned above
2. Ignore built-in OS related profiles, including the local administrator account
3. Load the registry hive from NTUSER.DAT files within the located profile folders
4. Delete a registry key, including all sub-keys, values etc. for each ‘mounted’ user profile *
5. Delete a single registry value for each ‘mounted’ user profile **
* ”
** ”
The script does NOT prompt to confirm when it is completed and any errors will be suppressed (by using ‘On Error Resume Next’ handling). This behavior can of course be modified to fit your needs. As this is not really a scripting article I cannot dive too much into the code, but if you are a bit familiar with scripting you should be able to get a pretty good idea of what it is doing.
The complete code example can be viewed and downloaded here! It has been tested on Microsoft Windows XP, Microsoft Windows Server 2003 and Microsoft Windows Vista.
SYSTEM is here!
At this point we can “hit” a single machine, the local computer from which we execute the script - or to be more accurate: all user hives on it. There is a major limitation though: users in general (hopefully) are NOT local administrators, and so they won’t be able to modify the registry for other users! This means we would want to either run the script as a local admin manually for all machines in the domain – or do something extremely effective: use a Group Policy on the machine level and configure a computer startup script. To learn more about computer startup script see the External Links section.
The beautiful thing about a computer startup script is that first of all it runs in the context of Local System, a very powerful account (so you can do almost anything), and second of all, it can be set to execute on thousands of computers within a few minutes by placing the GPO on the Active Directory domain, site or Organizational Unit (OU) level!
Please be aware, that the first load of the new computer GPO can ‘fail’, in this case you will have to restart the computer (and maybe perform a GPUPDATE /FORCE command just to be sure). Also, please give the script time to execute before logging on – both of these mentioned ‘issues’ can occur due to the way these policies are loaded during system boot. I am not going to address these Group Policy ‘features’ any further in this article.
If you have Wake-On-LAN (WOL) functionality on the network you can boot the computers during night time to do some “cleaning” and shut down the computers afterwards. So by combining scripting, WOL and Group Policy we can perform a very efficient cleanup job within short time – or some other job we might want performed without doing too much work: Imagination is the only limit!
Conclusion
We have seen how to combine scripting and computer startup scripts in Group Policy to perform a cleanup job in a very efficient way. We can now update user profiles even though they are not currently loaded into memory – without even logging on to the system(s).
This approach can be further developed to change other parts of the profiles, maybe files and folders, for all users on a given computer. Feel free to send me any feedback and ideas you might have on this.
Source : http://windowsecurity.com
