what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

checkpoint.ldap.txt

checkpoint.ldap.txt
Posted Oct 20, 1999
Authored by Olaf Selke

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.

tags | exploit, protocol
SHA-256 | 2f81200bc55676da2428f3831cedb8e4b15c6bd29aae46ce2333a5340e0d9e94

checkpoint.ldap.txt

Change Mirror Download
Overwiew:

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.


Technical background:

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.


Conclusion:

I don't consider it as major bug, but it's serious enough that one can't
rely on access control enforced through ldap. I've reported this problem
through Checkpoint's support channels two weeks ago, but so far there's
no response at all.

Attached is the original bug report I've sent to technical support.

Olaf
--
Olaf Selke, olaf.selke@mediaways.net, voice +49 5241 80-7069


=============================== snip ===============================

firewall: Solaris 2.6, V4.0 SP4 [VPN + DES + STRONG]
management machine: Solaris 2.6, V4.0 SP4 [VPN + DES + STRONG]
Directory Server: Solaris 7, Netscape-Directory/4.0 B98.349.0339


Today we found that FW-1 seems to ignore the ldap attribute
'fw1allowed-dst' completely, granting access to 'any' instead.
If that's really the case, it could lead to a breach of security.

We successfully coupled a FW-1 V4.0 SP4 with a Netscape Directory
Server according CP's documentation. Surprisingly this went very
smoothly ;-) In a second step we checked if the FW software really
cares about the ldap attributes controlling access in detail, using a
client authentication rule for this purpose.

It looks like the attributes 'fw1hour-range-from', 'fw1hour-range-to',
and 'fw1allowed-src' are interpreted as expected by the firewall, so
I think we didn't made some mistake in general.

However, from our point of view, in any case the ldap attribute
'fw1allowed-dst' is ignored and silently substituted by 'any'.
This means a user with restricted access through ldap attributes
has full access after successful authentication.

Login or Register to add favorites

File Archive:

July 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Jul 1st
    27 Files
  • 2
    Jul 2nd
    10 Files
  • 3
    Jul 3rd
    35 Files
  • 4
    Jul 4th
    27 Files
  • 5
    Jul 5th
    18 Files
  • 6
    Jul 6th
    0 Files
  • 7
    Jul 7th
    0 Files
  • 8
    Jul 8th
    28 Files
  • 9
    Jul 9th
    44 Files
  • 10
    Jul 10th
    24 Files
  • 11
    Jul 11th
    25 Files
  • 12
    Jul 12th
    11 Files
  • 13
    Jul 13th
    0 Files
  • 14
    Jul 14th
    0 Files
  • 15
    Jul 15th
    0 Files
  • 16
    Jul 16th
    0 Files
  • 17
    Jul 17th
    0 Files
  • 18
    Jul 18th
    0 Files
  • 19
    Jul 19th
    0 Files
  • 20
    Jul 20th
    0 Files
  • 21
    Jul 21st
    0 Files
  • 22
    Jul 22nd
    0 Files
  • 23
    Jul 23rd
    0 Files
  • 24
    Jul 24th
    0 Files
  • 25
    Jul 25th
    0 Files
  • 26
    Jul 26th
    0 Files
  • 27
    Jul 27th
    0 Files
  • 28
    Jul 28th
    0 Files
  • 29
    Jul 29th
    0 Files
  • 30
    Jul 30th
    0 Files
  • 31
    Jul 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close