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.

3
  • 3
    If all you want is time synchronisation, perhaps receiving an entirely passive clock source (e.g. the UK's MSF Signal or its local equivalent, or just GPS) would minimise the attack surface?
    – eggyal
    Sep 20 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 at 6: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 describes, only using a networking library.) Sep 21 at 15:08
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.

8
  • 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 at 8: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 at 9: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 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 at 13:44
  • 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 at 15:57
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.

3
  • Would the UDP packet flooding work if I'm not implementing a webserver in software? It's only a client. Sep 20 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 at 4: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 at 4: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.

6
  • 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 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. Sep 20 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 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 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. tf.nist.gov/tf-cgi/servers.cgi . NIST offers the NIST Authenticated NTP Service as well (nist.gov/pml/time-and-frequency-division/time-services/…) but I don't think that would be worth the hassle for a normal home IoT device. Sep 20 at 23:40
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.

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.

-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.

5
  • 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 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 at 22:39
  • @BenVoigt There is more than one kind of flood attack.
    – Peter Wone
    Sep 22 at 22:34
  • @PeterWone: But at the time you commented, you specifically called out a "SYN flood" attack.
    – Ben Voigt
    Sep 28 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 at 11:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.