News

Faux virus en VB.NET sur Youtube

le dans Racine - 2 Commentaires
Faux virus en VB.NET sur Youtube
Un visiteur du site m'a contacté pour avoir mon avis concernant une vidéo :

Citation:
Salut John John !!

Voici un gamin qui fait de sois disant faux virus pour "Troller ses potes"
LA vidéo montre l'affichage de boites de dialogue seulement. Mais une fois le zip sur mon PC avast s'affole. Tu pourrait éplucher le programme ??

Voici le lien
https://www.youtube.com/watch?v=ONHWUH21WrY&t=177s

Tu pourrait en faire une petite vidéo comme tu sais bien faire. Car c'est silence radio depuis janvier pour ta part. t'es sur un gros truc ou manque de temps ?


Je n'ai pas le temps de faire une vidéo là dessus pour expliquer.
Ce n'est pas le silence radio depuis janvier mais seulement février et j'en ai publié une hier. :p

Concernant les malwares, j'avais déjà fait une analyse plus poussée en juillet 2016 d'un autre truc mais qui était réel cette fois. Pour cette vidéo-ci : hélas ce n'est pas le seul à faire des blagues. C'est ce qui participe en partie à l'érosion du métier de développeur et des bonnes pratiques, les particuliers s'approprient ces outils professionnels pour faire n'importe quoi avec. Je n'ai pas vu de lien vers le code source, il propose 3 packages dans la description de la vidéo, j'ignore pourquoi s'éparpiller autant. :? Il ne livre que les .exe compilés. Après on pourrait aller plus en profondeur mais pas l'envie de décompiler. De ce que j'ai vu "WindowsApplication1" = cela semble être fait avec Visual Studio soit en C#, soit en VB.NET. Le type ne capte pas que son setup plante avec un message "read error" parce qu'il est sandboxé dans AVAST le temps de l'analyse heuristique. Bon soit.

Je rappelle qu'il est NORMAL que l'antivirus ne détecte rien puisque le programme lancé ne contient aucune signature de virus connue de la base de données de l'AV. L'analyse heuristique passe crème car comme il est planté son programme setup ne fait plus rien, donc AVAST situe le programme comme inoffensif car pas agressif dans des tentatives d'accès multiples pour pourrir le système. Les AV ont leurs limites, après le problème se situe entre le clavier et la chaise (Cf Ransomwares). Stop avec "Ohlalala AVAST c'est de la merde il a rien détecté". Les autres AV auraient certainement fait pareil.

Pour son application, rien de bien sorcier :
  • un enchaînement de fonctions MSGBOX (= MeSsaGeBOX), il existe ce genre de fonctions toutes prêtes dans tous les langages. En Pascal, en Java.
  • des formulaires (Forms = fenêtres) personnalisées avec quelques contrôles dessus.


En 20 minutes je te fais la même chose sans transpirer comme beaucoup d'autres, puisque quasiment n'importe qui qui débute avec Visual Studio passe par cela en général dans les tutoriels (voir sur Internet). :)





Le pire étant les commentaires des gamins parmi les viewers : "t'es trop fort, waouh". Je ferais un parallèle avec les vulgarisateurs comme Micode, ça épate les quidams, c'est joli, ça rend bien, mais au final les vrais savent qu'il n'y a rien de magique derrière tout cela (Kon-boot). Voir les commentaires sous la vidéo d'ailleurs. Le vrai génie n'est pas celui qui s'en sert mais celui qui l'a créé. Même si cela à l'avantage d'éveiller un peu les utilisateurs sur les questions de sécurité.

Le risque avec ces bêtises c'est qu'à force de "troller ses potes", certains ne fassent plus attention (Cf Le garçon qui criait au loup)

Voilà, bonne journée à tous. :)

Cloudbleed

le dans Informatique - 2 Commentaires
Cloudbleed



Voila un des dangers de faire transiter son trafic web par un tiers. Toute la websphere en parle : la faille liée à Cloudflare découverte par Tavis Ormandy. Mon site perso est également touché et figure dans la liste, tout comme win3x.org d'ailleurs, entre autre. Puisque Cloudflare est un CDN, c'est en quelque sorte un immense reverse-proxy distribué ayant la faculté de mettre en cache en plus des données.

