Une fois encore un groupe de cyber-espionnage Russe a attiré l’attention des médias en exploitant une vulnérabilité Zero-Day, contenue dans les OS Windows.

Grâce à l’exploitation de cette faille, ils ont pu espionner l’OTAN (Organisation du traité de l’Atlantique Nord), les agences gouvernementales ukrainienne et polonaise, ainsi que des industries européennes.

Les chercheurs de chez iSight Partners ont découvert cette vulnérabilité Zero-Day (CVE-2014-4114). Elle touche toutes les versions de Windows, aussi bien client que serveur, depuis Windows Vista et Windows Server 2008.

Qu’est-ce que cette faille Zero-Day ?

Référencée sous CVE-2014-4114, on apprend dans un rapport que cette vulnérabilité est contenue dans le gestionnaire OLE dans Windows. Ceci permet d’autoriser un hacker à exécuter du code arbitraire à distance.

iSight précise également que : “La vulnérabilité existe parce que Windows autorise le gestionnaire OLE à télécharger et exécuter des fichiers INF.” Ce fichier INF, fourni par le hacker pourra contenir des commandes à exécuter par le gestionnaire OLE, ce dernier ne vérifiant pas s’il s’agit d’une source de confiance ou non.

Cette campagne d’espionnage n’est pas nouvelle ! Ce groupe de hackers russe nommé “Sandworm Team” travaille probablement pour le gouvernement depuis au moins 2009, d’après la société iSight.

Microsoft va publier un correctif !

Microsoft est au courant de cette vulnérabilité et va mettre à disposition un correctif dans son prochain Patch Tuesday. D’ailleurs, le bulletin de sécurité est MS14-060.

Source

Anonabox est un boitier low cost qui vous permet de rester dans l’anonymat sur internet, de manière à protéger votre vie privée.

Équipé de deux interfaces Ethernet et d’une interface Wi-Fi, tout ce qui passera par l’intermédiaire de ce boitier sera relayé au travers du réseau Tor. De plus, cela est automatique et totalement transparent pour l’utilisateur, il n’est pas nécessaire d’installer Tor sur votre machine. L’Anonabox se charge de tout !

Grâce à cette manière de naviguer, on ne peut pas savoir où vous êtes, ni ce que vous faites grâce au chiffrement des communications de Tor.

Cette box a un intérêt particulier également dans les pays où internet est censuré, puisqu’elle permettra très certainement de contourner la censure imposée.

Léger et compact, vous pourrez emporter ce boitier partout avec vous,  il suffit à chaque fois de passer par son intermédiaire pour accéder à internet. Bien sûr, le boitier doit lui-même être connecté à internet, il sert d’intermédiaire entre vous et votre box (par exemple).

Une campagne pour Anonabox est lancée sur Kickstarter, afin de récolter des fonds pour le lancement de ce boitier qui ne vous veut que du bien. Les concepteurs cherchent à récolter 7500 dollars pour commencer la production du produit, qui quant à lui coûtera 45 dollars.

Après 2 jours de campagne, 150 000 dollars sont déjà atteints ce qui permettra largement de lancer la production de l’Anonabox.

I. Présentation

Dans ce tutoriel, nous allons voir une astuce qui permet de calculer la vitesse de lecture d’un disque dur, sous Linux et plus précisément sous Debian dans mon cas. Pour cela, nous allons nous appuyer sur fdisk pour lister les disques durs, et hdparm pour le calcul des performances.

II. Procédure avec hdparm

Commençons par lister les disques durs présents sur la machine grâce à la commande suivante :

fdisk -l | grep "Disque"

On remarque la présence de deux disques : sda et sdb. Quant à md0 et md1 il s’agit de grappes RAID logicielles présentent sur la machine.

Désormais, pour calculer la vitesse de lecture nous utiliserons deux options avec la commande hdparm :

• “-t” pour calculer la vitesse de lecture depuis le cache
• “-T” pour calculer la vitesse de lecture en accès direct sur le disque dur

Ce qui nous donnera la commande suivante (voir les exemples sur la copie d’écran pour sda, sdb et md0) :

