Cet article tente à lister les noms de domaines utilisés sur les appareils android afin de pouvoir identifier les services.
Google
auditrecording-pa.googleapis.com
Service utilisé par Google Play Service (src).
Il est conseillé de bloquer ce domaine.
geomobileservices-pa.googleapis.com
Service de géolocalisation de google. Même si vous configurez votre appareil afin de n'utiliser que le GPS/Galiléo, il va quand même émettre des requêtes régulières vers ce service.
Le bloquer est donc éssentiel par sécurité et n'empêchera pas les apps de (…)
VNU Net nous indique que, a la surprise generale, Internet Explorer (les dernieres versions 5.5 et 6) peut donner accès à tous les cookies présents sur le navigateur avec un simple script...
Je vous aurais bien mis un petit lien pour patcher vos navigateurs (y'en a qui bossent sous Windows), mais le site de Microsoft indique que :
"Why isn't there a patch available for this issue?
The person who discovered this vulnerability has chosen to handle it irresponsibly, and has deliberately made this issue public only a few days after reporting it to Microsoft. It is simply not possible to build, test and release a patch within this timeframe and still meet reasonable quality standards."
Ce qui peut se traduire par (Attention, traduction perso) :
"Pourquoi n'y a-t-il pas de mise à jour corrigeant ce problème ?
La personne qui a découvert cette vulnerabilité a choisi de se comporter de facon irresponsable, et ne l'a déliberemment rendue publique que quelques jours après l'avoir rapportée a Microsoft. Il est tout simplement impossible de développer, tester et rendre disponible une mise à jour dans un si court laps de temps, tout en maintenant une qualité raisonnable."
Après les bugs "off by one" & "zlib double free", l'équipe d'OpenSSH est en train de travailler à une nouvelle version qui la rendrait insensible à ce type de bug, grâce à une séparation des privilèges.
De l'avis des développeurs :
"Previously any corruption in the sshd could lead to an immediate remote root compromise if it happened before authentication, and to local root compromise if it happend after authentication. Privilege Separation will make such compromise very difficult if not impossible."
Le code est actuellement utilisable sur OpenBSD, mais le portage vers d'autre *nix ne sera pas difficile.
Source : OpenBSD journal
ISS, peu après avoir dévoilé le problème sur Apache, avait annoncé qu'ils travaillaient sur une faille d'un autre logiciel libre (en annonçant cette fois-ci que la démarche serait un peu différente !).
Encore Bind ? Sendmail ? Squid ?
Et bien non, OpenSSH... :-(
Les détails sur la faille ne sont pas encore connus mais on sait d'ors et déjà de la bouche de Théo de Raadt lui-même qu'elle sera exploitable à distance, sauf si la séparation de privilège récemment apparue est activée (« UsePrivilegeSeparation yes » dans sshd_config). Peu de distributions Linux proposent cette option pour le moment mais j'espère sincèrement qu'ils vont tous s'atteler pour que ce soit le cas avant la semaine prochaine, date fatidique à laquelle seront dévoilés les détails de l'exploit (et je pense qu'un exploit pas forcèment de Gobbles ne tardera pas à suivre...)
Plus de détails sur LinuxSecurity.com
Note d'un autre modérateur : voir sur debianplanet.org la source apt Debian pour avoir les paquets ssh et apache corrigés pour Woody, ainsi que Mozilla 1.0
Au menu, d'excellents articles sur le 'arithmetic overflow', que vous *devez*
connaître si vous voulez vous prétendre un programmeur un tant soit peu sérieux.
Je vous mets en lien quelques bugs courants qu'on a tous fait un jour et que vous ne devez plus jamais faire après lecture de ces excellents articles.
Voici une annonce qui explique ce qui s'est passé lors du piratage des serveurs Debian.org à partir de la première intrusion le 19 octobre.
Les machines : klecker, master, murphy et gluck ont finalement bien été rootkitées, c'est suckit qui a été installé, une description sommaire de ce rootkit est disponible dans l'annonce.
La première intrusion a été possible grâce à un mot de passe intercepté, et à un login avec un compte sans privilèges.
La conclusion actuelle est qu'il reste certainement une faille locale à découvrir.
Note du modérateur : Wichert Akkerman a tenu un compte-rendu au jour le jour sur cette question.
Symantec a découvert [1] ce week-end un nouveau ver destiné aux plate-formes Linux et UNIX. Il s'agit d'une nouvelle variante du virus Plupii découvert en novembre dernier [4].
Ce ver ne représente pas une énorme menace car il n'est que peu répandu. Mais comme il profite de 3 failles de sécurités différentes pour se propager, il faut y faire attention. Les 3 failles concernent (plus de détails dans l'article complet) :
1- XML-RPC for PHP Code Execution Vulnerability
2- AWStats Input Validation Vulnerability
3- WebHints Shell Command Injection Vulnerability
Le ver, une fois le système infecté, va ouvrir une trappe (ou porte dérobée) sur le port UDP 27015.
Des correctifs sont accessibles en ligne :
1- XML-RPC 1.1.1 est couvert [2]
2- AWStats 6.4 est couvert [3]
3- Il n'y aurait pas encore de patch disponible pour Webhints
Mettez à jour vos systèmes, si ce n'est pas déjà fait.
Tout est dans le titre.
Il faut tout de même précisé qu'il existe des correctifs que les administrateurs réseaux connaissent sûrement...
Note du modérateur: Encore un article pour l'internaute moyen qui va lui faire prendre peur :)
La NSA (National Security Agency) conjoitement avec le SCC (Secure Computing Corporation) ont mis au point des systèmes de sécurité dans le LOCK system; puis les ont portés avec l'aide de l'Université d'Utah dans le noyau Linux.
Ce système permet virtuellement de tout sécuriser sous Linux, de la mémoire à la couche réseau.
On peut bien sur lire les sources de tous les patchs.
Mais bon étant un peu paranoïaque, ne peut-on pas se demander si la NSA ne tenterait pas de nous refaire le coup de la NSA_KEY sous Windows (je sais qu'on peut lire les sources mais bon qui va auditer tous ces patch de maniere neutre)
PS: Attention la NSA décline toute responsabilité sur leur patch.
Selon le véritable découvreur (Renaud Deraison) de la backdoor des modems ADSL d'Alcatel, il serait impossible de pénétrer le modem de l'extérieur du réseau. Il faudrait avoir déjà un accès au PC relié au modem via un cheval de Troyes ou autre.
La découverte date de l'année 2000, le sieur Tsutomu Shimomura, spécialiste de la médiatisation de ses actes, aurait donc un rôle plutôt faible dans cette affaire.
On apprend que l'industrie du disque freine des quatres fers pour la publication des résultats de recherche sur la protection des fichiers musicaux mis au point par la SDMI. Du coup l'équipe de chercheurs de Princeton porte l'affaire en justice pour avoir la liberté de publier ces résultats de recherche.
Bonjour tout le monde,
Je cherche une formation orientée Sécurité sous Linux. Google ne m'aide pas trop. Sauriez-vous m'en recommander qui valent le coup ?
Durée de l'ordre d'une semaine. Peu importe le budget, c'est l'employeur qui paye :)
Merci par avance.
D'après un éditorial sur le site de Microsoft, il est temps de se lancer dans la chasse à «l'anarchie de l'information». Monsieur Culp (responsable du 'Security Response center') explique dans son petit billet qu'il n'y aurait pas de vers et de virus s'il n'y avait pas cette bande d'anarchistes irrésponsables qui trouvent les bugs et les publient.
Moi je suis d'accord avec lui, et je pense que toute personne faisant un rapport de bug devrait être sévèrement punie par la loi. Non mais franchement...
Liste
Health check d'un service web ou de l'IOT (camera, etc)
camera : ${alignr}${execp curl --connect-timeout 5 --user-agent "Conky HealthCheck" -k -s http://192.168.42.42 >/dev/null 2>/dev/null && echo '${color green}ONLINE${color}' || echo '${color red}OFFLINE${color}' }
Remplacez http://192.168.42.42 par l'adresse de la WEBUI de votre caméra. Certaines caméra utilisent https à la place d'http (il n'y a pas vraiment de différence ici mais il faut l'indiquer dans l'URL)
Health check d'un service web à travers Tor
Pratique pour vérifier la présence en (…)
LinuxSecurity décrit un trou de sécurité dans le loop device encrypté de Linux.
A cause de cela, un attaquant peut modifier le contenu du device encrypté sans être détecté.
Un texte est proposé pour rêgler ce problème en autentifiant le device.
NdR: C'est aussi un bon moyen de mettre le nez dans le cryptage, des pointeurs intéressants sont donnés.