July 2010
Another month filled with labs run in the Nordics but also in the US. Marcus busy doing pentests, Johan and Mikael ran the Deployment Geek Week in Las Vegas with delegates from all corners of the world. A success we may look into to repeat as the industry is rapidly moving towards Windows 7 and many need a touch up of their deployment skills.
Have you already taken a Microsoft class, like the 6294A "Planning and Managing Windows 7 Desktops and Environments" but like to dive deeper into to the real world deployment? Then sign up for any of our deployment labs. A road map is now located on our website.
Finally, remember that you can sign us up for shorter projects for onsite or online (Live meeting etc) consulting if you feel you are ready to deploy or implement any security measures, but just want to get a final check on your environment.
 |
Beyond unsupported - Windows XP SP3 Deployments
|
Even though Windows 7 is coming on big, you would be surprised to find out how many companies that are still deploying Windows XP. In this article I have gathered some nifty (unsupported) tricks for Windows XP Deployments such as HAL replacement, mass storage drivers and more...
When deploying Windows XP there a few tricks you can use to have a single image for all your machines, and also injecting storage drivers offline, eliminating the need for rebuilding your image. Below you find some (very unsupported) tweaks for the following:
1. HAL Replacement
2. Handling Multiple CPU Vendors (Intel & AMD)
3. Offline injections of Mass Storage Drivers
HAL Replacement
In 2005 I wrote my first general purpose script for HAL replacement, and back in 2008 it was still the most downloaded script on the myitforum website. The most up to date script for HAL replacement (that I know of) is maintained by Michael Petersen in Denmark
Link: http://blog.coretech.dk/osdeploy/handling-hal-switching-during-xp-deployment-no-bsod-0x07-error
Handling Multiple CPU Vendors (Intel & AMD)
If you create an image on a machine with Intel CPU you quickly find that it will bluescreen when deploying it to a machine with AMD Cpu. The reason is that the intelppm service doesn't work very well with AMD Cpu's (who would have guessed :) ).
One workaround is to have a script detecting the CPU type, and disable that service when deploying to AMD machines.
Another method is simply deleting the IntelPPM.sys file in C:\Windows\System32\Drivers
Here is a sample script: http://www.deployvista.com/Repository/tabid/71/EntryId/26/DMXModule/396/ctl/EntryDetails/mid/396/language/sv-SE/Default.aspx
Note: If deploying via MDT 2010 and/or ConfigMgr 2007 you need to update the script to reflect the correct path of the registry hive.
Offline injections of Mass Storage Driver
In Windows XP, injecing storage drivers offline is not supported, unless you use ConfigMgr 2007, then it suddenly is ... Mr David Ruhle has put together a nice script that does offline injection for Windows XP...
http://ruhle.wordpress.com/2009/10/20/injecting-intel-storage-drivers-into-xp-wims-via-mdt
Download link to script: http://brewcitycrawlers.com/ztiwiminjection.zip
/ Johan
|
Deploying Windows Server using MDT – Settings you may consider
|
At MMS last time I did a session about server Deployment and after that a got some questions about what default settings I always use when I deploy servers, so I thought I’ll share that with you. I assume you are going to deploy the servers using MDT 2010, but even if you don’t, these settings does apply to basically all server deployment. The small issue is that almost every single unattended xml file you can find is based on clients and these settings does not really apply all the times. So let’s begin with all the settings:
First of all, I “always” create a separate Deployment Share for Server deployment and the reason is very simple, the settings you would like to have in bootstrap.ini and customsettings.ini are commonly very different
Number 1: The Bootstrap.ini
Simple, basically untouched, I normally do not put in names/passwords in this (at least not when deploying servers) so it looks like this:
[Settings]
Priority=Default
[Default]
DeployRoot=\\SRV04\MDTPrd$
SkipBDDWelcome=YES
Number 2: The Custom Settings.ini
Most of the settings in CS.INI is simple, it’s just about not answering any questions. As you can see in this one, I use MacAddress, TaskSequenceID, Model and default. I like using TasksequenceID, then I don't need to modifysettings in the TaskSeqence so much, it can all be set in one location, but that’s just me. To make TasksequenceID to work, you need to do one modification to the tasksequence it self. You need to modify the settings on all three location for “Gather Local” and flip to “Gather Local and process rules”. You don’t need to type in any file name in the dialog box, it will use customsettings.ini by default. One other thing, if you check the driver settings, I use “Drivergroup” to make sure that all the drivers get in correctly, however, I have to be honest here. When it comes to servers, I just install some of the drivers need as “drivers”, most of the server vendors have really nice utilities that dynamically fixes that. So for HP, well I run the SupportPack application as a part of deployment (hpsum.exe /s /use_web) will make that app to do an inventory of that hardware, patch firmware and drivers. That’s nice or at least a bit handy. That’s why you see a Mandatory Applications on one of the models, that is just a bundle and that will the fire away the support pack in the task sequence.
[Settings]
Priority=MACAddress, TaskSequenceID, Model, Default
[Default]
SkipBDDWelcome=YES
OSInstall=Y
SkipAppsOnUpgrade=NO
SkipCapture=YES
SkipAdminPassword=YES
SkipProductKey=YES
SkipTimeZone=YES
SkipPackageDisplay=Yes
SkipLocaleSelection=NO
SkipDomainMembership=NO
SkipBitLocker=YES
DomainAdmin=Administrator
DomainAdminDomain=DOMAIN
DomainAdminPassword=Password01
JoinDomain=network.com
SLShare=\\MDT01\Logs$
SkipSummary=YES
SkipFinalSummary=YES
FinishAction=REBOOT
WSUS=http://wsus.network.com
[TSSRV001]
DriverGroup001=%MAKE%\Common\W7
DriverGroup002=%MAKE%\%MODEL%\W7
[TSSRV002]
DriverGroup001=%MAKE%\Common\W7
DriverGroup002=%MAKE%\%MODEL%\W7
[ProLiant ML150 G6]
MandatoryApplications001={3eea6ea8-39bb-4c33-a2f4-c7d8767a3510}
Number 3: Settings in the Task Sequence:
In the Task sequence I enable Windows Update (always disabled by default) and I add roles/features. On lab/play servers I add (prior to the first Windows Update pass)
“Install Roles and Features”, SNMP (needed by SupportPack in some cases), Desktop Experience, PowerShell (ICE on R2, normal Powershell on the rest, including core servers in R2), Wireless support (also just for LAB setups) and of course, all the flavor of .NET Framwork J. It really depends on the situation, ok. If deploying servers to play with, I add stuff that I need and might need, when deploying servers in production “less is more” someone told me J
To make the drivers stuff work (You remember, the “DriverGroup001” stuff you need to modify the TaskSequence setting in “Preinstall\Inject Drivers” and set that to Nothing. Then the drivers that you specified in customsettings.ini will be used, otherwise it will try to match drivers PNP number all over the place.
But, there are a bunch settings that you most likely would like to modify, and they need to be changed in the unattend.xml file, so right click on the task sequence and select the OS tab and then click on “Edit Unattend.xml” and modify the following (I don’t change this all the time, it of course depends on the customer)
Microsoft-Windows-BrowserService | MaintainServerList (Only for Windows Server 2008, not for R2)
This settings some of the “I would like to be the master browser on the network”
I normally set this to No
Microsoft-Windows-IE-ESC | IEHardenAdmin
Microsoft-Windows-IE-ESC | IEHardenUser
This will make the web browser more in a “it works” state
If this server is a “play around/lab/demo” I set those to “false”. In production, only when the customer really understand this setting
Microsoft-Windows-IE-InternetExplorer | DisableFirstRunWizard
Microsoft-Windows-IE-InternetExplorer | DisableOOBAccelerators
This is a client “thing”, who cares about settings in IE on the server?
I ALWAYS set those to True
Microsoft-Windows-OutOfBoxExperience | DoNotOpenInitialConfigurationTasksAtLogon
When you do interactive configuration this one make sense, but since you are trying to deploy the server using MDT, there is no reason to see this every time you logon.
I ALWAYS set this to True
Microsoft-Windows-ServerManager-SvrMgrNc | DoNotOpenServerManagerAtLogon
Same story here, no point of having this in the face every time you logon to the server
I ALWAYS set this to True
Microsoft-Windows-TerminalServices-LocalSessionManager | fDenyTSConnections
I enable RDP from the beginning, even if there are some fancy policys in AD, it always ends up with me walking down to the server and use the KVM, because it was something that did not “apply” correctly, and I hate walking
I ALWAYS set this to False
Networking-MPSSVC-Svc | FirewallGroups | FirewallGroup
You also need the firewall opened, and here is the “how to do for that”
Networking-MPSSVC-Svc | FirewallGroups | FirewallGroup | Active
Set to True
Networking-MPSSVC-Svc | FirewallGroups | FirewallGroup | Group
Set to Remote Desktop
Networking-MPSSVC-Svc | FirewallGroups | FirewallGroup | Key
Set to RemoteDesktop
Networking-MPSSVC-Svc | FirewallGroups | FirewallGroup | Profile
Set to All, Public or Domain
So, now you should have a pretty nice tasksequence for a server J
Happy deployment
/mike
|
Beware of the evil stick!
|
On July 16 Microsoft published an advisory regarding a vulnerability in Windows shell than can allow attackers to execute code on your computer.
The most alarming thing regarding this issue is that there in not yet a patch available even though the evil code is published on the web.
The vulnerability exists in the way Windows parses shortcuts and evil code may be executed if a specially crafted shortcut is displayed.
This means that if you open a drive or folder containing this shortcut, then evil code will be executed on your system.
Obviously USB drives will be a very popular vector for this attack, but the attack is not limited to them, any shortcut-file (.LNK extension) is a potential threat whether you find them on the web, as attachments in your inbox or in the root folder of a removable drive.
For years we have been recommending customers to disable the autorun-feature in Windows XP to prevent USB Drive-by-attacks. However this vulnerability goes beyond the old autorun issue. Even if a computer has autorun disabled the attack will be successful if only the drive is opened. This is scary!
So what can we do to prevent this?
Well, wait for the patch is of course one option but Microsoft presents 2 workarounds, but both of them have different drawbacks. (See the link to the advisory below for details)
My personal recommendation would be to use the built in feature in Windows called Software Restriction Policies (Windows XP) or (Applocker in Windows 7). 2 simple rules would prevent tis attack. One default deny for all .lnk-files, and then one optional rule for a location where you want to store your legit lnk-files (For example on the desktop). As long as you do not actively put a malicious lnk-file in your trusted folder you will be safe.
Until then, beware of the (USB) stick!
Link to the advisory is posted here: http://www.microsoft.com/technet/security/advisory/2286198.mspx
If you want to learn more about how hackers attack Windows platforms, then I recommend you to attend my 3-day windows hacking class J
Regards,
Marcus Murray
Where to find us
Come meet us at any of our labs. Below is a where we will hold labs during the next 2 months
Coming Labs in the US:
Hacking the Windows Platform, New York August 10-12
Zero Touch with Johan, Los Angeles August 24 -26
Lite Touch with Mikael, New York September 14-16
Zero Touch with Johan, Chicago September 14-16
Mastering SCCM 2007 SP2 R2/R3, Chicago September 15-17
For complete schedule listing go to http://en.truesec.com
|
