[EXT] New CWE proposed - Single Perspective Validation

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[EXT] New CWE proposed - Single Perspective Validation

Kurt Seifried
I would like to propose a new CWE: "Single Perspective Validation"

Please add any comments to the original at:


CWE - Single Perspective Validation


DRAFT Kurt Seifried [hidden email] 2020-04-03


Please feel free to leave comments and suggestions.


Description


For systems that need to retrieve a piece of data over an unencrypted/unauthenticated channel (e.g. a DNS lookup of a validation record) there is a significant weakness if the system only checks once from a single location for this data rather than checking multiple times from distributed locations. 


Extended Description


Many systems need to fetch external data to provide information to make a decision for e.g. IAM, to validate the existence of a piece of data and it’s value and so on. While many transactions to get a piece of such data are done over an encrypted and authenticated channel (e.g. a TLS connection to a remote database with authentication) many operations do not support encryption or authentication, for example viewing a DNS record to see if it exists and what the value is. For systems that need to remotely view a piece of data anonymously there exists a weakness due to the fact they only check once, this allows a man-in-the-middle attack to be successful more often than it should be. The good news is that the solution to this problem is relatively simple: check the value of the data from multiple perspectives, e.g. when doing a DNS lookup check from multiple sources that are widely distributed (making the man-in-the-middle attack much harder, or requiring them to effectively control the end resource, in which case this attack mechanism is no longer necessary). 


Relationships




Modes of Introduction


This flaw could be introduced during the design of the application or misconfiguration at run time by only specifying a single point of validation. This mode could also be introduced by intentionally failing all but one of the devices used to retrieve the data or by failing the devices that validate the data.


Phase

Architecture and Design

Implementation


Applicable Platforms


This is a language-independent 


Common Consequences


Scope / Impact

Integrity: an attacker that may be able to execute a single Man-in-the-Middle attack can subvert a check of an external oracle (e.g. the ACME protocol check for a file on a website) and thus inject an arbitrary reply to the single perspective request to the external oracle. 


Demonstrative Examples


Example 1

https://letsencrypt.org/2020/02/19/multi-perspective-validation.html


Observed Examples


DNS based man in the middle attacks are well known.

The DeFi “flash loan” attack that relied on manipulation of market pricing and the oracle only check the latest value https://www.coindesk.com/the-defi-flash-loan-attack-that-changed-everything


Memberships


Taxonomy Events



Related Attack Patterns



References

https://letsencrypt.org/2020/02/19/multi-perspective-validation.html

https://mailarchive.ietf.org/arch/msg/acme/s6Q5PdJP48LEUwgzrVuw_XPKCsM/


Content History

N/A




--
Kurt Seifried
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [EXT] New CWE proposed - Single Perspective Validation

Pascal Meunier
Kurt,

This reads like issue + mitigation all in one, but I think other mitigations are possible.
 I don't think we want to prescribe only one mitigation as acceptable.  Can the mitigation
be more separated and isolated from the description of the issue?  

Regards,
Pascal

On Wed, 2020-04-15 at 08:17 -0600, Kurt Seifried wrote:

> I would like to propose a new CWE: "Single Perspective Validation"
>
> Please add any comments to the original at:
>
> https://docs.google.com/document/d/1ntVHuprosF15UdDU7EOjm6Kfq2NXB-IATuhFP0a7NZY/edit
>
> CWE - Single Perspective Validation
>
> DRAFT Kurt Seifried [hidden email] 2020-04-03
>
> Please feel free to leave comments and suggestions.
>
> Description
>
> For systems that need to retrieve a piece of data over an
> unencrypted/unauthenticated channel (e.g. a DNS lookup of a validation
> record) there is a significant weakness if the system only checks once from
> a single location for this data rather than checking multiple times from
> distributed locations.
>
> Extended Description
>
> Many systems need to fetch external data to provide information to make a
> decision for e.g. IAM, to validate the existence of a piece of data and
> it’s value and so on. While many transactions to get a piece of such data
> are done over an encrypted and authenticated channel (e.g. a TLS connection
> to a remote database with authentication) many operations do not support
> encryption or authentication, for example viewing a DNS record to see if it
> exists and what the value is. For systems that need to remotely view a
> piece of data anonymously there exists a weakness due to the fact they only
> check once, this allows a man-in-the-middle attack to be successful more
> often than it should be. The good news is that the solution to this problem
> is relatively simple: check the value of the data from multiple
> perspectives, e.g. when doing a DNS lookup check from multiple sources that
> are widely distributed (making the man-in-the-middle attack much harder, or
> requiring them to effectively control the end resource, in which case this
> attack mechanism is no longer necessary).
>
> Relationships
>
>
>
> Modes of Introduction
>
> This flaw could be introduced during the design of the application or
> misconfiguration at run time by only specifying a single point of
> validation. This mode could also be introduced by intentionally failing all
> but one of the devices used to retrieve the data or by failing the devices
> that validate the data.
>
> Phase
>
> Architecture and Design
>
> Implementation
>
> Applicable Platforms
>
> This is a language-independent
>
> Common Consequences
>
> Scope / Impact
>
> Integrity: an attacker that may be able to execute a single
> Man-in-the-Middle attack can subvert a check of an external oracle (e.g.
> the ACME protocol check for a file on a website) and thus inject an
> arbitrary reply to the single perspective request to the external oracle.
>
> Demonstrative Examples
>
> Example 1
>
> https://letsencrypt.org/2020/02/19/multi-perspective-validation.html
>
> Observed Examples
>
> DNS based man in the middle attacks are well known.
>
> The DeFi “flash loan” attack that relied on manipulation of market pricing
> and the oracle only check the latest value
> https://www.coindesk.com/the-defi-flash-loan-attack-that-changed-everything
>
> Memberships
>
> Taxonomy Events
>
>
> Related Attack Patterns
>
>
> References
>
> https://letsencrypt.org/2020/02/19/multi-perspective-validation.html
>
> https://mailarchive.ietf.org/arch/msg/acme/s6Q5PdJP48LEUwgzrVuw_XPKCsM/
>
> Content History
>
> N/A
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [EXT] New CWE proposed - Single Perspective Validation

Kurt Seifried
There are of course numerous possible mitigations, I just went with the most common one that doesn't involve any work from the source of the data (e.g. no need to sign/authenticate/etc.). 

I'm not familiar with exactly how to write a CWE, is this a standard part of it (e.g. list as many mitigations as possible?), if so yes I can update this submission.

On Mon, Apr 27, 2020 at 12:42 PM Pascal Meunier <[hidden email]> wrote:
Kurt,

This reads like issue + mitigation all in one, but I think other mitigations are possible.
 I don't think we want to prescribe only one mitigation as acceptable.  Can the mitigation
be more separated and isolated from the description of the issue? 

Regards,
Pascal

On Wed, 2020-04-15 at 08:17 -0600, Kurt Seifried wrote:
> I would like to propose a new CWE: "Single Perspective Validation"
>
> Please add any comments to the original at:
>
> https://docs.google.com/document/d/1ntVHuprosF15UdDU7EOjm6Kfq2NXB-IATuhFP0a7NZY/edit
>
> CWE - Single Perspective Validation
>
> DRAFT Kurt Seifried [hidden email] 2020-04-03
>
> Please feel free to leave comments and suggestions.
>
> Description
>
> For systems that need to retrieve a piece of data over an
> unencrypted/unauthenticated channel (e.g. a DNS lookup of a validation
> record) there is a significant weakness if the system only checks once from
> a single location for this data rather than checking multiple times from
> distributed locations.
>
> Extended Description
>
> Many systems need to fetch external data to provide information to make a
> decision for e.g. IAM, to validate the existence of a piece of data and
> it’s value and so on. While many transactions to get a piece of such data
> are done over an encrypted and authenticated channel (e.g. a TLS connection
> to a remote database with authentication) many operations do not support
> encryption or authentication, for example viewing a DNS record to see if it
> exists and what the value is. For systems that need to remotely view a
> piece of data anonymously there exists a weakness due to the fact they only
> check once, this allows a man-in-the-middle attack to be successful more
> often than it should be. The good news is that the solution to this problem
> is relatively simple: check the value of the data from multiple
> perspectives, e.g. when doing a DNS lookup check from multiple sources that
> are widely distributed (making the man-in-the-middle attack much harder, or
> requiring them to effectively control the end resource, in which case this
> attack mechanism is no longer necessary).
>
> Relationships
>
>
>
> Modes of Introduction
>
> This flaw could be introduced during the design of the application or
> misconfiguration at run time by only specifying a single point of
> validation. This mode could also be introduced by intentionally failing all
> but one of the devices used to retrieve the data or by failing the devices
> that validate the data.
>
> Phase
>
> Architecture and Design
>
> Implementation
>
> Applicable Platforms
>
> This is a language-independent
>
> Common Consequences
>
> Scope / Impact
>
> Integrity: an attacker that may be able to execute a single
> Man-in-the-Middle attack can subvert a check of an external oracle (e.g.
> the ACME protocol check for a file on a website) and thus inject an
> arbitrary reply to the single perspective request to the external oracle.
>
> Demonstrative Examples
>
> Example 1
>
> https://letsencrypt.org/2020/02/19/multi-perspective-validation.html
>
> Observed Examples
>
> DNS based man in the middle attacks are well known.
>
> The DeFi “flash loan” attack that relied on manipulation of market pricing
> and the oracle only check the latest value
> https://www.coindesk.com/the-defi-flash-loan-attack-that-changed-everything
>
> Memberships
>
> Taxonomy Events
>
>
> Related Attack Patterns
>
>
> References
>
> https://letsencrypt.org/2020/02/19/multi-perspective-validation.html
>
> https://mailarchive.ietf.org/arch/msg/acme/s6Q5PdJP48LEUwgzrVuw_XPKCsM/
>
> Content History
>
> N/A
>
>
>


--
Kurt Seifried
[hidden email]