Connect with us
https://cybersecuritynews.site/wp-content/uploads/2021/11/zox-leader.png

Published

on

The Ultimate Managed Hosting Platform

August Patch Tuesday tackles 121 CVEs, 17 crucial bugs and one zero-day bug exploited within the wild.

The Ultimate Managed Hosting Platform

Source link

Continue Reading

Vulnerabilities

Technical Advisory – Multiple Vulnerabilities in Juplink RX4-1800 WiFi Router (CVE-2022-37413, CVE-2022-37414)

Published

on

Technical Advisory – Multiple Vulnerabilities in Juplink RX4-1800 WiFi Router (CVE-2022-37413, CVE-2022-37414)

The Ultimate Managed Hosting Platform

Juplink’s RX4-1800 WiFi router was discovered to have a number of vulnerabilities exposing its house owners to potential intrusion of their native WiFi community and full overtake of the machine. An attacker can remotely take over a tool after utilizing a focused or phishing assault to alter the router’s administrative password, successfully locking the proprietor out of their machine.

Two vulnerabilities had been uncovered, with hyperlinks to the related technical advisories beneath:

  • Technical Advisory: CSRF Vulnerability in Juplink RX4-1800 WiFi Router (CVE-2022-37413)
  • Technical Advisory: Lack of Present Password Validation for Password Change Performance (CVE-2022-37414)

Technical Advisories:

CSRF Vulnerability in Juplink RX4-1800 WiFi Router (CVE-2022-37413)

Vendor: Juplink
Vendor URL: https://www.juplink.com
Variations Affected: All Variations
Techniques Affected: RX4-1800
CVE Identifier: CVE-2022-37413
Severity: Excessive 7.5 (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H)

Abstract

The Juplink RX4-1800 WiFi router is a normal shopper Wifi router that gives an online interface for configuration. The browser interface of the router was discovered to be susceptible to cross-site request forgery (CSRF).

Impact

The WiFi router interface is vulnerable to CSRF. An attacker can trick a user into making unintended state-changing requests to the application, including changing the admin account password.

Details

Cross-Site Request Forgery (CSRF) is an attack that occurs when a user interacts with a malicious web site while logged into a vulnerable web application in the same browser. The malicious web site can cause the user’s browser to submit requests to the vulnerable application, causing various state-changing requests to be made in the context of the victim’s active session.

If the user is logged into the router web interface, an attacker could create a page like the example below and trick a user into clicking it to change the router administrative account password to any password of the attacker’s choosing.

Recommendation

This issue will remain exploitable to authenticated users as long as the vendor doesn’t fix it through a router firmware update.

Lack of Current Password Validation for Password Change Functionality (CVE-2022-37414)

Vendor: Juplink
Vendor URL: https://www.juplink.com
Versions Affected: All Versions
Systems Affected: RX4-1800
CVE Identifier: CVE-2022-37414
Severity: Medium 6.8 (CVSS v3.1 AV:A/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H)

Summary

The Juplink RX4-1800 WiFi router is a general consumer WiFi router that provides a web interface and admin account for configuration. It was found that the router web interface has insecure password change functionality.

Impact

An attacker can change the password of the admin account.

Details

There is password change functionality, referred to as ‘Modify Password’, located at the /nm_security.htm endpoint. When performing a password change, the user is asked to provide the old password. If the ‘Old Password’ field is blank or incorrect, an alert box is presented that says, “The old password is wrong!”

Use an interception proxy to inspect the HTTP POST request that is made when a valid password change request is submitted. You will see in the example POST request below that the old password is not included as a parameter in the body of the request, therefore there is no server-side validation of the old password. An attacker can use Cross-Site Request Forgery to trick the user and send a request to the web interface to change the password of the router’s admin account to one of the attacker’s choosing.

Recommendation

This issue will remain exploitable to authenticated users as long as the vendor doesn’t fix it through a router firmware update.

Disclosure Timeline:

July 1, 2022: Initial email from NCC to Juplink announcing to vendor that vulnerabilities were found in one of their devices.

August 12, 2022: NCC reached out to Juplink again to inform of the intent to publicly disclose the vulnerabilities unless they responded to us within the next 30 days.

September 22 2022: NCC Group informs Juplink that we will now be publishing all associated Technical Advisories for these vulnerabilities. 

As of the publishing date of this Technical Advisory, no response from Juplink has been received.

Thanks to

Nicolas Bidron, Andrea Shirley-Bellande, Jennifer Fernick, and David Goldsmith for their support throughout the research and disclosure process.

About NCC Group

NCC Group is a global expert in cybersecurity and risk mitigation, working with businesses to protect their brand, value and reputation against the ever-evolving threat landscape. With our knowledge, experience and global footprint, we are best placed to help businesses identify, assess, mitigate & respond to the risks they face. We are passionate about making the Internet safer and revolutionizing the way in which organizations think about cybersecurity.

The Ultimate Managed Hosting Platform

Source link

Continue Reading

Vulnerabilities

There’s Another Hole In Your SoC: Unisoc ROM Vulnerabilities

Published

on

There’s Another Hole In Your SoC: Unisoc ROM Vulnerabilities

The Ultimate Managed Hosting Platform

UNISOC (previously Spreadtrum) is a quickly rising semiconductor firm that’s these days centered on the Android entry-level smartphone market. Whereas nonetheless a uncommon sight within the west, the corporate has nonetheless achieved spectacular progress claiming 11% of the worldwide smartphone utility processor market, in response to Counterpoint Research. Just lately, it’s been making its means into a number of the finances telephones produced by identify manufacturers similar to Samsung, Motorola and Nokia; and the most recent 5G chipset advertises a powerful 6nm course of.

Regardless of this speedy progress, little analysis has been printed that validates the safety of the general UNISOC platform’s boot course of; and to this point prior analysis has been centered on the kernel drivers and the modem. With Google’s continued investments into the safety of AOSP, lately typically the weakest hyperlinks in Android telephones safety are discovered within the semiconductor vendor or OEM additions. For instance, pre-installed vendor purposes, vendor kernel drivers, in addition to the elements of a customized safe boot chain are the place many main vulnerabilities are being found.

Thus, for consumer privateness and safety it’s essential that the muse, similar to bootloaders and vendor drivers, upon which Android builds up, are sufficiently secured.

As a part of this analysis, NCC Group centered on the safe boot chain applied by UNISOC processors utilized in Android telephones and tablets. A number of vulnerabilities within the Boot ROM have been found which may persistently undermine safe boot. These vulnerabilities could possibly be exploited by malicious software program which beforehand escalated its privileges with a view to insert a persistent undetectable backdoor into the boot chain, or by a neighborhood adversary with bodily entry to the machine exploiting the restoration mode current on these gadgets.

Step one required previous to analyzing the BootROM is to extract its binary. Whereas second-stage bootloaders are sometimes available from Android firmware replace packages, and are generally saved with none encryption, that isn’t the case for the BootROM code. Since it’s baked into the processor’s silicon, there may be little cause for a vendor to offer simply accessible and auditable firmware binaries, and maybe there are incentives to not make it too simply accessible within the hopes of creating potential vulnerabilities more durable to find. Whatever the precise cause, this type of secrecy results in further work on researchers’ behalf with a view to initially achieve entry to the executable binary.

After setting our sights on a number of trendy UNISOC chipsets, NCC Group has obtained a number of UNISOC SoC-based gadgets:

  • Teclast T40 Plus, based mostly on the UNISOC Tiger T618 system-on-a-chip
  • Motorola Moto E40, based mostly on the UNISOC Tiger T700 system-on-a-chip
  • Teclast T40 5G, based mostly on the UNISOC Tangula T740 system-on-a-chip

Amongst these, the Teclast gadgets have been beforehand documented to reuse the default UNISOC personal key for signing its bootloaders that was freely available on GitHub. Moreover, because it turned out, the safe boot fuses weren’t burned on the Teclast gadgets and an arbitrary binary could possibly be booted using the system’s restoration protocol. Thus, the BootROM binary was dumped off these two gadgets with little effort, and was confirmed to be dated 2018-05-28 on the T618 and 2017-05-08 on the T740 machine.

The Motorola machine, then again, did allow safe boot with a customized vendor key, so it was not possible to dump the BootROM using the identical shortcut. As an alternative, NCC Group needed to reverse engineer FDL1, which is the second-stage restoration mode bootloader, and within the course of found a buffer overflow vulnerability which allowed for arbitrary code to be executed and dumped the T700 BootROM by way of these means. Because it seems, nevertheless, the T700 BootROM is precisely the identical because the T618 one, all the way down to the date code marking current throughout the binary.

