Exploit for BE85 (aarch64)?

[naf419]

Hello, I'm trying the userland/web exploit with a BE85, what binary did you get the ROP gadget from? Is it from nvrammanager itself or a shared library?

Originally posted by @VsnGamer in #1 (comment)

[naf419]

BE85 is aarch64, no? So its going to run into the whole issue of the scanf overrun primitive terminating on a null byte with little endian 64-bit addresses. Same struggle as the x80 which I haven't found a solution for.

But to answer your question, the ROP gadget in my proposed M9Plus exploit was found in nvrammanager itself since its not PIE (because shared libraries would be ASLR'd, yes?)

[VsnGamer]

Yea that makes sense, doesn't seem there's a vulnerability in this one.
Firmware seems based on openwrt, looks like they kept failsafe, however it's probably read-only root partition.

I'll try whenever I get the time, thanks anyway for your help!

[naf419]

If I've learned anything from all the deco vulns Ive seen, its that you need to look at each device individually (including older fw versions). They all have different quirks, some of which have vulns that others dont. Plus you need to look at bootloader also (similar code but seperate vulns again). So if you have serial access, feel free to dump the bootloader partition if you want me to peak and see if its vulnerable. Ill try to peak at a few versions of the usermode firmware update code when I have a free minute.

…

On Fri, Oct 25, 2024 at 5:03 PM Vasco ***@***.***> wrote: Yea that makes sense, doesn't seem there's a vulnerability in this one. Firmware seems based on openwrt, looks like they kept failsafe, however it's probably read-only root partition. I'll try whenever I get the time, thanks anyway for your help! — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE64FAUTTQ2SJPHMSEUICLLZ5K54NAVCNFSM6AAAAABQSYYKRKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZYHE2DGMRSGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[naf419]

Just a note that the usermode upgrade in BE85 fw 1.0.22 does NOT contain the sscanf vulnerability, but it DOES in 1.0.18. Still no known technique to deal with aarch64 ASLR problems to exploit it though.
Neither has an obvious signature bypass.
Still need to someone to provide a bootloader dump to look there.

[VsnGamer]

I've been trying to understand how the app connects via SSH into the router when you are in the same network.

According to the logs in the web interface it seems to use password auth but username seems null.

Also noticed the dropbear binary seems slightly modified (something to do with TPM, runs fw_input.sh add to allow traffic).

I'll try to decrypt the HTTPS traffic later, although it might get complicated if certificate pinning is done in a custom way.

[naf419]

I've been trying to understand how the app connects via SSH into the router when you are in the same network.

According to the logs in the web interface it seems to use password auth but username seems null.

Also noticed the dropbear binary seems slightly modified (something to do with TPM, runs fw_input.sh add to allow traffic).

I'll try to decrypt the HTTPS traffic later, although it might get complicated if certificate pinning is done in a custom way.

from looking at the binary of other deco versions and assuming it also applies to BE85, my understanding is that the dropbear binary is customized to remove interactive login shells completely (leaving only port forwarding to two specific ports) and the username auth module that should check etc/password is replaced with a module that looks up userpass in openwrt-style uci config. that uci config is populated based on info sent down from the deco server and same info goes to app so it can port-forward. the port-forward exposes the tmpsvr binary so that openwrt config can be passed via custom protocol from main router to devices on mesh. see also: https://github.com/naf419/tplink_deco_exploits/tree/main/rsa