Threats related to multi-factor authentication… and some multi-factor baking

A while back I stumbled upon a few recipes that had both baking soda and baking powder in them. Typically, you use just either-or. Immediately I thought about multi-factor authentication. Similar to having several factors to authenticate that it is you, you have several raising agents in your pastry!

What is multi-factor authentication?

The traditional way to authenticate is to type in username and password. The password is something that only you are supposed to know. Because the username and password can be guessed, leaked in data breaches, or gained with phishing, this is not a very secure method.

We can add more factors to authentication to make it more secure. In addition to something you know, we can demand that you show proof of something you have: your phone, for example. As almost everyone has a phone now, sending an additional authentication code as a text message is popular. You can also have separate authenticator devices.  

A woman entering the multi-factor authentication code from her mobile phone to her tablet. Illustration from Freepik.
The multi-factor authentication code coming to your MFA app or as an SMS adds an extra authentication layer. However, MFA is not flawless and it can be bypassed. In addition, MFA apps may have availability issues. Computer vector created by stories – www.freepik.com

Now we have multiple factors: something you know and something you have. This is called multi-factor authentication (MFA). Biometric authentication, such as fingerprint scan or retina scan, checks something you are. 

Note that sometimes MFA is referred to as two-factor authentication (2FA). I don’t typically use this term because the original approach, username, and password, already has two factors. But it depends on your viewpoint. If you consider the username public or already known information, then the extra verification code is indeed the second factor. But let’s not split hairs, I’ll just call this extra authentication layer MFA from now on in this article. 

How cybercriminals bypass multi-factor authentication

Multi-factor authentication can prevent someone from getting into your account if you get phished or your password leaks from a data breach of a poorly secured site. However, multi-factor authentication is not perfect. Let’s look at some attacks against MFA.

Phishing MFA codes live. Cybercriminals know that several users are using MFA so they take that into account when creating phishing sites. They add a convincing-looking step to ask for your MFA code, and because they are simultaneously entering your phished credentials to the actual site, you will get the code into your phone or MFA app. When you enter the MFA code to the phishing site, the criminals quickly enter the code to the real site as well. Multi-factor authentication was successfully bypassed. There are ready-made MFA phishing tools, such as Modlishka, that act as a man-in-the-middle proxy to perform

Social engineering MFA codes. The cybercriminal might pose as an acquaintance and politely ask you to send them the code you ‘accidentally’ received. This type of scam has been seen at least with WhatsApp.

Abusing application trust. If certain apps are allowed to bypass MFA, for example with an application-specific password, that trust can be abused. In an attack described by ThreatPost in 2020, the cybercriminals lure the victims to grant permissions to a malicious app that can bypass multi-factor authentication.

Exploiting authentication vulnerabilities. Vulnerabilities in the authentication protocol or implementation might allow attackers to bypass multi-factor authentication. For example, weaknesses in WS-Trust can allow bypassing MFA to get access to Microsoft 365 or other Microsoft-provided cloud services. The vulnerabilities are explained in detail in the SecureCloudBlog from 2019 and the Proofpoint blog from 2020.

Pass-the-cookie attacks. After you have successfully authenticated with MFA, you can use the application without entering any credentials for a while as long as the session is valid. Some cloud services also offer a “Stay logged in” option so you don’t need to re-authenticate so often. The session information is usually stored in a cookie on your computer. If an attacker can get hold of that cookie, for example by tricking you to install an info-stealing malware that steals the cookie, and puts it in their browser, they can effectively browse the application as you. The pass-the-cookie attack is explained step by step in the Stealthbits blog.  

SIM swapping. In a SIM swapping attack, the attacker persuades a mobile phone provider to switch a phone number to a new SIM card. The criminal can use details gathered from social media and other online sources, data leaks, and phishing to convince the customer service. The pretext for switching the SIM can be that your phone was lost or that your new phone needs a different size of SIM card. 

In February 2021, Europol arrested several criminals that had been doing a series of SIM swapping attacks against thousands of victims in the United States. The attackers were able to steal money and personal information, post social media content and send messages impersonating the victims. The criminals also hijacked social media accounts to post content and send messages masquerading as the victim.

Also in February 2021, the telecommunications provider T-Mobile disclosed that they had been a victim of a data breach after an unknown number of SIM swap attacks. The attackers may have accessed personal information including home and email addresses, account security questions, date of birth, and social security numbers.

Number porting. As an alternative to SIM swapping, the criminal can open a new mobile phone subscription impersonating the victim and ask to port the old phone number to the new operator. At least in Finland, in my experience, switching mobile operators take such a long time and you will get notifications about the porting as SMS, so I see this is an unlikely attack method. However, I’m not sure that how fast number porting is in other countries. It can be much faster especially if you claim that the previous SIM is lost.

