Reverse engineering
Netis WF2416: a router with an unexpected backdoor
A November 2017 look at the Netis WF2416: accessible Telnet, the Netis/Netcore backdoor on UDP port 53413 and recoverable administration credentials.
The Netis WF2416 I examined offered more access than a router owner should expect: an accessible Telnet service, a working backdoor on UDP port 53413, and recoverable credentials for the web administration panel. The Netis/Netcore backdoor had already been publicly reported in 2014, making its presence in this November 2017 investigation particularly frustrating.
Quick answer
- My WF2416 investigation found Telnet access and a working instance of the documented Netis/Netcore backdoor.
- The backdoor uses UDP port 53413. It is a separate service from the usual Telnet connection on TCP port 23.
- Access to the router's operating system also exposed the username and password for its web administration panel.
- Earlier public reports establish a wider firmware problem, but this observation does not prove that every Netis model or firmware revision is affected.
- A useful fix must address the exposed services and backdoor behavior, rather than relying only on a new administration password.
A small router with more than an extender feature
I started with the Netis WF2416, an inexpensive router that can also serve as an extender. That is an appealing use for a small network device: extend coverage without buying a more elaborate setup.
The security review quickly became more interesting than the feature list. Alongside its normal management interface, the device exposed Telnet and the backdoor associated with the Netis/Netcore firmware family. Netis is the international branding associated with Netcore, the name used in China.
Using publicly available information, I was able to make the backdoor work on the device I examined. After gaining access and exploring the operating system, I also found the credentials for the administration panel. Those are the concrete observations behind this article.
My notes do not record an exact firmware build or hardware revision. That limits how precisely another owner can map this result to their device. The product name identifies the router I examined, but it cannot replace a firmware version when determining whether a particular unit has been repaired.
Telnet and UDP port 53413 are different findings
Telnet provides an interactive terminal connection. On a router, that can expose an operating-system interface with capabilities beyond the settings visible in a browser. Its ordinary traffic is unencrypted, including login exchanges, which makes the network path relevant even when a password is required.
The backdoor discussed here is a separate listener on UDP port 53413. Treating the two as the same service would make remediation confusing: closing Telnet does not demonstrate that the UDP listener is gone, and filtering the UDP port does not establish that terminal access is disabled.
The broader risk was already documented before my investigation. Trend Micro's research on home-router security describes a Netis/Netcore backdoor reported in 2014 that allowed commands to be executed through the WAN side of affected routers. It also discusses subsequent firmware changes that closed the port while leaving backdoor code present.
That history matters, but it needs to be kept separate from my own observations. Finding access on my device does not establish which interfaces exposed it in every operating mode. A complete assessment would check the local and internet-facing sides independently and record the active configuration.
Why an old disclosure still matters in 2017
A vulnerability does not disappear from installed hardware when its disclosure stops being news. Owners may never receive an update notification, may be unsure which firmware matches their hardware, or may keep using a device because it still performs its everyday job.
There was already evidence of continued exposure after the original report. In its October to December 2015 monitoring report, published in February 2016, JPCERT/CC described scanning for Netis/Netcore devices on UDP port 53413. It noted that a firmware update had been released in 2014 while apparently unpatched devices remained connected.
The SANS Internet Storm Center reported a surge in exploitation attempts on August 4, 2016. Its analysis connected the traffic to the same backdoor and described attempts to execute commands that downloaded malicious files onto routers.
Those reports explain why revisiting the issue in November 2017 is useful. My WF2416 observation belongs to an existing problem with deployed devices, rather than a claim that I discovered a new vulnerability. It also does not justify saying that all Netis routers are vulnerable: firmware changes and differences between models need to be accounted for.
The administration password was inside the device
Once I could navigate the operating system, I found the username and password used by the web administration panel. That turns an internal management detail into another consequence of the initial access.
A web login form only protects the path that goes through it. If another service permits access to the underlying system and its stored configuration, an attacker may obtain the same credentials without ever guessing them at the browser login page.
This also changes how a password reset should be evaluated. Replacing an exposed password is useful after the access path has been addressed. If the backdoor remains usable and the replacement credential is stored in the same accessible place, the reset alone has not restored control.
The observation does not establish everything an intruder could retrieve or change. My original review demonstrates access and credential recovery; it does not document intercepted browsing sessions, modified DNS settings or a persistent implant. Those possibilities should not be presented as events that occurred during this investigation.
What a meaningful repair needs to establish
For this device, I would want a repair to answer several specific questions. Does the replacement firmware remove or disable the backdoor? Which interfaces can still reach management services? Is Telnet needed, and can the owner disable it? Do those changes survive a restart?
The model and hardware revision should be checked before applying firmware. After an update, the device needs to be reassessed in the mode actually used, including extender mode if that is its role. A setting in the web interface is evidence of intended configuration; observing which services remain reachable checks whether that intention is reflected in behavior.
If a satisfactory repair cannot be established, the device should not remain a trusted boundary for a home or office network. Restricting access through other equipment may reduce exposure, but that arrangement still needs to account for the router's local-network connections.
For manufacturers, the request is straightforward: ship management features that owners can understand and control, remove hidden access paths, and document security fixes against specific hardware and firmware releases. A router can work perfectly as an extender while still failing those requirements.
This investigation reflects my interest in looking beneath a device's visible interface and checking what its software actually permits. More of my independent technical projects are available in my selected work.
Frequently Asked Questions
Does this prove every Netis or Netcore router is vulnerable?
No. My observation concerns the WF2416 device I examined, while the historical reports cover a broader set of affected firmware. A reliable assessment of another router requires its hardware revision, firmware version and network configuration.
Is the backdoor on the Telnet port?
No. The documented backdoor uses UDP port 53413, while the usual Telnet service uses TCP port 23. They need to be checked separately because disabling one does not prove the other is inaccessible.
Does a strong web administration password solve the problem?
A strong password helps protect the normal login, but it does not remove a separate backdoor. In my investigation, operating-system access also revealed the administration credentials, so the underlying access path needs to be addressed.
Is using the WF2416 as an extender enough to make it safe?
Extender mode describes the device's network function, not a verified security boundary. Exposure depends on which services are running and which connected systems can reach them. Those conditions need to be checked in the actual installation.