Using LDAP for Authentication is Never Best Practice

Many enterprise clients rely on LDAP as their authentication and authorization provider for their websites. LDAP is used to store all of this information, the infrastructure already exists, so why not use it? There are plenty of reasons. So much so that I don't know if I can ever "recommend" a client directly integrate their web site with LDAP again.
When helping a fellow consultant recently, I was suddenly confused why LDAP is such a common tool. First of all it's a directory service, not a real IAM system. Second it requires a lot to be reimplemented on every client. Third, and maybe most importantly, it relies on each client to respect any permissions on the LDAP server. In any security best practice, do you ever rely on the client to be "secure"?
From a wonderful MSDN article on the subject¹ -

Identity and access management refers to the processes, technologies and policies for managing digital identities and controlling how identities can be used to access resources.

LDAP is not a full IAM system. It is a user directory that defines who a person is. Users are created with group memberships, used to explain where a user belongs in an org structure. There is not a natural translation to what the person can do, instead client applications must (loosely) translate these membership into application permissions. Worse, this translation is done by the client and isn't under the control of the IAM administrator, but purely under the discretion of the application developer. Sure the user's authentication can be blocked, but that doesn't solve the problems of limiting or adding permissions, only a binary allow/deny.
A real IAM system should be able to tell a single application if a user has access or not. This is the fundamental difference between a directory service and an IAM. Mappings should be done according to the requester, not returning all attributes and letting the application decide what's right. LDAP provides a centralized account repository and shared passwords, nothing more. Each client much configure their own connections and provide in-depth understandings of the LDAP protocol, no matter how advanced the usage is. After this excessive code is run, then the site administrator must configure how to translate the user's attributes into the context of their application.

Conclusion

LDAP is simply not web- or application- friendly. In our distributed web (even within a single organization), any IAM should include SSO, no question. That IAM should be lightweight, rely solely on the logic of the centralized system, and respect the concept of permissions over memberships. In web applications LDAP is done as far as I'm concerned. LDAP is dead, it's your turn CAS, Shibboleth, and OAuth.
 
Disclaimer: If you use LDAP within your application for more than just authentication and/or authorization, this doesn't apply to you. This is a complaint about how heavy-handed LDAP is compared to a more web-aware IAM system.

ref: http://erikwebb.net

PuttyHijack V1.0 - Hijack SSH/PuTTY Connections on Windows

PuttyHijack is a POC tool that injects a dll into the PuTTY process to hijack an existing, or soon to be created, connection.



This can be useful during penetration tests when a windows box that has been compromised is used to SSH/Telnet into other servers. The injected DLL installs some hooks and creates a socket for acallback connection that is then used for input/output redirection.


It does not kill the current connection, and will cleanly uninject if the socket or process is stopped.


Details


1) Start a nc listener

2) Run PuttyHijack specify the listener ip and port

3) Watch the echoing of everything including passwords





Some basic commands in this version include;


!disco - disconnect the real putty from the display!reco - reconnect it!exit - just another way to exit the injected shell


You can download PuttyHijack V1.0 here:
PuttyHijackV1.0.rar
Or read more here.

PuttyHijack V1.0 - Hijack SSH/PuTTY Connections on Windows

PuttyHijack is a POC tool that injects a dll into the PuTTY process to hijack an existing, or soon to be created, connection.

This can be useful during penetration tests when a windows box that has been compromised is used to SSH/Telnet into other servers. The injected DLL installs some hooks and creates a socket for acallback connection that is then used for input/output redirection.

It does not kill the current connection, and will cleanly uninject if the socket or process is stopped.

Details

1) Start a nc listener
2) Run PuttyHijack specify the listener ip and port
3) Watch the echoing of everything including passwords


Some basic commands in this version include;

!disco - disconnect the real putty from the display!reco - reconnect it!exit - just another way to exit the injected shell

You can download PuttyHijack V1.0 here:
PuttyHijackV1.0.rar
Or read more here.

Vista Security Feature - Teredo Protocol Analysis