Le bug tel que décrit réside dans un module de parser HTML qu'ils ont écrit eux-même dans lequel il y aurait une fuite de données. Ce module est ensuite intégré dans NGINX pour faire son job (de réécriture d'URL entre autres). NGINX tourne sur les nœuds "border edge" = de sortie = ceux qui acceptent les requêtes et remettent les réponses aux clients. De ce que j'ai compris : avec un certain type de requête on peut faire "dérailler" un buffer de ce module qui pourrait renvoyer au client des informations aléatoires résiduelles en mémoire vive concernant des requêtes/transactions faites par le même serveur par d'autres utilisateurs (à coté en parallèle), et ce quelque soit le site visité.

Les informations sortent en clair et c'est normal car c'est dans une zone ou le chiffrement n'est plus. :) Le chiffrement est d'une part entre le site d'origine (exemple OVH) et le serveur Cloudflare et d'autre part ensuite entre votre navigateur chez vous et le serveur Cloudflare. Le serveur Cloudflare déchiffre tout dans un sens et chiffre tout dans l'autre sens pour pouvoir faire ses traitements. C'est clairement un point sensible. :lol Du coup il est impossible de savoir quelles informations ont été remises à qui, et si cette personne s'en est servi ou pas. Un peut comme si votre facteur distribuait le courrier à n'importe quelle adresse de manière aléatoire. Les informations révélées peuvent donc être tout ce que vous envoyez vers un site (requêtes HTTPS), du genre :

  • Des morceaux de données POST, contenant éventuellement des mots de passe
  • Des réponses JSON d'une API
  • Des en-têtes HTTP
  • Des paramètres URI
  • Des cookies
  • Des clés API
  • Des jetons OAuth
  • Etc.


Comme Cloudflare a peut-être malheureusement redirigé ces informations vers n'importe qui à une période (depuis septembre 2016 mais surtout courant février visiblement). Le bug est corrigé mais ces données restent donc hypothétiquement dans la nature. Ces données sensibles ont parfois été mises en cache par des moteurs de recherche, elles sont donc pour certaines récupérables même si la faille a été comblée depuis. C'est pour cela que, par précaution, tout le monde vous conseille de :

  • modifier le mot de passe des sites hébergés qui sont derrière Cloudflare auxquels vous avez accédé, ces mots de passe ou leur hash (en espérant qu'ils soient salés, mais cela dépend des sites sur lesquels vous mettez les pieds et non de Cloudflare)
  • se déconnecter/se reconnecter des sites afin de faire sauter/invalider les jetons d'authentification qui ne seront plus valables pour se connecter avec votre compte à votre place.


Contrairement à ce que j'ai pu lire : non les bases de données des sites n'ont pas été hackées. C'est juste que ces infos ont fuité sur le chemin entre le site et votre navigateur.

Plus de lecture technique :

Nouveau dock Inateck FD2102

le dans Informatique - 1 Commentaire
Nouveau dock Inateck FD2102



Cette semaine achat d'un nouveau dock HDD et ce pour remplacer le bloc "rouge Ferrari" SATA/USB2.0 low-cost. Il y a quelques mois comme j'ai réuni mes deux NAS en un seul. La machine libérée m'a servi de base pour me faire un "nouveau" PC principal.

Donc dans le salon, ce n'est plus le Dell Optiplex 760 "Ananas" qui trône mais "Banane" (base de l'ancien NAS), dont le boitier a été remplacé par un Antec P100 (un peu overkill mais design). L'ancien Dell Optiplex 760 est maintenant dans l'atelier en remplacement du Dell Optiplex 745.

La carte mère de "Banane" possède des ports USB3.0 mais ne gère pas le E-SATA et donc je me retrouvais avec le débit de l'USB2.0 à 30Mo/s. Chose que j'ai pu dernièrement bien savourer quand j'ai fait ma sauvegarde avant une réorganisation de partitions. Je me suis finalement pris un Inateck FD2102 avec USB3 acheté sur Amazon.

Du coup je mets l'ancien Dock rouge sur le PC de l'atelier "Ananas" puisque lui possède l'E-SATA. Je le garde car il fait aussi les disques durs IDE (l'Inateck à deux emplacements aussi mais SATA uniquement), et ça peut toujours servir de connecter des vieux disques.

Je ne vais pas faire une review mais en tout cas j'en suis bien content, les avis sur Amazon ne mentent pas. :)

Tests :