SIM swapping and number porting attacks, in my opinion, reveal a problem in the level of trust that several customer service desk put in knowing some details, such as a home address, phone number, and personal identity code or social security number, to verify your identity. However, none of this information is secret so it should not be treated as something that only the person in question will know! These attacks should not be so easy. 

The caveat of MFA apps

In the light of phishing SMS codes and SIM porting attacks, it seems wise to use MFA apps, that will show the code you need to type or prompt you to accept or reject the new connection. However, there are some caveats in this approach: backups of the MFA app.

  • Losing your phone. If your phone gets lost or stolen, there goes the MFA application (and the possibility to receive SMS messages, at least temporarily).
  • Resetting your phone. If you need to reset your phone, for example, because you forget the security code, all data in the MFA app is lost.
  • Switching to a new phone. For security reasons, some MFA apps don’t allow including the app data into the phone backup, so you cannot restore the content when switching to a new phone.

I’ve lost access to one MFA-protected account myself once when I was switching phones and I did not realize this before it was too late. Depending on the account, getting access back ranges from a minor annoyance to nearly impossible.

Some MFA apps have a backup feature or they have multi-device support, so you can circumvent the problems listed above. Another option is to print backup codes and store them in a secure place so you can use them in case the MFA app does not work or you cannot get SMS messages due to network problems. Obviously, you need to remember where you stored the backup codes if you would ever need them. Another thing to keep in mind is that if an attacker can get hold of your backup codes, they can also use them!

Multi-factor baking: Irish soda bread

One of my dearest baking books is Maailman ihanimmat leivonnaiset (translates to World’s loveliest baked goods) published by Gummerus. The book takes you on a tasty world tour with easy baking recipes around the world, both salty and sweet. From Ireland the book introduces soda bread which fits the multi-factor authentication theme quite nicely: firstly, the recipe uses multiple raising agents, baking soda, and baking powder. Secondly, it bypasses the slower way of making bread with yeast. Perfect!

Home-made Irish soda bread fresh from the oven and wrapped in a kitchen cloth.
Home-made Irish soda bread straight from the oven.

To make soda bread, you’ll need:

  • 5 dl wheat flour
  • 4-5 dl graham flour (I used bread flour)
  • 2 tsp sugar
  • 1,5 tsp salt
  • 1,5 tsp baking powder
  • 1 tsp baking soda
  • (2 tsp caraway seeds; these are optional in the original recipe and I left them out)
  • (1 dl raisins)
  • 4 dl buttermilk (I used non-fat buttermilk)
  • 2 eggs
  • 2 tbsp melted butter (I used canola oil instead)

Search engines find plenty of soda bread recipes with small variations. Some of them have eggs and some of them don’t so that’s also an optional ingredient like raisins.

Heat the oven to 200 degrees. Mix all the dry ingredients in a bow. Add buttermilk, eggs, and the melted butter, and mix the dough quickly by hand. Tip the dough onto a floured surface and into a round loaf of bread. Place the bread onto a baking tray with paper. Use a sharp knife to cut a cross to the dough. Bake for 30-40 minutes. The book says that the bread is ready if there’s a hollow sound when tapped on the bottom. Wrap the soda bread inside a kitchen cloth and let it cool down for a while.

Soda bread is best as freshly baked and hot. And while you’re munching that yummy bread, you can double-check that you have alternative MFA methods, such as printed backup codes or an MFA app with multi-device support, so you don’t create a denial of service condition for yourself!

What do vulnerabilities and bread rolls have in common?

Recently I was going through the results of a Software Composition Analysis (SCA) scan of an application. While trying to figure out whether the reported vulnerabilities were relevant findings or false positives, it reminded me of bread rolls. Sounds odd? Well, let me explain.

Dependencies are like seeds in bread

I bake bread rolls pretty often. They are easy to make, the ingredients are so simple that I almost always have them in my kitchen cupboard, and it feels cozy to have warm bread just out of the oven for an afternoon snack. However, baking plain rolls can get a bit boring, so I often try to add a twist: adding some seeds, nuts, malt, or grated carrots brings a new kind of flavor.

Libraries in an application are like seeds in a bread roll. They are an inseparable part of the product. If the seeds are stale, the rolls might taste funny. The same goes with the libraries: if the libraries contain vulnerabilities, the application can be vulnerable, too. 

Not all vulnerabilities in dependencies are problematic

