archiveren

Tagarchief: group policy

A cool trick that was shown a couple of years ago, called BadUSB, turns random USB devices into possible snooping devices.

What if you plugin a USB-stick you found on the street and it turns out to open up an Internet Browser and steers you into a specific website, downloading and launching an application? USB has many profiles, so instead of a “mass storage device” (what you would expect from a USB drive that looks like an mass storage device) it imitates a HID device such as a keyboard or mouse… So your “drive” becomes a keyboard!
Automate some pre-defined keystrokes that randomly start after plugging in the USB device, like windows-logo+r, type https://mendelonline.be/temp/runme.exe, press enter a couple of times, and then run the same with %userprofile%\downloads\runme.exe and you’ll be pretty close running your executable without any user interaction!

Edit 26/05/2016: Exactly like this: https://www.informationsecurity.ws/2016/01/pwning-windows-7-with-avg-av/

Not that many technologies exist to prevent this from happening on Windows though… But I found some document on irongeek explaining how to block USB devices using Group :Policy. (local policy can also be used, you don’t need to have a domainjoined computer): http://www.irongeek.com/i.php?page=security/locking-down-windows-vista-and-windows-7-against-malicious-usb-devices

Open your local policy editor, open up “Computer Configuration->Administrative Templates->System->Device Installation->Device Installation Restrictions”, and start messing around 🙂

Capture

local group policy settings

I started with checking which USB devices were already known on my computer… You can use, always awesome, nirsoft’s “USBDevview” to have a look at your USB history.

So, I deleted all history, with the idea to start clean.
After deleting everything, I let Windows re-discover all devices default to my laptop.
Next, I started plugging some USB devices I owned and let it register and install.

Then, the actual blocking policy was enabled.

Another USB-device I didn’t install for testing purposes was plugged into my computer. And nothing happened.
Perfect 😎

I still needed to install that device anyway, but starting device manager with administrative credentials, allowed me to overrule the blocking policy, and to install the USB device for future use…
(Note: once a USB device is “installed”/”registered” into windows, it can be plugged in an used anytime in the future without the admin-overrule technique…)
Or you can start defining classes of usb devices, manufacturers, etc… Just check irongeek’s page 🙂

computermanagement

unrecognized

usbdevview

datatraveler not being used

computer

update driver as administrator

cptmgmtinstalled

good to go

installed

datatraveler active!

One of the recent security “packs” in the Microsoft ecosystem is LAPS, Local Administrator Password Solution (https://technet.microsoft.com/library/security/3062591). It tries to solve one of the ancient issues regarding the local administrator account on a Windows machine. It needs to exists, and it needs to have , preferably, secure and unique password. Yet, in many organizations, the default administrator account is enabled, with the exact same password on every machine…
Result: once you know the password, you’re an admin on every workstation! (latteral movement) 🙂
The idea of LAPS is to randomize each password of each workstation, and store it in the Active Directory as an confidential attribute of the computer object.

LAPS can be configured to manage the local administrator account, .\administrator, or another, configurable and existing, account.

Suprise!

Enter MS14-025.
MS14-025 disables the usage of CPasswords in Group Policy https://support.microsoft.com/en-us/kb/2962486 .

This is a good thing!

CPasswords allowed unsuspicious administrators to put plaintext password in publicly-readable group policy xml-files!
(almost plaintext as the passwords are encrypted with a known password).

Here is the password btw (https://msdn.microsoft.com/en-us/library/2c15cbf0-f086-4c74-8b70-1f2fa45dd4be.aspx#endNote2):

 4e 99 06 e8  fc b6 6c c9  fa f4 93 10  62 0f fe e8
 f4 96 e8 06  cc 05 79 90  20 9b 09 a4  33 b6 6c 1b

Yet, this also means you cannot create a new account using Group Policy anymore.
Little “forgotten” side-effect…

And there is no real alternative to actually create a local account on a domain member…
(At installation of LAPS clientside-MSI, an argument can be set to actually create a new account…)

One way to solve this is to create a new local user is using a startup script!
The script below was tested on Windows 10, some things did break between 8.1 and 10!
Deploy it using SCCM or GPO startupscripts!

It creates an account and LAPS will change its password on first gpupdate

Note, another point of discussion is the fact whether the .\administrator should be used or not. There are a lot of different opinions here…
For LAPS, some people at Microsoft advise to “just use the .\administrator account, because you know it will always be there”. (note: account is prone to bruteforce attacks as a lockoutpolicy never applies to the rid500)
In other cases (src1, src2, src3), Microsoft advises to disable the .\administrator account, create another administrator account and use that one…
Point is, when you’re not using bitlocker, there is a tool called “Offline Windows Password & Registry Editor” by pogostick which can always enable and reset the .\administrator account’s password.
So, the choice is up to you! My humble opinion is to use another account 🙂 (otherwise I wouldn’t be going through all this trouble to get another one 🙂 )

See https://gist.github.com/mendel129/59a175e49c57b8ef9847

#https://gist.github.com/mendel129
function create-localaccount ([string]$accountName = "testuser", [string]$Computer = "localhost") {   
   $comp = [ADSI]"WinNT://$Computer"  
   $user = $comp.Create("User", $accountName)  
   $user.SetPassword(([char[]](50..150) + 0..9 | sort {get-random})[0..18] -join '') # set a random password, let it be changed by LAPS afterwards
   $user.SetInfo()   
}

function get-currentlocaladministrators([string]$Computer = "localhost"){
   $obj_group = [ADSI]"WinNT://$Computer/Administrators,group"
   $members= @($obj_group.psbase.Invoke("Members")) | foreach{([ADSI]$_).InvokeGet("Name")}
   $members
}

function add-localadministrators([string]$accountName = "testuser", [string]$Computer = "localhost"){
   $AdminGroup = [ADSI]"WinNT://$Computer/Administrators,group"
   #$User = [ADSI]"WinNT://$hostname/$accountName,user" #something broke on windows 10
   #$AdminGroup.Add($User.Path) #something broke on windows 10
   $objUser = [ADSI]("WinNT://$accountName")
   $AdminGroup.PSBase.Invoke("Add",$objUser.PSBase.Path)
}

get-currentlocaladministrators -Computer "localhost"
create-localaccount -Computer "localhost" -accountName "testuser"
add-localadministrators -Computer "localhost" -accountName "testuser"
get-currentlocaladministrators -Computer "localhost"

Some good LAPS references: