Does the frontend crash after a malicious scan of ports?

[ethanjli]

After letting my frontend run on the Raspberry Pi a long time, the frontend may crash. It fails with a bunch of the following error messages:

What's happening is that something is trying to access some really weird URLs in the frontend: "/boot.ini" and "/etc/passwd". Since my RPi has not been locked down (i.e. its wifi connection is enabled and I didn't do any security configuration related to its internet connection), this seems likely to be some kind of attacker trying to see if my RPi's port 3000 (where the React dev server runs the frontend when I call yarn start) is exposing filesystem access. The sequence of unprintable bytes is: "%f8%80%80%80%ae%f8%80%80%80%ae", which is repeated with / as a separator. This looks like garbage, and the fact that the bytes are repeated doesn't seem like an attack which would break a Node.js server handling untrusted inputs (though maybe it could break something else?); when I did a google search, only two results showed up, both of the same email thread from the Linux mailing list fa.linux.kernel , where it's provided just as an example sequence of bytes in a discussion about how UTF-8 single-byte sequences might be rendered. If I instead search this sequence in hex formatting (\xf8 instead of %f8), I get two results: one is an error log which is apparently published online from some obscure company (seems like a security hole to me), where a server running phpMyAdmin reports that a client in 2017 tried to access a bunch of invalid URLs all within the same second but was denied: \xf8\x80\x80\x80\xae\xf8\x80\x80\x80\xae, Documentation.html, phpinfo.php, etc. The other is some anonymously-uploaded pcap recording in 2018 named "challengeCopy.pcap" generated by the "Acme Vulnerbilty Scaning Service" (including those spelling errors) which tried to access the same URL I in the error message from my RPi: "<\/\xf8\x80\x80\x80\xae\xf8\x80\x80\x80\xae repeated a bunch of times>/boot.ini". If I search "Acme Vulnerbilty Scaning Service", I get just 4 results, one of which is this previous search result, and the other three of which are duplicate results (on different paginations) of a single yolo.pcap file submitted in 2019 to the "MyCERT Pcap Analyzer" hosted by "The Honeynet Project", which appears to be a security research organization running honeypots. In the log for this file, it seems that the "Acme Vulnerbilty Scaning Service" is trying to access a very large number of different files, including the boot.ini as one of its first files (see the HTTP tab of https://pcap.honeynet.org.my/v1/submission/view.php?id=1725&dp-7-page=6&dp-2-page=1&dp-1-page=8).

From this investigation, it seems pretty clear that my RPi was attacked by a scanner (which has not been publicly described or reported) which tries to access a very large number of URLs to try to find vulnerabilities. This is a great warning sign that if we ever do open up any of our ports for remote access to the ventilator, we will need to add strong security protections, or else the frontend will be subject to attacks from the internet.

In this case, I don't have a very strong explanation for why the frontend would crash if a remote attacker tried to access a forbidden route. When I try to run wget localhost:3000/static/%f8%80%80%80%ae, the React dev server reports the same URIError but the frontend doesn't crash. It's certainly possible that the events are actually independent - that even if there is no attacker, the frontend might still crash after a long time. I'll have to continue trying to run the frontend for a long time to see what happens - next time I'll turn off wifi to remove that variable to see whether I can reproduce the crash, and I'll check to see if the Chrome DevTools console reports anything.

[ethanjli]

Solution to the port scanning problem: if we ever open wifi, we should close all ports to the outside world. If we ever need to make the frontend and/or the backend's websocket available to the outside world, it may not be enough to use a non-standard port (maybe even randomizing upon each run of the deploy script, and displaying it in an obscure place on the settings page for the technician to access) - this attack happened on port 3000. However, to protect against port scans, we would need to add port knocking. Wikipedia lists disadvantages of certain kinds of port knocking implementations, which we could use to help select a good implementation.

Note that if we open ports to the outside world, we'll need to consider two different kinds of threats:

• Random attacks like general scans of ports of IP addresses, where the attacker doesn't know what's behind the port. Port knocking based on a globally-shared secret would provide enough protection against this, and it would simplify administration.
• Targeted attacks where the attacker is trying to interact with the pufferfish backend and/or the web server hosting the pufferfish frontend. In this case, secrets should not be the same across machines - they should be randomized on each run of the deploy script, and a person would need to already be able to open the settings screen on the ventilator in order to see the secret. If we're trying to protect against this kind of attack, we should also have other defenses (e.g. application-level authentication for remote access) beyond port knocking.

[ethanjli]

For now, as part of defense-in-depth we should add some functionality to our deploy_lock.sh scripts to close all ports to the outside world, even though we're also disabling wifi. In that script we should probably also add some comment about the need for port knocking if we ever open up a port to the outside world, as well as linking to this issue on things to consider before opening up any port to the outside world.