Set PowerShell as Your Default Shell in Windows 2012 Core

One thing I do hate in the new Windows 2012 Core setup is that PowerShell is not the default shell when one logs in. Microsoft made it so that in Core most of the Administration task are done via PowerShell or Remote Administratio tools. The fist thing one must do is to take ownership of the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\AlternateShells\AvailableShells Registry key since we will be modifying it. To achieve this Microsoft was nice enough to include the GUI version of the registry editor so we only need to type regedit in the command prompt and hit enter, after it comes up we can navigate to the key We right-click on the Key AvailableShells and click on Permission, on Permissions click on Advanced and click on Change Add the Administrator account, click on OK and on the previous screen click on Apply. Create a registry value under the key with the name of 40000 and set the value to:

powershell.exe -noexit -command "& {set-location $env:userprofile; clear-host}"

Now when you log off and log back in you will be greeted with a PowerShell window.

The reason why we use 40000 is that when you install the full GUI Explorer.exe will be 90000 and we want to PowerShell to be the Shell only if we are in Core or in Server-Gui-Mgmt-Infra.

To make life simpler here is a script you can either copy and paste in to a PowerShell window or create a .ps1 file and execute from there:

# Use C# to leverage the Win32API
$definition = @"
using System;
using System.Runtime.InteropServices;   
namespace Win32Api
{
    public class NtDll 
    {  
        [DllImport("ntdll.dll", EntryPoint="RtlAdjustPrivilege")]  
         public static extern int RtlAdjustPrivilege(ulong Privilege, bool Enable, bool CurrentThread, ref bool Enabled); 
    } 
}
"@
Add-Type -TypeDefinition $definition -PassThru
$bEnabled = $false
# Enable SeTakeOwnershipPrivilege
$res = [Win32Api.NtDll]::RtlAdjustPrivilege(9, $true, $false, [ref]$bEnabled)
  
# Take ownership of the registry key
$key = [Microsoft.Win32.Registry]::LocalMachine.OpenSubKey('SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\AlternateShells', [Microsoft.Win32.RegistryKeyPermissionCheck]::ReadWriteSubTree,[System.Security.AccessControl.RegistryRights]::takeownership)
$acl = $key.GetAccessControl()
$acl.SetOwner([System.Security.Principal.NTAccount]"Administrators")

# Set Full Control for Administrators
$rule = New-Object System.Security.AccessControl.RegistryAccessRule("Administrators","FullControl", "Allow")
$acl.AddAccessRule($rule)
[void]$key.SetAccessControl($acl)

# Create Registry Value
[void][Microsoft.Win32.Registry]::SetValue($key,"90000",'powershell.exe -noexit -command "& {set-location $env:userprofile; clear-host}"') 

I hope you found the blog post information useful.

Windows 2012 Server Different GUI Levels

I do have to say after using Windows 2012 server for a while in my lab and to host several Hyper-V machines for research and testing I do have to say I like it. It is a lot less resource intensive that Windows 2008 and Windows 2008 R2 are, the use of WinRM for Remote Management and the Server Manager interface makes administrating several servers a breeze, the best part of all is that I can administer the server completely with Windows PowerShell and for those cases that I need the GUI I can install and remove it to save a couple of MB of memory and reduce the attack surface of the box. 

The main reason that the GUI can be modified is that the components for it are now features of the OS:

• Graphical Management Tools and Infrastructure (Server-Gui-Mgmt-Infra):  provides a minimal server interface and server management tools. The components for it are:
  • Server Manager
  • Microsoft Management Console (MMC) and snap-ins
  • Subset of Control Panel
• Server Graphical Shell (Server-Gui-Shell): it  is dependent on the first feature and provides the rest of the GUI experience. The component of it are:
  • Desktop
  • Start screen
  • Windows Explorer
  • Internet Explorer

In he blog post I will cover how to use PowerShell for adding and removing of the features since PowerShell is available in server core with none of the components installed.

Here is Windows 2012 Server Core default install after logging on as administrator:

The terminal it provides is cmd.exe so to get to Windows PowerShell we need to type powershell and press enter.  In PowerShell we can use the Windows Feature functions to add and remove features. To list them we can use the Get-Command cmdlet:

PS C:\Users\Administrator> Get-Command *windowsfeature* -Type function,cmdlet

CommandType     Name                                               ModuleName
-----------     ----                                               ----------
Function        Get-WindowsFeature                                 ServerManager
Function        Install-WindowsFeature                             ServerManager
Function        Uninstall-WindowsFeature                           ServerManager

We find that we can get the Windows Features currently installed on the system, we can Install and Uninstall Windows Features also. to get a list of the options and examples of use for each we can use Get-Help cmdlet with the –Full paramter:

Get-Help Install-WindowsFeature -Full

Lets start by installing only the Graphical Management Tools and Infrastructure (Server-Gui-Mgmt-Infra), this will give us the tools for only managing the server but not for browsing the web or doing some activities that might cause the server to fall for a client side attack.  To install we just use the Install-WindowsFeature function and give it the parameter to restart the server after it is installed:

Install-WindowsFeature Server-Gui-Mgmt-Infra –Restart

Once it is ran PowerShell will show the progress of the installation:

Once the server starts and one logs on we can see that. Once the server reboots and one logs one Server Manager will come up automatically and can be used for management tasks.

If we want the full desktop experience and the addition of Internet Explorer we just need to run the following command to add that component:

Install-WindowsFeature Server-Gui-Shell –Restart

One shortcut to install all if you are in Core enumerate the features with the word GUI and since PowerShell is an Object Based shell we can pass the objects it returns to the Install-WindowsFeture function to install those:

Get-WindowsFeature *gui* | Install-WindowsFeature -Restart

Once the server reboots and the user logs in they should have a full GUI experience:

One thing to take in to account on this system with no GUI as a Core only server default install memory use was around 322MB of memory, with the Infrastructure Management Tool support only it was around 436MB of memory and with the full GUI Experience it was around 527MB of memory. I would recommend only having Server-Gui-Mgmt-Infra installed as a mid point of usability and reduces attack surface on the server.

I hope you found the information on the blog post useful.

PowerShell Basics–The Environment

I do have to say last year I started to write about PowerShell Basics and I then stopped. The main reason was that after talking with Dave Kennedy I decided to write a class for DerbyCon 2012 and boy did I thought it was going to be simple. I started believing that I could write it in a month or two and have it done since I use PowerShell on a daily basis, took me over 6 months, ended up with over 600 slides and was even modifying the slides on the airplane ride to Louisville since Microsoft came out with PowerShell Version 3.0 as part of the Windows Management Framework 3 a week before the conference. The good part is that I have now more than enough material to re-start the series and cover more fun stuff for the security professional and the admin alike.

I have given the PowerShell for Security Professionals class 3 times and one thing I decided for the blog posts that differs from the class it self is to provide short segments of fast and easy to use information for people to start getting in to Powershell.

What is PowerShell

PowerShell is Microsoft new Command Line Interface for Windows systems, it provides access to:

