Re: [Hackmeeting] opinioni su crypto.cat, kyloggers e chiavi…

Borrar esta mensaxe

Responder a esta mensaxe
Autor: brno
Data:  
Para: hackmeeting
Asunto: Re: [Hackmeeting] opinioni su crypto.cat, kyloggers e chiavi segrete
Il 2015-09-15 12:12 Igor Falcomata' ha scritto:
> On Mon, Sep 14, 2015 at 09:47:59AM +0000, brno wrote:
>
> Non ho capito se hai letto di fretta, se sei un troll, se non hai idea
> di quello che stai dicendo o se mi stai a socialengineerizzare.
> Propendero' per il primo caso.
>
>> per esempio, se hai una macchina compromessa, non hai un grosso
>> vantaggio
>> nello scrivere le pwd in terminale anziche' in X (perche' anche le pwd
>> ssh/gpg/vpn dopo averle usate restano nella mem della shell, puoi
>> confermarlo se provi a dumpare la mem di bash e greppare la tua pwd in
>
> facciamo cosi', dimmi la tua pwd che provo a grepparla :)
>
> Se non sei root e riesci a leggere la memoria di un processo di un
> altro
> utente[1], fammelo sapere che mi interessa.
>


se hai un kernel mem leak e molto molto culo puoi sfruttarlo senza avere
la root per leggere, per esempio, file sensibili allocati da user space
(su legge shadow ad ogni avvio, tipo),
a volte dimenticano di azzerare la memoria, anche quella servita dal
kenrel ai processi, ma credo che nessun exploit writer sano
di mente si bruci una vuln cosi' per fare questa roba (e poi non e'
detto che si e' fortunati a poter leggere quel che serve), visto quanto
pesa avercela per bypassare ASLR per un futuro local exploit :)


> Se hai la macchina root-compromessa, hai gia' altri cazzi. Il mio
> threat
> model e' exploit nel browser o in altra app X (che in caso di RCE puo'
> "vedere" gli eventi Xorg) che gira con uid diverso da quello con cui
> uso
> le chiavi di cui sopra. E' la terza volta che lo dico, se non ti e'
> chiaro faccio un disegnino :)
>
> [1]: con grsecurity, neanche dello stesso per altro
>
> koba@katom:~$ strace -p`pidof ssh-agent`
> strace: attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
>



effettivamente c'e' stato un fraintendimento totale (da parte mia),
presupponevo che si fosse gia' root,
visto che di tutta la catena la parte priviledge escalation penso sia la
meno complessa (escludendo grsec, sandbox ed hardening vari)
ed in questo caso, siamo d'accordo, ci sono ben poche cose da fare..
beh si, penso sia molto piu' complesso un remote (in questo caso
particolare per il browser) che un local, o almeno in passato era cosi',
ma potrei sbagliarmi

ad ogni modo cretinate tipo alias ssh="strace -eread -o /bla/bla.txt
ssh" siano meglio di un keylogger in alcuni casi