Un logiciel de téléchargement à bannir: il effectue dans votre dos des attaques DDOS.

Woua... un registrar a été piraté, ce qui a permis de détourner carrément les sites du New-York Times, Twitter, ShareThis et Huffington Post vers des IP malveillantes.
Ce genre d'attaque contre les registrars est assez rare: les pirates s'attaquent généralement aux serveurs web eux-mêmes, aux inclusions (régies de pub), voir aux serveurs DNS.

Oh merde...   http://www.urbanterror.info/news/423-git-repository-hacked/

Là où tous ces tests se plantent, c'est qu'il comptent le nombre de caractères et en déduisent le nombre de bits, donc la sécurité. Mais c'est idiot.
Votre "manger couchette rose" est à peine plus sûr que "mcr": Le pirate, au lieu de rechercher en combinant des lettres, fera juste une recherche en combinant des mots. Et il y a déjà des tonnes de dictionnaires prêt à l'emploi sur le net.
Ces tests de sécurité des mots de passe ignorent ce fait et se contenteront de compter le nombre de bits, en partant du principe que le pirate essaiera toutes les combinaisons de bits ou de lettre (aaa, aab, aac...). Ils n'évaluent pas le temps nécessaire à la combinaison de mots issus d'un dictionnaire.
Si je prend un dictionnaire de la langue anglaise, "this is fun" prendra juste quelques minutes à trouver puisqu'il n'y a qu'à chercher la combinaison de 3 mots.

Exemple d'utilisaton de duplicity pour faire ses backups incrémentaux et chiffrés. Incrémentaux car seuls les fichiers modifiées sont envoyés, et chiffré (avec GPG) pour faire ses backups vers des serveurs qui ne sont pas forcément à nous.

+1
Chiffrés ou non, je ne laisse jamais un logiciel stocker mes mots de passe. *Jamais*.

Résumé de la Black Hat Conference, selon Kaspersky: La conclusion ? Très sombre: Question sécurité, le web est cassé et il n'y a pas vraiment de moyen de corriger le tir sans tout refaire. La cause majeur de cette insécurité ? Javascript !

TL;DR un certain nombre de noeuds TOR auraient été compromis, y compris distribuant des attaques javascript. L'attaque ne marche que:
    1) si vous activez javascript (interdit par défaut dans TorBrowser - ne jamais activer !)
et 2) si vous utilisez le même navigateur pour surfer normalement (ce qu'il ne faut jamais faire).

EDIT: TorMail est accessible.  La nouvelle chez TorProject: https://blog.torproject.org/blog/hidden-services-current-events-and-freedom-hosting
EDIT: Liens complémentaires: http://shaarli.cafai.fr/?PxOciw

:-)

| 2012/08/18_15:18:02 - 92.147.215.x - Login failed for user sebsauvage' --
| 2012/08/18_15:18:17 - 92.147.215.x - Login failed for user sebsauvage" --
Non non, n'insistez pas, y'a pas de SQL dans Shaarli  :-D

| 2012/11/02_18:33:15 - 80.185.48.x - Login failed for user audrey djiboutipresse
Gni ?

| 2012/12/27_02:49:23 - 113.212.70.x - Login failed for user discount north face denali  
Sans doute un bot spammeur un peu plus con que les autres...

| 2013/02/03_22:49:43 - 78.230.75.x - Login failed for user Donc_on_peut_envoyer_nos_commentaires_comme_ca_Cool.:D
Petit malin  :-)

| 2013/02/04_14:19:09 - 82.127.2.x - Login failed for user Coucou :P !
Coucou.

| 2013/02/15_21:01:04 - 78.231.35.x - Login failed for user eolivier
| 2013/02/15_21:01:51 - 78.231.35.x - Login failed for user oups-sorry-trompé-de-shaarli
Y'a pas de problème  ^◡^

| 2013/02/27_05:36:26 - 178.194.233.x - Login failed for user charly
| 2013/02/27_05:36:39 - 178.194.233.x - Login failed for user  charly
| 2013/02/27_05:36:58 - 178.194.233.x - Login failed for user charly
charly, es-tu là ?

| 2013/03/08_11:42:16 - 194.199.251.x - Login failed for user admin-shaarli
Non.
| 2013/03/08_11:42:30 - 194.199.251.x - Login failed for user admin-shaarli
Non.
| 2013/03/08_11:43:05 - 194.199.251.x - Login failed for user admin-shaarli
Toujours non.

| 2013/04/17_23:03:30 - 82.247.178.x - Login failed for user Pas de redirrection automatique vers https ?
Pas encore de https sur sebsauvage.net, désolé  :-)   (Je ferai peut-être ça un de ces jours vu que je vais changer de serveur.)

| 2013/04/20_00:32:25 - 86.220.203.x - Login failed for user protected against brute force
| 2013/04/20_00:32:53 - 86.220.203.x - Login failed for user dalahi
| 2013/04/20_00:33:16 - 86.220.203.x - Login failed for user titi is not there
| 2013/04/20_00:33:40 - 86.220.203.x - Login failed for user Otto
| 2013/04/20_00:33:40 - 86.220.203.x - IP address banned from login
Je confirme, ça marche. :o)

