Is Microsoft Windows User Account Control (UAC) a Security Feature?

User Account Control (UAC) helps mitigate the impact of malware.

Each app that requires the administrator access token must prompt for consent. The one exception is the relationship that exists between parent and child processes. Child processes inherit the user's access token from the parent process. Both the parent and child processes, however, must have the same integrity level. When a standard user attempts to run an app that requires an administrator access token, UAC requires that the user provide valid administrator credentials.

Integrity levels are measurements of trust. A "high" integrity application is one that performs tasks that modify system data, such as a disk partitioning application, while a "low" integrity application is one that performs tasks that could potentially compromise the operating system, such as a Web browser. Apps with lower integrity levels cannot modify data in applications with higher integrity levels.

A user that is a member of the Administrators group can log on, browse the Web, and read e-mail while using a standard user access token. When the administrator needs to perform a task that requires the administrator access token, Windows 10 automatically prompts the user for approval. This prompt is called an elevation prompt, and its behavior can be configured by using the Local Security Policy snap-in (Secpol.msc) or Group Policy.

Policy setting "User Account Control: Admin Approval Mode for the Built-in Administrator account" controls the behavior of Admin Approval Mode for the built-in Administrator account.

• Enabled The built-in Administrator account uses Admin Approval Mode. By default, any operation that requires elevation of privilege will prompt the user to approve the operation.
• Disabled (Default) The built-in Administrator account runs all applications with full administrative privilege.

Refer the reference [2] for more information on policy settings.

The UAC User Experience

When UAC is enabled, the user experience for standard users is different from that of administrators in Admin Approval Mode. The recommended and more secure method of running Windows 10 is to make your primary user account a standard user account. Running as a standard user helps to maximize security for a managed environment. With the built-in UAC elevation component, standard users can easily perform an administrative task by entering valid credentials for a local administrator account. The default, built-in UAC elevation component for standard users is the credential prompt.

Is UAC secure?

UAC is not a security feature. It’s a convenience feature that acts as a forcing function to get software developers to get their act together [4].

There’s a control panel that lets you specify how often you want to be prompted by UAC. You can set any of four levels:

1. Always notify
2. Notify only when apps try to change settings, use the secure desktop
3. Notify only when apps try to change settings, don’t use the secure desktop
4. Never notify

Although it looks like there are four settings, in a theoretical sense, there really are only two settings.

1. Always notify
2. Never notify

The reason why all the other options collapse into Meh is that the Notify only when apps try to change settings option can be subverted by any app simply by injecting a thread into Explorer and doing its dirty work there. Since Explorer is a program that the setting allows to elevate silently, this lets you perform a silent elevation from any thread that has thread injection rights into Explorer (which is pretty much any program running at medium integrity level or higher) [5].

UACMe [3]

UACMe [3] helps defeating Windows User Account Control by abusing built-in Windows AutoElevate backdoor. Relying on UAC on Windows 7 and Windows 10, however, is not enough. Attackers can use tools such as UACMe to gain access to a system.

Reference:
[1] https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works
[2] https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-security-policy-settings
[3] https://github.com/hfiref0x/UACME
[4] https://channel9.msdn.com/
[5] https://devblogs.microsoft.com/oldnewthing/20160816-00/?p=94105

Read More

SigRed (CVE-2020-1350) Registry Workaround

Security researchers at Check Point discovered a critical security flaw in Microsoft DNS servers. The flaw allows remote code execution attacks which leads to the total compromise of the server. The DNS server role is often bundled in Enterprise Domain Controllers in corporate environments. Hence, the exploitation allows an unauthenticated, remote attacker to gain domain administrator privileges and seize complete control of an organization's IT infrastructure. The flaw is named 'SigRed' by Check Point and assigned the CVE-2020-1350 with a CVSS base score of 10. The flaw is wormable, meaning a single exploit of the issue can trigger a chain reaction that allows attacks to spread from one computer to another.

To work around this vulnerability, make the following registry change to restrict the size of the largest inbound TCP-based DNS response packet allowed:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters

TcpReceivePacketSize

Value = 0xFF00

Note You must restart the DNS Service for the registry change to take effect.

    The Default (also max) Value = 0xFFFF
    The Recommended Value = 0xFF00 (255 bytes less than the max)

After the workaround is implemented, a Windows DNS server will be unable to resolve DNS names for its clients when the DNS response from the upstream server is larger than 65280 bytes.

Reference:

[1] https://research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/

[2] https://support.microsoft.com/en-us/help/4569509/windows-dns-server-remote-code-execution-vulnerability

Read More

Cracking Passwords with John the Ripper

John the Ripper (JtR) is a password cracking tool originally produced for UNIX-based systems. It was designed to test password strength, brute-force encrypted (hashed) passwords, and crack passwords via dictionary attacks.

