Threat Modeling: Designing for Security (2014)

Appendix B. Threat Trees

These threat trees are worked-through analyses, intended to act as both models and resources. Each tree is presented twice, first as a graphical tree and then as a textual one. The versions contain the same data, but different people will find one or the other more usable. The labels in the trees are, by necessity, shorthand for a longer attack description. The labels are intended to be evocative for those experienced with these trees. Toward this goal, some nodes have a label and a quoted tag, such as “phishing.” Not all nodes are easily tagged with a word or an acronym. The trees in this appendix are OR trees, where success in any node leads to success in the goal node. The rare exceptions are noted in the text and diagrams.

This appendix has three sections: The main body is a set of 15 STRIDE threat trees. That is followed by three trees for running code on a server, a client, or a mobile device, as those are common attacker targets. The last tree is “exploiting a social program,” illustrating how systems such as e-mail and instant messenger programs can be exploited. The appendix ends with a section on tricky filenames, and their use in certain classes of attacks which trick people.

STRIDE Threat Trees

These trees are organized according to STRIDE-per-element. Each has as its root node the realization of a threat action. These STRIDE trees are built on the ones presented in The Security Development Lifecycle (2006). The trees are focused on first-order threats. Once you have elevated privileges to root, you can do an awful lot of tampering with files on that system (or other mischief), but such actions are not shown in the trees, as including them leads to a maze of twisty little trees, all alike.

Each tree in this section is followed by a table or tables that explains the node and discusses mitigation approaches, both for those developing a system and those deploying it (“operations”) who need stronger security. The term “few” in the mitigations column should be understood as meaning there is no obvious or simple approach. Each of the ways you might address a threat has trade-offs. In the interests of space and focused threat modeling, those trade-offs are not discussed in this appendix. In a very real sense, when you start considering those trade-offs, threat modeling has done its job. It has helped you find the threat. What you do with it, how you triage and address the bugs from those threats, is a matter of good engineering.

The trees presented in this section are shown in Table B.0. In this appendix, the labels differs from normal Wiley style, in ways that are intended to be easy (or easier) to use given the specific information in this appendix.

§ Tables are numbered to align with the figures to make it easier for you to go back and forth between them. Thus, figure B.1 is referenced by Tables B-1a, B-1b, B-1c, B-1d and B-1e, while figure B.2 is referenced by a single Table B.2.

§ Many tables are broken into smaller logical units. The breakdown is driven by a desire to have tables of reasonable length.

§ Where there are multiple tables per tree, they are referred to as subtrees. Each subtree is labeled with a combination of category (“spoofing”) and subnode (“by obtaining credentials”).

§ Numbering of tables starts at zero, because you're a programmer and prefer it that way. (Or perhaps because we wanted to start figures at B-1, making this table hard to number.)

Table B.0 STRIDE-per-Element

* (B-1) Spoofing an external entity is shown as spoofing a client in the following tables.

** (B-3) Spoofing of a data flow is at odds with how STRIDE-per-element has been taught.

*** (B-8) Repudiation threats matter when the data stored is logs.

Figure B.1 Spoofing an external entity (client)

Table B.0 does not have a figure associated with it.

Note

The spoofing of a data flow is at odds with how STRIDE-per-element has generally been taught or presented, but it is in alignment with how some people naturally think of spoofing. It's less-tested content; and as you gain experience, you're likely to find that the threats it produces overlap heavily with spoofing of a client or tampering with a data flow.

Each tree ends with “other,” a node without further discussion in the explanatory text because given its unanticipated nature, what to add is unclear. Each tree is technically complete, as “other” includes everything. Less glibly, each tree attempts to focus on the more likely threats. Therefore, for example, although backup tape data stores are subject to both tampering and information disclosure, the disclosure threats are far easier to realize, so the backup threats are not mentioned in the tree for tampering with a data store. Generally, only security experts, those aspiring toward such expertise, or those with very high value targets should spend a lot of time looking for those “others.” It is tempting, for example, when writing about tampering with a process, to declare that those threats “matter less.” However, which threats matter is (ahem) a matter of requirements.

As a community, we know relatively little about what threats manifest in the real world (Shostack, 2009). If we knew more about which threats are likely, we could create trees optimized by likelihood or optimized for completeness, although completeness will always need some balance with pedantry and usability. Such balance might be provided by tree construction or how the tree is presented. For example, a software system that contains the trees could pre-sent various subsets.

