Sécurité informatique et "exploits" (failles de sécurité)

Salut tout le monde,

Je me disais que ce serait intéressant de recenser des ressources liées à la sécurité en informatique.
Essayer de donner des exemples pour décrire comment les hackers s'y prennent pour infiltrer tel ou tel système.
Voir le cheminement type d'une attaque, et comprendre ce qui a mené à avoir son compte hacké.
Ça permettra d'identifier des comportements à risque, et accessoirement de devenir parano
Je ne garantis pas l'accessibilité et l'exactitude des informations données ci-dessous, car analyste sécurité est vraiment un métier à part entière (et ce n'est pas le mien).

Comment minimiser les risques ?

En tant qu'utilisateur de services et sites Web (via un navigateur)

• Installer un plugin pour dégager le max de publicités dans son navigateur (par exemple AdBlock Plus mais attention par défaut il laisse passer certaines pubs "fair" sauf si on va dans les options pour vraiment tout enlever)
  - firefox https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/
  
• Installer un plugin pour éviter de cliquer sur des liens présents dans une page Web ou depuis un moteur de recherche le navigateur Internet.
  Il y a « Web of Trust » dont le principe est sympa car il affiche des icônes à côté de tous les liens avec un code couleur. Mais son efficacité n'est en fait pas vraiment mesurable car c'est basé sur le retour des utilisateurs.
  - firefox https://addons.mozilla.org/en-US/firefox/addon/wot-safe-browsing-tool/
  - chrome https://chrome.google.com/webstore/detail/wot-web-of-trust-website/bhmmomiinigofkjcapegjjndpbikblnp?hl=fr
  
  
• Éviter d'installer des plugins dont l'origine est douteuse car les plugins peuvent faire beaucoup plus que ce qu'on croit en général.
  
• Privilégier une URL tapée directement dans l'URL, plutôt que de cliquer sur un lien depuis un email (voir phishing plus bas).
  Vérifier que l'URL du site ne contient pas de typo (une lettre en plus ou en moins, des accents ou toute autre truc bizarre).
  Se méfier des sous domaines « amazon.monsite.com » (appartient au serveur 'monsite.com') ou des constructions de domaines comme « www.amazon.cdn.com »
  
• Éviter de surfer ou faire des achats en étant connecté à un Wifi ouvert, disponible "gratuitement".
  Privilégier le filaire (câble RJ45) si c'est possible.
  
• Garder son navigateur à jour le plus rapidement possible.
  
• Construire des mots de passe solides, uniques et avec un nombre de caractères connus (par exemple 8 ou 16).
  Éviter de les sauvegarder dans le gestionnaire de mots de passe de son navigateur, ou à défaut mettre un mot de passe principal.
  Soigner en particulier les comptes sensibles (banque, comptes email, EDF etc.) et ne pas les garder dans un fichier de l'ordinateur.
  Par exemple, un mot de passe solide à 16 caractères « SlsZ,ospb.Mc'ca! »
  Pour retenir un tel truc, construire une phrase que telle que « Sur le site ZC, on se plaint beaucoup. Mais c'est cool aussi ! » et prendre les premières lettres de chaque mot (avec majuscules de début de phrase ou des noms propres) + la ponctuation.
  
• Consulter régulièrement https://haveibeenpwned.com/ pour savoir si le darknet a mis en vente une base de données avec ses emails.
  Si oui, mettre à jour ses mots de passe pour les sites incriminés.
  
• Changer les mots passe régulièrement de sorte que si un hacker a volé massivement des informations de connexion, elles soient caduques au moment où quelqu'un essaiera de s'en servir.
  
• Connaître les endroits où on peut usurper son identité « facilement » en créant des comptes à partir de quelques informations personnelles. Devancer cette création.
  Par exemple, sur l'assurance retraite https://www.lassuranceretraite.fr, il « suffit » d'avoir récupéré par ailleurs un numéro de sécurité sociale, un nom, et un prénom (et déduire la civilité et une date de naissance sachant que la civilité et la date sont en partie comprise dans le numéro de sécu, et qu'en en 31 essais max, on trouve le bon jour) et on peut créer un compte puis récupérer le relevé des points de retraite, avec toutes les sociétés dans laquelle la personne a travaillé dans son passé.
  
• Éviter de mettre des informations sur les réseaux sociaux alors qu'elles peuvent être utilisées comme « question de secours » des comptes.
  
• Vérifier que les cartes bancaires ne sont pas automatiquement sauvegardées sur un site marchand après un achat même en ayant dit non à cette "fonctionnalité" (genre avec ces empaffés d'Amazon de médeux).
  Privilégier les cartes virtuelles avec un numéro virtuel (e-card) si votre banque le permet.
  
• Sous Windows, éviter avec force et conviction d'utiliser le navigateur 'Internet Explorer' ou alors si vraiment mais vraiment ce n'est pas possible, au moins désactiver les composants ActiveX.
  
• Être attentif aux emails disant qu'un changement de mot de passe à été effectué, en particulier si on est en couple. Demander à l'autre personne immédiatement et agir rapidement.
  
• Se renseigner auprès de sa banque en cas de fraude (couverture, plafond etc.)
  
• [Avancé] Considérer la création d'un live CD Linux bootable (ou son pendant en USB) avec un Linux en read-only juste pour faire des achats sur Internet.
  Démarrer alors l'ordinateur en bootant sur le CD ou la clé USB, tout sera en mémoire RAM, faire son achat puis redémarrer le PC sans le CD ou la clé (mode normal).
  
• [Avancé] Configurer correctement son système d'exploitation de sorte que son navigateur ait très peu de droits d'exécution et de lecture des fichiers sur le PC.
  

Voir aussi ici : https://www.zebrascrossing.net/t11563-trucs-et-astuces-autour-de-l-informatique-et-d-internet-utilitaires-etc#1165300

En tant qu'utilisateur d'un ordinateur

À mon sens, plus on monte en compétences sur les aspects suivants, plus on pourra être vigilant et réduire les risques :

• En cas de doute sur un fichier ou une archive, utiliser le site https://www.virustotal.com qui permet d'analyser avec 70 antivirus du marché
  
  
• Passer du temps à comprendre la gestion des droits et rôles des utilisateurs de son système d'exploitation (UAC sous Windows, utilisateurs/groupes/bit "s"/sudo/... sous Linux, etc.) et être sûr de comprendre les implications quand on passe dans le rôle administrateur. Par exemple, sous Windows, par défaut il "suffit" de cliquer sur Oui quand un programme demande à avoir les droits administrateurs :
  
  Sous Linux, par défaut, sudo demande de retaper le mot de passe quoi qu'on fasse. Ça met plus la puce à l'oreille !
  Sous Windows, il faut le faire aussi selon moi. Faire une action en tant qu'administrateur se doit d'être « chiante ». Il est bon d'avoir le temps de réfléchir et de laisser l'esprit critique refaire surface, et pour moi ce moment arrive au moment je m'apprête à taper 'Entrée' alors que j'ai tapé mon mot de passe. Par contre un simple clic, c'est trop rapide...
  
  

  Procédure pour activer sous Windows:

  
  
• Comprendre la notion de processus (gestionnaire des tâches sous Windows, commande ps sous Linux, etc.), connaître les ports utilisés de manière nominal sur son système (commande netstat), savoir utiliser Wireshark pour tracer les communications réseau
  
  
• Comprendre l'origine et la façon dont sont compilés les binaires ou archivés les packages, et ne pas faire confiance aveuglement à des logiciels "open-source".
  Open source, c'est cool car on peut modifier le logiciel s'il ne fait pas ce qu'on veut ou qu'il est bugué, et tout le monde peut en bénéficier.
  Par contre, n'importe qui peut le compiler et mettre un virus dedans au passage. Ça ne garantit pas qu'il est sans virus.
  (Ah zut, je croyais que c'était le cas pour CCleaner 5.33.6162 mais il n'est pas open source en fait)
  
  
• Comprendre quelles sont les implications d'avoir un navigateur Web (firefox, chrome, opera, Internet explorer etc.) pour surfer sur Internet et ce que les hackers sont capables de faire avec du javascript/des images/etc présent dans des pubs ou des iframes véhiculées justement par les régies publicitaires apparemment "saines". Par exemple, quand le logiciel malwarebytes affiche ce genre de message sous Windows :
  
  
  
  
• [Avancé] Mettre un routeur en coupure sur son réseau (par exemple, une vieille machine Linux avec 2 ports ethernet + quelques règles iptables + serveur DHCP/DNS) afin de voir passer, analyser et éventuellement filtrer tout le trafic réseau après détection des comportements « malicious » (botnets, emails spamming, distributed denial of service attacks).
  Ajouter éventuellement un proxy genre squid pour le filtrage du trafic HTTP/HTTPS (port 80/443), SMTP/POP3, FTP
  Ajouter éventuellement une DMZ ou des VLAN pour que le routeur donne une adresse aux PCs invités ajoutés sur le réseau (réseau distinct du réseau principal avec par exemple 192.168.0.0/24 et 192.168.100.0/24), ainsi les switchs protégeront nativement les machines entre elles.
  Exemple de schéma réseau avec un routeur en coupure
  
  

En tant que développeur

• Contrôler régulièrement que les briques logicielles utilisées ne présentent pas de failles de sécurité.
  
• Penser à assainir les données d'entrées avec des limites de tailles, de format etc. (input sanitize).
  
• Penser à tester le comportement aux limites et au delà avec des tests unitaires.
  
• Employer des outils comme valgrind notamment sur la suite des tests unitaires pour vérifier qu'aucune stack n'est attaquée selon les différentes exécutions.
  

En cours de rédaction

EDIT 20171220: Ajout 'Comment font-ils en pratique ?' + ajout d'un exemple de crack dans la section 'Virus traditionnels' + section 'Comment savoir si mon ordinateur est contaminé ?' + 'Injections SQL'
EDIT 20171221: Ajout 'Comment minimiser les risques ?' + 'Comment enregistrer l'activité du clavier et de la souris (keylogger) ?'
EDIT 20171222: Ajout livre sécurité
EDIT 20171224: Amélioration exemple 'Faux emails menant sur des "vitrines" présentant la même interface apparente (phishing)'
EDIT 20171225: Ajout d'exemples de liens HTML incohérents dans 'Faux emails menant sur des "vitrines" présentant la même interface apparente (phishing)'

A ajouter :

- CRLF injection https://www.owasp.org/index.php/CRLF_Injection
- rootkits sous Linux (dump rkhunter)
- navigateurs
  - cross site scripting https://en.wikipedia.org/wiki/Cross-site_scripting
  - navigateur web: malwares passent inaperçus par la compression des scripts js (scripts "minified" avec extension .min.js habituellement)
  - session token
  - lynx/curl/wget ne sont pas épargnés
  - Internet Explorer et ActiveX : au secours, c'est infernal !
- ordinateur quantique x qubits + algorithme de Shor = bye-bye encryption avec une clé x bits type RSA (basé sur la non décomposition simple d'un grand nombre en facteurs premiers)
- attaques man in the middle (en particulier wifi)

Liens

Moteur de recherches des objets connectés (exemple serveurs utilisant le FTP "proftpd")
https://www.shodan.io/search?query=proftpd

Liste des vulnérabilités d'un logiciel donné (exemple serveur FTP "proftpd")
https://nvd.nist.gov/view/vuln/search-results?query=proftpd&search_type=all&cves=on

Documentaire sur stuxnet
https://fr.wikipedia.org/wiki/Zero_Days

Livres :
- Detection of Intrusions and Malware, and Vulnerability Assessment: 6th International Conference

Notion de port, connexion et firewall

Prenons l'image d'un château fort situé à côté d'une ville. Le château est disjoint et distinct de la ville et ce sont deux entités (ordinateurs) différents.
Tant qu'on vit en autarcie (sans Internet, sans ajout de logiciel supplémentaire), et qu'on a une confiance méritée envers tout le peuple actuel, tout va bien.

Mais il y a toujours des échanges commerciaux avec l'extérieur (Internet).
Vu du château, chaque jour, des gens peuvent rentrer et sortir pour importer des choses à l'intérieur du château (download) ou exporter vers l'extérieur (upload).
Mais il y a des règles comme on est au moyen âge !

• Les seigneurs (utilisateurs avec un compte utilisateur actif) s'échangent des trucs entre eux via des parchemins (messages TCP/UDP) qui peuvent contenir des pièces jointes (payload des messages) et qui sont acheminés par porteurs (programmes).
  
• Les porteurs sont des humains qui doivent en principe obéir au seigneur.
  
• Le château a des numéros de liaison pour chaque demeure (numéro de port sur 16bits donc entre 0 et 65535 pour faire simple, car certains sont réservés) ainsi qu'éventuellement des portes principales autour du château avec des gardes offusquant ce qui se passe à l'intérieur si besoin (si des règles de trafic sont configurées via un éventuel pare-feu ou firewall).
  

Prenons le cas facile vu du château (download/upload) quand le transfert est à l'initiative d'un seigneur du château (intérieur → extérieur).
Le seigneur demande par message un truc à un seigneur de la ville car il connaît son numéro de liaison (on verra après le pendant quand on est dans l'autre).
Par exemple, il sait qu'un seigneur est joignable sur le numéro 1234 (un serveur écoute le port 1234)
Le seigneur d'en face reçoit le message, accepte et le porteur revient avec un paquet, une boîte ou une caisse.
De là trois choses possibles:

• Le colis est sain
  
• Le seigneur avait demandé un colis contenant un porteur qui sait faire des tâches intéressantes pour lui comme la cuisine, etc. mais en fait c'est entre autre un espion : pendant son temps libre celui-ci se balade à l'intérieur du château, ouvre les tiroirs, cherchent des trucs à piquer ou à utiliser. Son activité peut passer inaperçue sans antivirus ou si l'antivirus ne voit la différence avec les autres usagers du château (après tout, les gens honnêtes ouvrent aussi les tiroirs). Tant qu'on n'est pas connecté à Internet ou que le pare-feu empêche l'espion de communiquer avec l'extérieur, ça n'est pas trop grave. Par contre, si l'espion a amené des artisans pour changer toutes les serrures et prendre les gens en otages (disque crypté par un ransomware), le château est perdu s'il ne peut ou veut pas négocier.
  
• Le colis contient un virus mortel qui éradique tous les porteurs et les maisons du château. Le seigneur se retrouve seul avec un mur d'enceinte et des ruines (disque formaté). Il peut alors encore toujours fouiller les décombres pour retrouver des choses qui lui appartenait mais aussi bien tout est perdu (car le formatage efface seulement les indexes du système de fichiers).
  

Dans le cas où un espion est déjà dans l'enceinte du château, il y a un cas qui pose vraiment problème.
En partant de la ville, il avait noté le numéro de liaison d'un repaire de bandit (port 666). Il sait que quelqu'un écoute sur ce numéro (port 666) dans cette ville (adresse IP 10.11.12.13)
Comme l'espion est dans l'enceinte du château, il peut, au culot, se faire passer pour un seigneur et corrompre ou remplacer les porteurs habituels, éventuellement dégommer les gardes d'une des portes vers l'extérieur (firewall), et initier un transfert d'informations ou de choses volées vers le repaire de bandit.
Bien souvent, même s'il y a des gardes à l'entrée du château (firewall), ils ne demandent le fameux "qui va là ?!" que si un porteur se présente spontanément aux portes pour rentrer dans le château (cas d'un seigneur de la ville demandant à envoyer un message à l'intérieur du château, que l'on n'a pas vu encore). Au contraire, si une personne sort du château avec un message à destination du port 666, les gardes acquiescent simplement sa sortie, lui donne un ticket ou un tampon sur le bras pour pouvoir revenir après (identifiant de connexion), et ils le laisseront alors passer en revenant car il a son ticket. Les gardes sont assez permissifs quand cela va vers l'extérieur. Pourquoi ? Car sinon, cela serait dur de joindre l'extérieur. Mais au niveau sécurité, ça serait fort ! Dans ce cas, les gardes (firewall) diraient "Halte, avant de te donner un ticket, je veux savoir qui tu vas voir et où ?" et le porteur serait obligé de lâcher le numéro 666 (il ne peut pas mentir ici pour le coup). Les gardes diraient qu'ils ne connaissent pas ce numéro et remonteraient cela à l'intendant qui demanderait au seigneur (l'utilisateur du PC) s'il est d'accord pour autoriser un tel déplacement (une fenêtre popup du firewall dirait "Nouvelle connexion sur port 666. Autoriser ?"). Le problème : chaque nouveau couple ville/numéro liaison devrait être validé par le seigneur qui croulerait sur les demandes. Imaginez que chaque jour vous vous adressez à des dizaines et des dizaines de serveurs avec le navigateur Web. Il faudrait contrôler et donner son accord pour chacun d'eux... Moralité on ne le fait pas, c'est bien trop contraignant.

Maintenant, prenons le cas où le transfert est à l'initiative d'un seigneur de la vie (extérieur → intérieur).
Le seigneur de la ville doit déjà connaître l'adresse du château (adresse IP) et le numéro de liaison pour le porteur du message (port sur lequel un serveur écoute).

• Si les portes du château sont fermées ou les gardes refusent l'entrée (firewall qui bloque l'accès), alors le porteur ne rentre même pas. La demeure mandatée par le seigneur peut bien écouter pour recevoir des messages, le porteur n'ira pas plus loin (c'est souvent fait au niveau du noyau, par exemple avec des règles iptables sous Linux). En tant que développeur, c'est parfois bien chiant car tu ne comprends pas pourquoi ton programme ne marche pas car le système en lui-même bloque l'accès. Mais au niveau sécurité, c'est normal.
  
• Si les portes sont ouvertes, le porteur rentre dans l'enceinte et s'adresse à l'intendant du château avec son numéro de liaison (port). Si le secrétariat de la demeure est fermé ou le secrétaire malade (serveur crashé, mauvais port), le porteur ne peut pas aller plus loin. Il n'y aura même pas de porte sur laquelle frapper.
  
• Si le secrétariat est ouvert, il peut frapper à sa porte. Si le secrétaire a trop de demandes en cours, il ne répondra pas (serveur occupé → timeout ou erreur 500 parfois, la connexion ne peut pas se faire).
  
• Si le secrétariat est ouvert, disponible et répond "Oui, entrez" (la connexion est alors établie dès que le serveur répond la toute première fois), un mot de passe peut-être demandé (dans le protocole donc au dessus de la couche de transport, par exemple SSH, OAuth) avec éventuellement quelques allers-retours ville/château pour être sûr du correspondant.
  
• Si le porteur réussit ou s'il n'y avait pas de mécanisme d'authentification, les échanges peuvent continuer et le porteur peut déposer ou prendre des choses (upload/download)
  

Quels cas de figures mènent à des échanges indésirables

On a vu le premier cas, c'est celui où un porteur espion s'adresse à un repaire de bandit depuis l'intérieur.
C'est le plus difficile à traquer. Car comment séparer le bon grain de l'ivraie, sauf à connaître que ce couple adresse/numéro est "indésirable" ?

Le second cas, c'est celui où une brèche dans la forteresse permet de rentrer dans le château.
On a vu que si on a un numéro de port et que quelqu'un écoute à l'intérieur, ça peut nous permettre d'initier une connexion.
Mais bon initier une discussion (connexion) en termes de messages entre porteurs (donc une communication au niveau IP) n'apporte souvent pas grand chose, c'est juste pour comprendre les bases et ce qui vient après. Car derrière ça, il faut que les porteurs soient "corruptibles". C'est là que se passe les choses.

Il faut alors une demeure avec un port "ouvert" et des porteurs obéissants qui disent "amen" à tout selon comment on discute avec eux.
Mais comment créer cette brèche ?

Trois façons selon moi :

• Un espion a installé une demeure avec un port ouvert. Il a donc moyen de recevoir et accepter des connexions depuis l'extérieur. C'est comme si un artisan avait profité d'un changement de chauffe-eau pour déverrouiller la porte de derrière afin de pouvoir laisser des complices rentrer le soir venu.
  
• Le seigneur a fait installer une extension de son château (une librairie, un framework) et l'enceinte de cette extension est fragile à un endroit ou les ouvriers oublient systématiquement d'enlever une échelle à un endroit. Comme cette extension est utilisée dans plein de châteaux, certains ont vu le défaut et essaient de rentrer par cette voie dans tous les châteaux qui en sont équipés. Ramener à l'informatique, c'est un cas très très fréquent. Pourquoi ? Car les développeurs utilisent des "librairies" ou des "frameworks" tout faits pour éviter de réinventer la roue à chaque nouveau projet. Par exemple, ils veulent faire un dégradé. Au lieu d'implémenter le dégradé, ils trouvent une librairie qui fait le boulot, et ils appellent simplement la fonction qui va bien, genre "degradé(couleurDépart, couleurFin)". Idem, dans le cas d'un site, si on veut gérer du contenu, on peut considérer par exemple le framework Wordpress. Mais, ce faisant, on installe un système qu'on ne connait pas entièrement. Justement, on n'a pas envie de s'emmerder. On veut installer et que ça marche pour se concentrer sur la partie utile du site (le design, les nouvelles fonctionnalités). Mais, s'il y a des portes ouvertes ou des failles dans l'enceinte, on risque d'avoir de mauvaises surprises.
  
• Le seigneur a choisi une enceinte de château qui n'est pas très solide (système d'exploitation). Les ingénieurs ont mis plein de portes partout parce que c'était "cool" et utile à certains usagers, mais ils ont mal évalué les rondes des gardes, et parfois les portes sont grandes ouvertes suscitant l'intérêt des voleurs de passage. Et c'est là qu'un Windows XP directement placé derrière un modem ADSL s'arrête tout seul au bout de 60s car des robots scrutent toutes les IP d'Internet à la recherche de systèmes faillibles pour les accéder. Par exemple, MSBlast ci-dessus tirait partie d'une faille de sécurité pour se diffuser sans passer par le canal traditionnel des pièces-jointes d'email mais simplement en se spammant lui-même à un grand nombre d'adresses IP aléatoires.
  

Les deux dernières façons sont les fameuses failles de sécurité.
Dans tous les cas, les gens qui connaissent leur existence s'y connectent de l'extérieur et exploitent les porteurs dociles pour faire ce que bon leur semble.
L'analogie avec la vie courant serait une personne qui se rend dans un organisme qui donnent des cartes grises où les employés sont très nombreux et peu sensibilisés à la sécurité.
Cette personne sait par son expérience que lorsqu'elle arrive, elle n'a pas besoin de se présenter au guichet.
Si elle monte les marches directement, et donne son nom, la personne en face considérera qu'elle a déjà payé, et fera la carte grise.
Il y a des portes de derrière (backdoors) partout à qui sait bien regarder et n'a pas de problème de conscience.

Adresse IP (cas IPv4)

Je ne parlerai que de l'adresse IPv4 car c'est toujours la plus connue et utilisable.
Dans la vie courante, on identifie les villes par des codes postaux. Ils pourraient être uniques mais ceux par défaut sont souvent partagés entre plusieurs communes.
En informatique, tout se retrouve à être représenté en numérique à la fin. On cherchait un moyen d'identifier des machines.
Ce qui a été retenu pour l'IPv4 a été de prendre un espace d'adressage large de 4 octets.
Quand on lit par exemple 10.11.12.13, en fait ce sont les représentations numériques en base 10 de ces 4 octets, séparés par des points par commodité de lecture.
En théorie, on a donc des adresses allant de 0.0.0.0 à 255.255.255.255, ce qui représente un espace adressable de 256^4 (ou 2^32 si on raisonne directement en octets) soit environ 4 milliards de combinaisons possibles.
En pratique, celles qui sont réellement utilisables pour déterminer une adresse sont moins nombreuses (car certaines sont réservées).

Comment enregistrer l'activité du clavier et de la souris (keylogger) ?

La simplicité de cette étape a de quoi donner froid dans le dos...
Sous Windows, il suffit de chaîner un hook à une fonction définie dans une DLL via SetWindowsHookEx.
Par exemple, un pseudo code en C donnerait :

Code:

// main.c
HMODULE hMod = LoadLibrary("keylogger.dll");
if (hMod == NULL)
{
  MessageBox(hWnd, "Log", "Error: cannot start logger, keylogger.dll not found.", 0);
}

HHOOK hKH = SetWindowsHookEx(WH_KEYBOARD, &KeyProc, hMod, 0 );
 

// keylogger.dll
#define HOOKS_API __declspec(dllimport)
char text[100];

LRESULT HOOKS_API CALLBACK KeyProc(int nCode, WPARAM wParam, LPARAM lParam)
{
    char chInput = (char) wParam;
    static bool uppercase;
    char name[20] = {0};    

    if (nCode == HC_ACTION && lParam & 0x80000000)
    {      
      processKey(wParam, lParam);
    }

    return CallNextHookEx(hKeyHook, nCode, wParam, lParam);
}

void processKey(WPARAM wparam, LPARAM lparam) {
  TCHAR name[40] = {0};
  GetKeyNameText(lparam, name, 39);

  if (strlen(name) > 1) {
    // special keys like "PgDown", "Delete"
    if (string(name) == "SPACE" || string(name) == "ESPACE")
      // space key
    else
      // others
  }
  else if (ToAsciiEx(wparam, MapVirtualKeyEx(wparam, 2, kbd_layout), keystate, (LPWORD)&key, 0,  kbd_layout))
  {
    // individual key strokes are here, like 'a', 'b' etc.
  }
}

Virus traditionnels

Revenons un peu en arrière. Il y a une vingtaine d'années, les ordinateurs attrapaient des virus principalement par l'installation de logiciels d'origine douteuse ou de cracks. De mémoire, c'étaient souvent des virus dans le registre casse-couilles (par exemple qui faisaient bouger la souris de manière aléatoire en t'empêchant de cliquer, ou qui éteignaient l'ordinateur, ou vraiment au pire formatait le disque), ou des trojans qui permettaient d'ouvrir une brèche de l'intérieur. Les pirates s'en servaient alors pour rebondir d'ordinateurs en ordinateurs pour brouiller leurs traces quand ils faisaient des actes illicites.

Un exemple de crack simple

Pour comprendre les virus, il faut se rapprocher de la machine.
La meilleure façon de se rentre compte de ça est sans doute d'avoir une vision bas niveau, par exemple en regardant comment est généré un crack simple.
Si on prend le contrôle d'une licence très simple, il y a toujours un moment où il y a le test fatidique.
Par exemple, si on a une fonction C qui fait le test suivant

Code:

#include <stdlib.h>

void testLicense(char license)
{
  const char validLicense = 10;
  char testResult = (validLicense == license);
  if (!testResult)
  {
    // ouvrir un fenêtre avec le texte "Mauvaise licence"
    exit(1);
  }
}

Mais quand un programme est compilé et donné à l'utilisateur, on n'a pas le code source sympa (en python, en Java, en C, bref dans un langage plus proche de l'humain).
Pourquoi ?  Car le code source que ce soit en C, en python etc. et, même en assembleur, n'est pas interprétable par le système en soit.
La seule chose que le CPU comprend, ce sont des séquences d'opcodes. Pour en arriver là, il faut soit un compilateur (par exemple, gcc en C qui transforme un fichier .c en binaire) soit un interpréteur (comme python pour les fichiers .py, mais au final le code python est transformé par un compilateur interne).
Donc, si on exécute un fichier binaire (en double-cliquant sur un .exe sous Windows par exemple), on demande au CPU d’exécuter ces séquences d'opcodes.
Réciproquement, si on veut comprendre ce qui se passe dans ce binaire, on peut très bien ouvrir ce fichier avec un éditeur héxadécimal, et regarder les instructions machines (les fameux opcodes).
Mais comme c'est pas super de regarder des octets à la queue leu leu (55 48 89 e5 48 83...), on préfère habituellement désassembler le binaire (le fichier .exe) ce qui va nous donner un code assembleur correspondant, un peu plus lisible. Après on peut tenter de comprendre tant bien que mal ce qui est fait, car lire de l'assembleur devient vite difficile dans le sens où il n'y a pas de nom de variable, pas de nom de fonction. Simplement, du code et du code qu'il faudra analyser en ajoutant progressivement des commentaires dans le code assembleur pour pouvoir s'y retrouver.
Il y a une raison à ce que les gens censés évitent l'assembleur : c'est habituellement fastidieux.
Il faut vraiment avoir un besoin fort (par exemple pour optimiser le temps de codage dans un encodeur vidéo et réduire le temps de compression d'une vidéo) pour mettre le nez dans cette partie.
Il arrive que les gens ayant un petit/moyen niveau en assembleur te balancent "moi je code en assembleur ou en C, mon programme est donc super rapide".
Sauf que si je ne comprends rien à la complexité algorithmique, cet argument va venir décrédibiliser mon propos direct... En d'autres termes, je risque de passer pour un couillon.
Ainsi, un programme python réfléchi avec des boucles mais qui tire partie des accès en O(1) de ses hashtables peut pulvériser (mais atomiser quoi) le même programme en C parce qu'on avait pas ces hashtables et qu'on a alors fait du O(n³). Bref, c'est un autre débat.

Restons-en au fait que toute personne saine d'esprit devrait éviter l'assembleur
Mais bon, comme on est joueur, si on désassemble la fonction ci-dessus (en gardant les opcodes aussi), on va se retrouver avec une instruction qui sautera ou non la portion de code qui invalide la licence.

Code:

0x00000001004010f8 <+0>:     55              push   %rbp
0x00000001004010f9 <+1>:     48 89 e5        mov    %rsp,%rbp
0x00000001004010fc <+4>:     48 83 ec 30     sub    $0x30,%rsp
0x0000000100401100 <+8>:     89 c8           mov    %ecx,%eax
0x0000000100401102 <+10>:    88 45 10        mov    %al,0x10(%rbp)
0x0000000100401105 <+13>:    c6 45 ff 0a     movb   $0xa,-0x1(%rbp)
0x0000000100401109 <+17>:    0f b6 45 ff     movzbl -0x1(%rbp),%eax
0x000000010040110d <+21>:    3a 45 10        cmp    0x10(%rbp),%al
0x0000000100401110 <+24>:    0f 94 c0        sete   %al
0x0000000100401113 <+27>:    88 45 fe        mov    %al,-0x2(%rbp)
0x0000000100401116 <+30>:    80 7d fe 00     cmpb   $0x0,-0x2(%rbp)
0x000000010040111a <+34>:    75 0a           jne    0x100401126 <testLicense+46>  ; test de la licence (Jump if Not Equal)
0x000000010040111c <+36>:    b9 01 00 00 00  mov    $0x1,%ecx
0x0000000100401121 <+41>:    e8 2a 00 00 00  callq  0x100401150 <exit>
0x0000000100401126 <+46>:    90              nop                                  ; adresse du saut via le JNE
0x0000000100401127 <+47>:    48 83 c4 30     add    $0x30,%rsp
0x000000010040112b <+51>:    5d              pop    %rbp
0x000000010040112c <+52>:    c3              retq

Si on regarde les opcodes, on trouve un JNE avec un opcode de 0x75 qui saute de 0x0a à partir de la fin de l'instruction, soit 0x...1c + 0x0a = 0x...26.
Si on change le JNE par un JE d'opcode 0x74, on inverse le test et on ne rentrerait dans le corps du 'if {}' que si la licence était bonne.
Les systèmes de protections sont beaucoup plus complexes mais c'est l'idée.
Quand un hacker fait un crack, il fait un programme qui va changer localement la valeur 0x75 à 0x74 de sorte que le programme cracké bypasse le contrôle de licence.
Mais, un tel hacker est sans doute capable de lire direct l'assembleur ci-dessus.
Il peut alors soit profiter pour modifier plus drastiquement le programme cracké, soit directement mettre un virus dans l'exécutable qui transforme le binaire à cracker.
C'est ainsi que les virus traditionnels pouvaient et peuvent toujours commencer leur vie.

Comment savoir si mon ordinateur est contaminé

La solution la plus simple c'est d'avoir un antivirus/anti-malware à jour.
Mais ça n'est pas exhaustif malheureusement car :

1. Certains virus ne sont pas encore découverts
   
2. Certains virus se cachent si bien dans la mémoire que même avec l'antivirus qui les connais à priori, ils passent inaperçus, il faut alors par exemple enlever le disque dur et le mettre comme disque secondaire dans un autre ordinateur (sans booter le système avec ce disque, donc par exemple en le branchant après démarrage sur un docker USB). Alors une analyse avec l'antivirus pourrait le détecter plus facilement.
   

On peut aussi se demander comment font les chercheurs qui détectent les virus dans les laboratoires des fournisseurs d'antivirus.
Alors je crois qu'ils utilisent des ordinateurs ou machines virtuelles dédiés et déconnectés du réseau. Ensuite, avant d'installer le logiciel a tester :
- soit ils clonent les machines physiques avec un OS tout frais tout neuf (par exemple avec CloneZilla) pour qu'ils soient le plus clean possible
- soit ils enregistrent un snapshot de la VM pour pouvoir revenir à un état antérieur facilement

Après ils installent le logiciel à tester puis compare le registre, les fichiers système, les communications réseau avant/après.
Si c'est sous Windows, il existe aussi des outils qui monitorent tout ça en temps réel mais je ne rappelle plus du nom.
Tu fais une installation d'un logiciel et l'outil te dit tout ce qui a bougé entre avant et après.
Ensuite commence l'analyse qui peut être délicate car certains virus sont très très bien pensés par des esprits très brillants.

Comment font les pirates pour exploiter une faille (diffuser un virus, infecter un système) ?

Ici, les pirates sont moins actifs que dans le cas d'après. Il y a bien-sûr un travail préliminaire mais c'est surtout de l'attente ensuite. On pourrait dire qu'ils pêchent, en lançant des hameçons ou des filets.

Faux emails menant sur des "vitrines" présentant la même interface apparente (phishing)

La première faille est d'exploiter la naïveté humaine.
Après avoir dupliqué l'interface utilisateur du site visé et mis cette copie sur un serveur leur appartenant, ils envoient des emails en se faisant passer pour le site (cf. après).
Ils demandent de mettre à jour le mot de passe, disent qu'il y a un message en attente etc.
Bref ils cherchent à ce que l'utilisateur morde, à ce que les utilisateurs se connectent à ce qu'ils croient être le vrai site (qu'ils connaissent) en mettant leurs vraies informations de connexion.
Dans l'email, les gens cliquent sur le lien interne à l'email. Mais comment est-ce possible qu'on ne s'en rende pas compte ?

Pour bien comprendre, il faut faire un peu d'HTML. L'HTML est le langage utilisé par les développeurs (honnêtes ou non) pour afficher des pages Web.
Ce qui est intéressant ici est la balise issue du mot anglais anchor, soit <a>...</a>
Par exemple, dans une page Web qu'on est en train de créer, si on veut faire un lien vers l'adresse 'http://www.yahoo.fr' et que le texte affiché soit 'Yahoo!', on va mettre en HTML :

Code:

<a href="http://www.yahoo.fr">Yahoo!</a>

Si on démarre le navigateur et qu'on le redimensionne à outrance pour n'avoir que les parties intéressantes (le texte et la barre d'état en bas à gauche qui affiche les liens), on va alors voir dès qu'on passe la souris sur le lien :



Là tout va bien, c'est ce qu'on attendait.
Par contre, rien n'empêche d'écrire :

Code:

<a href="http://www.yahooo.fr">Yahoo!</a>

Voire plus vicieux

Code:

<a href="http://www.yahooo.fr">http://www.yahoo.fr</a>

Ramené à l'email, les gens se fient au visuel : ils cliquent et ils arrivent sur une interface qu'ils connaissent. Ça a l'air pareil et ça l'est !
Simplement, au lieu de t'adresser à la ville "Montpellier", tu rejoins la ville "Pékin".
Il faut bien regarder la barre avec l'URL du navigateur.
Si tu t'adresses à google.com et que tu arrives sur yingkl.cn à la place, tu vas tiquer normalement.
Par contre certaines fois, c'est plus subtile (par exemple le coup de la "typo" avec une lettre en plus ou en moins) :

Pièces jointes d'emails contaminées

La porte d'entrée la plus courante est celle des pièces jointes d'emails.
Pourquoi ? Parce que les gens ne font pas super attention.
Sur 100 emails envoyés, il y en aura bien un ou deux qui va cliquer par habitude.

La majorité des utilisateurs ne connaissait pas ou ne connaît toujours pas vraiment les extensions des fichiers de son système d'exploitation.
Il y a une pièce jointe, ils cliquent dessus par mégarde ou par curiosité que ce soit un .jpg, un .ppt ou un .exe.
Et bim, paie ta macro qui exploite une faille de sécurité dans Powerpoint.
Ou bam, paie ton exécutable vérolé qui déploie une saloperie sur le système.
Pire, les serveurs SMTP qui permettent d'envoyer des emails sont très souvent ouverts.
Ça veut dire que n'importe qui peut envoyer un email sans authentification en se faisant passer pour qui il veut.

Ça vous surprend ? Non, vraiment ?? Moi, ça m'avait bien scotché au début
Mais, en fait, c'est probablement calqué sur la boîte aux lettres : n'importe qui peut envoyer une lettre en se faisant passer pour qui il veut.
On ne peut pas mettre un agent assermenté qui contrôle devant chaque boîte aux lettres, carte d'identité à l'appui, que vous êtes bien l'émetteur de la lettre.
Par contre, on peut tiquer que l'expéditeur se dise de Paris alors que sa lettre vienne d'un autre département.

Là, où ce n'est pas très clair, c'est pourquoi ils ont fait la même chose en informatique alors que réciproquement ils ont toujours demandé un mot de passe pour les serveurs de réception (POP)...
Enfin, c'est un fait et comme c'est l'intérieur du message qui fournit les informations, il suffit de construire le message qui va bien à la main et l'envoyer de manière brute au serveur SMTP de son fournisseur d'Internet (par exemple le serveur smtp.free.fr). Pour cela, il suffit de connaître le protocole et d'envoyer les bons champs ! Par exemple quelque chose du genre :

Code:

HELO
MAIL FROM: emmanuel.macron@youpie.gouv.fr
RCPT To: you@iap.com
DATA
From: Manu <emmanuel.macron@youpie.gouv.fr>
To: Charles Pigeon <you@iap.com>
Subject: Invitation
Mime-Version: 1.0;
Content-Type: text;
Bonjour,

Je vous invite à un banquet à l’Élysée.
Allez, y-aura du gâteau !

Manu
.
QUIT

Donc les hackers ont tiré partie de cette ouverture et avec des scripts ont commencé à construire et spammer les adresses les plus probables, en construisant des adresses en partant de liste de prénoms et noms courants assemblés ensemble et suffixés par un fournisseur d'Internet.
Par exemple en python ça donnerait :

Code:

liste_prenoms = ['nicolas', 'jean', 'marie']
liste_noms = ['dupont', 'duc']
liste_internet = ['free.fr', 'orange.fr', 'yahoo.com']
for address in ['{}.{}@{}'.format(p, n, f) for p in liste_prenoms for n in liste_noms for f in liste_internet]:
    print address

Ce qui permet de balayer

Code:

nicolas.dupont@free.fr
nicolas.dupont@orange.fr
nicolas.dupont@yahoo.com
nicolas.duc@free.fr
nicolas.duc@orange.fr
nicolas.duc@yahoo.com
jean.dupont@free.fr
jean.dupont@orange.fr
jean.dupont@yahoo.com
jean.duc@free.fr
jean.duc@orange.fr
jean.duc@yahoo.com
marie.dupont@free.fr
marie.dupont@orange.fr
marie.dupont@yahoo.com
marie.duc@free.fr
marie.duc@orange.fr
marie.duc@yahoo.com

Une fois qu'une personne est infectée, le programme récupère les vrais contacts de la personne et se propage en utilisant de vraies adresses, et en se faisant passer pour la personne infectée (champ From:).
Les gens voient arriver un message avec le nom de la personne qu'ils connaissent. Ça baisse encore leur vigilance.
De nos jours les serveurs SMTP deviennent un peu moins permissifs, blacklistent les IPs qui spamment trop d'emails dans un certain laps de temps. Mais c'est quand même toujours ouvert.

Infiltration depuis un navigateur Web (drive-by download)

https://en.wikipedia.org/wiki/Drive-by_download
https://en.wikipedia.org/wiki/Shellcode

Et là, j'ai déjà eu des réactions de gens dans mon entourage qui disaient en substance "Moi, je crains rien, je suis sous Linux !" ou "Moi, quand un site craint, je télécharge en ligne de commande".
Dans les deux cas, ce n'est pas suffisant. Sous Linux, il existe des virus aussi. Bien sûr, c'est sans doute moins fréquent.
En général, sur les systèmes basés sur la distribution Debian, on utilise la commande apt-get qui va chercher dans les dépôts Debian officiels.
Sauf avoir importé des dépôts supplémentaires ou installé des paquets .deb à la main, le risque d'être contaminé est alors quasiment nul.

Par contre par le navigateur Web, on peut de nouveau se faire avoir, comme désormais le code est partagé entre les diverses plateformes (code source multi-plateforme).

Comment font les pirates pour trouver des brèches de sécurité ?

Ici, les pirates sont actifs dans le sens où ils vont chercher leur proie. On pourrait dire qu'ils chassent ou qu'ils pêchent en harponnant.

Attaque heuristique sur les IP

Maintenant, une autre façon destinée à attaquer les machines directement.
Comme les adresses sont de la forme 10.11.12.13, et bien allons-y, balayons la plage entière et accessoirement essayons de nous connecter aux principaux ports pour voir si ça répond.
Par exemple, on peut essayer avec le port 22 (SSH) et l'utilisateur "root" + mot de passe "root" au cas où une personne ait été imprudente.
On peut essayer aussi sur le port 80, voir si ça répond, attraper la version du serveur Web et voir si c'est une version présentant une faille connue.
Pourquoi ? Parce que la majorité des admins ne suit pas ces failles ! Ils n'ont déjà pas le temps de faire ce qu'on leur demande. Alors, faire de la veille sécurité en plus, faut pas déconner.
Donc, il y a plein de machines faillibles et disponibles. Suffit de regarder. Et les hackers, eux, connaissent les failles de sécurité. C'est leur gagne-pain.

Par exemple en python, si on voulait balayer les 254 adresses utilisables d'un réseau domestique :

Code:

import ipaddress

for address in ipaddress.ip_network(u"192.168.0.0/24").hosts():
    print address

Et ça donnerait :

Code:

192.168.0.1
192.168.0.2
192.168.0.3
192.168.0.4
192.168.0.5
192.168.0.6
...
192.168.0.251
192.168.0.252
192.168.0.253
192.168.0.254

Problème: ça fait vite du monde. Si on prend le cas naïf à 2^32 * 65535 ports (même si tous ces cas ne déjà pas valides) ça donne environ 280 billions de combinaisons à tester (sachant que les ports ne sont pas forcément ouverts en permanence). Ça fait du monde à visiter !

Il y a donc encore mieux que ça.
De nos jours, il y a des robots qui scrutent Internet à la recherche d'objets connectés.
Si par exemple, un hacker a remarqué une faille de sécurité sur une version donnée dur serveur FTP "proftpd" grâce à
https://nvd.nist.gov/view/vuln/search-results?query=proftpd&search_type=all&cves=on

Il lui suffit alors de regarder sur une des listes d'objets connectés du Web, comme https://www.shodan.io/search?query=proftpd et de faire son marché
C'est un peu flippant...

Injections SQL

Un peu de SQL pour comprendre le problème. C'est entre autres un langage de script qui permet d'envoyer des commandes à un serveur de base de données (database) utilisé encore massivement pour stocker des données et y accéder de manière rapide.
On peut voir ça comme un gros tableau avec des colonnes et des lignes. Les colonnes sont les champs stockés (par exemple 'Nom', 'Date de naissance', 'Email', etc.) et chaque ligne est une entrée avec des valeurs bien définies.
Un serveur de base de données (comme MySQL) comprend et interprète des commandes comme INSERT, SELECT, DELETE etc.



C'est avec ça que les développeurs sauvegardent les données utilisateurs grâce à une interaction déclenchée par l'utilisateur.
En principe, si sa configuration est bien faite, il ne répond qu'aux requêtes locales (localhost) et ignore ce qui vient de l'extérieur.
Cool, donc on ne peut pas le pirater !
Si malheureusement...

Imaginons que l'interface utilisateur permettent de chercher par utilisateur. Dans l'interface, il y aura un champ texte dans lequel on peut mettre par exemple 'Mike Lorri'.
De manière interne, le développeur naïf qui reçoit l'information va construire une requête SQL pour chercher dans la base. Par exemple, en PHP

Code:

$request = "SELECT * FROM user_accounts WHERE firstname='$name'"

Ce qui va se transformer en la requête SQL

Code:

SELECT * FROM user_accounts WHERE firstname='Mike Lorri';

Là, tout va bien.
Maintenant que se passe-t-il si une personne mal intentionnée passe par ici ?
Elle sait qu'on peut avoir plusieurs commandes sur la même ligne en les séparant avec ;
Elle va essayer de mettre dans le champ texte la valeur brute :

Code:

'; DROP TABLE user_accounts; --

Ce qui va se transformer en la requête SQL :

Code:

SELECT * FROM user_accounts WHERE firstname=''; DROP TABLE user_accounts; --'

MySQL va comprendre deux commandes à exécuter plus un commentaire à ignorer

• SELECT * FROM user_accounts WHERE firstname='' : qui ne renvoie aucun résultat, cette commande étant juste rendue caduque astucieusement
  
• DROP TABLE user_accounts : qui efface la table (à supposer qu'il ait trouvé un moyen de trouver le nom de la table par ailleurs)
  
• un commentaire --' qui est simplement ignoré, mais nécessaire pour que l'ensemble soit valide
  

Stauk a fait tourner une image qui illustre ça :


Ça peut être ce genre de choses qui mène à des fuites de données massives, car au lieu de supprimer la base, le hacker peut mettre

Code:

' OR 1=1; --

Et là, la condition WHERE devient toujours réalisée. Le résultat contiendra toutes les entrées possibles. Le hacker aura donc tous les comptes et pas seulement celui avec son nom.
Voir ce lien pour des exemples autour des injections SQL

Reverse engineering sur des patchs de sécurité officiels

Suis-je protégé derrière une machine virtuelle ?

FIXME:
- os invité avec VirtualBox/vmWare
- exploits qui traversent les machines virtuelles

.

Salut ortolan, comment ça va
Dans le second message, ça va être un peu le fourre-tout comme d'habitude donc n'hésite pas à donner des astuces ou des liens. Ça m'aidera sans doute en plus à prendre une direction comme c'est vaste cette affaire. Je crois me rappeler que certaines bonnes pratiques pour les utilisateurs avaient été évoquées ci et là sur le forum (comme la construction de mots de passe difficiles à partir des premières lettres de chaque mot d'une phrase, y compris sa ponctuation). Si quelqu'un a gardé les liens, qu'il n'hésite pas à faire tourner.
À suivre,

https://www.kaspersky.fr/blog/vulnerabilite-bash/3718/

euh, 26 sep 2014 !


?!

(pour ceux qui suivent le fil, le second message a pas mal bougé. Prochain étape, expliquer un crack simple + un peu d'assembleur)

@svt82 : j'ai pensé que le principe de la faille était intéressant. Désolé.

Salut Stauk, tu as bien fait Dans ce domaine, ce n'est pas parce que c'est vieux que ce n'est pas pertinent.
Je t'avoue que je n'ai pas encore regardé dans le détail, j'en suis seulement à tenter d'expliquer les bases qui permettront de mieux comprendre le reste. Mais ça viendra. À suivre !

(j'ai rajouté un exemple de crack simple)

(j'ai rajouté un exemple d'injection SQL dans un code sans sanitize input)

(j'ai ajouté 'Comment enregistrer l'activité du clavier et de la souris (keylogger) ?' et commencé 'Comment minimiser les risques ?')

(j'ai amélioré les sections 'Un exemple de crack simple' et 'Comment minimiser les risques ?')

J'ai aussi trouvé un exemple concret de Drive-by Attack dans le livre
Detection of Intrusions and Malware, and Vulnerability Assessment: 6th International Conference
2.2 An Example of a Real-World Drive-by Download (page 91)
(vue partielle)

parmi les attaques les plus sophistiquées de ces dernières années

https://fr.wikipedia.org/wiki/Stuxnet

"Le ver est capable de s'exécuter en trompant un processus du cœur de Windows (Ntdll.dll25), et en leurrant les anti-virus les plus connus. Il possède aussi des portions chiffrées qui interdisent toute lecture du virus non chargé en mémoire. Une particularité intéressante est qu'il ne s'attaque pas aux ordinateurs qui possèdent l'antivirus ETrust v5 et v6."

du coup on peut s’intéresser à Etrust

http://assiste.com.free.fr/p/logitheque/etrust.php

"Détection de virus performante : eTrust antivirus sait détecter 100 % des virus “en terrain inconnu”, et notamment les virus de secteur d’amorce, de secteur principal d’amorce, les virus résidant en mémoire, les virus fichiers multi-parties, les macro virus, les virus furtifs et les polymorphes. "

autant de failles de sécurité sur le topic actuel

en particulier les polymorphes, virus capable de se réécrire donc


https://fr.wikipedia.org/wiki/Virus_polymorphe

"les algorithmes ne sont pas modifiés, mais leur traduction en code-machine l'est."

"Mur antivirus : eTrust antivirus empêche les stations de travail d’infecter les serveurs de fichiers à l’occasion de la mise à jour de fichiers existants par une copie infectée. "

infection par mise à jour

par support aussi, donc y compris sur centrale nucléaire

https://www.malekal.com/virus-par-cle-usb/

on peut imaginer un drone survolant une centrale , captant ses fréquences et ses protocoles wifi s'ils existent et injectant un code via ce vecteur, on espère que la sécurité y a pensé aussi

https://www.futura-sciences.com/tech/actualites/technologie-virus-prolifere-via-reseau-wi-fi-52602/

http://www.clubic.com/smartphone/android/actualite-823324-androidos-switcher-virus-attaque-wi-fi.html

http://www.clubic.com/antivirus-securite-informatique/virus-hacker-piratage/piratage-informatique/actualite-837374-wifi-protection-wpa2-vulnerable.html

le code des cartes bancaires en puce moreno est quant à lui cassé depuis belle lurette si j'ai souvenir

mais bon parait qu'ils ont réécris

récemment aussi

https://fr.wikipedia.org/wiki/Cyberattaque_contre_TV5_Monde

" L'enquête indique que les pirates ont utilisé la technique de l'hameçonnage (ou phishing) en envoyant un e-mail fin janvier à l'ensemble des journalistes de la chaîne. Trois d'entre eux ont répondu, permettant aux hackers de pénétrer le réseau de la chaîne via un cheval de Troie. Trois semaines avant l'attaque, un virus informatique s'est propagé dans plusieurs ordinateurs, profitant d'une architecture informatique mélangeant la partie « métier » constituant le cœur de la chaîne et la partie bureautique ouverte sur l'extérieur via Internet. Les pirates auraient créé des comptes avec des droits d'administrateurs leur permettant de circuler là où ils le souhaitaient17,18."

on comprend rapidement que

"architecture informatique mélangeant la partie « métier » constituant le cœur de la chaîne et la partie bureautique ouverte sur l'extérieur via Internet"

est la source de la faille

cela implique une réflexion sur la sanctuarisation des données et leur mode de communication vers l'extérieur

ainsi que leurs backups

dans la série mister robot, conseillée par snowden , les serveurs de la multinationales sont sanctuarisés dans des bunkers et le hacker mister robot doit entrer physiquement dans le local , c'est l'idée de nombreux bunkers des grandes multinationales

mais faut bien aussi que les data sortent et rentrent, une connaissance approfondie et technique est donc requise pour ces actions là

en règle générale les pirates ont une connaissance approfondie des hardware et os et se documentent en permanence, parfois ce sont les codeurs même qui laissent des portes de derrières ou des failles plus ou moins volontairement, cela ne date pas d'aujourdhui, le film tron de disney et quelques autres au début de l'informatique moderne en causaient déjà

les oeufs de paques easter egg de pas mal de logiciels pouvaient servir de porte

chacun connait le simulateur de vol d'excel 1997

http://spenfen.free.fr/office/simul.htm

depuis c'est moins drôle

on attaque le composant le plus faible de la chaine, c'est souvent le même principe

mais... on peut aussi laisser béante de fausses failles.. pot de miel, pour attirer et controler

le fbi dans le temps et quelques autres laissaient les sites officiels us particulièrement vulnérables pour tracer les hackers et .. les recruter ?

lol

de nos jours la com est sans doute plus importante et plus personne ne joue à cela je suppose

et puis il y a le dark web.. mais il n'est pas si dark que cela pour tout le monde

mais là les connaissances et les compétences deviennent élevées voire hors de portée du commun des mortels

les failles facebook et réseaux sociaux sont légions

http://www.lefigaro.fr/secteur/high-tech/2016/03/09/32001-20160309ARTFIG00166-une-faille-de-facebook-permettait-de-penetrer-dans-n-importe-quel-compte.php

"Comme il l'explique sur son blog, dans un billet intitulé «Comment j'aurais pu pirater tous les comptes Facebook», le bug touchait le processus de réinitialisation de mot de passe. En temps normal, grâce au système de double authentification, Facebook envoie un code temporaire de six chiffres sur le smartphone de l'utilisateur. Après une dizaine d'essais erronés, le compte est bloqué."


ces mélanges de hardware et de com non sécurisées sont un paradis pour les hackers

le maillon faible est depuis quelques années le smartphone

qui donc n'a rien de smart

mais il y aura sans doute pire, les montres connectées sont le prochain challenge je suppose

https://www.watchgeneration.fr/montres-connectees/2017/10/severes-failles-de-securite-dans-plusieurs-montres-connectees-pour-enfants-7281

"Un malandrin peut ainsi pirater la Gator, suivre à la trace la localisation passée et actuelle de l'utilisateur — et donc connaitre son adresse personnelle —, il lui sera même possible de modifier les informations de contact et envoyer des messages vocaux. La SeTracker peut permettre à un pendard d'écouter en douce le porteur, et communiquer avec lui. Voilà qui fait froid dans le dos quand on sait que ces produits sont portés par des enfants…"

brave new world isn't ?

Merci Zeb
J'en ai profité pour faire une section 'Faux emails menant sur des vitrines présentant la même interface apparente (phishing)'

(j'ai ajouté des exemples concrets de liens HTML incohérents dans 'Faux emails menant sur des "vitrines" présentant la même interface apparente (phishing)' avec leur effet au niveau de l'URL dans le navigateur)

EDIT 20171227: Amélioration 'Exécution d'une procédure typique' + 'Comment corrompre le programme ?' + 'Autour de la pile d'exécution (callstack) et du retour de routine (instruction retq)'

Bon maintenant qu'on a débroussaillé, on va pouvoir commencer à mettre le nez dans le cambouis un peu !
Et ça risque d'être le joyeux merdier, je préfère ouvrir un autre message.

En l'état actuel, je pense que ce message va nécessiter certains prérequis pour être lisible :
- avoir un début de vision de la structure d'un programme compilé (sections heap/data)
- avoir un début de connaissance des instructions courantes en assembleur (nop/xor etc.)

Généralement, les shellcodes sont injectés dans la mémoire de l'ordinateur grâce à l'exploitation d'un dépassement de tampon (buffer overflow).

Dépassement de tampon (buffer/stack overflow)

Pour se rendre compte d'un buffer overflow ou d'un stack overflow, on doit redescendre proche de la machine.
Le plus simple est d'utiliser le langage C ou C++ comme ces langages ne protègent trop rien du tout dans la mémoire.
En tant que développeur, on peut quasiment faire tout ce qu'on veut (y compris inclure des bouts d'assembleur en plein milieu de son code si on joueur).

Mais, en particulier ce qui nous intéresse ici, c'est de mettre en évidence un overflow.
Prenons ce cas de figure en C :

Code:

int main()
{
  char buffer[100];
  int i = 0;

  while (i <= 100) {
    buffer[i++] = 0;
  }

  return 0;
}

La boucle a attaqué la pile (stack) à cause d'une étourderie dans le test du while. Il aurait fallu mettre soit 'while (i < 100)', soit 'while (i <= 99)'.
Total, le buffer[100] accède une zone en dehors de l'espace adressable réservé par le "char buffer[100];" qui ne peut être adressé que de 0 à 99.

Mais quel est le problème après tout ? Le problème est que, ce faisant, on a sans doute modifié une autre partie du programme, une variable par exemple.
Imaginons que cette variable est un pointeur (par exemple char* pPointeur), et qu'on accède au contenu dans une autre partie du programme via *pPointeur.
Si le pointeur est null (valeur 0) car on l'a écrasé en dépassant le buffer d'une façon similaire à l'exemple ci-dessus, on va tenter de ramener le contenu de l'adresse 0.
Dans les langages plus haut-niveau, ces erreurs sont en général masquées et on s'attrape une exception avec un texte qui explique qu'on a dépassé les bornes du tableau.
En C/C++, ça donne alors un segmentation fault (bien souvent aléatoire selon l'agencement de la mémoire) qui est une erreur très connue des développeurs, et le programme crashe. Éventuellement, il y a un core dump qui permet de retomber sur l'erreur à posteriori mais pour le joli message d'erreur, on repassera plus tard

FIXME: section data etc.

Exécution d'une procédure typique (push des paramètres et du contexte dans la pile + instruction pointer EIP)

Si on se place au niveau du processeur, on a vu qu'il exécutait des opcodes de manière séquentielle.
Un processeur dans son fonctionnement nominal est plutôt bête et méchant :

1. Il lit l'instruction en cours
   
2. Il obtient une longueur pour cette instruction (qui dépend de l'instruction, ça peut être 1 octet pour un NOP, 2 octets pour un JNE, ou plus pour d'autres) et met à jour le registre PC ('program counter') ou EIP ('instruction pointeur') pour avoir l'adresse de la prochaine instruction à exécuter
   
3. Il exécute l'instruction
   
4. Il se positionne sur la prochaine instruction grâce au registre de l'étape 2, puis il recommence à l'étape 1.
   

Si on n'avait que des instructions dont l'exécution durait un cycle d'horloge, il ferait cela à la fréquence du processeur soit 4 200 000 000 fois par seconde pour un core de processeur cadencé à 4.2Ghz.
En réalité, ça dépend des instructions. C'est pour cela qu'il y a un distinguo entre fréquence en GHz et MIPS.
Enfin là je ne connais pas bien, il faudrait que je regarde à l'occasion.
Mais à froid c'est plus côté électronique/architecture du CPU, et il y a des éléments de réponse dans un message d'un autre fil du forum (électronique).

Bref, ça c'est pour le fonctionnement très schématique du processeur.
Ensuite d'un point de vue pratique, si on regarde un programme en assembleur, on peut "retrouver" une certaine similitude avec ce qu'on aurait pu écrire en C.
Bien qu'en assembleur ce soit ultra linéaire, on peut y retrouver des routines (des fonctions) et quand elles ont terminées leur exécution, on revient d'où on avait sauté pour entrer dans la routine et on repart éventuellement ailleurs.

Réciproquement si on fait un programme très linéaire en C de sorte qu'il colle assez à l'assembleur, et qu'on regarde le déroulement d'un appel d'une fonction C en sa traduction assembleur, il y a du code "en plus" pour permettre d'automatiser une programmation fonctionnelle du processeur (c'est-à-dire "à base de fonction") telle qu'on en a l'habitude en C. Cela se fait en sauvegardant le contexte d'exécution dans la pile.

Lorsque l'on rentre dans une routine assembleur, en plus de pousser les paramètres etc. l'adresse de retour est sauvegardée dans la stack pour pouvoir revenir, et c'est justement masqué en C car on ne veut pas avoir à gérer ça (voir plus bas pour creuser un peu plus). C'est pour ça que les programmeurs adoraient le C quand ils venaient de l'assembleur...
Bye-bye la gestion des paramètres, la sauvegarde d'où on venait. C'est le compilateur qui gérait tous ces trucs méga chiants et répétitifs à leur place !

Mais si on fait de l'assembleur, on a besoin de ça car le processeur sait juste faire des sauts lui.
Si on ne regarde que le jeu d'instructions basiques (excepté les instructions MMX etc. qui font des choses suffisamment complexes pour être vues comme des fonctions), le processeur ne sait pas vraiment ce qu'est une fonction au sens où on l'entend en programmation.

Pour en revenir aux hackers, ils agissent habituellement sur l'adresse de retour.
Si un programme bouffe la stack, alors potentiellement, il peut altérer l'adresse de retour de sorte qu'elle pointe "ailleurs".
Si le hacker a réussi à injecter du code interprétable par le processeur, et qu'il a réussi à modifier l'adresse de retour en bouffant la stack de manière appropriée (en exploitant par exemple un buffer overflow dans du code mal protégé), alors en sortie de la fonction corrompue, l'instruction pointeur va alors sauter dans la zone mémoire injectée et exécuter le code indésirable, au lieu de retourner là où elle devrait.

Autour de la pile d'exécution (callstack) et du retour de routine (instruction retq)

https://en.wikipedia.org/wiki/Call_stack
https://www.recurse.com/blog/7-understanding-c-by-learning-assembly

Bon on a vu comment on fait des fonctions à partir du processeur. Maintenant, il faut regarder encore de plus près pour voir comment on peut corrompre la stack.
La pile sauvegarde en gros le contexte d'exécution d'une fonction appelée (avec ses variables etc.).
On parle de pile car on "empile" les données au fur et à mesure qu'on a besoin, puis à la fin on dépile.
C'est un peu difficile à se représenter car en mémoire la pile est à l'envers. Par exemple, si le main() par de l'adresse 0x1000, et qu'on rentre dans une fonction1() depuis main(), on va empiler un nouveau contexte mais en fait l'adresse du haut (top of stack) va diminuer. Et elle va encore diminuer si on appelle une fonction1a() depuis fonction1().

Ce qu'il faut comprendre, c'est que la pile d'exécution est inhérente à une exécution du programme (comme son nom l'indique).
Si pour une raison ou une autre on attaque/bouffe cette stack car on la fait plus haut, le programme a toutes les chances de planter à un moment.

Pour essayer de comprendre l'exécution normale d'un programme, essayons de regarder une fonction C 'dummyFunction()' qui ne fait rien d'autre qu'exister en gros :

Code:

void dummyFunction()
{
  char useless = 2;
}

int main()
{
  ...

  dummyFunction();

  ...
}

On la compile avec gcc sur une archi 64-bit (sans optimisation) et on regarde ce qui se passe avec gdb :

Code:

$ gdb testProgram
(gdb) b callingFunction:line
(gdb) set disassemble-next-line on
(gdb) r
17        dummyFunction();
=> 0x0000000100401123 <main+13>:        e8 b8 ff ff ff  callq  0x1004010e0 <dummyFunction>
(gdb) p {$rbp,$rsp}
$30 = {0xffffcbb0, 0xffffcb80}
(gdb) p/d (int)0xffffffb8
$25 = -72

(gdb) stepi
=> 0x00000001004010e0 <dummyFunction+0>:        55      push   %rbp
   0x00000001004010e1 <dummyFunction+1>:        48 89 e5        mov    %rsp,%rbp
   0x00000001004010e4 <dummyFunction+4>:        48 83 ec 10     sub    $0x10,%rsp

(gdb) nexti
0x00000001004010e1      2       {
   0x00000001004010e0 <dummyFunction+0>:        55      push   %rbp
=> 0x00000001004010e1 <dummyFunction+1>:        48 89 e5        mov    %rsp,%rbp
   0x00000001004010e4 <dummyFunction+4>:        48 83 ec 10     sub    $0x10,%rsp
(gdb) p {$rbp,$rsp}
$31 = {0xffffcbb0, 0xffffcb70}
(gdb) x/a ($sp +
0xffffcb78:     0x100401128 <main+18>

(gdb) nexti
   0x00000001004010e0 <dummyFunction+0>:        55      push   %rbp
   0x00000001004010e1 <dummyFunction+1>:        48 89 e5        mov    %rsp,%rbp
=> 0x00000001004010e4 <dummyFunction+4>:        48 83 ec 10     sub    $0x10,%rsp
(gdb) p {$rbp,$rsp}
$3 = {0xffffcb70, 0xffffcb70}


(gdb) nexti
3         char useless = 2;
=> 0x00000001004010e8 <dummyFunction+8>:        c6 45 ff 02     movb   $0x2,-0x1(%rbp)
(gdb) p {$rbp,$rsp}
$4 = {0xffffcb70, 0xffffcb60}

(gdb) nexti
4       }
=> 0x00000001004010ec <dummyFunction+12>:       90      nop
   0x00000001004010ed <dummyFunction+13>:       48 83 c4 10     add    $0x10,%rsp
   0x00000001004010f1 <dummyFunction+17>:       5d      pop    %rbp
   0x00000001004010f2 <dummyFunction+18>:       c3      retq
(gdb) x/b $rbp - 0x1
0xffffcb6f:     0x02


(gdb) nexti 3
0x00000001004010f2      4       }
   0x00000001004010ec <dummyFunction+12>:       90      nop
   0x00000001004010ed <dummyFunction+13>:       48 83 c4 10     add    $0x10,%rsp
   0x00000001004010f1 <dummyFunction+17>:       5d      pop    %rbp
=> 0x00000001004010f2 <dummyFunction+18>:       c3      retq
(gdb) p {$rbp,$rsp}
$8 = {0xffffcbb0, 0xffffcb78}
(gdb) p/a $rip
$15 = 0x1004010f2 <dummyFunction+18>
(gdb) x/a $sp
0xffffcb78:     0x100401128 <main+18>

On voit que le 'callq' sauvegarde l'adresse courante 0x100401128 dans la pile avant de sauter dans la fonction 'dummyFunction'.
Il prévoit de l'espace pour les variables locales (habituellement avec un multiple de 16 octets). Ici, on utilise seulement 1 octet sur les 16.
Puis, juste avant le 'retq' on est bien de nouveau aligné au niveau de la pile, ce qui fait qu'on revient bien d'où on est parti.

Comment corrompre le programme ?

Bon, je ne retrouve pas le schéma que j'avais mis de côté alors je me rabats sur celui de Wikipédia à défaut.
Voilà une représentation d'une stack


Attention, vu de la mémoire et comme on l'a vu plus haut, le haut de la stack se trouve dans les adresses basses par rapport au bas de la stack  
Donc l'adresse de retour ('Return Address') est situé dans une zone mémoire avec une adresse plus importante que celle des variables locales.

Vous me voyez arriver ?

Ça veut dire que si j'alloue un zone mémoire dans les variables locales (disons un tableau de 256caractères typiquement une chaîne de caractères C censée ne jamais dépasser 256 caractères, mais non protégée lors de la copie car personne n'ira jamais mettre un truc aussi long) et que je sors de mon buffer, je vais venir écraser l'adresse de retour.

Par exemple, si l'adresse de retour est claquée en 0x1008 par le callq, il y a la sauvegarde de l'ancien %rbp dessus dans la pile donc avant dans la mémoire, ici en 0x1000.
Puis commence l'espace pour les variables locales. Si on met un 'char buffer[256]', %rsp va passer à 0xF00 et on va pouvoir le remplir de 256 caractères de 0xF00 à 0xFFF.
Tout va bien si on met une chaîne plus petite que 256 caractères.
Par contre, si on met une chaîne de 256 + 8 + 8, en soignant les 8 derniers caractères, on va pouvoir assigner soi-même l'adresse de retour via ces 8 derniers caractères.
On va déporter le programme qui ne va pas revenir de son callq !
Si on a réussi à glisser du code parmi les 256 caractères d'avant. et si on provoque un JUMP sur cette zone alors on peut faire descendre le code que l'on veut dans cet ordinateur.
Ça y est, on a alors ouvert une brèche.
Qui pense à ça quand il programme ? Pfff personne ? On n'arrive déjà même pas à finir ce qui est demandé par le marketing à temps. Alors réfléchir aux trous de sécurité...

Pourquoi "ne rien faire" via des NOP (= No Operation) est-il si important ?

Alors on en arrive aux limites de ce que je connais et comprends actuellement.
J'ai vu que les shellcodes qui détournent le programme de son exécution optimale étaient souvent préfixés par des NOP.
Les NOP sont habituellement utilisées pour des problématiques d'ailgnement mémoire et d'optimisation mais ils ne font aucun tâche.
Le processeur comprend qu'il ne doit rien faire dans ce cycle et attend le suivant.

Comment donc peut-on s'en servir pour attaquer un système s'ils ne font rien ?

La première explication serait que si la payload du shellcode (la partie utile) est de x octets, et qu'il faut y octets pour provoquer l'overflow, on se retrouve avec un zone de y-x octets à combler.
On pourrait alors mettre du "padding" entre le début et la fin (soit y-x NOP).

Une autre explication serait que les hackers ne savent pas précisément modifier l'adresse de retour.
Alors, ils provoquent un très très gros overflow rempli d'instructions NOP avec ponctuellement des répétitions du shellcode par ci par là.
Si à un moment le processeur "tombe" dans un trou de NOP, il va dérouler les NOP jusqu'à rejoindre l'une des copies du shellcode insérées ponctuellement dans l'overflow.

Pourquoi des chaînes sans caractères nuls et seulement avec des caractères alphanumériques ?

Idem, je ne sais pas trop. Ça reste encore un peu flou et compliqué pour moi.
Je suspecte qu'il faut :

1. Éviter les \0 car tout à la fin se retrouve plus ou moins en C avec des strcpy qui s'arrêtent au premier caractères nul (c'est le marqueur de fin de chaîne de caractères en C)
   
2. Privilégier les caractères alphanumériques pour passer les filtrages des navigateurs qui gueulent si on met des chaînes avec des caractères qui ne sont pas alphanumérique
   

Si quelqu'un a des exemples pour comprendre, je prends !

(j'ai essayé de mettre à jour le message précédent 'Pourquoi "ne rien faire" via des NOP (= No Operation) est-il si important ?' mais j'avoue que je commence à arriver à mes limites là si quelqu'un connaît bien cette partie, qu'il hésite pas à prendre le relais surtout)

(j'ai mis à jour le message ci-dessus pour expliquer la callstack et la corruptibilité de celle-ci)

sur les attaques par buffer overflow

http://www.cse.scu.edu/~tschwarz/coen152_05/Lectures/BufferOverflow.html

exemple "récent"

https://www.acunetix.com/vulnerabilities/network/vulnerability/kaspersky-antivirus-buffer-overflow-vulnerability/

Merci Zeb, ton premier lien est vachement intéressant !
Ça démontre comment on force la pile pour sauter dans une fonction non appelée normalement.
Aussi il utilise printf sans argument pour dépiler la stack grâce au format de la chaîne, qui utilise normalement les n paramètres, et ça lui permet de dumper la stack. Malin, ça va me servir ça

Code:

printf("My stack looks like:\n%p\n%p\n%p\n%p\n%p\n% p\n\n");

Sinon j'ai extrait et essayé d'améliorer la liste des bonnes pratiques (dans le premier message).
Ortolan, si tu as des choses à ajouter (ou les autres), c'est le moment et je mettrai à jour ce premier message au fur et à mesure

(j'ai mis à jour la liste 'Comment minimiser les risques ?' du premier message)

Tiens, en passant, je crois me rappeler avoir vu passer sur le forum des recommandations pour un autre bloqueur qu'AdBlock (Kalthu ?).
Si quelqu'un retrouve le message, ou se rappelle du pourquoi, ça m'intéresse

@ stv82
piste : uBlock origin

Merci an.a.co.lu.the
Bon finalement soit c'était Fata dans ce message, soit c'était une autre personne mais le moteur de recherche merdique de phpBB veut le garder pour lui !

Bonjour,

Très bonnes explications et mesures !

J'ajouterais les suivantes, ce sont des mesures de base (j'espère ne pas créer de redondances):

Sauvegardes

Effectuer une sauvegarde régulière des documents en appliquant le principe suivant: avoir une copie des données stratégiques / vitales sur un support local et une sur un support distant, de façon à avoir au moins 3 emplacements.

Navigation

Pour Firefox et Chrome, installer le plugin suivant https://www.eff.org/https-everywhere afin de passer les requêtes en HTTPS sur les sites sécurisées

Mots de passe

Utiliser un gestionnaire de mot de passe. Chacun peut être amené à retenir 30, 50 ... 100 mots de passe différents. Difficile de les retenir tous. C'est le rôle du gestionnaire de mot de passe de stocker.
Je préfère celui-ci : KeePass/. Il n'est pas très pratique (pas de synchro native avec le cloud), mais relativement simple et robuste.

Créer une adresse jetable pour se connecter à des sites suspects. Par exemple yopmail.com. Pratique pour faire des tests aussi.

Si je suis motivé, je présenterai la faille XSS en détail ...

J'ai ajouté un lien sympa dont je me sers souvent pour tester des binaires/archive/URLs ou des zips vérolés que j'avais gardés pour analyse : https://www.virustotal.com
Sinon, je suis tombé sur un livre à la bibliothèque, et il est plutôt cool si vous êtes intéressés par l'inforensics :

Sécurité informatique et Malwares
Analyse des menaces et mise en oeuvre des contre-mesures (2e édition)
Paul RASCAGNERE

Il recense plein d'outils que j'ai mis plusieurs années à trouver en glandant à droite, à gauche.
Par exemple, Cuckoo Sandbox dont j'évoquais le fonctionnement plus haut sans me rappeler du nom.
Il y a même une version online de cet outil : https://malwr.com/

Ces outils finiront bien par émerger ici tôt ou tard mais si vous êtes impatients et que vous en avez l'occasion, donnez-lui une chance !

J'avais lu il y a quelques années un article sympa de Dr Goulu sur les nombres premiers :
https://www.drgoulu.com/2012/04/15/comment-produire-des-nombres-premiers/

La question qui me chiffonnait à l'époque était en somme la suivante :
Si la clé privée d'un chiffrement RSA c'est P*Q avec P et Q deux nombres premiers, cela signifie qu'on sait déterminer que P et Q sont premiers sur x bits. Qu'est-ce qui empêche alors de recenser tous les couples P et Q sur cette largeur de bits, de sorte de trouver toutes les clés privées possibles ?

En substance :
- On sait générer/construire un sous-ensemble de grands nombres premiers selon certaines règles. Mais l'ensemble des nombres premiers est énorme lui !
- Mais en revanche, si on nous donne un grand nombre, on ne sait pas le décomposer en nombres premiers facilement (enfin tant que les ordinateurs quantiques et l’algorithme de Shor ne sont pas utilisés)

Le corollaire de savoir générer de grands nombres par "certaines règles", c'est que si on est capable de prédire comment sont générés ces nombres P et Q lors de la création d'une nouvelle clé, on peut alors recenser ces différents couples P et Q et bye-bye le chiffrage !
Je crois que c'est arrivé il y a une dizaine d'années avec le serveur Linux openssh, toutes les clés étaient caduques il me semble.

Sinon pour revenir au chiffrage, Dr Goulu a fait le boulot de prolonger :
- sur le chiffrement HTTPS : https://www.drgoulu.com/2017/01/11/drgoulu-com-passe-en-https/
- sur les clés asymétriques type RSA : https://www.drgoulu.com/2017/02/15/alice-et-bob-et-les-cles-asymetriques/
- sur l'attaque man in the middle : https://www.drgoulu.com/2017/11/20/alice-bob-et-lhomme-du-milieu/

Super intéressant !

rainbow table, c'est ce que tu cherches

En passant avant d'oublier, une vidéo de ScienceÉtonnante où il parle de l'algo de Shor, des cryptages basés sur des grands nombres premiers.

Les Ordinateurs Quantiques:

Salut,

stv82 a écrit:

quand je vois un post traitant de la sécurité, qui en une image, nous montre :
- windaube
- IE
- gogole

je rigole...

.

ortolan a écrit:Plutôt que la moquerie, il faut privilégier les infos pertinentes et utiles à visée pédagogique amenant les utilisateurs à mieux se protéger.

Certes, c'était sans doutes maladroit.

ortolan a écrit:
Mais ça me paraît important d'amener les utilisateurs à réaliser cette transition (hygiène numérique, politique de sécurité renforcée en matière de données et d'usage d'internet) à leur rythme pour que l'informatique un peu plus poussée ne soit pas réservée à une pseudo-élite qui pourrait vite être perçue comme méprisante.

Je pense que ça fait quelques années maintenant qu'on n'a plus à compiler son kernel pour avoir un linux fonctionnel. Au contraire je trouve meme son installation devenue encore plus simple que macos ou windaube...
Ceux qui restent sous windaube sont soit méconnaissant de ce qu'il se fait à coté, soit fainéant. Dans le second cas, qu'ils se débrouillent (perso je ne mets plus les mains sur un windows, peu importe ce que l'on me demande ou à qui il est).

.

On a visiblement le meme point de vue. J'ai arreté d'y toucher depuis millenium (haaa, la FAT16, sesdisques durs qui claquent sans prévenir, etc.) , retourné de temps en temps sousXP, et définitivement arreté à l'arrivée de vista (qui en plus avaient le bon gout d'avoir copié les sources de XGL, à l'époque le moteur de bureau 3D qui venait d'etre fait sous nux, sauf que forcément, meme en copiant/collant du code, ils ont pas été foutu de faire un truc qui marche sans trop ramer).

.

Initialement XGL était fait pour tourner avec l'openGL, et comme ils ne savaient pas faire... ben voilà

Pour répondre à hobb, j'ai souvent pris les premières images qui passaient par là pour illustrer le fonctionnement de tel ou tel truc.

Je crois que j'ai été clair sur IE :

Sous Windows, éviter avec force et conviction d'utiliser le navigateur 'Internet Explorer' ou alors si vraiment mais vraiment ce n'est pas possible, au moins désactiver les composants ActiveX.

IE c'est le pire des logiciels... Chaque année
Après, y-a des vieux trucs (genre routeurs) qu'on ne peut configurer qu'avec cette cochonnerie.
Je n'ai pas retrouvé de graphes plus récents que ceux de 2014 sur NVD
Mais voilà ce que ça donnait à l'époque



J'ai trouvé ça de 2016 mais je ne sais pas la source

https://heimdalsecurity.com/blog/most-vulnerable-software-2016/

L'argument "Je suis sous Linux, donc il peut rien m'arriver" est pour moi fallacieux.
Il y a des vulnérabilités. Des grosses parfois. Après, toutes ne sont pas exploitées. Peu le sont sous Linux.
Comme dit ortolan, les hackers ne sont pas bêtes, ils vont pas s'emmerder à viser un Linux alors que 90% des proies sont sur Windows. Donc, ils ciblent majoritairement du Windows.
De nos jours, tu as du code cross plateforme dans Firefox par exemple (moteur javascript etc.).
On peut très bien se faire piéger même sans ça d'ailleurs.
Un service avec un utilisateur (genre un apache avec user:group www-data) ayant trop de droits sur ton système, devient une porte d'entrée.
Un ajout de repo distant parce qu'on a pas envie de s'emmerder à recompiler un truc qu'un autre zozo met à dispo.
Si un hacker est malin, il targette ce qu'il veut.
Ça peut aller vite... Dire que Linux est mieux est pour moi à nuancer.
Clairement, actuellement, oui c'est le cas mais est-ce que ça durera dans le temps si Linux devient plus populaire ?

Personnellement, je me suis déjà mangé un rootkit sur un de mes Linux, alors que j'essaie de faire gaffe.
Alors, je me garderais bien de déifier à outrance la fée Linux

stv82 a écrit:
L'argument "Je suis sous Linux, donc il peut rien m'arriver" est pour moi fallacieux.

Complètement d'accord. J'ai la flemme de chercher, mais des distros de nux (par mi les plus populaires) ne sont pas sur le graphique, je présume que mint et ubuntu  sont sensiblement identiques entre elles  (puisque ce sont les memes dépots) ?

.

.

Joli pavé NOP. Je ne crois pas que ceux qui n'y connaissent rien t'aient compris, et pour les autres tu n'apprends rien.
De toute façon ça sert à quoi la sécurité ? Tu passes dans la rue, quelqu'un a garé sa voiture fenêtres ouvertes, est-ce pour ça que tu vas la voler ?

.

Chez certains hackers pirates il y a une volonté de perfection qui me semble liée à pas mal de mépris en fait : Montrer aux autres qu'ils sont nuls, car on ressent cela vis à vis de soi, que si on n'est pas exceptionnel on n'est rien. Tu es totalement méprisable si tu n'es pas génial mon fils (
Et je trouve ça super triste.