Skip to Content
Author's profile photo Oliver Kling

Message authorization in IoT

In a threat modeling workshop for a specific scenario we discovered a message authorization issue. In the following I would like to repeat exemplarily the thinking that led to this discovery. The example I am using is completely fictitious and I have not verified if any existing product on the market is susceptible to this. Even if one would be susceptible – this is no hacking guide! Remember that we are on the good side.

The example I would like to dissect is home automation. Let’s assume we are building a home automation solution that allows amongst others controlling the heating system with temperature sensors and opening the door with a remote key.

What are we going to protect? Amongst other things we want to prohibit an attacker to open the door. Sure we do not want to give attackers a chance for tampering with the heating or other connected things either, but let’s concentrate on the door.

We can use basically any threat modeling methodology to analyze this scenario. For example we could use attack trees, where the attacker’s goal would be to open the door without the appropriate door opener. STRIDE (see also: would definitely work as well but I would like to use our SAP methodology for the time being.

Typically, we start with spoofing / authentication related threats.

Can we spoof the identity of a thing?

OK, we have temperature sensors and door openers (still looking at the subset only). How are they authenticating their identity against the central system? Our current design foresees that authentication uses a pre-shared key plus an object ID. From an attacker’s perspective (that is our current role) we want to get access to both. We want to have a valid ID and a valid key. As we have no access to the house where this stuff is located, access is difficult – but wait, the heating system relies on a sensor sending the outside temperature. Can we get access to that? Maybe we can reach the sensor without breaking into something. But we need physical access – quite a bit of a hurdle.

Assume we get access to the sensor, we would need to be able to get the ID and the key from it. Maybe the ID is printed on the case? Maybe we need to open the case and try to download the code from the processor? Let’s assume the ID is not printed on the case, but we are able to connect to the processor using some appropriate connection (might be an Arduino using an onboard USB or so). We use a tool to download the code from the unit and get the assembler code. Again that is quite a bit of a hurdle, as we need to be able to analyze and understand assembler coding. But let’s assume we are so clever, the code will eventually unveil the key and the ID to us. Now we can fake at least sensor data, if we are able to upload our own malicious code. At least we should be able to fake outside temperature and bring the heating system to heat up or switch off.

So we have broken authenticity. The next step is to check what we can do once we are in (authorization). As what we reached currently is not what we want.

Let’s ask further questions. What happens if we send an ‘open the door’ message using our sensor access? Let’s try. We can search for the correct format of the message in publicly available specifications. Now let’s just create and upload a program that does not sense temperature but sends an ‘open the door’ message.

As an attacker, let’s hope that we can trick the system to open the door. If it works, we have succeeded with our attack. But what went wrong from the design perspective?

The designers (we) missed to check the message authorization. We have implemented a two-step approach: 1) check the authenticity of the sender and 2) check if the message is well formed. If both conditions are met, we process the message. But we missed to verify if the ‘open-the-door’ message is coming from the door opener.

How big is this threat? Well, we need access to a device (no internet attack detected for the time being), we need to be able to download the code and analyze it (depends very much on the hardware in use). We need to be able to write a malicious program using the correct message format. Overall the attack is not so easy (we would label it at least ‘advanced’) but the impact would be severe: somebody could enter our house without leaving a trace. An advanced attack leading to a severe impact is a critical risk in our methodology. So we better try to fix this.

I know I skipped a lot of details, but in principal it is a design flaw we found already and not necessarily in IoT scenarios, though it makes up a good example.

What is your opinion on that? I would be interested for example in your view on the assorted risk. Happy to read your comments.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Colleen Hebbert
      Colleen Hebbert

      Hi OIiver

      In relation to your scenario - advanced or not - it would really come back to do value of the attack by the perpetrator - What's the impact and the cost and of the impact? Your scenario has already identified the vulnerability and although it is an advanced attack it will be exploited if there is benefit. Plus, the person wants to break in for a reason so doing a first round visit to inspect the device is not going to be a deterrent (maybe security guard stands out the front as an additional protection measure).

      What's behind the closed door that the really want. Even to a simply scenario of interfering with HVAC - change the temperature alone could have adverse effects (i.e. data centre intead of a home).

      Your scenario is quite like an interface coming into a SAP system or a an RFC connection. You might perform RFC call to another system and the other system has malicious code which executes in the called system (paraphrasing). Similar setup where you are trusting the identity and the message format but you didn't consider the context of it. Good to know SAP has the additional RFC security in SM59 to limit which connects can call-back and execute which RFCs. Again, this type of attack would be considered advanced but if there is benefit and someone has the motivation then it could happen.

      From a physical point of view the same break in authenticity could be someone handing their security Id over to a friend who looks like them and walk straight into the building. Once they're in the building, if there are not specific access restrictions (e.g. certain floors are off limits for that person) the attacker now has the keys to the kingdom.

      Interesting read and I loved the scenario based approached to step to identifying the flaw and realise that you need to think through the risk (and outside the box) to find the vulnerabilities and risks.



      Author's profile photo Oliver Kling
      Oliver Kling
      Blog Post Author

      Hi Colleen,

      thanks for your comment, you are perfectly right. The very first step is to know what you are protecting - it is basically the question about the assets. If you do not know what you are trying to protect the security measures and their related investments might be meaningless at worst. Very often you protect the confidentiality and integrity of data plus the availability of the system. In IoT scenarios there are much more severe consequences that you typically want to avoid. But as said you need to be sure what you are trying to protect.

      Once you know that it is helpful to think about the potential hackers. Who would have an interest to break into your system or to create havoc. The range is very wide from script kiddies over criminals, hacktivist, to terrorist and finally to state financed groups.

      Recently I added white hat hackers on my list as well. Though they have good intention by the definition of white hat hacking, they pose a certain risk to your product or service as publishing a successful hack can definitely have a negative impact on your business.

      These two steps can from my view point be completed rather easily. Skipping the somewhat tricky part of finding the vulnerabilities you reach the point where you have to evaluate the risk behind it.

      As a first step it is perfectly OK for me to evaluate the risks of the vulnerabilities (never had one threat modeling where we had only one vulnerability - my minimum is 4) from a 'local' perspective. Meaning you just focus to rate the risks of your project to help you prioritize your efforts. Already that is not so easy to be honest.

      Once you want to achieve comparability across a portfolio of products or services it becomes even more tricky. For sure stuff for many more blogs 😉

      However just starting to do threat modeling is rather easy. And even if you apply it on an ad hoc basis only it is so helpful, that I do not see any excuse for not doing it. And by the way it is always very interesting and sometimes real fun.

      Best regards