Few weeks ago, one particular large scale cyber-attack hit the mainstream news everywhere. Russian cyber actor APT28 attacked SOHO routers and managed to compromise some credentials through that. The attack itself was carried in multiple phases and was quite interesting. Let’s take a look at those individual steps, what happened, how it worked and what could have been done to prevent this type of attack.
Phase 1 – taking control of SOHO router
The attack begin simply by attacking SOHO routers with a single goal – changing the address of the used DNS resolver. Result of this phase, if successful, wouldn’t be that easy to detect. People could still connect to the Internet and carry-on working from home as they always did. Nothing really suspicious. Might break some DNS based load-balancing for CDNs, but I wouldn’t expect that it would be that noticeable in the end.
One particular attack vector that is being talked about quite often is attack on TP-Link WR841N using CVE-2023-50224. This particular vulnerability made a headlines already last autumn. It was fixed in an update for some revisions of the router. But even back then, the main concern was that there were plenty of devices that were out of support and has been still actively used (and some shops still had them in stock) and at the same time there were plenty of devices, that even though the fix for them exist, weren’t updated.
This highlights why SOHO routers were targeted. In business environment, you have an IT department that makes sure, that your infrastructure is still supported by a vendor and that the latest patches are always applied. At home, people don’t pay that much attention to it. Especially in the router segment. They notice when their phone gets sluggish and they replace TVs for a bigger ones with higher resolutions. But router? It is some box, out of sight, happily blinking and providing the internet. And while it does it’s job, nobody pays attention to it. Nobody cares how old it is and nobody checks the updates regularly.
Off-course, having outdated and vulnerable firmware is not the only way how to invite an attacker to your home. There are other miscon figurations that help as well. Like keeping the default password or opening the web interface of the router to the internet. But just firewall might not be enough. The original CVE was exploited even by using malicious javascript running inside a browser of some device within the local network.
How to stop attackers in the first stage?
In theory it is simple. And could be easily prevented or at least the number of affected device could have been greatly reduced.
Make sure your device is still supported by your vendor.
Even in the report from the last autumn, big part of the discussion was that it was affecting routers that were still sold in some shops but at the same time were out of support by their manufacturer. With upcoming CRA this will hopefully improve. Every device sold in EU will have at least five years of security updates guaranteed. And when expected use is longer, it should receive updates for even longer time period. But CRA is not in the effect yet. In the meantime, check your devices and whether they are still supported by your vendor. If not, it is best to look for a new device. Ideally something with a long term support. If your device is Turris, you don’t need to check, we still support everything we ever manufactured 😉
Make sure that it is up to date.
Taking care of updates is bothersome but important. That is why we decided to do automatic updates more than a decade ago when we started making Turris routers and why we encourage people to use this feature. If you don’t have a Turris router, you might be forced to check and apply updates manually. This is bothersome and people tend to forget about it. But luckily, nowadays there even some non-Turris routers that support automatic updates.
So next time, you will be shopping for a new router, check for how long it will be supported and whether it has an option to enable automatic updates.
Don’t use default passwords or defaults in general.
When I was young, when you scanned for available Wi-Fi networks, you frequently found SSIDs with various vendors names. Some of them even were password protected, but I would bet that most of the protected ones were protected just because a vendor provided a default password. Nowadays, situation got much better. People realized, that sharing your Wi-Fi with whole neighborhood doesn’t make it faster. But still, when you are in a small hotel or some BnB, you frequently find open web administration interface and I would bet that admin/admin credentials would succeed quite often. You can see that the default credentials are quite often among the top ten in Turris Sentinel View.
To conquer this bad habit, when we were designing Turris, we made sure not to have a default password and not to let people online till they set some of their own. Because if you unbox the router, plug it in and everything just works without setting anything up, it is nice and convenient, but probably not that secure.
Apart from passwords, even setting router IP to something else than 192.168.1.1 might also make it harder for attackers to target the device. As the previously mentioned JavaScript attack targeted specifically this IP address.
Limit access to the admin interface.
Even low-end routers nowadays support guest Wi-Fi. Enable it and use it for devices you don’t trust. Never open the admin interface to the Internet. If you need to manage your router remotely, setup a VPN. It could be quite bothersome, but again, in Turris, we tried to make it as simple as possible.
Phase 2 – forwarding DNS requests and spying
When attackers took a control over the home routers, the only thing they did was forward all DNS traffic to their resolvers. Internet still worked, everything is encrypted nowadays, so it doesn’t sound that problematic does it? Well, the tricky part is, using somebody’s DNS resolver, you are basically giving them a big part of your browsing history. They don’t see individual web pages, just the server names. But even that could be quite sensitive. Especially if you give those information to the group of attackers looking for the most vulnerable victims.
We use DNS requests and TLS handshakes in our NetFlow monitoring solution Pakon, that can be easily enabled on our Turris routers. You can give it a try and see, whether you would be comfortable with sharing all those server names with somebody who wants to take an advantage of you.
In typical scenario, your ISP has all that information at his disposal. If you want more privacy, you can use for example DNS over TLS and one of the open resolvers that are available on the internet. Then those providers will have your browsing history and you can decide, whether you trust with your data companies like Google and CloudFlare or Quad9 and CZ.NIC.
Phase 3 – MiM attack
Once victims were identified, Man in the Middle attack was performed. Basically once the attacker has a control over your resolver, he can pick interesting domains and resolve them to IP addresses under his control. This way, the attacker doesn’t need to be physically in the middle, doesn’t even need to be anywhere close. And he can also easily pick only the interesting services. The rest of your internet would work fast without any interruptions. Similar approach is actually used by various DNS based security solutions to display you an error message when you are trying to navigate to a problematic site.
Can you protect yourself from such a type of attack in case your resolver contains falsified records? Sure, there is a technology to solve that – DNSSEC. Turris routers have DNSSEC enabled by default so even if forwarding to malicious resolver, it wouldn’t be possible to modify records for DNSSEC protected services and you wouldn’t be led to the attackers site. On top of that, if the resolver you are using is falsifying the records, you could just enable full blown recursive resolver and not rely on a third party. But those features are unfortunately rarely implemented by other vendors.
Other option how to ensure you validate DNSSEC is if you are using Linux and systemd like most of the distributions out there. You can force the use of DNSSEC by modifying systemd-resolved settings and using systemd-resolved to resolve DNS queries. In the same daemon, you could also force the use of DNS over TLS to avoid the simplest way of being spied on or define a set of resolvers to use (or to use as a fallback).
You can see bellow the example of configuration that you can put into your /etc/systemd/resolved.conf.d/dns-tweaks.conf configuration file. It ensures DNSSEC is used, tries to use DNS over TLS whenever possible and falls back to ODVR.
[Resolve] DNSSEC=true DNSOverTLS=opportunistic FallbackDNS=193.17.47.1 185.43.135.1 2001:148f:ffff::1 2001:148f:fffe::1
Phase 4 – credentials gathering
So far you have seen how sneaky the attack was and you are probably expecting (as I did) a grand finale. Unfortunately, the reality is much more mundane.
In the end, the attackers managed to steal some credentials, targeting mainly Outlook accounts. They did it through the Man in the Middle attack mentioned in Phase 3.
When I heard about that, I was really curious. Today, TLS is the norm and every decent site (including Outlook) uses HSTS. And with those technologies in place, it is really hard not to notice that something fishy is going on. With HSTS I found it really difficult to ignore TLS errors when I broke a web server setup on my own server. So how did they do it?
(Un)fortunately, they just relied on people being persistent, ignoring the warnings and sending them their credentials anyway 🤦 Because in security, you have to be vigilant all the time, but attacker has to catch you off-guard only once. And even though modern systems do their best to warn you, that sending your credentials to a site with invalid certificate is not a good idea, people do it anyway.
Conclusion
We have seen how the attack started and how did it progressed. Is there a technology that could have helped? Yes. Making sure people have still supported routers and installing latest updates would greatly reduce the initial impact. Using DNSSEC on the client devices would have prevented the Man in the Middle attack. Those were the corner stones of the Turris router development. But in the end, for the last phase, there was a technology in place that should have prevented the attack from succeeding and it didn’t failed, but the end users worked hard enough to ignore all the warnings. So yes, technology could have helped a big time, but in the end, the most vulnerable piece of the puzzle is the person behind the computer.