Security Measures for "Login flow v2" ?

[githubkoma]

Dear Team,

i discovered Login flow v2

My Question is at the bottom :-)

Lets say, a phisher tries to use that API to initiate the Retrieval of an AppToken for UserXYZ, that is not himself.
curl -X POST https://demo2.nextcloud.com/index.php/login/v2
(-> Using demo2.nextcloud.com in this example, but it could be nextcloud.ImportantCompany.com as well)

The phisher gets back the following:
{"poll":{"token":"3cx8pDOb3QJfQJDZDo4WemN4cjQDIhV4YZZELxeL7Wm5qWiIyZkYnLbZnbyS4IdEEakvVYMqxY1PM6tFr3Paam2dOstOjarCX4NfxGGFUFOxzjDjziJFdgX2A8NKoRH","endpoint":"https:\/\/demo2.nextcloud.com\/index.php\/login\/v2\/poll"},"login":"https:\/\/demo2.nextcloud.com\/index.php\/login\/v2\/flow\/ve5rsdvyLkgPjMU8ozIDf2Q0YVpz3aEj98oKQ59N3SiAzrwP9Zi0Rm1kdjgcQgRoE0OL9s52im0cGAlAZ18QG0MX63k4pemHVlCShGZbFYI4AvRJ985bBavDsz0Lqc21s"}

The phisher then sends an EMail to UserXYZ at ImportantCompany Ltd. to open up the link and follow the instructions at:
https://demo2.nextcloud.com/index.php/login/v2/flow/ve5rsdvyLkgPjMU8ozIDf2Q0YVpz3aEj98oKQ59N3SiAzrwP9Zi0Rm1kdjgcQgRoE0OL9s52im0cGAlAZ18QG0MX63k4pemHVlCShGZbFYI4AvRJ985bBavDsz0Lqc21s

The phisher waits for the user to grant access and afterwards the phisher polls:
curl -X POST https://demo2.nextcloud.com/login/v2/poll -d "token=3cx8pDOb3QJfQJDZDo4WemN4cjQDIhV4YZZELxeL7Wm5qWiIyZkYnLbZnbyS4IdEEakvVYMqxY1PM6tFr3Paam2dOstOjarCX4NfxGGFUFOxzjDjziJFdgX2A8NKoRH"

So the phisher retrieves an AppToken für UserXYZ like:

{
    "server":"https:\/\/demo2.com.com",
    "loginName":"UserXYZ",
    "appPassword":"yKTVA4zgxjfivy52WqD8kW3M2pKGQr6srmUXMipRdunxjPFripJn0GMfmtNOqOolYSuJ6sCN"
}

I assume the phisher then can use all API Calls whatsoever of that Nextcloud's User named UserXYZ.

Question is: Are there any measures that prevent a phisher to use this method?
Perhaps not only targeted for a specific user, but using this for a mass mailing phishing attack.
(The phisher then of course has to build an infrastructure to mass-poll the API, which should be no problem)

Am i missing something here?

[kesselb]

server/core/Db/LoginFlowV2Mapper.php

Line 35 in 5bf3d1b

private const lifetime = 1200;

It seems the token is valid for 30 20 minutes.

[nickvergessen]

Well if a user does this:

Connect to your account

Please log in before granting xxx access to your Nextcloud account.

You lost already anyway. Sure we can improve the message, but on a technical level this is not an issue.
It's like preparing a page and asking the user to login with their nextcloud account on your page.

[githubkoma]

@nickvergessen
as a phisher you dont even have to forge a page or spoof a domain

nextcloud presents the perfect login page under the correct domain

[nickvergessen]

Yeah, which is why we should extend the description a bit: #21706
But the technical thing is still valid. If someone logs in on any link you gave them ¯\_(ツ)_/¯

[rullzer]

I mean in theory we could show 5 digit code. or something. But I doubt people will check.
It is in my opinion similar to granting others access via google or facebook. If you click yes at the moment that it shows you are about to give 'X' access to 'Y' then that is what you do.

also please always report security sensitive issues via hackerone

[githubkoma]

@nickvergessen
thanks!

i am a bit irritated about the "disconnect" between the Client (who perhaps is meant to be an e.g. Native App)
and the one who polls the AppPassword. Of course, usually this is One Person. But it could also be 2 different Machines.

i myself perhaps would feel better, if the second /POST/ to actually retrieve the Token would be forced to originate from the same source-ip adress

that would make it harder for a third party to get the AppPassword

[githubkoma]

also please always report security sensitive issues via hackerone

I'll keep that in mind

The difference between Oauth2 is, that the IdP hands out an AuthCode back directly to the user. OAuth2 sends the user back to the Serviceprovider or NativeApp, via redirect_uri.
So a phisher wouldnt get hands on the the auth_code.

Here with login flow v2, you just push out an Auth-Page to UserX and
then, in phase 2, to get the actual Token, a potential Phisher could sit anywhere in the world and pull that Token.
There is no a)IP Check (or similar) and b) no redirect_uri mechanism