Tuesday, April 20, 2010


Write-line "Hello World"

I have been distracted from some work I was doing for computer account security research, so I thought I would get back to it by sharing some of limited fuzzing results for UAC values of objects use this attribute (anything using the User class, such as user accounts, and computer accounts).

The various bit values are shown in this table from kb305144


Having rights to write to this value does not guarantee all values can be written. There are two values related to delegation, which were smartly locked down to Domain administrator edits only. Some of the bit values are not in use, but can be used, while others are not in use and cannot be used. I break these down as follows:

M = Mandatory entry, but can only contain one type. Used for account type
N = Not possible to edit (note: domain administrator level accounts may be able to try to edit these values without error, but it won't write the value)
P = Possible to edit when write UAC property permission or write all properties permissions is possessed by editor
A = Domain admin level rights required to edit:
- = Can be used in a modify operation, but will not be written

Bits: 0000 0011 0111 1111 0011 1011 1010 1010
Oper: ---- --PA -PPP APPP --MM M-MM PNPN P-PN

When trying to write values to UAC, you can provide in hex format or integer format. Other entries or invalid characters will throw errors. Negative numbers can be provided, but they will be handled with the appropriate bit values and hold to the same restrictions.

As for computer account security, I find it interesting that the creator of a computer account can manipulate some of these values that would be better left to an administrator. One in specific would be the account type values allowing more interactive access like I mentioned in my avoiding account lockout article. Luckily, delegation enable/disable is restricted, so if you have Domain admins that understand the implications of this and restrict its implementation, you have some degree of safety. Once enabled though, maybe another story.

Wednesday, April 7, 2010

Scripting games, to script or not to script?

I'm debating this one. Perhaps I'll rearrange some of my existing code for submission. Currently I'm rewriting most of the NetBIOS name protocol in pure powershell/.Net. This may be finished by then.

Monday, April 5, 2010

Managing large sets of scripts

Over the last year I have been rolling out a lot of Powershell functions that I like to have readily available in my profile. Originally this was one large block over roughly 2000 lines of code, which gets a bit unmanageable. Eventually I created a base profile, a secondary profile with reference functions, and multiple executable and header files to split up functions based on usage. This has become 42 files and 5300 lines of self updating and centrally managed code with stable and beta sets. As this set of files continues to grow rapidly, I am evaluating the design principles again to see if there are any better solutions out there. This is what I have at the moment:

1) Base profile. Changes between beta copy and production copy on a function call that overwrites the file at $profile with the appropriate version. This base profile checks all files at a specific network share, either prod share or beta share, compares a set of files on the local system with the ones on the share for any changes/new files that need updating, updates and applies the secondary profile with the "." operator.

2) Secondary profile. Contains a few complete functions for parsing system names, command line options, and a few other functions that don't fit well in other files. Besides this there are pointer functions that call external scripts at ($localpath + "extFile.ps1"). These calls can directly call a stand alone script, or call a script that contains multiple executable functions. In this case, the name of the function + arguments is passed and interpreted by something like this:

$server = $args[0]
$function = $args[1]
&$function $server

3) External scripts. Stand alone that manage arguments passed. Options passed are general hash table's with switches or valued arguments passed. External scripts may load header type files with the "." operator. Since the files are separate from the profile, the scripts may be updated by another process without reloading the profile.

4) Header files. Contain a range of functions for a specific area (hardware, directory, security, etc) that would not be very useful when used directly. Functions here may be required for several different executable functions. They also allow for rapid development of future executable functions. The problem here is designing functions that are useful for what you are doing when you write them, and still usable for other code without having to be rewritten, or written with excessive capabilities the first time.