Bene e benvenuti su Gitbar! Voi state sentendo me ridere come un povero scemo ma dovete sapere che è successo di tutto prima che partisse questa puntata a iniziare dai dieci pompieri o otto dieci quanti erano che uscivano da casa mia dieci minuti fa, al microfono di Luca che non funzionava oggi ma andiamo dritti e partiamo col nostro episodio per fortuna che ho con me i due baldi co-host che mi accompagneranno in questo episodio di oggi, altra cosa simpatica non stavo registrando la mia voce ma no worries, abbiamo Luca e Leo che ci accompagnano in questa passeggiata in un mondo tutto nuovo da scoprire, oggi parliamo di security raga come siete messi? Io sono venuto qua a imparare come sempre per cui...

Io sono stato bucato un sacco di volte quindi sarà anche ora di imparare a non essere più così lo scemo del villaggio dicevamo.

Benvenuti su Gitbar il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.

Abbiamo con noi in realtà una persona super, una di quelle persone devo dirlo che stavo corteggiando da un po' di tempo per portare qua con noi ma che finalmente ho il super super super piacere di avere qua a Gitbar.

Intanto ve lo presento, un divulgatore, blogger, infatti ha un bellissimo blog che si chiama codiceinsicuro.it, youtuber che fa degli short fantastici cioè praticamente gli short suoi e di Edo sono diventati ormai le storie che scrollo con più piacere.

Abbiamo con noi Paolo Perego, ciao Paolo.

Ciao ciao a tutti, è bellissimo essere qui con voi stasera.

In realtà io non ho detto che ufficialmente a parte la tua attività da blogger e da divulgatore tu sei prodotto prodotti security engineer a SUSE.

Sì, lavoro anche nel senso che mi occupo di tutta la parte di analisi del codice che poi va nella distribuzione che diamo alla community per quanto riguarda le anime openSUSE, leap e tumbleweed e poi tutta la parte di prodotti di SUSE Enterprise.

Insomma una grande responsabilità.

Sì, abbastanza.

Però è sempre quello che è quello che ho sempre voluto fare nella vita, fare audits del codice è un pallino che ho da credo da quando ero un giovane consulente in una società di consulenza del torinese con sede a Milano, non so se si possono fare nomi però se guardate il mio link ed in si capisce bene.

Già da lì avevo la passione per l'audit del codice.

Sono sempre stato una persona di security che amava programmare e amava rompere e anche divulgare su come scrivere codice più sicuro se vogliamo.

Per un appassionato di security penso che rompere sia uno dei verbi più usati.

Anche perché se per essere da una parte della barricata devi essere anche da quell'altra.

Certo, sì, è una dicotomia che deve funzionare per forza se tu vuoi insegnare anche solamente a una società, a una persona, come difendersi devi saperla bucare.

Non ce n'è.

Ti faccio una domanda.

Vai.

E questa la faccio al Paolo Uomo, non al Paolo Professionista.

Il fare il tuo tipo di lavoro presuppone che tu debba prestare attenzione ai dettagli.

Prestare attenzione si trasforma poi in una grande responsabilità.

Nel senso che se qualcosa ti sfugge, qualcosa sta sfuggendo a te, che sei la persona alla quale non dovrebbe sfuggire nulla di queste cose o il meno possibile.

Ecco, il meno possibile.

Come gestisci il peso di questa responsabilità da un uomo? Eh, mamma mia.

Ma non mi avevi detto che questo podcast era così pregno.

Ma mi è venuto adesso.

È una domanda di quelle molto...

Allora io personalmente, se qualcuno che sta ascoltando mi conosce, sa che ho una sindrome dell'impostore altissima.

Poi sono una persona anche molto empatica, quindi si fa molto carico degli errori, sono molto autocritico.

Quindi io quando faccio un audit vivo un buffer di tempo nel cui sono terrorizzato che qualcosa possa andare male.

E in effetti io ho anche la fortuna di avere un timing adesso sul lavoro che mette l'auditore a proprio agio.

Apro una parentesi, il compito vostro sarà di chiuderle, perché io ne apro mille.

Quando ero un consulente si sa quando si fa un audit per un cliente si hanno delle milestone molto molto rigide.

Adesso in SUSE, visto anche la sensitività di quello che andiamo a fare, abbiamo dei tempi un pochino più rilassati proprio perché dobbiamo andare nel dettaglio.

Nonostante questo io me la faccio sotto, nel senso che ho sempre paura di non vedere quella cosa macroscopica che uscirà cinque minuti dopo, un CVE che mi arriva tra il capo e il collo e ci faccio la figura del cioccolataio.

Però diciamo che è un po' il gioco delle parti, perché io parto dopo vent'anni e ho capito che il cento per cento della security non esiste e l'infallibilità non è di questo mondo e quindi di sicuro ci sarà qualche problema o qualche cosa che può andare storto e se deve andare storto lo andrà.

Per rispondere alla tua domanda, non so neanch'io come faccio a sopportarlo.

Penso di pensarci un pochino e poi non ci penso più, sono impazzisco.

Sai che in realtà quello che hai appena detto è veramente interessante.

È un tipo d'approccio che ho iniziato ad abbracciare in modo automatico quando le responsabilità hanno iniziato a scalare, cioè lo switch off automatico del pensare a quella cosa che poi rischia di immobilizzarti, dalla quale non ti muovi.

Quindi quasi in modo di un meccanismo di autoprotezione mi stacca completamente da quel tipo di responsabilità e io so che devo fare una cosa e la faccio a quel punto con la tranquillità.

Anche perché, e questo per me è importante condividere questo pensiero, l'infallibilità, cioè il fatto di non essere infallibile, non è sinonimo di essere superficiale.

Sono due cose completamente diverse.

Talvolta nel giudizio noi le confondiamo o vengono confuse.

Nel senso, è uscito un CVE vuol dire che il pen tester è stato superficiale oppure hai rotto qualcosa e hai fatto una cagata nel codice, ho fatto una cagata nel codice vuol dire che il developer è superficiale.

Non è detto.

Perché c'è tutta una serie di sfumature tra l'una e l'altro e su quale sfumature sta l'essere attenti.

Noi dobbiamo posizionarci nella più alta di queste sfumature possibili.

Esatto e infatti quando mi sono trovato ad andare a parlare con sviluppatori perché dovevi fare il corso di awareness, dovevi andare a dargli i risultati di una code review, la sfida più grande era proprio cercare di dire ho trovato una vulnerabilità ma attenzione che non sto giudicando te come professionista, ti sto dicendo che ho trovato qualcosa che è sfuggito un attimino e quindi cercare di essere il più positivo possibile in un feedback negativo che è una cosa difficilissima infatti tutti ti odiano quando sei una persona che va a dire problemi.

È proprio una roba allucinante.

Sì perché magari entra il concetto di dire che te ti senti superiore, cioè ti vedono come superiore come per dire ma che vuole questo? Cioè arrivatemi va a cliccare il codice che ho fatto però se te stai esperto esattamente di quel aspetto lì del codice quindi non stai ottimizzando delle query SQL, stai dicendo qui c'è possibilità di una SQL injection che è diverso.

Esatto ma poi perché c'è anche un altro bias molto grande che ho visto nel corso della mia carriera che spesso security e sviluppo tendono a vedersi in maniera totalmente contrapposa, totalmente slegata e io non ho fatto la mia battaglia personale io andavo a parlare ai Ruby Day, andavo a parlare nelle conferenze degli sviluppatori proprio perché la security io la dovevo portare là, dovevo imparare un altro linguaggio non dovevo andare a parlare di sviluppo sicuro nelle conferenze di security perché lì dovrebbero saperlo tutti, dovrebbero saperlo tutti.

Dovevo andare a parlarlo a gente che vedeva il codice che io bucavo da un altro punto di vista era il loro prodotto e io quindi dovevo andare a dirgli che il loro prodotto che loro avevano sviluppato secondo Sacri Crismi perché sono dei professionisti competenti aveva però delle lacune perché non vedevano un problema perché performa mentis lo vedo io che ho la mentalità dell'attaccante e quindi giustamente come dici tu era un pro una la difficoltà stava proprio nel tarare il proprio dizionario per andare a parlare in maniera coi guanti di velluto.

Però i problemi erano, sono immagino oggettivi quindi è un po' difficile anche discutere nel momento in cui c'è una vulnerabilità, la vulnerabilità c'è quindi non si tratta né di critica o né di giudicare il codice ci sta c'è stato il seguito o tutto quanto.

Ma li dipende proprio dalla personalità che hai di fronte perché trovi anche dei professionisti che non vogliono sentir dire che il codice che hanno scritto ha un problema ma perché banalmente almeno questo è per carità la mia come posso dire la mia esperienza più nel passato perché adesso è radicalmente opposta.

C'è una forte diciamo così attaccamento al codice che magari il consulente Pinko Pall aveva sviluppato per quel progetto per il quale se Security andava a dirgli che c'era un problema era una valutazione nel merito del professionista non nel merito del singolo codice che magari è scritto quel giorno che il tuo capo ti aveva stressato che non eri al 100% e magari ti è sfuggito il controllo e bla bla bla quindi assolutamente io sono io sai quante cappellate faccio come professionista per tornare alla chiosa di Mauro di prima nel senso che io sento il peso perché so benissimo che anche io magari mentre faccio un audit mentre faccio un pen test posso mancare un controllo posso non vedere una porzione di un sito che sto analizzando di un codice che sto analizzando quindi nessuno ha proprio nessuno infallibile tra l'altro ti rubo giusto un secondo perché è una roba successa settimana scorsa io adesso sto facendo l'audit per Salt ok Salt Project mi è capitato tra capo e collo una sospetta CVE di una di una esecuzione di codice arbitrario su Salt caperi sto facendo l'audit adesso non l'ho vista sono proprio un ciuccio e tra l'altro va bene non è se è seguita la responsible disclosure poi magari se avete voglia chiacchieriamo anche su questo perché sono fissatissimo sulla su come si deve fare disclosure delle vulnerabilità quindi giusto il chi l'ha riportata ha dato giusto due due int in questo file in questa variabile c'è un buffer overflow ora parliamo di come si fa un buffer overflow in python va bene facciamo anche finta file analisi è un fasso positivo però sì per tornare al discorso di prima due minuti di sudore freddo mi sono arrivati io poi devo andare a giustificare il mio capo sto facendo l'audit proprio di quello è arrivato un cv dall'alto dicendo 9.8 l'altro di cvss che poi se vogliamo chiacchierare su che cos'è sì sì gli ascoltatori è praticamente la dato una vulnerabilità è un punteggio che viene assegnato per una scala da 1 a 10 per secondo alcune metriche per definire quanto è grave quindi 9.8 su 10 voleva dire una roba tipo armageddon e in realtà poi su il soufflé che si sgonfia quando apri fuori paolo dice una cosa a livello proprio di processo come funziona dall'apertura di una vulnerabilità tutta la parte della disclosure e la chiusura poi alla fine con rilascio e l'aggiornamento come la chiusura sia presente perché immagino che sono bug che sono rimangono aperti o o fa il sicurezzo oppure tutti cv a un certo punto vengono chiusi allora quando io ho un altra mia fisima personale e quando mi si mette su una frase dove c'è tutti un assoluto sto sulla difensiva non lo so ovviamente la risorsa no non posso sapere allora ti dico quello che succede sulle cose di cui ho il controllo quando trovo una vulnerabilità e la riporto upstream quindi la riporto al mantener del progetto open source dove io sto facendo sto facendo odi gli faccio un report dove gli dico ovviamente una comunicazione privata questa è meglio ancora se nei repository c'è un bellissimo security.md o security txt quello che volete voi il formato dove dove ci dite a noi security researcher come contattarvi nel caso trovassimo una vulnerabilità nel vostro codice sarebbe bellissimo forse magari mettete anche una chiave pgp per cifrare la mail il top del top la comunicazione quindi bidirezionale tra me e il maintainer dove gli dico guarda c'è questo problema lo puoi replicare facendo così ti mando anche una poc della vulnerabilità se mi piace se ho particolarmente attinenza col codice gli posso dare anche un suggerimento magari guarda in questa variabile devi fare questo controllo e poi gli dico dovresti avere secondo le nostre nostre policy due settimane di tempo ce la fai per fissare per committare sul tuo repository altrimenti noi facciamo disclosure poi ovviamente dipende se è una vulnerabilità critica allora si tende a essere molto rigorosi sul timing quindi due settimane magari anche qualcosina di meno se invece si tratta di una vulnerabilità un cross scripting reflected che non ti dà nulla a livello a livello formale non ti permette di che ne so di fare una remote code execution non ti permette di fare di fare tanto allora si può si concorda col maintainer dicendo guarda vediamoci d'accordo tu quando me la fixi sia una una chiacchierata di questo genere e poi si passa a chiedere il cv e e poi quando la fix è entrata nel repository viene rilasciata si fa la comunicazione urbi e torbi a open source security la mailing list dove si dice è stata trovata la cv tra i detali fixata in data e questo è il processo di responsible disclosure.

Ti faccio una domanda però perché la parola responsible disclosure presuppone la parola responsible da qualche tempo a questa parte io tipo sto facendo la battaglia o almeno sto evidenziando la nostra community e alle persone che incontro di un problema che per me è fondamentale cioè il fatto delle librerie a maintainer singolo nel tempo libero questa è la mia descrizione che sono almeno nell'ambiente dove lavoro io che l'ambiente Node.js sono un gozziliardo sono veramente tante e sono un problema e lo sappiamo che sono un problema in quel caso ti è mai capitato in tutta la tua carriera di trovarti in difficoltà nel fare un disclosure di una certa vulnerabilità in una libreria di questo tipo per esempio col timing quando il mantenere dice ma io sono da solo come cazzo faccio? A livello personale no a livello di team sì nel senso che il maintainer non ha proprio risposto e scaduta la deadline che ci siamo dati come policy si è andati a fare la disclosure della vulnerabilità.

Se in tre mesi nessuno ci mette una patch nonostante tanti solleciti adesso in quel caso non era una cosa severa severa anche qui la risposta non è univoca nel senso che se fosse una cosa da Defcon 0 e quella libreria è completamente non mantenuta e lì si fa di necessità virtù e si fa una pull request o piuttosto si si fork al repository e si dice ragazzi benissimo questa libreria è un problema utilizzate questo fork che ha la patch se proprio il mantenitore non risponde.

Diciamo che si cerca di essere il più concilianti possibile con la persona perché sappiamo come funziona il mondo open che appunto è in camera caritati e quindi se uno lo mantiene nel tempo libero è un rischio ok però d'altra parte si deve anche cautelare perché magari quella libreria è utilizzata in 25.000 siti e ci sono dati che viaggiano dati di produzione e quindi in qualche modo bisogna mettere una pezza su.

Si è un balance tra due responsabilità che diventa sempre complicato quando si ha poi è quello che succede quando si ha a che fare anche con la natura umana nel senso che si ha la responsabilità di un'industria e dall'altra la responsabilità dell'approccio verso una persona che può essere complicato.

Anche perché noi come Dogma vediamo che l'attaccante è un passo avanti a noi quindi per quanto ne sappiamo l'attaccante l'ha già trovata con la vulnerabilità e potenzialmente la sta già sfruttando e quindi noi dobbiamo cercare di rincorrere sapendo che magari dall'altra parte non si sa perché non troviamo risposta però c'è appunto un'industria che si basa su quel lavoro e dobbiamo come dicevi tu Mauro bilanciare le cose.

Ecco ho una domanda quando ti trovi a scoprire una vulnerabilità diciamo c'è questo pensiero che qualcuno probabilmente l'ha scoperta non so due settimane prima la sta già usando ora te poi se l'hai accennato.

No impazzisci se no.

Esatto cioè non ci pensi perché comunque la risposta potrebbe essere sì.

Sì ma allora banalmente allora io non so quanti pacchetti ho nella distribuzione questo vale più o meno per tutte le distribuzioni di Linux vale per Windows vale per mac os e a livello di linee di codice stiamo su milioni contro quelle che riusciamo a fare audit e quindi ci sta che statisticamente l'attaccante l'ha già trovata le vulnerabilità che io sto cercando ora.

Statisticamente lo so è un gioco è un gioco a rincorsi dove io sto già perdendo.

Ecco è vero che l'attaccante è sempre in vantaggio.

Questo è un po quello che si dice perché l'attaccante non sai da dove arriva e lui potrebbe aver trovato una cosa che non si sa difendere o meglio forse le difese vengono costruite una volta che si sono scoperti gli attacchi.

È una cosa vera oppure non proprio.

No allora per quanto mi riguarda è vera nel senso che appunto se io ti devo dire guarda solta 600.000 linee di codice io riuscirò a farne l'audit di un 20% ragionevolmente cercando di andare a colmare tool automatico con lettura del codice con cercare di capire dove vanno dove va il flusso dei dati.

Però se dall'altra parte c'è che ne so una gang di uno stato X dove sono in 50 a fare il lavoro che faccio io sulla stessa code base statisticamente lo devi accettare che loro sono in vantaggio e sono 50 contro 1 e vada a sé.

Ma non ci penso.

È un po come quelli che ti dicono dai fai il trading da casa poi se ti scontri contro gli edge fund che stanno 150 analisti che stanno 24 ore e invece da casa comprate le azioni binarie dovresti fare i soldi.

Forse poi impari la cosa io faccio il mio senza pensare di essere più forte da solo rispetto a questi gruppi.

Esatto.

Assolutamente.

Ti volevo fare una domanda però gli ascoltatori e Luca e Leo sanno che tipo quest'ultimo periodo io ho la scimmia dello studio della complessità e di come funziona il nostro cervello di fronte alla complessità.

Tu fai audit di codice che non conosci quindi ti districhi continuamente in code base dove con difficoltà devi trovare i punti di riferimento ed è una cosa molto complessa perché innanzitutto si deve comprendere quello che sta succedendo e in più aggiungi un layer di complessità che è quello della ricerca delle vulnerabilità.

