Si vous pensiez vous mettre à l'abri des scans en déplaçant le port de votre serveurs ssh de 22 à 2222, vous avez tout faux. Tout le monde utilise déjà 2222. Prenez carrément des ports beaucoup plus élevés (hé... vous pouvez aller jusqu'à 65535 !), et surtout n'oubliez pas: Installez fail2ban !
(ou encore, connectez-vous avec des certificats et désactivez les mots de passe.)

Voilà (coucou tester): Java est désormais la principale source d'infection.

J'étais complètement passé à côté de ça (merci Nono): Malekal et botnets.fr se sont associés pour lancer ce site à destination du grand public pour sensibiliser les internautes à la sécurité. Je ne peux qu'approuver (ayant moi-même fait ce genre de page, mais sans doute en moins didactique et attrayant: http://sebsauvage.net/safehex)

Mais enfin... NON !  On utilise JAMAIS un UUID comme token !  Rhhâââ...
Les UUID offrent la garantie d'unicité, mais en **aucun cas** d'aléa non prédictible.
Ou alors il faut recourir à des fonctions crypto, par exemple en concaténant un salt à l'UUID et en hashant le tout (sha1 ou autre). Là on a un token assez solide (et résistant à l'attaque d'anniversaire). L'idéal étant tout de même un véritable générateur aléatoire, mais ce n'est pas à la portée de tous.
(Et là je viens de m'apercevoir que dans Shaarli, comme un con, j'ai oublié d'ajouter un salt avant de hasher pour générer les tokens ...  doh. Rassurez-vous, le risque sécurité est très faible (Je vois mal quelqu'un lancer une attaque d'anniversaire à travers une attaque CSRF... ou alors je me trompe ? En javascript ? ça me paraît assez peu réaliste.)

(Oui j'ai bien conscience que j'ai dû perdre quelques lecteurs depuis le début de cet article.)

EDIT: Si vous voulez patcher Shaarli tout de suite, dans la fonction getToken() modifiez la ligne:
$rnd = sha1(uniqid('',true).'_'.mt_rand());
en:
$rnd = sha1(uniqid('',true).'_'.mt_rand().'####CE QUE VOUS VOULEZ, ÇA PEUT MÊME ÊTRE ASSEZ LONG####');

Et voilà. Bye bye l'attaque d'anniversaire.

Un bug de "privilege escalation"... provoqué par un pilote de carte graphique. Doh.

Bloqué à 200 km/h pendant 200 km dans sa Renault Laguna.
Mais à part ça, tout va bien, les millions de lignes de code des automobile n'ont pas de bug. Non non, ce n'est pas possible.
EDIT: ça pourrait être une manœuvre de la part du conducteur (merci : http://www.courrier-picard.fr/courrier/Actualites/Info-regionale/Miracule-mais-sans-permis-de-conduire (via g.neuromancien.free.fr)

Pourquoi, hein, pourquoi les Chinois ont-ils le plus gros taux d'infection par des malwares ? Parce que ce sont les plus gros utilisateurs d'Internet Explorer.
Et quand je parle d'IE, je parle aussi d'IE6. Oui oui, vous avez bien lu.
Quand IE6 est à 0,4% aux USA ou 0,1% en Norvège, est il à 21,3% en Chine (!).
(source: ie6countdown.com)

Et vous vous doutez bien que s'ils sont aussi en retard sur les navigateurs, ils doivent avoir aussi plusieurs versions de retard sur Flash, Java et Acrobat Reader.  Je vous laisse imaginer la boite de pétri que ça donne.  Pouah.

Et après ont s'étonne de voir des attaques ou du spam venir d'IP chinoises...

Cette page recense différentes formes d'attaque (dont XSRF). Pas encore eu le temps de lire mais ça a l'air bigrement intéressant.
Ça explique aussi la raison pour laquelle Google ajoute while(1); au début de tout json renvoyé par des services comme GMail: http://stackoverflow.com/questions/3146798/why-do-people-put-code-like-throw-1-dont-be-evil-and-for-in-front-of

à mon avis, une lecture à garder sous le coude sur la sécurité web.

Héhé... Je n'avais pas regardé mes logs de connexion Shaarli, et j'y ai vu ça:

2012/08/18_13:51:38 - 82.242.x.x - Login successful
2012/08/18_14:39:50 - 82.242.x.x- Login successful
2012/08/18_15:18:02 - 92.147.x.x- Login failed for user sebsauvage' --
2012/08/18_15:18:17 - 92.147.x.x- Login failed for user sebsauvage" --
2012/08/18_15:38:51 - 82.242.x.x- Login successful
2012/08/18_16:10:54 - 82.242.x.x- Login successful

C'est mignon   :-D

Héhé... le patron de Mega offre 10 000 euros à qui arrivera à casser la sécurité de sa nouvelle plateforme.
Y'a pas à dire, il sait communiquer. C'est une bonne manière de contrer les très nombreuses critiques envers le nouveau Mega.

Sauf Flash ?   :-/
C'est quand même l'une des principales sources d'infection.

Énorme. Absolument énorme. Les mots de manquent. Ça c'est du business de pro. Leur offre "cloud" me semble d'autant plus tentante.
(merci à Jérôme R. pour la capture).
EDIT: Nous sommes en novembre 2013, SFR n'a pas changé: http://bluetouff.com/2013/11/20/le-message-hilarant-de-linterface-de-gestion-des-dns-chez-sfr-business-team/

Mega répond sur les nombreuses critiques concernant la faiblesse de leur crypto et leur sécurité.

moui, à voir: https://detectify.com

Woao... Google s'intéresse aux excellentes YubiKeys ? C'est bien. En prime, c'est assez facile à implémenter pour vos propres applications.

Et hop... encore un 0-day Java  :-/

Ding dong ! C'est l'heure de mettre - ENCORE - Flash et PDF Reader à jour: Il y a des failles de sécurité.
En principe Flash se mettra à jour automatiquement, mais si ce n'est pas le cas, faites-le vous-même: http://ninite.com/flash-flashie/

Hé ouais... les jetons dans les formulaires. C'est con hein, mais c'est indispensable pour se protéger des attaques de type CSRF (Cross site request forgery).

Et croyez-moi, pratiquement *AUCUN* site ne le fait (J'ai déjà piégé des modos de CCM avec ça. Assez poilant.)

Pourtant c'est assez facile de protéger ses applis. Si ça vous intéresse, jetez un coup d'œil aux sources de Shaarli: Il y a 2 petites fonctions php qui génèrent et contrôlent les tokens attachés à la session (getToken() et tokenOk()). C'est très simple. (C'est opensource: vous pouvez réutiliser ces fonctions.)

Le principe est d'inclure un token dans tout formulaire qui agit sur les données (getToken()), et lors du traitement de ces formulaires de s'assurer qu'ils contiennent un token valide (tokenOk()). Un attaquant ne pourra pas générer de token valide, et votre appli rejettera la requête (Dans Shaarli, je fais juste un die("Wrong token.");)

Failles chez Facebook qui permet d'enregistrer un utilisateur Facebook à son insu à travers sa webcam et le poster sur son mur... sans que l'utilisateur en ait conscience.
Facebook a juste mis 5 MOIS pour corriger la faille.

Un cache web réparti, en P2P, pour accélérer la consultation web ? Pourquoi pas.

EDIT: Comme me font remarquer Sam & Max:
Dans http://www.hola.org/legal/sla/ on peut lire: "The source code, design, and structure of the Software are trade secrets. You will not disassemble, decompile, or reverse engineer it, in whole or in part".
Donc: NON. Hors de question.

PS: Le titre est totalement faux. Ce logiciel d'Elcomsoft ne crack pas les partitions TrueCrypt: Il essaie de récupérer les clés de chiffrement en mémoire vive.

Bof... Franchement mettre sa machine en hibernation avec un conteneur TrueCrypt ouvert, faut être stupide (ou inexpérimenté).
Et puis ce n'est pas pour rien si TrueCrypt a des options de démontage automatique en cas de mise en veille, de déclenchement de l'économiseur d'écran ou d'inactivité sur le volume chiffré. Il faut peut-être penser à les activer.

Si vous avez une porte super-blindée mais que vous laissez vos clés sous la paillasson, il ne faut pas être surpris de se faire cambrioler. Le problème n'est pas la sécurité de la porte blindée, c'est votre comportement.

Oho... pas mal. Après l'attaque par HashDOS des framework web (cf. http://sebsauvage.net/links/?-A9eag), il semblerait que certains systèmes de fichiers soient également sensibles à cette attaque, comme btrfs.

Facebook = passoire.
Il est possible d'obtenir le numéro de téléphone ou l'adresse e-mail associée à un compte Facebook, même si l'utilisateur a mis ces informations en privé.

Rappel sur la (non) sécurité des puces NFC: Non seulement c'est mal sécurisé, mais en prime on peut intercepter les transmissions à 15 MÈTRES.
Et toutes les cartes bancaires en sont maintenant équipées. (Si vous avez ce logo: http://sebsauvage.net/files/20120921_logo_nfc.jpg alors votre carte bancaire est aussi NFC).

Tiens... Tuto4PC, trop détecté par les antivirus, a sorti un nouvel exécutable, servi sur de nouveaux domaines.
Merci à Malekal pour sa vigilance.