There’s a twist with vulnerable components. For example, some of the components that your source code includes are only used for testing and development. These dev or test dependencies will not be a part of the actual product, so you don’t have to mind about the vulnerabilities in these. 

Some of the libraries are direct dependencies of the application, so the application is using the functionality provided by these. In most cases, you should just update the library to get that vulnerability fixed. If updating is not possible (due to incompatibility issues or updating would require a service break that you cannot afford to have right now) you can try to examine if the vulnerable method is actually used by your application or try to have alternative means of protection, such as a web application firewall blocking exploit attempts.

Other libraries are transitive, meaning that they are not directly used by your application, but some of the libraries you directly include are using their functionality. The chain of dependencies can get quite long. Transitive libraries can induce vulnerabilities into your application, too. However, it can be difficult to check whether the vulnerable code in a transitive library is actually used by your app and end up in the product. At least it requires extensive knowledge about the application functionality. Another problem is that typically you cannot just go and update the transitive libraries on your own – you need to update the direct libraries to a version that will use the fixed new version of the transitive library. 

Let’s compare dependencies and baking

If we go back to the bread rolls and baking analogy, these are the dependency types:

  • Direct dependencies
    • Flour
    • Seeds
    • Yeast
    • Water
  • Transitive dependencies
    • Air (formed by yeast when it splits sugars, causing the dough to rise) 
    • The viscous and elastic mass formed by gluten proteins when you mix the dough enough
  • Testing dependencies
    • A cocktail stick to check if the pastry is done
  • Development dependencies
    • Baking bowl to mix the ingredients
    • Mixer or a large spoon
  • Compilation dependencies
    • Oven
    • Electricity
    • Baking paper
    • Baking tray
  • Runtime dependencies
    • Knife
    • Butter to spread on the ready rolls

Let’s bake some bread rolls!

If you need some time to chew over the dependency problem, you can bake some bread rolls in the meantime. You’ll need

  • 2 dl of oatmeal (rolled oats)
  • 1 bag of dry yeast (around 11 g)
  • 5 dl of water
  • 2 tbsp of syrup (you can also use honey)
  • 0,5-1 tsp salt
  • 9 dl of bread flour (mine included wheat flour, wheat groats, dark wheat flour, and rye flour)
  • 1 dl seed mix (mine had sunflower seeds, pumpkin seeds, pine seeds, and cranberries)
  • 0,5 dl cooking oil (I used canola oil but you can also use e.g. rapeseed oil)I

Measure the oatmeal and dry yeast in a baking bowl. Heat the water into 42 ºC and pour it over into the bowl. Mix. Add syrup and salt. Add the flour in small batches and mix well with a mixer with dough hooks (you can also use a spoon and later knead it with your hands). Add the seed mix, oil, and the rest of the flour and mix until the dough does not stick into the dough hooks anymore. Depending on the type of flour, you may need to add some extra flour.

Let the dough rise in a warm place until the size has approximately doubled. I tend to put the baking bowl inside a loosely closed clean plastic bag and put the whole thing inside the microwave oven (don’t put the microwave on, though). Raising the dough takes around 50-60 minutes.

Tip the dough onto a floured surface and roll into a baguette-type shape. Cut the dough in halves and roll into two even baguettes. Divide the rolls into 18-24 pieces and roll them into tiny balls. Place the balls onto a baking tray with paper and leave some room for rising. Cover the bread rolls with a cloth and let them rise for 20-30 minutes. You can pt

Heat the oven to 210 ºC (if you have a convection oven) and bake for 10 minutes. If you have a regular oven, use 225 ºC and bake for 12-15 minutes. If you are unsure, check that the bread rolls are done by inserting a cocktail stick or a toothpick into the bread roll. If there’s some dough on the toothpick, put the rolls back to the oven.

Let the bread rolls cool for a while. Enjoy with some butter and hot tea!

Fresh home-made bread rolls with oatmeal and seeds. Yum

While munching on those bread rolls, you can read more about the subject from the following links:

Introducing Bake Security In

Baking and cybersecurity go together like bread goes with butter.

I work in cybersecurity and I’m especially into in product security and cybersecurity awareness. My background is in software testing and I’ve always been good at breaking stuff. However, traditional security testing comes late in the software development process. That’s why it’s better to have application security it’s baked into the software from the beginning and it should be included into the development processes. 

I also like baking so I thought that why not – let’s combine information security and baking! So begins Bake Security In, a blog dedicated to cybersecurity and yummy baking recipes. 

My goal is to offer information, processes and tools that help you understand cybersecurity a bit better, detect potential security problems early and bake tasty cakes and bread. I welcome you to a tasty infosec journey with me!