Introduction
An internet edge router is the device which provides your network with its ‘window on the world’. An adversary who has control over this equipment is in a particularly privileged position to affect the security of your network. Certain attacks that are very difficult over the internet become extremely easy when launched from equipment on your network edge.
Though organisations of almost any size may have internet facing routers, this guidance is aimed specifically at larger, enterprise-level installations.
Your ISP might manage these devices or you may handle things in-house. Either way, if you suspect an internet edge router has been compromised, you must act immediately. Ensure that your traffic does not go through the compromised device either by reconfiguring your own systems or contacting your ISP to have them re-route your traffic away from that router. In extremis, disabling the router in-situ may be preferable.
This document details how to determine whether your router is vulnerable, and the potential harm that could come from such a security breach.
How can I tell if my internet edge router is vulnerable?
This guidance is for enterprise class devices and services.
- Determine your external IP address or addresses
- Obtain an internet connection that is unrelated to your organisation
- Perform a full and complete port scan of your external IP addresses from the connection outside your network looking for both UDP and TCP services
- If, from the internet location which is not associated in any way with your organisation, any management services can be identified on your network device, the device should be investigated for potential compromise. The presence of inbound SNMP, telnet or HTTP services should cause the investigation to be a priority. SSH or HTTPS services which terminate on the router (e.g. are not being passed through to a device within your network) would also require investigation but as a lower priority.
- Your device manufacturer should have information available on how to assure the integrity of your device.
- If your internet facing router is managed by another party and you are able to identify any of the above protocols then you should contact your service provider.
Potential Impact
The potential impact of your internet edge router being compromised by a sophisticated adversary can be divided into the following five categories:
1) Compromise of non-secure protocols routed over the edge (e.g. HTTP, SMTP)
Many widespread internet protocols are not secure by default, so an adversary in control of your internet edge will be able to read and modify any traffic that traverses the edge devices using these protocols. This could lead to the loss and – potentially – alteration of information carried over these protocols. Altered content could have both business and security impacts which you should consider. The most widespread protocols in this space are SMTP for internet email and HTTP for (unsecured) web browsing.
2) Loss of Security policies/functions enforced at the edge (e.g. VPNs, IP whitelists)
If you rely on your internet edge devices to apply security enforcing functions, for example IP whitelisting, VPN termination or MPLS/VLAN labelling, then you should consider the impact on your systems if these functions failed. For example, if you have an IP whitelist, consider the impact of an adversary being able to bypass that function effortlessly. If you have a VPN that terminates on your edge device, you should consider the impact of the adversary having complete control and access to the data.
3) Man-in-the-Middle attacks against traffic routed over the edge (e.g. DNS, crypto, using your organisation’s public IP address externally).
Many protocols and security measures can be affected by a man-in-the-middle attack, which is trivially enabled by an adversary controlling your edge device. DNS is the most obvious protocol for which man-in-the-middle and man-on-the-side attacks are easy and useful, but certain badly configured cryptographic protocols can also be vulnerable.
The other major issue is where remote services whitelist your edge IP address. This would include your cloud service provider, for example. Obviously, an attacker with control of your edge devices can use your organisation’s public IP addresses at will.
4) Loss of enterprise metadata to attacker
An attacker with control of your edge devices can generate metadata around your organisation’s use of the internet. This includes what services your organisation uses and at what scale, plus who connects into your network. Everything from fully interactive services, through exposed APIs, to issues such as email relationships with external organisations (who emails whom) are at risk. Understanding whether there is any actual impact is, unfortunately, a matter for individual organisations.
5) Information (logs etc) provided by edge devices could have been false
An attacker with control of an edge device can obviously forge or modify any logs created by that device. If your security monitoring ingests logs generated by the potentially compromised device, you should consider what, if anything, would be uniquely identified by those specific logs and consider the consequences of failed detection should an attacker have modified those logs.
This document examines the impact of your internet facing edge devices being compromised. If the compromised devices actually form part of a site-to-site network (or similar) for your enterprise network, then the attacker effectively has a point of presence within your network that likely bypasses your edge security controls. There can be no generic advice in this case and you should seek expert advice in the short term.
Technical Details
Here we take a more detailed look at some of the possible outcomes, should your internet edge device be compromised.
This section is intended to give technical staff a rounded view of the problems they may face and suggest some courses of action. We therefore assume the reader has a reasonable level of technical knowledge.
Most of the attacks listed here are hard to achieve over the internet, but significantly easier if you own the first/last hop which also control the network’s view of the world in IP space. If you have an NCSC engagement contact already, they will be able to broker access for you to technical specialists if you need assistance. If you do not have an existing relationship with NCSC but feel that you have a situation we should be aware of, then please contact us.
1) Abuse of insecure protocols
If your internet facing router is compromised, it is possible for an adversary who has control of the device to trivially inspect, modify and redirect insecure protocols that traverse the router. While consideration should be given to all plain text protocols that traverse your internet edge, the following are likely to be the most common issues for enterprises:
Unless specifically configured to protect your email communications with other organisations through the use of TLS, your SMTP server will send and receive your external email in the clear. If your mail server is configured this way, you should have no expectation of privacy for your inbound and outbound external email traffic anyway.
However, access to your edge router allows an attacker to trivially inspect and copy at will any email traffic that is not otherwise secured (for example through S/MIME or PGP). You should consider whether any sensitive information has been sent unsecured over email (especially things like credentials) and, if identified, a mitigation plan should be put in place.
The NCSC strongly advises all organisations who run their own mailserver to configure opportunistic TLS for all SMTP connections as an absolute minimum. However if an attacker has access to your edge router and is particularly determined, they may be able to prevent secure connections from being established using this method. If you are concerned about this, you should check your mail server logs for increased levels of TLS negotiation failures.
NCSC email configuration guidance (aimed at government, but widely applicable) can be found here, and related TLS advice, here.
telnet
If you are using telnet outbound from your organisation to communicate with external devices or systems, you should immediately change all credentials on any devices being managed using this protocol.
While compromise of such systems does not require a compromised router, access to your edge router provides a single vantage point from which an attacker can watch and access credentials as they flow across the edge device. You should, if possible, consider using more secure protocols such as SSHv2.
If you are permitting telnet inbound to your systems, there are likely significant issues with the target system and any systems that can be accessed from it. It is highly likely that internal systems accessible via telnet from the internet will be compromised regardless. However, access to the edge router gives attackers a much higher fidelity picture of the network, access to credentials and a stable platform for conducting their attacks.
HTTP-only
Regardless of any router compromise, no sensitive information should be used with services that operate over HTTP only (i.e. no HTTPS). Any information entered into HTTP-only websites or services (including SOAP APIs, RESTful APIs etc) should be considered compromised, as should any associated credentials.
Again, compromise of the edge router makes it much easier and more reliable to perform these attacks than if an attacker is operating more remotely. Compromise of the edge router also allows an attacker to perform arbitrary injects into the HTTP protocol stream, for example to inject JavaScript, IFRAMEs or other elements to aid malware installation.
If your antimalware solution is modern and up-to-date, your browsers and endpoint OS are all modern and (on average) fully patched then there is only a small increase in risk over other forms of attack. However, you should consider a compromise assessment if you have concerns.
HTTP cookies will also be accessible to an attacker. These can be used for ‘auto sign in’ on some websites and access to these, along with the ability to generate traffic from your IP address space, gives attackers a potential for trivial masquerade of user accounts on these services, especially if your browsers are so old they do not respect a published HSTS policy. You should consider telling your users to log out (assuming they’ve used a ‘remember me’ function) and change their passwords on any websites they have accessed from systems behind any router you suspect may be compromised.
Time (NTP)
Many networks import a common time source from the public NTP pool. If you have systems that rely on wall clock time for security or correlation of events, you should consider investigating whether an adversary drifting the network clock could adversely affect your systems. This is likely to affect only niche systems.
2) IP spoofing
Obviously, an adversary in control of your internet facing router has control of your network’s view of the IP address space. While it is generally quite hard to run a full TCP session from a spoofed IP address over the internet, it is trivial to do so from your edge router, as the adversary can source any traffic from your external IP address and can inject traffic that appears to be from any IP address on the internet.
Therefore, if you have any inbound IP whitelist rules for traffic that traverses your internet facing router, you should consider the impact on the target systems as if the rules were not present (i.e. that anyone on the internet could route traffic to those systems).
There is an obvious corollary that any remote systems that whitelist the IP address that your internet edge exposes should be investigated as well.
3) DNS modification
An adversary with control of your internet facing device has almost complete control over your view of the internet as provided through DNS. If you record DNS responses as part of your protective monitoring solution, you may be able to use open source passive DNS sources to retrospectively discover if you have been served malicious DNS responses for A and AAAA records.
However, it is much more likely that network operators will be unable to discover retrospectively any malicious modification to their DNS traffic (for any record type). You should consider if you implicitly rely on the veracity of any non-A/AAAA records for any of your systems.
Spoofing A/AAAA records allows an attacker to arbitrarily redirect a user or system to a different destination to the one they intended. For users, this is probably best thought of as similar in effect to a successful spear phishing attack, although able to be performed at much greater scale and with much higher probability of success.
It is impossible to provide generic advice as to the risk of machine-to-machine protocols in the face of malicious DNS responses. A well designed M2M protocol would not rely on DNS as a security mechanism, but would instead rely on a cryptographic mechanism to authenticate the endpoints.
4) Cryptographic Man-In-The-Middle (MITM) problems
An adversary with control of your internet facing router has an excellent platform from which to perform man-in-the-middle (and to the extent necessary in this position, man-on-the-side) attacks.
It is impossible to provide generic guidance on every possible outcome, but we discuss below some of the more common issues that could happen. Network administrators should consider what other communications traverse the potentially compromised device and whether these could be affected in similar ways.
-
SSHv1
SSHv1 has a set of cryptographic faults that allow an adversary who can perform MITM attacks, to decrypt SSHv1 sessions. You should therefore consider all private keys and credentials used on SSHv1 sessions (inbound or outbound) compromised (whether the SSHv1 server keys and credentials, or the credentials used with systems behind the SSHv1 server). You should stop using SSHv1. Additionally, if a service supports both SSHv1 and SSHv2 then a downgrade attack is possible against the connection, forcing the use of the vulnerable protocol version. Really, stop using SSHv1.
-
SSHv2
While SSHv2 is not subject to arbitrary session decryption attacks, most usage of SSHv2 is open to server key replacement attacks. If you use SSHv2 (inbound or outbound), you should check all clients to ensure they have the correct server key fingerprint. An adversary could easily have presented replacement keys which, while giving a warning, most users normally accept.
If you find any instances of unauthorised server key fingerprints in your client caches (or you suddenly get SSHv2 server key change warnings when your router is replaced), you should consider all credentials used over that channel to be compromised and should move to mitigate that issue.
-
TLS
Some TLS ciphersuites are subject to relatively simple man-in-the-middle attacks. If you have systems, browsers or other clients which allow for rollback to SSL2, SSL3 or TLS1.0 you should consider the effect of the adversary having access to the unencrypted communications encapsulated in these protocols.
For more modern TLS protocols and ciphersuites, it is very likely that any certificate substitution attacks will cause a warning to users or an error code in automated clients. You should ensure that any automated connection code correctly handles errors and that your users have not been presented with certificate errors of late.
If your users have out of date browsers, it is possible that they would not be presented with errors in all cases. You should consider the impact of introspection by the adversary into TLS protected tunnels and consider proactively addressing any significant risks, even if there is not direct evidence.
-
HTTP, HSTS and HTTPS
If your end user browsers are not sufficiently modern to respect the HTTP Strict Transport Security (HSTS) header, or your users regularly use sites that do not request HSTS from their clients, there are a number of somewhat trivial attacks that the attacker in control of your internet-facing router could mount that would result in them having complete access to the unencrypted session – through a combination of forced HTTP fallback and some of the other techniques discussed in this document.
If your browsers do not support HSTS, or you have a corporate proxy that routinely breaks HSTS to the client, then you should consider informing your users that it is possible that their credentials, used on external sites protected by HTTPS, may have been compromised and they should consider changing passwords on those sites.
If you have proxy logs, you should be able to catalogue sites that your users regularly visit and determine if those request HSTS. If you believe you may be vulnerable in this way, you are almost certainly vulnerable to the cookie stealing attack detailed earlier.
If, via this router, you expose a webmail service (e.g. Outlook Web Access) to your network users which is accessible to arbitrary clients (i.e. not limited to managed machines) then you should assume that all your user mail credentials on your internal mail system are compromised and move quickly to mitigate this at the domain level.
-
VPNs
If you have VPNs which traverse the router, you should consider whether their configuration is sufficiently strong, given the privileged position the attacker has. Configuration guidance for IPSec VPN is available here.
TLS VPNs are proprietary in general, but good practice for TLS configuration using modern protocol and ciphersuites, along with good certificate management (considering the appropriate root CA) should ensure that it is hard to perform an undetected MITM attack.
5) In band management protocols and other high impact protocols
If you use in band management protocols across this router – whether standards based or proprietary – you should consider the credentials used and the integrity of the managed devices to be compromised, unless you have independently verified the cryptographic protections on the protocol in question. If you have insecure protocols tunnelled over security protocols (e.g. SSHv2, SSL/TLS, IPSec) then you should consider the implications of those protocols being compromised in ways described elsewhere in this document.
If you are running unsecured industrial control protocols or access to ICS systems over this router, you should consider the integrity of that control system compromised. Specific actions will depend on the precise nature of the system and the protocols involved.
6) RDP
If you expose an RDP (or similar, VNC, VDI etc) server to the outside world, you should ensure that your configuration is sufficiently strong and that your implementation is sufficiently up to date.
Older versions of RDP-like servers have been shown to have a range of security defects that could be leveraged by an attacker in such a privileged position. If you are running old versions that could be subject to timing, or man-in-the-middle attacks (including realtime proxy attacks), then you should consider all the credentials that could be used on this system as compromised.
Furthermore, if you allow administrative logins over this channel, you should consider the domain compromised. If you are using fully patched modern software with a relatively restrictive configuration that does not allow administrative logins, then this should not be a significant risk to you.
Note that this advice applies where you are exposing the RDP-like instance directly. The issues are different if it is tunnelled in a cryptographic VPN, provided the VPN does not terminate on the compromised router.
7) Any VPN terminated on the router
If you have any cryptographic VPN terminated on a compromised router, you should consider all the traffic it has passed as compromised and untrusted, as the adversary has the ability to read and modify traffic entering and leaving the VPN for no work.
As a minimum, you will need to replace all cryptographic trust roots, certificates and PSKs used. And it is strongly advised that you consider other members of the cryptographic VPN mesh to be similarly compromised. In this case, you should consider performing significant investigation into the systems at the end of the VPN tunnels.
Note that is different to the case where there is an independent VPN that traverses the router.
8) MPLS/VLAN tagging on the router
If you are relying on MPLS or VLAN tagging from this edge router, you should consider the separation and enforcement logic broken. An adversary with control of this router will be able to generate arbitrary MPLS labels on the external edge and add arbitrary MPLS labels to incoming packets from the WAN side.
On the customer side, any VLAN translation should be considered unreliable as the attacker can generate arbitrary 802.1Q tags on the downstream trunk. It is impossible to provide generic guidance as to the impact of this sort of attack as it depends wholly on the network architecture and trust model.
A good starting point for the academic exercise you should perform to determine your highest risk is to start with the assumption that all VLANs are collapsed into a single VLAN that will route to arbitrary endpoints and that all MPLS labels are collapsed into a single label that will route – via arbitrary MPLS VPNs.
If, as they are intended, your MPLS and VLAN implementations are used only for traffic management and are not deemed a security boundary, then this should not adversely affect the security of your systems. However, if you are treating these tags as security enforcing, you may wish to investigate additional security controls as appropriate.
9) Required learned routes
Your internet facing router will likely participate in route learning protocols as well as honour any static routing you have set. An adversary with control of your router can obviously change routing costs, add new static routes or add new GRE/VRF destinations.
If you rely on required routing for security, you should consider this broken and begin investigation into the potential impacts on the systems that rely on this. As a matter of urgency, you should move away from this as a security measure if you currently rely on it.
10) Metadata
Where your edge router is used as part of a large proportion of your business activity, the attacker will quickly learn how your business operates in detail, being able to see, at a minimum, metadata associated with all traffic transiting the device.
This will include websites accessed/hosted, internal network configuration and public IP addresses of external equipment which accesses or are accessed by the network. Consequently, an attacker could use this information to gain access back into the network.
Once remediation work has completed, you should re-assess the security of your network given this information. Should communications (email/VOIP) be in the clear at the router, the attacker will also have been able to extensively profile the people within your organisation. In this case, there could be a higher likelihood of attack via spear-phishing of key individuals (e.g. network administrators).
11) Monitoring, DPI and Logs
If your internet facing router has been compromised, you can’t rely on current and historic logs, monitoring, or DPI provided by the router as being accurate.
Source: NCSC
