The Publish-Subscribe messaging pattern is a solution to message dissemination and delivery challenges. Instead of directly transmitting a message to an end receiver (e.g. the way the traditional request-response pattern work), a publisher publishes the message under a relevant topic to an intermediary server (broker). Receivers communicate their demand for receiving specific messages (not necessarily from specific publishers) with the broker by subscribing to certain topics. Since the publisher and subscriber are not aware of the other party, the broker is responsible for capturing published messages, binding the subscriptions to the topics, and delivering the messages to the interested recipients.

Figure 1: Publish-Subscribe Architecture

Communication protocols based on the Publish-Subscribe pattern have been used for connecting different information systems and software components since the late 1980s. Such technologies, with the help of message queuing methods, have evolved around the main feature of the Publish-Subscribe pattern that is decoupling the sender (publisher) and receiver (subscriber). This property enables message producers and consumers communicate across time, space and synchronization. Such dissociation of publishers and subscribers, combined with content-based routing protocols, facilitates many-to-many communications.

STRIDE threat modeling and solution discussion

The decoupled multicast nature of many-to-many communications in the Publish-Subscribe pattern introduces the system components to threats such as unwanted traffic flooding, node compromise attacks, data tampering, privacy violation, and so on. We have identified the potential risks based on Microsoft’s STRIDE model. Figure 2 relates STRIDE threats to possible attacks and potential solutions in a Publish-Subscribe ecosystem.

Figure 2: STRIDE in Publish-Subscribe

Spoofing identity

An adversary can access, guess, or rebuild a legitimate user’s credentials to impersonate an authenticated entity in the system. In a Publish-Subscribe environment, publishers, subscribers, and brokers are subject to spoofing attacks. An illegitimate publisher may connect to the system as an authentic one. The broker (or a network of brokers) gives it permission to publish to restricted topics, and the subscribers accept its messages as they are from an authentic publisher. A disguised subscriber can also subscribe to restricted topics and receive potentially confidential messages. A malicious broker can introduce itself as a legitimate one to the system. If messages are not end-to-end encrypted, the fake (malicious) broker is able to read the messages or push crafted messages to certain critical topics on behalf of authenticated publishers. Moreover, it may modify routing settings or drop messages. This harms the confidentiality, integrity, and availability of the information system.

Some Publish-Subscribe protocols support mutual authentication by Transport Layer Security (TLS), using a certificate/private key, or Simple Authentication and Security Layer (SASL) mechanisms [4]. TLS might be too heavy for resource-constrained nodes since it imposes a fair amount of cryptographic computations on both the broker and the client. Although brokers might be resource-rich nodes capable of handling the load, publishers are typically thin nodes designed for specific purposes. For example, a battery-powered smoke detector that sends the measurement results to a local receiver might not have enough resources to maintain a TLS connection.

Tampering with Data

Data tampering involves unauthorized modification of stored or in-flight data. After the authentication phase, nodes in a Publish-Subscribe system generally communicate with each other using data and acknowledgment messages. If either is maliciously changed, the integrity of the messages is at risk. Four types of communications can be involved in such a system:

Publisher — Broker Broker — Broker (message routing) Broker — Subscriber Publisher — Subscriber (via broker)

The authenticity and integrity of messages can be verified at the transport or message level. TLS, as a transport level protection, when coupled with proper certificate validation can be used to protect against tampering. Message level mechanisms such as Digital Signature or MAC (Message Authentication Code) may ensure that an attacker cannot modify messages during transit, mitigating the risk of a replay attack. MACs are commonly employed if using TLS is not feasible, or if there are untrusted clients in the environment which can access restricted topics. For example, adding a Digital Signature or keyed-hash message authentication code (HMAC) of a published message content to the message helps the receiver validate the message.

Since Digital Signature mechanisms are asymmetric, the key provisioning requirements make decoupling publishers and subscribers challenging. These mechanisms are suitable in scenarios where a single publisher (which holds the private key) publishes to a certain topic. On the other hand, HMAC employs a shared key (that should be securely exchanged before the connection) with which holders can both sign and verify messages. HMAC calculations are typically faster than Digital Signature ones and consume fewer resources on constrained devices. The disadvantage of HMAC is that all nodes which have the shared key can sign any message (lack of non-repudiation).