This vulnerability in FDL1 is described under.

Discovering #1: Buffer Overflow in FDL1 USB Restoration Mode When Transferring Knowledge (CVE-2022-38693)

  • NCC Group’s General Threat Evaluation: Excessive

FDL1 is a part of the UNISOC restoration course of that’s usually loaded from the host by the BootROM. FDL1 initializes system reminiscence and masses the second-stage restoration payload, FDL2, from the host over a customized USB protocol. A buffer overflow problem exists within the operate answerable for retrieving the information, reproduced in pseudocode under:

lengthy usb_get_packet(byte *dst) {
  ...
  state = 0;
  is_masked = false;
  writeptr = dst;
  do {
    if (DAT_00014c40 == DAT_00014c10) {
      DAT_00014c40 = 0;
      DAT_00014c10 = 0;
      do {
        FUN_0000f460();
      } whereas (DAT_00014c10 == 0);
      DAT_00014c14 = DAT_00014c28;
      DAT_00014c28 = DAT_00014c28 ^ 1;
    }
    uVar2 = DAT_00014c10;
    pbVar3 = (byte *)(DAT_00014bc0 + (ulong)DAT_00014c40);
    whereas (DAT_00014c40 *writeptr = bVar1 ^ 0x20;
            is_masked = false;
            writeptr = writeptr + 1;
          } else {
            *writeptr = bVar1;
            state = 2;
            writeptr = writeptr + 1;
          }
        }
      } else if (state == 0) {
        state = *pbVar3 == 0x7e;
      } else if (state == 2) {
        if (*pbVar3 == 0x7e) {
          return (lengthy)writeptr - (lengthy)dst;
        }
        goto LAB_0000fc70;
      }
      pbVar3 = pbVar3 + 1;
    }
  } whereas( true );
}

Be aware that the operate doesn’t implement the utmost dimension of a payload that it could possibly obtain. Because of this, a bunch can ship a really giant payload and trigger a world buffer overflow, doubtlessly leading to arbitrary code being executed inside FDL1.

Particularly, NCC Group found that on a tool based mostly on the UNISOC T700 chipset, the momentary buffer is pointing into FDL1 executable reminiscence. Subsequently, exploiting this bug permits us to overwrite reminiscence coaching code that’s now not wanted after machine initialization. If the overwrite is giant sufficient, it’s potential to overwrite the next executable code that’s nonetheless getting used, and execute arbitrary code throughout the context of FDL1.

NCC Group efficiently exploited this vulnerability with a view to acquire code execution throughout the FDL1 on the Moto E40 machine and dump its BootROM.

A number of frequent challenges come up when reverse-engineering a typical BootROM. Few, if any, debugging strings can be found, and the code typically makes use of undocumented {hardware} registers or numerous lower-speed peripheral interfaces. For instance, as an alternative of organising a quick DMA switch between eMMC flash and the principle reminiscence, code for which may sometimes be referenced in open-source Linux drivers, the BootROM might use a slower and easier PIO interface, that is probably not publicly documented or applied. However, by finding commonplace bootloader constructing blocks similar to UART interfaces, USB setup packet parsing, and RSA signature validation it’s potential to determine the general design and implementation of the BootROM.

Within the case of UNISOC, the BootROM is a reasonably easy binary blob that takes up simply round 35 kilobytes of code. Two power-on boot modes are applied: common boot in addition to restoration boot which is entered when both a particular key’s held on energy up, or the second-stage bootloader is lacking or fails to validate. The restoration protocol itself is analogous to what’s current on the older UNISOC/Spreadtrum feature-phones, with the identical algorithms used for CRC calculation and HDLC protocol wrapping.

Upon finding the code answerable for the implementation of the UNISOC BootROM restoration mode, NCC Group found that it lacked most of validity checks on the enter information. A number of vulnerabilities have been rapidly discovered that allowed for arbitrary code execution throughout the BootROM. All of those will be reachable by an attacker that has temporary bodily entry to the machine as booting a UNISOC telephone or a pill into restoration mode solely requires holding a particular button (sometimes quantity down) throughout energy up. The vulnerabilities under are listed within the order of lowering severity.

Discovering #2: Unchecked Write Tackle (CVE-2022-38694)

  • NCC Group’s General Threat Evaluation: Excessive

The restoration mode applied by UNISOC exposes 5 instructions that are accessible over UART and USB interfaces with the aim of loading and beginning the next-stage payload, FDL1.

