Identify misconfigured IoT policies using AWS IoT Device Defender

Introduction

We are excited to announce a new AWS IoT Device Defender audit feature to identify potential misconfigurations when using wild cards in Internet of Things (IoT) policies. AWS IoT Device Defender is a fully managed IoT security service that enables you to audit and monitor your IoT device fleet and secure your IoT configurations on an ongoing basis. Security misconfigurations, such as overly permissive policies that permit a device access to unintended resources, can be a major cause of security incidents and compromise the security posture of your solution. With the new AWS IoT Device Defender IoT policy potentially misconfigured audit feature, you can more easily identify flaws, troubleshoot issues, and take necessary corrective actions. This can help you improve the security posture of your IoT solutions.

Background

AWS IoT Core policies are JSON documents. They follow the same conventions as AWS Identity and Access Management (IAM) policies. With AWS IoT Core policies, you can control access to the AWS IoT Core data plane. The AWS IoT Core data plane consists of operations that enable you to connect to the AWS IoT Core message broker and send and receive MQTT messages. Similarly, data plane operations can also help you get or update the state of your device through AWS IoT Device Shadow, a feature of AWS IoT Core that makes a device’s state available to apps and other services, whether the device is connected to AWS IoT or not.

In some cases, customers might misconfigure IoT policies because of confusion between IoT policy wildcards and MQTT wildcards. If a customer configures IoT policies in a certain way, it is possible to over-subscribe devices to receive data on topics when the devices should have been explicitly denied subscription.

In this blog, we discuss two types misconfigurations and how you can use AWS IoT Device Defender audit to identify and fix these potential misconfigurations in IoT policies.

Using wildcard characters in MQTT and AWS IoT Core policies

MQTT and AWS IoT Core policies have different wildcard characters and you should choose them after careful consideration. In MQTT, the wildcard characters ‘+’ and ‘#’ are used in MQTT topic filters to subscribe to multiple topic names. Character ‘+’ for single MQTT topic level, and ‘#’ for multiple MQTT topic levels. AWS IoT Core policies use ‘*’ and ‘?’ as wildcard characters and follow the conventions of IAM policies. In a policy document, the ‘*’ represents any combination of characters and a question mark ‘?’ represents any single character. In policy documents, the MQTT wildcard characters, ‘+’ and ‘#’ are treated as those characters having no special meaning. To describe multiple topic names and topic filters in the resource attribute of a policy, use the ‘*’ and ‘?’ wildcard characters in place of the MQTT wildcard characters.

When choosing wildcard characters to use in a policy document, consider that the ‘*’ character is not confined to a single topic level as the ‘+’ character is in an MQTT topic filter. To help constrain a wildcard specification to a single MQTT topic filter level, consider using multiple ‘?’ characters. Refer to the documentation for examples of wildcard characters used in MQTT and AWS IoT Core policies for MQTT clients.

There are 2 types of misconfigurations:

Type 1: When customers want a device to receive messages for a whole topic space ‘building/*’ but not for specific sub-topics related to ‘building/control_room/*’.

In this example, topic filters are intended to deny access, but the use of wildcard results in allowing access. In a policy that contains topic filter with wildcards in allow statements, and a deny statement that has a subset of allow resources, the deny topic messages can potentially be accessed by subscribing to wildcards.

{

Effect:  Allow

Action: Subscribe

Resource: /topicfilter/building/*

Effect: Deny

Action: Subscribe

Resource: /topicfilter/building/control_room/#

Effect: Allow

Action: Receive

Resource: /topics/building/ *

}

However, when a device subscribes to ‘building/#’, it gets messages from ‘building/control_room/3’.

This is because topic ‘building/#’matches allow ‘building/*’, authorizing the subscription operation for the device. Note that lower in the application code, ‘building/#’ matches all data, and since a device is already subscribed it will receive all the matching topic data.

When you specify topic filters in AWS IoT Core policies for MQTT clients, MQTT wildcard characters ‘+’ and ‘#’ are treated as literal strings. Their use might result in unintended behavior.

How to fix it:

{

Effect:  Allow

Action: Subscribe

Resource: /topicfilter/building/*

Effect: Deny

Action: Subscribe

Resource: /topicfilter/building/control_room/*

Effect: Deny

Action: Receive

Not-resource: /topic/building/control_room/*

}

Once you do that, the device will receive messages published on any topic under topic/ (for example ‘building/common_area’) however, the device will not receive any messages published on any topic under ‘building/control_room/’ (for example ‘building/control_room/3’)

There could be legitimate use cases where the author may have done it this way, for example, to permit maintenance crew to access a particular space (for example ‘/building/control_room/3’). Thus, in our AWS IoT Device Defender audit check, we named this a potential misconfiguration and we leave it up to the user to decide, whether this was intentional or an unintended misconfiguration.

Type 2: When customers want a device to receive messages for a whole topic space ‘building/camera/*’ but not for specific sub-topics that involve control_room as in ‘building/+/control_room’. MQTT wildcards in Deny statements could potentially be circumvented by devices when replacing wildcards with specific strings.

{

Effect: Deny

Action: Subscribe

Resource: /topicfilter/building/+/control_room

Effect: Allow

Action: Subscribe

Resource: /topicfilter/building/camera/*

}

The desired behavior is to deny device access to ‘building/camera/control_room’, but allow access to ‘building/camera/resident1’.

However, devices can send request to topic ‘/building/+/control_room’ and end up receiving messages from topic ‘/building/camera/control_room’.

How to fix it:

{

Effect: Deny

Action: Subscribe

Resource: /topicfilter/building/*/control_room

