Street fighter -- Assassin's Fist

De manière générale, l'adaptation d'un jeu vidéo en film donne très rarement des bons résultats.
Mais ce n'est pas toujours vrai.

Je viens de découvrir la web série "Street Fighter - Assassin's Fist" sur Machinima, et je ne peux que conseiller à tous les fans de Street Fighter 2 de la regarder. Cette série est constituée de 12 épisodes + deux trailers. L'histoire raconte l'entraînement de Ken et Ryu sur la voie de l'art martial Ansatsuken, initiés par leur maître Gouken. Le film fait des sauts dans le passé expliquant l'origine de l'ansatsuken et la rivalité entre Gouken et Akuma.

D'après les commentaires lus sur internet il s'agit d'une série faite par deux fans du jeu et cela se ressent. Cette websérie présente Ken, Ryu, Gouken et Akuma de manière tout à fait crédible.

Le scénario se tient, les combats parviennent à être crédible tout en conservant le visuel et les mouvements du jeu vidéo. Le caractère de Ryu e Ken correspondent également à l'idée que l'on se fait d'eux: Ryu, tout en réserve et Ken beaucoup plus extraverti.
Il y a eu un gros travail sur la bande son, ou l'on retrouve plusieurs morceaux du jeu vidéo retravaillés, et détourné comme la musique de Ryu jouée à la flûte. A ce sujet, le nombre de détails tirés du jeu sont innombrables et participent beaucoup à l'immersion dans l'esprit du jeu vidéo.

Cette websérie est un must see pour tout joueur de street fighter, et j'espère que la saison 2 viendra bientôt avec la même qualité.

L'ensemble des vidéos sur le site d'Assassins Fist.

SSTIC 2014

Tout droit sorti de l'imprimante

L'antivirus est mort (air connu)

On a vu cette info beaucoup reprise sur les réseaux sociaux ces derniers temps: pour Bryan Dye, vice-président chez Symantec, l'antivirus est mort et condamné à l'échec. C'est une position étrange pour une société qui édite justement un antivirus. Si on regarde l'article initial, on se rend compte que sa position est effectivement plus nuancée.