• Existing Windows Command Line tools.
• PowerShell Cmdlets (PowerShell own Commands)
• PowerShell Functions
• Access to the .Net Framework API
• Access to WMI (Windows Management Instrumentation
• Access to Windows COM (Component Object Model)
• Access to function in Windows DLL (Dynamic Linked Libraries)

As it can be seen PowerShell does provide a lot of access to different technologies and APIs on a Windows system making it ideal for administration and for security work alike.

Microsoft if making PowerShell the default management interface for many of it’s server products like Exchange, System Center Operations Manager, SQL Server, SharePoint Server and more, not only that but with Windows 2012 server the default install is core (GUI-Less System) and management is done via the command line or using Remote Admiration Tools. Microsoft included over 4 thousand new PowerShell cmdlets to make the administration of the new server the easiest ever using the command line.

PowerShell

Depending on the environment and systems you work with there are 2 main versions of PowerShell you will fond your self working with:

• PowerShell v2 –Included with Windows 7 and Windows 2008 R2. Available as a separate download for Windows XP SP3, Windows 2003 SP2, Windows Vista SP1 and Windows 2008 SP2. It can be pushed to hosts via Windows Server Update Service. Download t http://support.microsoft.com/kb/968929
• PowerShell v3 – Included with Windows 8 and Windows 2012. Available as a separate download for Windows 7 SP1 and Windows 2008 R2 SP2. It can not be pushed to hosts via Windows Server Update Service. Download http://www.microsoft.com/en-us/download/details.aspx?id=34595

On Windows System prior to Windows 8 and Windows 2012 PowerShell can be found under Start –> All Programs –> Accessories –> System Tools Depending on the architecture of the operating system there will be an x86 version and a x64 version of PowerShell. In addition to the shortcut to the PowerShell terminal there will also be shortcuts to the ISE (Integrated Scripting Environment) and Editor for PowerShell scripts that was included with PowerShell v2 and greatly improved on PowerShell v3. On Systems running Windows 8 and Windows 2012 with the Metro Interface one just need to type PowerShell or PowerShell_ISE to access the components. On a Windows 2012 Core System one just needs to type powershell.exe in the command prompt to load it.

Some recommendations when loading PowerShell:

• Since PowerShell provides access to many administrative functions it is recommended to run it as Administrator.

• If you are on a x64 system make sure you run the x64 version of it (The one with no x86 in the name of the shortcut)

 

When we launch PowerShell we are greeted with a blue command window with white text.

As it an be seen one can easily determine by looking at the title bar of the window if one is running as Administrator or not.

I would recommend to take the chance and customize the shortcut for launching PowerShell so as to provide the best experience. Right click on the PowerShell blue icon on the top left of the PowerShell Window and select Properties, make sure on the Options tab that the Edit Options are selected

On the Layout tab adjust the Screen Buffer Size Width to one where there is no need for side scroll bar making sure that both Width fields have the same value in both the Buffer Size and Window Size.

Ensuring a proper with will make the management of large amounts of output generated by some cmdlets easier to look at on the screen.

The terminal has several keyboard shortcuts that can be used, a list of the most common are in the table bellow:

On PowerShell v2 the ISE can also be use as an interactive command prompt where commands are entered in on window and output is shown in the next, in addition it is is a script editor with syntax highlighting

On PowerShell v3 the ISE has been greatly improved, offering a consolidated command prompt and also provides a cmdlet help pane

In addition ISEv3 also provides:

• Intellisense for Cmdlets and parameters with parameter help popup.
• Intellisense will provide values for parameters based on enumerations and pre-defined sets.
• Intellisense will perform smart matching for cmdlet names
• Intellisense will show path options for filesystems and PSProviders
• Intellisense will show variables
• Intellisense will show for objects properties and methods available

It will also provide an Icon Reference that makes it easier to select in Intellisense what one wants to choose.

The command prompt on ISEv3 can be said to be the closest one can get to the perfect terminal for PowerShell with the exception that since it is not a true terminal several console commands are not supported. To get a list of the unsupported console commands one can take a look at the $psUnsupportedConsoleApplications variable

There are some other alternatives to consoles I recommend people to also try out if they find the one included with Windows to limiting:

• PowerCMD http://www.powercmd.com/
• Console http://sourceforge.net/projects/console/
• conemu-maximus5 http://code.google.com/p/conemu-maximus5/

For my next blog post I will go in to running commands, exploring the commands and using the help system.

Metasploit Framework Guides Updated for Using Git

I updated my installation guides for Metasploit Framework for Ubuntu and OS X for the recent changes where Git is now used for updating. I do have to say I'm a happy ow, since the addition on Gemcache folder to host all the Gems for both the Open Source base and the Comercial Products based of it SVN has timed out or error out in updating those so with this change it resolves this issue. If you have used my guides for you current setups just:

cp /usr/local/share/metasploit-framework/database.yml /tmp
cd /usr/local/share/
rm -rf metasploit-framework
git clone https://github.com/rapid7/metasploit-framework.git
cp /tmp/database.yml /usr/local/share/metasploit-framework/ 

Should We Exploit Every Vulnerability to Prove it Exist?

Recently I made a comment in twitter where I said that I cringe every time a hear that to confirm a vulnerability an exploit must be ran to confirm and prove it.  Some people agreed that it is not the perfect solutions other argued that it is the best one. Let me explain in more that 140 character chunks why I cringe. The scenario I refer to is that of an internal security team managing the security of their infrastructure on a daily basis.  

1. There are safer ways to check if a vulnerability is present after performing a patch deployment or a configuration change. Most scanner now a days have credential checks where they check versions of files, presence of package and even if the server has been rebooted or not in addition to the network validation of connecting to a possible service and interacting with it to try to determine in a safe way if the service is vulnerable or not. We also have systems in most medium to big organizations that inventory the hosts and can produce detailed reports of what patches have been installed and which not, some tools are even free. Many times the Security team just needs to ask for confirmation from one of the infrastructure teams or have read permissions to those inventory systems. Other times why may just need to put a bit of elbow grease and determine what specific permission they would need on a account that is only used for scanning. 
2. Not all exploit frameworks and tools have all exploit and attacks for every vulnerability that you may be exposed to. In fact network remote exploits are every time less and less and the numbers have shifted to client side, even with my love of Metasploit Framework I know that Cavas, Core Impact and many other tools will have exploit that the other does not and many just do not get added to the tools, others would require that we automate the user actions that would execute the vulnerable software against a file or attacker system to prove it is vulnerable. this mean that one is leaving a very large number of possible vulnerabilities missed if exploitation is the only way.
3. I do not discard the use of exploits as a verification method, it could be use for certain critical vulnerabilities where we may have taken actions to implement countermeasures against and a patch is not present. Now this has to be done in a planned way where both the security team and other infrastructure teams must participate to be able to deploy, test and validate. Running any exploit against all reported vulnerable systems is risky since many may crash a service or the server, if done without planning and proper communication between the teams this could have business impact consequences and further deteriorate any existing political or personal problems in a organization. 

One of the arguments I got was that many companies the teams do not talk, are just not willing to work together or by design there is a separation of roles and responsibilities that prohibits working together. To be honest I see this as a big problem in management and leadership in a organization. Are there companies that are like this? yes. Should we try our best to change this if we work in such a company? absolutely. If we are in that situation our success will vary or we may not be successful at all but that does not make running exploits for confirmation without planning or knowing the risks that it may cause the option and solution. I know that some will agree and others will not but I felt it was better I wrote it down that sending twitter public  and direct messages al day long and be able to transmit my reasoning for the comment.  Hope my 0.02 cents on the subject may be helpful to someone and I'm open to opinions and counter arguments.