The tool comes in both GNU-licensed and proprietary (Pro) versions. An enhanced “jumbo” community release has also been made available on the open-source GitHub repo.

JtR works in three different ways.

1. Dictionary attack
2. Brute-force attack
3. Rainbow tables: A pre-computed list of password hashes (derived from commonly set passwords) is compared against an existing data dump to find the correct password in its plaintext form.It should be noted that this approach will be ineffective when password hashes are salted and salt values are too large, all of which increases the overall complexity.

JtR provides at least three modes along with an “external” mode, which is basically letting a user define a customized mode via a configuration file.

• Single crack mode: JtR creators recommend running this mode first as it’s considered the quickest. Single crack mode uses information from UNIX passwd files -- users' full names, usernames, etc. -- as present in GECOS fields within UNIX passwd/shadow files to “guess” passwords. This can be helpful in cases when a user has set a password for an account based on commonly available information or phrase in the username (e.g. admin:password, john:john123).
• Wordlist mode: This mode relies on the user providing a text file with a list of passwords, ideally one per line and no duplicates.
• Incremental mode: JtR’s equivalent of brute-force is the most powerful cracking mode, but is so time consuming that for a password complex enough, it may never be able to complete in practical course of time and never terminate.

Usage Examples:

Example 01:

Now, let's assume you've got a password file, "mypasswd", and want to crack it. The simplest way is to let John use its default order of cracking modes:

	john mypasswd

This will try "single crack" mode first, then use a wordlist with rules,
and finally go for "incremental" mode.

If you've got some passwords cracked, they are stored in $JOHN/john.pot. The john.pot file is not meant to be human-friendly. You should be using John itself to display the contents of its "pot file" in a convenient format:

	john --show mypasswd

If the account list gets large and doesn't fit on the screen, you should, of course, use your shell's output redirection.

You might notice that many accounts have a disabled shell. You can make John skip those in the report. Assuming that the disabled shell is called "/etc/expired", the command would be:

	john --show --shells=-/etc/expired mypasswd

or shorter, but will also match "/any/path/expired":

	john --show --shells=-expired mypasswd

or if you also want to ignore some other shell, say "/etc/newuser":

	john --show --shells=-expired,newuser mypasswd

To check if any root (UID 0) accounts got cracked:

	john --show --users=0 mypasswd

or to check for cracked root (UID 0) accounts in multiple files:

	john --show --users=0 *passwd* *.pwd

To display the root (username "root") account only:

	john --show --users=root mypasswd

And finally, to check for privileged groups:

	john --show --groups=0,1 mypasswd

4. You might prefer to manage the cracking modes manually. It is wise to start with "single crack" mode:

	john --single mypasswd

or since the GNU-style double dashes are optional and since option names can be abbreviated for as long as they remain unambiguous:

	john -si mypasswd

You should not abbreviate options in scripts which you would want to work with future versions of John since what is unambiguous now might become ambiguous with the addition of more options.

If you have more files to crack, it is preferable to load them at the same time:

	john --single passwd1 passwd2

or even:

	john --single *passwd* *.pwd

This way, John will run faster and might even crack more passwords than it would if you ran it on each password file separately.

5. To catch weak passwords not derived from readily available users' personal information, you should proceed with cracking modes demanding more processor time. First, let's try a tiny wordlist with word mangling rules enabled:

	john --wordlist=password.lst --rules mypasswd

or abbreviating the options:

	john -w=password.lst -ru mypasswd

Then proceed with a larger wordlist, also applying the mangling rules:

	john --wordlist=all.lst --rules mypasswd

If you've got a lot of spare disk space to trade for performance and the hash type of your password files is relatively slow, you may use John's "unique" utility to eliminate any duplicate candidate passwords:

	john --wordlist=all.lst --rules --stdout | unique mangled.lst
	john --wordlist=mangled.lst mypasswd

If you know that your target hash type truncates passwords at a given length, you may optimize this even further:

	john --wordlist=all.lst --rules --stdout=8 | unique mangled8.lst
	john --wordlist=mangled8.lst mypasswd

Alternatively, you may simply use huge.lst available on Openwall wordlist collection CDs. It has word mangling rules pre-applied for the most common languages and it has any duplicates purged.

Depending on target hash type, the number of different salts (if applicable), the size of your wordlist, rules, and processor performance, wordlist-based cracking may take anywhere from under a second to many days.

You do not have to leave John running on a (pseudo-)terminal. If running John on a Unix-like system, you can simply disconnect from the server, close your xterm, etc. John will catch the SIGHUP ("hangup" signal) and continue running. Alternatively, you may prefer to start it in the background right away:

	john --wordlist=all.lst --rules mypasswd &

Obviously, the "&" is specific to Unix shells and will not work on most other platforms.

You may further enhance this by specifying a session name:

	john --session=allrules --wordlist=all.lst --rules mypasswd &

