ACTS Blog Selection
We use machine learning technology to do auto-translation. Click "English" on top navigation bar to check Chinese version.
Identify misconfigured IoT policies using Amazon Web Services IoT Device Defender
Introduction
We are excited to announce a new
Background
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 Amazon Web Services IoT Device Defender audit to identify and fix these potential misconfigurations in IoT policies.
Using wildcard characters in MQTT and Amazon Web Services IoT Core policies
MQTT and Amazon Web Services 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. Amazon Web Services 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
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 Amazon Web Services 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 Amazon Web Services 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 Amazon Web Services IoT Device Defender audit check
In this section, we’ll show how to configure, run, and take corrective actions in the Amazon Web Services IoT Console for the two types of misconfigurations described earlier.
In this example we’ve entered Type 1 and Type 2 in Amazon Web Services IoT as follows:
Figure 1: Type 1 policy named as ‘MisconfiguredPolicy’ configured in Amazon Web Services IoT
Figure 2: Type 2 policy named as ‘MisconfiguredPolicyInfo_2’ configured in Amazon Web Services 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 Amazon Web Services IoT policy:
a) POLICY_CONTAINS_MQTT_WILDCARDS_IN_DENY_STATEMENT
b) TOPIC_FILTERS_INTENDED_TO_DENY_ALLOWED_USING_WILDCARDS
Figure 3: Results from Amazon Web Services IoT Device Defender ‘IoT policy potentially misconfigured’ audit check
The Amazon Web Services 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
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 Amazon Web Services 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 Amazon Web Services 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 Amazon Web Services IoT Device Defender, you can enable the new audit check in the Amazon Web Services IoT Device Defender audit section. If you are new to Amazon Web Services IoT Device Defender, you can improve the security posture of your IoT device fleet with the one-click process in the Amazon Web Services IoT console. For more information, refer to Amazon Web Services IoT Device Defender
Authors