Come fai a gestire questi due layer di complessità? Hai un tuo workflow o dei tool o anche solo un modo per approcciare che ti aiuta? Io baro nel senso che non parto sul codice se il mio capo mi sta ascoltando con la traduzione in bulgaro si parto sul codice, no scherzavo, uso un approccio misto nel senso che prendo l'applicazione runtime e cerco di attaccarla, vedo dove c'è il particolare problema e vado a cercare di capire in quale porzione del codice è implementata la funzione che ha quel problema, prendo il codice, me lo studio e vedo se quel problema è veramente un problema di security o è solamente un errore non gestito piuttosto che una condizione che non porta a nulla oppure se invece si può costruire un exploit che mi permette di eseguire codice piuttosto che sfiltrare dati o fare altre cose.

Quindi in realtà io non parto subito a cannone con un'analisi statica del codice, parto con un pen test, con un penetration test dell'applicazione che sto facendo magari anche utilizzando il fuzzing se il linguaggio me lo permette e poi andando ad accoppiare dove trovo qualcosa di interessante, codice alla mano, mi vado a vedere la funzionalità e dentro il dettaglio.

Però sì, avete assolutamente ragione, andare a mettere la testa in codice scritto in mille linguaggi da mille persone è veramente una cosa possiamo dire anche alienante per certi versi, ma a me non è il caso di fare sponsorizzazione di comportamenti non a norma e diciamo che se hai la fortuna di avere del codice scritto da sviluppatori che sono coscienziosi e quindi hanno anche magari le suite di test implementate allora riesci, con un po' di documentazione riesci a barcamenarti.

Se il codice è proprio scritto a caso, insomma l'intera devi fare un po' di reversing, però vi dicevo prima che sono abbastanza fortunato che mi viene concesso il tempo necessario per studiarmela anche la codebase a grandi linee.

Hai parlato di fuzzing? No, giusto la domanda, in caso di codice scritto a caso e hai ovviamente magari sei anche commissionato quindi non è un progetto open source cioè sei commissionato dai maintainer, hai la facoltà o puoi dire no guardate così non ce la posso fare a guardarlo, non ce la posso fare a fare audit rifatelo no vero? No ma in che senso? No, noi facciamo il codice che noi auditiamo è tutto open quindi è tutto codice che bene o male trovi nei repository o che finisce in repository pubblici anche codice in nostro interno poi ha una sua anima open source quindi è tutto codice che poi esce e no assolutamente non posso permettermi di dire una roba del genere ma non sarebbe neanche nelle mie corde, cioè rientriamo nel discorso della valutazione in merito di cui si faceva prima cioè se il codice scritto veramente male mi prendo due spedine io e magari nel report dico che potrebbe essere migliorato per leggibilità però no rifiutare un audit no quello non è nella nostra missione, non lo facciamo però diciamo che può capitare è successo che alcuni miei colleghi abbiano fatto dell'audit di codice che era veramente brutto ma che poi portava anche a delle vulnerabilità perché era brutto e hanno dovuto scrivere che il codice non era leggibile in maniera facile e gli hanno fatto un papiro di report con 3 o 4 cv e allora lì si capisce da solo che probabilmente sulla qualità bisogna lavorarci un pochino di più.

Hai parlato di fuzzing, puoi spiegare un po' di cosa si tratta? Grandi linee, niente di too much.

Ok, allora il fuzzing è quella magia oscura per la quale quando compili un programma lo fai con un compilatore, una versione del compilatore C ad esempio perché io quando faccio fuzzing lo faccio esclusivamente su librerie scritte in C, lo fai con un compilatore C che istruisce il tuo programma a essere interrogato in maniera particolare, interrogato poi dal fuzzer che prende questo programma e passa degli input generati con i suoi algoritmi particolari in maniera tale da ampliare, far esplodere il numero di casi di test possibile e far attraversare nell'albero delle possibili esecuzioni del programma tutti i possibili rami in maniera tale da sollecitarlo il più possibile, possibilmente con degli input non attesi perché lo scopo del fuzzing è quello di darti degli input completamente non attesi e vedere come si comporta il programma.

Crescia magari con un bel segmentation fault e da lì ci si diverte a vedere se si può sovrascrivere l'extraction pointer e scrivere un exploit.

Purtroppo è da tanto che sto facendo audit di codice Java e Python quindi il fuzzing non mi posso divertire, lo vedo lontano, è nel mio arsenale ma non posso utilizzarlo.

Una domanda, quindi il segmentation fault è un segnale che qualcosa non va? Cioè non può crashare un programma semplicemente, dovrebbe sempre raccogliere tutte queste escezioni? Oppure scusa io non sono esperto di C, mi ricordo all'università quando c'era il segmentation fault avevi fatto qualche cagata però su una roba semplice.

Vuol dire non ci dovrebbe mai essere un segmentation fault? No, perché se c'è è sintomo che stiamo accedendo a della memoria a cui non avevamo accesso? Il segmentation fault si ha quando hai sovrascritto l'extraction pointer con un valore arbitrario per il quale lui va a puntare a un'istruzione di memoria per la quale non ha accesso e quindi ha un errore di segmentazione della memoria e quindi il programma crasha.

Può crashare in mille altri modi, diciamo che dal punto di vista della security è interessante quando tu ottieni quel segnale perché è sintomo che tu sei andato a potenzialmente manipolare il flusso del programma eseguito.

Non è detto che sempre si traduca in un exploit o in un'esecuzione di codice arbitrario però diciamo che quello è un cartino al tornasole che ci potrebbe essere problemi.

Questo è un mondo che apre mille porte.

Vabbè noi siamo programmatori java script per cui...

Cosa vuoi che conti? C'è il browser.

Fa tutto lui.

Vedi questa cosa mi porta a parlare di una roba molto pratica e porto la mia esperienza.

Una cosa che ho scoperto essere importante col tempo è stata la validazione dei dati d'ingresso.

Una cosa che spesso non viene fatta è la validazione dei dati d'ingresso e questa cosa tra l'altro è stata piacevole vederla su un framework come Fastify.

Questa è una piccola parentesi.

Nel senso che di solito i framework la validazione la danno implicita o danno dei tool per la validazione.

Però non stanno nella struttura del framework.

Una cosa che ha fatto Fastify che secondo me è molto figa a livello di security è il fatto di mettere la validation dell'input e dell'output formale in ogni handler di un server HTTP.

Dalla tua esperienza Paolo, io non so quanto hai lavorato su web e quanto invece hai lavorato più sui sistemi operativi, moduli di kernel, però dal tuo punto di vista quante vulnerabilità venivano da una mancata validazione dell'input in ingresso? Una marea.

Praticamente tutta la top 10 OSP deriva dal fatto che chi sviluppa si fida dell'input che gli sta arrivando dall'utente.

Allora quello che hai detto, mentre tu lo dicevi sono andato a vedere che cos'è Fastify perché io non lo so, sono ignorante.

Mentre lo raccontavi mi è venuto in mente quando ho iniziato a sviluppare Rails, che è una cosa che il framework ti dava gratis tutta la parte di escaping del javascript, tutta la parte di validazione dell'SQL quando andavi a fare le query.

È una cosa che mi ci ritrovo e la verità è una cosa che secondo me è necessaria che il framework introducano per nascondere allo sviluppatore tutto un lavoro, uno vero e detto lavoro che non compita l'unico.

Cioè è standard forse.

E' standard e poi lo sviluppatore deve scrivere il codice per fare uno shop, per fare un carousel, per fare un sito di e-commerce.

Secondo me non deve stare a preoccuparsi troppo della security, dovrebbe essere il quanto più possibile embeddata negli strumenti che gli vengono dati a disposizione.

Ed è ancora qui che torno sul fatto che forse manchiamo anche noi persone di security di andare a migliorare, a collaborare con chi scrive il framework per nascondere tutta la parte di security allo sviluppatore finale.

Ecco, vedi, hai usato la parola nascondere.

Con Fastify però, con questa cosa di formalizzare la validazione in ingresso nella richiesta HTTP, no? Cioè tu nella richiesta HTTP crei il tuo bel JSON schema e validi.

Tutto quello che non passa quel JSON schema, la risposta è un...

adesso non mi ricordo che cos'è un validation fail o qualcosa del genere.

E anche la risposta in output volendo può essere validata.

E questa cosa la devi fare formalmente.

Cioè l'handler ha la definizione formale all'inizio e alla fine come parametri.

Io adesso sto semplificando, andate nella documentazione di Fastify a vederla ragazzi se vi interessa di più, se vi interessa sapere di più.

Però quello che voglio dire è, hai detto rendere trasparente non tutta la parte di security.

Io sono d'accordo con te perché è un overhead nella testa dello sviluppatore che se tu riesci ad automatizzarlo, a renderlo trasparente, stai acquisendo sicurezza gratis senza delegare lo sviluppatore che può fare cappellate.

Vero.

Però il fatto di rendere le cose esplicite, non pensi sia anche un modo per generare quel tipo di awareness che un po' ci manca infatti nella veste di sviluppatore.

Cioè quello che ho vissuto io come esperienza personale è che me ne battevo le balle altamente perché bene o male c'era il framework sotto il cofano che mi faceva l'escape, l'ORM che mi faceva l'escape dei param che andavo a buttare nelle sequelle.

Avevo bene o male il framework che mi parava il sederino e mi gestiva tutta la parte di injection.

Magari mi faceva un escape fatto bene dell'XML che ho visto è ancora, io pensavo fosse superato, però il linkare entiti esterne è ancora una vulnerabilità nell'ousa o owasp che non riesco a pronunciarlo bene.

