3

TL;DR Would a potential attacker need to have my Wi-Fi password and be connected to my network in order to read HTTP requests?

Over the past year or so, I have made a few DIY home automation projects. Included in this is a garage door opener. The basic premise of which is that when I want to open the garage, the home automation hub sends an http (not https) GET request (e.g. 192.168.1.xxx/openGarage) to the DIY IoT device which then opens the garage. (The IoT device will trigger the garage whenever it receives that specific /openGarage request)

However, for some time now, this has worried me. I was wondering whether an attacker who was not connected to the network would be able to intercept the HTTP get request (192.168.1.xxx/openGarage) and then be able to replay this get request in order to open the garage without my knowing.

So, my question is: would an attacker need to be connected to my home network in order to intercept this GET request (/openGarage) or would they need to bee connected in order to see this?

Thank you in advance for your help,

Kind regards, Rocco

P.S. I understand that making this request an https one instead would obfuscate the request, however, it is quite hard to implement proper SSL encryption on an ESP8266 which is what I am using for this IoT device. Thus, I am willing to hinge my security on the strength of my WPA2 password. That is, if an attacker would need to be connected to my network in the first place to intercept the request as per the above question.

Rocco
  • 205
  • 1
  • 6

2 Answers2

7

Yes. An attacker would need to be on your network - either wirelessly or wired - to intercept an intra-network HTTP request. If it left your network for the broader Internet, the attacker could potentially intercept it anywhere between your property and the server, but with the server on the same local network the traffic won't leave your router. As WPA provides both encryption and replay protection, an attacker wouldn't know what message you are sending, nor would they be able to replay it (although traffic analysis - such as noting the packet size, and/or noting that a message for a particular MAC address is always sent before the garage door opens - would be possible).

However, by implementing your system this way, you're opening yourself up to the massive world of web application / web service security vulnerabilities. As a trivial example, you service right now is almost certainly vulnerable to CSRF; if any machine on your network visits a web page with 256 invisible image tags on it - one each from <img src="http://192.168.1.0/openGarage"> to <img src="http://192.168.1.255/openGarage"> - your garage door would open. JS could be used to iterate through even much larger spaces very quickly.

CBHacking
  • 40,303
  • 3
  • 74
  • 98
  • Thank you for your answer! I'm glad to hear that an attacker would need to actually be on my network to read or replay these HTTP requests. However, as you say, I do agree that this current implementation is in no way secure. I hadn't even considered the trivial attack you mentioned. Luckily, as a first line of defence, the `/openGarage` is just for demonstration and in reality the string is random generated. However, I appreciate that it is still rather insecure. What would you recommend is the best step forward? Looking into `https`? Basic http authentication? Thanks once again! – Rocco Mar 15 '19 at 23:36
  • Basic auth wont do anything to defend in a HTTP environment. Your only hope (if HTTPS truly cant be done) is to validate the client using either a pre-shared-key or a challenge. While this would also fix the CSRF CBHacking mentioned, i think the argument of CSRF, though technically correct, is tenuous, as it insinuates someone has already figured out the /openGarage request on the network. Which would likely mean that have some level of access to your network anyway and could therefore make the request themself (that or they have read this question). – hiburn8 Mar 15 '19 at 23:44
  • Neither of those approaches would fix the problem, as CSRF is entirely independent of HTTPS (or its lack) and basic auth is sent automatically by any browser that has logged into the site in question. Moving from GET to POST would make things marginally trickier but is no real fix either. Using some other HTTP verb would be much more secure, but specifically because browsers would refuse to send the request absent specific situations. I suggest an access token in a POST message body; a browser will happily send that but an attacker won't know the token to send. – CBHacking Mar 15 '19 at 23:50
  • 1
    @hiburn8 I will try to look further into HTTPS as I feel it will fix many unforeseen problems. Luckily, as I stated, `/openGarage` specifically is just an example, in reality the string is something random (e.g. `/gnexewjow`) so I hope this also adds some 'security'. However, as I said in my main question, I am willing to hinge some of my security simply on the exclusivity of my network and therefore on my WPA2 passcode. – Rocco Mar 15 '19 at 23:51
  • @CBHacking Ah I see. What do you mean by "Using some other HTTP verb"? Also how do you suggest an access token would solve the problem? Would you be able to link to a more detailed explanation of the implementation? Thanks once again – Rocco Mar 15 '19 at 23:55
  • HTTPS really is the obvious solution. But it wasn't a stupid question because there are a lot of IoT SoCs that simply dont have enough CPU grunt to use HTTPS :) – hiburn8 Mar 15 '19 at 23:59
  • Basically, you set up a token - a pre-shared secret is probably fine, here, although if you want to be fancy you could use a TOTP key instead - that both the server (IoT device) and your client (either in your head or in the web page or whatever you use to send the request) know, but that isn't published anywhere else. You send the request as a POST, with the token in the body; the server ignores any requests over GET or that don't have the right token. As for the thing about HTTP verbs, there are other ones than GET or POST, and browsers won't send most of them to other sites by default. – CBHacking Mar 16 '19 at 08:12
  • A rudimentary way to secure this setup, without using a lot of memory that you don't have, would be to use a random number generator with a known seed value. As long as the algorithm for generating the number is the same on both ends and you only have one device activating the other you can be sure that each time you run it they'll both generate the same number. This will also let you know if someone did get in because the numbers will be out of sync. I'd also make it lock down for a short period and record anytime it's sent an invalid number so that you're made aware when someone tries. – krowe Mar 16 '19 at 11:38
2

Unless you want to read around the subject areas involved, this is a simple question with a simple answer. YES, an attacker would need to be connected to your network (given that it is an encrypted network) in order to see the contents of packets and therefor the /openGarage API.

If thats all you care about, we're done. But I will go on to say that even in a non secured (http) environment, it might still be possible to get some level of assurance that no-one is successfully hitting up your API. The way i would do this is have a pre-shared key between the IOT device and server, which are used to generate continuously changing tokens for use to validate each-other. Essentially the same model as a one-time passcode. This seems like something even very basic IoT devices which might struggle to process HTTPS data should be able to achieve. The ideal scenario would be that the 'server' is aware of the last used token, to prevent an attacker from abusing the race-condition to re-use a token.

Pretty much any other attempt to add security would have to rely on obscurity. As a really awful example, you could change '/openGarage' to '/questions' and on that network use a DNS server such that requests appear to be going to 'stackexchange.com/questions'. Depending on what the attacker sees, they might be fooled into thinking the endpoint is of no interest/value.

Lastly. If the IoT device can handle it... some logging never hurts.

hiburn8
  • 441
  • 2
  • 11
  • Apologies for repeating some of what CBHacking wrote, i think we were both typing at the same time. The CSRF he mentioned is remediated by the concept of a one-time passcode however... as i mentioned you could use. – hiburn8 Mar 15 '19 at 23:39
  • Thank you for your detailed answer. Would you be able to go into more depth about using a pre-shared key? If it is possible, would you be able to link to a demonstration if such an implementation do I can look into seeing whether it is something I could implement into the ESP8266? – Rocco Mar 15 '19 at 23:48
  • Based on your hardware limitations, i would imagine the best tradeoff for security and effort (given that you are not protecting the crown jewels but still want to have some assurance) would be to use the current time of the devices to encrypt a string/passphrase. The 'server' would perform this operation once at timed intervals (say per minute) and therefore the client would be able to generate a valid token within this timeframe assuming it's system clock is in reasonably good sync with the server. – hiburn8 Mar 15 '19 at 23:54
  • So i think to make that happen all you really need to do is A) make sure that the clocks/times are in sync for the client and server. B) figure out which forms of encryption are possible on your IoT device. Given that you are only performing encrypt actions every minute and decrypt actions on every request, this shouldnt be a huge performance requirement at all. – hiburn8 Mar 15 '19 at 23:56
  • Don't use time, it is unreliable. The best you can do is having Client and Server sharing a secret, then each request packet is signed with HMAC for authenticity and the secret is used for validation. This means that 1) you have to securely upload the same secret both to Client and Server using another medium 2) all data is publicly visible so you can't send sensitive information 3) you cannot use that public connection to update the secret on Client and Server, so you will have to updated it from time to time using a secure medium. 4)both Client and Server are vulnerable to Replay attacks – CoffeDeveloper Mar 16 '19 at 07:15
  • You can mitigate Replay attacks by forcing X requests in a time interval, and each request is signed with X(n) and current time. So if someone sends another replay request with X(n) before time elapsed, the request is rejected because X(n) was already used, if someone sends a request with X(n) and previous time, you can reject it because current time is greater than previous time + time interval. You should use a time interval for rejection that is actually shorter (something like t/2) than the maximum requests, so you don't get random rejections when near interval limits. – CoffeDeveloper Mar 16 '19 at 07:19
  • So actually "(YOUR_MESSAGE) (REQUEST NUMBER:X) (TIME OF MESSAGE SENT)", and sign that with H(secret|| H(secret || message)). Note here "request number". If any message with "request number was sent" before time*0.75. Reject it. If any message with time < (now - time*0.5) was sent reject it. If HMAC signature verification fails, reject the message. You could allow in example 65536 messages every 10 seconds both on client and server. With 10 seconds you can theorically have clocks with 1 seconds difference – CoffeDeveloper Mar 16 '19 at 07:24
  • Time is not so simple on the IoT devices I've used. In order to have accurate time your going to want\need a RTC which is a separate piece of hardware that you'll need to buy and replace the battery for every year or so. See my comment above for a better solution that is, essentially, equally secure but actually possible on these very limited devices without additional hardware or laughable memory requirements (like encryption in 100k of memory). – krowe Mar 16 '19 at 11:58
  • Don't trust IoT. Over time it unpatched it will become owned by someone else. Separate your IoT to a dedicated VLAN. Restrict node access to your API and log everything and use secure passwords that are machine random generated. Audit your network regularly especially bandwidth utilization. When you find an anomaly get a full packet capture and see where it's going and to what. – Brad Mar 17 '19 at 05:14
  • Let's not get confused people, for a device to be classified IoT, it would... by definition, require access to the internet and therefore need a RTC. If you are talking about devices that are so dumb that they dont have an RTC (for example a philips hue bulb might not need one) then you are forgetting that these devices only function with the use of a bridge component. The bulb alone is hardly an IoT device. Typical universal IoT SoCs are actually quite feature-rich, just low spec. They will ALWAYS have an RTC. – hiburn8 Mar 18 '19 at 08:27
  • To be fair @brad you could say that about any device (e.g. Windows systems) where the user deploys a poor patching cycle. Its not an inherent issue with IoT, and is effectively user-error. – hiburn8 Mar 18 '19 at 08:29
  • @hiburn8 With users own systems, yes poor patching practices. However, for IoT devices say a door lock attached to your deadbolt the manufacturers will only support the device with patching for a certain amount of time unless there is a forced continuity like an ongoing maintenance fee to keep funding the further software development of the device. Also the hardware if you dissect such a device is generally under-powered with barely enough storage and memory to handle such updates of included frameworks. – Brad Apr 01 '19 at 15:21
  • @Brad i agree with you in practice that IoT is generally weaker, although those are not inherent problems with IoT that you have highlighted, but a poor security state for the businesses making IoT devices. You have the exact same problem with motherboard vendors who can't be bothered to update a BIOS after 12 months, despite possible vulnerabilities. And the hardware of an IoT device should be strong enough to at least support updates, or else thats just a design flaw. – hiburn8 Apr 02 '19 at 14:43
  • Hopefully IoT will sort itself out in a few years when all in one IoT SOCs are more prevalent and its not everyone making a bunch of proprietary trash. – hiburn8 Apr 02 '19 at 14:44