mike1813
commented
11 months ago Threats causing Loss of Service TW are CC.L.CSHSAC.1, CC.L.CSCCHuoSt.1 and CC.L.CSCCHuSt.1. All are restricted to direct channels to the untrustworthy service, but should apply to any channels.
- [x] Make Loss of Service TW affect indirect or direct channels in CC.L.CSHSAC.1, CC.L.CSCCHuoSt.1 and CC.L.CSCCHuSt.1.
Threats causing Service Impersonation are CC.AuS.CRoS.3, CC.AuS.CRoSG.3 and CC.AuS.CRoSI.3. All affect direct channels only (via a client path through the network), but the effect should also apply to any associated indirect channels. This is already the case for these threats.
Threats causing Loss of Anon User TW previously worked only for direct channels via transparent proxies, but they have now been replaced by threats representing network access to arbitrary services including transparent proxies, step-wise access via a proxy, and access to the indirect channel if the first and last direct channels are affected. See #64.
Threats causing Client Impersonation (Loss of Client Authenticity) are:
- CC.AuC.CACHcLSS.1 and CC.AuC.CACHLSS.2: represent access to the target service from a compromised or stolen client.
- CC.AuC.CCC-nS.1: represents anonymous access to a target service that fails to use any client authentication.
- CC.AuC.HumCCC-nS.3: represents a brute force attack such as credential stuffing to discover a weak password.
- CC.AuC.CCC-nS.3.2, CC.AuC.HuDFTCS.3 and CC.AuC.HuDSTCS.3: represent various methods for stealing a client password by directing the client (or redirecting their messages) to an imposter service.
- CC.AuC.CCC-nS.3.3: represents stealing a client password via snooping in the network.
- CC.AuC.HuiHCCC-nS.3.3, CC.AuC.HuiHrCCC-nS.3.3: represent stealing a client password by shouder-surfing.
- CC.AuC.DFrXSS.3, CC.AuC.DFsXSS.3, CC.AuC.DSrXSS.3 and CC.AuC.DSsXSS.3: represent cross-site scripting attacks to steal the client's session cookie/token, allowing the attacker to intrude on a legitimate client-service connection.
- CC.AuC.CCCSScS.1: represents authenticated access to a separate OIDC-style authentication service used by the target service.
Most of these threats use prohibited links that inhibit the threats unless the service authenticates the client. They don't apply to client-service connections via transparent proxies, so they only affect end-to-end connections, as required.
They also don't affect connections to services that rely on another service for client authentication, including redirection of the client to an OIDC-style authenticator, or forwarding of authentication requests by a transparent proxy to a back end service. In either case, authenticated access (Client TW) to the authenticating service causes Client Impersonation at the dependent service.
CC.AuC.CCCSScS.1 doesn't quite work to cause Client Impersonation in channels via transparent proxies, because there must be both a common client and a 'controls' relationship between the two services. The simplest solution is to remove the inferred 'controls' link (construction pattern CuPvnS+c) so CC.AuC.CCCSScS.1 no longer covers any connections via transparent proxies. This leaves a separate threat CC.AuC.CCCvCCS.1, also added in response to issue #64, to handle those.
- [x] Remove the inferred 'controls' link from construction pattern CuPvnS+c so CC.AuC.CCCSScS.1 does not make Client Authenticity in direct channels via transparent proxies dependent on Client TW in indirect end-to-end channels.
The other problem is with CC.AuC.CACHcLSS.1 and CC.AuC.CACHLSS.2, which are also restricted to channels where the service authenticates the client, and (since they require a client attack path) exclude indirect channels via transparent proxies. Evidently, client authenticity is meaningless if the client is such a proxy, so the first restriction is not a problem, although it does mean we will need some other way to represent the effect of a compromised proxy.
The second issue is more problematic. One solution is to link indirect client channels to client attack paths connected to direct channels to/from proxies. However, this would lead to duplicate threat paths from CC.AuA.CCAPNaS.1 or CC.AuA.OCAPNaS.1 via CC.AuA.CCCPCCcS.1 and CC.AuA.CCCv2CCS.1. The best solution seems to be new threats alongside CC.AuC.CACHcLSS.1 and CC.AuC.CACHLSS.2, to cover the case where the end-to-end connection is indirect.
- [x] Add new threats alongside CC.AuC.CACHcLSS.1 and CC.AuC.CACHLSS.2 leading to Client Impersonation in end-to-end connections. NOT DONE.
Threats causing Loss of Client TW are:
- CC.R.CCC-pS.1: added to address #64 represents authenticated access to a service by someone able to authenticate as the client (Client Authenticity) and send messages to the service (Anon User TW).
- CC.R.HuoStCCCS.1 or CC.R.HuStCCCS.1: insider attacks, which lead directly to Loss of Client TW (not via Client Impersonation) because there is no possibility of intruder detection after authentication (the attacker is a legitimate user).
- CC.R.CDBSC.4: query injection via a service which is a trusted client of a DB service, represented as Loss of Client TW in the channel to the DB service.
The first of these excludes channels from transparent proxies because Client Authenticity is meaningless in those cases, but this means there is no path from compromise of the transparent to Loss of Client TW in the direct channel from there towards the back-end service. To fix this, a new threat is needed.
- [x] Add a new threat similar to CC.AuC.CACHcLSS.1 leading to Loss of Client TW in a channel from a transparent proxy should the proxy be compromised, i.e., controlled by a malicious hacker.
Note that this new threat can lead to Loss of Client TW rather than Client Impersonation because a reverse proxy cannot have an interactive user, so there is no possibility that the intruder could be detected after authentication to the back-end service.
The two insider attacks also exclude channels where the service doesn't authenticate the client. The query injection attack could affect direct or indirect channels, but normally it will be an end-to-end channel because a DB service wouldn't normally act as a transparent reverse proxy. We may want to introduce a modelling error threat to detect where it is used in that way (elevating this assumption to become a domain model restriction). See also
Then all threats caused by Client Authenticity or TW, Service Authenticity or TW, and Client-Service Accessibility must be made consistent with the above.
As discussed in #67, where threats to data flows are caused by issues in Client Channels (client-service relationships) there is a case for restricting the threat so they are only caused by Client Channels representing direct connections (not via transparent proxies) or end-to-end connections (not to/from a transparent proxy).
Loss of Service TW is caused by a malicious service manager/operator or a compromised (hacked) service. In the former case, it is possible for Loss of Service TW to be caused in end-to-end channels only, because the threat is only relevant if the client has the same manager/operator. In the latter case Loss of Service TW is caused in all Client Channels to the service. Where the service is a transparent proxy, these threats only affect the local channels, affecting data flows on end-to-end channels through the proxy but not allowing direct attacks on the end-to-end relationship. Hence Loss of Service TW should not propagate between indirect and direct channels.
Service Impersonation (Loss of Service Authenticity) is caused by an attacker gaining control of the network and diverting client messages, or diverting the client by sending an incorrect service endpoint, e.g., via a phishing attack. In the former case this affects direct channels to the service, as the effect arises in the network. However, if the service is a transparent proxy, what is thereby diverted is the end-to-end communication, so that should also be affected. In the latter case, only end-to-end channels can be affected. Service Impersonation should therefore propagate from direct to indirect channels.
Loss of Anon User TW just means an attacker has network access to the service, which may be true of any service. It therefore affects all direct connections. It should propagate step-wise via transparent proxies towards the back-end service, as if anyone can send messages to the proxy, it will forward them. If the effect is present for a complete chain of connections from the client to the back-end service, the end-to-end connection should also be affected.
Note that Loss of Anon User TW does not imply that an attacker can authenticate or access the service, but it is a prerequisite for malicious access, and sufficient to launch anonymous attacks on a service.
Client Impersonation (Loss of Client Authenticity) is caused when an attacker acquires the means to authenticate to the service as the client. This does not imply they can access the service, however. The ways an attacker can acquire the means to authenticate include (a) access to a service that fails to authenticate clients - so the attacker wouldn't need any credentials at all, (b) access to credentials used by the client that are verified by the service, or (c) authenticated access to a separate service that handles authentication on behalf of the target service. Case (b) includes access to credentials by compromising the client, while case (c) includes authentication by a back-end service enabling authenticated access to a transparent proxy.
Client Impersonation does not propagate between indirect and direct connections. Client Impersonation in an indirect end-to-end connection may be a precursor to an end-to-end Loss of Client TW, enabling Client Impersonation in direct connections from the intervening transparent proxies. Client Impersonation in one of those direct connections does not affect the end-to-end connection, however.
Loss of Client TW is caused by a malicious client user, a compromised (hacked) client, or an attacker with both network access to the service and access to a means of authentication as the client. The first two cases work in the same way as Loss of Service TW, and may affect either direct or indirect channels via transparent proxies. The last case only arises in end-to-end channels which may or may not be indirect.
Where the cause is not a malicious insider, the service may be able to detect that the client is being used by the wrong person (e.g., via biometric profiling) after authentication, so Loss of Client TW implies slightly more than the combination Loss of Anon User TW and Client Impersonation, which are enough to launch authenticated attacks but not to use the service where such checks are possible. Loss of Client TW (by itself) implies access by an imposter. It must be used in conjunction with (possibly contextualised) client attributes to fully model access by a hacked or malicious (but legitimate) client.
If a transparent proxy is compromised, it leads to a Loss of Client TW affecting only the direct channel to the adjacent back-end service, which may or may not be another proxy. The attacker would then have a means to leak data coming from a service and alter data going to a service.
The proxy could also snoop passwords or other credentials (unless protected end-to-end) along with data. However, it doesn't have unfettered access to the back-end service.
Conclusion
We should change threats causing these behaviours so they arise only where they should.
We should change threats caused by these behaviours or the associated TW attributes to ensure they are caused if appropriate while avoiding duplication between direct and indirect channels.