Sensitive Cookie in HTTPS Session Without 'Secure' Attribute
LedgerSMB does not set the 'Secure' attribute on the session authorization
cookie when the client uses HTTPS and the LedgerSMB server is behind a
reverse proxy. By tricking a user to use an unencrypted connection (HTTP),
an attacker may be able to obtain the authentication data by capturing
- 1.8.0 upto 1.8.21 (including)
LedgerSMB 1.8 and newer switched from Basic authentication to using cookie
authentication with encrypted cookies. Although an attacker can't access
the information inside the cookie, nor the password of the user, possession
of the cookie is enough to access the application as the user from which the
cookie has been obtained.
In order for the attacker to obtain the cookie, first of all the server
must be configured to respond to unencrypted requests, the attacker must be
suitably positioned to eavesdrop on the network traffic between the client
and the server *and* the user must be tricked into using unencrypted HTTP
Proper audit control and separation of duties limit Integrity impact of
the attack vector.
CVSSv3.1 Base Score: 5.9 (Medium)
CVSSv3.1 Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:L/A:N
Users of LedgerSMB 1.8 are urged to upgrade to known-fixed versions. Users
of LedgerSMB 1.7 or 1.9 are unaffected by this vulnerability and don't need
to take action.
As a workaround, users may configure their Apache or Nginx reverse proxy
to add the Secure attribute at the network boundary instead of relying on
For Apache, please refer to the 'Header always edit' configuration command
in the mod_headers module.
For Nginx, please refer to the 'proxy_cookie_flags' configuration command.
0xdhinu, user of the huntr.dev platform