Schneier on Security

Clive Robinson • August 25, 2022 9:31 AM

@ ALL,

The ARS article written by Dan Goodin, as well as some of the comments are “barking up the wrong tree” when it comes to a solution to this vulnarability.

For instance look for,

“I’m David Turner, Director of Standards Development at the FIDO Alliance. I think I can answer your question.”

He then goes on to only talk about how a 2FA token will make setting up the “man in the middle” harder. That is make the “connection” harder not the “transaction” vulnerability which remains unchanged…

So it in no way solves the real problem which remains at Microsoft’s servers…

To see why, if I put a “Man in the middle” attack on a network router either just upstream of you or the cloud server then I can still get at the “transaction ticket” so can make the attack work again…

The only solution that will work is as I’ve said for decades now,

“Authenticate the transaction.”

Which has to be done on Microsft’s servers.

The reason nobody is talking about it is probably because it is a hard problem to solve with our current technology design and usage.

Worse any solution will have serious “privacy” implications. Which might be acceptable to your employers managment.

But what about your “Privacy” as an individual?

Oh and remember if you read inbetween the lines a little, you can be set up for all sorts of crimes and be blackmailed.

For instance an early form of blackmail attack was to hide some sexualy explicit if not criminal images on your harddrive, then demand money…

This attack as the ARS and Microsoft articles mention alows the attacker to hide received Emails marked as read on your account. That is the attacker can send you stuff from a highly questionable sexplotation site and make it look like you’ve not just read them but viewed the images repeatedly as well…

Just one of very many ways you can be attacked via cloud services where,

“Transactions are not correctly authenticated.”

And people wonder why I don’t have Social Media, Email or similar and don’t use cloud based services…

Clive Robinson • August 25, 2022 11:20 AM

@ Matt,

You have a question and an insult…

To answer your question of,

“Think you could provide an actual practical solution suggestion”

I already have on this back in the late 1990’s, and have mentioned it before on this blog repeatedly, including how one attempt trying not to use a token device failed[1].

What you need is an “authentication chain” that includes,

1, The human.
2, A Token.

The token generates a session sensitive continuously changing authentication token rather than Microsoft’s pointless session independent fixed token.

To include the human in the chain you have to provide a positive action on their input, that has minimal load on them.

One way to start addressing this problem is to seperate the user interface devices (keyboard, screen etc) from the communications interface device (computer) and have the transaction authentication token sit between them.

The nearest we have in moderate usage so far is keyboards with Smart Card interfaces where the key presses are encrypted through the smart card. The trouble is it generally is only used to authenticate a login which is back to authenticating the connection, not the individual transactions.

Extending it to include the transactions could be relatively trivial but secure once the token has been properly placed in the chain.

I hope that answers your question?

P.S. As for your insult, you do not need to insult me for me to give you an answer just a polite enquiry is usually more than sufficient. Also when you think about it, many other readers here know that. So in effect you are diminishing your own standing in their eyes, not mine.

[1] The reason we need a token is the failing of the human mind, which was never designed for such activities. Very few of us can remember even a “weak password” by modern attack standards. As for calculating hashes and checking them in our heads… So I looked for something humans were reasonably adept at that computers were not. Back then “captcha” systems were new and computer image recognition poor, so it looked like a potential way out of having to use a token. What I had not reconed on was in effect “slave usage” of the human mind as a “mechanical turk”. It was economically viable to sit a person infront of a computer in China and forward the captcha image to them and have them solve it in near real time. These days computer image recognition is more than sufficient for the original captcha images. I suspect it’s also now sufficient for the likes of Googles reCAPTCHA images as well.

Clive Robinson • August 25, 2022 5:25 PM

@ AlanS,

Re : trandaction authentication

“On Bank of America’s site the security key isn’t just for login but also some transactions after you are logged in.”

All authentication processes can be used over and over again. Obviously something that is data visable to an attacker is effectively worthless. Which is what the MITM Attack does.

Worse if the authenticating token is
invarient and not tied to the data as is the case with Microsoft’s system, then an attacker can just jump in when a sessionless protocol like HTTP(S) is used.

