Vai al contenuto
Home » Alcune lezioni dal primo tentativo fallito per l’OSCP

Alcune lezioni dal primo tentativo fallito per l’OSCP

Sono passati alcuni mesi dall’ultimo post. E’ arrivato
WannaCry, è arrivata Petya /
NotPetya

e i media generalisti hanno scoperto il malware e la sicurezza informatica.

E’ stato bucato
Rousseau
e dati di molti militanti del Movimento 5 Stelle sono ora in vendita sul web.

Mentre il mondo ITSEC italiano si sbizzarriva su Twitter su vari temi, io ero impegnato a tentare l’assalto all’OSCP.

5 punti

Partiamo subito con l’esito, servivano almeno 70 punti per passare ed in un
torrido 1 Agosto, mi sono fermato a 65 punti con 3 root flag, una shell con
privilegi non elevati e una macchina con una SQL Injection trovata e sfruttata
ma senza ottenere una shell. Quindi, nonostante un buon report, bocciato.

Ho ricevuto l’esito 1 giorno e mezzo dopo, come da prassi, e smaltita la
delusione provo a buttare qui sul blog qualche errore che ho commesso, nella
speranza di raggiungere l’obiettivo massimo questo autunno.

Io e me

Di solito sono iper critico con me stesso. Basta poco per farmi vedere difetti
ovunque e far precipitare la mia autostima sotto le scarpe.

In questo caso, però, non ce l’ho fatta a non vedere il bicchiere pieno per
3/4. Avevo fatto un buon esame, praticamente rinfrescando concetti che non
toccavo più dai tempi del SiLAB all’Università.

Mi sono perso in un effetto tunnel, quando ho carcato di sfruttare il mio unico
tentativo con Metasploit, per sfruttare una MS17-010 perdendo un po’ di tempo.
Sono andato liscio su alcune cose che mi sarei aspettato più ostiche e sono
arrivato stremato dopo quasi 19 ore di lavoro.

Quindi, possiamo dire bocciato ma soddisfatto, il prossimo tentativo
andrà meglio, anche perché vorrò evitare questi errori, queste lezioni.

Cosa ho imparato

  1. Usare una versione di Kali a 32 bit, o comunque tenere una macchina Linux a
    32 bit per compilare exploit vecchi, magari in maniera statica.
  2. Non sottovalutare MAI il laboratorio dell’OSCP. Con i 5 punti che avrei
    avuto facendo un buon report del laboratorio sarei passato.
  3. Avere a portata di mano una macchina Windows con Visual Studio per compilare
    exploit per Win perché, in alcuni casi, fare una compilazione cross da Linux
    ti può portare via troppo tempo.
  4. Non iniziare l’esame a mezzanotte. Seguire il flusso della giornata
    lavorativa, molto meglio iniziare alle 6 o alle 7 e fare una tirata unica
    fino alle 2 del giorno dopo.
  5. Non serve, almeno a me, pianificare le pause. Vanno fatte, piccole e
    frequenti, ma è inutile forzare la pausa ad una certa ora.
  6. Provare sempre la cosa più ovvia, come una password banale o a verificare
    quella misconfiguration vista l’ultima volta nel 2001…
  7. nmap è un caro amico, ma a volte è così lento. Pianificare con attenione le
    attività automatiche che si sa essere quelle più lunghe e dedicarsi ad altro
    mentre gli strumenti macinano.
  8. Metasploit è utile ma non indispensabile, mentre msfvenom è fondamentale
  9. Pianificare prima, le attività di test. Durante l’esame sale comunque
    l’adrenalina e lo stress, la mente si appanna quindi serve un piano di
    battaglia almeno macroscopico delle attività da fare durante la
    ricognizione.
  10. Niente è impossibile. #tryharder non è messo lì per caso e durante il
    percorso per l’OSCP è l’attitudine a non mollare che fa la differenza.

Off by one

A settembre, con calma estenderò il laboratorio e ripianificherò l’esame per
l’autunno. Nel frattempo, ho trovato un po’ di siti dove vengono date macchine
da testare e challenge da risolvere e si farà pratica.

Ci sarà poi una piccola migrazione dei contenuti di Codice Insicuro. Post come
questi, non li vedrete più qui ma su uno spazio diverso, più blog personale. Su
Codice Insicuro ci saranno post leggermente diversi e introdurrò la doppia
lingua.

Enjoy it!

Tag:

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *