Attacks by clients on services, whereby the right of a compromised client to access a service is exploited.
Unauthorized access attacks, whereby an attacker gains access to a service with the rights of a client, either by exploiting a failure by the service to authenticate the client, or by first gaining the means to impersonate the client.
Remote attacks exploiting a backdoor or other vulnerability in the service, which may or may not require authentication.
We now have several distinct trustworthiness attributes (and associated misbehaviours) for a client-service relationship that related to the ability to access the service as the client:
AnonUserTW: the ability to send unauthenticated messages to a service.
ClientAuthenticity: the ability of the service to authenticate the client.
ProxyUserTW: the ability to send messages to the service via a proxy having authenticated to the proxy.
ClientTW: the ability to access the service as the client, so low TW means an attacker can access the service.
ClientTW is the attribute that really counts. Low ClientTW means an attacker can access the service as the client and access data that was supposed to go to or from the legitimate client.
AnonUserTW does not represent the ability to authenticate or access the service functionality. Low TW just means malicious messages can reach the service. This means they could access the service, a threat leading directly to LossOfClientTW, unless the service authenticates its clients. Even in that case, it would be possible to exploit vulnerabilities if they are accessible without authentication, including pre-installed back doors.
AnonUserTW exists for every Client Channel, but currently, threats leading to Loss Of AnonUserTW are restricted to cases where the service is accessed via a transparent proxy. Such a proxy forwards all requests to a back-end service without authenticating the client, which means a malicious message would reach the target. Why not make this apply to all services, not just proxies?
ClientAuthenticity represents possession of client credentials. Low TW means an attacker has stolen those credentials. This does not imply that the attacker can access the service, as it may be on a protected network. If we expand our threats so every service is subject to threats against AnonUserTW, then a combination of this with ClientAuthenticity would imply access to the service (and LossOfClientTW), unless user biometrics can be used to recognise an imposter.
ProxyUserTW covers the forwarding of messages via an authenticating proxy. The proxy would then access the service under its own ID so this is authenticated access (the service thinks it is a legitimate client), subject to the proviso that one can only send messages if the proxy allows it, i.e., to a mapped endpoint. It would be possible to exploit vulnerabilities in the service application (i.e., requiring authentication), and if the service is a remote access service, it would be possible to get shell access to the host.
So the way to generalise the meaning of AnonUserTW, involves checking threats leading to this condition, or potentially caused by it. This comprising the following groups of threats:
[x] Caused by NetworkUserTW, leading to LossOfAnonUserTW: access via a client attack path. Prevented only by disabling network access to the service or filtering based on a known client IP address (if possible).
[x] Leading to a Loss Of Client Authenticity (ClientImpersonation): any threat to client credentials not involving access to the service, e.g., phishing, service impersonation, network snooping, password cracking. Not applicable to services that use a separate authenticator.
[x] Caused by ClientTW in one Client Channel, leading to ClientImpersonation in another. Only applicable to services that use a separate authenticator, whose ClientChannel is a cause of the threat
Caused by AnonUserTW:
[x] simple unauthenticated access, leading to LossOfClientTW. Prevented by any client authentication strategy, including a relationship
[x] access via a transparent proxy, leading to LossOfAnonUserTW.
[x] access to a backdoor, leading to LossOfUserTW at the Service, i.e., access to the Service host with the rights of the Service.
[x] remote exploit of vulnerabilities that can be reached without prior authentication.
Caused by AnonUserTW and LossOfClientAuthenticity
[x] Access using client credentials, leading to LossOfClientTW, unless prevented by using biometric signals to detect an imposter.
[x] Remote exploit of vulnerabilities that cannot be reached without prior authentication.
Caused by ProxyUserTW :
[x] Access to a backdoor, leading to LossOfUserTW at the Service, i.e., access to the Service host with the rights of the Service.
[x] Access to the host when the Service is a remote access service, leading to LossOfUserTW or LossOfControl at the Service Host,
[x] Remote exploit of vulnerabilities that cannot be reached without prior authentication.
Caused by ClientTW :
[x] Exploitation of a compromised authentication service, leading to ClientImpersonation in another, if using OAuth/OIDC.
[x] Threats to data flows.
Since only the first of these involves a client attack path (which are very numerous), it should be possible to reduce the number of threats used to cover the remaining cases.
mike1813
commented
12 months ago
We have three types of attacks on services:
We now have several distinct trustworthiness attributes (and associated misbehaviours) for a client-service relationship that related to the ability to access the service as the client:
ClientTW is the attribute that really counts. Low ClientTW means an attacker can access the service as the client and access data that was supposed to go to or from the legitimate client.
AnonUserTW does not represent the ability to authenticate or access the service functionality. Low TW just means malicious messages can reach the service. This means they could access the service, a threat leading directly to LossOfClientTW, unless the service authenticates its clients. Even in that case, it would be possible to exploit vulnerabilities if they are accessible without authentication, including pre-installed back doors.
AnonUserTW exists for every Client Channel, but currently, threats leading to Loss Of AnonUserTW are restricted to cases where the service is accessed via a transparent proxy. Such a proxy forwards all requests to a back-end service without authenticating the client, which means a malicious message would reach the target. Why not make this apply to all services, not just proxies?
ClientAuthenticity represents possession of client credentials. Low TW means an attacker has stolen those credentials. This does not imply that the attacker can access the service, as it may be on a protected network. If we expand our threats so every service is subject to threats against AnonUserTW, then a combination of this with ClientAuthenticity would imply access to the service (and LossOfClientTW), unless user biometrics can be used to recognise an imposter.
ProxyUserTW covers the forwarding of messages via an authenticating proxy. The proxy would then access the service under its own ID so this is authenticated access (the service thinks it is a legitimate client), subject to the proviso that one can only send messages if the proxy allows it, i.e., to a mapped endpoint. It would be possible to exploit vulnerabilities in the service application (i.e., requiring authentication), and if the service is a remote access service, it would be possible to get shell access to the host.
So the way to generalise the meaning of AnonUserTW, involves checking threats leading to this condition, or potentially caused by it. This comprising the following groups of threats:
Since only the first of these involves a client attack path (which are very numerous), it should be possible to reduce the number of threats used to cover the remaining cases.