Teredo is a platform-independent protocol developed by Microsoft, which is enabled by default in Windows Vista. Teredo provides a way for nodes located behind an IPv4 NAT to connect to IPv6 nodes on the Internet. However, by tunneling IPv6 traffic over IPv4 UDP through the NAT and directly to the end node, Teredo raises some security concerns.

Primary concerns include bypassing security controls, reducing defense in depth, and allowing unsolicited traffic. Additional security concerns associated with the use of Teredo include the capability of remote nodes to open the NAT for themselves, benefits to worms, ways to deny Teredo service, and the difficulty in finding all Teredo traffic to inspect.
You can find the report here:
Teredo Security [PDF]

Fake NetBIOS Tool - Simulate Windows Hosts

Some cool free tools made by folks from the French Honeynet Project.
FakeNetBIOS is a family of tools designed to simulate Windows hosts on a LAN. The individual tools are:

FakeNetbiosDGM (NetBIOS Datagram)
FakeNetbiosNS (NetBIOS Name Service)

Each tool can be used as a standalone tool or as a honeyd responder or subsystem.

FakeNetbiosDGM sends NetBIOS Datagram service packets on port UDP 138 to simulate Windows hosts bradcasts. It sends periodically NetBIOS announces over the network to simulate Windows computers. It fools the Computer Browser services running over the LAN and so on.

FakeNetbiosNS is a NetBIOS Name Service daemon, listening on port UDP 137. It responds to NetBIOS Name requests like real Windows computers: for example ‘ping -a’, ‘nbtstat -A’ and ‘nbtstat -a’, etc.

You can download the tools here:
FakeNetBIOS-0.91.zip
There are a few others things here:
http://honeynet.rstack.org/tools.php

Nemesis - Packet Injection Suite

Nemesis is a command-line network packet crafting and injection utility for UNIX-like and Windows systems. Nemesis, is well suited for testing Network Intrusion Detection Systems, firewalls, IP stacks and a variety of other tasks. As a command-line driven utility, Nemesis is perfect for automation and scripting.

Nemesis can natively craft and inject packets for:
ARP
DNS
ETHERNET
ICMP
IGMP
IP
OSPF
RIP
TCP
UDP

Using the IP and the Ethernet injection modes, almost any custom packet can be crafted and injected.

Unix-like systems require: libnet-1.0.2a, and a C compiler (GCC)Windows systems require: libnetNT-1.0.2g and either WinPcap-2.3 or WinPcap-3.0

Download it here:
Source code: nemesis-1.4.tar.gz (Build 26)Windows binary: nemesis-1.4.zip (Build 26) (includes LibnetNT)

You can read more here:
Nemisis at Sourceforge

Babel Enterprise - Cross Platform System Auditing Tool

Babel Enterprise is a systems auditing tool. Babel performs a security level check of the machine, or hardening. The check consists of a number of auditing tests that obtain a snap of the security status of each machine. The result is a security index of the system that is given after each execution. It a non-intrusive tool, meaning that it does not make any changes in the system at all. It simply takes note of what is not working properly and reports it to the user. .

Babel Enterprise has being designed to manage security on many different systems, different technologies and versions, and different issues and requirements. It is a distributed management system, multi-user, that allows redundant installation in all its critical components. Each change occurring in the system can be watched and marked automatically each time a new audit policy is executed. Users can add, delete or modify existing elements to see exactly if the system works better or worse and why. Babel Enterprise uses a pragmatic approach, evaluating those aspects of the system the represent a security risk and that can be improved with the intervention of an administrator.

Babel Enterprise has a version of its agent for each of the latest Microsoft operating systems, Windows 2003 and Windows XP, and the main Unix system: Solaris 10, AIX 5.x, SUSE GNU/Linux 9 ES and Ubuntu Dapper, although they can be easily adapted to different versions and other UNIX OSs (such as BDS or HP-UX )

Babel currently has modules for auditing many different aspects of system security. These are some examples of currently implemented audit modules:
Service minimization.
Centralized file hashing.
Anomalous SUID0 executable detection.
File permissions checker.
Password strength tests.
Generic registry lookup (Windows)
Remote services configuration.
Audit for Kernel networking and security parameters.
Apache2 configuration auditing
User accounts auditing
Root environment audit
UID0 users detection.
Centralized patch management.
Centralized software inventory.
Listening ports auditing.
Inetd / Xinetd minimization.