E quindi dicevo è proprio secondo me un modo per da una parte si ha sì quella security gratis però c'è anche il rovescio della medaglia che stai nascondendo, allontanando dalla consapevolezza lo sviluppatore e lo dico da sviluppatore inconsapevole, occhio, lo dico da sviluppatore inconsapevole con le mie responsabilità.

Allora sì e anche qui secondo me entra in gioco l'esperienza personale.

Nel corso della mia carriera ho fatto lo sviluppatore per una web agency per un paio d'anni e quando andavamo a scrivere codice noi non avevamo il tempo materiale per occuparci della security.

Perché? Perché arrivava il project manager e ti dava una settimana di tempo per realizzare un sito vetrina con un back end di e-commerce e quindi tutto quello che era nascosto dalla tecnologia era grasso che colava.

Tu mi dici allontano dall'awareness e sì è vero, è vero.

Ed è male, ed è male.

Non è vero però non viviamo in un mondo in un mondo reale, in un modo ideale.

Quindi è sempre un gioco del bilanciamento tra quello che è andare online con un prodotto e nei tempi che ci vengono commissionati quanto la scoperta personale di ognuno di noi che poi è in realtà il mindset hacker che è proprio anche degli sviluppatori quello di andare ad approfondire a cercare di capire sì ho capito ma perché se io uso Active Record non sono vulnerabile alle SQL injection? Cosa c'è dietro al cofano? E mi vado a leggere il codice di Active Record e lo capisco.

E l'approfondimento è una cosa che secondo me è una roba che ognuno di noi ha dentro e vuole farlo ma perché è proprio indole, è proprio indole di andare sotto il cofano a vedere che cosa succede perché ci sono questi meccanismi di protezione che io non so neanche perché intervengono ma di fatto lo fanno che poi in realtà poi possono essere anche bypassati perché ovviamente la protezione è un livello base ma come dicevamo dieci minuti fa l'attaccante è un passo avanti e quindi ha già studiato come bypassare il meccanismo di un framework open source che anche lui può auditare.

Concordo con te Lamiero, una provocazione è proprio per dire che non esiste una posizione assoluta.

No, non esiste assolutamente.

Il bello di queste domande è che difficilmente potrò dire che sono le mie perché tutto dipende.

Infatti noi abbiamo la musichetta, non so se ti è capitato mai di sentirla, no? È Arabe De Palo.

Volevo chiederti una cosa, tu sei da, ormai hai detto parecchi anni nel settore, una ventina no? Tanti, dal 2001.

Eh cazzo, sono tanti.

E quindi questa domanda cascafagiolo.

Cosa è cambiato con l'avvento così spinto del cloud per un pen tester? In realtà dal punto di vista del pen testing poco o niente, perché alla fine della fiera la risorsa non è importante dov'è, ma la risorsa è importante come è configurata.

Quindi se la porta di casa è a Gessate, faccio un esempio molto pratico, dove ho il server fisico, andrò a testarlo in una particolare maniera, ma se la porta di casa è in un data center ad Ivrea o sotto il Monte Bianco, tanto i pacchetti lì arrivano, è più proceduralmente che devo chiedere magari la manleva, avvisare il vendor del cloud che sta per fare un test, ci sono magari tutte le lungaggini burocratiche da fare, perché giustamente se non è un data center in casa del cliente, quindi ho degli obblighi anche verso chi gestisce quel cloud, per dire guarda che sto testando questo server per il mio cliente, ti faccio del traffico nomolo, occhio, avvisa il tuo team di security che vedrà arrivare questo traffico nomolo, è una cosa autorizzata, bla bla bla.

Di solito sono abbastanza veloci a rispondere, questo è reminiscenza di 3-4 anni fa, perché giustamente nel lavoro che faccio adesso non è una cosa che mi trovo tutti i giorni, però sono abbastanza veloci a rispondere, ti dicono sempre che non c'è nessun tipo di problema, avete questa finestra da lunedì alle 9 per dire fino a venerdì alle 17, dopodiché traffico illecito.

E per chi non fa il pentesting, cioè che fa solo il penetration, nel senso vuole attaccare il cloud, è un ambiente più sicuro, più controllato rispetto al server o ci sono state, perché magari sono anche cose che non sono state divulgate, ci sono stati problemi grossi anche su cloud? Allora guarda, la complessità poi lì si esposta magari sulla parte di attacchi legati all'esaurimento di risorse, come mi viene in mente il denial of service, la capacità di far scalare il cliente creandogli mille istanze delle proprie macchine sul cloud perché lo sta inondando le richieste, quindi gli fai anche un danno economico oltre al blocco del servizio.

Però come ti dicevo, la tecnica d'attacco, sì allora ci sono cose in più da controllare, come è configurata appunto le particolari istanze del cloud, se ci sono dei dati che non sono protetti adeguatamente, però una volta fatto quello, che sia sul cloud o che sia on-premise, non cambia molto dal punto di vista dell'attaccante.

Ti può essere, magari ti può andare di fortuna se hai un sito, però non è una condizione enterprise, magari un sito di una piccola medie imprese che è in un cloud condiviso, che magari è un server che gestisce 20-30 clienti completamente differenti e allora bucato uno che magari non c'entra niente con il target, hai bucato anche il target che tu avevi in mente.

Sai perché ho fatto questa domanda? Perché in realtà il mio team ha avuto un assessment qualche mese fa.

E' una parte delle cose che ci sono state segnalate, niente di critico, però riguardava le modalità di connessione ad alcuni servizi cloud.

Per esempio in quel caso noi stavamo su Azure e c'era il suggerimento di usare le managed identity di Azure, perché in quel caso si evitava di mettere le chiavi, insomma una serie di cose.

E quindi la mia domanda era quanto il cloud ha portato questo tipo di complessità, perché in realtà quanto l'infrastruttura è parte del lavoro del pentester.

Il discovery sull'infrastruttura diventa parte del lavoro del pentester, perché anche dietro a come viene gestita l'infrastruttura poi si nascondono tutto un ventaglio enorme di vulnerabilità, specie oggi che l'infrastruttura sta andando a sostituire quella parte di glue code, come mi piace chiamarlo me, che prima solitamente si scriveva a mano, oggi che ne so uso dei message broker che mi triggerano una lambda, che mi fanno queste cose su un certo cloud provider.

Ecco in quel caso sembra, dal mio punto di vista di gnubbo, sembra un lavoro completamente diverso che fare il pentesting di un'applicazione che è isolatrice.

Perché è un'overhead di configurazione che tu hai messo on top, la parte di gestione dell'identità delle persone che vanno a gestire il cloud, la parte di deploy anche sul cloud stesso, quindi sì hai aggiunto un overhead di complessità, chiaro.

Se tu la vedi assetticamente come l'applicazione in quanto tale non cambia nulla, cambia sì assolutamente la parte di contorno, quindi come l'applicazione vive nel suo ecosistema in cloud.

Ripeto, a me ha in qualche modo stupito il fatto che proprio dall'assessment erano venute fuori queste cose e diceva ma cazzo allora i pentester sono dei supereroi.

Conoscono il codice, conoscono l'infrastruttura e che cazzo.

Questo è quello che ho pensato, vi dico la verità.

Di solito io viaggio con un mantello, sì.

Di questo ci farò la clip, Paolo.

Una domanda, tanti anni fa ho conosciuto una persona che fa il pentester, però di notte si metteva il mantello e faceva bug bounty e praticamente il lavoro era diventato quasi un'altra cosa, arrotondava col lavoro perché col bug bounty faceva molti soldi, ovviamente lavorando la notte.

È un percorso che è abbastanza comune per chi si occupa di sicurezza o è abbastanza comune per chi si occupa di sicurezza e ha un sacco di tempo libero e può dormire due ore a notte? Allora, credo che dipenda poi dalla caratteristica della persona e anche dalla sua età anagrafica, se io ho 46 anni non lo farei mai.

Avevo pensato quando ho lasciato l'ultimo lavoro prima di andare in Suse di darmi alla libera professione, al bug bounty, ma poi è arrivata questa opportunità che mi ha fatto un pochino rinsavire.

È un percorso che vedo fare da molti ragazzi giovani che intraprendono il percorso della carriera nel nostro campo, nel campo della cyber security, ed è profittevole.

È buono per loro.

È profittevole ovviamente nella misura tale in cui, come dicevi tu, riesci a dedicare tanto tempo e riesci a trovare tante cose.

Perché poi, attenzione, non è che il cross-site scripting te lo pagano 20.000 euro, il cross-site scripting 500, 500.

Quindi devi anche avere la bravura tecnica per trovare qualcosa di veramente grosso che ti permetta anche di sostenerti, nel senso che, a meno che tu non faccia bug bounty, per crescita professionale, perché ci può anche stare.

Nel senso, voglio migliorare le mie capacità da penetration tester, che cosa faccio? La sera faccio bug bounty, ovvero in una situazione controllata dove mi hanno dato un perimetro di test reale, faccio test e quindi per forza mi esercito, aumento le mie skill e guadagno anche bene, tanto meglio.

Fare una professione dipende dalla capacità e anche dalla fortuna che tu hai nel trovare la vulnerabilità che ti apre.