Spoofing an External Entity (Client/ Person/Account)

Figure B.1 shows an attack tree for spoofing by/of an external entity. Spoofing threats are generally covered in Chapter 3, “STRIDE,” and Chapter 8, “Defensive Tactics and Technologies,” as well as Chapter 14, “Accounts and Identity.”

§ Goal: Spoof client

§ Obtain existing credentials

§ Transit

§ Federation issues

§ Change management

§ Storage

§ At server

§ At client

§ At KDC

§ At 3rd party

§ Backup authentication

§ Knowledge-based authentication (KBA)

§ Information disclosure (e-mail)

§ Chained authentication

§ Authentication UI

§ Local login Trojan (“CAD”)

§ Privileged access Trojan (./sudo)

§ Remote spoof (“phishing”)

§ Insufficient authentication

§ Null credentials

§ Guest/anonymous credentials

§ Predictable credentials

§ Factory default credentials

§ Downgrade authentication

§ No authentication

§ Other authentication attack

Also consider whether tampering threats against the authorization process should be in scope for your system.

Table B.1a Spoofing by Obtaining Existing Credentials Subtree

Table B.1b Spoofing by Obtaining Existing Credentials: Attacking Storage Subtree

Table B.1c Spoofing Backup Authentication Subtree

* It is tempting to suggest that you should not display data that other sites might use for authentication. That advice is a “tar pit,” leading to more questions than answers. For example, some organizations use the last four digits of a SSN for authentication. If you don't display those last four digits, should you display or reveal other digits to someone who can authenticate as your customer? If you do, you may help an attacker construct the full number. It is also tempting to say don't worry about organizations that have made poor decisions, but backup authentication is a real challenge, and characterizing those decisions as poor is easy in a vacuum.

Table B.1d Spoof Authentication UI Subtree

* Currently, phishing is typically performed by websites, but other forms of remote spoofing are feasible. For example, an app store might contain an app falsely claiming to be from (spoofing) Acme Bank.

Table B.1e Spoofing Where There's Insufficient Authentication Subtree

There is no table for either no authentication (which is hopefully obvious; change that if the requirements warrant such a change) or other authentication attack.

Spoofing a Process

Figure B.2 shows an attack tree for spoofing a process. Spoofing threats are generally covered in Chapter 3, and Chapter 8. If an attacker has to be root, modify the kernel, or similarly, use high privilege levels to engage in spoofing a process on the local machine; then, generally, such attacks are hard or impossible to mitigate, and as such, requirements to address them are probably bad requirements.

figure B.2 Spoofing a process

Goal: Spoof process

§ Name squatting

§ Load path

§ Remote system spoofing

Table B.2 Spoofing a Process

Spoofing of a Data Flow

Figure B.3 shows an attack tree for spoofing a process. Spoofing threats are generally covered in Chapter 3, and Chapter 8; and many of the mitigations are cryptographic, as covered in Chapter 16, “Threats to Cryptosystems.” Spoofing a data flow is an amalgamation of tampering with a data flow and spoofing a client, which may be a more natural way for some threat modelers to consider attacks against network data flows. It is not traditionally considered in STRIDE-per-element, but it is included here as an experimental approach.

Figure B.3 Spoofing of a data flow

Goal: Spoof a data flow

§ Spoof endpoint

§ Steal keys

§ Forge keys

§ Weak key generation

§ Via PKI

§ Weak authentication

§ Spoof endnode

§ MITM

§ Take over endpoint

§ Spoof packets

§ Blind injection

§ On-path injection

§ Other spoofing data flow

Table B.3a Steal/forge Keys Subtree

Table B.3b Forge Keys Subtree

* Some examples of weak key generation include (Debian, 2008) and (Heninger, 2012).

† Examples of misrepresentation include Verisign issuing certificates for Microsoft (Fontana, 2001). A legal demand might be like the one issued to Lavabit (Masnick, 2013). Commercial deals include ones like Verisign's operation of a “lawful intercept” service (Verisign, 2007).

Table B.3c Weak Authentication Subtree

Table B.3d Spoof Packets Subtree

The “take over endpoint” node should be self-explanatory.

Tampering with a Process

Figure B.4 shows an attack tree for tampering with a process. Tampering threats are generally covered in Chapter 3, and Chapter 8, and are touched on in Chapter 16.