This ensures that you won't accidentally interfere with the instance of John running in the background if you proceed to start other sessions.

To view the status of a running session, use:

	john --status

for the default session or:

	john --status=allrules

for any other session. This works for both interrupted and running sessions. To obtain the most up-to-date information from a running session on a Unix-like system, send a SIGHUP to the appropriate "john" process.

Any interrupted sessions may be continued with:

	john --restore

or:

	john --restore=allrules

Finally, to make John have less impact on other processes, you should set the option "Idle = Y" in the configuration file.

To only crack accounts with a "good" shell (in general, the shell, user, and group filters described above work for all cracking modes as well):

	john --wordlist=all.lst --rules --shells=sh,csh,tcsh,bash mypasswd

Like with all other cracking modes, it is faster to crack all the files you need cracked simultaneously:

	john --wordlist=all.lst --rules passwd1 passwd2

You can crack some passwords only. This will try cracking all root (UID 0) accounts in all the password files:

	john --wordlist=all.lst --rules --users=0 *passwd*

Alternatively, you may wish to not waste time cracking your very own passwords, if you're sure they're uncrackable:

	john --wordlist=all.lst --rules --users=-root,solar *passwd*

Sometimes it is useful to split your password hashes into two sets which you crack separately, like:

	john --wordlist=all.lst --rules --salts=2 *passwd*
	john --wordlist=all.lst --rules --salts=-2 *passwd*

This will make John try salts used on two or more password hashes first and then try the rest. Total cracking time will be almost the same, but you will get some passwords cracked earlier, which is useful, for example, for penetration testing and demonstrations to management. Similarly, you may check all password hashes with a small wordlist, but only those that you can check faster (with "--salts=2") with a larger one. With large numbers of password hashes and/or with a highly non-uniform distribution of salts, it may be appropriate to use a threshold larger than 2 with "--salts" (sometimes even values as high as 1000 will do).

Note that the default wordlist rules include ":" (a no-op - try words as they are in the list) on the first line. If you already ran through a wordlist without using rules, and then decided to also try the same wordlist with rules, you'd better comment this line out.

6. The most powerful cracking mode in John is called "incremental" (not a proper name, but kept for historical reasons). You can simply run:

	john --incremental mypasswd

or:

	john -i mypasswd

This will use the default "incremental" mode parameters, which are defined in the configuration file's section named either [Incremental:ASCII] (for most hash types) or [Incremental:LM_ASCII] (for Windows LM hashes). By default, the [Incremental:ASCII] parameters are set to use the full printable ASCII character set (95 characters) and to try all possible password lengths from 0 to 13 (if the current hash type has a lower maximum password length, incremental mode's length limit is reduced accordingly). [Incremental:LM_ASCII] is similar, except that it takes advantage of LM hashes being case-insensitive and of their halves being limited to 7 characters each.

In some cases it is faster to use some other pre-defined incremental mode parameters and only crack simpler passwords, from a limited character set. The following command will try 10 different characters only, passwords from "0" to "99999999999999999999" (in an optimal order):

	john -i=digits mypasswd

Of course, you can use most of the additional features demonstrated above for wordlist mode with "incremental" mode as well. For example, on a large-scale penetration test, you may have John crack only root (UID 0) accounts in a set of password files:

	john -i -u=0 *.pwd

7. If you've got a password file for which you already have a lot of passwords cracked or obtained by other means, and the passwords are unusual, then you may want to generate a new charset file, based on character frequencies from that password file only:

	john --make-charset=custom.chr mypasswd

Then use that new file with "incremental" mode.

If you've got many password files from a particular country, organization, etc., it might be useful to use all of them for the charset file that you then use to crack even more passwords from these files or from some other password files from the same place:

	john --make-charset=custom.chr passwd1 passwd2
	[ Configure your custom "incremental" mode now. See below. ]
	john -i=custom passwd3

You can use some pre-defined or custom word filters when generating the charset file to have John consider some simpler passwords only:

	john --make-charset=my_alpha.chr --external=filter_alpha mypasswd

If your "pot file" got large enough (or if you don't have any charset files at all), you might want to use it to generate a new set of main charset files:

	makechr

where "makechr" is a script that invokes "john --make-charset=..." with varying filenames, for all of the external mode word filters defined in the configuration file. In this example, John will overwrite the charset files with new ones that are based on your entire $JOHN/john.pot (John uses the entire "pot file" if you don't specify any password files).

8. Finally, you might want to e-mail all users with weak passwords to tell them to change their passwords. (This is not always a good idea, though, since lots of people do not check their e-mail or ignore such messages, and the messages can be a hint for crackers.) Edit the "mailer" script supplied with John: the message it sends and possibly the mail command (especially if the password file is from a different machine). Then run:

	mailer mypasswd

Reference:

[1] https://www.openwall.com/john/doc/EXAMPLES.shtml

Read More