Cannot enter 2FA code

[Ian Braithwaite]

On 12/09/2022 19:18, Daniel Lenski wrote:
> On Mon, Sep 12, 2022 at 6:42 AM Ian Braithwaite <idb at tagvision.dk> wrote:
>> I'm not the original poster, but I'm experiencing the same problem.
>> Here's the details of the challenge form as requested.
>> As you guessed, OpenConnect isn't recognizing that a field needs to be
>> filled in
>> and is just continuing without it.
>>
>> I guess it's this one?
>>      <input type="hidden" name="challenge_code" value="0" />
>>
> That's a great catch. Also, a nearly identical situation was reported
> ~10 days ago on GitLab at
> https://gitlab.com/openconnect/openconnect/-/issues/489
>
> So now we have *THREE* reports of this on real Cisco servers.

I'm not so sure that field is the right one, after trying your next 
suggestion.


>> I don't know how OpenConnect is supposed to recognize it... weird it's
>> "hidden".
>>
>>
>> Questions that may help resolve this issue.
>>
>> 1. Ian, does your server also fall back to the non-XML-based
>> authentication, like Henry Luis's report and like
>> https://gitlab.com/openconnect/openconnect/-/issues/489?

Yes it does (redirect, GET /+webvpn+/index.html).

>> 2. Does spoofing an official Cisco Windows client change anything?
>> (openconnect --os=win --useragent 'Cisco AnyConnect VPN Agent for
>> Windows 4.9.0195')?)

Very much - OpenConnect successfully connects, without the redirect.

The server response is completely different - the hidden fields are gone 
and it has a normal password field that OpenConnect handles just fine:

-+-+-+-
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Transfer-Encoding: chunked
Cache-Control: no-store
Pragma: no-cache
Connection: Keep-Alive
Date: Tue, 13 Sep 2022 09:10:37 GMT
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-XSS-Protection: 1
Content-Security-Policy: default-src 'self' 'unsafe-inline' 
'unsafe-eval' data: blob:; frame-ancestors 'self'; base-uri 'self'; 
block-all-mixed-content
X-Aggregate-Auth: 1
HTTP body chunked (-2)
< <?xml version="1.0" encoding="UTF-8"?>
< <config-auth client="vpn" type="auth-request" aggregate-auth-version="2">
< <opaque is-for="sg">
< <tunnel-group>Konsulent</tunnel-group>
< <auth-handle>417970910</auth-handle>
< <config-hash>1662441803424</config-hash>
< </opaque>
< <auth id="challenge">
< <title>Login</title>
< <message id="2" param1="Indtast tilsendte engangskode" 
param2="">%s</message>
< <form>
< <input type="password" name="answer" label="Response:"></input>
< <input type="submit" name="Continue" label="continue"></input>
< </form>
< </auth>
< </config-auth>
Indtast tilsendte engangskode
-+-+-+-

>> It may be easier to follow up on the GitLab issue:
>> https://gitlab.com/openconnect/openconnect/-/issues/489#note_1097313325
>>
>> My best guess about the root cause here is that either it's a result
>> of a server being misconfigured/confused due to a lack of testing with
>> non-official clients, OR that it's an intentional obfuscation of the
>> authentication forms with the intention of confusing non-official
>> clients.

Or even both :-).

-Ian

>> Dan
>>
>> ps- Oddly, we also have a very similar issue with F5 VPNs (*completely
>> different protocol*) that has popped up recently, wherein the form
>> fields for 2FA codes get sent in a needlessly obfuscatory way:
>> https://gitlab.com/openconnect/openconnect/-/issues/493#note_1097084348