312-50 Question 409
Single answer▪ IoT ConceptsDuring an authorized assessment of a smart building, you discover several IoT environmental sensors and lighting controllers connected to the corporate network. The devices expose a web interface, but many also communicate using lightweight publish/subscribe messaging to a local broker on TCP port 1883. The client traffic appears unencrypted, and device status messages can be read in clear text when mirrored from a switch port. The security team asks which issue presents the most immediate risk that an attacker on the same network segment could exploit to manipulate device behavior with minimal effort. What is the BEST answer?
- A
The devices are using MQTT over port 1883 without transport encryption or strong authentication, allowing an attacker on the local network to subscribe to topics and potentially publish unauthorized control messages
- B
The devices are vulnerable because Zigbee traffic is always routed over TCP port 1883, allowing direct packet injection from any host on the IP network
- C
The main risk is that CoAP requires a web browser plugin, which attackers can use to bypass network segmentation and control the sensors remotely
- D
The greatest risk is that IoT devices using REST APIs on HTTP cannot be fingerprinted, making it impossible for defenders to detect rogue commands
Show answer and explanation
Correct answer: A
Explanation
The key indicators in the scenario are publish/subscribe messaging, a local broker, TCP port 1883, and clear-text traffic. Together these strongly identify MQTT used without TLS. In IoT environments, MQTT is widely deployed because it is lightweight and efficient for constrained devices, but insecure deployment creates a practical attack path: anyone with access to the same network segment may capture messages, learn topic structure, and potentially publish unauthorized commands if the broker does not enforce authentication and authorization properly. This is especially serious in operational environments like smart buildings because control topics may affect physical systems.
From a CEH perspective, the candidate should recognize protocol identification and assess real attack impact rather than just naming ports. Best practice is to use MQTT over TLS, commonly on port 8883, implement broker-side authentication/authorization, segment IoT networks, and monitor topic access. These recommendations align with widely accepted guidance from MQTT security best practices and general IoT security guidance such as NIST IoT cybersecurity publications and vendor documentation for MQTT brokers.
- A. Correct.
Correct. MQTT is a common lightweight messaging protocol used in IoT environments. Port 1883 is typically associated with MQTT without TLS, while 8883 is commonly used for MQTT over TLS. If MQTT traffic is unencrypted and authentication is weak or absent, an attacker on the same network can observe topic names, subscribe to telemetry, and in some cases publish malicious messages to command topics. In a smart building, that could allow manipulation of lighting, HVAC-related sensors, or other building functions. This is an immediate practical risk because it requires neither sophisticated exploitation nor physical tampering if the attacker already has network access.
- B. Incorrect.
Incorrect. Zigbee is a low-power wireless protocol suite operating at the radio/network layer and is not simply routed over TCP port 1883. Port 1883 is associated with MQTT, an application-layer protocol over TCP/IP. A candidate might choose this option by confusing common IoT protocols, but the scenario explicitly describes publish/subscribe messaging to a broker on TCP port 1883, which strongly indicates MQTT rather than Zigbee.
- C. Incorrect.
Incorrect. CoAP is a lightweight application protocol typically using UDP, commonly on port 5683, and it does not depend on a web browser plugin. Attackers do not use a browser plugin to bypass segmentation in the way described. This distractor targets the misconception that all IoT protocols behave like web technologies. The scenario points to an observable broker-based publish/subscribe architecture, not CoAP.
- D. Incorrect.
Incorrect. REST APIs over HTTP can absolutely be fingerprinted through headers, endpoints, response patterns, and traffic analysis. The lack of encryption in HTTP is itself a concern, but the statement that REST-based IoT devices cannot be fingerprinted is false. Also, the question asks for the most immediate risk tied to the observed clear-text broker traffic, making MQTT message abuse the stronger answer.