ITPro.TV: CompTIA Security+ (SY0-601)

CompTIA Security+ Exam Cram

It actually took me a couple of days to work through chapter 24 of the Exam Cram, “Authentication and Authorization Solutions”. Lots of little details here.

Authentication

AUTHENTICATION MANAGEMENT: The management of user credentials across the entire user lifecycle.

Unencrypted Plaintext Credentials

Wait, wut?!?

In a Windows environment, failed logins record the plaintext password in the Security log.

I guess people must forget their usernames with relative frequency, as Exam Cram is suggesting that a failed login attempt followed by a successful one has a high probability of revealing the user’s password (at least in smaller/less busy environments).

Filesystem Permissions

Exam Cram notes that the Security+ test’s main concern with insecure permissions is the violation of the principle of least access.

When enabling access audit logs:

The Windows gpresult utility calculates the effective group policy of a user or computer (essentially calculating the “sum” of the active group policies). The accesschk tool is similar, which shows the effective permissions a user or computer has to a particular object (these permissions are determined in part by the applied group policies).

Windows permissions for folders:

Windows permissions for files:

Windows “advanced permissions” are just bundles of the above.

I suspect that there must be a bit more to advanced permissions than this, as otherwise there’s a lot of duplication here (either that, or Windows is supporting a lot of legacy permission bundles, which also wouldn’t surprise me). Also, all of these advanced permissions include the “full control” permission, which would seem to make them all equivalent to… “full control”?

When a user is part of two groups with different permissions to an object, the allow permission will only override inherited deny permissions (explicitly set deny permissions cannot be overridden; remember that Windows access handling is default-deny).

Okay, learned something new about Linux permissions I wasn’t expecting: If a user has write access to a directory, then they can write to any file they have at least read access to (!!!).

Access Violations

The Windows “Microsoft Operations Manager” (MOM) includes an “Audit Collection Service” (ACS) that collects various audit events into a single database. There are two preconfigured reports:

Authentication Protocols

PASSWORD AUTHENTICATION PROTOCOL (PAP): Username and password are sent to the server in plaintext. That’s it. Was used for PPP connections.

CHALLENGE HANDSHAKE AUTHENTICATION PROTOCOL (CHAP): Is a (slightly) more secure authentication protocol, again used in PPP connections. In a CHAP authentication handshake, the server (authenticator) sends the client a (random?) challenge to the client. The client then combined this with the user password and hashes the result (typically with MD5). The server can then compare this using the same process to determine is the client knows the correct user password. Reauthentication is randomly re-requested with new challenges. Requires both the client and server to know the user’s password in plaintext.

MICROSOFT CHAP (MS-CHAP): Is a Microsoft variant of CHAP. Both Exam Cram and Wikipedia are a bit light on details, but authentication (at least in MS-CHAPv2) is bidirectional and the algorithm appears to use NTLM hashes encrypted with DES. Both the v1 and v2 versions of this algorithm are considered broken, but v1 is very broken. The security of MS-CHAP can be improved by using the “extensible authentication protocol” (EAP) or the “protected extensible authentication protocol” (PEAP); the latter of these actually fires up an encrypted tunnel between the client and server before exchanging the authentication handshake.

802.1X

802.1X is an IEEE standard for port-based access control on a network. It works by encapsulating EAP with some IEEE network protocol, and relies on a dedicated authentication server rather than having the system the client is connecting to handle the authentication.

AAA Protocols and Services

Recall that “AAA” stands for “authentication, authorization, and accounting”.

RADIUS stands for “Remote Authentication Dial-In User Service”, which should give you a sense of when it was designed. RADIUS works primarily over UDP (though TCP implementations are possible); users present their credentials directly to a resource, which then passes them to the RADIUS server (passwords are transformed using MD5 + a salt shared by the resource and RADIUS server). (Note that Exam Cram implies that credentials are presented directly to the RADIUS server, but all of the other resources I can find indicate that this is not the case.) The RADIUS server may authenticate and authorize the user immediately, reject them immediately, or request an additional challenge (which will be handled directly by the RADIUS server, and not the requesting resource). Once the user is authenticated and authorized, the resource may send periodic accounting messages to the RADIUS server to indicate the user’s usage.

RADIUS servers can forward credentials to other servers for verification. The users that a given RADIUS server is responsible for are its “realm”, and the realm of a login request can be prepended to the username using \ (“prefix notation”, which then looks like AD domains) or appended using @ (“postfix notation”, which looks like an email address). Both notations can be combined to allow for user accounts in two realms.

TACACS+ is the “Terminal Access Controller Access Control System Plus” is a Cisco standard dating from 1993. It uses TCP 49; while the design details differ (in particular, TACACS+ completely encrypts user information, while RADIUS only protects the password), the general authentication/authorization/auditing flow is similar to RADIUS.

TACACS+ cleanly separates out the authentication and authorization stages, which allows alternate authentication mechanisms to be more easily used than RADIUS (Exam Cram implies that authentication could be handled entirely by the resource). Because of this, it can also be used to authorize actions at a much finer level - typically individual commands, rather than RADIUS’s coarser resource-based approach.

Federated Services

Federated services typically use token-based authentication, where the user authenticates with with a central server once and then receives a token that can provide access to further resources. Tokens can be scoped in time, space (which resources they’re valid for), or both.

SAML

SAML (“Security Assertion Markup Language”) provides authentication (user identity), attribute (user metadata), and authorization (user permissions) attestation in a single XML bundle. SAML terminology:

SAML flow:

Note that (single) sign-on is initiated by the service provider; the IdP is only used for authentication.

SAML authentication responses assert the validity of a user’s identity, rather than confirming successful authentication directly. SAML requests need to be scoped in time to prevent replay attacks.

Note that both OAuth 2.0 and OpenID Connect (below) can use SAML for user authentication/authorization.

OAuth 2.0

OAuth (“Open Authorization”) is primarily used for API-level authorization. Terminology:

While SAML is about authorizing user access to a particular resource, OAuth is about authorizing two systems to talk to each other on behalf of a user.

Types of “grants” in OAuth 2.0:

OAuth 2.0 uses JSON rather than SAML’s XML, and is overall a simpler protocol. Partly, this is due to the fact that OAuth only deals with authorization; authentication is handled by having the user log into the provider before issuing a token. In order to prevent session-based attacks, if a user isn’t already logged into the provider, they should be logged out after authorization is complete.

OpenID Connect

Besides an explicit login, authentication can also be layered on to OAuth 2.0 using OpenID Connect, which extends the OAuth 2.0 authorization process to include an authentication step. Generic OpenID Connect flow:

There are three specific variants of the generic OpenID Connect flow:

OpenID Connect ID tokens are JSON web tokens; the payload of these tokens contains assertions about the user’s authentication (and can also include additional user information, though this is now discouraged), the integrity of which is guaranteed by a cryptographic signature. They are used only to verify a successful login (preventing a situation where a local attacker on a mobile device can inject false login information), and as such often expire after a very short time.

Access tokens in OpenID Connect are exactly the same as the API tokens issued in OAuth 2.0. To prevent (local) interception attacks, both OpenID Connect and OAuth 2.0 clients can layer in a “code verification” flow (PKCE, “Proof Key for Code Exchange”), in which the client sends the server a hashed (per-client/connection) secret during the initial authentication/authorization, and then subsequently sends the original code when using the returned authorization code. OpenID Connect + PKCE tightly binds the returned ID and access tokens to a particular client instance, but is only applicable to the “authorization code” and “hybrid” flows.

In short, in OpenID Connect the access token provides long lived or renewable API authorization while the ID token provide short-lived proof of authentication. These two tokens together are equivalent to a SAML assertion, but can be handled without having to deal with XML, SOAP, etc.

Shibboleth

Shibboleth is an open source federated SAML implementation. It layers on the concept of a (optional) “discovery service” that is used to determine a user’s IdP across organizational boundaries. Apparently tricky to configure.

Kerberos

Kerberos uses symmetric keys for protocol encryption. Kerberos uses TCP/UDP 88, though UDP is preferred except for large tickets; UDP (?) 749 is used for administrative access.

Kerberos differs from protocols previously discussed in that the client initially sends authentication information directly to the KDC (“key distribution center”) server, rather than working through the actual resource server. A quick sketch of the Kerberos authentication process:

A more detailed sketch is provided in my notes in “A Hacker’s Notes”.

The idea with Kerberos is to have a short enough ticket validity lifespan that cryptographic attacks are infeasible, and the entire process doesn’t require any direct exchange of passwords. The extensive use of timestamps effectively prevent replay attacks (Exam Cram notes the importance of time synchronization between all systems in an environment using Kerberos).

Unfortunately, the most common Kerberos implementation is Active Directory, which uses NTLM hashes as its secrets and allows for stored “pre-autheticated” tickets that bypass the KDC. This allows for serious side-channel attacks. Kerberos 5 tries to mitigate these attacks by having client and service authenticate each other with challenge codes (“mutual authentication”), but this only prevents on-the-wire MITM attacks, not attacks that harvest tickets from client machine directly (like Rubeus and Mimikatz).

Access Control

ACCESS CONTROL: The process by which resources are made available only to those entities that should have access (and access is denied to all others).

Types of access controls:

If I read all of this right, ABAC is a way of implementing access control, rather than a type of access control.

Note that the “Trusted Computer System Evaluation Criteria” (TCSEC) specification (a.k.a., the “Orange Book”) only defines the use of MAC and DAC.

Privileged Access Management

PAM systems are access control systems with the following properties:

PAM solutions are primarily concerned with machine, application, and administrative accounts.