| 2013/06/07_21:16:08 - 83.202.178.x - Login failed for user -- olol apprenti hackerz coucou seb^^
:-)

Et enfin, un botnet utilisant de multiples adresses IP semble essayer de se connecter tous les jours (avec un user vide, ça ne risque pas de marcher). Il ne fait que quelques essais par jour, et utilise différentes adresses IP. Exemple pour une IP:

| 2013/07/26_10:48:39 - 142.4.213.x - Login failed for user
| 2013/07/26_11:14:07 - 142.4.213.x - Login failed for user
| 2013/07/26_11:23:52 - 142.4.213.x - Login failed for user
| 2013/07/26_12:25:16 - 142.4.213.x - Login failed for user
| 2013/07/26_12:25:16 - 142.4.213.x - IP address banned from login
| 2013/07/26_15:23:26 - 142.4.213.x - Ban lifted.
| 2013/07/27_22:04:05 - 142.4.213.x - Login failed for user
| 2013/07/27_23:04:56 - 142.4.213.x - Login failed for user
| 2013/07/28_21:59:48 - 142.4.213.x - Login failed for user
| 2013/07/28_23:00:44 - 142.4.213.x - Login failed for user
| 2013/07/28_23:00:44 - 142.4.213.x - IP address banned from login
| 2013/07/31_21:40:02 - 142.4.213.x - Ban lifted.
| 2013/07/31_21:40:03 - 142.4.213.x - Login failed for user
| 2013/07/31_22:44:41 - 142.4.213.x - Login failed for user
| 2013/08/01_12:01:16 - 142.4.213.x - Login failed for user
| 2013/08/01_13:08:37 - 142.4.213.x - Login failed for user
| 2013/08/01_13:08:37 - 142.4.213.x - IP address banned from login

Quel acharnement !
Et cette pattern se reproduit pour plusieurs adresses IP différentes, qui changent au cours du temps:

| 2013/07/12_15:12:54 - 94.23.234.x - Login failed for user
| 2013/07/12_16:17:41 - 94.23.234.x - Login failed for user
| 2013/07/17_22:31:28 - 94.23.234.x - Login failed for user
| 2013/07/17_23:34:40 - 94.23.234.x - Login failed for user
| 2013/07/17_23:34:40 - 94.23.234.x - IP address banned from login
| 2013/07/18_21:28:45 - 94.23.234.x - Ban lifted.
| 2013/07/23_20:16:23 - 94.23.234.x - Login failed for user
| 2013/07/23_21:16:13 - 94.23.234.x - Login failed for user
| 2013/07/26_17:53:30 - 94.23.234.x - Login failed for user
| 2013/07/26_18:53:40 - 94.23.234.x - Login failed for user
| 2013/07/26_18:53:40 - 94.23.234.x - IP address banned from login
| 2013/07/27_12:41:48 - 94.23.234.x - Ban lifted.
| 2013/07/28_04:06:10 - 94.23.234.x - Login failed for user
| 2013/07/28_05:06:55 - 94.23.234.x - Login failed for user
| 2013/07/28_18:32:06 - 94.23.234.x - Login failed for user
| 2013/07/28_19:32:57 - 94.23.234.x - Login failed for user
| 2013/07/28_19:32:57 - 94.23.234.x - IP address banned from login
| 2013/07/28_22:22:59 - 94.23.234.x - Ban lifted.

C'est limite flippant.
Donc, je vous recommande très fortement de mettre, dans le *MOINDRE* formulaires de login un système de bannissement (que ce soit fail2ban sous Linux, ou une petite lib maison en php comme j'ai fait pour Shaarli.).

Voici un bout de code adapté de Shaarli qui s'en occupe. Il est assez facile à utiliser (3 petites fonctions): http://sebsauvage.net/paste/?36dbd6c6be607e0c#M5uR8ixXo5rXBpXx32gOATLraHPffhBJEeqiDl1dMhs=
Instructions d'utilisation:
 • Faites un require_once de ce script.
 • à l'endroit où vous testez la validité du mot de passe:
     • Si ban_canLogin()==false, l'utilisateur est banni. Ne testez même pas le mot de passe: Rejetez l'utilisateur.
     • Si ban_canLogin()==true, vérifiez le mot de passe.
           • Si le mot de passe est ok, appelez ban_loginOk(), sinon appelez ban_loginFailed()
La lib s'occupe de compter le nombre d'échecs et de gérer la durée de bannissement (bannissement/levée de ban).
Cette lib créé un sous-répertoire "data" qui contient les données de bannissement (ipbans.php) et un log de connexion (log.txt).

Pour fail2ban, j'ai fait un tuto là: http://www.commentcamarche.net/faq/18225-utiliser-fail2ban-pour-proteger-votre-application-web

Un hacker a eu par hasard accès au backoffice de la société BitTorrent, avec accès à *TOUT*: Dépôt Git (avec droits complets), accès aux DNS, aux documents internes.  Le tout accessible sans mot de passe.
Il a donc prévenu la société qui l'a remercié et promis une récompense... qui n'est pas venue. Quand il leur a rappelé, il s'est fait jeter.
Pas très sympa... ou alors il ne fallait rien promettre.
(Le hacker n'a gardé aucun document: Il publie juste les copies d'écran pour prouver.)

Je ne sais pas, mais un hacker qui a évité que votre société se retrouve COMPLÈTEMENT À POIL sur internet (documents internes (y compris financiers), code source, mots de passe, config DNS...) ne mérite pas mieux qu'un simple «merci» ?

Je m'y attendais un peu: les malwares commencent utiliser l'Unicode pour masquer les noms de fichiers.

D'abord avec un fichier hosts leurre dont le "o" n'est pas un "o" latin mais un caractère cyrillique. Ce fichier leurre ne contient aucune entrée malveillante. Donc à l'inspection, l'utilisateur ne verra rien d'anormal. Le vrai fichier hosts reste caché, contenant les domaines détournés.

Ensuite, plus subtile, en utilisant le caractères Unicode qui inverse l'écriture. Par exemple en insérant ce caractère après "pic" dans "picgpj.exe", le fichier apparaît comme "picexe.jpg", mais il a bien l'extension .exe et s'exécutera si on double-clic dessus. Diabolique.

Il fut une époque où le même genre de magouille était possible dans les URL, mais désormais les navigateurs affichent (généralement) les URL encodées en PunnyCode pour les différencier. Exemple:  Voyez-vous des différences entre ces URLs ?
http://cοmmentcamarche.net/
http://cѻmmentcamarche.net/
http://commentcamarche.net/
http://c੦mmentcamarche.net/
http://c౦mmentcamarche.net/
Elles sont toutes différentes, mais une seule mène au vrai site de commentcamarche. Les autres domaines n'existent pas, mais rien n'empêcherait quelqu'un de les acheter et de mettre de fausses pages de login commentcamarche.

Certes il y a https://canary.pw/ (cf.http://sebsauvage.net/links/?Jy6gWg) mais n'oublions pas l'excellent "Google Dorks" qui permet également de trouver des choses effarantes qui traînent sur le net, simplement avec quelques requêtes Google bien placées.

Faites gaffe aux fausses mise à jour Flash (et utilisez WOT !)

Uho... OVH semble voir été pénétré par des pirates qui ont eu accès au backoffice.
EDIT: les explications d'OVH: http://travaux.ovh.net/?do=details&id=8998

Je me disais bien qu'il avait forcément du Stéphane Bortzmeyer derrière un rapport de ce genre :-)

La statistique du jour qui fait rigoler: Vous avez plus de chances de choper un virus en surfant sur des sites religieux qu'en surfant sur des sites porno.  LOL.

Voici une liste d'outils sécurité pour Windows. /!\ Attention: ils ne sont généralement pas destinés à tous les publics et sont souvent ciblés (par exemple AdwCleaner qui cible certaines spywares/PUP coriaces).
Visiblement la plupart de ces outils fonctionnent hors-ligne: Il peut donc être utile de les embarquer sur clé USB pour nettoyer des machines.

Gni ? L'équipe VLC aurait menacé légalement Secunia ? (Secunia avait informé VideoLan que le patch de la 2.0.5 ne suffisait pas à combler une faille de sécurité.)
Et la réponse de VideoLan: http://www.jbkempf.com/blog/post/2013/More-lies-from-Secunia

Comme d'habitude, McAfee SiteAdvisor au meilleur de sa forme.
(avant, ils bloquaient aussi Commentcamarche et Malekal. Duh.)
McAfee lui-même n'utilise plus McAfee.

Good. Il ne faut pas que ceux qui mettent en lumière les failles de sécurité soient condamnés, sinon *personne* ne sera en sécurité.

Cet outils en ligne est une sorte d'unpacker générique qui peut travailler sur javascript, HTML, PDF et captures réseau pcap, dans le but de trouver du code potentiellement malveillant. L'outils repère les <script, eval() et autres et vous l'affiche sous forme décompressée/dé-base64isé/dé-urlencodé.
Utile pour des investigations sécurité.
Les sources de l'outil sont là: https://code.google.com/p/jsunpack-n/

CryptoCat a utilisé pendant 347 jours un chiffrement beaucoup trop faible.

OMG.  Non pitié, c'est juste pas possible de laisser ce genre de faille en 2013 ! C'est quand même l'un des grands classiques.

Effectivement, si c'est juste pour de la consommation "passive", TOR convient très bien.
Quant à être "safe" avec SSL, c'est tout relatif. Se pose toujours le problème de vérifier la signature des certificats: Faire confiance aux autorités de certification ? L'expérience montre que ce n'est pas fiable.
Se contenter des certificats auto-signés ? Mais dans ce cas, comment vérifier que le premier certificat reçu est valide et que ce n'est pas un MITM ? (par exemple avec un détournement DNS).
Il n'y a à l'heure actuelle encore pas de solution évidente.

Wow... pensez à mettre à jour Firefox. La version 22 corrige des failles de sécurité critiques permettant l'exécution de code arbitraire (gloups).
Allez dans "A propos de Firefox".
EDIT: La liste des changements: http://linuxfr.org/news/22-v-la-firefox