[<--] Indice [-->]

From Claudio <vecna@s0ftpj.org>
Date Thu, 23 Jun 2005 08:52:50 +0200
Subject Re: [Hackmeeting] riguardo ai fatti del server di autistici [was:Re: ah, le foto, la privacy] 

Wed, 22 Jun 2005 23:47:54 +0200 koba@sikurezza.org:

> Una buona  cosa (mi riallaccio alla  mail di vecna) e'  la cifratura
> dei dischi,  che non  risolve comunque  il problema  della sicurezza 
> fisica della stazione ma puo' rendere un po' piu' difficile l'attacco.
comprare una macchina all'estero non e` cosi` difficile, basta un po' di
hosting in un paese straniero e si risolvono potenzialmente un po' di
problemi aggiuntivi. ok non si potra` andare a cambiare l'hardware, ma
... ha importanza rispetto ai vantaggi :) ? 

nella mia email volevo appunto focalizzare l'attenzione sulla cifratura
e sulla possibile "cifratura integrale", ieri sera con grande stupore
ho scoperto non serve far alcuna patch come m'aspettavo ...

> Il problema e'  che, soprattutto con gli strumenti  integrati nel
> kernel(dm-crypt, cryptoloop), si possono fare home e partizioni varie
> cifrate, ma e' piu' difficile cifrare swap, tmp e root; l'attacco
> rimane comunque abbastanza  semplice (di  default per  esempio i 
> certificati stanno  in partizioni non  cifrate) o cmq  basta troianare
> la macchina  e catturare password  delle  partizioni  quando  queste
> vengano  montate
cerchiamo anche di rimanere sul nostro "modello di difesa". sicuramente
se in 2 ore di downtime arriva una squadra di reverser, una di
crittografi ed una di fancazzisti allora tutto puo` essere troianato
poco a poco, ma in un mondo reale il consulente che fa acquisizione di
un disco non sa troianare un software, cross compilarlo e mettertelo sul
disco *senza montarlo* e *senza avviarlo*, si va incontro a problemi
tecnici non indifferenti e non sostenibili da un'azione di analisi tale
che come mira ha quella di non far sembrare niente.

comunque, 

> Anche cifrando la root (p. es.  loop-aes), rimane un punto d'attacco;
> il kernel deve per forza stare in una partizione non cifrata (o cd,
> floppy, usb, etc;  non cambia molto)  insieme a qualche  modulo e i 
> binari tipo mount, losetup e antani.
http://wiki.blagblagblag.org/Encrypting_Root_Filesystem

questo e` piu` o meno uno studio che cercavo di fare, san naif m'ha
detto che c'e` gia`, meglio cosi` :) praticamente integra gnupg con
dm-crypt. il problema probabilmente e` sorto da: "come posso cambiare la
password di dm-crypt ?" non si puo', pero` si potrebbe tenere la chiave
cifrata in modo simmetrico e poi cambiare la password al file che la
contiene. allo stesso modo puo' esistere un sistema minimale che
supporti il boot, un servizio di rete .. e quando la macchina va giu` un
utente si logga da remoto e fa bootare il resto. si ok puo' esistere
software troianizato, ma chi da parte sua ha la fretta e la necessita`
d'essere precisio suppongo:

1) eviti
2) non rischi
3) non rischi assolutamente
4) se rischia fa molte prove ed appena qualcosa si discosta abbandona

in quest'ottica suppongo che qualche rapido integrity check (tipo
md5 dei binari) over ssl (nel senso che i checksum stanno in remoto
accessibili solo al server) possa essere fatto ad ogni boot. ok e`
possibile TUTTO, ma solo in un film fantascientifico senza saperlo
qualcuno craka questo sistema mentre viene simulato un downtime.

ciao :*
Claudio/vecna




-- 
0xC2752D4B pgp.mit.edu - http://www.gnupg.org - http://www.s0ftpj.org

Attachment: pgp00061.pgp
Description: PGP signature

_______________________________________________
Hackmeeting mailing list
Hackmeeting@inventati.org
https://inventati.org/mailman/listinfo/hackmeeting
[<--] Indice [-->]