Officially the "Corinex CXWC-HD200-WNeH" cable modem is out of support for
years and deployments should have migrated to newer solutions. That is the
reason I got my hands on one: it was replaced by a docsis-based modem.
For as far as I can tell these modems are based on homepna or homeplug, over
coax networks (the tools on the router don't tell what kind of standards the
coax side uses).
I'd like to know if any of these are still used in the wild. If you find this
post because you got bored and looked at the underside of the wifi box in your
holiday park, get in touch!
My e-mail address is at the bottom of this page and I'm on twitter as
@khoos.
Corinex CXWC-HD200-WNeH side with warrantylabel. The warranty was voided.
This week I was attending a course in hardware hacking: HackLab: Hardware Hacking
at the Deloitte office in Den Haag.
How to find the right pins to get a commandline on a router-like device was
part of this course, and the last day there was an option to Bring Your Own
Device, to hack it. So I brought this router as I thought it was an ideal
target to get access to it, since on the earlier try
I could not get into the webinterface of the Corinex CXWC-HD200-WNeH device.
Corinex CXWC-HD200-WNeH opened boards visible
So this time I took out the screwdriver, voided the warranty of the device by
breaking the little sticker on the side and opening it. It has a board with the
powersupply and cable interface parts. The powersupply is shielded with some
plastic.
There is a smaller board with the main chip which contains the processor,
ram, wifi module. The first task was to find the uart interface which should
give a serial console. That's a skill I learned in the hacklab: first find
out which pins have continuity to ground with the device switched off. With
a simple multimeter which has a beeping continuity meter this is simple.
The beep makes it possible to test the device without looking at the meter.
After that it's a matter of switching the multimeter to voltage and checking
other pins for voltage. Usually there are 4 pins on a uart port: ground
which is physically connected to the device ground, receive data and send
data and a reference voltage. On measuring the pins the reference voltage will
be at the steady maximum voltage, the data transmitting from the device will
be varying and the pin where the device expects data will be at 0 volt.
Uart ports can be 5 volt, 3.3 volt, 2.5 volt or 1.8 volt in recent devices.
5 and 3.3 volt are the most common. USB serial interfaces that support 5
and 3.3 volt are cheap (3 euro), USB serial interfaces that support all 4 are
somewhat more expensive (10 euro).
For the Corinex router the voltage is 3.3 Volt. There was a 3.3 Volt ftdi USB
to serial interface available, so I was able to access the uart port. I
connected to the uart port, used a terminal program and searched for the right
serial port settings and ended up at 57600 baud, 8 bits, no parity, 1 stopbit.
After looking at all the boot messages I was greeted with a root prompt. No
more hacking, just full access. The system boots using the U-Boot bootloader.
The system runs linux with a 2.6.21 kernel. I looked around on the filesystem
and started looking for the configuration for the webserver hoping to find the
username/password. I found this in /flash/config so I could get into
that interface as well.
I also found it was running a telnet server, but not on the standard port. The
port was 32560. Without commands like netstat or ss I had to
learn this from /proc/net/tcp. Browsing the iptables listing shows
that port 80 is supposed to be allowed and other ports aren't, but 32560 reacts
fine.
Chip found: Ralink RT3052F processor with embedded ram and flash and with
2.4 GHz wifi and a network switch for 1 gigabit port and 5 100 mbit ports.
Things I'd still like to do: copy the entire filesystem to another computer
so I can research it and check around the web interface for security issues.
Ik kreeg vandaag een phishing mailtje gericht aan:
Cher(ère) client(e) Maes-Swerts/A.,
Votre abonnement Proxumis a été suspendu, car vous avez fait opposition
à un règlement de dette. Tant que le problème n'a pas été résolu, vous
ne pouvez utiluser aucune de vos services proxumis.
De resulterende pagina wil een credit-card betaling. Dus verzamelt gewoon
credit-card gegevens. Ik zou me bijna afvragen hoe snel er fraude komt als
ik daar echte gegevens invullen. Ik denk dat het in de orde van minuten is,
maar dat wil ik niet testen.
De spam voor 'Maes-Swerts/A.' is nu al meer dan 10 jaar bezig!
Eerder,
eerder,
eerder,
eerder,
eerder,
eerder,
eerder de originele ontdekking in 2012.
There are always attacks in the logs, but this one caught my eye because
someone mentioned it, I saw it in logs and searching for a simple explanation
for what I saw gave no answers.
Those are the interesting ones. So here is the logline split into multiple
parts in an attempt to make it more readable:
Searching for timepro.cgi finds a2004ns-mod/timepro.cgi at master · hklcf/a2004ns-mod · GitHub
which seems to be compiled code:
ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped.
Based on Honware: A virtual honeypot framework for capturing CPE and IoT zero days
my best guess is that requests to timepro.cgi attempt to reconfigure
a home router. And my next guess is that the attempt is to set the DNS resolvers
to 128.0.104.18 and 128.0.104.33. Further searching finds
another attempt from the same source IPv4 address which also looks a lot
like an attempt to reconfigure DNS settings:
The theory that this is an attempt to redirect DNS traffic is somewhat
confirmed by the fact that 128.0.104.18 indeed runs an open resolver
which will give me answers. For the few things I have tried those are valid
answers (no clear attempts to redirect traffic to other places). I get no
answers from 128.0.104.33 at the moment.
Update:
Searching for the string 128.0.104 finds more:
I wanted to use wapiti as scanner to check for other vulnerabilities in
The Virtual Bookcase after
receiving a report
about a cross-site scripting vulnerability. Wapiti is open source and
free, which is a fitting price for scanning a hobby project site.
I quickly ran into wapiti taking hours to scan because of the URL structure of
the site: all /book/detail/x/y URLs map to one handler that deals
with the X and Y parameters in SQL queries. Yes those queries are surrounded
by very defensive checking and I use positional parameters. Everything to
avoid SQL injection and becoming the next Little Bobby Tables.
Wapiti has no simple method that I can find to crawl for a list of URLs and
stop at that to allow for selecting the list of URLs to scan. But it has an
option to minimize crawling and import a list of additional URLs to scan so I
used that option to get at the same result.
Gathering URLs was done with wget:
After that I sorted the file with URLs and threw out a lot of them, making
sure all the scripts with several variants of input were still tested.
With that list I start wapiti with some special options. It still needs a
starting url at -u so I give it the root but I limit the crawling with
the depth parameter -d 1 and the max files parameter
--max-files-per-dir 50. Then I add the additional urls from the
earlier scan with the -s parameter. It's a lot of tweaking but it does
the trick.
No vulnerabilities were found. I found one PHP warning which only triggered
in the kind of corner case a web vulnerability scanner causes, or an
attacker. So I fixed that corner case too.
I received a responsible disclosure report of a vulnerability in
The Virtual Bookcase.
I will directly admit I haven't done a lot of maintenance on this site in the
past few years but I want to keep my sites secure.
The report came via openbugbounty.org and has no details about the
vulnerability, so I am not 100% sure where the reported vulnerability is. But
based on the report text XSS (Cross Site Scripting) and a peek in the
access-log looking for specific requests I found I made a beginner mistake in
dealing with a search query: displaying it as-is within an HTML context. I
immediately fixed that error in the site.
Now I wonder why it took so long for me to realize the error of my ways or for
someone to notice it!
Checking the logs some more finds huge amounts of attempts at SQL injection,
which is a vulnerability I am very aware of and where I put up standard
defenses. But this is the first time a security researcher made me aware of
the cross-site scripting vulnerability.
Update:
I contacted the reporter about the vulnerability who responded quickly
inquiring about the possible bounty for finding the bug. As this is a site
that hasn't delivered any income in years the best I can do is a mention
in the credits of the site or on a separate hall of fame.
Update:
I also started a vulnerability scanner on the site myself, to find any other
vulnerabilities I might have missed. This scanner is going through the
development site at the moment. Like many other scanners it doesn't see by
default how certain urls all map to the same PHP script.
I already committed a few minor updates to improve handling of corner cases
in not set variables and other things popping up in the scan.
Update 2022-09-23:
I realized the reporter has never responded with the actual bug information.
After digging into setting up radius and WPA Enterprise with an Asus WL300g accesspoint
the next step was to peek into the traffic on a client.
For that part I used a linux machine with a wired and wireless interface and
used tcpdump to try to capture the wireless authentication packets.
I configured /etc/network/interfaces
for wpa enterprise, based on the eduroam examples.
And this worked, starting the capture:
And I typed in another window 'ifup wlan0'. This resulted in a capture with
the right Extensible Authentication Protocol (EAP) packets included:
root@ritchie:~# tcpdump -nr wlanstart.pcap -v
reading from file wlanstart.pcap, link-type EN10MB (Ethernet)
16:47:39.658963 EAP packet (0) v2, len 5, Request (1), id 0, len 5
Type Identity (1)
16:47:39.660863 EAP packet (0) v1, len 25, Response (2), id 0, len 25
Type Identity (1), Identity: anonymous@idefix.net
16:47:39.662840 IP6 (hlim 1, next-header Options (0) payload length: 56) :: > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener report v2, 2 group record(s) [gaddr ff02::1:ff23:123 to_in, 0 source(s)] [gaddr ff02::1:ff84:afe0 to_ex, 0 source(s)]
16:47:39.668736 EAP packet (0) v2, len 6, Request (1), id 1, len 6
Type TTLS (21) TTLSv0 flags [Start bit] 0x20,
16:47:39.670420 EAP packet (0) v1, len 6, Response (2), id 1, len 6
Type Nak (3) unknown (25),
16:47:39.682125 EAP packet (0) v2, len 6, Request (1), id 2, len 6
Type unknown (25)
16:47:39.741150 EAP packet (0) v1, len 203, Response (2), id 2, len 203
Type unknown (25)
16:47:39.756343 EAP packet (0) v2, len 1004, Request (1), id 3, len 1004
Type unknown (25)
16:47:39.756598 EAP packet (0) v1, len 6, Response (2), id 3, len 6
Type unknown (25)
16:47:39.834920 EAP packet (0) v2, len 1000, Request (1), id 4, len 1000
Type unknown (25)
16:47:39.835159 EAP packet (0) v1, len 6, Response (2), id 4, len 6
Type unknown (25)
16:47:39.842070 EAP packet (0) v2, len 1000, Request (1), id 5, len 1000
Type unknown (25)
16:47:39.842318 EAP packet (0) v1, len 6, Response (2), id 5, len 6
Type unknown (25)
16:47:39.866174 EAP packet (0) v2, len 79, Request (1), id 6, len 79
Type unknown (25)
16:47:40.006260 EAP packet (0) v1, len 144, Response (2), id 6, len 144
Type unknown (25)
16:47:40.014338 EAP packet (0) v2, len 65, Request (1), id 7, len 65
Type unknown (25)
16:47:40.016467 EAP packet (0) v1, len 6, Response (2), id 7, len 6
Type unknown (25)
16:47:40.028765 EAP packet (0) v2, len 43, Request (1), id 8, len 43
Type unknown (25)
16:47:40.029290 EAP packet (0) v1, len 96, Response (2), id 8, len 96
Type unknown (25)
16:47:40.036381 EAP packet (0) v2, len 75, Request (1), id 9, len 75
Type unknown (25)
16:47:40.043383 EAP packet (0) v1, len 144, Response (2), id 9, len 144
Type unknown (25)
16:47:40.057720 EAP packet (0) v2, len 91, Request (1), id 10, len 91
Type unknown (25)
16:47:40.058739 EAP packet (0) v1, len 80, Response (2), id 10, len 80
Type unknown (25)
16:47:40.071176 EAP packet (0) v2, len 43, Request (1), id 11, len 43
Type unknown (25)
16:47:40.072087 EAP packet (0) v1, len 80, Response (2), id 11, len 80
Type unknown (25)
16:47:40.082689 EAP packet (0) v2, len 4, Success (3), id 11, len 4
16:47:40.082865 EAPOL key (3) v2, len 117
16:47:40.091607 EAPOL key (3) v1, len 117
16:47:40.107041 EAPOL key (3) v2, len 175
16:47:40.107839 EAPOL key (3) v1, len 95
At the same time I captured the radius traffic. Now time to correlate those
two traffic streams in wireshark.
For work I am looking into how Wi-Fi Protected Access (WPA)actually works down to the byte level, to be able to explain
what actually happens and where the security strenghts and weaknesses are.
To set this up I need a separation between the access-point and the
authentication server. I dug up an old Asus WL300g access-point and looked at
FreeRADIUS as authentication,
authorization and auditing (AAA) server. I followed the A very basic (but functional) eduroam configuration - FreeRADIUS wiki
guide to get to a working setup, but with different passwords.
Getting the access-point to talk to a radius server took a bit of searching
and trying: I assumed that "802.1x" which is extended to "Radius with 802.1x"
was the right mode to use a radius server in the background, but it turned out
this didn't do what I want. I saw no communication with the radius server and
I didn't see the SSID advertised.
The right mode is "WPA" and things started to work that way. It still needs a
few settings to talk to the radius server: IP address, port and shared secret.
I chose to go the 'eduroam' way because that is what I am used to from work.
This does mean I had to set a home domain idefix.net for
authentication. With eduroam I also get Extensible Authentication Protol
(EAP) extensions to handle with the real user data. The result is an
outer authentication layer visible to the first radius server in the path
and an inner authentication layer only visible to the final radius server in
the path. Although both the outer and the inner authentication servers run
on the same freeradius server they are separate configurations with a trust
relation between them.
The traffic to the inner authentication server is wrapped in TLS and needs a
certificate. I used LetsEncrypt to generate a trusted certificate. I noticed
I am at a point where generating a valid LetsEncrypt certificate was easier
for me than fiddling with self-signed certificates. So I could set up my
phone to require a valid certificate for radius.idefix.net.
All of this worked and I had a WPA Enterprise connection with the access-point
and a lot of debug logging in freeradius.
My next plan is to find some computer with a network card where I can run
wpa_supplicant while at the same time grabbing all the raw 802.11
frames and analyzing/understanding the traffic. I will also look at the
radius traffic between access-point and outer radius server, and the radius
traffic between outer and inner radius server.
Summertime is also time for some extortion scamming... this one just in:
Hi. How are you?
I know, it’s unpleasant to start the conversation with bad news, but I have no choice.
Few months ago, I have gained access to your devices that used by you for internet browsing.
Afterwards, I could track down all your internet activities.
Here is the history of how it could become possible:
At first, I purchased from hackers the access to multiple email accounts (nowadays, it is a really simple thing to do online).
As result, I could easily log in to your email account
One week later, I installed Trojan virus in Operating Systems of all devices of yours, which you use to open email.
Frankly speaking, it was rather straightforward (since you were opening the links from your inbox emails).
Everything ingenious is quite simple. (o_0)!
..
Here is my bitcoin wallet provided below: bc1q82tvkvmzjzyqf60guqpxhcn2tuapqup35a9ldr
You should complete the abovementioned transfer within 48 hours (2 days) after opening this email.
The following list contains actions you should avoid attempting:
#Do not try calling police as well as other security forces. In addition, abstain from sharing this story with your friends.
After I find out (be sure, I can easily do that, given that I keep complete control of all your devices) – your kinky video will end up being available to public right away.
#Do not try searching for me – there is absolutely no reason to do that. Moreover, all transactions in cryptocurrency are always anonymous.
#Do not try reinstalling the OS on your devices or throwing them away. It is pointless as well, since all your videos have already been uploaded to remote servers.
Ik kreeg vandaag een phishing mailtje gericht aan:
Cher(ère) client(e) Maes-Swerts/A., Votre abonnement Proxumis a été suspendu, car vous avez fait opposition à un règlement de dette. Tant que le problème n'a pas été résolu, vous ne pouvez utiluser aucune de vos services proxumis.De resulterende pagina wil een credit-card betaling. Dus verzamelt gewoon credit-card gegevens. Ik zou me bijna afvragen hoe snel er fraude komt als ik daar echte gegevens invullen. Ik denk dat het in de orde van minuten is, maar dat wil ik niet testen. De spam voor 'Maes-Swerts/A.' is nu al meer dan 10 jaar bezig! Eerder, eerder, eerder, eerder, eerder, eerder, eerder de originele ontdekking in 2012.
Ik kreeg vandaag een phishing mailtje gericht aan:
