All posts by rocco

CWE

CWE-352 – Cross-Site Request Forgery (CSRF)

Read Time:3 Minute, 7 Second

Description

The web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request.

When a web server is designed to receive a request from a client without any mechanism for verifying that it was intentionally sent, then it might be possible for an attacker to trick a client into making an unintentional request to the web server which will be treated as an authentic request. This can be done via a URL, image load, XMLHttpRequest, etc. and can result in exposure of data or unintended code execution.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: Medium

 

Related Weaknesses

CWE-345
CWE-345
CWE-346
CWE-441
CWE-642
CWE-613

 

Consequences

Confidentiality, Integrity, Availability, Non-Repudiation, Access Control: Gain Privileges or Assume Identity, Bypass Protection Mechanism, Read Application Data, Modify Application Data, DoS: Crash, Exit, or Restart

The consequences will vary depending on the nature of the functionality that is vulnerable to CSRF. An attacker could effectively perform any operations as the victim. If the victim is an administrator or privileged user, the consequences may include obtaining complete control over the web application – deleting or stealing data, uninstalling the product, or using it to launch other attacks against all of the product’s users. Because the attacker has the identity of the victim, the scope of CSRF is limited only by the victim’s privileges.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Phase: Implementation

Description: 

Ensure that the application is free of cross-site scripting issues (CWE-79), because most CSRF defenses can be bypassed using attacker-controlled script.

Phase: Architecture and Design

Description: 

Generate a unique nonce for each form, place the nonce into the form, and verify the nonce upon receipt of the form. Be sure that the nonce is not predictable (CWE-330). [REF-332]

Note that this can be bypassed using XSS (CWE-79).

Phase: Architecture and Design

Description: 

Identify especially dangerous operations. When the user performs a dangerous operation, send a separate confirmation request to ensure that the user intended to perform that operation.

Note that this can be bypassed using XSS (CWE-79).

Phase: Architecture and Design

Description: 

Note that this can probably be bypassed using XSS (CWE-79), or when using web technologies that enable the attacker to read raw headers from HTTP requests.

Phase: Architecture and Design

Description: 

Do not use the GET method for any request that triggers a state change.

Phase: Implementation

Description: 

Check the HTTP Referer header to see if the request originated from an expected page. This could break legitimate functionality, because users or proxies may have disabled sending the Referer for privacy reasons.

Note that this can be bypassed using XSS (CWE-79). An attacker could use XSS to generate a spoofed Referer, or to generate a malicious request from a page whose Referer would be allowed.

CVE References

  • CVE-2004-1967
    • Arbitrary code execution by specifying the code in a crafted img tag or URL
  • CVE-2004-1842
    • Gain administrative privileges via a URL in an img tag
  • CVE-2005-1947
    • Delete a victim’s information via a URL or an img tag
  • CVE-2005-2059
    • Change another user’s settings via a URL or an img tag
  • CVE-2005-1674
    • Perform actions as administrator via a URL or an img tag
  • CVE-2009-3022
    • CMS allows modification of configuration via CSRF attack against the administrator
  • CVE-2009-3759
    • web interface allows password changes or stopping a virtual machine via CSRF
CWE

CWE-353 – Missing Support for Integrity Check

Read Time:1 Minute, 15 Second

Description

The software uses a transmission protocol that does not include a mechanism for verifying the integrity of the data during transmission, such as a checksum.

If integrity check values or “checksums” are omitted from a protocol, there is no way of determining if data has been corrupted in transmission. The lack of checksum functionality in a protocol removes the first application-level check of data that can be used. The end-to-end philosophy of checks states that integrity checks should be performed at the lowest level that they can be completely implemented. Excluding further sanity checks and input validation performed by applications, the protocol’s checksum is the most important level of checksum, since it can be performed more completely than at any previous level and takes into account entire messages, as opposed to single packets.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: Medium

 

Related Weaknesses

CWE-345
CWE-354

 

Consequences

Integrity, Other: Other

Data that is parsed and used may be corrupted.

Non-Repudiation, Other: Hide Activities, Other

Without a checksum it is impossible to determine if any changes have been made to the data after it was sent.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Add an appropriately sized checksum to the protocol, ensuring that data received may be simply validated before it is parsed and used.

Phase: Implementation

Description: 

Ensure that the checksums present in the protocol design are properly implemented and added to each message before it is sent.

CVE References

CWE

CWE-354 – Improper Validation of Integrity Check Value

Read Time:1 Minute, 9 Second

Description

The software does not validate or incorrectly validates the integrity check values or “checksums” of a message. This may prevent it from detecting if the data has been modified or corrupted in transmission.

Improper validation of checksums before use results in an unnecessary risk that can easily be mitigated. The protocol specification describes the algorithm used for calculating the checksum. It is then a simple matter of implementing the calculation and verifying that the calculated checksum and the received checksum match. Improper verification of the calculated checksum and the received checksum can lead to far greater consequences.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: Medium

 

Related Weaknesses

CWE-345
CWE-345
CWE-754
CWE-353

 

Consequences

Integrity, Other: Modify Application Data, Other

Integrity checks usually use a secret key that helps authenticate the data origin. Skipping integrity checking generally opens up the possibility that new data from an invalid source can be injected.

Integrity, Other: Other

Data that is parsed and used may be corrupted.

Non-Repudiation, Other: Hide Activities, Other

Without a checksum check, it is impossible to determine if any changes have been made to the data after it was sent.

 

Potential Mitigations

Phase: Implementation

Description: 

Ensure that the checksums present in messages are properly checked in accordance with the protocol specification before they are parsed and used.

CVE References

CWE

CWE-318 – Cleartext Storage of Sensitive Information in Executable

Read Time:36 Second

Description

The application stores sensitive information in cleartext in an executable.

Attackers can reverse engineer binary code to obtain secret data. This is especially easy when the cleartext is plain ASCII. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-312

 

Consequences

Confidentiality: Read Application Data

 

Potential Mitigations

CVE References

  • CVE-2005-1794
    • Product stores RSA private key in a DLL and uses it to sign a certificate, allowing spoofing of servers and Adversary-in-the-Middle (AITM) attacks.
  • CVE-2001-1527
    • administration passwords in cleartext in executable
CWE

CWE-319 – Cleartext Transmission of Sensitive Information

Read Time:1 Minute, 49 Second

Description

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

Many communication channels can be “sniffed” by attackers during data transmission. For example, network traffic can often be sniffed by any attacker who has access to a network interface. This significantly lowers the difficulty of exploitation by attackers.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-311
CWE-311

 

Consequences

Integrity, Confidentiality: Read Application Data, Modify Files or Directories

Anyone can read the information by gaining access to the channel being used for communication.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Encrypt the data with a reliable encryption scheme before transmitting.

Phase: Implementation

Description: 

When using web applications with SSL, use SSL for the entire session from login to logout, not just for the initial login page.

Phase: Testing

Description: 

Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Phase: Operation

Description: 

Configure servers to use encrypted channels for communication, which may include SSL or other secure protocols.

CVE References

  • CVE-2008-4122
    • Chain: Use of HTTPS cookie without “secure” flag causes it to be transmitted across unencrypted HTTP.
  • CVE-2008-3289
    • Product sends password hash in cleartext in violation of intended policy.
  • CVE-2008-4390
    • Remote management feature sends sensitive information including passwords in cleartext.
  • CVE-2007-5626
    • Backup routine sends password in cleartext in email.
  • CVE-2004-1852
    • Product transmits Blowfish encryption key in cleartext.
  • CVE-2008-0374
    • Printer sends configuration information, including administrative password, in cleartext.
  • CVE-2007-4961
    • Chain: cleartext transmission of the MD5 hash of password enables attacks against a server that is susceptible to replay (CWE-294).
  • CVE-2007-4786
    • Product sends passwords in cleartext to a log server.
  • CVE-2005-3140
    • Product sends file with cleartext passwords in e-mail message intended for diagnostic purposes.
CWE

