2022-10-31 I found a vulnerability in the Corinex CXWC-HD200-WNeH and I tried to report it
Somewhere between the digging in the Corinex CXWC-HD200-WNeH I found a vulnerability. A combination of a misconfigured network filter and a default account make it quite easy to get into the device and get full access. I tried to report this vulnerability before publishing about it. Timeline:
- 24 September 2022 I mailed a general address at Corinex about this
- 29 September 2022 I mailed someone who wrote about Corinex devices in the Netherlands
- 28 October 2022 I tried to contact @CorinexCorp on twitter via a mention
All this got exactly zero response.Update 2022-11-17: @CorinexCorp responded on twitter: Hi Koos. Apologies for a lack of response. Corinex no longer supports CXWC-HD200-WNeH devices. The company exited the consumer market many years ago. Because this device is out-of-support for years now and should not be in use anywhere anymore, I think I've invested enough effort in trying to report this vulnerability to the right people and I can now publish this and close this chapter. On to the actual vulnerability. Like a lot of other vulnerabilities this is a case of multiple things coming together.
The misconfigured network filterThe CXWC-HD200-WNeH is running a telnet server on port 32560. Attempts have been made to filter this telnet server so it can't be reached, as this port isn't allowed per the DEFAULT_INP filter, referenced from the standard INPUT filter. But since there is no DROP/REJECT rule or policy for this traffic this failes. Maybe the filtering on traffic not via the bridge should be doing this, but in bridged mode this isn't working.# iptables -L INPUT -n -v Chain INPUT (policy ACCEPT 19 packets, 9912 bytes) pkts bytes target prot opt in out source destination 3414 280K all -- * * 0.0.0.0/0 0.0.0.0/0 3414 280K all -- * * 0.0.0.0/0 0.0.0.0/0 3414 280K ISAP_INP all -- * * 0.0.0.0/0 0.0.0.0/0 3414 280K DEFAULT_INP all -- * * 0.0.0.0/0 0.0.0.0/0 # iptables -L ISAP_INP -n -v Chain ISAP_INP (1 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:161 0 0 ACCEPT 2 -- * * 0.0.0.0/0 0.0.0.0/0 # iptables -L DEFAULT_INP -n -v Chain DEFAULT_INP (1 references) pkts bytes target prot opt in out source destination 3284 260K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 223 13380 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 36 4320 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- !br0 * 0.0.0.0/0 0.0.0.0/0
The default accountOne of the things I type when confronted with a login prompt on a device under test is username 'admin' and password 'admin'. This works on this device.$ telnet 10.10.1.253 32560 Trying 10.10.1.253... Connected to 10.10.1.253. Escape character is '^]'. login: admin Password: BusyBox v1.12.1 (2012-08-22 10:19:32 CST) built-in shell (ash) Enter 'help' for a list of built-in commands. #
ConclusionThese two things together cause a vulnerable situation: in a holiday park you don't want the visitors to get full access to the configuration of the network router.