hdparm -t -T /dev/sda

La ligne “Timing cached reads” est le résultat de l’option “-t” alors que la ligne “Timing buffered disk reads” correspond à l’option “-T“. On peut voir des vitesses de lecture d’environ 50 Mo/s et de 65 Mo/s sur chacun de mes deux disques, qui sont en fait des disques durs virtuels stockés sur un disque dur physique 5200 tr/min.

Pour information, sachez que l’outil “dd” qui est généralement préinstallé sur Linux, permet d’effectuer également des tests d’écriture au niveau du disque dur. Par exemple, comme test on pourra faire :

dd bs=1M count=256 if=/dev/zero of=test

Alors s’il y a bien un titre qui est très galvaudé de nos jours, c’est bien celui de « Chef de Projet » !

Ce titre est mis à toutes les sauces et pourtant…on rencontre souvent des « Chefs de Projets » qui ne font leur travail qu’à moitié en pensant que seul le respect du planning compte et que l’état de l’art consiste à presser (stresser) les différents acteurs afin que ce derniers respectent les délais qui ont été convenus. On jugera alors essentiellement les résultats par rapport aux objectifs du seul planning en mettant de côté les véritables « bonnes pratiques » que l’on est en droit d’attendre…

Nous parlerons ici de « projets » visant l’évolution du système d’information, bien entendu.

Je suis un D.S.I, je suis donc responsable d’un certain nombre de « projets », rôle qui consiste essentiellement à :

•  Analyser une demande émanant d’un « métier » de l’entreprise,
•  Proposer une solution pour répondre à cette demande,
•  Développer et/ou déployer cette solution,
•  Maintenir cette solution dans le temps.

Décrit comme cela, c’est tout bête…mais quand on commence à rentrer dans les détails, c’est là que cela se complique… Exemples :

•  La demande ne correspond t-elle à un réel besoin, validé par l’équipe dirigeante ?
•  La solution envisagée est-elle « acceptable » par l’entreprise, en terme de délais, en terme de coûts…etc… ?
•  Le développement (ou le déploiement) peut-il être effectué en interne ?
•  Le projet ne nécessite t-il pas la refonte ou la remise en question d’une autre application ?
•  La solution proposée est-elle pérenne ?
•  La solution n’est-elle pas trop chère à maintenir dans la durée ?

…etc…

Des questions comme celles ci-dessus, on peut s’en poser plus d’une centaine pour chaque projet que l’on adresse et ce, quelque soit sa taille…mais ce n’est peut-être pas comme cela qu’il faut procéder car ce serait alors un processus trop long, trop coûteux et pas vraiment « efficace » !

C’est là qu’entre en jeu le Chef de Projet qui, à partir de constats simples, doit rapidement fournir une réponse au « métier » (qui par définition demande des choses pour la veille…) car il serait illusoire de penser qu’ils vont attendre plusieurs semaines, voire plusieurs mois pour obtenir une réponse sur la faisabilité dudit « Projet ». Et si vraiment vous en arrivez-là alors ne vous étonnez pas de voir le « métier » se tourner vers un prestataire externe en vue d’acheter un produit sur étagère ou en mode SaaS, produit qui s’avérera au fil du temps cher à intégrer et cher à maintenir, le tout en apportant un « zéro » pointé au savoir-faire de votre entreprise…

Vous l’avez donc bien compris, le Chef de Projet se doit être un expert du système d’information et se doit connaître le métier (ou la partie du métier concernée) de son entreprise sur le bout des doigts.

Au sein de mon équipe, il y a plus de Chefs de Projets que de Développeurs, ce qui s’explique tout simplement par le fait que le développement d’une application (au sens codage du terme) n’est qu’une partie du projet et parfois, c’est la plus « petite »…

Dans notre entreprise (taille intermédiaire : 400 salariés), on pourrait résumer le rôle du Chef de Projet comme suit :