You can download the latest stable version of Babel Enterprise here:
Babel Enterprise 1.0 version.
Or read more here.

argus - Auditing Network Activity - Performance & Status Monitoring

Another tool for the security side, good for forensics, monitoring and auditing.

Argus is a fixed-model Real Time Flow Monitor designed to track and report on the status and performance of all network transactions seen in a data network traffic stream. Argus provides a common data format for reporting flow metrics such as connectivity, capacity, demand, loss, delay, and jitter on a per transaction basis. The record format that Argus uses is flexible and extensible, supporting generic flow identifiers and metrics, as well as application/protocol specific information.

Argus can be used to analyze and report on the contents of packet capture files or it can run as a continuous monitor, examining data from a live interface; generating an audit log of all the network activity seen in the packet stream. Argus can be deployed to monitor individual end-systems, or an entire enterprises network activity. As a continuous monitor, Argus provides both push and pull data handling models, to allow flexible strategies for collecting network audit data. Argus data clients support a range of operations, such as sorting, aggregation, archival and reporting. There is XML support for Argus data, which makes handling Argus data a bit easier.

Argus currently runs on Linux, Solaris, FreeBSD, OpenBSD, NetBSD, and MAC OS X and its client programs have also been ported to Cygwin. The software should be portable to many versions of Unix with little or no modification. Performance is such that auditing an entire enterprises Internet activity can be accomplished using modest computing resources.

You can download argus here:
argus-2.0.6 (various options available)
Or read more here.

raWPacket HeX - Network Security Monitoring & Analysis LiveCD

HeX is a project aimed at the NSM (Network Security Monitoring) community for use by network security analysts। The developers believe that simplicity and analysis work flow logic must be enhanced and emphasized through-out the process of designing this liveCD. Not only have they carefully chosen all the necessary applications and tools to be included to the liveCD, they have also tested them to make sure everything running as smooth as possible. In order to summarize the objective of HeX, they are trying to develop the first and foremost Network Security Monitoring & Network Based Forensics liveCD!

HeX Main Features
HeX Main Menu - Cleaner look and more user interface oriented and maximum 4 levels depth HeX Main Menu allows quick access to all the installed applications in हेक्स।

Terminal - This is exactly what you need, the ultimate analyzt console!
Instant access to all the Network Security Monitoring(NSM) and Network Based Forensics(NBF) Toolkits via Fluxbox Menu। We have also categorized them nicely so that you know what to use conditionally or based on scenario.

Instant access to the Network Visualization Toolkit, you can watch the network traffics in graphical presentation and that assist you in identifying large scale network attacks easily।

Instant access to Pcap Editing Tools which you can use to modify or anonymize the pcap data, it’s great especially when you want to share your pcap data।

Network and Pentest Toolkits contain a lot of tools to perform network or application based attacks, you can generate malicious packets using them and study malicious packets using those analysis tools listed in NSM-Toolkit and NBF-Toolkit as well।

While we think HeliX liveCD is better choice in digital forensics arsenal, Forensics-Toolkit can be considered as the add-on for people who are interested in doing digital forensics.
Under Applications, there are Desktop, Sysutils and Misc, all of them are pretty self-explained and contain user based applications such as Firefox, Liferea, Xpdf and so forth. Additionally, Misc contains some useful scripts, for example you can just start ssh service by clicking on SSHD-Start.
You can download HeX 1.0.3 here:
hex-i386-1.0.3.iso

Kerberos VS NTLM

What are the main feature differences between the Windows Kerberos and NT LAN Manager (NTLM) authentication protocols? Why is the Kerberos protocol generally considered a better authentication option than the NTLM protocol?

NTLM Authentication: Challenge- Response mechanism.
In the NTLM protocol, the client sends the user name to the server; the server generates and sends a challenge to the client; the client encrypts that challenge using the user’s password; and the client sends a response to the server.If it is a local user account, server validate user's response by looking into the Security Account Manager; if domain user account, server forward the response to domain controller for validating and retrive group policy of the user account, then construct an access token and establish a session for the use.

