Under certain conditions a local, physical attacker can get access to passwords of previously logged in users from the WebUI.

Details

Preconditions

This problem occurs, if the following conditions apply:

1. A logged in user in the WebUI locks the WebUI or logs out and does not close the browser tab.
2. The attacker gets local access to the browser tab.

Affected versions

privacyIDEA < 2.21.4

Technical background

Advisory

• No third person should use the user’s computer/desktop
• The desktop should be locked, when the user leaves his desktop
• The browser tab should be closed, when the user has finished working in the UI.

Fix

This bug is fixed in the current version 2.21.4 of privacyIDEA.

Credits

• Affected version: up to privacyIDEA 2.11.2
• Propability: Medium
• Security Severity: High

Technical Background

The passOnNoUser policy is supposed to check if an authenticating user exists. If the user exists, normal authentication is performed. If the user does not exist in the user store authentication is immediately successful. This is useful in special scenarios, where the Application has several levels of authentication and privacyIDEA is just the second level. Users that do not exist in privacyIDEA will only authenticate with the first level and users, that have an account in privacyIDEA will need to authenticate with the second level.

The Bug: If the policy passOnNoUser is set, it is not checked, if the user exists. I.e. even users that do exist are successfully authenticated, without checking their OTP value or password.

Advisory

You need to disable a policy containing the passOnNoUser action or remove the passOnNoUser action from you policies immediately.

Fix

You should update to version 2.11.3 which is released today.

• Affected version: privacyIDEA 2.6
• Propability: High
• Security Severity: Low

Technical Background

privacyIDEA allows to authenticate with a username or a token serial number. I.e. the API can do a

POST /validate/check

user=username
pass=PIN+OTP

or a

POST /validate/check

serial=serialnumber
pass=PIN+OTP

A bug in file privacyidea/lib/policydecorators.py, which checks for challenge-response functionality will cause an authentication request without a username to fail.

Advisory

In common scenarios the user will always authenticate with his username.
Only if you are using Remote token types or if you have a special workflow there might be scenarios when authentication is done using only the serial number of the token.

If you are not authenticating with serial numbers, you do not need to take any actions.

If you are running such a scenario either

• use privacyIDEA 2.5
• use privacyIDEA >= 2.7dev1
• or drop us a note.

Fix

The bug is fixed in 2.7 development release and will be released with 2.7 in October.

Under certain conditions a rogue user can login as an LDAP user to the privacyIDEA web UI or guess a static password part during authentication when the policy scope=authentication, otppin=userstore is used.

Details

Preconditions

This problem only occurs, when both conditions are met:

1. The LDAP resolver defines a wrong, not existing UID-Type.
2. The LDAP server is configured to allow anonymous binds.

Technical background

During the password verification process, the LDAP resolver tries to find the user with the given UID – defined by the UID type. It then uses the user objects DN to bind to the LDAP server.

If the UID type does not exist, the LDAP resolver will get an empty DN to bind to the LDAP server. Binding with an empty DN is equal to an anonymous bind. If your LDAP server accepts anonymous binds, the bind will be successfull and the password verification is regarded as successful.

Advisory

If you have an LDAP server, that allows anonymous binds, you should check your LDAP resolver. Please check, that the UID Type you specified, really exist.

Verify authenticating to the Web UI with an existing LDAP user, but with an invalid password.

Fix

This bug is fixed in this commit and will be release with version 2.6 shortly.