Hello and welcome to the Monday, October 31st, 2020 edition of the Sansonet Storm Centers.

Stormcast, my name is Johannes Ulrich, and I'm recording from Jacksonville, Florida.

Multi-factor authentication is, well, certainly a must these days for cloud services like Office 365.

But recently, well, multifactor authentication, so we've got some kinks in its armor because attackers have tricked victims into approving authentication requests from multifactor authentication apps by essentially just flooding the victim with requests.

Tom now wrote up how to protect yourself against these types of attacks if you're using dual securities authentication app to log into Office 365.

One pretty obvious method is not to allow the simple push authentication method where the user

just has to press OK instead.

The user will have to use a one-time code to authenticate.

This can be enabled by only allowing a code authentication to be used with Office 365.

A little bit in between, kind of of the simple app push and the one-time code option is also

a verified push.

What this really means is that when the user logs in, the system will display a number to them,

and then they have to enter that number into the app in addition to approving the login.

Of course, the victim wouldn't really see a number that's being displayed to the

attacker, so that flooding with bogus requests wouldn't really work quite well in this case.

But anyway, if that's something you're interested in, take a look at Tom's Diary from Friday.

And back in September, Microsoft fixed an interesting vulnerability in the Windows TCP IP stack.

The vulnerability allows for remote code execution using a fragmented IPSEC packet that's transmitted over IPV6.

At that time, it wasn't really clear sort of what exact combinations of features could lead to exploitation.

Newman Cyberlapse now reversed the patch and released a blog post with details about the vulnerability and how to potentially exploit it.

The exploit requires that the attacker sends an IPV6 packet with IPVSEC payload, and then that IPSEC payload is actually then fragmented.

The proof-of-con concept exploit causes a crash and not

...