[EXT] New CWE proposed - Single Perspective Validation
Locked
[EXT] New CWE proposed - Single Perspective Validation
 
|
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] |
Re: [EXT] New CWE proposed - Single Perspective Validation
|
|
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 > > > |
Re: [EXT] New CWE proposed - Single Perspective Validation
|
|
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, Kurt Seifried
[hidden email] |
| Free forum by Nabble | Edit this page |