ASUS POC cleanup

[theweefies]

I’ve been working through the POC for ASUS, wanted to drop a note to confirm that the POC, specifically the Tpri computation does not seem to work for ASUS RT-AX86U Pro model, I’ll post the firmware version here shortly (older than what is designated as working for the non-Pro models). I set up this model as the master node with an RT-AC3100 as the slave for the AIMesh network. The 3100 does have older firmware (will post firmware version for this as well).

Is there any specific settings or a specific recommended operation mode or network architecture that needs to be implemented for this to work? Just want to make sure I’m not missing something. I am seeing the vendor specific data element in the beacon frames, and it seems to be formed properly, but the computation does not seem to be yielding TPri.

Separately, I did make some significant code cleanup for both the computation script and the pull password script that includes allowing the user to enter arguments, as well as removing the dependency on pwntools (created u32 packing and unpacking functions accounting for endianness, and using the standard socket library. I have tested the computation version of my script which works great, but have not tested the pull_password script yet to completion, should be able to today once I get my AX55 in.

Do you have any interest in incorporating these scripts into the repo? I code quite a bit in my spare time so I will likely perform some cleanup of other scripts here as well.

Thanks, look forward to hearing from you.

[zhouxinan]

All affected devices would receive a patch with the note "Fixed the ARP poisoning vulnerability. Thanks to the contribution of Xin'an Zhou". RT-AX86U Pro does look like a new model that has no such patch note.

Is there any specific settings or a specific recommended operation mode or network architecture that needs to be implemented for this to work?

No actually.

but the computation does not seem to be yielding TPri.

Try doing some reverse engineering on your cfg_server binary of your firmware?

Do you have any interest in incorporating these scripts into the repo?

Yes, welcome! Just let me know.

[theweefies]

Alright, so i'm kind of at an impasse. I have an ASUS AX55, firmware version 3.0.0.4.386_52294-g3d46867 (which should be compatible with this attack). I've tried a firmware above and below this version with both the AX86U as a node and the AC3100 as a node; all with AiMesh version 2 with different firmware versions (none that have changelog text that indicate that the patch in question was applied. The AX55 is set in Router/AiMesh Master mode, with the others set up as the slaves. I also tried setting up the AX55 as the node and the other routers as the master nodes. All links are wireless; i have not tried ethernet connection because i assume this was not the way the research was conducted.

I performed wireless capture of beacon frames for all nodes in the network, and have run my version of the script against the vendor specific hex data and mac address, as well as your version. neither yield the Tpri in any iteration.

I was able to pull the cfg_server binary from the AX55, and decompiled using Ghidra, but haven't had much time to really dig into it. I was able to run the cfg_server binary and get the cfg_group from the output; i then tried to run the script to pull the wifi password using the group_id, but this fails after attempting to retrieve the aes data. Additionally, i noticed the following output from the cfg_server that seems problematic:

json_object_from_file: error opening file /tmp/maclist.json: No such file or directory

Another thing i noticed, is that in your code, you have the cfg_ver explicitly set; this seems like this could change. I ran:

nvram get cfg_ver

And my cfg_ver is different than what is in your code, which seems like this could be problematic as well. That being said, i was able to modify this value and it does not work still.

Any ideas or clues? Could you provide some guidance to where i might look in the cfg_server binary to find the block that sets all of these values and deals with the creation of the group_id?

[zhouxinan]

I just looked into the cfg_server binary for your model and firmware version: ASUS AX55, firmware version 3.0.0.4.386_52294-g3d46867. The cfg_group algorithm is the same (vulnerable) one. The algorithm is at sub_8E7AC()/.text:0008E7AC.
Can you first grab your ground truth on ASUS AX55 3.0.0.4.386_52294-g3d46867:

nvram get lan_hwaddr
nvram get app_mnt_ts

For example, my lan_hwaddr is 04:42:1A:B4:C1:B0, and my app_mnt_ts is 1718158543, which is very near to my real value of T(pri) 1718158561. "md5 -s 04:42:1A:B4:C1:B0_1718158561" is "633ed873722e542e6ccb037737a38c5d", my real value of "nvram get cfg_group"

Can you try values near app_mnt_ts to at least confirm your real value of T(pri)?