I am very proud to be part of that research we published :
It was amazing to work with all these colleagues :-)
mardi 30 octobre 2018
Par Cedric Pernet le mardi 30 octobre 2018, 16:10
I am very proud to be part of that research we published :
It was amazing to work with all these colleagues :-)
mardi 11 mars 2014
Par Cedric Pernet le mardi 11 mars 2014, 14:09
Une interview de votre serviteur vient d'être publiée, à propos des "incident handlers" ou "incident responders" ... Ca se passe ici, et merci à Jérôme Saiz :-)
jeudi 12 décembre 2013
Par Cedric Pernet le jeudi 12 décembre 2013, 16:40
jeudi 3 octobre 2013
Par Cedric Pernet le jeudi 3 octobre 2013, 22:49
On entend souvent parler, lorsqu'est évoqué le sujet des attaques de type "APT", de "spear phishing".
Alors le spear phishing, c'est quoi ?
Dans un contexte général, le spear phishing consiste à cibler précisément une personne et lui envoyer un contenu e-mail personnalisé, pour maximiser les chances que cette personne ouvre le courriel et tombe dans le piège tendu par l'attaquant (généralement, une infection par malware).
Imaginez qu'une personne veuille prendre le contrôle de votre ordinateur. Elle sait que vous êtes relativement sensible à la sécurité informatique et que vous n'ouvrez pas n'importe quel e-mail. Par contre, vous êtes passionné de guitare et collectionneur. C'est en tout cas ce que dit votre profil Viadeo (partie "mes centres d'intérêts") et/ou votre profil Copains d'avant. En plus, vous avez indiqué que vous habitiez à Nogent sur Tartiflette, petite commune perdue quelque part en France.
Votre attaquant sait que vous n'ouvrirez jamais un mail générique de type "Livraison UPS", "Réduction de malade chez RueduCommerce" ou encore "On ne se connait pas mais tu es le droïde de ma vie je m'appelle Marvin écris-moi vite bisous".
Par contre, quelles sont honnêtement les chances que vous ouvriez un mail intitulé "Nouveau magasin de guitares vintage - ouverture imminente à Nogent sur Tartiflette" ? Pire, quelles sont les chances pour que vous l'ouvriez, s'il vient d'un de vos proches, et contient juste un message "t'as vu, y'a un nouveau magasin de grattes qui va ouvrir près de chez nous" accompagné d'un PDF ?
Je dirais que les probabilités sont assez hautes, largement plus en tout cas que pour un contenu générique. Evidemment, la pièce jointe ou le lien contiendra un malware, et ce sera le début de la fin pour votre ordinateur et peut-être votre compte bancaire, ou vos données sensibles.
Le spear phishing ciblant les particuliers est relativement rare pour le moment, d'autres méthodes de phishing plus traditionnelles continuant à être efficace et permettant de jouer sur l'effet de masse. Je pense à ces grosses campagnes de phishing de différentes banques que vous voyez passer régulièrement, qui continuent à bien fonctionner avec certains utilisateurs crédules.
Du point de vue de l'attaquant, le spear phishing nécessite un déploiement d'efforts non négligeables et surtout du temps, afin de bien cibler la victime. Des formes de ce que j'appellerais du "semi spear phishing" existent néanmoins. Pour poursuivre sur notre exemple précédent, on pourrait imaginer que vous soyiez inscrit sur un forum de collectionneurs de guitare. L'attaquant pourrait compromettre le forum, récupérer toute sa base de donnée, et par conséquent toutes les adresses e-mail des membres, puis envoyer un e-mail alléchant parlant de vente de guitares vintage à tout le monde. Le taux de clic sur sa pièce jointe infectée devrait grandement le satisfaire... Et vous feriez probablement partie des grands gagnants.
En entreprise, les choses sont différentes. Un mail vous parlant de guitare devrait naturellement éveiller votre suspicion, étant donné que vous ne recevez que des e-mails professionels (en théorie).
Le spear phishing en entreprise consiste donc à infecter un ou des employés en leur envoyant un contenu qui semble être professionel et cohérent. Le but de la manoeuvre, lors d'une attaque de type APT, est d'entrer dans l'entreprise. Peu importe l'employé infecté, à partir du moment où son poste sera compromis l'attaquant disposera de la capacité de rebondir de là pour compromettre d'autres machines.
RECOMMANDATIONS POUR LES EMPLOYES
En tant qu'employé, il est fortement recommandé de:
* Ne pas croire que la protection de l'entreprise (après tout, il y a deux anti-virus, des filtres pour les navigations Internet, des firewalls, des antispams etc.) va tout faire à la place de l'utilisateur, et qu'un virus ne peut pas arriver par mail. Les attaquants, même d'un faible niveau technique, sont tout à fait capables de contourner tout cela.
* Ne pas ouvrir de mail qui proviennent de personnes inconnues. Si le doute persiste et que le mail est déjà ouvert, veiller à ne pas ouvrir les pièces jointes contenues dans ce mails et ne pas cliquer sur un éventuel lien contenu dans ce mail.
* Ne surtout jamais répondre à aucun mail de ce genre (cela pourrait donner des informations sur le système d'information à l'attaquant, telles que l'antispam utilisé, l'anti-virus, la version du serveur de mail, etc.)
* Se maintenir sur le qui-vive. Un attaquant peut très bien faire croire qu'un e-mail provient d'un collègue de travail. En cas de doute, il convient de confirmer la légitimité de ce mail avec l'émetteur (par téléphone ou rencontre, pas par mail) avant d'ouvrir la ou les pièces jointes.
QUELS SONT LES MOYENS POUR LE SALARIE DE DETECTER UN E-MAIL DE SPEAR PHISHING ?
Même s'il semble venir d'une personne connue du destinataire, voici des éléments qui devraient inciter à la suspicion:
- L' utilisation de phrases/tournures inhabituelles de la part de l'émetteur.
- L'absence de signature de mail, alors que l'émetteur en ajoute toujours une.
- Le sujet de l'e-mail. Est-ce crédible de mailer quelqu'un pour le motif invoqué ?
- Le ressenti par rapport au contenu. Ce mail a-t-il été envoyé dans le seul but d'ouvrir une pièce jointe ou de cliquer sur un lien ?
Vous l'aurez compris, plus les attaquants en savent sur vous et vos collègues, plus ils auront de chances de créer un e-mail crédible et vous le faire ouvrir. Parmi les techniques "habituelles" utilisées par les attaquants lors d'APT, on peut citer les e-mails contenant des noms de projets en cours, des propositions de réunion, des demandes de consultation de documents, des informations sur des concurrents, des opportunités à saisir, etc.
En matière d'APT, le Spear Phishing constitue la méthode la plus utilisée actuellement par les attaquants pour compromettre certains postes de travail d'entreprises et pouvoir compromettre tout le réseau, avant de dérober de l'information sensible. Le spear phishing est utilisé dans 91% des APT (étude Trend Micro)
L'attaque par spear phishing est efficace, et facile à mettre en oeuvre. Pour les RSSI, il convient donc de sensibiliser régulièrement les employés sur ce risque, quitte à procéder de temps en temps à des simulations réelles.
Un employé sensibilisé est un maillon de moins pouvant constituer une infection initiale lors d'une APT. Cependant, plusieurs groupes de personnes extérieures à l'entreprise, qui n'ont aucune notion de sécurité informatique, viennent semer le doute dans l'esprit de ces employés sensibilisés: les marketeux, les commerciaux, les chasseurs de tête, les meneurs d'études, les statisticiens, etc.
Ces gens n'ont aucun scrupule à envoyer des spam par milliers, à destination de personnes qui ne leur ont rien demandé. Leurs e-mails n'usurpent pas l'identité d'autres employés, mais ils contiennent de quoi semer le doute dans l'esprit d'un utilisateur averti.
J'en prends pour exemple un e-mail, reçu par votre serviteur cette semaine sur son adresse e-mail professionnelle (j'en ai anonymisé certaines parties avec des x):
De : Rachel xxxxx survey@areyounet.com
Envoyé : mercredi 2 octobre 2013 10:43
À : Pernet, Cedric
Objet : Enquête sur l'équipement mobile des ingénieurs et techniciens sur le terrain
Bonjour,
Je mène actuellement une grande enquête au niveau national sur l'équipement mobile des ingénieurs et techniciens sur le terrain. Pour mener à bien cette opération, je travaille en partenariat avec xxxxx, acteur majeur sur le marché français.
Répondre au questionnaire vous prendra moins de 4 minutes.
Grâce à vos réponses nous pourrons faire un état des lieux de l'équipement mobile des entreprises et avoir une tendance des besoins et des investissements à venir.
Accéder au questionnaire
Je vous remercie par avance du temps que vous y consacrerez.
Bien cordialement,
Rachel xxxxxx
Etudes & Statistiques
Si vous souhaitez ne plus répondre à nos enquêtes, rendez-vous ici
Je dois bien avouer qu'à la lecture de cet e-mail, je me suis demandé si j'étais ciblé par une attaque. Le contexte semble idéal et propice: une personne inconnue, un contenu sans fautes d'orthographes, bien rédigé, qui me demande juste de cliquer sur un lien externe, pour aller en plus lui fournir des informations sur moi ou mon entreprise. Le seul hic, c'est que le contenu est générique et a dû être envoyé à de nombreuses personnes, ce qui ne cadre pas avec un spear phishing traditionnel.
J'ai néanmoins pris quelques minutes pour investiguer et vérifier la légitimité de cette campagne honteuse : "areyounet.com" est bien une entreprise déclarée au Registre du Commerce et des Sociétés, "spécialiste dans les solutions d'enquêtes en ligne et sur mobiles".
Les informations demandées dans leur questionnaire en ligne peuvent être utiles à un attaquant:
- Nombre de salariés de mon entreprise
- Secteur d'activité
- Quelle est ma fonction exacte au sein de l'entreprise ?
- Combien d'ingénieurs/techniciens sur le terrain ?
- etc.
Bref, ce qui m'énerve ici, outre le fait de recevoir ce genre de spam détestable sur ma boite mail professionnelle (il contient du tracking en plus) , est de me dire que cela sème la confusion dans l'esprit des utilisateurs et entretient l'idée qu'il est normal de recevoir des e-mails extérieurs et d'y répondre.
Comment voulez-vous, après cela, réussir à prévenir le spear phishing en entreprise ?
lundi 16 mai 2011
Par Cedric Pernet le lundi 16 mai 2011, 18:39
"Exposing the Lack of Privacy in File Hosting Services".
C'est sous ce titre que vient d'être publiée une étude ma foi bien intéressante sur le sujet des "hébergeurs de fichiers". Mais si, vous savez, les "rapidshare" et autres sites qui vous permettent de partager des gros fichiers avec vos amis, votre famille, mais aussi vos collègues de travail ?
Pour donner une définition rapide, il s'agit de sites qui vous proposent d'héberger (de façon continue ou temporaire) des fichiers volumineux afin de les partager. Le principe est simple : vous envoyez le fichier par le biais du site, qui vous retourne un lien unique qui pointe vers le fichier concerné. Du genre http://superserveurdepartagedefichiers.com/ddfeab3245ae34/
La confidentialité est censée être assurée par le fait que ce lien unique vers votre fichier n'est connu que de vous. Libre à vous de le transmettre aux collègues avec qui vous voulez le partager, ou de le mettre sur un forum/autre site s'il s'agit d'un document public que vous voulez distribuer en masse.
Seulement voilà, il existe différents niveaux de qualité pour ce type de site, et la majorité d'entre eux présentent diverses failles qui permettent à un tiers d'accéder aux documents que vous croyiez inatteignables.
Revenons donc à cette étude, qui est je crois la première sur le sujet, et qui porte sur 100 services de partage de fichier différents, dont je vous recommande chaudement la lecture.
J'en retiens :
* Etude de la confidentialité des données
- 12 services parmi les 100 contiennent des moteurs de recherche sur les données qu'ils hébergent. Ils ont été exclus de l'étude.
- Sur 88 services, il y en a 34 (soit 38,6%) qui génèrent un identifiant de façon séquentielle. Ainsi, il suffit de changer l'url d'un fichier pour en obtenir un autre. (exemple: http://vulnerable.com/9996, http://vulnerable.com/9997, etc.) Par contre, 14 de ces 34 services nécessitent quand même l'association avec le bon nom de fichier. (ex:http://site-o ne.com/9996/foo.pdf)
- Un robot développé par les chercheurs, fonctionnant sur ces services ne fournissant qu'une génération séquentielle d'url, a pu télécharger 310 735 fichiers uniques en 30 jours. Ces fichiers ont été recherchés (sur la base de leur nom) sur Bing : 54,16% n'étaient pas connus, et donc supposés privés. (Je ne lancerais pas de troll sur le choix du moteur de recherche...)
- Les fichiers réputés "privés" sont principalement des images (27 000 environ), puis des archives de type ZIP (13 000 environ), puis du PDF,Word,Excel,Powerpoint... ce qui tend à laisser penser que malgré un usage personnel important, le partage de documents professionnels est monnaie courante sur ce type de service.
- Les 54 services qui fournissent un identifiant "non séquentiel" sont très variables au niveau du nombre de caractères utilisés pour générer les liens. Ainsi, en brute-forçant des sites ne proposant qu'un lien constitué de 6 caractères numériques, les chercheurs ont trouvé 728 fichiers en 617 169 tentatives. D'autres services heureusement proposent des identifiants beaucoup plus robustes, constitués d'au moins 12 caractères alphanumériques. Je note au passage qu'on peut tranquillement faire du brute-force à partir de la même adresse IP, sur une durée de 5 jours, d'une même machine, pour obtenir des fichiers, sans être blacklisté. (encore une fois,ce n'est pas valable pour tous les services de partage de fichier, seulement pour les moins robustes)
* Vulnérabilités
13% des services utilisent le même soft, disponible publiquement, et présentant un certain nombre d'erreurs d'implémentation et de design.
* "Honey Files"
Les chercheurs ont créé un certain nombre de fichiers HTML,PDF, et DOC se connectant sur un serveur appartenant aux auteurs, permettant d'étudier les accès à ces fichiers. Ils ont ensuite été uploadés sur les services de partage de fichiers, quatre fois par jour. Ces fichiers avaient des titres évocateurs faisant référence à de la fraude "intéressante" : promesses de numéros de cartes bancaires, d'identifiants Paypal, etc.
- En un mois, 80 adresses IP différentes ont accédés à ces fichiers sur 7 services différents. La répartition géographique n'est pas inintéressante d'ailleurs... 50% d'adresses IP russes, 24% d'adresses IP ukrainiennes ...
- Sur les 7 services desquels des fichiers ont été téléchargés, 1 disposait d'une fonctionnalité de catalogue, 2 disposaient d'une option de recherche, les 4 restant ne disposant à priori d'aucun moyen de découverte par mot clef. A noter que l'un de ces services utilisait quand même une fonctionnalité de recherche, mais par le biais d'un tiers.
Je passe sur la partie contre-mesures de l'étude, moins passionnante ... Et tient également à signaler que je ne me suis pas relu ... Désolé donc pour les erreurs/fautes de ce post ;-)
vendredi 26 février 2010
Par Cedric Pernet le vendredi 26 février 2010, 12:45
Autant vous prévenir, si vous ne connaissez pas le fonctionnement de Twitter, vous pouvez éviter de lire ce billet... Ce warning étant écrit, je peux démarrer.
Il y a deux jours a été publié un billet en anglais sur l'excellent blog de Sucuri, qui fait partie des centaines de blogs de sécurité informatique que je lis régulièrement.
Pour résumer très rapidement, le chercheur nous indique qu'il est hébergé chez GoDaddy aux USA (l'un des plus gros ISP là-bas), qu'il n'a qu'un honeypot SSH derrière son port 22, et qu'il utilise un/des autres ports pour accéder à ses serveurs en SSH. Alors qu'il farfouillait en bon paranoïaque dans ses journaux de connexion, il découvre avec stupéfaction et horreur qu'une adresse IP inconnue a accédé à son honeypot en utilisant le véritable mot de passe qu'il utilise pour son vrai serveur SSH. Pire, deux mots de passe sont utilisés : ses deux derniers mots de passe.
Les pensées du chercheur à ce moment précis doivent être à peu près : "Panique à bord, mon dieu mon dieu on m'a rooté je suis foutu, les carottes sont /quit (elle est de moi, je la revendique celle-là!), c'est la fin du monde !" (hello au passage à ericvo)
Après quelques recherches, il se rend compte que l'adresse IP attaquante provient de chez GoDaddy, et reçoit à peu près au même moment un mail de GoDaddy l'informant que son serveur web est peut-être infecté par du malware. Et là, en toute quiétude, l'ISP lui dit que les mots de passe dont il dispose dans ses fichiers n'est plus bon et qu'il a besoin de l'accès root (administrateur) pour vérifier ça, sous peine de suspension de compte.
Plutôt inquiétant de voir que (propos de l'auteur)
L'histoire ne se finit pas ici. Le chercheur a eu un contact par téléphone avec le CSO (Chief Security Officer) de GoDaddy, qui lui a expliqué un certain nombre de choses :
Au final, pas de malware, l'activité suspecte était dûe au honeypot du chercheur, et il a pu s'expliquer et régler le problème avec GoDaddy sans avoir à communiquer son accès root. L'ISP s'est excusé, et informera ce user de toute prochaine intervention *avant* de faire quoi que ce soit.
Je n'apporterais que très peu de commentaires à propos de ce "fait divers" de sécu :
Mais ce n'est pas la fin de l'histoire, et le plus amusant reste à venir. Car ce chercheur n'a pas été mis en contact avec un CSO tout puissant suite à un contact avec le support : il a été contacté directement par le CSO. Pourquoi ? Comment ? La réponse est présente sur Twitter.
Le lendemain, je lisais l'update sur le blog. Il est dit : "it reached the ears of the GoDaddy people".
En fait, GoDaddy, comme beaucoup d'entreprises conscientes de la nécessité de surveiller leur image, exerce une surveillance sur Twitter. Et le post blog de sucuri, qui a été largement retweeté, a été rapidement détecté par GoDaddy, qui ont décidé de contacter l'auteur du blog. Je faisais partie de ces gens qui ont retweeté l'article le jour même, et j'ai eu la surprise le lendemain de découvrir un message sur Twitter qui m'était adressé et qui venait du compte officiel Twitter de GoDaddy, je cite:
-- @cedricpernet Just FYI, the author posted an update to his blog. It clarifies a lot. We hope you'll read that too. http://fwd4.me/GxT --
Je me suis empressé de faire quelques recherches, et me suis rendu compte que l'article initial de sucuri avait été retweeté par 130 autres personnes, et que le même message que j'avais reçu avait été tweeté à ces 130 personnes.
Du beau boulot, en termes de communication. GoDaddy non seulement surveille les tweets qui parlent d'eux, mais en plus ils réagissent lorsqu'un incident d'image les impacte, et de façon plutôt pro et efficace. Les réactions ne se sont pas faites attendre sur Twitter : tout le monde a twitté le lien vers l'update, souvent avec un petit commentaire du genre "bravo GoDaddy pour la transparence" ...
Voilà un bel exemple de contre-attaque d'image basé sur un incident de sécurité informatique, ou comment renverser la vapeur et se faire mousser gratuitement sur une base initialement négative.
Chapeau bas, GoPapa ! :-)
Et enfin, je dédie ce post blog à un ami très GUMOristique, sans qui ma vie professionnelle ne serait pas ce qu'elle est :-p
lundi 7 septembre 2009
Par Cedric Pernet le lundi 7 septembre 2009, 18:26
Recently I attended the SANS GCIH (GIAC Certified Incident Handler) courses in London. I don't want to make too much advertise for it, it is not the goal of this post but anyway, it's a great course and I had a great time there.
Of course, when you're in a room full of other people learning about compromising computers, you expect strange things to happen on the wireless network.
And something strange happened to me during the second day of the course : my computer couldn't connect anymore to the network. I tried to figure out what was happening but couldn't find any problem.
The machine was an XP SP3, fully patched. I'm not using Windows usually (except at work), but it was better for the course. Anyway, I switched to an Ubuntu and had the same trouble : no connection.
Since it was the end of the day, I got back to my hotel and came back early the next morning, to try to fix the problem. I talked about it with someone from the SANS staff, Tomasz, and he told me he had noticed a strange behaviour from one machine, which was sending a hell of a weird trafic, almost taking all the bandwidth. The machine had quickly been blacklisted on the wireless network, according to its MAC address. And guess what ? The MAC address was my wifi card's one.
Well of course, as an incident handler, I immediately thought : hell, I've been compromised. After telling the SANS dudes I had not been running anything special on my machine and not knowing what was up, we decided to have a look at the trafic sent by my machine. It was sending packets on the network like crazy, but there were only two kind of packets : "BROWSER Election Requests", and "Local Master Announcement" ...
This was definitely not the behaviour of a malicious attacker or malware. For a moment I thought it was a hardware problem with my network card, but under Ubuntu there was no such behaviour.
Anyway, I ended the GCIH course using my Ubuntu, with an XP under VirtualBox.
I left the course on the saturday afternoon, after the capture the flag event (which was really great btw), but I told Tomasz that I would keep in touch, and would investigate the machine later on.
I didn't touch the machine for some weeks (you know this feeling, when you've always got something else to do and can't fight it...) and then I decided I would look at it quickly : I made a full dd of the Windows partition, and decided not to follow the usual forensics rules and just boot the machine. After all, it was mine, and I had a dd in case I would have time to do real forensics on it.
Together with my friend David Bizeul, who was interested in the case, I had put the machine on a hub with another machine, running a network sniffer. The results were the same than before : the machine started to send these crazy packets again, eating a good 25% of the bandwidth I had (10M).
A quick jump in command line, to see more about the activity, immediately proved something was definitely wrong :
All of my UDP ports (except the 256 first ones) were opened, by a unique process.
Now what was the process exactly ? Look here :
My machine was not infected by a malware. It was not compromised. You guessed it right, it was just an incompatibility problem between VMware Player and my hardware,which is from an Asus 1000H (eeepc).
The version I was using :
End of the story... I still wanted to blog about it because it could happen to a lot of other people using the same hardware, and to give a clear answer to my SANS friends about this machine, which had been a curiosity... I'm taking this occasion to say hi to the great people from the SANS : Tomasz Miklas, Terry Neal, Pieter Danhieux... And hi to Ben, and all the nice people I met in London :-)
See ya ! :-)
lundi 8 juin 2009
Par VFL le lundi 8 juin 2009, 13:00
Bonjour à tous,
Tout d'abord, merci à Cédric de me laisser quelques pages sur son blog.
Je travaille actuellement dans une structure CERT d'un établissement bancaire français. Nous nous occupons entre autres de réponse à incidents de sécurité informatique et de lutte contre la cybercriminalité. Dans le cadre de ma mission, j'ai eu l'occasion d'assister à l'édition 2009 du SSTIC.
Ceci est le compte-rendu de ma première participation à cette manifestation. L'impression générale que j'ai eue de cet évènement est très positive. L'ambiance était très bonne, et j'ai eu l'occasion de pouvoir échanger avec des gens venant d'industries différentes. J'ai notamment beaucoup apprécié le social event.
Evoluant d'habitude dans un environnement peu technique (en tout cas beaucoup moins que la plupart des participants de ce Symposium), je ne pense pas pouvoir faire aussi bien que d'autres blogueurs bien connus, à moins de reprendre le contenu des actes. Pour cette raison, la suite de cet article présentera les conférences qui m'ont le plus marqué au cours de l'édition 2009 du SSTIC.
Merci de votre indulgence et bonne lecture.
La conférence d'ouverture a été présentée par M. Pascal Andrei, directeur de la sûreté aérienne chez Airbus. Elle a été l'occasion de découvrir une vue métier sur la sécurité informatique dans un environnement aérien. Notamment, la différence entre la sécurité (safety) et la sûreté (security) a été évoquée. La sécurité concerne la conception d'appareils, le développement de composants. En résumé, il s'agit de s'assurer de la fiabilité des appareils, démarche en cours depuis plus de 30 ans chez Airbus. La Sûreté (security) est quand à elle plus récente. Elle distingue la sécurité physique (bombes, passagers clandestins, etc.) et la sécurité informatique. Cette dernière a été un sujet de préoccupation plus récent, qui à coïncidé avec l'entré de composants logiciels dans les systèmes embarqués ainsi que l'informatique de divertissement. Au passage, des connexions à Internet ont été mises à disposition dans l'A380. Les équipements connectés sont bien entendu isolés du reste de l'infrastructure critique. Cette conférence a aussi été l'occasion d'évoquer l'évolution des contraintes de sécurité informatique imposées aux compagnies aériennes en général et à Airbus en particulier. Ainsi, il n'y avait que peu de contraintes sur les appareils conçus avant l'A380. Puis des pentests ont étés mis en place, ainsi que la création d'un CERT interne, dont le but est de surveiller les vulnérabilités pouvant impacter l'infrastructure informatique. Il est aussi question de l'adoption de normes telles que ISO 27000. De manière générale, Les problématiques de sécurité semblent être prises très au sérieux chez Airbus.
Data tainting
Cette conférence, présentée par Florent Marceau du CERT LEXSI, a évoqué une technique d'automatisation d'analyse de code malveillant mettant en œuvre du data tainting. Le principe est de marquer et tracer les données manipulées par un code malveillant lors de son exécution sur une machine victime. Ce traçage s'applique également aux données chargées d'un serveur éventuellement contacté dans le cadre de l'attaque. On peut ainsi contourner les techniques de chiffrements employées par la plupart des malware modernes. En pratique, le code malveillant est soumis à une machine virtuelle pour être analysé. En moyenne, une analyse prend une dizaine de minutes (dans le cas où aucun système de détection de machine virtuelle n'est mis en œuvre par le code malveillant). LEXSI peut ainsi parvenir à analyser entre 2000 et 2500 binaires suspicieux par jour. Un autre challenge à l'analyse est les stimuli qui déclenchent l'activation d'actions malveillantes.
Projet WOMBAT
Symantec a ensuite présenté son projet WOMBAT. Le but est d'obtenir une meilleure compréhension des menaces qui pèsent sur Internet. L'implémentation de WOMBAT consiste en une multitude de senseurs qui ont 2 fonctionnalités principales: identifier les attaques connues dont ils sont la cible et identifier les nouvelles attaques. Les données ainsi collectées sont transmises à un serveur qui procède à l'analyse. Une fois qu'un chemin d'attaque est identifié, il est diffusé à toutes les sondes WOMBAT du réseau. La présentation était émaillée de nombreux graphes et données statistiques.
ACPI et routine de traitement SMI
La démonstration de l'exploitation de failles ACPI et SMI a été très visuelle. Nous avons vu M. Loïc Duflot de la DCSSI obtenir un accès root à une machine en débranchant et rebranchant plusieurs fois le câble d'alimentation de son laptop. Le but était de mettre en évidence deux types de failles. La faille ACPI qui permet à un attaquant de modifier les routines de gestion de la batterie en réécrivant les tables ACPI. La deuxième exploitation présentée était un accès à la routine SMI. L'attaque se produit par une compromission du BIOS.
Questions sur l'utilité de ISO 27001
Alexandre Fernandez-Toro de HSC a dressé un bilan de l'implémentation de la norme ISO 27001. ISO 27001 ne constitue pas un nouveau "nirvana" de la sécurité mais a eu le mérite d'établir un référentiel des bonnes pratiques de sécurité. Ce qui est certifié n'est pas un niveau de sécurité, mais un processus d'amélioration continue de la sécurité. Chercher la certification "pour la certification" n'est pas utile. Il est plus intéressant de voir ISO 27001 comme un modèle vers lequel tendre et de se faire certifier sur opportunité. Présentation intéressante et vivante.
Traçage des traitres en multimédia
Sujet d'actualité évoquant le watermarking (tatouage digital). Le but est d'identifier le ou les utilisateurs à l'origine de la dissémination de copies pirates d'un fichier multimédia. Un fichier multimédia est tatoué différemment pour chaque utilisateur. Le tatouage permet d'identifier quel utilisateur est à l'origine de la fuite. Dans le cas où plusieurs fraudeurs entrent en jeu, il est possible d'identifier les fraudeurs avec un certain degré de probabilité.
Le vol d'information n'existe pas
Il n'est pas reconnu juridiquement. En revanche, la divulgation peut faire l'objet de sanctions. Pour l'entreprise, il est possible de se protéger par le contrat de travail (obligation de loyauté), une politique de classification des documents, une charte utilisateur et une politique de gestion des tiers.
Pourquoi la sécurité est un échec
D'après Nicolas Ruff, la sécurité est un échec. La faute à de mauvaises décisions techniques et organisationnelles, des marchés captifs et un buzz non mérité sur certaines applis de sécurité. La présentation était conviviale et mettait en relief certaines opinions assez partagées dans le monde de la sécurité.
Macaron, une porte dérobée pour toutes les applications JavaEE
Une présentation d'Atos a démontré l'installation d'une backdoor dans une application J2EE via l'insertion d'un jar malveillant dans une Web Archive. Le but était de mettre en évidence un trou dans les procédures d'audit standard. Si la vérification du code est effectuée, il n'y a en général pas de vérification des binaires compilés. Cela met aussi le doigt le champ beaucoup plus large de la sécurité des applications J2EE en général.
Émanation compromettantes électromagnétiques des claviers filaires et sans-fil
La conférence sur la détection des émanations électromagnétiques des claviers a mis en évidence qu'il est possible de détecter les entrées tapées sur un clavier en se basant sur les interférences électromagnétiques produites lors de l'utilisation des touches. Cette technique pourrait permettre d'espionner les entrées clavier à l'aide d'une antenne dans un périmètre de 20 mètres autour de la source. Des recherches sont toujours en cours pour tenter d'étendre le périmètre.
A noter les présentations rumps de Philippe Lagadec de l’OTAN sur la cybersécurité et de Bruno Kerouanton sur la communication.
Pour conclure, ce SSTIC 2009 a été pour moi une très bonne expérience. J’espère la renouveler en 2010.
Vincent Ferran-Lacome
mercredi 10 décembre 2008
Par Cedric Pernet le mercredi 10 décembre 2008, 00:32
Les attaques par bruteforce SSH existent depuis des années. Il s'agit tout simplement pour un attaquant de trouver un serveur SSH à attaquer (souvent par un scan de plages complètes d'adresses IP) et d'essayer d'obtenir un accès SSH. Pour cela, l'attaquant tente de trouver un identifiant et un mot de passe valide.
Ce type d'attaque laisse d'énormes traces dans les logs. On y voit clairement des tentatives de connexion avec des noms d'utilisateurs bien connus (guest, root, etc.) ou sortis d'une liste (alex, mike, etc.). De nombreuses tentatives infructueuses sont ainsi constatées, l'attaquant essayant souvent plusieurs dizaines de mots de passe courants (toto, frodo, starwars, barneystinson etc.).
Habituellement, une seule adresse IP était utilisée à ces fins. Il était très facile de faire bannir une adresse IP qui essayait de se logger sur plusieurs comptes, ou qui tentait de se connecter plus de x fois sur un compte.
Or depuis la semaine dernière, et même si je pense que la technique existe depuis beaucoup plus longtemps que ça, certains chercheurs en sécurité informatique s'inquiètent de voir apparaitre des tentatives d'attaque par bruteforce SSH provenant de botnets. (La synthèse d'Arbor Networks est bien rédigée, je vous laisse la lire, elle reprend d'autres posts également)
Ainsi, l'attaquant peut utiliser des centaines d'adresses IP différentes pour essayer de trouver un accès valide. Chaque IP ne sera vue qu'une ou deux fois, et ne sera pas bannie.
Afin de contrer ces attaques, il semble donc judicieux d'établir des règles strictes sur les accès:
lundi 24 mars 2008
Par Cedric Pernet le lundi 24 mars 2008, 23:33
jeudi 27 septembre 2007
Par Cedric Pernet le jeudi 27 septembre 2007, 15:42
mercredi 6 juin 2007
Par Cedric Pernet le mercredi 6 juin 2007, 12:42
mercredi 23 mai 2007
Par Cedric Pernet le mercredi 23 mai 2007, 16:46
dimanche 20 mai 2007
Par Cedric Pernet le dimanche 20 mai 2007, 12:09
mercredi 18 avril 2007
Par Cedric Pernet le mercredi 18 avril 2007, 13:31
dimanche 15 avril 2007
Par Cedric Pernet le dimanche 15 avril 2007, 16:46
vendredi 6 avril 2007
Par Cedric Pernet le vendredi 6 avril 2007, 15:34
jeudi 29 mars 2007
Par Cedric Pernet le jeudi 29 mars 2007, 16:26
mercredi 28 mars 2007
Par Cedric Pernet le mercredi 28 mars 2007, 15:04
mardi 13 mars 2007
Par Cedric Pernet le mardi 13 mars 2007, 09:59
« billets précédents - page 1 de 2