Affichage des articles dont le libellé est ec2. Afficher tous les articles
Affichage des articles dont le libellé est ec2. Afficher tous les articles

mardi 17 janvier 2012

Hacking : Google et Bing comme outils de 1er rang

Il y a quelques semaines, j'évoquais la notion de cyber-arsenal, d'un ton presque badin. Aujourd'hui, c'est un peu plus sérieusement que j'y reviens puisque un article paru hier sur Infosec Island, (re)met sur le devant de la scène des travaux de recherche consistants mais aussi inquiétants sur la puissance du Google Hacking dans le cadre d'une utilisation malveillante.

Tout d'abord, un mot sur ce dont il s'agit : le Google hacking est une technique qui utilise les fonctions étendues des moteurs de recherche, au premier rang desquels Google et dorénavant Bing. Cette technique donne accès à une incroyable mine dans laquelle on trouverait  en même temps de l'or autant que du pétrole ou des métaux rares ! L'analogie de cette fabuleuse mine avec l'information me parait judicieuse puisque cette technique est donnée comme de premier rang pour la plupart des exploits des Lulzsec et, surtout, des Anonymous. 

L'ensemble permet de collecter de l'information sur les vulnérabilités logicielles, des erreurs de programmation tout comme de trouver de nombreux documents, de simples fichiers texte par exemple, dans lesquels peuvent se trouver des informations sensibles qui ne devraient pas être (aussi facilement) accessibles : fichiers personnels (facilitant l'ingénierie sociale), documents d'entreprise à usage interne, éléments d'administration de réseaux, etc. 

Toutes ces informations sont utiles voire nécessaires pour élaborer puis mettre en œuvre un scénario d'attaque et, cerise sur le gâteau, le Google hacking permet également de découvrir d'innombrables mots de passe facilitant largement les attaques. L'irresponsabilité de nombreux internautes mais aussi d'entreprises peut ainsi être qualifiée de pousse-au-crime, le B-A-BA n'étant même pas respecté.

La présentation faite à Miami dans le cadre de Hacker Halted  en octobre 2011 est technique mais n'en demeure pas moins éloquente, d'autant plus que Francis Brown a élaboré un outil permettant l'automatisation des recherches et facilitant l'interprétation des résultats. Parmi leurs cibles, les failles embarquées par Flash pour des pénétrations malveillantes et déconcertantes de facilité ainsi que la mise en lumière des faiblesses du cloud. Ses principaux opérateurs fournissent un service qui n'est, pour le moment, pas fiable en terme de protection de l'information : les accords contractuels précisent qu'ils ne sont pas responsables d'une quelconque fuite d'information ni de perte d'intégrité des données ! Un comble pour un service donné comme la révolution informationnelle actuelle au sein des entreprises alors qu'il s'agit, une fois de plus, de la confirmation la plus élémentaire de prudence recommandée par ce blog et bien d'autres.

La présentation de Francis Brown démontre particulièrement la facilité qu'il y a de récupérer des informations dans "le nuage", en particulier sur l'EC2 d'Amazon qui est l'une des plate-formes les plus utilisées et qui a déjà connu de sérieux problèmes l'année dernière. Il est donc recommandé de ne pas stocker, pour le moment, de données sensibles dans le cloud. Tout comme il pourrait être "amusant" pour un RSSI, si ce n'est déjà fait, de faire passer son système d'information au travers des fourches caudines du Google hacking !

lundi 2 mai 2011

Panne du cloud d'Amazon : explications et transparence ?

Le 21 avril 2011, le Cloud connaissait probablement SON incident technique et historique le plus sérieux jusqu'à lors. La plateforme EC2 d'Amazon (Elastic Compute Cloud - l'offre de service "en nuage" d'Amazone) subissait une interruption de service de plusieurs heures.  Puis de sérieux aléas techniques jusqu'au 25 avril. Ce qui représente un préjudice financier non-négligeable puisque ses clients à l'est des USA ont été touchés,  clients d'envergure nationale et parfois internationale, qui offrent certains services web via EC2 (Quorra, Redit, Foursquare).

Pour autant, on peut s'interroger sur l'explication apportée : l'infrastructure de stockage des données repose sur ce qui s'appelle l'EBS (Elastic Block Store). Ce système permet de se créer une instance de travail sur un ou plusieurs volumes (disques). La solution est donnée comme novatrice et très sûre (snapshot personnalisable) : la preuve ! (je sais elle était facile :)

L'explication donnée est qu'une opération de maintenance a mal tourné : l'un des opérateurs (?) a détourné le trafic de l'une des sections géographiques (le Nord de la Virginie en l'occurrence) du réseau primaire de l'EBS vers un réseau de secours doté de moindres de capacités de traitement des flux de données (un routeur moins performant en fait). Et l'ensemble du réseau Est des USA de l'EC2  a subi de grandes perturbations avant que l'origine de la panne ne soit identifiée et résolue.

L'étonnement est grand de s'apercevoir que ce type de routage, d'une importance opérationnelle non-négligeable, ne dispose pas de garde-fous via l'IHM comme des messages d'avertissement voire des autorisations spécifiques de validation. C'est ce point qui m'intrigue et me fait planer en tête le fameux "1% de doute". Ou alors les concepteurs système sont gravement incompétents !

Quoiqu'il en soit, Amazon dédommagera ses clients lésés et aura eu le mérite de communiquer hier dans le détail (en anglais), avec une transparence quasi-didactique. Encore heureux cependant que l'on ait cette fois-ci eu affaire à une erreur humaine,  pas à une malveillance ! Et de cela, je suis sûr à 100% !