Cela dit, rien que sur ce point là (l'envoi d'un mail piégé avec un trojan dedans), on se doute fortement que ça sera un bon vieux trick de social engineering invitant la "victime" à cliquer sur une pièce jointe piégée attachée au mail, mais...disons que ça a de fortes chances d'atteindre un taux d'échec assez élevé ce truc là (puis pour peu que le serveur de mails soit doté d'un antispam/antivirus un tant soit peu efficace)Dans ce cadre défini, les policiers, commis sur commission rogatoire, peuvent « mettre en place un dispositif technique ayant pour objet, sans le consentement des intéressés, d'accéder, en tous lieux, à des données informatiques, de les enregistrer, les conserver et les transmettre, telles qu'elles s'affichent sur un écran pour l'utilisateur d'un système de traitement automatisé de données ou telles qu'il les y introduit par saisie de caractères »
L'installation de ce dispositif technique pourra se faire aussi bien physiquement (grâce à l'introduction de la police dans un véhicule ou dans un lieu privé) que via la transmission par un réseau de communications électroniques (comme par exemple grâce à un courriel piégé avec un spyware).
mardi 16 février 2010
loppsi
hacking PSP et chinois du FBI
[...] Ce nouvel essai, le 6.20MAD-003, se présente sous une nouvelle forme avec un exécutable Windows (start.exe) et un fichier pour la PSP. [...]Dans l'archive en question, un lien est donné vers un site "étrange", qui affiche les IP et infos navigateur des potentielles "victimes". Je n'ai pas jeté de coup d'oeil au fichier exe incriminé, et ne sait encore moins ce qu'il fait précisément, mais ça ne m'étonnerait pas que ça soit une bonne vieille backdoor, et que les IP de ce site soient majoritairement des gens ayant cliqué sur cet executable, et donc potentiellement infectés.
Comme vous le savez sans doute, lancer un programme sur son PC sans avoir la certitude de la qualité morale de son créateur est toujours une expérience à éviter. Ici, il faut reconnaître que cet exécutable est loin d'être clean et si vous le lancez sur votre PC plusieurs choses louches semblent se passer. Il semblerait que ce soit un virus ou quelque chose d'approchant. [...]
Ensuite, ce truc essaye de modifier des Dll de Windows (le logiciel de surveillance a réagi lors du lancement de celui-ci sur notre PC de test) : SXS.DLL, xpsp2res.dll CLBCATQ.dll et shell32.dll. A priori, cela ne peut affecter que les utilisateurs de XP car au dessus les dll sont normalement protégés par Windows.
[1] source pour cet article: http://www.pspgen.com/custom-firmware-6-20-auteur-disparu-actualite-192448.html
vendredi 15 janvier 2010
vendredi 8 janvier 2010
Factorisation d'une clé RSA de 768 bits
The following effort was involved. We spent half a year on 80 processors on polynomial selection. This was about 3% of the main task, the sieving, which was done on many hundreds of machines and took almost two years.Quand ils parlent de "many hundreds of machines", c'est un immense cluster réparti sur plusieurs pays. Mais là encore, la lecture du pdf est probablement plus intéressante. A noter également cette petite info:
On a single core 2.2 GHz AMD Opteron processor with 2 GB RAM per core, sieving would have taken about fifteen hundred years.Ainsi que:
Preparing the sieving data for the matrix step took a couple of weeks on a fewprocessors, the final step after the matrix step took less than half a day of computing, but took about four days of intensive labor because a few bugs had to be fixed.Je ne vais pas parler des détails mathématiques concernant cette belle performance, je ne suis pas très orienté maths :) Par contre, on peut toujours s'intéresser à l'impact que cela peut avoir sur la sécurité-informatique-de-l'internet-mondial (ah non, c'est vrai que l'idée de nationaliser "l'Internet" a été émise [1]).
Premier exemple qui me vient à l'esprit, le fait que nos cartes bancaires utilisent une taille de clé RSA de 768 bits (elles étaient à 320 bits avant l'affaire Humpich). Même si factoriser un nombre de cette taille a pris un peu de temps avec quelques milliers de machines, on pourrait se demander si ça ne sera pas faisable avec un botnet un de ces jours, par des gens pas spécialement bien intentionnés (bon en meme temps, y'a d'autres moyens d'abuser des cartes bancaires, comme les cloneurs de cartes qu'on trouve parfois sur des ATM).
Ensuite, bien sûr, l'utilisation de RSA en cryptographie dans la vie de presque-tous-les-jours (comme PGP [hein ? vous ne chiffrez pas vos mails ?!]). Un document trouvé sur le site de l'ANSSI nous conseille ces tailles de clé:
RègleFact-1. La taille minimale du module est de 1536 bits, pour une utilisationEn gros, 1536 bits est le minimum à utiliser actuellement, mais 2048 bits sont recommandés. Ensuite, l'utilisation de la crypto ne doit pas être vue comme un moyen ultime d'empêcher quelqu'un de consulter des documents qu'il ne devrait pas consulter de manière perpétuelle, mais plutôt de le ralentir dans cette démarche. Tout dépend donc de la période pendant laquelle on souhaite rendre le document inaccessible.
ne devant pas dépasser l’année 2010.
RègleFact-2. La taille minimale du module est de 2048 bits, pour une utilisation
ne devant pas dépasser l’année 2020.
RègleFact-3. Pour une utilisation au-delà de 2020, la taille minimale du module
est de 4096 bits.
RègleFact-4. Les exposants secrets doivent être de même taille que le module.
RègleFact-5. Pour les applications de chiffrement, les exposants publics doivent
être strictement supérieurs à 216=65536.
RecomFact-1. Il est recommandé d’employer des modules d’au moins 2048 bits,
même pour une utilisation ne devant pas dépasser 2010.
RecomFact-2. Il est recommandé, pour toute application, d’employer des exposants publics strictement supérieurs à 216=65536.
RecomFact-3. Il est recommandé que les deux nombres premiers p et q constitutifs du module soient de même taille et générés aléatoirement.
On note au dessous une explication quant à la raison du non-choix d'une taille de clé RSA de 1024 bits, qui, bien que non encore factorisé, reste sujet à controverse et est donc un mauvais choix si l'on souhaite maintenir un niveau de sécurité conséquent. D'ailleurs, il va être temps que je passe ma clé PGP perso à une taille de clé supérieure, au détriment des performances de mon téléphone (openpgp sur mon téléphone prend de longues secondes pour déchiffrer un mail chiffré avec une clé de 1024 bits: j'imagine à peine le résultat avec 2048. Le pire restant 4096, car là, l'OS du téléphone tue le thread de déchiffrement)
Une alternative intéressante: les courbes elliptiques, qui demandent une taille de clé moindre, pour une sécurité équivalente.
Il ne me reste plus qu'à vous souhaiter, en retard, une bonne année.
[1] Idée évoquée par un député Français, pour faire comme en Chine afin de se protéger d'une hypothétique menace étrangère qui n'existe probablement pas. Quand on commence à prendre en exemple la Chine, je pense que là y'a du danger et personne ne peut nous sauver)
mardi 1 décembre 2009
Old school exploit
Je ne pensais pas revoir de failles de ce style de mon vivant. Certaines, par le passé, ont été assez violentes, mais dans mes souvenirs, assez rares. Eh oui, on peut le dire, cette faille fait très "90's".
Sur son (super) blog, xorl explique assez clairement le pourquoi du comment de la faille. Et pour ceux qui ne comprennent pas le post de xorl, un patch temporaire (à utiliser à ses risques et périls) est disponible. Il s'agit d'un patch assez violent qui se contente d'essayer de désactiver les variables d'environnement qui doivent l'être (lorsqu'un binaire suid-root est exécuté), et qui s'il n'y arrive pas, bloque l'exécution du binaire. Un patch plus abouti fera un peu d'assainissement de l'environnement je pense (en désactivant pour de bon les variables d'environnement comme LD_PRELOAD)
En tout cas, sur mon FreeBSD 7.2, l'exploit fonctionne très bien :-) (il ne fonctionne donc pas que sur FreeBSD 8.0)
freebsd% sh sploit.shEdit: Il y a également un exploit de stealth (Sebastian Krahmer), blindé d'explications, et qui à priori date d'il y a un petit moment.
env env.c program.c program.o sploit.sh w00t.so.1.0 FreeBSD local r00t zeroday
by Kingcope
November 2009
env.c: In function 'main':
env.c:5: warning: incompatible implicit declaration of built-in function 'malloc'
env.c:9: warning: incompatible implicit declaration of built-in function 'strcpy'
env.c:11: warning: incompatible implicit declaration of built-in function 'execl'
/libexec/ld-elf.so.1: environment corrupt; missing value for
/libexec/ld-elf.so.1: environment corrupt; missing value for
/libexec/ld-elf.so.1: environment corrupt; missing value for
/libexec/ld-elf.so.1: environment corrupt; missing value for
/libexec/ld-elf.so.1: environment corrupt; missing value for
ALEX-ALEX
# id; uname -sr
uid=1001(meik) gid=1001(meik) euid=0(root) groups=1001(meik),0(wheel)
FreeBSD 7.2-RELEASE
lundi 23 novembre 2009
Fedora 12 et séparation des privilèges
Un bien bel exemple, assez représentatif du concept de "en voulant simplifier la vie à l'utilisateur, on réduit le niveau global de sécurité d'un système". En gros, sans entrer trop dans les détails (les posts sur la mailing list, et la "wave" sur Google Wave, liés à ce problème, seront plus précis et plus instructifs), tout utilisateur sur le système peut installer n'importe quel package signé sans avoir à donner de mot de passe root (bon, après tout, sur une distribution Ubuntu, on utilise sudo et on donne le mot de passe de l'utilisateur connecté pour installer des packages). Certains peuvent se demander où est le problème. Il est là: The default configuration of PackageKitinFedora 12 permits non-root users to install signed rpm packages from configured yum repositories. This creates a number of potential security problems including the possibility to: 1) Execute a remote-root exploit by exploiting a networked client such as firefox, Adobe flash, pidgin, xchat, etc. to obtain a remote user shell, and then installing a signed package from a configured repository which contains a local-user to root privilegeescalation vulnerability to gain root. 2) Similar to #1 above, but downloading a signed rpm from a previous OS release that has a known user-to-root shell vulnerability, and doing a local install. 3) Similar to #1 above, only doing a denial of service attack by installing a massive number of applications (in one massive transaction, or many smaller ones), and possibly tying up a large amount of network bandwidth, spiking the system CPU load, causing an out of memory condition, etc. Au final, après un long troll (dont j'ai pris connaissance en lisant dailydave), une décision importante a été prise et annoncée par le type qui maintient le package responsable de ce léger défaut: "After more discussion and thought, though, the package maintainers have posted to the fedora-devel-list mailing list agreeing to provide an update to Fedora 12's PackageKit. The update will require local console users to enter the root password to install new software packages." A part ça, sans transition, Google Wave c'est rigolo 5 minutes, mais je pense qu'une majorité de gens ne savent pas encore trop à quoi ça peut leur servir. J'aurai peut-être quelques invitations à refiler d'ici quelque temps. Pour le moment, à part ce qui peut s'apparenter à un échange de "mails" (qui s'appellent des "waves" là dedans), et un test de twitter-via-gwave, je n'ai pas fait grand chose. Par contre, il faudra envisager les plugins permettant de chiffrer/déchiffrer ce qu'on envoie sur wave :-)