Anche perché penso che nel momento in cui a te o alla tua azienda ti danno da fare l'audit di quel pezzo di codice sai che ci sei solo te.

Nel bug bounty, se l'azienda X dice, testatemi in questo modulo, sai che c'è migliori di persone che stanno provando ad attaccarli da tutte le parti, quindi forse anche più senti un po' la competizione.

Magari è proprio quello che è un drive per persone giovani.

Sì, anche perché io ho visto i programmi di bug bounty che la giocano molto sulla gamification, quindi oltre alla recompensa economica magari hai i punti, scali la classifica, ti arrivano i bug bounty più grossi, esatto, quegli inviti privati, ti arrivano anche i gadget, quindi entri in una specie di gioco per la quale il tuo ego è solleticato a cercare di spingerti ancora più in là e loro si guadagnano dei test di buon livello.

Tu ci guadagni perché, come dicevamo prima, oltre ai soldini aumenti le skill, ti diverti anche, tu ti vincoli in questo gioco.

Poi ovviamente, attenzione, non è che è un anel dorato per la quale chi ci sta ascoltando domani molla tutto, fa bug bounty e fa i milioni.

No, lì vale come diceva Gianni Morandi, uno su mille ce la fa a fare milioni con il bug bounty.

Visto che stiamo parlando di questo topic, ti faccio una domanda che puoi tranquillamente declinare sfanculando, quindi hai tutto il diritto, però se vuoi la tagliamo.

Non ho un avvocato.

No, se vuoi la tagliamo, però io intanto te la faccio.

Vai.

Tu fai un lavoro dove il baricentro etico è fondamentale, nel senso che ogni giorno in quello che fai decidi da che parte stare.

E dove le parti non necessariamente sono due, ma ci sono tutta una sommatura di parti.

Questa cosa ti è mai pesata? Allora, pesare no.

La riflessione del tipo aciderbolina, quelli che stanno dalla parte ostile e effettivamente fanno i gran soldi, sì, l'ho fatta.

Però non mi sono mai visto con quel cappello per mia indole personale.

Mi so che sembra un po'...

si può dire paraculo? A limite puoi biparlo.

Una dopo l'altra, parolaccia libera qua.

Ah, vabbè, potevi dirlo prima, è un'ora che mi trattengo.

So che sembra un po' paraculo da dire, ma la mia soddisfazione è nell'elevare il livello di qualità del codice.

Sono arrivato a un punto dove ho un lavoro che mi permette di portare a casa da mangiare per la mia famiglia, io sono soddisfatto.

Magari c'è il criminale che fa la bella vita un anno e poi lo beccano e la sua carriera è finita.

Secondo me il gioco non vale la candela.

Non ci starei da quella parte da barricata.

Chiaro, però una cosa che ho visto è che ci sono anche un gozziliardo di sfumature di grigio, come si suol dire, no? Del tipo, nel senso...

Non c'è un half way tra i criminali? Non lo so.

Allora, sì...

Sto facendo il diavolo tentatore.

No, no, ma sì, ci sta.

Però nonostante io in Dungeons & Dragons non interpreti mai un personaggio puramente buono, non riesco a vedermici, quindi ci sono tante sfacciature di grigio nel nostro lavoro, ma anche quando devi fare, che ne so, la segnalazione a un ente governativo che il suo sito ha un problema, io mi faccio tanti scruppoli, perché poi effettivamente dipende dall'altra parte se hai una persona che è illuminata abbastanza da dire, aspetta, questo non è un...

Dirla qualsiasi, ma è un personaggio che vuole aiutare, damoglia...

Insomma, io non voglio vivere la mia vita con la querela o con l'avvocato che mi bussa la porta perché hai messo un apice e ti ha risposto SQL Server e loro pensano che tu abbia il dump del database.

Quindi sì, dalla zona grigia cerco di rimanerne lontano.

So che sembra abbastanza ruffiano come discorso, però magari a chi ci ascolta...

Ma che cazzo sta dicendo questo qua? Ha più che senso.

Andiamo però ai giocattoli, è il momento dei giocattoli, non dei balocchi ancora, ma dei giocattoli.

OWASP, qual è la vulnerabilità dentro OWASP che ti gasa di più, quella che ti piace di più? Allora, a me piace tanto l'injection.

A me piace tanto l'injection, forse perché è a livello che ormai è difficile trovare quelle belle e potenti.

Perché ti permette da un SQL di arrivare non solo al dato, ma magari almeno tempo fa addirittura ti permetteva di eseguire codici all'interno del DBMS per la quale eseguivi il XPCommandShell e avevi una shell sulla macchina.

E allora questa è potenza, è così affascinante.

Parti dal SQL e ottieni un codice arbitrario.

Adesso io ti dirò, guarda, la cosa che mi piace un pochino di più è l'uso insicuro delle librerie di terze parti, che poi strizza l'occhio al problema della supply chain, ovvero di come le nostre applicazioni si portano in eredità tutte le vulnerabilità nascoste delle librerie di terze parti che le nostre applicazioni inglobano, senza saperlo.

E questo è praticamente un mondo.

L'ho perso.

L'abbiamo perso tutto.

Ma assolutamente, ma quello è proprio stato un esempio devastante che capita quella volta ogni 5-6 anni, ma ti basta per fare storytelling da qui all'infinità.

Ci saranno ancora giornalisti quando parlo di Log4J, si mettono a parlare di quanto è stato devastante, quant'altro, che magari non ne sanno neanche tanto.

Però sì, il problema delle librerie di terze parti è un problema che a me affascina molto.

E ti dirò di più, avevo anche proposto, e mi avevano dato come side project internamente all'azienda, di fare l'audit delle Apache Common, di tutto l'ecosistema delle librerie Apache.

Avevo iniziato, poi mi è capitato questo audit gigantesco tra capo e collo che mi sta inglobando da un anno ormai.

Però sì, è una cosa che mi aveva preso, personalmente mi aveva dato come obiettivo di andare ad analizzare il codice delle librerie di base, che sono la base delle applicazioni web.

È super interessante questo mondo, soprattutto se noi pensiamo che le nostre applicazioni usano un botto di librerie.

Io guardo le mie applicazioni, ci sono una marea di dipendenze e io tipo avrò guardato il codice di Sgt.

Trey quest.

A me non è fattibile.

Se non fosse per tool automatici tipo Renovate Bot, probabilmente il mio codice sarebbe un collabrodo.

E lo ammetto, per fortuna che esistano questi bot.

Però comunque viviamo con un livello di entropia tale, proprio dato dall'insieme delle dipendenze, che in qualche modo avere anche la benché minima apparenza di sicurezza è un atto di delegation.

È un mero atto di delegare.

Perché avevo visto che si ricollega un po' a quello che stavi dicendo tu sui programmi delle dipendenze in ambiente in Node.js.

C'era questo meccanismo che si chiama CREV, che praticamente ti permetteva di fare l'audit del tuo modulino e quando andavi a installarti con il comando le tue dipendenze, andavi a risolvere le dipendenze, ti scaricava anche gli audit delle varie moduli che stai andando a pescare e quindi hai tra virgolette il report degli audit che la community ha fatto sul codice che ti stai andando a importare.

Questo concetto a me è piaciuto molto.

Ho fatto questa analisi per una week, una settimana in cui noi possiamo lavorare sui progetti che ci piace di più fare l'anno scorso, su cercare di ampliare questa metodologia, questo standard per altri linguaggi.

Certamente è difficilissimo per una cosa come ad esempio Python o C, è praticamente impossibile fare una roba del genere, però sì, potrebbe essere in un mondo ideale la cosa fiche è questa, quando ti scarichi tutte le tue dipendenze, ti scarichi anche il punteggio o il reportino che ti dice se qualcuno c'è andato a fare audit oppure no, in maniera tale, anche perché non è non è vivibile che tu vai a leggerti tutto il codice di tutte le tue dipendenze.

La cosa interessante mi porta però a parlare di una cosa, di continuous delivery.

Oggi ci riempiamo la bocca di processo agile, rilascio continuo, rilascio costante, rilascio super veloce.

Ecco, in un mondo ottimale, visto che il pen testing nonostante tanto tooling automatico ha ormai quasi sempre bisogno di un uomo che prova a dare i calci al codice nei punti più critici per vedere se scricchiola e prova a sentire lo scricchiolio per capire cosa sta scricchiolando, ecco c'è ancora bisogno dell'uomo.

Quindi come si posiziona il pen testing all'interno del loop agile in modo che non diventi un elemento stativo rallentante, non so se si dice rallentante in italiano, passiamolo, rallentante, ma diventi una parte integrante del processo di sviluppo, che è una cosa che io non ho ancora visto perché per me l'audit io l'ho sempre vissuto come uno degli stadi quasi finali del waterfall per la creazione di un prodotto.

Ma lo vedevo anche io così, nel senso che il paradigma della security è shift left, quindi tutti i controlli di security devono essere fatti il più a sinistra possibile del ciclo di sviluppo, quindi verso idealmente la stesura dei requisiti.

Tutto quello che si fa ridosso della produzione ti mette a rischio di ritardi barra avere dei costi per andare a mitigare una vulnerabilità che potrebbero non essere anche sostenibili.

