Baseline for Ed 2 of tr 24772

7.14 Authentication Logic Error [XZO]

7.14.1 Description of application vulnerability

The software does not properly ensure that the user has proven their identity.

7.14.2 Cross reference

CWE:

287. Improper Authentication

288. Authentication Bypass by Alternate Path/Channel
289. Authentication Bypass by Alternate Name

290. Authentication Bypass by Spoofing

294. Authentication Bypass by Capture-replay

301. Reflection Attack in an Authentication Protocol

302. Authentication Bypass by Assumed-Immutable Data

303. Improper Implementation of Authentication Algorithm

305. Authentication Bypass by Primary Weakness

7.14.3 Mechanism of failure

There are many ways that an attacker can potentially bypass the validation of a user. Some of the ways are means of impersonating a legitimate user while others are means of bypassing the authentication mechanisms that are in place. In either case, a user who should not have access to the software system gains access.

Authentication bypass by alternate path or channel occurs when a product requires authentication, but the product has an alternate path or channel that does not require authentication. Note that this is often seen in web applications that assume that access to a particular CGI (Common Gateway Interface) program can only be obtained through a "front" screen, but this problem is not just in web applications.

Authentication bypass by alternate name occurs when the software performs authentication based on the name of the resource being accessed, but there are multiple names for the resource, and not all names are checked.

Authentication bypass by capture-replay occurs when it is possible for a malicious user to sniff network traffic and bypass authentication by replaying it to the server in question to the same effect as the original message (or with minor changes). Messages sent with a capture-relay attack allow access to resources that are not otherwise accessible without proper authentication.  Capture-replay attacks are common and can be difficult to defeat without cryptography. They are a subset of network injection attacks that rely on listening in on previously sent valid commands, then changing them slightly if necessary and resending the same commands to the server. Since any attacker who can listen to traffic can see sequence numbers, it is necessary to sign messages with some kind of cryptography to ensure that sequence numbers are not simply doctored along with content.

Reflection attacks capitalize on mutual authentication schemes to trick the target into revealing the secret shared between it and another valid user. In a basic mutual-authentication scheme, a secret is known to both a valid user and the server; this allows them to authenticate. In order that they may verify this shared secret without sending it plainly over the wire, they utilize a Diffie-Hellman-style scheme in which they each pick a value, then request the hash of that value as keyed by the shared secret. In a reflection attack, the attacker claims to be a valid user and requests the hash of a random value from the server. When the server returns this value and requests its own value to be hashed, the attacker opens another connection to the server. This time, the hash requested by the attacker is the value that the server requested in the first connection. When the server returns this hashed value, it is used in the first connection, authenticating the attacker successfully as the impersonated valid user.

Authentication bypass by assumed-immutable data occurs when the authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker, for example, if a web application relies on a cookie "Authenticated=1".

Authentication logic error occurs when the authentication techniques do not follow the algorithms that define them exactly and so authentication can be jeopardized. For instance, a malformed or improper implementation of an algorithm can weaken the authorization technique.

An authentication bypass by primary weakness occurs when the authentication algorithm is sound, but the implemented mechanism can be bypassed as the result of a separate weakness that is primary to the authentication error.

7.14.4 Avoiding the vulnerability or mitigating its effects

Software developers can avoid the vulnerability or mitigate its ill effects in the following ways:

• 
  Funnel all access through a single choke point to simplify how users can access a resource.  For every access, perform a check to determine if the user has permissions to access the resource.  Avoid making decisions based on names of resources (for example, files) if those resources can have alternate names.
  
• 
  Canonicalize the name to match that of the file system's representation of the name. This can sometimes be achieved with an available API (for example, in Win32 the GetFullPathName function).
  
• 
  Utilize some sequence or time stamping functionality along with a checksum that takes this into account to ensure that messages can be parsed only once.
  
• 
  Use different keys for the initiator and responder or of a different type of challenge for the initiator and responder.
  

7.15 Hard-coded Password [XYP]

7.15.1 Description of application vulnerability

Hard coded passwords may compromise system security in a way that cannot be easily remedied. It is never a good idea to hardcode a password. Not only does hard coding a password allow all of the project's developers to view the password, it also makes fixing the problem extremely difficult. Once the code is in production, the password cannot be changed without patching the software. If the account protected by the password is compromised, the owners of the system will be forced to choose between security and availability.

7.15.2 Cross reference

CWE:

259. Hard-Coded Password

798. Use of Hard-coded Credentials

7.15.3 Mechanism of failure

The use of a hard-coded password has many negative implications – the most significant of these being a failure of authentication measures under certain circumstances. On many systems, a default administration account exists which is set to a simple default password that is hard-coded into the program or device. This hard-coded password is the same for each device or system of this type and often is not changed or disabled by end users.  If a malicious user comes across a device of this kind, it is a simple matter of looking up the default password (which is likely freely available and public on the Internet) and logging in with complete access. In systems that authenticate with a back-end service, hard-coded passwords within closed source or drop-in solution systems require that the back-end service use a password that can be easily discovered. Client-side systems with hard-coded passwords present even more of a threat, since the extraction of a password from a binary is exceedingly simple. If hard-coded passwords are used, it is almost certain that unauthorized users will gain access through the account in question.

7.15.4 Avoiding the vulnerability or mitigating its effects

Software developers can avoid the vulnerability or mitigate its ill effects in the following ways:

• 
  Rather than hard code a default username and password for first time logins, utilize a "first login" mode that requires the user to enter a unique strong password.
  
• 
  For front-end to back-end connections, there are three solutions that may be used.
  
  1. 
     Use of generated passwords that are changed automatically and must be entered at given time intervals by a system administrator. These passwords will be held in memory and only be valid for the time intervals.
     
  2. 
     The passwords used should be limited at the back end to only performing actions for the front end, as opposed to having full access.
     
  3. 
     The messages sent should be tagged and checksummed with time sensitive values so as to prevent replay style attacks