1/ L'antivirus est un échec [(c) newsoft]
Dye dit que l'antivirus est un échec commercialement parlant. Symantec va décider de ne plus investir dans cette technologie  "We don't think of antivirus as a moneymaker in any way.".
Le calcul ici est simple: les "bad guys" savent contourner un antivirus. Les antivirus et les virus ont joués à la souris pendant longtemps (vitesse et fréquence de mise à jour, analyse comportementale, ajout d'options de firewalling, sandbox, etc..) mais à la fin, le virus gagne toujours. Selon Dye, il semble donc plus pertinent de passer à autre chose que de continuer cette course à la technologie dans laquelle ils sont perdant.

2/ Mais l'antivirus reste incontournable.
Malgré ses défauts, l'antivirus bloque tout de même 45% des menaces (toujours selon le même article).
Même si ce pourcentage reste sujet à caution (comment sont qualifiées et comptées ces menaces? Voir un article de S.Bortzmeyer intéressant à ce sujet), l'antivirus reste bon dans son domaine: bloquer un certain "bruit de fond" de menaces informatiques. Dye souhaite don le cantonner à ce rôle et proposer une nouvelle forme de défense.

3/ Ne plus essayer de protéger, mais de minimiser les impacts
Dès lors qu'il est majoritairement admis que des attaquants motivés savent contourner les antivirus, et que ces mêmes antivirus ne pourront jamais l'empêcher, il faut trouver une ligne de défense supplémentaire.
Au lieu de prévenir une infection, le but est désormais de la détecter fiablement le plus vite possible, peu importe que l'infection initiale ait réussie ou non.
Et bien évidemment, Dye indique que Symantec va lancer une nouvelle offre de sécurisation des données et des réseaux qui va faire du comportemental: combo classique sonde réseau (et probablement agents sur les postes et points clés).

4/ Etes vous les 20%
L'analyse faite sur les antivirus par Mr Dye peut être portée de la même manière sur les firewalls: ils savent bloquer une petite catégorie d'attaque, mais un attaquant motivé va toujours le contourner. Faut il pour autant le supprimer? Bien évidemment non. Un antivirus et un firewall vont bloquer 80% des attaques. Le problème, dont j'ai déjà parlé ici, concerne ces fameux 20% restants.

80% des attaques bloquées par les outils traditionnels (antivirus, firewall, lecture de logs), qui sont des defaçages de site web, des vols de numéros de CB, du spam, etc.. Les 20% restants, ce sont du vol de propriété intellectuelle, obtenir des informations confidentielles, endommager des infrastructures du monde physique, décrédibiliser une entreprise, voler du code source ou des certificats de chiffrements etc. et ce sont ces 20% qui posent problème.

Fin 2012, les options consistaient en l'analyse des 10 ou 12 failles vraiment problématique, l'offensif ou l'augmentation du coût de l'attaque. Si on les prend dans l'ordre:

• L'analyse des failles c'est bien (et super intéressant), mais est-ce suffisant pour établir une ligne de défense solide? Cela fait évidemment partie d'une stratégie plus globale mais ne peut prétendre à elle seule être une solution.
• L'offensif, pourquoi pas, mais aucune entreprise commerciale ne pourra proposer cette option.
• L'augmentation du coût de l'attaque est une hypothèse peu efficace dans le cadre d'attaquant motivé par un autre but que l'argent (par exemple pour stuxnet, quelle était le poids du budget dans la décision de lancer le projet?)

Ces méthodes restent encore une fois dans la défense; est-ce vraiment le bon (ou l'unique) moyen de se prémunir des attaques?

5/ un nouveau paradigme: vous êtes compromis.
La stratégie qui consiste à empêcher un attaquant d'entrer et corrompre un réseau va donc le mur.

Il semble plus sage aujourd'hui de considérer que l'état de compromission est l'état standard d'un réseau et de ses données et qu'il faille faire avec.

Nous commençons aujourd'hui à observer une voie médiane qui consiste non plus à empêcher ces attaques de survenir, mais à les détecter et les analyser afin d'en comprendre l'origine, l'ampleur et le but[1]. Les protections vont dans ce sens. Dans le même ordre d'idée certaines sociétés ne proposent plus de pentest mais des analyses de compromissions.

L'état est donc le suivant, qui n'est pas à l'avantage de la défense:

• bloquer 80% des attaques low tech avec les outils traditionnels (antivirus, firewall, logs, etc.)
• minimiser au maximum l'impact des 20% d'attaques high tech avec des nouveaux outils et nouvelles méthodes. Reste à trouver lesquels sont efficaces et lesquels sont du pur produit marketing :-)

---
[1] Je ne peux m'empêcher de penser à un cours d'histoire que j'avais eu plus jeune concernant les menaces terroristes: a une époque, les gouvernements cherchaient surtout à empêcher les groupes terroristes de se former. Puis ils ont ensuite cherché à les contrôler afin de mieux connaître ces groupes, ces personnes et ces réseaux. Quelle est la méthode la plus efficace?

400 Gigabits par seconde, c'est beaucoup pour un DDOS?

Il y a un peu moins d'un an, je titrais un article de blog "300 Gigabits par seconde, c'est beaucoup pour un DDOS"? Il y a de cela deux semaines, CloudFlare donnait de nouveaux chiffres alarmant, citant une attaque à 400Gbit/s.

Cette info m'a inspiré deux réflexions. La première concerne  le messager: on sait que cloudflare vend de la protection antiDDos, ils sont donc les plus intéressés de citer des DDos de grande ampleur en raison de la publicité que cela leur fait. Les chiffres ont en effet été repris par un certain nombre de sites d'infos techniques avec des liens vers cloudflare. Vu les moyens mis en oeuvre pour l'attaque contre SpamHaus pour atteindre 300GBit/s, ce chiffre de 400 avait une odeur de suspicion. La seconde réflexion concerne les motivations de la personne effectuant ce DDos qui ne sont jamais données, non plus que la cible. Nous aurions une personne (ou un groupe de personnes) capable de lancer le DDos le plus puissant du monde, sans raison, ni motivations, ni cible. Ce qui semble étrange. J'ai donc laissé de côté un peu cette info, pensant être en face d'un "coup" marketing plus que technique.

Puis des informations techniques sont tombées, extrêmement intéressantes.

Tout d'abord, sur la méthode employée. Comme attendu, les attaquants ont utilisés de l'amplification. Au lieu d'attaquer le serveur, on requête un serveur tiers avec l'IP source de la victime, et on s'arrange pour que la réponse de ce serveur tiers soit plus grosse que la requête. Double effet: on masque la véritable IP de l'attaquant, et on gagne en puissance de feu^W débit. Il y a 6 mois, on entendait beaucoup parler d'amplification par les serveurs de jeux (par exemple à la GreHack). Un nouvel amplificateur particulièrement puissant a été trouvé: le NTP. Un bon article de Bortzmeyer explique cette attaque. Je me demande si des gens ont scanné Internet à la recherche de "chargen", ça pourrait être très pratique. [EDIT : effectivement : Cf https://isc.sans.edu/diary/A+Chargen-based+DDoS%3F+Chargen+is+still+a+thing%3F/15647]

Ensuite, des chiffres équivalents ont été donnés par d'autre fournisseurs de service comme OVH, ce qui tend à prouver la réalité de ces chiffres élevés.

Enfin, un document interne de CloudFlare donne beaucoup d'informations sur l'attaque (contrairement à leur premier communiqué). L'amplification NTP permet de faire un x200 en débit (!!!). L'autre information percutante, c'est celle-ci "Remarkably, it is possible that the attacker used only a single server running on a network that allowed source IP address spoofing to initiate the requests." En x200, il suffit de deux cartes réseaux à 1Gbit/s pour atteindre 400GBit/s... CloudFlare compare ensuite l'attaque au DDos qui a eu lieu contre spamhaus (qui avait sollicité de gros moyens) avec celle-ci. Il a suffit à l'attaquant 7 fois moins de machines amplificatrics pour un résultat 33% supérieur. Finalement, l'attaque à 400Gbit/s est relativement plus simple que celle contre SpamHaus, permettant d'imaginer ce DDos comme un test grandeur nature.

Pour terminer, il semblerait que le prochain amplificateur soit trouvé avec  snmp. Les premiers calculs indiquent une amplification maximale de 650! S'il se réalise, le prochain DDos dépassera le Terabit/s. Comme disent les anglais: "wait and see".

Bluetouff et gogleuh

Vous n'avez pas pu le rater, Bluetouff est désormais un cybercriminel.

Résumé des faits : Bluetouff cherche à l'aide de Google diverses données. Il tombe sur le site web de l'Anses qui contient des documents très intéressants. Il en télécharge plusieurs, et commente certains d'entre eux sur le site de reflets. L'Anses s'émeut du fait de trouver ses documents et décide de mener une enquête.
Bluetouff se voit donc face à la justice, et tout geek un minimum versé dans la technique ne voit pas d'autre issue dans ce procès que la relaxe puisque Bluetouff n'a rien fait d'autre que de télécharger des documents accessibles publiquement.

Le jugement en appel, décidé par le parquet uniquement (l'Anses n'a pas voulu poursuivre la procédure) montre le contraire puisque Bluetouff est condamné. On a pu voir fleurir un bon nombre de commentaires mi amusé, mi ecoeuré sur le thème: la justice n'y connait rien, et utiliser gogleuh n'a rien de répréhensible. Le jugement est pourtant très clair et n'a rien à voir avec Google.

Le jugement, public, est disponible : Arrêt Bluetouff. Il se lit très bien (6 pages). Les juges vont devoir qualifier en droit les actes qu'on leur a soumis. Le procès va donc chercher à éclaircir trois points, pour juger de ces trois infractions:
1/ Bluetouff s'est introduit de manière frauduleuse dans le site de l'Anses
2/ Bluetouff s'est maintenu frauduleusement dans le site de l'Anses
3/ Bluetouff a volé des données sur le site de l'Anses

Et là, les juges vont faire du juridique et non pas de la technique. Sur le premier point, ils indiquent que Bluetouff n'est pas poursuivi car rien ne vient prouver l'intention frauduleuse d'accéder à ces données, puisque même l'Anses le reconnaît. Point besoin d'être expert sécu pour comprendre que si le plaignant indique n'avoir rien fait pour protéger ses données, la bonne foi du visiteur passant par là peut être acquise. Sur le second point, c'est là que tout se joue. Les juges indiquent noir sur blanc que le prévenu "a constaté la présence de contrôles d'accès" et qu'il le reconnaît. Point besoin de technique non plus pour lui mettre le dos le "maintien frauduleux". Dans l'esprit des juges, il savait que c'était protégé, il est resté, donc maintien frauduleux; c'est simple. Sur le vol, les juges indiquent que Bluetouff a copié, dupliqué et partagé ces fichiers sans plus d'explications. Les juges indiquent vol de fichiers inaccessibles au public, mais le point 1 montre qu'en tout état de cause ces fichiers étaient accessibles au public (de manière involontaire, certes). C'est un point léger dans leur argumentaire.

Que peut on en conclure? Le raisonnement des juges est assez clair et le point central repose sur cet "aveu" de Bluetouff disant qu'il est resté après avoir su qu'il s'agissait de documents protégés. Si vous vous faites arrêter un jour (et je ne le souhaite à personne), faites attention à ce que vous dites...


Pour la suite, il y a le point de vue du principal intéressé sur son blog, et un pourvoi en cassation qui est en cours. Je ne suis malheureusement pas très optimiste sur le pourvoi en cassation :-( l'histoire nous le dira.

Haka est sorti: TCP/IP security is not boring anymore!

Il y a trois ans, je publiais un article intitulé "TCP/IP security is boring" dans lequel j'indiquais que la sécurité TCP/IP était devenue ennuyeuse.
La sécurité remonte sur les couches hautes, et les firewalls sont finalement limités dans leur usage: on coche une case pour appliquer une politique de sécurité sans jamais pouvoir sortir du carcan initial prévu par l'outil.

Mais le projet HAKA voit le jour, et je vais en faire un peu sa pub [1].

Je fais partie de l'équipe qui développe le projet HAKA, et avec HAKA la sécurité réseau ne sera plus jamais ennuyeuse. Haka est un langage orienté sécurité et réseau permettant d'accéder à n'importe quel champ protocolaire d'une communication et d'interagir avec celle-ci de manière simple (modification, suppression, création de paquet) sans avoir à se poser des questions compliquées sur la gestion bas niveau (gestion de la mémoire, dissection de protocole, ordonnancement des paquets, etc..). Ceci donne des possibilités illimitées quant à l'application de règles de sécurité et d'analyse des flux réseaux.

Un site web a été ouvert, ainsi qu'un github car HAKA est open-source. Get it, commit, play with it, fork it ou tout autre mot en 'it' :) Une version précompilée pour debian (32 ou 64bits) est disponible afin de pouvoir le tester facilement. Haka peut être lancé sur du trafic live pour l'analyser (le logger, bloquer, modifier, etc..) ou bien sur des pcap. La version 0.1 permet d'accéder à n'importe quel champ IP, TCP et HTTP.

Pour montrer la facilité d'usage de HAKA, des tutoriels montrent comment utiliser Haka. Après l'inévitable Hello World, sont présentés la manière de faire du filtrage sur n'importe quel champ IP/TCP/HTTP puis une méthode originale pour bloquer les navigateurs webs qui ne sont pas à jour en les forçant à être redirigés sur les sites d'update. Puis un module de statistiques est écrit sur une manière de browser des pcaps. Ensuite un exemple de détection de SQL injections est écrit: en une centaine de lignes de code, il devient possible de détecter et bloquer (ou modifier, ou ce que vous voulez en fait) des SQLi sur flux sans utiliser de proxy applicatifs ou autre outil lourd, avec des possibilités d'extensions simples. Pour finir, un exemple de groupe de règles est expliqué.

Pour donner un avant goût, voici un exemple de règle haka:

Pour les exemples, un seul endroit: le site web.

Haka a beaucoup d'autres fonctions qui en font un langage facile à utiliser:
debugger, analyse interactive, API C/Lua pour l'étendre, etc... La version 0.1 permet d'utiliser les règles de sécurité, les versions suivantes vont donner la possibilité de définir une grammaire et une machine à état pour définir soi-même des règles de dissection protocolaire.

Haka, c'est bon, mangez-en :-)
---
[1] Ce blog reste un blog personnel, le site officiel et la communication officielle autour de Haka se fait sur son site web et sur github.