Ovviamente la qualità del codice dipende unicamente dal modello open source o meno, non da chi lo scrive o mantiene la repository 
Ma come si sta ribaltando tutto cit.
Più seriamente, mi aspetterei molti piu occhi puntati su Signal, che è l app portata come eccellenza per quanto riguarda comunicare in sicurezza. Open source, protocolli standard, no profit, e2e encryption…. E invece taac
signal honeypot cia
Dai che il discorso non era questo, avevo scritto che a parità di tutto il resto, avere il codice aperto o meno rende più facile trovare eventuale codice malintenzionato. Ed è così palese la cosa che non mi va neanche più di ribadirlo
1 Like
Ma non è vero, ci son stati altri redflag su Signal
Ecco appunto
Non ne sono a conoscenza, quando leggo online viene sempre portata come app n1 per comunicare in sicurezza quindi rimango abbastanza sorpreso.
Dove leggete voi che app si consigliano al giorno d’oggi?
Ad esempio ancora di recente ho visto giornalisti chiedere di essere contattati via telegram per tutto quel che deve rimanere riservato
dai vendor di droghe
quella che va per la maggiore ultimamente è Session
1 Like
Crypto 
ci andrei coi piedi di piombo già che leggo che è basata su un token, ma leggero come funziona per curiosità, non la conoscevo
E comunque puoi essere open source quanto vuoi ma se un app viene pubblicata su uno store nessuno ti garantisce, a meno di build riproducibili, che quello che il codice che vedi è quello che installi. Che io ricordi almeno fino a 2 anni fa la versione iOS di Signal non ce l’aveva
Inutile dire che tutto questo rientra nel grande piano di “fanculo gli store decido io cosa va installato esattamente sul mio dispositivo” etc etc
guarda io mai usata, quindi non ti so dire in effetti pregi/difetti ma vedo che molti vendor la usano.
altra chat che dovrebbe essere sicura è Matrix (https://matrix.org/) ma è una menata da configurare/installare e non è esattamente user friendly. ha però un concetto carino che è quello dei bridge dove puoi interfacciarti con altre app di messaggistica (tipo telegram) ma in quel caso non ho ben chiaro fin dove arrivi encryption e compagnia bella
1 Like
ma che poi cercando se signal crittografa i files. esce fuori che si sa da un bel po’
“We’re not going to be adding any local access control or protection. You can use Chrome profiles, full disk encryption, and a screenlock.”
prime robe che ho trovato
Qui gli store e le build riproducibili non c’entrano una sega però eh
Aggiungiamo solo un +1 al counter di queste situazioni per cui “come è possibile che sia successo nessuno si è letto il codice open source” e fine.
Tra l altro penso proprio che in questo caso è ancora più grave dettato dal fatto che non stiamo parlando di un buco di sicurezza di un protocollo non implementato correttamente o librerie con problemi salcazzo, qui sembra proprio un errore banale a mio avviso, salvare della roba in chiaro su file system dove tutti possono leggere, roba che immagino un ricercatore average di sicurezza beccherebbe al primo colpo…
Si, il mio discorso era su “Signal è sicuro”. Comunque ha già scritto tutto @Nightmare sopra, se è “per design” fanno proprio cacare loro, non penso sia stato introdotto a questo punto 
Ho letto il primo messaggio di quel thread e mi pare si stia parlando di roba totalmente diversa .
Non male. Per me finora la reward piu’ alta e’ stata di 38K per un bug nel tax admin system della Finlandia, che mi consentiva di accedere a praticamente tutto 
Povera Taylor, adesso come fara’ a farsi il secondo billion
Ora non voglio creare una polemica inutile: però quando si analizza la sicurezza di un’applicazione bisogna anche considerare quale è il threat model.
Bisogna per esempio comunque considerare che dove vengono salvati i dati rimane comunque il tuo dispositivo. Se un estraneo riesce ad avere accesso al tuo dispositivo (da remoto o con accesso fisico), allora il tuo problema sta da un’altra parte, ed è decisamente più grave del fatto che un’applicazione di messaggistica, il cui scopo è principalmente quello di impedire l’intercettazione dei dati intransito, abbia salvato localmente degli allegati.
Poi non è chiaro un aspetto fondamentale: l’allegato viene salvato su disco IN FASE DI RICEZIONE, o DOPO CHE VIENE APERTO?
perchè lì l’utente apre l’immagine prima di far vedere che questa viene salvata, e secondo me c’è una bella differenza.
E comunque in definitiva è inutile che stiamo qui a farci mille pippe sulla questione sicurezza e riservatezza delle informazioni: tanto a livello di opsec, di cazzate ben peggiori ogniuno di noi ne fa, e il problema degli allegati salvati su disco è l’ultimo dei problemi; e ribadisco, se qualcuno ha accesso a quei file sul disco del tuo sistema hai ben altro di cui doverti preoccupare.
Son d’accordo in linea di massima anche se va contestualizzato al fatto che stiamo parlando di Signal.
Un app che viene usata moltissimo in ambiti dove chi la usa rischia di grosso, tipo giornalisti che hanno a che fare con grossi scandali.
In questo contesto correggetemi se mi sbaglio ma l attacco sta nel fatto che un altra app nel sistema possa leggere quei dati in chiaro, non è tanto questione che uno è loggato dentro il tuo portatile con la tua password.
Se i dati vengono criptati (così come avviene giustamente per le conversazioni) allora anche se ti scarichi la libreria malevola che nel post install fa un check nella cartella /qualcosa/signal/foto si becca roba criptata e tanti saluti
In linea di massima la questione della crittografia dello storage applicativo avrebbe senso, però ovviamente poi quei dati (allegati) li apri solo con l’app.
Lì viene fatto l’esempio di un’immagine ma allora dobbiamo considerare che un giornalista o un whistleblower lavora anche con altri tipi di documenti, che devono venir salvati fuori dal “vault” (chiamiamolo così) di signal per poter essere aperti con gli applicativi nativi, e allora anche lì ti esponi.
Secondo me in quel tipo di contesto, se sei davvero SERIO riguardo alla sicurezza e temi di poter avere applicazioni sul sistema che canappano i dati, devi iniziare a pensare di compartimentare tutto in maniera molto più resiliente.
Mac OS X non è un sistema pensato da zero per compartimentare i contesti di esecuzione.
A quel punto l’unica soluzione che ti può davvero salvare è qualcosa tipo qubeOS, o l’impiego intenso di tante virtual machine che vengono usate ogniuna per il proprio contesto operativo, in modo da evitare che i “micromondi” leakino informazioni uno con l’altro.
A quel punto tieni l’applicazione di messaggistica in una VM dedicata, e sei sicuro che altre applicazioni, che girano in altre VM, lì non ci arrivano (ok salvo exploit di escape to host, ma lì l’asticella si alza parecchio.
1 Like
Se questo mi viene confermato sono altre 3K :D Non tantissimo perche’ questa azienda non paga molto, ma ho impiegato 4 ore su questo target.
Questa e’ la seconda volta che faccio escalation di LFI (Local File Inclusion) a RCE (Remote Code Execution) in pochi mesi.
Il target e’ una PHP app on una LFI vuln che mi consente di far rendere a PHP un file il cui path specifico in un parametro. Il file non viene reso (si dice cosi’ rendered?) cosi’ come e’, ma viene fatto parsing con PHP. Potevo gia’ riportare la LFI perche’ ho trovato per esempio config file con credenziali database e API keys, ma ho continuato.
Dal momento che posso far rendere il file che voglio, posso far rendere il log di Apache. Ho inviato una richiesta che include un PHP code snippet nello user agent.
Dal momento che Apache aggiunge lo user agent al log per ogni richiesta, quando il file viene processato da PHP il mio code snippet viene eseguito; il code snippet esegue il comando OS che specifico nel param cmd, quindi → RCE. Posso anche avviare una reverse shell cosi’. 
3 Likes
Moar
https://x.com/mysk_co/status/1809287118235070662?s=46
Questa è abbastanza pesante, anche più dei file non criptati. Multiple sessioni aperte senza nessun segnale