The information switch initialization command, cmd_start, was discovered to not carry out any checks towards the attacker-controlled goal handle of the payload:

void cmd_start(cmd_start_t *payload)
{
  uint write_addr_be;
  uint write_sz_be;

  write_addr_be = payload->addr_be;
  write_sz_be = payload->sz_be;
  // NCC: huge endian byte-swap
  g_write_addr = (ulong)((write_addr_be ^ (write_addr_be >> 0x10 | write_addr_be > 8 &
                         0xff00ff ^ (write_addr_be >> 8 | write_addr_be > 0x10 | write_sz_be > 8 & 0xff00ff ^
                      (write_sz_be >> 8 | write_sz_be 

Subsequent, when the information switch command, cmd_recv_data, is repeatedly executed, it writes attacker-controlled information to the attacker-controlled g_cur_write_ptr pointer after which advances it by the dimensions of the information:

void cmd_recv_data(cmd_recv_data_t *payload)
 (payload->size_be & 0xff) g_cur_write_ptr,payload->information,sz);
  g_cur_write_ptr = g_cur_write_ptr + sz;
  g_num_received = g_num_received + sz;
  send_status(0x80);
  return;

Because of this, these two instructions present an arbitrary write primitive into the BootROM’s reminiscence area. This performance may then be utilized by an attacker with bodily entry to the machine to overwrite a operate pointer someplace within the BootROM information part or a return handle saved on the stack and execute their very own code with BootROM privileges.

Discovering #3: Unchecked Command Index (CVE-2022-38695)

  • NCC Group’s General Threat Evaluation: Medium

The implementation of the USB command dispatcher is reproduced under in pseudocode:

void recovery_comms(void)
{
  uint uVar1;
  payload_t *buf;
  undefined4 len;

  do {
    whereas (uVar1 = receive_and_validate_payload(&buf,&len), uVar1 == 0x8f) {
      (*(code *)(&g_func_table)
                [(ulong)((uint)((ulong)buf->cmd_be >> 8) | (uint)buf->cmd_be 

Note that the global array g_func_table is indexed with the arbitrary 16-bit argument (buf->cmd_be) which is not validated against the size of the array. Because the array only contains 5 elements, passing a command value greater than 4 would result in data past the end of the array being treated as a function pointer and the BootROM attempting to execute code at that location.

In the worst case scenario, this could result in arbitrary attacker-controlled code being executed within the context of the BootROM. However, because this array is located in the read-only BootROM memory region, and there is no obvious path to implant an attacker-controlled value nearby, the Overall Risk of this finding is reduced to Medium.

Finding #4: Unchecked Write into a Global Buffer (CVE-2022-38696)

  • NCC Group’s Overall Risk Assessment: Medium

The USB data transfer function is reproduced below in pseudocode:

void receive_payload_usb(void)
{
  byte *pbVar1;
  byte ch;
  undefined4 local_4;

  local_4 = 0;
  while (g_recv_status != 3) {
    ch = get_byte_from_usb(&local_4);
    if (g_recv_status == 1) {
      if (ch != 0x7e) {
        if (ch == 0x7d) {
          ch = get_byte_from_usb(&local_4);
          ch = ch ^ 0x20;
        }
        g_recv_status = 2;
        pbVar1 = g_output_ptr + 1;
        *g_output_ptr = ch;
        g_output_ptr = pbVar1;
        g_written_len = g_written_len + 1;
      }
    }
    else if (g_recv_status == 0) {
      if (ch == 0x7e) {
        g_recv_status = 1;
      }
    }
    else if (g_recv_status == 2) {
      if (ch == 0x7e) {
        g_recv_status = 3;
      }
      else {
        if (ch == 0x7d) {
          ch = get_byte_from_usb(&local_4);
          ch = ch ^ 0x20;
        }
        pbVar1 = g_output_ptr + 1;
        *g_output_ptr = ch;
        g_output_ptr = pbVar1;
        g_written_len = g_written_len + 1;
      }
    }
  }
  return;
}

The data is read byte-by-byte from the host and unmasked using an HDLC-like algorithm. Because there is no length checking performed against the received data, a host that sends a large payload could overflow the fixed-size BootROM buffer, resulting in memory corruption within the BootROM and potentially code execution.

The same issue exists in the UART data transfer function, receive_payload_uart(), located at address 0x104924 in the BootROM.

Note that while the global buffer is located close to the end of BootROM memory and past the stack region, and it is not possible to trivially obtain code execution by overwriting a return pointer, an adversary may instead attempt to write to a memory-mapped hardware device instead that is present on the system and induce a controllable memory corruption that way.

Finding #5: Lack of USB wLength Validation

  • NCC Group’s Overall Risk Assessment: Low

The USB setup packet handler contains a vulnerability where it does not properly validate the value of wLength for requests of type GET_STATUS:

void handle_setup_request(void)
{
    ...
    reqTypeBit = g_setup.bmRequestType >> 5 & 3;
      ...
      if (g_setup.bRequest == 0) {
        bVar2 = cRead_1(DAT_5fff0012);
        cWrite_1(DAT_5fff0012,bVar2 | 0x40);
        idx = 0;
        if (CONCAT11(g_setup.wLength._1_1_,(undefined)g_setup.wLength) != 0) {
          do {
            cWrite_1(usb_txrx,(&DAT_00004010)[idx]);
            idx = idx + 1;
          } whereas (idx );
        }
        bVar2 = cRead_1(DAT_5fff0012);
        cWrite_1(DAT_5fff0012,bVar2 | 10);
        return;
      }
    ...
    else if (reqTypeBit == 2) {
      bVar2 = cRead_1(DAT_5fff0012);
      cWrite_1(DAT_5fff0012,bVar2 | 0x40);
      idx = 0;
      if (CONCAT11(g_setup.wLength._1_1_,(undefined)g_setup.wLength) != 0) {
        do {
          cWrite_1(usb_txrx,(&DAT_00004010)[idx]);
          idx = idx + 1;
        } whereas (idx );
      }
      bVar2 = cRead_1(DAT_5fff0012);
      cWrite_1(DAT_5fff0012,bVar2 | 10);
    }
    ...
}

Because of this, sending a GET_STATUS setup request with a big wLength worth would disclose reminiscence previous the tip of the DAT_00004010 world variable.

Discovering #6: Lack of Payload Dimension Validation

  • NCC Group’s General Threat Evaluation: Low

The implementation of the USB command dispatch is reproduced under in pseudocode:

void recovery_comms(void)
{
  uint uVar1;
  payload_t *buf;
  undefined4 len;

  do {
    whereas (uVar1 = receive_and_validate_payload(&buf,&len), uVar1 == 0x8f) {
      (*(code *)(&g_func_table)
                [(ulong)((uint)((ulong)buf->cmd_be >> 8) | (uint)buf->cmd_be 

Note how two arguments are passed further to the implementation: the payload buffer and its size. However, as NCC Group has discovered, the implementation does not actually validate the size of the received payload:

void cmd_start_usb(cmd_start_t *payload)
 write_sz_be sz = (ulong)((uint)((ulong)payload->size_be >> 8) 

In particular, cmd_start_usb retrieves write address and size from the payload buffer without validating that the payload buffer is at least 12 bytes (2 bytes header, 2 bytes padding, 4 bytes for addr_be and 4 bytes for sz_be), and cmd_recv_data_usb copies data of sz bytes from the payload without validating the amount of data present. As a result, uninitialized memory values may be unintentionally copied. Then, by attempting to execute the resulting image, and observing the returned error code, it may be possible for an adversary to disclose portions of the BootROM memory.

Additionally, the same issue exists in the UART recovery command handlers cmd_start_uart and cmd_recv_data_uart.

After discovering the issues in the recovery mode, NCC Group’s focus shifted to the regular boot process. The UNISOC BootROM implements a secure boot chain with the root key anchored within the BootROM by utilizing eFuses. Every stage in the boot process is then responsible for validating the signature of the next stage. As such, compromising an early boot stage, such as BootROM validation of the second-stage bootloader, would allow for a complete takeover of the rest of the system.

One vulnerability was discovered in the loading of second-stage executables. Since this code is used for both the regular boot and the recovery boot, exploitation of this single vulnerability allows for a persistent compromise of the system.

Finding #7: Lack of Certificate Type 0 Validation results in Memory Corruption (CVE-2022-38691, CVE-2022-38692)

  • NCC Group’s Overall Risk Assessment: Critical

The second-stage bootloader loaded by the BootROM contains a certificate as a part of its image. This certificate includes a public RSA key to validate the current image, as well as hash of the next public RSA key in the boot process. This creates a secure boot chain that is ultimately anchored by the BootROM to a hash of the first public RSA key stored in eFuses. However, a vulnerability is present in the BootROM where the hash of the public RSA key is not always properly validated.

Specifically, the BootROM accepts two types of certificates: 0 (contentcert) and 1 (keycert). According to the UNISOC’s U-Boot source code, the keycert embeds a hash of the next public key, creating a secure boot chain, whereas the contentcert does not and appears to be used as the last certificate in the chain. Normally, a certificate of type 1 is embedded within the second-stage bootloader and in this case the BootROM properly validates its public RSA key against eFuses. However, in the case where the certificate of type 0 is used, no such validation is performed as can be seen from the second if condition branch in the pseudocode snippet below:

undefined8 validate_rsa(byte *fused_key_hash,byte *calculated_payload_hash,cert_t *cert)
{
  ...
  certtype = *(byte *)&cert->certtype;
  memset(decrypted_sig,0,0x100);
  pubkey_hash._0_8_ = 0;
  pubkey_hash._8_8_ = 0;
  pubkey_hash._16_8_ = 0;
  pubkey_hash._24_8_ = 0;

  if (certtype type == 1) && (g_min_required_ver version)) {
        calculate_hash(&cert1->pubkey,((cert1->pubkey).keybit_len >> 3) + 8,pubkey_hash);
        iVar1 = memcmp(calculated_payload_hash,cert1->hash_data,0x20);
        if ((iVar1 == 0) && (iVar1 = memcmp(fused_key_hash,pubkey_hash,0x20), iVar1 == 0)) {
          local_4 = do_rsa_powmod(&(cert1->pubkey).e, (cert1->pubkey).n,
                                  (cert1->pubkey).keybit_len, cert1->signature,
                                  decrypted_sig);
          calculate_hash(cert1->hash_data,0x48,hashed_contents);
          validate_sig_oaep(hashed_contents,0x20,decrypted_sig,0x100,0x20,0x2000004,0x2000004,
                            0x800,&local_4);
          is_valid = 1;
          if (local_4 != 0) {
            set_flag(0x2000000000);
            is_valid = 0;
          }
        } else {
          set_flag(0x400000000);
          is_valid = 0;
        }
      } else {
        set_flag(0x8000000000);
        is_valid = 0;
      }
    }
    else if ((cert0->type == 1) && (g_min_required_ver version)) {
      calculate_hash(&cert0->pubkey,((cert0->pubkey).keybit_len >> 3) + 8,pubkey_hash);
      // NCC: No call to memcmp pubkey_hash
      iVar1 = memcmp(calculated_payload_hash,cert0->hash_data,0x20);
      if (iVar1 == 0) {
        local_4 = do_rsa_powmod(&(cert0->pubkey).e, (cert0->pubkey).n,
                                (cert0->pubkey).keybit_len, cert0->signature,
                                decrypted_sig);
        calculate_hash(cert0->hash_data,0x48,hashed_contents);
        validate_sig_oaep(hashed_contents,0x20,decrypted_sig,0x100,0x20,0x2000004,0x2000004,
                          0x800,&local_4);
        is_valid = 1;
        if (local_4 != 0) {
          set_flag(0x2000000000);
          is_valid = 0;
        }
      } else {
        set_flag(0x400000000);
        is_valid = 0;
      }
    } else {
      set_flag(0x8000000000);
      is_valid = 0;
    }
  } else {
    set_flag(0x1000000000);
    is_valid = 0;
  }
  return is_valid;
}

As a result, an arbitrary public RSA key could be provided by an adversary with the certificate type set to 0. Several possibilities then exist for potential exploitation of this issue.

Crafted RSA Signature

Since an adversary now controls the public RSA key, an obvious avenue to exploit this vulnerability would be to craft a legitimate signature for an arbitrary bootloader image. However, an additional issue exists in the BootROM in the following snippet:

local_4 = do_rsa_powmod(&(cert0->pubkey).e,(cert0->pubkey).n,(cert0->pubkey).keybit_len,
                        cert0->signature,decrypted_sig);
calculate_hash(cert0->hash_data,0x48,hashed_contents);
validate_sig_oaep(hashed_contents,0x20,decrypted_sig,0x100,0x20,0x2000004,0x2000004,0x800,
                  &local_4);

Consider the definition of both cert0_t and cert1_t structures:

struct cert0_t {
    uint certtype;
    struct pubkey_t pubkey;
    byte hash_data[32];
    uint kind;
    uint model;
    byte signature[256];
};

struct cert1_t {
    uint certtype;
    struct pubkey_t pubkey;
    byte hash_data[32];
    byte hash_key[32];
    uint kind;
    uint model;
    byte signature[256];
};

Be aware that a further 32-byte hash_key area exists within the cert1_t construction. The intent of passing dimension 0x48 to the calculate_hash operate is to seize all of hash_data, hash_key, kind and model variables within the hash. Nevertheless, when coping with the certificates kind 0, the hash_key area doesn’t exist, and so a 32-byte chunk of the signature is calculated as a part of the hash that’s then validated utilizing RSA-OAEP. As a result of implementation particulars, NCC Group was unable to craft a legitimate signature that might bypass this test.

Buffer Overflow when Studying the Key

One other problem is current within the RSA validation performance that might lead to a reminiscence corruption occurring throughout the BootROM. Previous to performing the RSA operation, a byte-swap is carried out and the consequence saved in a world buffer in BootROM reminiscence:

undefined4 do_rsa_powmod(undefined8 e,undefined8 n,undefined4 bits,undefined8 sig,undefined8 dst)
{
  undefined4 uVar1;

  memset(BYTE_ARRAY_00002988,0,0x100);
  uVar1 = FUN_001059ec(e,n,bits,sig,BYTE_ARRAY_00002988);
  memcpy2(dst,BYTE_ARRAY_00002988,0x100);
  return uVar1;
}

undefined8 FUN_001059ec(undefined8 e,undefined8 n,int bits,undefined8 sig,undefined8 dst)
{
  FUN_00105514(dst,sig,n,e,bits >> 3);
  return 0x100;
}

void FUN_00105514(undefined8 dst,undefined8 sig,lengthy n,lengthy e,uint bytelen)
{
  DAT_00004420 = 0;
  DAT_00004428 = 0;
  DAT_00004430 = 0;
  DAT_00004438 = 0;
  DAT_00004440 = 0;
  memset(g_n,0,0x800);
  if (e != 0) {
    byteswap_for_rsa(g_e,e,4);
  }
  if (n != 0) {
    byteswap_for_rsa(g_n,n,bytelen);
  }
  byteswap_for_rsa(g_sig,sig,bytelen);
  DAT_00004420 = 0xe1000010e0c0001;
  DAT_00004428 = CONCAT44(0xb0002168,(bytelen & 0xffff) 

As a result of no dimension test is carried out towards the RSA key dimension, a key higher than 2048 bits would overflow the worldwide g_n and g_sig buffers that are 256 bytes in dimension. These buffers are situated at addresses 0x2168 and 0x2268. For the reason that stack pointer is ready to 0x4000 throughout BootROM initialization, a big RSA key is ready to corrupt the saved return handle on the stack after which trigger arbitrary code to be executed. For the reason that weak RSA key parsing is reachable from each the restoration and common boot modes, this vulnerability could possibly be exploited for persistent code execution throughout the BootROM context.

Regardless of a reasonably minimal characteristic set and a small dimension of its binary, the UNISOC BootROM was discovered to comprise a number of high-impact vulnerabilities, doubtlessly affecting hundreds of thousands of shipped gadgets. Whereas these points can’t be fastened because of the read-only nature of the BootROM code, customers can cut back their threat by not leaving their gadgets unattended, and putting in newest software program updates to mitigate the danger of CVE-2022-38691/CVE-2022-38692 being persistently exploited by way of a brief privilege escalation.

  • Might twenty sixth: NCC Group makes an attempt to contact UNISOC by emailing the [email protected] handle. This preliminary contact try is unsuccessful resulting from an error returned by the UNISOC mail server.
  • Might thirty first: NCC Group makes an attempt direct e mail contact with a number of members of the UNISOC safety workforce.
  • June 2nd: NCC Group receives UNISOC’s PGP key and confirmed that the beforehand encountered mail server problem is now resolved.
  • June 2nd: Vulnerability report submitted to UNISOC.
  • June sixth: UNISOC confirms receipt of the report; NCC Group follows-up by asking to publicly disclose the report on July sixth.
  • June fifteenth: UNISOC requests to delay the disclosure timeline by 8 weeks; NCC Group accepts disclosure date of August tenth.
  • July sixth: NCC Group asks UNISOC for an replace to make sure every little thing is on observe for August tenth. We didn’t obtain a response.
  • July 18th: NCC Group requests an replace. We didn’t obtain a response.
  • July twenty eighth: NCC Group asks for an additional replace and reminds UNISOC that the embargo deadline is lower than 2 weeks away.
  • August 2nd: NCC Group requests CVE task from MITRE. This request is subsequently denied on August 4th as UNISOC has signed up as a CVE CNA within the meantime.
  • August fifth: UNISOC responds and confirms they’ve requested CVE numbers and likewise asks to increase the advisory date to September 2nd.
  • August twenty third: NCC Group requests an replace from UNISOC together with details about the assigned CVE numbers.
  • August twenty ninth: UNISOC units up a gathering throughout which it requests one other extension of as much as 3 months. NCC Group opts to publish on the beforehand agreed upon date.
  • September 1st: UNISOC responds to NCC Group, offering requested CVE numbers.
  • September 2nd: Publication of this advisory.

The Ultimate Managed Hosting Platform

Source link

Continue Reading

Vulnerabilities

Cybercriminals Are Selling Access to Chinese Surveillance Cameras

Published

on

Cybercriminals Are Selling Access to Chinese Surveillance Cameras

The Ultimate Managed Hosting Platform

Tens of hundreds of cameras have didn’t patch a important, 11-month-old CVE, leaving hundreds of organizations uncovered.

New research signifies that over 80,000 Hikvision surveillance cameras on the planet at this time are susceptible to an 11 month-old command injection flaw.

Hikvision – brief for Hangzhou Hikvision Digital Expertise – is a Chinese language state-owned producer of video surveillance tools. Their prospects span over 100 nations (together with the US, regardless of the FCC labeling Hikvision “an unacceptable danger to U.S. nationwide safety” in 2019).

Final Fall, a command injection flaw in Hikvision cameras was revealed to the world as CVE-2021-36260. The exploit was given a “important” 9.8 out of 10 score by NIST.

Regardless of the severity of the vulnerability, and practically a 12 months into this story, over 80,000 affected units stay unpatched. Within the time since, the researchers have found “a number of situations of hackers seeking to collaborate on exploiting Hikvision cameras utilizing the command injection vulnerability,” particularly in Russian darkish net boards, the place leaked credentials have been put up on the market.

The extent of the harm carried out already is unclear. The authors of the report may solely speculate that “Chinese language risk teams reminiscent of MISSION2025/APT41, APT10 and its associates, in addition to unknown Russian risk actor teams may doubtlessly exploit vulnerabilities in these units to satisfy their motives (which can embody particular geo-political concerns).”

The Threat in IoT Gadgets

With tales like this, it’s straightforward to ascribe laziness to people and organizations that depart their software program unpatched. However the story isn’t all the time so easy.

Based on David Maynor, senior director of risk intelligence at Cybrary, Hikvision cameras have been susceptible for a lot of causes, and for some time. “Their product comprises straightforward to take advantage of systemic vulnerabilities or worse, makes use of default credentials. There isn’t any good technique to carry out forensics or confirm that an attacker has been excised. Moreover, we have now not noticed any change in Hikvision’s posture to sign a rise in safety inside their improvement cycle.”

A whole lot of the issue is endemic to the business, not simply Hikvision. “IoT units like cameras aren’t all the time as straightforward or easy to safe as an app in your telephone,” Paul Bischoff, privateness advocate with Comparitech, wrote in an announcement through e mail. “Updates will not be computerized; customers must manually obtain and set up them, and plenty of customers may by no means get the message. Moreover, IoT units may not give customers any indication that they’re unsecured or outdated. Whereas your telephone will warn you when an replace is on the market and certain set up it mechanically the following time you reboot, IoT units don’t supply such conveniences.”

Whereas customers are none the wiser, cybercriminals can scan for his or her susceptible units with search engines like google like Shodan or Censys. The issue can actually be compounded with laziness, as Bischoff famous, “by the truth that Hikvision cameras include one of some predetermined passwords out of the field, and plenty of customers don’t change these default passwords.”

Between weak safety, inadequate visibility and oversight, it’s unclear when or if these tens of hundreds of cameras will ever be secured.

 

The Ultimate Managed Hosting Platform

Source link

Continue Reading

Trending