But transaction level authentication has to be supported correctly by the server. Microsoft does not do this.

The simplest way to do primative authenticate of all transactions in the communications channel is to use nested encryption channels,

1, Authenticate the outer channel using what ever 2FA system you have.
2, Then use a “shared secret” to make a new unique encryption key and initialisation vector pair.
3, Set up a CBC encrypted communications channel inside the outer channel and send one or more “numbers used once”(nonces) down it.

Provided,

A, Shared secret is never disclosed.
B, Key and IV generation process is secure.
C, Client and server are secure.

Any MITM attack fails as you switch to using the inner encrypted channel after step 3.

But the reality is the encryption is not authenticating transactions but the communications within a communications channel[1] In effect it is authenticating all traffic but weakly as it is vulnerable to certain attacks so is not as strong as it could be.

The service provider needs to decide what a single transaction is and additionally use crypto hashes as part of “Secure Transaction Authentication Codes”(STACs) for each one.

Whilst it can be hard to get your head around a written description, making a drawing of it usually makes understanding easy.

[1] language can be fun… A “communications channel” carries “communications” in exactly the same way a “water pipe” carries “water”. But it should be obvious a “water pipe” is not “water”. Only as a communications channel actually is an information carrier you can nest communications channels inside other communications channels as many deep as you like.

Clive Robinson • August 26, 2022 4:22 AM

@ Ted,

Re : Suggestions ar not solutions.

“Microsoft seems to offer a plethora of mitigation suggestions.”

But what do they mitigate?

Currently our entire security struccture rests on the notion of “shared secrets” also called a “root of trust”.

Authentication between two parties when analysed is a multi-step process.

Anything prior to the correct use of a shared secret is vulnerable to a variety of “man in the middle attacks”.

Security even after the correct use of a shared secret is at best only ever conditional.

One issue is obviously the shared secret becoming known in some way.

One way is for the plaintext of the shared secret to become visable to an attacker.

Back in the very early days of networking the Telnet protocol was used. This was a plaintext protocol therefore the users “username” and “password” were seen as plaintext on the wire.

Later the VNC protocol used DES encryption. But whilst the plaintext was nolonger directly visable on the wire the VNC prorocol used the same embedded crypto key. So even though the plaintext was not on the wire it was trivially recoverable.

People changed VNC to alow the crypto key to be changed, but this is a difficult problem to solve with a gotcha in it.

A multiuser system has no way to know who is connecting to the system untill they securely identify themselves. Thus this first step has no shared secret and is vulnerable to a man in the middle attack and is not secure by definition.

How do you establish a secure connection. Well one way is with a game of encryption ping pong.

In the simplest case anyone can claim to be jo1234 but if jo1234 and the system share a secret then that can be established by a challenge and response protocol. Lets assume the shared secret is used as an encryption key. The system encrypts a piece of plaintext and sends it to the user as a challenge. The user decrypts the challenge and performs some transform on it and returns it to the system as a response. If it’s returned as plaintext then an evesdropper can see it and over time work out any correlation such as if the server only has a repertoire of say six different challenges for the user. But the same applies even with an encrypted response if the encryption is used incorrectly (as it often has been).

But also consider another issue that of temporal divides. If you were using a plaintext protocol or weak ciphertext protocol then switch to a strong protocal later, but do not change the shared secret at the same time… Then an attacker can carry forward the fact that they know the shared secret even though the strong protocol would stop them finding it.

I could go on with a long long list of such issues but I think I’ve made the point that they are there in great number and some can be not immediately obviouse.

Now remember a mitigation is not a solution, but a work around. As a general case a mitigation only works around a single instance of a vulnarability, not a class of vulnarabilities or multiple classes of vulnerabilities.

As I pointed out there are two known vulnarabilities in this attack,

1, Man in the middle
2, Invarient token

Both are actually “class vulnarabilities” with an unknown number of attack instances possible.

Mitigating one instance of just one class is not going to solve the problem.

You need correct solutions to both classes of vulnarability.