Quindi quando ero giovine e ai tanti e facevo security in azienda cercavo di andare a introdurre la sicurezza come awareness, come linea guida di controlli che dovevano essere fatti dal lato sviluppatore, API da non utilizzare in fase di sviluppo.

Purtroppo c'era anche il problema di dotare gli sviluppatori di tool di code review, ma lì ci si scontrava con problemi di natura meramente economica per le quali non si riusciva a dare lo strumento allo sviluppatore, quindi si sopperiva magari con il find bugs della situazione che è uno strumento open source per codice java all'epoca, ma era il limitato perché magari per alcune tecnologie la parte di code review era scoperta.

Il pen test risultava la parte finale, quindi mettevi il pollino col pen test a tutto il lavoro che avevi fatto prima con gli sviluppatori.

Torniamo sulla parte di code review perché mi hai messo la pulce sull'orecchia, adesso quella pulce sta ronzando in modo compulsivo dentro.

Quando dici tool di code review, qual è il ruolo specifico di questi tool di code review? Fai il casino! No scherzo! Allora, io parlo come pentito, come un pentito della malavita dei tool di code review perché ne ho creati due.

Ho creato OWASP Horizon nel 2008, che era un tool di code review per codice java, e ho creato Dawnscanner, che è un tool di code review per codice Ruby, che attualmente non mantengo più perché non uso più quella tecnologia, quindi non ho tempo da metterci.

Purtroppo, però, li ho visti sempre come un grep più più che mi andava a facilitare il mio compito nella misura in cui mi andava a identificare quelle porzioni di codice che forse potevano avere dei bug, perché magari interloquivano con la sessione, perché facevano I.O.O.

da qualche parte, perché c'era tanto, appunto come dicevamo prima, tanta gestione dell'input e quindi in uno scenario dove lo sviluppatore trasta l'input, si fida dell'input che gli arriva, se lì c'è tanto input vada a vedere lì.

Mi sono trovato anche nel corso della vita a fare dei POC, a fare delle dimostrazioni per i clienti con tool commerciali, effettivamente però il rumore di fondo, o almeno dati aggiornati al 2018, dei tool commerciali era tantissimo, quindi un sacco di falsi positivi, mi scappava la voglia.

Quindi io quando ho il mio workflow di adesso, come dicevamo prima, accanto a un po' di pen test, poi io vado di grep, di tool, basilari, magari anche qualcosa di scritto a mano, ma perché? Perché mi serve per magari il progetto specifico.

Quindi io so la codebase come è fatta e quindi mi faccio un accrocchio mio che deve funzionarmi quest'anno, l'anno prossimo, perché la codebase è più o meno fatta così.

E la domanda dopo è perché non usi Semgrep? Giusto? Ti anticipo.

Perché me l'hanno chiesto anche in un video che ho fatto, mi hanno chiesto perché non usi Semgrep, è così semplice.

Tra l'altro c'è anche un caro amico che lavora per Semgrep, ciao Paper, se mi stai ascoltando.

Perché ho un limite mio? Allora io ne ho avuto bisogno per l'audit di Salt, perché volevo andare a cercare se del certo codice che andava a fare il controllo, se l'utente fosse in sessione, fosse autenticato, in tanti codici Python.

Io quando ho dovuto scrivere la policy in YAML per farlo non ce l'ho fatta.

Ci ho perso 3-4 giorni, mi sono stufato e l'ho abbandonato.

Dovrò approfondirlo perché mi è rimasto qua al tarlo, quindi non è una sfida che voglio lasciare impunita, diciamo.

Quindi tornerò su Semgrep, però ecco la maggior parte delle cose la faccio con quello che mi dà il sistema operativo e con scrittini che mi faccio a mano.

Non ho tanta fiducia nei tool commerciali, se vogliamo.

Hai parlato di code review.

E mettere un uomo nel loop? Nel senso nel ciclo iterativo, il classico cicletto agile dove io faccio i test, scrivo il codice, faccio la mia PR, qualcuno dei miei peer mi fa la review e tra i miei peer se ci fosse anche un pen tester che ci butta un occhio può essere utile o stai rallentando il processo? No, sarebbe il top.

Vorrebbe dire prendere un Paolo operativamente, non è perché penso di essere chissà che, ma operativamente uno che fa le mie mansioni e lo metti in ciascun tool, in ciascun team di sviluppo e sarebbe fantastico perché realizzerebbe quell'occhio critico con la mentalità d'attaccante.

Dentro il team quindi shareare la vulnerabilità diventa una responsabilità, cioè l'errore all'interno della codebase diventa più una responsabilità condivisa all'interno di tutto, cioè diventa più facile comunicare.

Sì assolutamente, e non mi piace comunque parlare di errore.

Nel senso che la vulnerabilità è come qualsiasi bug che esiste in un codice bug funzionale, è soltanto un bug che può essere sfruttato per far fare al programma qualcosa che non era previsto.

Quindi errore, magari non usiamo errore così lo vediamo in maniera più positiva, ecco.

Così cominciamo a battere muri tra security e sviluppatori.

Ho trovato una feature per sviluppare i nostri server.

Mettiamo fiori di nostro exploit.

Vedo che abbiamo superato l'ora quindi ti faccio una domanda rapida poi chiedo a Leo e a Luca se hanno qualcosa da chiederti.

Domanda, a oggi se dovessi suggerire un learning path utile per non perdere tempo a fingersi cracker e diventare un ricercatore professionista.

Secondo te qual è il percorso ottimale dalla tua esperienza? Hai speso tanti anni non nel costruire il tuo percorso di carriera quindi magari alcune strade che hanno allungato la via, sei riuscito a riconoscerle e altre che ti hanno dato un boost di velocità altrettanto.

Allora, un learning path che sicuramente dà una marcia in più è quello di partecipare alla community.

Partecipare alla community che cosa vuol dire? Vuol dire non solamente essere nei canali telegram dove si parla di pentest, dove si parla di codice sicuro, di code review, ma andare a partecipare al codice.

Quindi che ne so, ti piace PHP, ti piace fare pentest su WordPress, vai e partecipi con il codice.

Ti piace vincere facile.

Ti piace vincere facile con i temi, con i plugin di WordPress, è una roba allucinante.

Consiglierei di non fermarsi al mero trovo la vulnerabilità ma la risolvo e la propongo.

Perché? Perché in quel modo riesci a vedere il problema di security anche dall'altra aspettatura e questo ti permette anche di aumentare anche le tue capacità di scrittura di exploit perché se trovi il modo di mettere una pezza, una vulnerabilità che hai trovato, ti viene di sicuro la sfida di dire ok bene l'ho aggiustata, aspetta che la ricontrollo per vedere se trovo il modo di trovarne un'altra, di sfruttarne ancora e così via e così si reitera.

A livello più formale mi verrebbe da dire di non, allora non so se vogliamo trattare il tema università perché qua poi si apre il vaso di Pandora e non ne finiamo più.

Se le persone che ci ascoltano stanno già facendo un percorso universitario di non sottovalutare quello che stanno imparando anche se al momento sembra completamente slegato dal mondo del lavoro, io ne avrei ancora per 40 minuti per parlarne, e poi di buttarsi su pratica, pratica, pratica.

Pratica cosa vuol dire? Ci sono siti come Vulnab, Try2HackMe, Ponyx.io che ti danno delle macchine fatte con delle vulnerabilità, le famose GTF, ok? Lì potete giocare, è tutto legale, la macchina è fatta apposta per essere bucata, trovate le vulnerabilità, scrivete un bel report, lo pubblicate, fatevi un vostro blog, voi dite è un lavoro, no, perché quello dimostra che non solo sei stato bravo nel trovare la vulnerabilità, ma sei stato innanzitutto bravo perché hai capito cosa hai fatto, l'hai saputo scrivere in inglese e magari anche in italiano decente, io sono un po' un grammarnazio, e lo hai saputo comunicare, ok? E se sei riuscito a far capire a qualcuno che non è della tua nicchia quello che tu hai fatto, allora basta.

Quello è il tuo portfolio, ok? Come uno stilista ha il suo book con i suoi bozzetti, per un aspirante a security research era avere un portfolio di problemi di security risolti con un write up, quindi con un report dettagliato di chi dimostra come opera sul campo, secondo me poi all'atto pratico in un mondo ideale se il recruiter ne capisce riesce a trovare valore aggiunto.

C'è una piccola stilettata qua.

Hai detto una cosa bellissima che guarda ti manderei una casa di birra premium per ringraziarti di averla detta, cioè il saper comunicare.

La sfida veramente grande, ed è una cosa che sto vivendo adesso con alcune persone che sto seguendo, è fondamentale tanto quanto sape scrivere il codice o trovare la vulnerabilità.

Cioè io mi trovo davanti a...

e io in primis ho avuto difficoltà perché andavo a scrivere delle pull request dove la description era AAA o non era proprio AAA ma era questo ripara questa cosa.

Si, argomenta.

Non devi scrivere cosa hai fatto, devi scrivere la ragione per cui l'hai fatta nel modo dettagliato che permetta alle persone di capire.

Prima di capire questa cosa, che un po' si ricollega a quello che dicevi tu, magari non perfettamente perché vista dal lato sviluppatore, però il saper comunicare agli altri, la missing part, la parte mancante, diventa indispensabile in una crescita a livello di carriera.

Senza di quella non si cresce.

