News archive October 2022 - Koos van den Hout

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.

All the news about twitter makes me wonder if I want to stay there in the long run.

But changing a social network is always a negative experience, you lose contacts. I still remember some several people who I haven't heard much from since google+ and wonder how they are doing!

For amateur radio I'm having a look at mastodon as @PE4KH@mastodon.radio.

One conclusion is that my own site is more permanent than any social media. My own website survived the rise and fall of google+ while importing my posts so those are still available here. But interaction on my own site is complex and needs constant maintenance to avoid spam.

Usually I switch on the amateur radio setup, and the software surrounding it just to get a feel for which amateur bands are active and what's happening on those bands and maybe get a few contacts in the log.

Saturday evening was such a moment. But on the DX cluster I saw a new country (for me) active: Djibouti. On the 20 meter band in FT8. Recently Africa hasn't been too hard for me to get in the log so I joined the loads of amateurs trying to work J28MD and after a while I got the contact in the log with a good signal report.

The fun part is I assumed based on the website I would get a confirmation via Logbook of the World months later or after paying for a card. But after somewhat more than 24 hours this contact was already confirmed!

Another attempt at trying to understand the Ethernet over Cable stuff in the Corinex CXWC-HD200-WNeH that I have been working on. I found this on the device:

# /app/plcStatus 
Socket creation success.
Socket binding to vlan1 success.
Send success (22).
Send success (22).

Node type: 01
Ip address: 0.0.0.0
Parent mac: 00:00:00:00:00:00
Up speed: 00
Down speed: 00
Child count: 00
# 

The use of 'plc' (PowerLine Communications) and the way this works suggests to me this is indeed an ethernet-over-coax device (so no docsis). But I can't figure out where the ethernet-coax bridge is. I thought plcStatus would use some ethernet protocol to communicate with the bridge (just as the devolo dlan tools do) but I can't find any trace of the traffic on the wifi interface.

Bijna 10 jaar geleden deed ik mee aan een CTF: Ik heb meegedaan aan de hackcontest ter ere van 20 jaar SURFcert. En daar won ik een Samsung tablet. Die is dus ondertussen ook 10 jaar oud, bevat Android 4.2.2 met Linux kernel 3.0.31 en krijgt geen updates meer.

Recent bedacht ik me dat ik die tablet misschien nog als scherm zou kunnen gebruiken voor mijn thuis grafana server. Maar die server is alleen bereikbaar met https en daar heb ik een LetsEncrypt certificaat voor waarbij ik alleen de chain gebruik vanaf de ISRG Root X1 en niet meer vanaf de DST Root CA X3 omdat dat op andere plekken problemen geeft.

Daarmee werkt het gewoon niet. Ik heb nog pogingen gedaan om de ISRG Root in de certificaten van de tablet te krijgen maar als .pem, .crt of .cer file worden deze niet gezien als certificaat door de tablet.

De tablet is daarmee gewoon afgeschreven en niet meer bruikbaar. Ik heb deze tablet een aantal jaar gebruikt en daarna is deze vooral gebruikt door mijn zoon om spelletjes op te spelen en youtube filmpjes te kijken.

This weekend turns out to be a weekend for making radio contacts with countries / entities I haven't contacted before. Or especially trying to get more of those countries contacted in morse.

Friday evening I got Dodecanese contacted in morse, and already confirmed. Dodecanese is part of Greece, but counts as a separate entity for amateur radio. I have had contacts with Dodecanese before on all kinds of frequencies, but it turned out I didn't have it in morse yet. Time to fix that, and I managed to ge the contact.

Saturday I got the Comores in morse on the 12 and 17 meter amateur band. The 12 meter contact was easy with clear signals, the 17 meter contact was in the noise and hard. So I'm not completely surprised the logbook of the Comores dxpedition D60AE only shows the 12 meter contact.

I also managed to get a contact with Guadeloupe, a French oversees department in the Caribian. I had Guadeloupe before in digital modes but adding morse is good. This contact took a lot of tries, I think I was trying to get this one for nearly two hours. Other people probably are working longer at this, so I am not complaining.

Sunday morning I saw the Russian DXpedition team in Benin TY0RU active on 17m FT8. It also took a while of trying and paying attention to the radio to get this contact in the log.

There were also other contacts to special event stations or other activities, mostly in morse.

Radio contacts with dxpeditions can take a while to get through because a lot of radio amateurs in the world want the special contact, and when the contact finally happens it is ultra short. Exchanging callsigns and a default signal report is enough, and the dxpedition wants to get on to the next contact!

I also don't have the ideal callsign for noisy morse contacts: it could be shorter and the H at the end (in morse: ....) can be confused for an S (in morse: ...). Yes, PE4KS is in a few logs out there!

Yesterday I learned that ISC DHCP server will be end of life at the end of this year. For a package I started using around 1998 with one of the first versions I expected a bit more announcement time. At the same time I'm so used to using ISC dhcp server in my home network I never subscribed to any mailing list or other announcements about ISC dhcp server, it's just there, I can configure it to do what I want including supporting pxe booting systems for installation or diagnostics or supporting special dhcp options for APC AP7920 rackmount power distribution units. And all the virtual lans of my home network.

ISC suggests using Kea DHCP server to replace it in most server implementations. Kea DHCP server should be able to get a lot of configuration data from databases and allow for dynamic updates of the configuration. That is an improvement over ISC dhcp as it is at the moment, which needs a full restart for every change.

So time to peek at Kea DHCP server. I don't think ISC dhcp server will be unavailable after 31 December 2022 but I don't expect updates anymore and when a good replacement is normalized I expect ISC dhcp server to slowly fall away from linux distributions.

Currently it's not even available for Debian or Devuan stable or oldstable strangely enough. I wonder what happened there. But there are distribution packages for debian buster at Cloudsmith - Repositories - ISC - Internet Systems Consortium (isc) - kea-2-3 (kea-2-3) - Packages / format:deb.

Time to install the latest and let apt fix the dependencies:

koos@testrouter:~$ sudo dpkg -i isc-kea-dhcp4_2.3.1-isc20220928105532_amd64.deb isc-kea-dhcp6_2.3.1-isc20220928105532_amd64.deb isc-kea-common_2.3.1-isc20220928105532_amd64.deb 
Selecting previously unselected package isc-kea-dhcp4.
(Reading database ... 46609 files and directories currently installed.)
Preparing to unpack isc-kea-dhcp4_2.3.1-isc20220928105532_amd64.deb ...
Unpacking isc-kea-dhcp4 (2.3.1-isc20220928105532) ...
Selecting previously unselected package isc-kea-dhcp6.
Preparing to unpack isc-kea-dhcp6_2.3.1-isc20220928105532_amd64.deb ...
Unpacking isc-kea-dhcp6 (2.3.1-isc20220928105532) ...
Selecting previously unselected package isc-kea-common.
Preparing to unpack isc-kea-common_2.3.1-isc20220928105532_amd64.deb ...
Unpacking isc-kea-common (2.3.1-isc20220928105532) ...
dpkg: dependency problems prevent configuration of isc-kea-dhcp4:
 isc-kea-dhcp4 depends on libboost-system1.67.0; however:
  Package libboost-system1.67.0 is not installed.
[..]
koos@testrouter:~$ sudo apt install -f
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Correcting dependencies... Done
The following additional packages will be installed:
  libboost-system1.67.0 liblog4cplus-1.1-9 libmariadb3 libpq5 mariadb-common
  mysql-common
The following NEW packages will be installed:
  libboost-system1.67.0 liblog4cplus-1.1-9 libmariadb3 libpq5 mariadb-common
  mysql-common
0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded.
3 not fully installed or removed.
Need to get 760 kB of archives.
After this operation, 4,001 kB of additional disk space will be used.
[..]

Looking at the sample configuration makes me think I can do this with a text-based configuration (it's actually JSON) and get it going fast. For my home network that is probably the best solution. Kea does have options to use MariaDB or PostgreSQL backends for storage which does look really nice for my home network but at the same time adds a dependency and a layer of complexity.

I can see IPAM systems totally going to Kea DHCP and give a full interface on managing the databases directly including APIs for adding/removing objects as they are added in other systems.

One of my oldest certificate signing request files was still using a sha1 hash and LetsEncrypt started rejecting it. As soon as I realized it used the old hash I redid it and wondered why it was still accepted in 2022.

This also mean the private key of this service is showing age. Maybe time to regenerate it.

The announcement is at Rejecting SHA-1 CSRs and validation using TLS 1.0 / 1.1 URLs - API Announcements - Let's Encrypt Community Support.

After the problems with detaching and attaching the USB 1-wire interface from a kvm virtual machine to fix an interference issue showed up again I decided to move the USB 1-wire interface to a different machine, one where kvm virtualisation isn't in the mix. The closest available machine that can deal with the 1-wire interface is a Raspberry Pi which also has other monitoring tasks.

This move worked fine and the 1-wire temperatures are showing up again in influxdb. I decided not to update the rrdtool temperature database. I will have to find time to migrate the rrdtool history to influxdb. Ideally there will be some aggregation for older measurements but I'd like an "infinite" archive of a daily average.

My dive into the Corinex CXWC-HD200-WNeH continues. After getting root on the serial console of the Corinex CXWC-HD200-WNeH I ordered similar gear as used in the hardware hacking course to do my own hardware hacking. It arrived this week and today I had some time to play with it.

Using the techniques from the course I found the serial console interface again. The CPU board has 4 through-holes, that is a likely candidate. Next step is finding which pin is which using a multimeter. Ground pin has continuity to any other shield. One pin is at 0 volts without continuity to ground: the receive data pin (from the viewpoint of the chip), another pin has a varying voltage near the maximum voltage, this is the transmit data pin (again from the viewpoint of the chip) and the fourth one has the constant maximum voltage, which was 3.3 volts in this case.

I switched my USB to serial interface to 3.3 volts and connected the TX on the system to the RX on the serial interface and the RX on the system to the TX on the serial interface. I used Dupont cables to make this connection. With minicom as communications program I opened the right interface: minicom -D /dev/ttyUSB0.

After powering the router I got unreadable characters on the screen, I had to adjust the serial port rate. This router has a serial console at 57600 bps, 8 bits, no parity, 1 stopbit.

And messages came out:

U-Boot 1.1.3 (Jan 31 2013 - 17:23:55)

Board: Ralink APSoC DRAM:  32 MB
relocate_code Pointer at: 81fa8000
flash_protect ON: from 0xBF000000 to 0xBF02435F