Breaking into my router cuz why not
I wanted to stream games. My ISP doesn’t allow me to use IPv6, and IPv4 is behind a CGNAT. So I went probing.
Began by checking the web ui - extremely confusing, nothing made sense. the options are all jumbled up, not documented properly, and it’s a pain to use. however, this wasn’t gonna stop me. after extensive research i realised, that it doesn’t seem like I can enable ipv6, because EXCITEL DOESNT PROVIDE IPV6 AT ALL.
but fine. I was wrong, it’s alright. then something catches my eye.
telnet. ssh. what could these possibly be doing here? ainnoway this thing is running an actual os - I thought it’d be running a custom barebones OS or some proprietary OS that won’t be usable.
but I still checked. begin nmap scan bunch of ports open, some filtered. weird. these aren’t supposed to be visible or in use at all. this is a router ffs.
enable telnetd. try to connect. asks for a username pwd. root root doesn’t work. try my mgmt interface custom pwd. works. fine. now I’m dropped into a weird little program. it’s not a shell. it’s just a menu being spammed into the terminal over and over, and it allows me to send commands. alright, let’s see. hmmm. this isn’t interesting - i want sh.
I dont like this. go online, find an update fw file. RE that. not a lot of hints but strings reveals interesting stuff, like a command called enterlinuxshell that i wouldve never otherwise found (/bin/cli is a really bad custom realtek mgmt interface) . try it out - dropped to a linux shell. great. no other passwords than the wifi required.
first thing I do check /etc/ for config files and stuff - barely anything worthwhile. it seems to not follow FHS conventions. fine.
run ls -> wait this looks like linux. /etc /var /mnt /tmp this seems oddly similar
uname doesnt work. try cat /proc/version
Linux version 3.18.24 (Lipeichao@terminal) (gcc version 4.8.5 20150209 (prerelease) (Realtek MSDK-4.8.5p1 Build 2536) ) #3 SMP Wed Sep 25 16:30:48 CST 2024 [luna SDK V3.3.0]
well well well. this is… old. to say the least.
first thing we do check that ssh. its dropbear ssh. have to use legacy params to connect with standard ssh commands after enabling. works.
what now? dump everything/
cat /proc/meminfo
MemTotal: 132768 kB
MemFree: 67432 kB
MemAvailable: 70876 kB
Buffers: 320 kB
Cached: 13040 kB
SwapCached: 0 kB
Active: 26396 kB
Inactive: 10580 kB
Active(anon): 23684 kB
Inactive(anon): 48 kB
Active(file): 2712 kB
Inactive(file): 10532 kB
Unevictable: 0 kB
Mlocked: 0 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 132768 kB
LowFree: 67432 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 23688 kB
Mapped: 12472 kB
Shmem: 68 kB
Slab: 21828 kB
SReclaimable: 1388 kB
SUnreclaim: 20440 kB
KernelStack: 2480 kB
PageTables: 768 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 66384 kB
Committed_AS: 157324 kB
VmallocTotal: 1015800 kB
VmallocUsed: 2488 kB
VmallocChunk: 968732 kBcuriosity got the best of me. cpuinfo:
router# cat /proc/cpuinfo
system type : RTL9607C/RTL9603C
machine : RTL9607C/RTL9603C
processor : 0
cpu model : MIPS interAptiv (multi) V2.0
BogoMIPS : 761.03
wait instruction : yes
microsecond timers : yes
tlb_entries : 64
extra interrupt vector : yes
hardware watchpoint : no
isa : mips1 mips32r2
ASEs implemented : mips16 mt eva
shadow register sets : 1
kscratch registers : 0
package : 0
core : 0
VPE : 0
processor : 1
cpu model : MIPS interAptiv (multi) V2.0
BogoMIPS : 574.66
wait instruction : yes
microsecond timers : yes
tlb_entries : 64
extra interrupt vector : yes
hardware watchpoint : no
isa : mips1 mips32r2
ASEs implemented : mips16 mt eva
shadow register sets : 1
kscratch registers : 0
package : 0
core : 0
VPE : 1
processor : 2
cpu model : MIPS interAptiv (multi) V2.0
BogoMIPS : 761.03
wait instruction : yes
microsecond timers : yes
tlb_entries : 64
extra interrupt vector : yes
hardware watchpoint : no
isa : mips1 mips32r2
ASEs implemented : mips16 mt eva
shadow register sets : 1
kscratch registers : 0
package : 0
core : 1
VPE : 0
processor : 3
cpu model : MIPS interAptiv (multi) V2.0
BogoMIPS : 761.03
wait instruction : yes
microsecond timers : yes
tlb_entries : 64
extra interrupt vector : yes
hardware watchpoint : no
isa : mips1 mips32r2
ASEs implemented : mips16 mt eva
shadow register sets : 1
kscratch registers : 0
package : 0
core : 1
VPE : 1well that’s fairly decent for a router. wasn’t expecting SMT on 2 cores. props to them here.
here’s where the fun begins.
the realtek mgmt interface looking quite juicy - re that and came to know a lot about the system, underlying cmds, etc.
14 mtd* partitions. most readable. mtd0 - bootloader locked. use page reads. mtd11 or whatever, one partition. 4kb all 0s. doesn’t seem to really have anything… weird.
get all partitions, recombine into one image. save.
dump the rootfs. tar everything into a file and get it out. got a copy, that’s done.
got the rootfs of the running one and an update capsule. have root.
what now?
instead of looking into the boa webserver (which is unmaintained since around 2005 iirc) and is probably vulnerable, though i can’t be sure just yet I check the DHCP and SSID logic. because that’s going to be more difficult to compro.
find a hardcoded pin what appears to be a WPS key - tests failed using it. so let go for now. found a bug in the DHCP systems where I can add modify dns entries in certain cases by using a specially crafted hostname because no input sanitization. classic. that’s good. maybe it’ll come in handy later foreshadowing but it’s not enough.
check telemetry - everything I do being sent to an external second shadow server (or what appears to be it.). not convinced.
tr069 - check. good, we can send remote commands. fine. might come in handy later asod_agent. seems to be a way to remotely control the device from aprecomm cloud. not good, not good. command goes straight to root. my hardware is less accessible to me than it is to a cloud entity, and there is no way to disable this from the webui.
scan wifi from host - wait there’s 3 networks with the same BSSID. one is named www.excitel.com. I never configured this. check firmware. custom hardcoded password that automatically comes back on (what appears to be) reboot and reset. hmmm. great. just great.
hop on to the network. can’t reach google.com in the browser. weird. thorough scan from the client side, turns out TCP and UDP are blocked for this. why would they ever do that?
ICMP goes through (ping works). the rest are going through. so why would it ever block TCP/UDP? (why does this network exist at all?)
here’s my guess. proximity. technician comes to your house, needs to do maintenance, he connects to this, then uses that connection as proof of proximity. wild theory, not sure, not verified. as good as your guess.
anyway. knowing that 192.168.1.1 is probably compromisable considering it’s running very old software (ssh from around 2000s, early 2010, vulnerable to heartbleed) telnet client old, the realtek sdk dates back to 200X. not looking great. I expect patched firmware. you guys have RCE into my router, full view of what I’m doing at all times and you can’t even give me basic security against attackers? pff. (software stack)
- OpenSSL 1.0.1c (May 2012) — Heartbleed-vulnerable
- BusyBox 1.22.1 (2014)
- Boa 0.93.15 (banner) / 0.94 (source) — EOL since 2005
- Kernel 3.18.24 — Dirty COW vulnerable, EOL
- miniupnpd 1.4.0 (2011)
- wscd (WPS) v1.24 — Realtek WiFi Simple Config, 2006 vintage
- uClibc 0.9.33.2
- dnsmasq 2.80
- dropbear SSH (2019.78 era based on the key types) if I can get onto the SSID I can compro these. check tr069, asod_agent. periodic pings upstream. hmmmmm. wait. wait.
if just from DHCP and connecting a device we can poison DNS, can’t we MITM tr069 and asod? turns out, not really. tr069 is plaintext, but it’s got a hardcoded entry at the top of the file. and the parser takes precedence for whatever is set higher (weird). fine. try for asod. yes, we can poison the cache. but we still don’t recieve it’s requests. why
the enforcement of ACLs, of what can go where, who can talk to who is enforced in a what seems to be an asic. those rules I couldnt figure out how to modify even with root. so I cant recieve those requests on the same network what about OOB? maybe I can have it request outside, take malicious commands and run them? tls. the one place that’s vulnerable to dns poisoning, we have tls. great. 1024-bit tls. practically unbreakable at hobby scale, but nation-state actors could probably crack it. or ask the company to hand over my data. probably the latter.
found a lot of decoy stuff. serial numbers that are 123456789. 11223344- onwards. a cert with data as AU and Some-State, test.org, default company ltd in use… very, very interesting.
hardcoded key in the router - if anybody gets a hold, they can decrypt the telemtry it sends at the other end… alright.
tr069 cert. expired. realtek dev cert. expired. ssh host key. same on all.
this one is more interesting. /etc/certs/adls_ca_client.{crt,key} — aprecomm mTLS client cert + encrypted private key. passphrase: literal string aprecomm. Fleet-shared across all routers possibly.
tr-069 creds - compro. chinese isp defaults stillin here.
passwords, defaults all over the place.
found a(nother) backdoor.
PROVINCE_SICHUAN_E8C_BACKDOOR_ENABLE=1
very interesting flag. very, very, very interesting. strings backdoor and we have hits? that is insane engineering.
it seems nobody provisioned it and the pages were ripped out so we’re relatively ok. and that for now it seems to need wifi ssid creds to be accessible. the pages are ripped out, but the handlers and the functions are not. they’re compiled INTO the boa binary, so if you needed to, and you had a provisioned version, you could just POST to those endpoints and it’d work. great work.
tried all the channels I knew. bunch of CVEs I found that might be relevant, didn’t work.
so this is where you people (yes, you, the reader) come in.
do you have ideas on how this can be exploited further? not from being connected to the main wifi network. no, from connecting to the alternate VAP www.excitel.com. I’ve tried a bunch of stuff including trying to reconstruct TCP packets in the kernel by sending invalid fragments, trying to smuggle protocols inside other protocols but it just wont work.
so…
use excitel / exc@123 to login to 192.168.1.1
I don’t think this is a CVE, because so far I didn’t really find anything convincing enough to be classified as an exploit per-se. I checked excitel’s policy on reporting CVEs, surprise surprise, they don’t have one.
reach out to me. on discord (arulgandhi) if you’re interested in breaking this. even if you don’t have excitel, you’ve got other routers. good. more variety. reach out, let’s break stuff together.