Per dirvi, il 90% degli investimenti che sto facendo oggi io a livello di carriera sono sul migliorare la comunicazione.

Perché? Perché talvolta vale più del codice.

Esatto Mauro e mi permetto di aggiungere una cosa, la forma con cui presentate i vostri risultati.

Un mio vecchio capo mi disse, Totò ciao, saluto un sacco di gente, scusami se uso questo spazio come chat personale, il nostro lavoro di consulente è il 90% presentazione.

Perché giustamente quando tu vai dal cliente non gli interessa che tu hai il suo account di administrator, ma come gli presenti l'attività, quindi come gli fai capire la problematica.

E quindi questo è importante, è importante anche la forma con la quale un giovane che si sta approcciando a questa carriera decide di fare il write up, quindi curare anche la parte di produzione linguistica, curare anche il dettaglio nello screenshot, perché sembrano stupidaggini ora che ne parliamo, ma poi quando ti devi andare a qualificare per un lavoro, questi sono i dettagli che vengono guardati, quanto sei professionale.

Non voglio dire che tutti prendiamo la shell di root, non è vero, ma in tanti lo fanno.

Se tu ti vuoi differenziare dalla massa è come vendi il tuo risultato che hai ottenuto, tramite duro lavoro ovviamente.

Visto che ci avviciniamo alla chiusura, volevo chiedere rapidamente a Leo e a Luca se hanno qualche altro domanda.

Sì, mi sono chiesto di farlo, mi sono chiesto di fare una domanda, ma non mi sono chiesto di fare una domanda.

Io ho una domandina, forse off topic, forse no.

Negli audit di applicativi, quindi non di librerie, non so se ne fate, ne fai, c'è spazio anche per guardare al social engineering, quello che può dare problemi in un contesto di social engineering? Io ho sempre in questo contesto, ho sempre in mente un episodio che chiamo La mia banca, la banca non è open source, non applicativo open source almeno, non che mi risulti, o forse non tutti, comunque, dovevo fare un'operazione e l'operatore mi dice, ah per abilitare questa operazione dimmi la terza cifra del tuo PIN.

Ok, ah operazione, no la dobbiamo rifare, ok adesso il sistema mi chiede la quarta cifra del tuo PIN.

Ok, la terza volta, la dobbiamo rifare, no aspetta adesso non rifacciamo niente perché altrimenti faccio prima a dirti il PIN c'è qualcosa che non va.

Quindi no, avevo in mente questa cosa qua e la domanda era se c'è spazio, c'è tempo, è il focus anche del team di Odit che fa questo? No, sfortunatamente no, di solito, allora negli Odit che faccio io ora, nel mio lavoro attuale, assolutamente no, è completamente fuori dallo scopo, è più un'attività legata se vogliamo a Red Teaming, quindi la simulazione di un attaccante a 360 gradi, dove dell'azienda forse le risorse umane e il capo della security sanno che stai facendo quell'attività giusto per prevenire che se qualcuno chiama i carabinieri, qualcun altro dall'alto dice sì ok, no era autorizzato.

Purtroppo no, non è in scopo, è un'attività legata al PIN test, alla simulazione di un attaccante, sì assolutamente, è una cosa che dovrebbe essere fatta al social engineering, però anche qua ci si scontra con una serie di problemi anche legati alla gestione della risorsa lavoro, perché se tu fai un social engineering che va a buon fine, cosa succede a quel dipendente? Dovrebbe essere premiato perché sa che quell'attacco...

No, no, se va a buon fine, nel senso se tu fai social engineering alla tua banca e ottieni un'informazione che non avresti dovuto fare all'interno di un'attività lecita, metti in difficoltà quella persona che forse non ha avuto un training adeguato, quindi anche a livello di gestione delle risorse umane si ha un pochino di remora a fare un'attività così invasiva sulla persona.

Perché forse non si fa abbastanza training, nel senso un operatore di call center che lavora per una banca, e no, appunto, quello appunto si fa o no? Si fa, e se è un problema, è un problema, no, che immagini no, non si fa training.

Io ho visto un video, immagino sia un po' famoso io, sia abbastanza virale, durante un DEF CON che una ragazza si fa, praticamente fa sim swapping live usando un video di YouTube di bambino che piange, dicendo no ma mio marito, scusa, ho il bambino che piange, che sempre fa sì va bello, e gli dà praticamente i dati per cambiargli la sim, e di chi è la colpa? È chiaro che chi fa social engineering ha tutti i vari trigger psicologici per provare a… e quell'altro non ha il training adeguato per dire guarda potrebbero farti anche questo.

E lì non è nulla di te, in senso non è appena che si parla di psicologia umana? No, no, no, lì è un errore procedurale che la formazione al dipendente finale non ha coperto anche questo caso, questa tipologia di truffa.

La colpa è di chi avrebbe dovuto erogare il training, però anche lì ci scontriamo con mille altre problematiche, se beh, insomma, sia la che ti rigira siamo sempre a parlare di tempo e sole, vuoto per pieno.

È chiaro che l'operatore di frontiera che ha interfaccia come le nostre form web che vengono attaccate, l'operatore di frontiera è la prima linea di difesa tra virgolette, no, cento tra virgolette, la prima linea di difesa della nostra istituzione, quindi dovrebbe essere la persona più… che subisce più training.

Io avevo in mente qualcosa che stava anche un po' in mezzo, nel senso che proprio a livello di flussi dell'applicazione, fermarsi un attimo e dire scusate, con questo flusso basta una telefonata, nemmeno troppo psicologicamente penetrante e il problema è girabile.

Forse bisogna, diciamo, rivedere questi flussi.

Pensavo più, diciamo, a questo scenario piuttosto che proprio fare l'attacco o simulare l'attacco di social engineering, vero.

Bene, siamo un'ora e mezza, raga.

Io ci vi accompagno alla… Comunque posso dire qua pubblicamente, sarebbe interessante fare una puntata in incognito con qualcuno un po' più black hat di Paolo, che ha un'etica incredibile per cui non parli di queste cose, dove poter fare domande scomode, risposte scomode, non lo so.

Io la butto lì per magari la taglio, no, però magari se arrivano dei contatti via mail… insomma, sarebbe carino per sapere cosa succede dietro.

Ecco, a tutti i black hat Paolo compresi… Paolo non è compreso, ha detto prima, non la parli più di questo capello.

Ma il suo è double face, è bianchissimo, è verdissimo.

No, è green hat, Paolo.

Giusto, Pa? Giusto.

Detto questo, in realtà l'ultima domanda per Paolo è, hai anche una felpa nera col cappuccio? Sì, te la danno nel manuale, cioè devi averla, non puoi non averla.

Tra l'altro, veramente ce l'ho di Ekimbo, saluto anche Mario, già che ormai stiamo salutando tutti, uno dei eventi qui a Bologna di security… ho una felpa nera.

Beh, prima parlavi di gadget, quindi forse rientrava in qualche gadget… Eh no, quando sono andato speaker mi hanno dato la felpa, cioè per forza ragazzi.

Anche Paolo colleziona gadget.

Ecco, noi che siamo dev, quando andiamo speaker ci hanno la maglia, se sei un pen tester, un ricercatore di sicurezza ti hanno la felpa, forse conviene diventare… Però quello che c'è comune è… … un valore di mercato maggiore, no? L'amore per gli adesivi, gli adesivi da attaccare sulla cover del laptop, quello c'è comune.

Wow! Sto mostrando il mio pacchetto di adesivi, questi sono in attesa del nuovo laptop.

Detto questo, arriviamo al momento tipico e topico del nostro podcast, il momento del Paese dei Balocchi, il momento in cui i nostri guest e anche i nostri host condividono con noi qualcosa che abbia catturato la loro attenzione, insomma, fatto drizzare le antenne e che pensano sia importante da condividere all'interno proprio della community.

La mia domanda è per Paolo, hai qualcosa da condividere con noi? E conduco nel Paese dei Balocchi.

Ah, il Paese dei Balocchi.

Sì, due cose.

Allora, la prima è un libro che mi sono fatto arrivare da poco che è The Rust Programming Language, che io Rust non lo conosco, però visto che adesso nel versione 6.2 è ormai ufficiale che è un linguaggio per scrivere sotto sistemi di cambio di links… Mi tocca.

Mi tocca perché andando a fare audit, soprattutto uno dei miei side project è andare a fare un pochino più di ricerca sul kernel, mi toccherà andare a imparare anche Rust.

E sempre legato al kernel di Linux, una versione aggiornata a febbraio 2023, The Linux Kernel Module Programming Guide, che è un libro di molti autori, disponibile su GitHub, poi non so se hai modo Mauro di mettere il link da qualche parte.

Sì, mettiamo tutto nelle note dell'episodio.

Perfetto, questo è open, assolutamente, te lo mando, è open, quindi tutti possono usufruirne.

E' aggiornato la versione 2.5 del kernel, quindi abbastanza recente, 6.5 scusate.

Figo, mettiamo tutto nelle note dell'episodio.

Allora, io, visto che si parlava di Rust, anche io ho comprato Rust in Action, perché era un po' che Rust mi girava nella testa, però il balocco non è questo.

