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
> 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
>
>
>
Locked
