Bene e benvenuti su Gitbar! Io, voi state sentendo me ridere come un povero scemo ma dovete soffere 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.Insomma, nulla funzionava oggi, ma andiamo dritti e 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 buccato un sacco di volte quindi sarà anche ora di imparare a non essere più così lo scemo del villaggio.Benvenuti su Gitbar, il podcast dedicato al mondo dei fullstack developer, i mezzo artigiani, i 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 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 Product 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 ai nostri alla community per quanto riguarda le anime open souse, leap e tumbleweed e poi tutta la parte di prodotti di Suesel Enterprise Edition Insomma, una grande responsabilità Sì, abbastanza però è sempre quello che ho sempre voluto fare nella vita L'audit del codice è un pallino che ho 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 LinkedIn si capisce bene.Già da lì avevo la passione per l'audit del codice.Sono sempre stato una persona di security che amava programmare, 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.Eh sì, per forza.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 Mauro.Come gestisci il peso di questa responsabilità da uomo? Eh, mamma mia, cominciamo...ma non mi avevi detto che questo podcast era così pregno? È una domanda di quelle molto...allora io personalmente se qualcuno che sta ascoltando mi conosce sa che ho una sindrome dell'impostore altissima.Io 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 è e 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 un cliente sia una se sono delle milestone molto molto rigide.Adesso in SUSE visto anche la sensibilità 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 sempre paura di non vedere quella cosa macroscopica che uscirà cinque minuti dopo un CVE che mi arriva tra il capo e collo e ci faccio la figura della della cioccolataio però eh diciamo che è un po' è un po' il gioco delle parti perché io parto dopo vent'anni ho capito che la il cento percento della security non è non non non è di questo mondo e quindi di sicuro ci sarà qualche problema o qualche cosa che può andare storto e se può andare e se deve andare storto lo andrà quindi eh come per rispondere alla tua domanda quindi eh buono lo sono anch'io come faccio a supportarlo penso di pensarci un pochino e poi sono impazzisco sai che in realtà quello che ha appena detto è veramente interessante io ho 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 ti 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, la faccio a quel punto con la tranquillità anche perché, e questo mi fa 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 no? Nel senso è uscito un CVE vuol dire che il pen tester è stato superficiale oppure Hai rotto qualcosa e fatto una cagata nel codice o fatto una cagata nel codice vuol dire che il developer è superficiale non è detto Quindi perché c'è tutta una serie di sfumature tra l'una e l'altro E su quale sfumature sta L'essere attenti no? Noi dobbiamo posizionarci nella più alta di queste sfumature possibili Esatto, 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 è sfuggita 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 vuoi dire problemi è proprio una roba una roba allucinante sì sì sì perché magari entra il concetto di dire oh ma che te ti senti superiore cioè ti vedono come superiore come per dire ma che vuole questo cioè arrivate mi va a cliccare il codice che ho fatto, però se tu sei 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 contrapposata, totalmente slegata e io non ho fatto una 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é "vabbè, lì dovrebbero saperlo dovrebbero saperlo tutti.Dovevo andare a parlarlo a gente che vedeva il 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 la difficoltà stava proprio nel tarare il proprio dizionario per andare a parlare in maniera con i guanti di velluto.Però i problemi erano già sono immagino oggettivi quindi è un po' difficile anche discutere nel momento in cui c'è una vulnerabilità, quindi non si tratta né di critica o né di giudicare il codice, ci sta, c'è stato il seguito o tutto quanto.Sì, ma lì dipende proprio dalla personalità che hai di fronte, perché trovi anche dei professionisti che non vogliono sentire dire che il codice che hanno scritto ha un problema ma perché banalmente, questo è per carità la mia 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 però io ho fatto il controllo e bla bla bla quindi assolutamente io sono io sai quante cappellate faccio come come professionista per tornare alla alla chiosa di di Mauro di prima nel senso che io lo sento il peso perché so benissimo che anch'io magari mentre faccio un un odiette mentre faccio un pentest posso mancare un controllo, posso non vedere una di un sito che sto analizzando, di un codice che sto analizzando, quindi nessuno, 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 eh sospetta CVE di una ehm di una esecuzione di codice arbitrario su solde.Dico caperi.Sto facendo l'odio adesso non l'ho vista.Sono proprio un ciuccio.Ehm tra l'altro vabbè non lì non è seguita la responsable disclosure poi magari se avete voglia chiacchieriamo anche su questo perché sono fissatissimo 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 falso positivo però sì per tornare al discorso di prima due minuti di sudore freddo mi sono arrivati.Io poi devo andare a giustificare al mio capo, sto facendo proprio di quello, è arrivato un CV dall'alto dicendo 9.8 l'altro di CVSS che poi se vogliamo chiacchierare su che cos'è per gli ascoltatori è praticamente 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 il soufflé che si sgonfia quando apri il forno.Paolo dicci 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.Qual è il processo presente? Scusa dove scusami? Dove la chiusura sia presente perché immagino anche che sono lag che sono rimangono aperti o o fa il sicurezza oppure tutti i cv a un certo punto vengono chiusi eh eh allora quando io ho ho un'altra mia fisima personale e quando mi si si mette su una frase dove c'è tutti un assoluto sto sulla difensiva non lo so ovviamente 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 mantainer del progetto open source dove io sto facendo sto facendo audit, 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 ci dite a noi security researcher come contattarvi nel caso trovassimo una vulnerabilità nel vostro codice sarebbe bellissimo, magari mettete anche una chiave pgp per cifrare la mail il top del top.La comunicazione quindi unidirezionale 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-site scripting reflected, che non ti dà nulla a livello formale, non ti permette di fare una remote code execution, non ti permette di fare tanto, allora si concorda con il maintainer dicendo "guarda, vediamoci d'accordo, tu quando me la fixi, si ha una chiacchierata di questo genere e poi si passa a chiedere il CVE e poi quando la fix è entrata nel repository e viene rilasciata, si fa la comunicazione urbi e torbi a opensource 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 alla nostra community e alle persone che incontro di un problema che per me è fondamentale, cioè il fatto delle librerie a mantener 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 mantenerti 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, 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, quindi se uno lo mantiene nel tempo libero è un rischio.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, quindi in qualche modo bisogna mettere una pezza Sì, è 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 che non è così, non è così come dicevi tu Mauro, bilanciare le cose.Ecco, ho una domanda, quando ehm ti trovi a scoprire una vulnerabilità ehm diciamo c'hai questo pensiero che eh qualcuno l'avrà probabilmente l'ha scoperta, non so, due settimane prima l'ha stato già usando, ora te poi se l'hai accennato.No, impazzisci sennò.Eh esatto, cioè non ci pensi perché comunque la risposta potrebbe essere sì.Banalmente, 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 e le vulnerabilità che io sto cercando ora.Statisticamente lo so, è un gioco a rincorsi dove io sto già perdendo.Ecco, è vero che l'attaccante è sempre in vantaggio? Allora, questo è un po' quello che si dice, perché l'attaccante se non sai da dove ti arriva e lui potrebbe aver trovato una cosa che te non ti 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 è vero, 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 codebase, statisticamente lo devi accettare che loro sono in vantaggio.E sono 50 contro uno e vada a sé.Ma non ci penso.Un po' come quelli che ti dicono "dai fai il trading da casa poi te ti scontri contro gli edge fund che stanno 150 analisti che stanno 24 ore e te invece da casa comprando le opzioni binarie dovresti fare i soldi.Forse un po' impari la cosa io faccio il mio senza pensare di essere più forte da solo rispetto a questi gruppi qua.Esatto, no? 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 in codebase 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ù aggiunge 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? Un metodo ecco.Io baro, nel senso che non parto sul codice, se il mio capo mi sta ascoltando con la traduzione in bulgaro, sì parto sul codice, no scherzavo, un approccio misto nel senso che prendo l'applicazione a 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 nel 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 per certi versi.Giustifichare qualunque uso di droga.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, un po' di documentazione riesci a barcaminarti.Se hai 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 Fuzzy? No, giusto una domanda.In caso di codice scritto a caso e hai ovviamente magari sei anche commissionato quindi non è un progetto open source cioè sei commissionato dei 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 no 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 il codice nostro interno poi ha una sua anima open source, quindi viene tutto codice che poi esce.E no, assolutamente non posso permettermi di dire una roba del genere, ma non sarebbe neanche nelle mie corde.Rientriamo nel discorso della valutazione in merito di cui si faceva prima.Cioè, se il codice è scritto veramente male mi prendo due spidine io e magari nel report dico che potrebbe essere migliorato per leggibilità però no rifiutarsi di rifiutare un audit no quello non non è nella nostra missione no no no no no no 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 tre o quattro cve 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? 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 vedere come si comporta il programma.Crasha, 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 eccezioni? Oppure, scusa, io non sono esperto di C, mi ricordo dal tempo dell'università, quando c'era il segmentation fault avevi fatto qualche cagata però su...cioè, una roba semplice.Vuol dire non ci dovrebbe mai essere un segmentation fault in un...No, perché...Che cosa dovrebbe esserci? Che cosa dovrebbe esserci? No, nel senso...Se c'è è sintomo che stiamo accedendo a della memoria a cui non avevamo accesso? Però se è catturato non è corretto? Il segmentation fault si ha quando hai sovrascritto l'instruction pointer con un valore arbitrario per il quale lui va a puntare a un'istituzione di memoria per la quale non ha non ha accesso e quindi ha un errore di segmentazione della memoria e quindi il programma cresce.Ah, ok.Poi può crescere in mille altri modi.Diciamo che dal punto di vista della security è interessante quando tu ottieni quel segnale perché è il sintomo che tu sei andato a potenzialmente manipolare il flusso del programma eseguitivo.Ok, ok.Non è detto che sempre si traduca in un exploit o in un'esecuzione di codici arbitrarie, 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...Che cos'è la script? Cosa vuoi che conti? C'è il browser.Fa tutto lui.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 questa cosa tra l'altro è stata piacevole vederla su un framework come fastify.questa è una piccola parentesi no? nel senso che di solito i framework la validazione la danno implicita o danno dei tool per la validazione ok 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 OASP 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 un ignorante, e mentre lo raccontavi mi è venuto in mente quando ho iniziato a sviluppare il Rails, che è una cosa che il framework ti dava gratis, tutta la parte di escaping del del javascript, tutta la parte di validazione dell'sql quando andavi a fare le query, è una cosa che mi ci ritrovo e tutta la verità è una cosa che secondo me è necessaria che il framework introducono per nascondere allo sviluppatore tutto un lavoro, uno vero e devo di lavoro che non compita a lui.E' standard e poi lo sviluppatore deve scrivere il codice per fare uno shop, per fare un carousel, per fare un sito, 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 security persone di security di andare a migliorare i frame a collaborare con chi scrive i 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 è valido.Tutto quello che non passa quel JSON schema la risposta è...adesso non mi ricordo che cos'è un validation fail o qualcosa del genere...è 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 capellate.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 visto 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 in...che ne so...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 a via che pazienza 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 il grasso che colava.Tu mi dici "allontana dall'awareness" e sì è vero, è vero ed è male, ed è male, è 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 Mindseeker che è 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? Mi vado a leggere il codice di Active Record e lo capisco.E l'approfondimento è una cosa che secondo me è una roba che qualcuno che ognuno di noi ha dentro e vuole farlo ma perché è proprio indole, è proprio indole di andare sotto il cofano a vedere che cosa cosa succede perché eh 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 frame o 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, se ti è capitato mai di sentirla, no? E' Arabe De Palo quando parte lui.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 pentester? In realtà dal punto di vista del pentesting poco e niente perché alla fin della fiera la 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 Monte Monte Bianco tanto i pacchetti lì arrivano è più è più a proceduralmente che devo chiedere magari la manleva a avvisare a il vendor del cloud che sto per fare un test ci sono magari tutte le lungaggini burocratiche da da fare perché giustamente non è un data center in casa del cliente quindi ho degli obblighi anche verso chi fa un chi gestisce quel cloud per dirgli guarda che sto testando il mio questo questo server per il mio cliente ti faccio del traffico anomalo occhio non avvisa il tuo team di security che vedrà arrivare questo traffico anomalo è una cosa autorizzata bla bla bla di solito sì sono abbastanza veloci a rispondere questione reminiscenze di 3-4 anni fa perché giustamente nel lavoro che faccio adesso non è una cosa che provo tutti i giorni però sono abbastanza veloci a rispondere, ti dico sempre 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 si sposta 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 la tecnica d'attacco sì allora ci sono cose in più da controllare magari 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 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 ha bucato uno che magari non c'entra niente con il target che aveva, hai bucato anche il target che ti aveva, che tu avevi in mente.Sai perché ho fatto questa domanda? Perché in realtà il mio team ha avuto un assessment qualche qualche mese fa è 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 pen tester.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 enormi di vulnerabilità specie oggi che l'infrastruttura sta andando a sostituire quella parte di glue code come mi piace chiamarlo me Che prima si 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 di gnubbo sembra un lavoro completamente diverso che far pentesting di un'applicazione che è isolata.Perché è un'operetta di configurazione che tu hai messo on top la parte di gestione delle identità delle persone che vanno a gestire il cloud, la parte di anche sul cloud stesso quindi sì hai aggiunto un'overhead di complessità chiaro se tu la vedi asetticamente come l'applicazione in quanto tale non cambia nulla cambia sì assolutamente la parte di contorno di quindi come l'applicazione vive nel suo ecosistema in cloud Si, ripeto, a me ha in qualche modo stupito il fatto che proprio dall'assessment erano venute fuori ste cose e dicevo "ma cazzo, allora i penteste 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, si.Di questo ci farò la clip, Paolo, permette.una domanda, scusami, perché tanti anni fa ho conosciuto una persona che si occupa, che fa il pen tester, 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, vabbè.È 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? credo che dipenda poi dalla caratteristica della persona e anche dalla sua età anagrafica.Nel senso io a 46 anni non lo farei mai.Avevo pensato quando ho lasciato il lavoro, l'ultimo lavoro prima di andare in Suse, di darmi alla libera professione, al bug bounty, ma poi è arrivata diciamo così questa opportunità che mi ha fatto un pochino rinsavire.No, è assolutamente 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 faccio 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, tanto meglio.però è molto più facile e meglio eh fanno 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 l'audit di quel pezzo di codice sai che ci sei solo te nel bug bounty se l'azienda X dice testatemi questo modulo sai che c'è milioni di persone che stanno provando ad più senti un po' che la competizione magari è proprio quello che è un driver magari per persone giovani tanto sì anche perché io ho visto i programmi di bug bounty che la giocano molto sulla gamification quindi maggiore oltre alla recompensa economica magari hai i punti scali la classifica ti arriva più grossi esatto quelli inviti privati ti arrivano anche i gadget quindi entri in una specie di 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 è una è una nel dorato per la quale ci sta ascoltando domani molla tutto fa bug bounty e fai 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ò...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 effettivamente fanno i gran soldi sì l'ho fatta però non mi sono mai visto con quel cappello per per mie indole per me indole personale c'è mi so che sembra un po si può dire paraculo? A limite puoi biparlo.No, no, parolaccia libera qua.Ah, va beh, potevi dirlo prima, è un'ora che mi trattengo.So che è sempre 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 e 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 della 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 per dire 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 damone 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 ti ha risposto sì quel server e loro pensano che tu avviare il dump del database.Quindi sì no dalla zona grigia cerco di rimanerne lontano.So che sembra abbastanza ruffiano come discorso.No ma magari a chi ci ascolta lo 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 potenti perché ti permette da un sequel di arrivare non solo al dato ma magari almeno tempo fa ti permetteva di eseguire codici all'interno del dbms per la quale eseguivi il common shell e avevi una shell sulla macchina e allora questa potenza è così affascinante parti dal sequel 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 in global senza saperlo e questo è praticamente un mondo.Logg4j, lo abbiamo pensato tutti.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, il mio era notato come side project, internamente l'azienda di fare l'audit delle delle Apache Common di tutto l'ecosistema delle librerie Apache avevo iniziato poi mi è capitato questo audito gigantesco tra cappo e collo che mi sta inglobando da un anno ormai però però sì è una cosa che anche mi aveva preso proprio personalmente mi ero dato come come obiettivo di quello 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 S3 e queste.No ma non è fattibile.se non fosse per per tool automatici tipo renovate bot probabilmente il mio codice sarebbe un collabro 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 parvenza di sicurezza è un atto di delegation, è un mero atto di delegare.Sì, 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 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, l'ho fatto questa analisi per una nostra, un'Hack Week, una settimana in cui noi possiamo lavorare sui progetti che ci piace di più fare l'anno scorso, su appunto cercare di ampliare questa metodologia, questo standard per altri linguaggio ovviamente è 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, il reportino che ti dice se qualcuno c'è andato a fare odito oppure no in maniera tale appunto anche perché non è non è vivibile che tu vai a leggerti tutto il codice di tutte le tue dipendenze.No è oggettivamente possibile.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 e 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 allora 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/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 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ì si scontrava con problemi di natura meramente economica per i 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 per codice Java all'epoca, ma era il limitato perché magari per alcune tecnologie la parte di CodeReview era scoperta.Il pen test si 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 CodeReview perché mi hai messo la pulce sull'orecchia e adesso quella puggia sta ronzando in modo compulsivo dentro.Quando dici tool di code review, qual è il ruolo specifico di questi tool di code review? Fare 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 Dawn Scanner 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.Le ho visti sempre come un grep ++ 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 io 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 vado 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, 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 grab, 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, perché non usi Semgrep? È così semplice! E 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 il certo codice che andava a fare il controllo dell'utente fosse in sessione, fosse autenticato in tanti codici Python.Io quando ho dovuto scrivere la policy in YAML per per farlo, non ce l'ho fatta e 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 tool, con quello che mi dà il sistema operativo e con scriptini che mi faccio a mano.Non ho tanta fiducia nei tool commerciali se vogliamo.Hai parlato di code review.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 mi fa 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 che si chiama 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.E se dentro il team quindi scelare 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, ma 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 eseguire i nostri server.Mettiamo fiori nei nostri 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 scusate di codice di codice sicuro di codreview ma andare a proprio 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 faci con i temi, con i plug-in di WordPress, è una roba allucinante.Però ecco, 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 a 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, 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, non sottovalutare quello che stanno imparando, anche se al momento sembra completamente slegato nel mondo del lavoro, che io ne avrei ancora per 40 minuti per parlarne, e poi di buttarsi su pratica pratica pratica.Pratica pratica cosa vuol dire? Ci sono siti come vulnab, try2hackme, ponix.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 gran marnazzi scusatemi, 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 è avere un portfolio di problemi di security risolti con un 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.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...io in primis ho avuto difficoltà perché andavo a scrivere delle pull request dove la description era "a-a-a" o non era proprio "a-a-a" ma era "questo ripara questa cosa" appunto.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.Io 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.Il mio vecchio capo mi disse "Toto ciao" se neanche...ho saluto già con un sacco di gente scusami se uso questo spazio come come chat personale.Il nostro lavoro di consulenti è 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, quindi è 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 altra domanda.milioni ma non per una prossima puntata.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 vimmi 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.Scegli o no, 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 se c'è spazio, c'è tempo.È il focus anche del team di Odit che fa questo? No, sfortunatamente no.Di solito, 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 è non è in scopo è un'attività di legata al pentest alla simulazione di un attaccante sì assolutamente è una cosa che dovrebbe essere essere fatta il 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.E che forse non si fa abbastanza training, nel senso un operatore di call center che lavora per una banca, "eh no" appunto, e quello appunto dice "si fa o no?" Si fa.Eh, è un problema.Eh sì, è un problema, è un problema, no.Che immagini, no, non si fa training.Io ho visto un video, immagino sia un punto io, sia abbastanza virale, durante un Defcon, 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 c'ho il bambino che piange che sempre fa sì va bello e gli da 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 trovare a e e quell'altro non ha il training adeguato per dire che si parla di psicologia umana e riguarda potrebbero farti anche questo e lì e non è nulla di che colpa no no no è un errore è un errore procedurale che la formazione al al dipendente finale non ha coperto anche questo caso questa tipologia di truffa eh di chi è la colpa la avrebbe dovuto erogare il training però anche lì ci scontriamo con mille altre problematiche se beh insomma la sera che ti rigira siamo sempre a parlare di tempo e sole vuoto per pieno è chiaro che l'operatore di frontiera che ha interfaccia come come le nostre form web che vengono attaccate l'operatore di frontiera è la prima linea di difesa tra virgolette no cento tra virgolette la l'applicazione è la prima linea di difesa della della nostra istituzione quindi dovrebbe essere la persona più eh che subisce più training Sì sì sì nel senso che qualcosa che stava anche un po' in mezzo nel senso che proprio a livello di flussi della dell'applicazione fermarsi un attimo e dire scusate con questo flusso nemmeno troppo psicologicamente penetrante e il problema è girabile.Forse dobbiamo diciamo rivedere questi flussi.Pensavo più diciamo a questo a questo scenario piuttosto che proprio fare l'attacco o simulare l'attacco di social engineering.bene siamo un'ora e mezza raga io ci vi accompagno comunque posso dire pubblicamente sarebbe interessante fare una tipo una puntata in incognito con qualcuno un po' più black hat di Paolo che ha 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ì, poi 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 è Compresi, l'ha detto prima, non la parli di black hat.Ma il suo è double face, è bianchissimo, è verdissimo.No, è green hat, Paolo.Giusto, Pa? Giusto.No, detto questo, in realtà l'ultima domanda per Paolo è "hai anche una felpa nera col capuccio? Sì, te la danno nel manuale, 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 degli venti qui a Bologna di security.Prima parlavi di gadget, forse rientrava in qualche gadget.Quando sono andato speaker mi hanno dato la felpa, 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 un valore di mercato maggiore, no? L'amore per gli adesivi, gli adesivi da attaccare sulla cover del laptop, quello c'è comune 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, 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 non conosco, io Rust non lo conosco, però visto che adesso nel versione 6.2 è ormai ufficiale che è un un linguaggio per scrivere i sottosistemi del kernel di Linux.Mi tocca perché andando a fare audit e 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 del 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...mettiamo tutto nelle note dell'episodio...perfetto questo è open assolutamente te lo è open quindi tutti possono usufruirne.È aggiornato alla 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 per ratta mi girava nella testa, però il barocco 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 deve essere di qualcuno che ha iniziato il capitolo sull'ownership, ha scazzato male e l'ha venduto.Io lì ancora non ci sono arrivato, però poi se lo trovate su Invendita alle Eurossi sono io eventualmente.No, comunque il mio ballocco era un'altra cosa.Visto che è marzo e io sono a Firenze, a marzo a Firenze succede una cosa, c'è l'Open Source Day 2023, organizzata dagli amici di Schrödinger's Hut, così per dire quasi metà degli speaker è stato ospite di Kisper, 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 è un ma comunque potrebbe essere un'occasione per incontrarci.Ne approfitto per mandare un abbraccio agli amici di Schreidinger.Il mio blocco è stato nominato, stavo proprio pensando di portare tryhackme.com, non so se era quello, però io avevo già fatto una volta su...mi ero registrato, 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, che 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.Bellissimo.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 molo.E' una garanzia.No, 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, proprio non proprio fresco di uscita, ma l'ho visto e mi ha colpito e 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 quittografia per arrivare al merkel tree per la gestione delle chiavi sotto chiavi per la validazione insomma c'è un mondo no? Esiste una versione di mastering 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 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 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 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 ragazzi e ragazze di OutZero che un po' racconta questa 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 vederle in modo amichevole e scoprire un po' insomma come funziona e la complessità che ci sta sotto.Per questo Paolo ti ringraziamo tantissimo.Sono io che ringrazio voi 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! Sì, tra l'altro mi accorgo adesso che è verde e potrebbe essere un refrain commerciale incredibile, però è bellissima la mia 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, Gitbar diventa un po' casa tua, quindi quando hai 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à grande gioia.Le porto io da casa.Tra l'altro offriamo noi, offriamo noi e se vai a Firenze offri a 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, caro! Quindi se adesso...Oh scusi, anche questo entrerà nel testo, cioè sono cerca cazzo.Ok, perfetto.si si, cercheremo un cazzo e troveremo Leo che dice no in realtà funziona o almeno dovrebbe, se non funziona ragà fate una PR dicevo se volete supportarci supportateci se non volete supportarci ci basta che lo diciate 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.La troviamo.Detto questo io ringrazio nuovamente Paolo e vi do appuntamento alla prossima settimana.Ciao! [Musica] All'ombra dell'ultimo sole si addormentò un programmatore tra le sue braccia un manuale sognando il mare tropicale.[Musica] con un progetto inconsistente delle richieste da far paura prima di ieri perché ho premura e domando un lavoro in mani con le specifiche più strane Io voglio tutto e pago niente, ho fretta, sono un committente.Gli occhi dischiusi e il softwareista, un video l'unica sua lista, dall'alba grigia fino a sera, incatenato alla tastiera.La la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la.Battendo i tasti a moglio sesso e trascurando cibo e sesso, riusci un bel giorno a consegnare una release preliminare.E si sentivo ormai contento, ma fu sollievo di un momento, La richiamava a quel cliente, qui non funziona un accidente.La la la la la la la, la la la la la la la, la la la la la la la, la la la la la la la.Ricominciò il programmatore, a faticar per ore ed ore, sopra un problema assai intricato, nascosto dentro ad un mistato.Venne di nuovo il committente, disse "così è meglio che niente" E tuttavia per me è importante fare una piccola variante Lalalalalalalalalala Lalalalalalalala Lalalalalalalala All'ombra dell'ultimo sole, dormiva già il programmatore tra le sue braccia o manuale suonando un'aria etropica 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 Full Stack Dead.citandotivideomaggini.vide industryinform вопрос hole x,isw,ab facilita le istituzioni physiologo sicuro oso sono sala mi sono passa il scena di trasporto Sottotitoli e revisione a cura di QTSS
