Hitronhub CVE-30360 (Kabel Deutschland) WLAN Hack?

Ich habe den Proxy dahingehend erweitert, dass er nicht mehr im Browser eingetragen werden muss.
Jetzt reicht herunterladen und starten.
Die Router-Oberfläche wird dann automatisch mit dem Standardbrowser geöffnet.

Download Windows
Quelltext

Das Ganze wird möglich gemacht durch einen lokalen Webserver(Port 8081) der mit dem Proxy(Port 8080) kommuniziert.
Der widerum spricht mit dem Router unter IP 192.168.0.1.
 
Zuletzt bearbeitet:
Habe es letztendlich doch noch geschafft mit dem localhost und dieses proxy.exe,:Dhoffe nur es hält!!Danke nochmal für deine ausführliche beschreibung!!:thumb_up:Gruß
 
Info

Ich denke. Die Router hat 3 user. Für wechsel Settings, du brauchst dies login und password von Superadmin User. 8)

Super Admin (Sysop) (superadmin/ ????)
Admin (Admin/Password)
User (Guest/Guest)
 
@ Intrusion
Hey,
thanks for your answer. Too bad I cannot find the new firmware anywhere. Might I ask why you are interested in CVE-30360?

BTW I am currently analyzing the 3.1.1.21 firmware and found some interesting things. The configuration file is DES encrypted, we knew already that it is a block cypher, now it's confirmed. Also the web gui is a custom program using the GoAhead webserver library.
My findings up till now
 
Habe jetzt den DES- Schüssel für die Konfigurationsdateien gefunden:
0x57, 0x8A, 0x95, 0x8E, 0x3D, 0xD9, 0x33, 0xFC
Ein Programm mit dem man Dateien ent/ver- schlüsseln kann findet sich hier zum selbst compilieren
 
Hast du schon mal in der config was geändert und wieder aufgespielt. Wenn ja was ist passiert?

weil wenn man so was sieht juckt es unter den Fingen. :p

Code:
local_management telnet false
local_management ssh false
...
wireless false
 
Hast du schon mal in der config was geändert und wieder aufgespielt. Wenn ja was ist passiert?

weil wenn man so was sieht juckt es unter den Fingen. :p

Code:
local_management telnet false
local_management ssh false
...
wireless false
local_management telnet/ssh öffnen beide temporär ihren Standardport nach dem Start des Routers. Mit folgendem Benutzer/Passwort -Paar kannst du dich einloggen(quasi root):
Code:
app - com8&#wDs2*1er
Nahezu die gesamte Platte ist allerdings read-only. Und die Stellen die du beschreiben darfst(/dev) werden bei einem Neustart zurückgesetzt. Einzige Möglichkeit Kontrolle über den Router zu übernehmen, soweit ich weiß, ist eine frische Firmware hochzuladen. Das kann man mit dem Befehl dload in dem Tool /usr/sbin/cli machen. Ein Tool zum entpacken und packen der Firmware gibt es hier. Probiert habe ich das allerdings nicht, ist also alles auf eigene Gefahr.

Wenn du dir nur die aktuelle Firmware genauer anschauen willst installiere einen tftp(z.b. für windows) bei dir und speichere folgendes Script(z.b. mit vi) im /dev-Ordner und mach es ausführbar "chmod +x script.sh":
Code:
#!/bin/sh

find $1 | while read file
do
	remote=`echo $file | sed -e "s/\//_/g"`
	tftp -l $file -r $remote -p $deineip 69
done
wobei $deineip halt deine IP ist.
Dann ruf es für jedes Verzeichnis auf dass du haben willst. Also z.b. für /etc:
Code:
./script.sh /etc

wireless auf true setzen hat bei mir nichts bewirkt.

PS: der DES-Schlüssel sowie das Admin-Passwort standen im Klartext in einer Binary (libhtx_db.so). Wer auch bisschen rumforschen will kann IDA benutzen.
 