Figure B.4 Tampering with a process

Goal: Tamper with a process

§ Corrupt state

§ Input validation failure

§ Access to memory

§ Local user/program

§ Local admin

§ Call chain

§ Caller

§ Callee

§ Spoof an external entity

§ Subprocess or dependency

§ Other tampering with the process

Also consider whether these threats apply to subprocesses, or what happens if callers or callees are spoofed.

Table B.4a Corrupt State Subtree

Table B.4b Call Chain Subtree

Tampering with a Data Flow

Figure B.5 shows an attack tree for tampering with a data flow. Tampering threats are generally covered in Chapter 3, and Chapter 8, cryptography will often play a part in addressing them, and is covered in Chapter 16.

Figure B.5 Tampering with a data flow

Generally, if you don't prevent spoofing of a data flow, you have tampering and information disclosure problems.

Data flow threats can apply to channels or messages, or both. The difference is easiest to see with examples: E-mail messages travel over an SMTP channel, whereas HTML (and other format) messages travel over HTTP. The question of which you need (either, neither, or both) is a requirements question.

Goal: Tamper with a data flow

§ Message

§ No message integrity

§ Weak message integrity

§ Weak key management

§ Channel

§ No channel integrity

§ Weak channel integrity

§ Weak key management

§ Man in the middle

§ Spoof endnode (or endpoint)

§ Exploiting PKI

§ Time or ordering

§ Replay

§ Reflection

§ Collisions

§ Upstream insertion

§ Other tampering with data flow

Table B.5a Tampering with a Message Subtree

Table B.5b Tampering with Channel Integrity Subtree

Table B.5c Tampering with Time or Ordering Subtree

Table B.5d Tampering via Upstream Insertion Subtree

Tampering with a Data Store

Figure B.6 shows an attack tree for tampering with a data store. Tampering threats are generally covered in Chapter 3, and Chapter 8.

Figure B.6 Tampering with a data store

Goal: Tamper with a data store

§ Not protected

§ Confuse request

§ Bypass protection rules

§ Weak rules

§ No protection

§ Bypass protection system

§ Bypass monitor

§ Bypass integrity checker

§ Use another program to write

§ Physical access

§ Capacity failures

§ Discard

§ Wraparound

§ Other

You might consider tampering with the monitor or elevation of privilege against it; however, often at that point the attacker is admin, and all bets are … more complex. Capacity failures are an interesting balance of tampering and denial of service, but they can certainly result in tampering effects that are valuable to an attacker.

Table B.6a Tamper with a Data Store Subtree

Table B.6b Tamper by Bypassing Protection Rules Subtree

Table B.6c Tamper by Bypassing a Protection System Subtree

Table B.6d Tampering via Capacity Failures Subtree

The developer mitigations in Table B.6d are slightly less tongue-in-cheek than it may appear. After all, when you are out of storage, you're out of storage; and at that point you must choose either to allow the storage issue to stop the system or to make room in some fashion. Not shown in the table are compression and moving data to another store somewhere, both of which can be legitimate approaches.

Repudiation against a Process (or by an External Entity)

Figure B.7 shows an attack tree for repudiation against a process, or by an external entity. Repudiation threats are generally covered in Chapter 3, and Chapter 8, as well as in Chapter 14.

Figure B.7 Repudiation against a process

Goal: Repudiation

§ Account takeover

§ Real

§ Fake

§ Message

§ Deny sending

§ Deny receipt

§ Assert tampering

§ Assert not proper account

§ Replay

§ Other

Table B.7a Repudiate by Account Takeover Subtree

* If you impose penalties, you will inevitably impose them on innocent customers. Be judicious.

Table B.7b Message Repudiation Subtree

Repudiation, Data Store

Figure B.8 shows an attack tree for repudiation in which logs are involved. Repudiation threats are generally covered in Chapter 3, and Chapter 8.

Figure B.8 Repudiation, Data Store

Goal: Repudiation (data store focus)

§ Transaction

§ No logs

§ Insufficient logs

§ Logs scattered

§ Logs not synchronized

§ Logs not capturing authentication

§ Tamper with logs

§ DoS logs

§ Attack through logs

§ Other

Table B.8a Transaction Repudiation Subtree

* Also, manage privacy issues here, and information disclosure risks with logs exposing authentication information.

Table B.8b Redupidation Attacks through Logs Subtree

See also denial of service (Figure and Tables B.14) and tampering with data stores (Figure and Tables B-6a).

Information Disclosure from a Process

Figure B.9 shows an attack tree for information disclosure from a process. Information disclosure threats are generally covered in Chapter 3, and Chapter 8.

Figure B.9 Information disclosure from a process

Goal: Information disclosure from a process

§ Side channels

§ Timing

§ Power draw

§ Filesystem effects

§ Emissions

§ Sound

§ Other radiation

§ Protocol

§ Banners

§ Behavior

§ Logs

§ Corrupt process

§ Other

§ Swap/Virtual memory

As a class, side channels are like metadata; they're unintentional side-effects of computation, and they are often surprisingly revealing.

Table B.9a Information Disclosure via Side Channels Subtree

Table B.9b Information Disclosure via Protocol Subtree

Table B.9c Additional Information Disclosure Threats Subtree

Information Disclosure from a Data Flow

Figure B.10 shows an attack tree for information disclosure from a data flow. Information disclosure threats are generally covered in Chapter 3, Chapter 8 and Chapter 16.

Figure B.10 Information disclosure from a data flow

Generally, if you don't prevent spoofing of a data flow, you have tampering and information disclosure problems.

Data flow threats can apply to channels or messages, or both. The difference is easiest to see with examples: E-mail messages travel over an SMTP channel, whereas HTML (and other format) messages travel over HTTP. The question of which you need (either, neither, or both) is a requirements question.

Goal: Information disclosure from a data flow

§ Observe message

§ No confidentiality

§ Weak confidentiality

§ Observe channel

§ No confidentiality

§ Weak confidentiality

§ Man in the middle (See Tables B3 spoofing data flows.)

§ Side channels

§ Effects

§ Other and spoofing