Effect: Allow

Action: Subscribe

Resource:  /topicfilter/building/camera/*

Effect: Allow

Action: Receive

Resource: /topic/building/camera/*

Effect: Deny

Action: Receive

Resource: /topic/building/*/control_room

}

With this fix, IoT policy will allow the device to receive messages from:

/building/camera/resident1

/building/camera/resident2

/building/camera/resident3

But not from

/building/camera1/control_room

/building/camera2/control_room

/building/any_camera/control_room

Identify potential misconfigurations using AWS IoT Device Defender audit check

In this section, we’ll show how to configure, run, and take corrective actions in the AWS IoT Console for the two types of misconfigurations described earlier.

In this example we’ve entered Type 1 and Type 2 in AWS IoT as follows:

Figure 1: Type 1 policy named as ‘MisconfiguredPolicy’ configured in AWS IoT

Figure 2: Type 2 policy named as ‘MisconfiguredPolicyInfo_2’ configured in AWS IoT

Then, once we run the new ‘IoT policy potentially misconfigured’ audit check, the following reason code is returned when this check finds a potentially misconfigured AWS IoT policy:

a) POLICY_CONTAINS_MQTT_WILDCARDS_IN_DENY_STATEMENT

b) TOPIC_FILTERS_INTENDED_TO_DENY_ALLOWED_USING_WILDCARDS

Figure 3: Results from AWS IoT Device Defender ‘IoT policy potentially misconfigured’ audit check

The AWS IoT Device Defender ‘IoT policy potentially misconfigured’ check inspects for MQTT wildcard characters (‘+’ or ‘#’) in deny statements. Wildcards are treated as literal strings in a policy document and can make it overly permissive.

How to fix it

This audit check flags potentially misconfigured policies as there might be false positives. Mark any false positives using Audit finding suppressions so they don’t get flagged in the future.

You can also follow these steps to fix any noncompliant policies attached to things, thing groups, or other entities:

• Use CreatePolicyVersion to create a new, compliant version of the policy. Set the setAsDefault flag to true. (This makes this new version operative for all entities that use the policy.)
• Verify that all associated devices are able to connect to AWS IoT Core. If a device is unable to connect, use SetPolicyVersion to roll back the default policy to the previous version, revise the policy, and try again.

Conclusion

In this post, you’ve learned about finding potential misconfigurations in your IoT policies using AWS IoT Device Defender audit. The ‘IoT policy potentially misconfigured’ audit feature, checks for the use of wild cards in IoT policies and alerts you in the case of potential misconfigurations. Then, you can follow the security recommendations and take corrective actions if needed. This new audit check makes it easier for customers to reduce IoT policy misconfigurations and helps you improve the security posture of your IoT solutions.

If you use AWS IoT Device Defender, you can enable the new audit check in the AWS IoT Device Defender audit section. If you are new to AWS IoT Device Defender, you can improve the security posture of your IoT device fleet with the one-click process in the AWS IoT console. For more information, refer to AWS IoT Device Defender documentation.

Authors

Ryan Dsouza is a Principal Solutions Architect for IoT at AWS. Based in New York City, Ryan helps customers design, develop, and operate more secure, scalable, and innovative solutions using the breadth and depth of AWS capabilities to deliver measurable business outcomes. Ryan has over 25 years of experience in digital platforms, smart manufacturing, energy management, building and industrial automation, and OT/IIoT security across a diverse range of industries. Before AWS, Ryan worked for Accenture, SIEMENS, General Electric, IBM, and AECOM, serving customers for their digital transformation initiatives.

Andre Sacaguti is a Sr. Product Manager-Tech at AWS IoT. Andre focuses on building products and services that help device makers, automotive manufacturers, and IoT customers from diverse industries to monitor and secure their devices from edge to cloud. Before AWS, Andre built and launched IoT products at T-Mobile and Qualcomm.