Zuletzt bearbeitet:
Zuletzt bearbeitet:
Seit dem Update auf 3.1.1.29 funktioniert die Script-Aktivierung nicht mehr. Mit der Proxy-Methode hat man zwar noch Zugriff auf die WLAN Ebene, aber bei manueller Aktivierung übernimmt er dieses nicht und loggt einen sofort aus
Hallo, seit heute funktioniert bei mir die Wlan funktion auch nicht mehr X(!!Wenn ich in Benützer Menü Wlan aktiviere und dann auf übernehmen geh,schmeißt er mich aus dem menü automatisch raus X(!!Hoffe es findet jemand schnell eine Lösung!!
 
Hi FLIPFLOP,

how did you find out that:

app - com8&#wDs2*1er

would log you in? You can send me this in a personal mail, ofcourse.


My interest in this Hitron hack lies in the fact that I would like to add a route to a VPN server in the Hitron gateway. Quite legitimate I would say. You can argue about the wifi thing in my opinion.


With the login method you described I got a way in. After some changes in the Iptables and some other things I can now login even after the initial boot login session has stopped.

I am however not sure what the status would be after a reset. I am also not sure if a new image could be sent and installed in the modem.

I would like to prevent this tftp upload of a new image or settings. Is it possible to prevent such an upload? Does tftp need a password and if so which user would be used? I changed passwords of the users in the passwd file.

I hope you don't mind me writing in English; you can answer in German, ofcourse.
 
Hi FLIPFLOP,

how did you find out that:

app - com8&#wDs2*1er

would log you in? You can send me this in a personal mail, ofcourse.
I stumbled over it while analyzing the firmware (v. 3.1.1.21) which you can find here. The position where I found it was in offset 00046080 of the file /lib/libhtx_db.so. I used IDA to look at it.

With the login method you described I got a way in. After some changes in the Iptables and some other things I can now login even after the initial boot login session has stopped.
Could you elaborate on the iptable changes you used to prevent blocking?

I am however not sure what the status would be after a reset. I am also not sure if a new image could be sent and installed in the modem.

I would like to prevent this tftp upload of a new image or settings. Is it possible to prevent such an upload? Does tftp need a password and if so which user would be used? I changed passwords of the users in the passwd file.

I hope you don't mind me writing in English; you can answer in German, ofcourse.
Actually I don't know how the update works. I would guess that it checks a remote server every so often (there are no open ports on the outside). You could check all the scripts and binaries running on the device. One of them probably contains the actual call to tftp. If you succeed please post your progress here.
 
I tried to download this version of the firmware from the git repository but did not succeed. I got a file of 24kB. (I have an old firmware version nr 19 maybe because I asked for the old software after problems with the IPv6 move). But anyway I don't have IDA, i suppose you can use that at work. I did notice however that the file you mentioned contained many times the string "password" and your com8... password string. Quite nice that you apparently found the exact place where the entered password was compared to the given string.

Strange that the manufacturer just compared plaintext strings. I think I would have used a password file (with encripted passwords) and build that in a rootfs. That's how I have seen it in a logitech webcam. But you can modify this password file and insert your own encripted password or leave it empty.

If you are in with your password (connect while booting) you can start the command line interface: cli.

All kind of things are settable also ssh and telnet server.
Choose the RG menu and look around a bit. There I also found the command admpass. It showed me another password: Egj1nP .

Alter I enabled ssh and telnet the ports were still not available.
Then I entered the Iptables. I am no iptables expert but it was easy to find where the ports 22 and 23 were closed.

Normally the following ports are in use:

80/tcp open http
139/tcp closed netbios-ssn
445/tcp closed microsoft-ds
1900/tcp closed upnp
5000/tcp closed upnp
9100/tcp closed jetdirect


If I enable upnp via the web interface port 5000 went open. apparently miniupnpd uses 1900 and 5000 (1900 for streaming and 5000 for port forwarding?)

iptables -L gives you the whole table (a bit to big for here).

I did:
# iptables -L MANAGEMENT_ACL 3
DROP tcp -- anywhere anywhere tcp dpt:ssh
# iptables -R MANAGEMENT_ACL 3 -p tcp --dport 22 -j ACCEPT

And also (if you wish) for port 23. After that port 22 and 23 are open.
I think I started after that utelnetd. Maybe telnetd and dropbear where already running when I enabled them in the cli program.
Now I could quit my boot ssh session and connect anytime.

the password file in /var/tmp contains this:

app:***:0:0:Default Admin:/:/bin/sh
msoadmin:***:0:100:System admin:/:/usr/sbin/login_cli.sh
admin:***:0:101:Customer admin:/:/usr/sbin/login_cli.sh
nobody:***:0:1001:Customer admin:/:/usr/sbin/login_cli.sh

The "***" I entered myself.

I think this file is tarred into /var.tar and committed to nvram. I don't know if this happens automatically or only when you change something in the web interface. Other routers explicitly ask for a save action.

I am still carefull not to reboot the router because I am busy with openvpn for which I would like to add a route to my vpn server. This vpn thing is now more or less working: I can reach all systems (in one network) from all systems (in another network). However there are some systems I can not reach and I can not find the reason (but that is for another forum, I suppose);)

Errata: I had to reboot the Hitron and unfortunately the things I changed were gone.
Also I am not able to ssh into the hitron; apparently I did more than I remembered above. Still trying....

Errata: a second iptables entry was necessary:
iptables -I LOCAL_MANAGEMENT_CONTROL 1 -p tcp --dport 22 -j ACCEPT

Errata: my assumption about /var.tar was incorrect. I untarred this file and the password file contained a root entry while later there is no root at all in the passwd file. So maybe this is a boot only "part of the filesystem" file?

So the important question is: how do you prevent an update or remote management. And how can you make changes in RG settings permanent (boot resistant)?
 
Zuletzt bearbeitet:
I forgot to report on the tftp thing:


I found the program ti_tftp that is obviously a tftp server/client.
In several places in /lib this program is called:

libpacm_cfm.so:Spawned ti_tftp client with args %s.
libpacm_sec_util.so:/sbin/ti_tftp %s -v -i %s -f %s -c
libplugin_rgcli.so:ti_tftp %s -f %s -w /var/tmp -b 512 -t 2
libplugin_rgcli.so:ti_tftp %s -s %s -w /var/tmp -b 512 -t 2
libplugin_ticli.so:/sbin/ti_tftp
libplugin_ticli.so:ti_tftp

This suggests in the last four lines that it is manually called in the cli program. The first two lines maybe called automatically by the modem. ???

So far I have not found anyplace (in a script) where it was called.
Maybe you could have a go at it (the libpacm files), Flipflop?
 
Zuletzt bearbeitet:
Thanks for your detailed answer(s).

I tried to download this version of the firmware from the git repository but did not succeed. I got a file of 24kB. (I have an old firmware version nr 19 maybe because I asked for the old software after problems with the IPv6 move).
Try to clone the repository.

But anyway I don't have IDA, i suppose you can use that at work.
You can use the demo of IDA.

So the important question is: how do you prevent an update or remote management. And how can you make changes in RG settings permanent (boot resistant)?
I think the only way to be completly safe from update or remote management is making your own firmware. You can do that using the firmware-mod-kit for unpacking and packing firmware/*.sbn files and the dload command of the cli tool to actually load the firmware onto the device. I did not try that, so you are on your own on that.
 
I suppose that making your own image is doable. (I have no experience with Git but I can learn. The firmware construction is working here on an other trx file). I am not sure how you could flash that into your modem. There is no option in the webinterface for reflashing the software. Have you any idea how the software installation process goes?

I have done this once (with a sitecom webcam) but it took some nerve to push the (software image) upload button.

Apart from the technical problems there are some legal issues. I know that all I want is an extra route in the route table of this modem. But you can argue that you are changing somebody elses property. As I said, what I want - just an extra route- is in my opinion legitimate and I will try much to achieve it.

Did you try the iptables stuff?

Have you played with the cli program? All kind of things in there.

As you can hear I am no real hacker talking of legal issues. I am most afraid, though, of bricking the modem!

Hope to hear from you.
 
I have seen that there is a directory /nvram. Maybe some expert in embedded Linux can confirm that changes in this filessystem (jffs2) are permanent.

There is also a file /nvram/.rgsetup.cfg that contains many settings (including your password in plaintext). I have seen that changes made in the webinterface changes settings in this file (and supposedly are permanent).

There is also a file /nvram/sysstartup.sh that is executed at boot and apparently starts the required software. See also /etc/init.d/rdS.
Correction: the file /etc/scripts/sysstartup.sh is executed at boot. The purpose of the file /nvram/sysstartup.sh is unclear to me.

Would the end of this file be a good place to place your own commands?
I would like to put two iptable commands there and start dropbear.
Correction: this problably does nothing. Alas...

I don't have the guts because this modem is my only internet access possibility. Anybody else?
 
Zuletzt bearbeitet:
I finally succeeded in making the required adjustments in the Hitron modem automatically. It reguires a computer running a script that repeatedly tries to login in.This will only succeed immediately after boot. The boot maybe because of installation of new software or because of power failure (that may be intentionally).

On this computer (in my case a Raspberry Pi in use for other things) must run the following script "connect":


HITRON=10.0.2.136 (change this for your modem's ip)
USER=app
PASSWORD="com8&#wDs2*1er"
OPTIONS="-o StrictHostKeyChecking=no -o ConnectTimeout=10 -o ServerAliveInterval=5 -o ServerAliveCountMax=1"
echo Password of $USER $PASSWORD
while [ 1 ]
do
echo connect...
sshpass -p$PASSWORD ssh $OPTIONS $USER@$HITRON $1
done

This will connect you with your HITRON just after the booting.
Then you can do what you want but after quitting the ssh shell you can not connect again (unless you have changed the iptables).


When inside the modem you can make (with vi) the following script:

if [ ! -f /var/tmp/in ]; then
sleep 15
ip route add 10.0.0.0/24 via 10.0.2.150
ip route add 10.0.1.0/24 via 10.0.2.150
iptables -I LOCAL_MANAGEMENT_CONTROL 1 -p tcp --dport 22 -j ACCEPT
touch /var/tmp/in
fi

Save it as /nvram/init. The directory /nvram is in nonvolatile memory.
Make it executable with chmod 755.

Run on your computer:

./connect /nvram/init

Reboot your modem.


Your computer will make a connection with your modem and change a few things there:

- add some routes in my case for routing to a VPN server.
- change a firewall rule so you can connect from now (with ssh).

The sleep command is important because you get in before the route table or the iptables are complete.

The /var/tmp/in file is used to signal that the changes have been made and should not be made again. The /var/tmp directory is in volatile memory.

Unfortunately you can not change the app password in the "init" script because passwd does not read from stdin, so you must do that when you first ssh to your modem.

I am not completely sure about the options for ssh but the ones given here seem to do the job.





It would all be better if we could apply the changes at boot without the help from an other computer but sofar I have not found things in the nvram or the stored files there that could do that.
 
Zuletzt bearbeitet:
Zurück
Oben