Io l'ho preso su Vinted, a 25 euro, nuovo, perfetto, quindi ragazzi cercate libri di qualsiasi tipo, cercateli su Vinted, non si vende solo abbigliamento, ma si trova anche gente che gli regalano un libro che non lo usano e lo danno via senza sapere qual è il valore.

Sicuramente, sicuramente deve essere di qualcuno che ha iniziato il capitolo sull'ownership, ha scazzato male e l'ha venduto su Vinted.

Io lì ancora non ci sono arrivato, però poi se lo trovate in vendita alle Eurossi sono io eventualmente.

No, comunque il mio balocco era un'altra cosa, visto che a marzo io sono a Firenze, a marzo a Firenze succede una cosa, c'è l'Open Source Day 2023, organizzato dagli amici di Schrödinger's Hut, così per dire, quasi metà degli speaker è stato ospite di GitLab, però per farvi capire un attimo la qualità della conferenza, 24 marzo a Firenze, il 23 marzo è il mio compleanno, quindi diciamo che in quel weekend a Firenze succedono cose, per cui se venite scrivetemi su Telegram, io sarò lì perché Matteo Pollina è uno degli speaker, è gratuito, costa solo dormire a Firenze, per cui sì, la conferenza è poco costosa, ma comunque potrebbe essere un'occasione per incontrarci.

Ne approfitto per mandare un abbraccio agli amici di Schrödinger's Hut.

Il mio balocco è stato nominato, stavo proprio pensando di portare tryhackme.com, non so se era quello, però io avevo già fatto una volta, mi ero registrato e avevo provato a fare qualcosina lì, però a me questo è un topic che mi piace tanto, ma ho tanta paura del mio lato oscuro.

Per fortuna sono una pippa, quindi il mondo può dormire tranquillo.

E niente, paradossalmente poco tempo fa sono arrivato un po' con un po' di anni di ritardo, ho visto un film che magari qualche pollo come me non l'ha visto, che si chiama Try to Catch Me, in italiano è Prova a Prendermi, che riguarda appunto il social engineering più o meno, per solmi capi.

È una storia vera, la storia di Abagnale, che è stato, dicono, il più grande truffatore d'America, se non del mondo.

Dopo Ponzi, probabilmente.

Comunque il cognome italiano gira un po'.

E mentre lo vedevo pensavo proprio a quanto la conoscenza del sistema che può essere casuale o può essere proprio studiata è importante per bucare il sistema, che sia informatico o che sia procedurale di un'azienda o quel che sia.

L'ho visto proprio con piacere, è del 2002, non proprio fresco di uscita, ma l'ho visto e mi ha colpito, già che siamo in topic, lo balocco.

Abbiamo parlato di truffa e quindi io vi parlerò di cripto.

Scherzo.

In realtà voglio portare qualcosa riguardante il mondo delle cripto, voglio portare Master in Bitcoin, che è un libro di Antonopoulos, che parla di Bitcoin.

Bitcoin, dal mio punto di vista, al di là della sua funzionalità, è senza dubbio un'innovazione tecnica altissima, che attinge a tanta letteratura accademica che era nascosta a partire dalla criptografia per arrivare al Merkle Tree per la gestione delle chiavi, sotto chi hai per la validazione.

Insomma c'è un mondo, no? Esiste una versione di Master in Bitcoin in italiano e lo suggerisco perché.

Perché è un libro che parla di informatica, non di Bitcoin, che parla di sviluppo software, che parla di sicurezza by design ed è uno dei pochi libri tecnici scritti in modo eccelso.

Antonopoulos, secondo me, in quel libro insegna come deve essere scritta la documentazione legata al learning.

Noi sappiamo che la documentazione assume sfumature completamente diverse, no? C'è la documentazione tecnica che si occupa attraverso esempi di favorire l'apprendimento, c'è poi la lista di tutte le funzionalità di un API, ci sono diversi tipi di documentazione.

E secondo me Master in Bitcoin è un libro che riesce a evidenziare quelle che sono le caratteristiche che per me deve avere un libro tecnico.

Quindi leggerlo da questa prospettiva cambia un po' il suo posizionamento proprio a livello di posizione.

Esiste un'altra piccola cosa.

Siccome abbiamo parlato di security, una delle vulnerabilità di sicurezza che più mi ha gasato e più mi ha fatto piangere perché mi ha fatto dire Mauro sei un idiota, è stata una vulnerabilità trovata nei JSON Web Token dove era praticamente possibile passare come algoritmo null e senza una verifica in back-end del cambio dell'algoritmo tu potevi attingere ai privilegi di amministratore fondamentalmente della web application.

E per uno come me che ha utilizzato pesantemente JSON Web Token, leggere di questa vulnerabilità pur poi scoprendo di essere protetto da questa vulnerabilità, però comunque leggere e capire come funziona mi ha fatto rendere conto di quanta complessità c'è in una semplice azione che può risultare banale.

Vi condivido un post del blog dei ragazzi di OutZero, che un po' racconta questa vulnerabilità.

Bene, siamo arrivati alla fine di questo episodio e siamo ancora tutti vivi.

È stato un viaggio fighissimo, Polo ha fatto da ciccinone in un mondo che in realtà in qualche modo si compenetra in quello che facciamo, però lo vediamo talvolta in modo antitetico come diceva lui, altre volte in modo conflittuale.

Ed è stato bello vederlo in modo amichevole e scoprire un po' insomma come funziona e la complessità che ci sta sotto.

Per questo, Polo, ti ringraziamo tantissimo.

Sono io che ringrazio poi di questa bella chiacchierata.

Volevo aggiungere giusto due cose, sulle note dell'episodio mettiamo il blog di Paolo, il suo canale YouTube, mi raccomando iscrivetevi al canale perché fa ridere e tra l'altro Paolo hai la macchinetta del caffè più colorata del mondo, io la adoro! Tra l'altro mi accorgo adesso che è verde e potrebbe essere un refrain commerciale incredibile, però è bellissima la macchinetta del caffè, la adoro anche io.

Mi è nato sto schizzo di fare questi short a gennaio e mi diverte molto come formato.

Io, ripeto, ti ringrazio tantissimo, mi raccomando andate a recuperarvi il canale YouTube, gli short di Paolo, il suo blog, i suoi profili social, mettiamo tutto sulle note dell'episodio.

Ringrazio tantissimo Paolo per essere venuto a trovarci.

Come diciamo sempre, una volta che si entra nel GITBAR diventa un po' casa tua, quindi quando è qualcosa di nuovo da raccontarci, qualcosa che ti puta interessante, non aver timore o remora di contattarci, c'è sempre una birra in fresco per te, anche se virtuale.

Va benissimo, sarà una grande gioia.

Le porto io da casa.

Bravo, questo è lo spirito.

Tra l'altro, offriamo noi, offriamo noi e se vai a Firenze offre Leo il compleanno.

Detto questo io vi ringrazio infinitamente, ringrazio anche Luca e Leo che mi hanno supportato e accompagnato in questo viaggio insieme a Paolo.

Vi ricordo che in realtà abbiamo sospeso le pubblicità, quindi se volete supportarci c'è un link supportaci all'interno della nostra pagina web.

Vi ricordo anche che dalla settimana scorsa abbiamo attivato la funzione di ricerca testuale in quanto detto.

Oh, cazzo! Scusi, anche questo entrerà nel testo, cioè sono cerca cazzo.

Ok, perfetto.

Sì sì, cercheremo cazzo e troveremo Leo che dice no, in realtà funziona o almeno dovrebbe.

Se non funziona, ragazzi, fate una PR.

Dicevo, se volete supportarci supportateci, se non volete supportarci ci basta che lo codiciate ad amici in modo che la voce si sparga e noi diventiamo famosi e potremo andare a Sanremo a cantare la canzone del codice, quella degli anni 90.

Luca mi devi mandare il link perché chiuderemo la puntata con quella canzoncina.

Te la ricordi? Tu l'avevi condivisa, la canzone del programmatore.

Credo di averla rimossa, quella del programma forte e programmatore.

La cerco, la cerco.

Detto questo io ringrazio nuovamente Paolo e vi do appuntamento la prossima settimana.

Ciao! Ciao! Ciao! Ciao! All'ombra dell'ultimo sole si addormentò un programmatore tra le sue braccia un manuale sognando il mare tropicale.

Prende alla ditta un committente con un progetto inconsistente delle richieste da far paura prima di ieri perché a Premura.

E domandò un lavoro in mane con le specifiche più strane.

Io voglio tutto e pago niente e ho pretta sono un committente.

Gli occhi dischiusi e il softwareista un video l'unica a sua vista.

Dall'alba grigia fino a sera incatenato alla tastiera.

Battendo i tasti a modi ossesso e trascurando cibo e sesso riusci un bel giorno a consegnare una release preliminare e si sentiva ormai contento ma fu sollievo di un momento già richiamava quel cliente qui non funziona un accidente.

Ricominciò il programmatore a faticar per ore e ore sopra un problema assai intricato nascosto dentro ad un istato venne di nuovo il committente.

Dice così è meglio che niente e tuttavia per me importante fare una piccola variante.

L'ombra dell'ultimo sole dormiva già il programmatore tra le sue braccia manuale e la sua.

Gitbar il circolo dei fullstack developer una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web di metodologie ed strumenti immancabili nella cassetta degli attrezzi dei fullstack dev..