Is dropbear SSH server in OpenWrt vulnerable to Terrapin Attack?
If so, is a patch coming? What are the instructions for configuring dropbear ssh server to prevent attacks by disabling hacha20-poly1305@openssh.com encryption and -etm@openssh.com MAC algorithms?
The SSH vulnerabilities are tracked as CVE-2023-48795, CVE-2023-46445 and CVE-2023-46446.
a) On the very page you linked, a tester for the vulnerability is provided. Did you try?
b) Unless your SSH is open to the Internet (and if so, why?), do you have a massive concern about the nature of the vulnerability? Again, from the page you linked, unless you are a state agent or member of a sleeper cell, I don't think it's worth losing sleep over.
Yes, dropbear in OpenWrt 23.05 is version 2022.82, and the paper specifically mentions that the attack works on 2022.83.
Dropbear does not have runtime configuration switches to enable or disable specific algorithms. You would need to do a custom build, which at that point you might as well implement OpenSSH's kex-strict protocol.
Fortunately, while this is a serious bug that needs to be fixed (and it will), it's not a catastrophic bug that requires emergency patches. From my first reading of their paper:
In my opinion, the easiest to preempt this attack right now in OpenWrt 23.05 while keeping the existing Dropbear install is to tunnel SSH over a Wireguard tunnel. Wireguard (an instantiation of the Noise protocol framework) authenticates the entire handshake. If you're worried about active MitM in your local network, then you can deploy an overlay network with Wireguard specifically for management protocols like SSH. These are all good ideas to implement in any case.
Otherwise, wait until Dropbear gets patched or temporarily replace with OpenSSH 9.5 and configure accordingly. If you want kex-strict then you can cross-compile 9.6 yourself or wait until OpenSSH 9.6 is available with opkg.
I ran the tester against my install, its vulnerable.
SSH is usually safe enough to expose-that a MITM is this rare illustrates why. Probably worth fixing to be safe.
Unless you're targeted, though, this really shouldn't affect you.
Having read the summary of the Terrapin attack, I concur with the other viewpoints shared here. A reasonable person would agree that SSH should not be facing the Internet (and long before this announcement). I also confirmed that 22.03.0 is vulnerable - specifically on the ChaCha algorithm. So yes, while vulnerable, I am not losing sleep over it (much like others have shared). Yes, the prudent thing would be to update when something viable is ready. In the meantime, like @elbertmai said, implement WireGuard and tunnel any protocol over that from the Internet.
Thanks everyone for the in depth analysis. Looks like the average home user should not need to worry about this vulnerability, and that this vulnerability is mitigated if using Wireguard VPN.
Could you explaint to me, why you think this way? I agree for dropbear, but I do run opensshd on a port different to 22 with a limited user on public key auth only and no shell access. This way I can have poor mans vpn with dynamic port forwarding / socks proxy. It is very useful in combination of a proxy switching tool like "foxy proxy" in browsers and if you user more than one it is way more flexible than an single vpn.
Would you consider this insecure compared to a vpn? I am just curious because I got no answer in a forum somewhere else...
I am not intimately familiar with that use case so I had to do a little reading.
Let me praise you on a few things first. Great job running on a different port - hopefully the number is high beyond popular scanning services. Second, you have restricted user permissions and the authentication method significantly and are reducing your attack surface.
I am not sure if you are proposing this for home or enterprise use. SSH daemons, as with any service (even WireGuard or listening on some port), are subject to vulnerabilities which would require prompt patching. And those vulnerabilities can vary from privilege escalation to shell access (regardless of what users you have established in the way you described), and (now) the vulnerability here with certain encryption schemes. And in this day and age, unpatched services are detected on systems within minutes (not hours or days). Shodan and Censys help with that. How quickly are you patching your home router or enterprise equipment? Flexibility/usability vs security is finding a comfortable balance. While the extension "Foxy Proxy" is useful to have within the browser, you are potentially preferring convenience and flexibility over security. It appears Foxy Proxy also offers a VPN and proxy service. If you use that, then there is a dependency there. How much trust do you have in the extension? Millions of downloads and potentially by admins to access systems - which makes it a great target to attempt to compromise.
Your question: Your approach is insecure vs. VPN? It is a great question, and I pivot back to the convenience vs. security discussion. One could look at bug/CVE history for certain SSH implementations vs VPN to help inform a decision. Or even what underlying libraries are used by each implementation (software supply chain). I don't know enough about your operational situation, where this is used, what you prioritize, or your risk appetite. 100% convenience means no security, and 100% security means no convenience (let alone value at all). That is why I said reasonable - reasonable people look at the risks, weigh the pros and cons of potential solutions, and most likely shy to the less risky option. We don't want headaches (especially on a home router scenario). That is one reason why we are seeing this "secure by default" initiative for consumer devices.
I went far and wide there so I hope this was useful.
Thank you for your detailed response, that helped me a lot! Yes, it is always coming down to minimize the attack surface. I am talking about private use - in enterprise use I would not use the easy approach.
Otherwise, if I run either ssh or vpn I am still exposing one service to the internet which can be vulnerable. IMHO the advantage of a vpn is that it is using udp instead of tcp. That makes the service more difficult to discover, as tcp port scans are easier.
That said I will stay with ssh for myself, restricting it to ipv6 only. The bigger adress space is not that easy to scan and the possible damage on my side is very limited.
Why, if I might ask? Until this attack SSH came out as pretty secure... sure one can do SSH over a VPN, but that a) still uses SSH and b) now one has one more piece to keep secure... (Wireguard for all its advantages is not universally usable, as it requires UDP and some users can only use TCP, so if one wants to maintain the capability to reach one's home network from around the world, wireguard seems less attraktive than OpenVPN, but that has a larger attack surface).
There are dragons... IPv6's larger address space can help in that it allows for better randomization, but IP addresses can leak, so one should not consider that as a sole means of security...
That is not my only effort to have a good configuration, but you are right, if it was it would be dangerous. I can say my log files do not show any attempts of brute force bots anymore. Before (1-2 years ago) that was different although I had a high 5-digit port. So I consider this as an useful additional / ice caking defense. Not more but not less.
I agree with you - can't use the IPv6 address space as a security control.
CVEs for SSH: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ssh ; 956. Yes, I realize there are multiple vendors in this list, and yes, I realize SSH has been around a long time (1995).
CVEs for WireGuard: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=wireguard ; 11. Yes, it is a newer service than SSH and OpenVPN by decades.
CVEs for OpenVPN: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openvpn ; 118. Originally released in 2001.
To be clear, I am not referencing this information exclusively to make my point. But such information should feed into a decision making process about risk. One could look deeper and assess if the number of vulnerabilities are increasing each year for each service or not. EDIT: Yes, you can parse out the severity rating of each and do comparisons there. Lots of other ways people smarter than me can recommend. But that is the beauty of information - you can use it to make informed decisions.
I am not familiar with why some users can only use TCP (is this by some policy established by themselves personally or an enterprise?). I believe that there are plenty of other services which use UDP which are necessary to have a useful system whether solely connected to a LAN or the Internet. Perhaps I misunderstood your point there.
Most govt and commercial organizations I am familiar with stay away from OpenVPN or WireGuard in general - so perhaps that factors into my perspective on this. Those services can be reserved for home users and tinkerers, whereas enterprises will use Cisco, Palo Alto for VPN. They concluded it is lower risk to go with a commercial vendor vs. open source. Maybe this will change in the future based on risk, cost, impact, etc. EDIT: I see OpenVPN has support services now. My point is still there - I have not seen OpenVPN used in the work settings I have been in.
I can't speak for the whole world, but when I use WireGuard at Wifi hotspots, I don't have issues a majority of the time. If I do have an issue, LTE/5G works great. I am honestly trying to see this from your perspective and the conditions and constraints that exist within your environment.
Perhaps I went too far speaking to what I thought a reasonable person would do. It was merely my opinion based on my experience. I hope I have supplied some information sheds light on how I arrived there.
I have seen both OpenVPN and WireGuard in the corporate setting.
In 2008, OpenVPN was used at Yandex (a company with thousands of employees at that time). Source: I worked there.
Regarding WireGuard, unfortunately, I still have an active NDA that prohibits me from mentioning who used it.
The most reliable way is to disable the dropbear service in autostart, when you need to turn it on, do what you need to do and turn it off 
Some ISPs throttle high rate UDP flows (for understandable reasons, UDP can be address spoofed and is often used for DDOS attacks). Some firewalls di not allow UDP traffic at all (only specific things like TCP port 80).
The simple reason SSH is worse to expose than VPN is resulting damage from breach.
Should someone breach your VPN entry point, in the worst-case scenario they have a presence on your (potentially restricted) VPN LAN subnet. This is not ideal, but certain assumptions are made that devices on said LAN are also at least somewhat protected from direct intrusion.
Should someone breach your SSH connection, on a normally-configured instance of OpenWRT, they have root shell access on your primary network gateway.
I think it follows rather easily why the latter condition is orders of magnitude more dangerous than the former.
SSH is designed to run arbitrary commands remotely (as the logged-in user). Obviously that's the whole point of the protocol, so that administrators can actually manage the servers under their care. But it does mean that a SSH break-in can have more serious consequences than other types of services, like a web server that hosts a blog made up of static webpages.
So a defense in depth argument, an attacker now needs to break both the VPN and SSH... fair enough.
For me there are basically three reasons to favour a (wireguard-) VPN over direct ssh access, in a belt and suspender approach.
Whenever I do see questions about this, it's typically combined with the follow-up intention of ssh tunneling/ proxying - and that really should be a thing of the past (15+ years ago at least). Don't get me wrong, it works, done properly (and this aspect is harder than it looks) it's also secure (at least if you're the sole user), but a VPN is just so much easier and convenient for these use cases (there may still be reasons for ssh tunneling in case of hostile ISPs actively trying to prevent VPN pass through).