Kerberos authentication: Trust-Third-Party Scheme.
Kerberos authentication provides a mechanism for mutual authentication between a client and a server on an open network.The three heads of Kerberos comprise the Key Distribution Center (KDC), the client user and the server with the desired service to access. The KDC is installed as part of the domain controller and performs two service functions: the Authentication Service (AS) and the Ticket-Granting Service (TGS). When the client user log on to the network, it request a Ticket Grant Ticket(TGT) from the AS in the user's domain; then when client want to access the network resources, it presents the TGT, an authenticator and Server Principal Name(SPN) of the target server, contact the TGS in the service account domain to retrive a session ticket for future communication w/ the network service, once the target server validate the authenticator, it create an access token for the client user.

NTLM is a challenge/response-based authentication protocol that is the default authentication protocol of Windows NT 4.0 and earlier Windows versions. For backward compatibility reasons, Microsoft still supports NTLM in Windows Vista, Windows Server 2003 and Windows 2003 R2, Windows 2000, and Windows XP.

Starting with Win2K, Microsoft implements Kerberos as the default authentication protocol for the Windows OS. This means that besides an NTLM authentication provider, every Windows OS since Win2K also includes a client Kerberos authentication provider.

below, compares Kerberos to NTLM, the default authentication protocol of NT 4.0 and earlier Windows versions. The next paragraphs expand on some of the major feature differences between the Kerberos and the NTLM authentication protocols and explain why generally Kerberos is considered a better authentication option than NTLM.

Faster authentication. When a resource server gets Kerberos authentication information (in Kerberos speak "tickets" and "authenticators") from a client, the resource server has enough information to authenticate the client. The NTLM authentication protocol requires resource servers that aren't domain controllers (DCs), to contact a DC to validate a user's authentication request. This process is known as pass-through authentication. Thanks to its unique ticketing system, Kerberos doesn't need pass-through authentication and therfore accelerates the authentication process.

Mutual authentication. Kerberos can support mutual authentication. Mutual authentication means that not only the client authenticates to the service, but also the service authenticates to the client. Mutual authentication is a Kerberos option that the client can request. The support for mutual authentication is a key difference between Kerberos and NTLM. The NTLM challenge-response mechanism only provides client authentication. In the NTLM authentication exchange, the server generates an NTLM challenge for the client, the client calculates an NTLM response, and the server validates that response. Using NTLM, users might provide their credentials to a bogus server.

Kerberos is an open standard. Microsoft based its Kerberos implementation on the standard defined in Request for Comments (RFC) 4120. RFC 4120 defines version 5 of the Kerberos protocol. Because Kerberos is defined in an open standard, it can provide single sign-on (SSO) between Windows and other OSs supporting an RFC 4120-based Kerberos implementation. You can download RFC 4120 from the Internet Engineering Task Force (IETF) at http://www.ietf.org. NTLM is a proprietary authentication protocol defined by Microsoft. The NTLM protocol is not specified in an open standard document (for example in an IETF RFC).

Support for authentication delegation. Thanks to authentication delegation, a service can access remote resources on behalf of a user. What delegation really means is that user A can give rights to an intermediary machine B to authenticate to an application server C as if machine B was user A. This means that application server C will base its authorization decisions on user A's identity rather than on machine B's account. Delegation is also known as authentication forwarding. You can use delegation for authentication in multi-tier applications. An example is database access using a Web-based front-end application. In a multi-tier application, authentication happens on different tiers. In such a setup, if you want to set authorization on the database using the user's identity, you should be capable of using the user's identity for authentication both on the Web server and the database server. This is impossible if you use NTLM for authentication on every link, simply because NTLM doesn't support delegation.

Support for smart card logon. Through the Kerberos PKINIT extension, Win2K and later versions include support for the smart card logon security feature. Smart card logon provides much stronger authentication than password logon because it relies on a two-factor authentication. To log on, a user needs to possess a smart card and know its PIN code. Smart card logon also offers other security advantages. For example, it can block Trojan horse attacks that try to grab a user's password from the system memory. The NTLM authentication protocol doesn't support smart card logon.