See also tampering with data flows (Figure and Tables B-3a and B-5a, many of which can lead to information disclosure.

Table B.10a Information Disclosure by Observing a Message Subtree

Table B.10b Information Disclosure by Observing a Channel Subtree

Table B.10c Other Information Disclosure Threats Subtree

Information Disclosure from a Data Store

Figure B.11 shows an attack tree for information disclosure from a data store. Information disclosure threats are generally covered in Chapter 3, Chapter 8, and Chapter 16.

Figure B.11 Information disclosure from a data store

Goal: Read from a data store

§ Bypass protection

§ Canonicalization failures

§ No protection

§ Bypass monitor

§ Weak permissions

§ Use other consumers

§ Metadata

§ Name

§ Size

§ Timestamps

§ Other

§ Surprise

§ Occluded data

§ Side channels

§ Storage attacks

§ Physical access

§ Non-cleaned storage

§ Reused memory

§ Backup

§ Other

Table B.11a Information Disclosure by Bypassing Protection Subtree

Table B.11b Information Disclosure through Metadata and Side Channels Subtree

Table B.11c Information Disclosure from Surprise Subtree

Table B.11d Information Disclosure via Storage Attacks Subtree

* Threats to backup can also allow tampering. However, completing a tampering attack with a backup tape is far more complex than information disclosure through such tapes.

Denial of Service against a Process

Figure B.12 shows an attack tree for denial of service against a process. Denial-of-service threats are generally covered in Chapter 3, and Chapter 8.

Figure B.12 Denial of service against a process

Goal: Denial of service against a process

§ Consume application resource

§ Consume fundamental resource

§ Input validation failures

§ Hold locks

§ Other

Table B.12 Denial of Service against a Process

Denial of Service against a Data Flow

Figure B.13 shows an attack tree for denial of service against a data flow. Denial-of-service threats are generally covered in Chapters 3, and Chapter 8.

Figure B.13 Denial of service against a data flow

Goal: Denial of service against a data flow

§ Preplay

§ Corrupt messages

§ No integrity

§ Weak integrity

§ Incapacitate channel

§ Consume fundamental resource

§ Consume application resource

§ Incapacitate endpoints

§ Squatting

§ DoS against process

§ Other

Table B.13a Denial of Service via Preplay Subtree

Table B.13b Denial of Service via Corrupt Messages Subtree

Table B.13c Denial of Service By Incapacitating a Channel Subtree

Denial of Service against a Data Store

Figure B.14 shows an attack tree for denial of service against a data store. Denial-of-service threats are generally covered in Chapter 3, and Chapter 8.

Figure B.14 Denial of service against a data store

Goal: Denial of service against a data store

§ Squatting

§ Corrupt data (See tamper with data store, Figure B.6.)

§ Incapacitate container

§ Deny access to store

§ Exceed capacity

§ Fundamental

§ App specific

§ Quotas

§ Bandwidth

§ Other

Exceed capacity or bandwidth means I/O operations per second, and if sustained, that can have knock-on effects as I/O is queued.

Table B.14a Deny Service by Squatting Subtree

Table B.14b Deny Service by Incapacitating a Container Subtree

Elevation of Privilege against a Process

Figure B.15 shows an attack tree for elevation of privilege against a process. Elevation of privilege threats are generally covered in Chapter 3, and Chapter 8.

Figure B.15 Elevation of privilege against a process

Goal: Elevation of privilege against a process

§ Dynamic corruption

§ Input validation failure

§ Access to memory

§ Static corruption (See tamper with data store, Figure B.6.)

§ Insufficient authorization

§ Cross domain issues

§ Call chain issues

§ Design issues

§ Usability

Table B.15a Elevate Privilege by Dynamic Corruption Subtree

Table B.15b Exploit Insufficient Authorization to Elevate Privileges Subtree

* Amazon and Akamai are mentioned to be evocative, not to disparage their services.

Other Threat Trees

These trees are intended to be templates for common modes of attack. There are several tensions associated with creating such trees. First is a question of depth. A deeper, more specific tree is more helpful to those who are experts in areas other than security. Unfortunately, through specificity, it loses power to shape mental models, and it loses power to evoke related threats. Second, there is a tension between the appearance of completeness and the specificity to an operating system. For example, exploit domain trust is Windows specific, and it can be derived from either “abuse feature” or “exploit admin (authentication)” or both, depending on your perspective. As such, consider these trees and the audience who will be using them when deciding if you should use them as is or draw more layers.

Unlike the STRIDE trees shown earlier, these trees are not presented with a catalog of ways to address the threats. Such a catalog would be too varied, based on details of the operating systems in question.

Running Code

The goal of running code can also be seen as elevation of privilege with respect to a system. That is, the attacker moves from being unable to run code (on that system) to the new privilege of being able to run code (on that system). These trees also relate to the goal of exploiting a social program, which is presented next. The key difference is that the trees in this section focus on “run code,” and that is not always an attacker's goal. These trees do not contain an “other” node, but the categories are designed to be broad.

On a Server

In this context, a server is simply a computer that does not have a person using it, but rather is running one or more processes that respond to network requests. The goal is “run code” rather than “break into,” as breaking in is almost always a step along a chain, rather than a goal in itself, and the next step toward that goal is almost always to run some program on that machine. This tree, as shown in Figure B.16, does not distinguish between privilege levels at which an attacker might run code.

Figure B.16 Run code on a server

Goal: Run code on a server

§ Exploit a code vulnerability

§ Injection vulnerabilities

§ Script injection

§ Code injection (including SQL and others)

§ Other code vulnerabilities

§ Abuse a feature

§ Exploit authentication

§ Physical access

§ Supply chain

§ Tamper with hardware

§ Tamper with software

§ As shipped

§ Tamper with an update

§ Administrator action

§ Intentional

§ Accident/mislead

Tampering with software updates may be targetable or may require a broad attack. Injection vulnerabilities are a broad class of issue where code/data confusion allows an attacker to insert their code or scripts.

On a Client

All of the ways that work to break into a “server” work against a client as well, although the client may have less network attack surface. As shown in Figure B.17, the new ways to break in are to convince the person to run code with additional or unexpected functionality or to convince them to pass unsafe input to code already on their machine. You can either convince them to run code knowing they're running code but not understanding what impact it will have, or confuse them into doing so, such as by using a file with a PDF icon and displayed name which hides its executable nature. (See the section below on “Attack with Tricky Filenames.”) If you're convincing a victim to pass unsafe input to a program on their machine, that input might be a document, an image, or a URL (which likely will load further exploit code, rather than contain the exploit directly).

Figure B.17 Run code on a client

These attacks on the person can come from a variety of places, including e-mail, instant message, file-sharing applications, websites, or even phone calls.

Goal: Run code on a client

§ As server

§ Convince a person to run code

§ Extra functionality

§ From a website

§ Tricked into running

§ Convince person to open an exploiting document (possibly via a document, image, or URL)

§ Watering hole attacks

§ Website

§ Filesharing

§ Other

§ “What's this?”

Those paying attention might notice that this is informed by the Broad Street Taxonomy, as covered in Chapter 18, “Experimental Approaches.” Watering hole attacks are similar to “convince person to open an exploiting document,” but they target a possibly broad class of people. That may range from targeting those interested in an obscure government website to those visiting a programming site. (Attack code in either place may involve some discretion based on target IP, domain, or other factors.) Watering hole attacks can also impact those downloading content from file-sharing services and the like. The last category (“What's this?”) refers to attacking a person via a file on a file share, USB key, or other device, so curious users click an executable because they're curious what it does.

On a Mobile Device

The term mobile device includes all laptops, tablets, or phones. Attacks against mobile devices include all client attacks, and physical access has added prominence because it is easier to lose one of these than a refrigerator-size server. The additional attacks are shown in Figure B.18.

Figure B.18 Run code on a mobile device

Goal: Run code on a mobile device

§ As client

§ Convince to run code* (may be modified by app stores)

§ Physical access has greater prominence

*Convincing someone to run code may be changed by the presence (or mandate) of app stores. Such mandates lead to interesting risks of jailbreaks carrying extra functionality.

Attack via a “Social” Program

For longer than the Internet has been around, people have been attacked at a distance. Most countries have a postal police of some form whose job includes preventing scammers from taking advantage of people. The Internet's amazing and cheap channels for connecting people have brought many of these online, and added a set of new ways people can be taken advantage of, such as exploiting vulnerabilities to take over their computers.

The threat tree shown in Figure B.19 can be used in two ways. First, it can be used as an operational threat model for considering attack patterns against e-mail clients, IM clients, or any client that a person uses in whole or in part to connect with other people. Second, it can be used as a design-time model to ensure that you have defenses against attacks represented by each part of the tree.

Figure B.19 Using a social program to attack

Goal: Attack via a “social” program

§ Run code

§ Unattended exploit

§ Exploit vulnerability via document

§ Reason to act + belief in safety

§ Belief in safety

§ Human action

§ Visit a website

§ Phishing

§ Exploit vulnerability*

§ Ad revenue

§ Other

§ Drive other action

*The “Exploit vulnerability” reason to get a person to visit a website means that the attacker does something to convince a person to visit a website where there's exploit code waiting. It is duplicative of the “exploit vuln with assistance.” It is sufficiently common that it's worth including in both places. (There is an alternative for attackers, which is to insert their exploit into an advertisement shown on the web.)

This tree intentionally treats attacks by administrators or the logged-in account as out of scope. The “logged-in account” here refers to acts taken either by that person or by code running with the privileges of that account. Once code is inside that trust boundary, it can most effectively (or perhaps only) be managed by code running at a higher privilege level. Almost by definition that is out of scope for such a social program. You might have an administrative module that runs at higher privilege and, for example, acts as a reference monitor for certain actions, but code running as the logged-in account could still change the user interface or generate actions.

Attack with Tricky Filenames

A simple model of convincing a person to act requires both a reason for them to act and a belief that the act is safe, or sufficiently safe to override any caution they may feel. The reasons that attackers frequently use to get people to act are modeled in Table 15-1 of Chapter 15. A belief in safety may come from a belief that they are opening a document (image, web page, etc.) rather than running a program. That belief may be true, and the document is carrying a technical exploit against a vulnerability. It may also be that the document is really a program, and named in a way that causes the user interface to hide parts of the name. Hiding parts of the name can be a result of extension hiding in Mac OS, Windows, or other environments. It can also be a result of various complex issues around mixing displayed languages whose text directions are different (read left to right or right to left). For example, what's the correct way to write Abdul's Resume? Should it be resume ? If, rather than having that resume in a file named .doc, it's a .exe, where should the .exe be displayed relative to ? On the one hand, the Arabic should be displayed farthest right, but that will confuse those who expect the extension there. If the extension is on the far right, then the Arabic is displayed incorrectly. It's easy for a person to get confused about what a file extension really is.

Entertainingly, Microsoft Word took the text entered as “Abdul (in Arabic) Resume” and re-rendered it as “R” “e” “s” “u” “m” “e” “L/lam” etc. Abdul, and then re-arranged the question mark typed after the name to be between those words. (Which just goes to show…the issues are complex, and there's no obviously right answer.)