Check Point Firewall-1 LDAP Authentication Vulnerability
BID:725
Info
Check Point Firewall-1 LDAP Authentication Vulnerability
| Bugtraq ID: | 725 |
| Class: | Access Validation Error |
| CVE: | |
| Remote: | Yes |
| Local: | No |
| Published: | Oct 20 1999 12:00AM |
| Updated: | Oct 20 1999 12:00AM |
| Credit: | This vulnerability was posted to the Bugtraq mailing list by Olaf Selke <[email protected]> on Wed, 20 Oct 1999. |
| Vulnerable: |
Check Point Software Firewall-1 4.0 |
| Not Vulnerable: |
Check Point Software Firewall-1 3.0 |
Discussion
Check Point Firewall-1 LDAP Authentication Vulnerability
With FireWall-1 Version 4.0 Checkpoint introduced support for the Lightweight Directory Access Protocol (LDAP) for user authentication. It looks like there's a bug in Checkpoint's ldap code which under certain circumstances can lead to unauthorized access to protected systems behind the firewall.
A user can authenticate himself at the firewall providing a valid username and password. The firewall acts as a ldap client, validating the credentials by a directory server using the ldap protocol. After successful authentication access will be granted to systems protected by the firewall.
In contrast to authentication using the Radius or SecurID protocol, after successful authentication the directory server can supply the firewall with additional ldap attributes for the user like the time and day of a week a user is allowed to login, the source addresses a user can run a client from, or the system behind the firewall a user is allowed to access. This can be done individual for each user.
In general I think that's a great idea but it seems Checkpoint made something wrong interpreting the ldap attribute 'fw1allowed-dst' which is supposed to control in detail which protected network object a user can access.
It seems this attribute is ignored by the firewall software, granting access to all protected network objects instead.
Example:
------ Server 'Foo'
|
Internet --- FW-1 ---|
|
------ Server 'Bar'
Supposed there's a user 'Sid' with access only to Server 'Foo', and a second user 'Nancy' with access restricted to Server 'Bar', both controlled by the ldap protocol, using the ldap attribute 'fw1allowed-dst'. The bug will cause that both, Sid and Nancy, will have access to Foo and to Bar.
[Quoted from the post by Olaf Selke with permission]
With FireWall-1 Version 4.0 Checkpoint introduced support for the Lightweight Directory Access Protocol (LDAP) for user authentication. It looks like there's a bug in Checkpoint's ldap code which under certain circumstances can lead to unauthorized access to protected systems behind the firewall.
A user can authenticate himself at the firewall providing a valid username and password. The firewall acts as a ldap client, validating the credentials by a directory server using the ldap protocol. After successful authentication access will be granted to systems protected by the firewall.
In contrast to authentication using the Radius or SecurID protocol, after successful authentication the directory server can supply the firewall with additional ldap attributes for the user like the time and day of a week a user is allowed to login, the source addresses a user can run a client from, or the system behind the firewall a user is allowed to access. This can be done individual for each user.
In general I think that's a great idea but it seems Checkpoint made something wrong interpreting the ldap attribute 'fw1allowed-dst' which is supposed to control in detail which protected network object a user can access.
It seems this attribute is ignored by the firewall software, granting access to all protected network objects instead.
Example:
------ Server 'Foo'
|
Internet --- FW-1 ---|
|
------ Server 'Bar'
Supposed there's a user 'Sid' with access only to Server 'Foo', and a second user 'Nancy' with access restricted to Server 'Bar', both controlled by the ldap protocol, using the ldap attribute 'fw1allowed-dst'. The bug will cause that both, Sid and Nancy, will have access to Foo and to Bar.
[Quoted from the post by Olaf Selke with permission]
Exploit / POC
Check Point Firewall-1 LDAP Authentication Vulnerability
See Discussion.
See Discussion.
Solution / Fix
Check Point Firewall-1 LDAP Authentication Vulnerability
Solution:
Check Point Support <[email protected]> emailed the following information to [email protected]:
Resolution: After investigation, Check Point Software confirms this as the appropriate behavior with "standard" checked in "Required Sign On" field under "Client Authentication". In other words, when using "standard" sign-on, the "Destination" field under "Client Authentication" properties cannot be intersected with the user database property which defines user access to specific destinations. Accordingly, the "Destination" field is grayed out in the Client Authentication Action Properties. This information is documented on Page 534 of VPN-1/FW-1 Administration Guide where it is stated that under such circumstances, the "Destination" field is automatically set to "Ignore User Database" and that the user can access all destinations allowed by the rule. The VPN-1/FW-1 GUI can cause confusion because it simply grays out the value set in "Destination" field instead of setting it to "Ignore User Database". But internally, the "Destination" value is set to "Ignore User Database". The GUI will be amended in the subsequent release of VPN-1/FW-1 to make this more clear. It is important to note that the "Source" field can be intersected with user database even if standard sign-on is selected under Client Authentication.
Also, this behavior is independent of whether the user is defined in VPN-1/FW-1 internal database or an external LDAP-complaint directory server.
If one would like to enforce the "allowed-destinations" attribute (defined for each user) under Client Authentication Rule, the "Required Sign On" field must be set to "Specific", and an appropriate Sign-On Method should be selected.
This limitation does not exist under User Authentication Rules.
Solution:
Check Point Support <[email protected]> emailed the following information to [email protected]:
Resolution: After investigation, Check Point Software confirms this as the appropriate behavior with "standard" checked in "Required Sign On" field under "Client Authentication". In other words, when using "standard" sign-on, the "Destination" field under "Client Authentication" properties cannot be intersected with the user database property which defines user access to specific destinations. Accordingly, the "Destination" field is grayed out in the Client Authentication Action Properties. This information is documented on Page 534 of VPN-1/FW-1 Administration Guide where it is stated that under such circumstances, the "Destination" field is automatically set to "Ignore User Database" and that the user can access all destinations allowed by the rule. The VPN-1/FW-1 GUI can cause confusion because it simply grays out the value set in "Destination" field instead of setting it to "Ignore User Database". But internally, the "Destination" value is set to "Ignore User Database". The GUI will be amended in the subsequent release of VPN-1/FW-1 to make this more clear. It is important to note that the "Source" field can be intersected with user database even if standard sign-on is selected under Client Authentication.
Also, this behavior is independent of whether the user is defined in VPN-1/FW-1 internal database or an external LDAP-complaint directory server.
If one would like to enforce the "allowed-destinations" attribute (defined for each user) under Client Authentication Rule, the "Required Sign On" field must be set to "Specific", and an appropriate Sign-On Method should be selected.
This limitation does not exist under User Authentication Rules.
References
Check Point Firewall-1 LDAP Authentication Vulnerability
References:
References:
- Check Point Technical Support (Check Point Software)
- Firewall-1 Connection Table Paper (Lance Spitzner)