Repudiation

Repudiation threats involve situations where there is no evidence that a user has taken an action in the system. For example, if a publisher posts an illegal message to a topic, there should be enough proof that the publisher has sent the message by intention.

Since Digital Signatures use asymmetric cryptography, no one other than the holder of the private key can sign malicious messages unless the private key is leaked. Therefore, Digital Signatures provide non-repudiation.

Although HMAC uses symmetric algorithms, if the subscriber stores the shared key in a tamper-proof hardware security module that calculates the tag and never releases the key, it can provide non-repudiation as well.

Information Disclosure

Information disclosure is about accessing confidential information by unauthorized individuals. In a Publish-Subscribe environment, sensitive messages can be exposed while in transfer between publisher-broker-subscriber or at rest.

TLS can provide strong protection by encrypting the transport layer. Publishers and subscribers must validate the broker’s certificate and establish a secure channel to it. In cases where even brokers are not allowed to access the message content or clients are not able to handle TLS, end-to-end encryption is required. Albeit, this opposes the nature of Publish-Subscribe systems in which publishers and subscribers are supposed to be decoupled.

In addition to protecting the communication channels, brokers must store the session information and in-flight messages in a secure database that is either encrypted by the broker application or is on a protected file-system. Brokers must restrict access to system feedbacks and status topics. For example, it is bad practice if a broker publicly publishes the server status, detailed error messages, metadata, and so forth. By implementing access control mechanisms such as role-based access control (RBAC), brokers can explicitly specify users’ (or roles’) access to each topic.

Denial of Service

Denial of service (DoS) attacks prevent the system from providing service to legitimate users. Publish-Subscribe networks are susceptible to such attacks due to their centralized nature. Slow publishers or subscribers, verbose publishers, mishandled exceptions, large messages, etc. may overwhelm the broker and exhaust its available resources. Both malicious and benign nodes in a network can cause DoS. Implementing proper authentication and encryption mechanisms provides protection against deliberate attempts. To prevent resource exhaustion caused by bad broker implementation or configurations, the broker should:

Return a reply code and close the connection to avoid ambiguous states after an error occurrence. For example, syntax errors, over-sized data, and failed authentication attempts;

Close the connections and release the resources after a configurable amount of time;

Check if a publisher or subscriber is authorized to request higher guaranteed delivery levels;

Mirror topic queues across multiple nodes;

Monitor memory and disk usage and dedicated resources accordingly; and,

Set general and client-specific resource consumption limits (E.g., number of concurrent connections, message size, publish rate to certain topics, etc.).

Elevation of privilege

Elevation of privilege is when an unauthorized user gains access to privileged functions and takes actions beyond its allowed expected behavior. For example, a temperature sensor that is programmed to publish the recorded temperature can be tricked to send a ‘delete device’ command. Such attacks are possible if there are not enough authorization schemes and device access control mechanisms in place.

Conclusion

The Publish-Subscribe messaging pattern adds advantages such as loose coupling and scalability to Machine-to-Machine communications. However, it makes the system vulnerable to a range of attacks if proper protection mechanisms are not in place. We applied the STRIDE model to group the potential threats and investigate possible solutions. This article helps the system designers to address such threats and incorporate suitable defense measures in their design according to the system’s requirements, capabilities, and characteristics.

References

Patrick Th. Eugster, Pascal A. Felber, Rachid Guerraoui, and Anne-Marie Kermarrec. 2003. The many faces of publish/subscribe. ACM Comput. Surv. 35, 2 (June 2003), 114–131. DOI=http://dx.doi.org/10.1145/857076.857078 The STRIDE Threat Model, https://msdn.microsoft.com/en-us/library/ee823878(v=cs.20).aspx The Transport Layer Security (TLS) Protocol Version 1.2, https://tools.ietf.org/html/rfc5246 Simple Authentication and Security Layer (SASL), https://tools.ietf.org/html/rfc4422 OASIS Advanced Message Queuing Protocol (AMQP) Version 1.0, http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-overview-v1.0-os.html

Authored by:

Amir Pourafshar, Application Security Researcher