CWE-32 – Path Traversal: ‘…’ (Triple Dot)

Read Time:1 Minute, 3 Second

Description

The software uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize ‘…’ (triple dot) sequences that can resolve to a location that is outside of that directory.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-23

 

Consequences

Confidentiality, Integrity: Read Files or Directories, Modify Files or Directories

 

Potential Mitigations

Phase: Implementation

Effectiveness: High

Description: 

Phase: Implementation

Description: 

Inputs should be decoded and canonicalized to the application’s current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.

CVE References

  • CVE-2001-0480
    • read of arbitrary files and directories using GET or CD with “…” in Windows-based FTP server.
  • CVE-2002-0288
    • read files using “.” and Unicode-encoded “/” or “” characters in the URL.
CWE

CWE-321 – Use of Hard-coded Cryptographic Key

Read Time:27 Second

Description

The use of a hard-coded cryptographic key significantly increases the possibility that encrypted data may be recovered.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-798
CWE-798
CWE-798

 

Consequences

Access Control: Bypass Protection Mechanism, Gain Privileges or Assume Identity

If hard-coded cryptographic keys are used, it is almost certain that malicious users will gain access through the account in question.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Prevention schemes mirror that of hard-coded password storage.

CVE References

CWE

CWE-322 – Key Exchange without Entity Authentication

Read Time:1 Minute, 9 Second

Description

The software performs a key exchange with an actor without verifying the identity of that actor.

Performing a key exchange will preserve the integrity of the information sent between two entities, but this will not guarantee that the entities are who they claim they are. This may enable an attacker to impersonate an actor by modifying traffic between the two entities. Typically, this involves a victim client that contacts a malicious server that is impersonating a trusted server. If the client skips authentication or ignores an authentication failure, the malicious server may request authentication information from the user. The malicious server can then use this authentication information to log in to the trusted server using the victim’s credentials, sniff traffic between the victim and trusted server, etc.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-923
CWE-295

 

Consequences

Access Control: Bypass Protection Mechanism

No authentication takes place in this process, bypassing an assumed protection of encryption.

Confidentiality: Read Application Data

The encrypted communication between a user and a trusted host may be subject to sniffing by any actor in the communication path.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Ensure that proper authentication is included in the system design.

Phase: Implementation

Description: 

Understand and properly implement all checks necessary to ensure the identity of entities involved in encrypted communications.

CVE References

CWE

CWE-323 – Reusing a Nonce, Key Pair in Encryption

Read Time:41 Second

Description

Nonces should be used for the present occasion and only once.

Nonces are often bundled with a key in a communication exchange to produce a new session key for each exchange.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-344

 

Consequences

Access Control: Bypass Protection Mechanism, Gain Privileges or Assume Identity

Potentially a replay attack, in which an attacker could send the same data twice, could be crafted if nonces are allowed to be reused. This could allow a user to send a message which masquerades as a valid message from a valid user.

 

Potential Mitigations

Phase: Implementation

Description: 

Refuse to reuse nonce values.

Phase: Implementation

Description: 

Use techniques such as requiring incrementing, time based and/or challenge response to assure uniqueness of nonces.

CVE References

CWE

CWE-324 – Use of a Key Past its Expiration Date

Read Time:54 Second

Description

The product uses a cryptographic key or password past its expiration date, which diminishes its safety significantly by increasing the timing window for cracking attacks against that key.

While the expiration of keys does not necessarily ensure that they are compromised, it is a significant concern that keys which remain in use for prolonged periods of time have a decreasing probability of integrity. For this reason, it is important to replace keys within a period of time proportional to their strength.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: Low

 

Related Weaknesses

CWE-672
CWE-298

 

Consequences

Access Control: Bypass Protection Mechanism, Gain Privileges or Assume Identity

The cryptographic key in question may be compromised, providing a malicious user with a method for authenticating as the victim.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Adequate consideration should be put in to the user interface in order to notify users previous to the key’s expiration, to explain the importance of new key generation and to walk users through the process as painlessly as possible.

CVE References