1

How can malware or a hacker penetrate a firewall in a router/AP or a dedicated firewall without "help from the inside" (running malicious script on a computer, forgotten open ports with port forwarding, configuration mistakes etc.)? Should I be afraid of external devices before my router (like my colleagues in my work, neighbors in an apartment building or in a dorm)? And how should I protect?

My thoughts:

  • You can trick a simple stateless firewall to accept an incoming connection (Prevention: Firewall should have stateful packet inspection like e.g. Mikrotik.)
  • Administration/ssh connection to the router available from outside. (Prevention: Should be turned off/blocked.)
  • UPNP (Prevention: Should be turned of if not necessary.)
  • Man in the middle attacks allowing to manipulate incoming data (Prevention: use only https pages/services or VPN.)
  • Exploiting known vulnerability in a router (Prevention: Use device from a vendor providing updates and update the device.)

...about the last one. From what I've read it looks like that vulnerabilities allowing to directly penetrate the dedicated firewall/firewall in AP from "outside" are extremely rare and most attacks from external perimeter are DDoSes. And that malware or even hackers usually breach the network security from inside the LAN. Is this assumption correct?

Improve this question

1 Answer 1

Reset to default
3

You've broadly covered it. However, I want to highlight a few points.

First of all, it's not just "forgotten" open / forwarded ports; lots of software needs to act as a server at least some of the time (game server hosting, file servers, SSH/RDP/VNC servers, web servers, etc.) or at least might work better if it can (bittorrent and other peer-to-peer transfer software, Skype and other communication protocols that prefer to establish direct links rather than relaying over a server, etc.). This isn't necessarily insecure - those servers can be authenticated, hardened, use secure protocols, etc. - but a lot of them aren't (game servers are often terribly insecure), and even in the best case, it does offer attack surface behind your firewall.

Second, you note but largely dismiss malicious traffic coming from servers back to your clients. This is a mistake; TLS and VPNs aren't used for everything and don't fully solve this problem anyhow. A few things to consider:

  • The server you're connecting to might itself be malicious. No need for an MitM if I (the attacker) control e.g. an ad server and you visit a webpage (over https) that tells your browser to make a request to my server (over https) and run the script it retrieves. That script could cause your browser to make network requests from inside your firewall. CSRF, essentially, but not necessarily targeting other websites; it could instead attempt to exploit local HTTP/HTTPS listeners on your network, even your router's internal administration portal, or just port-scan your host and network.
  • Same idea as above, except the content I return could be even more malicious than that. 0-day vulnerabilities in browsers' JS engines, media parsers, and so on can all happen. Browsers are sandboxed to limit the damage, these days, but it could still potentially get me code execution on your machine even if only with minimal permissions.
  • Your SSH/TLS/VPN client code is itself attackable. Either as a malicious server or a man-in-the-middle, I can attack your client via malicious handshake response data or side-channel data. Remember Heartbleed, way back in 2014? It was mostly known as an attack against servers, but a server (or MitM) could use it to attack clients as well, stealing all the data out of their process memory heap too.
  • Lots of stuff doesn't use TLS or VPN or other secure protocols, at least not always. DNS is now sometimes over HTTPS (which is over TLS), but that's not the default configuration and lots of machines/software don't do that. Software package repositories (classically things like Linux .deb or .rpm repositories, but also other things like perl, python, node, .NET, etc.) don't always use TLS, relying instead on the packages having trusted signatures on them to ensure they're correct... but the code that parses that package and verifies its signature could be vulnerable too. Some services still use telnet, FTP, and other unsecured protocols. A lot of POP/IMAP/SMTP email clients still use unsecured connections by default, possibly upgrading to TLS only if the server says they should; a MitM can launch essentially an SSLStrip attack on that process.
  • Your firewall won't save you if the legitimate response to your request is malicious. A supply chain attack could cause npm to download a malicious package, which will then execute on node, gaining full control over that process. As far as the firewall can tell, though, everything was legitimate; you made a connection to a server (even over HTTPS), got a response (encrypted) from that server, and maybe closed the connection; no funny business.
Improve this answer
6
  • CBHacking: Impressive! Thank you for your answer! I would like to put aside requests to evil/tampered servers, browser vulnerabilities and forging package signatures for a while to keep it simple: Lets assume we have a common SoHo router like Mikrotik with default FW enabled. And a computer in LAN - powered on, but not running any services like auto-updates, web/file etc. + nobody is using a browser. Can someone directly penetrate the router from WAN (e.g. by using some exploit on a router's firewall) and change its setting or attack the computer in lan?
    – M_Ryan
    Commented Mar 14, 2022 at 18:53
  • (fyi I'm trying to understand what threats may be waiting outside my network and whether an ordinary Mikrotik's/similar SoHo's firewall can stop it at all - or if I have to use some special and smarter device with advanced packet filtering and so on. I was reading some CVEs and it looks like that almost all router vulnerabilities begins from an infected computer/other device in the LAN, not from the external perimeter. Sounds weird to me, are routers really so unbreakable nowadays...)
    – M_Ryan
    Commented Mar 14, 2022 at 18:54
  • Without addressing individual products (which I neither own nor have the time to perform a thorough pentest of), and assuming a fairly default settings (which do vary between SOHO routers but usually not by too much) plus the changes mentioned above (e.g. disabling UPNP), you're probably pretty safe. Part of that is that rejecting unsolicited inbound TCP traffic is easy (UDP is harder), and you're not generating any outbound requests. Part of that is that routers now mostly don't run external listeners by default. It is not, given those constraints, a hard problem.
    – CBHacking
    Commented Mar 15, 2022 at 8:51
  • However, I also want to be clear: that router firewall could well not be doing anything useful security-wise. Using NAT with absence of port forwarding is sufficient to prevent inbound traffic in the typical default router setup. The router must do some parsing of the incoming IP packets but not very much; it's generally easy to do safely. Obviously you shouldn't simply assume any given parser (or other attack surface) is safe if the security is very important, but in practice, basic router functions are in fact almost always secure.
    – CBHacking
    Commented Mar 15, 2022 at 8:57
  • In fact, the router might not even be needed. If a PC isn't listening for any external-network requests, and isn't generating its own external-network requests, it might not be vulnerable either. Lots of software listens on all interfaces without any need to do so, and that's bad, but a software firewall can prevent that (or you can simply not run such software / run it in a virtual network space and not forward traffic to it from the real interface). Software firewalls are of course also attackable, but I'm only aware of one example, over a decade old, of a firewall being exploitable.
    – CBHacking
    Commented Mar 15, 2022 at 8:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .