EoP Threat Suits - S (Spoofing)

Spoofing (S) is the first suit of threats in the STRIDE threat enumeration.

Spoofing describes any threat that allows an attacker (or accidentally causes a user) to pretend to be someone or something else. Accordingly, the characters on the cards are masked individuals wearing crowns - unknown attackers, pretending to be royalty.

Spoofing threats are generally countered through quality implementations of Identification and Authentication, also known in their combined form as "Authentification". Authentification is almost always a pre-requisite to Authorisation, although the three are not generally combined to form "Authentifisation". This isn't Mighty Voltron, you know.

Another successful way to mitigate spoofing is to not care about the identity of participants - this is only a successful mitigation when operations by anonymous, even untrustworthy, users are allowed. Ignoring identity and hoping that attackers will not look at areas they aren't supposed to enter is not a valid mitigation strategy.

The cards in the Spoofing suit are as follows

Spoofing Suit
Value	Threat	Example / Mitigation
2	An attacker could squat on the random port or socket that the server normally uses	Example: An FTP server listens for data connections on sequential port numbers starting at 1024. An attacker can guess what the next port number will likely be, and connect to it before the client. Your service listens on a named pipe, called "MyServicePipe". An attacker could create a pipe with that name, and intercept calls or prevent your service from running. Mitigation: Make it impossible to guess port numbers, by using truly random assignments. Communicate port numbers only after the listening socket is successfully created. Identify named pipes in ACL-protected configuration stores such as system files or registry keys.
3	An attacker could try one credential after another and there’s nothing to slow them down (online or offline)	Example: (Online) A web service accepts function requests with an authentication parameter that consists of a password. An attacker could continually send function requests with different passwords until he gets a successful response. (Offline) The password database consists of hashed copies of each user's password. An attacker could download the password database, and hash passwords using his super-fast implementation of the password hash function until he finds a password hash that is in your password database. Mitigation: In online credential validation, identify sources of bad logon attempts and delay or disconnect them. Remember that account lockout creates a denial-of-service attack in itself, and avoid using it unless regulations or policies require it. For offline credential validation, use an algorithm, and number of rounds, that will mathematically guarantee long execution times, no matter how fast the implementation is. Remember to protect password hashes from birthday attacks by using a random and unique salt on each password to be hashed.
4	An attacker can anonymously connect, because we expect authentication to be done at a higher level	Example: A web site that uses forms-based authentication, and then redirects users to a different site that does not confirm the authentication information from the previous site. An attacker can simply skip the form page and continue on to the target page. Mitigation: Verify authentication, using a token whose validity you can check. Examples of reliable tokens include signed or encrypted cookies, SSL session keys, security tokens, Kerberos tickets. A TCP or named-pipe connection that is authenticated early on can be considered to still carry the same authentication throughout its life or until its authentication is changed.
5	An attacker can confuse a client because there are too many ways to identify a server	Example: A client can connect to a server using its IP address, its FQDN (www.example.com), its short name (example), and may not be able to verify the server's identity with a certificate that it receives from such a connection. If the user (or the client application!) expects to be told that the server name does not match the certificate, that user will dismiss similar errors - essentially being trained to allow an attacker to create a parallel server. Mitigation: Funnel connections through a single mechanism, so that normal users are presented with a consistent secure and recognisable entry point to your server. That way, if an attacker tries to spoof a server, the user and client will be able to raise an alert.
6	An attacker can spoof a server because identifiers aren’t stored on the client and checked for consistency on re-connection (that is, there’s no key persistence)	Example: A client application connecting to a web service can be given credentials (by an attacker pretending to be that service) which match the client’s expectations for a valid credential set, but have been manufactured by the attacker to fool the client. Mitigation: Store a copy of the most recently-validated credentials, and warn when the credentials change – particularly if the change is not associated with the previous certificate expiring or being revoked.
7	An attacker can connect to a server or peer over a link that isn’t authenticated (and encrypted)	Example: Connections to a third party web service where the third party does not require you to identify yourself. This could result in charges for access by people who are not you, or other negative effects such as disruption to your service, modification of your data, etc. Mitigation: Use HTTPS with client authentication; use HTTPS with other forms of authentication. Most authentication protocols are not suited for HTTP. Kerberos is one good exception.
8	An attacker could steal credentials stored on the server and reuse them (for example, a key is stored in a world readable file)	Example: Breach notifications should serve as a sufficient warning sign against storing customer passwords. Credentials used by a web server to talk to the back-end database can be used by an attacker who has hacked your web server. This “leap frogging” allows an attacker to make a path into your internal systems and expand their exploit. Mitigation: For customer passwords, use a modern strong cryptographic hash of a salted copy of the password – run the hash through several rounds to make it infeasible to attack the password hash database even if it gets stolen. Ideally, use an internal password-verification service, so that an attacker cannot directly access the password hash database at all. For internal credentials, make sure that they are protected from access by the account used by the web server. Ideally, use other credentials and authentication (such as IPsec) that are controlled by the system account on the web server machine.
9	An attacker who gets a password can reuse it (Use stronger authenticators)	Example: Basic Authentication over HTTP sends the username and password in the clear. The same username and password can then be re-used by anyone else who intercepts the communication. Using the HTTP GET method with Forms-based Authentication leads to username and password being logged at intervening proxies and at the web server’s logs. Mitigation: Stronger authenticators would include certificate-based client authentication over HTTPS, two-factor authentication, or an authentication protocol like S/Key, where a new key is derived from your password for each connection. In each of these authentication techniques, your previous authentication information cannot be re-used even if it is intercepted.
10	An attacker can choose to use weaker or no authentication	Example: An attacker who gets to choose what method of authentication is used by a connection will choose the weakest form. In an FTP connection, for instance, if the attacker can prevent client and server from authenticating through SSL, and the client chooses to fall back to unprotected passwords, the attacker can capture a password that would be unavailable to them in FTP over SSL. Similarly, in an HTTP scenario, if a user can authenticate through Forms-based Authentication over HTTP or HTTPS, the attacker can force transmission of a clear-text password by blocking the HTTPS connection. Mitigation: There are no good reasons these days to use plain-text authentication over a clear-text link. Do not allow passwords to be sent over unencrypted links. Do not accept authentication (other than Kerberos) through HTTP. If connecting to an FTP site over SSL, refuse to drop back to unencrypted FTP.
J	An attacker could steal credentials stored on the client and reuse them	Example: Mitigation:
Q	An attacker could go after the way credentials are updated or recovered (account recovery doesn’t require disclosing the old password)	Example: Mitigation:
K	Your system ships with a default admin password, and doesn’t force a change	Example: Mitigation:
A	You’ve invented a new Spoofing attack	Example: Mitigation:

[When completed, each card description above will link to a copy of the card, along with examples of the threat and some specific mitigation steps. Point to Patterns & Practices documents, excerpts from Writing Secure Code, etc, where possible. Emphasise that the information is already out there, so that dev teams widen their horizons.]