22

I am connecting an Arduino Uno to the internet via ethernet (using the ethernet shield v2) and querying NTP time. Making requests to a NTP server is the only internet related thing it does. You can use the ethernet shield as an SD card to host data, I WILL NOT be doing that. It will only be querying NTP.

I'm worried this IoT device will become a security target for my network. What attacks is it vulnerable to? And how do I secure such a low spec device?

Note: I am not worried about physical attacks, the device will be locked away.

Sadly Full Stack
  • 103
  • 3
JohnnyAppleseed
  • 331
  • 2
  • 5
  • 3
    If all you want is time synchronisation, perhaps receiving an entirely passive clock source (e.g. the UK's [MSF Signal](https://www.npl.co.uk/msf-signal) or its local equivalent, or just GPS) would minimise the attack surface? – eggyal Sep 20 '21 at 12:25
  • 1
    Probably focus on the shield and the network. So sniffing and nasty packets (along the lines of ping of death), flooding, and that's about it. – mckenzm Sep 21 '21 at 06:51
  • Just to be explicit (because apparently that exists): I suppose the Arduino is not running an operating system? (Instead, it is something like [this page](https://www.arduino.cc/en/reference/ethernet) describes, only using a networking library.) – Peter - Reinstate Monica Sep 21 '21 at 15:08

6 Answers6

41

Unless your code has a memory corruption vulnerability in its handling of NTP, or there's a similar vulnerability in some part of the networking stack, there's basically no attack surface there.

Furthermore, an Arduino Uno uses an Atmel ATmega328P, which does not support execution of code from RAM. The code executes from the MCU program flash, which is not writable at runtime. This makes it highly implausible that anyone could gain either volatile or non-volatile persistence on it.

Polynomial
  • 132,208
  • 43
  • 298
  • 379
  • NTP implementations in the past have had vulnerabilities, especially acting as DoS amplifiers IIRC. However I doubt the Arduino implementation would be subject to that (though I really haven't looked at it all). – jcaron Sep 21 '21 at 08:10
  • Even if there were an NTP vulnerability: Wouldn’t it require a malicious NTP server or a man in the middle attack? – Michael Sep 21 '21 at 09:59
  • 2
    @jcaron the DoS amplifiers were problems with the servers (having a “send me a list of the last 600 requests you received” option, which is obviously easily abusable), rather than the clients. – Tim Sep 21 '21 at 12:55
  • 3
    @Tim in the (original) NTP world, the distinction between a server and a client is limited, a good “client” (which remains active monitoring time and adjusting system time) is actually also a server, possibly with access-control lists. But I indeed doubt any Arduino models actually follow that implementation and are probably more along the lines of sntp, indeed closer to a pure client. – jcaron Sep 21 '21 at 13:44
  • The flash memory on a ATmega328P can be written to at runtime, Arduino bootloaders do that for instance. (That can be disabled by setting a fuse bit though.) – Mat Sep 22 '21 at 06:12
  • @Mat Good point, I had forgotten about that. I'll do a quick read-up on the exact mechanism and update my answer to reflect the details. – Polynomial Sep 22 '21 at 14:52
  • 1
    Having thought about it some more, not sure how much of a threat it is. (Most?) AVR chips can't run code from RAM, only from flash. If the user code doesn't write to flash itself, I guess only the bootloader could be exploited (if it is even there), and that's prob going to need physical access. – Mat Sep 22 '21 at 15:57
  • @Mat Also good observations. I'll take a proper look at the AVR datasheets tomorrow or Friday, hopefully, and update this with a proper breakdown. – Polynomial Sep 22 '21 at 22:17
5

What attacks is it vulnerable to?

Denial of service comes to mind. E.g. someone sending data packets to the Uno at wire speed will probably be something of an issue to it. Something on the board needs to look into at least some part of the packets to determine if the software should care about it.

As far as I understand, the Wiznet chip on the Ethernet shield implements TCP and UDP itself, so it probably can filter out the uninteresting packets. But I can't find any numbers for what kind of performance you can expect. In any case, if the device is flooded with valid UDP packets aimed at the port your NTP client uses, the chip will likely need to pass them all to software. (If it supports filtering so as to accept only packets from the server you're trying to talk to, the attacker would need to spoof their IP address too.)

Depending on the specifics, the DoS could cause it to miss valid NTP replies, or just make it loop forever at looking at the network packets, without getting any useful work done.

Of course, you're probably not using any authentication with NTP, so forged/tampered reply packets could also be a possible issue.

ilkkachu
  • 2,086
  • 1
  • 11
  • 15
  • Would the UDP packet flooding work if I'm not implementing a webserver in software? It's only a client. – JohnnyAppleseed Sep 20 '21 at 23:42
  • 1
    Yes, consider the stack as a sieve. The Layer 1 PHY accepts all valid frames. The layer 2 MAC accepts all packets directed to your interface, if there is a running thread the layer 3 and above stack filters by ip and protocol. At some point an application will see if the data is semantically correct. Without an OS there is not really a concept of "closed ports", it is just a mask for part of the ip packet. At any layer of the stack is susceptible to DOS and errors. What happens in the worst case is less clear. Hardware implemented stacks are becoming more common, always read the errata! – crasic Sep 21 '21 at 04:35
  • 1
    UBOOT is an excellent case study, and analogy. By default uboot has no task running and no ISR, so when in uboot prompt the device will not accept an ICMP ping because there is no background thread, nobody is home even though the link is active. But, if you start a ping task on the device, it will happily respond to arbitrary ICMP packet and can be DOS'd. Since NTP is presumably expecting a response, there is some resident application that is accepting packets, at least some of the time. – crasic Sep 21 '21 at 04:39
3

Of course any vulnerability in the network stack or NTP will be a problem. Given a "big enough" vulnerability, remote code execution should be possible (since execution from RAM isn't possible, something like ROP could be used).

Finally, what could happen is that tiny device being used to relay an attack to your network (or to attack other networks, but that's less of a worry for you). In that context, you should consider isolating it.

Yes, whatever attack is done will not be persistent, but could be used to get a persistent presence in your network.

user1532080
  • 583
  • 2
  • 8
  • 2
    I'm not sold on the "relaying attack". You'd only be able to do something like that if you already compromised the device with a code execution vulnerability and found a way to build a reliable, repeatable packet forwarding capability purely out of ROP chains. That's already hard enough to pull off when you've got the source code, and quite impossible from a black-box perspective. An Arduino Uno certainly doesn't have any inherent properties that make it more useful for relaying traffic than any other network-connected device - you can't just magically use it to get traffic onto the network. – Polynomial Sep 20 '21 at 15:07
  • 2
    @Polynomial Relay attacks are a known issue with UDP based services (and NTP has been a rather well known target for them as it’s normally an unauthenticated public UDP service), you don’t need to compromise the relay device itself, you just need to successfully get a UDP packet with a fake source address matching your attack target to the relay. This can be as simple as having network access on the same subnet as the relay. – Austin Hemmelgarn Sep 20 '21 at 17:38
  • @AustinHemmelgarn If you're on the same subnet as the Arduino, you don't need to reflect off of it. You can just send traffic directly to the target using the Arduino's IP address as the spoofed source instead. A reflection attack only makes sense if you can use it to bypass a security boundary. If you're on an adjacent subnet and you can route packets into the target subnet with falsified source IPs, you don't need the Arduino to reflect them, and it's the router that's misconfigured - there's nothing specific to the IoT device here. Plus any reflected traffic would be limited to NTP replies. – Polynomial Sep 20 '21 at 17:50
  • UDP reflection is pretty much only useful for DDoS attacks because of the amplification you get. But in this context that doesn't make any sense as a threat, because the Arduino has extremely limited resources. The only security control I'd potentially consider in this regard is request rate limiting, but even that is a bit overkill. – Polynomial Sep 20 '21 at 17:52
  • This was really interesting to learn about! But I'm going to agree to Polynomial that it might not be that big of a deal. I'm going to be using the NIST ntp pool. https://tf.nist.gov/tf-cgi/servers.cgi . NIST offers the NIST Authenticated NTP Service as well (https://www.nist.gov/pml/time-and-frequency-division/time-services/nist-authenticated-ntp-service) but I don't think that would be worth the hassle for a normal home IoT device. – JohnnyAppleseed Sep 20 '21 at 23:40
  • You'd need more information... Attacker might have useful information (disgruntled former employee?). There are probably not that many network stack in Arduino. In general for an anonymous device connected to Internet, you may not have that much to fear from a random attacker. Also your last comment seem to indicate you're targeting home usage, so also a less interesting target to random attackers. – user1532080 Sep 21 '21 at 17:01
2

Good answers so far, but there's one thing I think has been missed (at least in detail), forging NTP packets. It's highly likely, due to the UDP nature of NTP, that the Uno will be susceptible to forged packets. Some one could send an NTP response back to the Uno and make it think it's really an hour (month, year, etc.) ahead or behind real time. How important of a risk this is depends on your threat model. If this is for deciding on when to turn on fans and grow lights for your indoor greenhouse, you might have a ruined crop or higher than normal power bill if the Uno continually thinks it's time to run those accessories.

It can take a little skill, but not too much to forge these. UDP is just one packet for request and one for response. If someone is close enough (network-wise) to monitor the packets, they can easily see the outgoing packets and forge the appropriate response. Even if they are out of the normal path of the traffic, it still might be possible to do it. NTP does provide an optional authentication layer, but it's likely not implemented in your library and rarely used anyways. Most often, a good NTP implementation will reject packets that are too far skewed from the current time (except for on boot), but this is probably just a simple implementation.

penguin359
  • 121
  • 2
0

Others have mentioned the DoS threat, and also the possibility of spoofed NTP. Depending on the use case, it might be possible to put it behind a firewall that could rate-limit UDP traffic to and from it. That would both mitigate the possibility of it being DoSed and of being used as a DDoS vector. That firewall - or another device - could also act as an NTP server or NTP proxy. That way you wouldn't have to allow traffic from the Arduino out to the internet. Instead, the firewall would talk to the NTP pool, and the Arduino would talk only to the firewall.

A simple Raspberry Pi with your choice of Linux or BSD could act as the firewall, with any of NTPsec, Chrony or OpenNTPD as the NTP server/proxy.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Jade Sprague
  • 101
  • 1
-1

All small devices with soft network stacks are vulnerable to flood attacks because the network can outrun the processor and overflow the buffer. The safest thing to do is ensure you have network hardware.

For example, the Raspberry Pi 3B+ and subsequent models have network hardware and can be hardened, but earlier models have soft stacks and are not suitable for use as controllers in a hardened system.

This is what ilkkachu is talking about with the Wiznet chip. His points illustrate that hardware link layer handling is only the beginning.

Peter Wone
  • 99
  • 3
  • 1
    NTP, which isn't based on TCP, doesn't even have a SYN bit. There's no reason for an Arduino doing NTP requests to ever enable TCP support in the Wiznet. – Ben Voigt Sep 21 '21 at 22:29
  • Small devices are prone to DOS attacks if which can render them effectively unusable *while* they are being flooded with packets, but a properly-designed device which receives packets faster than it can process them will simply discard them (it may sometimes be useful for devices which are close to being overloaded to send back packets requesting that the source back off, but a server should be prepared for the possibility that packets may arrive faster than it can NAK them (in which case they should be discarded). – supercat Sep 21 '21 at 22:39
  • @BenVoigt There is more than one kind of flood attack. – Peter Wone Sep 22 '21 at 22:34
  • @PeterWone: But at the time you commented, you specifically called out a "SYN flood" attack. – Ben Voigt Sep 28 '21 at 17:02
  • @BenVoigt I was thinking about a particular case when I wrote it. You could have said "while the SYN flood attack does not apply to this particular circumstance the principle holds" instead of nitpicking. – Peter Wone Sep 29 '21 at 11:25