• Il analyse la demande en relation directe avec le « métier », il n’hésite pas à aller sur le terrain pour mieux comprendre,
• Il rédige cette analyse (une page maxi., au delà les gens ne lisent plus…) et il fait valider cette analyse par les demandeurs,
• Une fois l’analyse validée, il propose (rédige) une solution, là aussi une page maxi.,
• Il propose ensuite cette solution à ses pairs (autres Chefs de Projets) et au D.S.I (c’est moi!),
• Si acceptation du projet, il fait valider cette proposition par les demandeurs (le métier),
• Il assiste le (ou les Développeurs) dans la réalisation,
• Il teste les développements réalisés,
• Il fait tester la réalisation par les demandeurs,
• Il prononce la recette,
• Il définit les méthodes et moyens à mettre en place pour superviser cette nouvelle application ou cette évolution, si cela est nécessaire,
• Il écrit la documentation nécessaire au support,
• Il écrit la documentation technique nécessaire,
• Il met en « production » (déploiement la solution), en relation avec le « métier ».

Vous avez bien lu, il y a 13 étapes… Dans les plus grandes organisations, le chef de projets prend en charge beaucoup plus d’étapes encore, telles que : la conduite du changement, la formation, les manuels utilisateurs, la sécurité, la conformité, le respect des libertés, etc… Cela ne veut pas dire que ces sujets ne sont pas abordés chez nous mais ils sont souvent pris en charge par le « métier » ou directement par le D.S.I et non gérés par le Chef de Projet « Informatique ».

Ces 13 étapes constituent pour moi le « service minimum », quelque soit la taille de l’entreprise concernée. Faire une impasse sur une de ces étapes représenterait un maillon faible pour le projet concerné.

Attention toutefois à ne pas tomber dans l’excès, toute demande d’évolution du S.I n’est pas forcément à traiter en mode « projet » ! Et c’est là, peut-être, que l’on peut faire la différence entre une « bonne » D.S.I, à l’écoute du « métier », à l’écoute du marché (le fameux « Time to Market » qui signifie tout simplement : savoir réagir rapidement aux évolutions des marchés dans lesquels votre entreprise opère) et une D.S.I « Mamouth » où tout est compliqué et où rien ne peut se faire en moins de 6 mois et à moins de 100K€ (100.000€) voire plus !

Exemple : la modification d’une fonctionnalité, déjà existante et ,n’ayant aucun impact sur des données stockées dans une base, n’est pas à traiter en mode projet. A contrario, toute modification sur une donnée (longueur, type…etc…) ou tout ajout de données dans une base doivent forcément faire l’objet d’un « Projet », aussi petit soit-il, ne serait-ce que pour s’assurer que d’autres fonctionnalités ou d’autres applications ne seront pas affectées par cette modification.

En conclusion, l’objectif consiste à toujours répondre rapidement aux besoins du « métier » sans négliger la « consistance » de vos données et sans mettre en péril d’autres fonctionnalités de votre S.I. Facile à dire certes, mais pas toujours simple à faire ! Bon courage !

CyanogenMod, la très célèbre ROM alternative pour smartphones sous Android contiendrait un exploit Java dû à une mauvaise réutilisation d’un code.

Un expert en sécurité s’est aperçu que la ROM contenait un code Java vulnérable, qui, lorsqu’il est exploité permettrait une attaque de type Man-in-the-middle. Ainsi, une sécurité pourrait être contournée.

La vulnérabilité permet d’associer n’importe quel nom de domaine à un certificat SSL et, de le faire accepter comme domaine valide.

D’après cet expert, le bout de code vulnérable est présent dans de nombreux codes Open Source. En fait, ce sont les développeurs qui utilisent un exemple de code Java de validation des certificats SSL, simplement en effectuant un copier-coller. Certes, c’est pratique mais par contre s’il y a des bugs et des failles dans le composant, on ne s’en rend pas compte !

Visiblement, cette faille n’est pas méchante et devrait être rapidement corrigée. L’expert en sécurité affirme qu’il s’agit d’une erreur banale sur les dangers de la réutilisation de code.

En termes de réactivité, nous pouvons faire confiance à la communauté Cyanogen.

Source