When Security in Mind doesn’t match with the Application’s Security
1. Introduction
This case was originally written in Portuguese back in September 2006, it is about a case where customer was really concern about security. However his application was not that concern about this subject. Here is the scenario:
· Customer has an application that uses LDAP to send query to Active Directory;
· The user that uses this application when tries to connect to Active Directory using LDAP it uses his credentials to bind to the directory;
· This application used to work just fine for years.
· Problem: After the company implemented some security policies this particular application stopped to work.
This sound really familiar with almost of the scenarios where security policies are applied without collect exactly the needs of each application. But, it is our job to fix it and point it where is the breach that needs to be addressed in the application.
2. Understanding the Environment
First of all we had to ask, ask and keep asking about the environment to understand what really changed. In this case the good part was that customer was only starting to make the changes that the security policy had determined. One of changes that he did was to implement restrictions on the workstations that the user can logon (that’s an old one, but useful). You can find this window on the user’s properties, as show in the window below:
Figure 1 – Restricting what workstations the user can use to logon.
You might thing: what this has to do with the LDAP issue? Well, at beginning, when customer showed me that I was like: ok, thanks for let me know. But then, he said some magic words: If I add the Domain Controller in this list, the application works fine. That was really interesting; I didn’t know yet how that could be related. I decided to do another test, which was: run the application from the Domain Controller itself using the user’s credential and it works.
3. Dealing with the Misconception
First thing that customer said was: this is a security vulnerability, looks like it just works if the DC is in this list. I could understand his frustration, because he was the Security Administrator and in one side he had the Developers saying that the Microsoft LDAP is not using the standard LDAP implementation and this is the reason why is failing. In the other side the CEO is saying that the Security Team broke the application. It was at least 10 minutes of stress without do anything technical.
To isolate things the first that I said was: let’s test the same query (LDAP) but using our application (LDAP.EXE), which is available via Windows Server 2003 Support Tools. After open the LDAP.EXE, on the screen below I added the user name, the password and checked NTLM:
Figure 2 – LDAP Tool’s authentication window.
Guess what? It works !! It works without have to add the DC in the logon workstation’s list. Silent…..the conf call remained silent for 30 seconds.
Time to break that silence and then see what’s going on behind the scenes; of course, the best way to do that and see what is passing through the wire.
4. Narrowing Down
To understand what the difference was between the two applications I got a netmon trace on each scenario and let’s see what happened:
Test 1 – Using Microsoft LDAP.EXE Tool
1. Client sends the request (TCP Port 389) and the 3 way handshake happens successfully:
192.1.16.15 192.7.11.12 TCP 4507 > ldap [SYN]
192.7.11.12 192.1.16.15 TCP ldap > 4507 [SYN, ACK]
192.1.16.15 192.7.11.12 TCP 4507 > ldap [ACK]
2. The LDP Tool sends the “Bind Request” and the credentials are sent using NTLM:
192.1.16.15 192.7.11.12 LDAP MsgId=13
Bind Request, DN=(null), NTLMSSP_AUTH, User: DOMAINNAME \TestUser
Lightweight Directory Access Protocol
LDAP Message, Bind Request
Message Id: 13
Message Type: Bind Request (0x00)
Message Length: 225
Response In: 3175
Version: 3
DN: (null)
Auth Type: SASL (0x03)
Mechanism: GSS-SPNEGO
GSS-API Generic Security Service Application Program Interface
NTLMSSP
NTLMSSP identifier: NTLMSSP
NTLM Message Type: NTLMSSP_AUTH (0x00000003)
Lan Manager Response:
F1DC6D4CFFCD04F900000000000000000000000000000000
Length: 24
Maxlen: 24
Offset: 134
NTLM Response: F2988187EC1C67496EDF4F46313F401E08F688325DC541A8
Length: 24
Maxlen: 24
Offset: 158
Domain name: DOMAINNAME
Length: 18
Maxlen: 18
Offset: 72
User name: TestUser
Length: 32
Maxlen: 32
Offset: 90
Host name: COMPUTER1
Length: 12
Maxlen: 12
Offset: 122
Session Key: 33724B7018EADC94650FCAAB1F6741EF
Length: 16
Maxlen: 16
Offset: 182
Flags: 0xe2888215
3. Server answers saying that the bind was done successfully:
192.7.11.12 192.1.16.15 LDAP MsgId=13 Bind Result
Lightweight Directory Access Protocol
LDAP Message, Bind Result
Message Id: 13
Message Type: Bind Result (0x01)
Message Length: 9
Response To: 3174
Time: 0.001953000 seconds
Result Code: success (0x00) <----------------------
Matched DN: (null)
Error Message: (null)
Test 2 – Using Third Party LDAP Application
1. Client sends the request (TCP Port 389) and the 3 way handshake happens successfully:
192.1.16.15 192.7.11.12 TCP 4507 > ldap [SYN]
192.7.11.12 192.1.16.15 TCP ldap > 4507 [SYN, ACK]
192.1.16.15 192.7.11.12 TCP 4507 > ldap [ACK]
2. The LDAP Application sends the “Bind Request”, but now check the difference:
192.1.16.15 192.7.11.12 LDAP MsgId=1 Bind Request, DN=CN=TestUser,OU=Test,DC=domainname,DC=local
Lightweight Directory Access Protocol
LDAP Message, Bind Request
Message Id: 1
Message Type: Bind Request (0x00)
Message Length: 83
Response In: 998
Version: 3
DN: DN=CN=TestUser,OU=Test,DC=domainname,DC=local
Auth Type: Simple (0x00) <---------------- Authentication Method
Password: 12345678
4. Server answers with the error:
192.7.11.12 192.1.16.15 LDAP MsgId=1 Bind Result, invalidCredentials
Lightweight Directory Access Protocol
LDAP Message, Bind Result
Message Id: 1
Message Type: Bind Result (0x01)
Message Length: 94
Response To: 997
Time: 0.001954000 seconds
Result Code: invalidCredentials (0x31) <-------------- ERROR
Matched DN: (null)
Error Message: 80090308: LdapErr: DSID-0C090334, comment:
AcceptSecurityContext error, data 531, vece
The LDAP Protocol implemented by Microsoft can use the following methods:
Authentication Method |
Description |
LDAP_AUTH_SIMPLE |
Authentication with a simple clear-text password. |
LDAP_AUTH_NTLM |
Windows NT® LAN Manager |
LDAP_AUTH_DPA |
Distributed password authentication (used by Microsoft Membership System) |
LDAP_AUTH_NEGOTIATE |
Generic security services (GSS) (Snego). Does not provide any authentication services, instead chooses the most appropriate authentication method from a list of available services and passes all authentication information on to that service. Use with Windows® 2000 |
LDAP_AUTH_SSPI |
This constant is obsolete and is included for backward compatibility only. Using this constant selects GSS (Snego) negotiation service. |
Table extracted from the document Understanding LDAP.
Now the question: what the authentication method have to do with the LDAP problem?
Let’s see the authentication process on the third party LDAP Application:
1) The application sends the authentication using LDAP_AUTH_SIMPLE. This method sends only the user name and the password.
2) When the DC receives the authentication requests it checks not only the user’s credential, but also the User-Workstations attribute. This attribute contains list of computers that the user can logon.
3) Since the application doesn’t send the location (domain or computer name) the DC uses his own name to check (DCNAME\User) to check that.
4) DC checks if his own NetBIOS name is present on that list and since it is not it will refuse with an Access Denied.
Now it makes sense that if we add the DC’s name to that list it will work, right? J
With the Microsoft LDP Tool this doesn’t happen because we send the credential using LDAP_AUTH_NTLM. When we do this, the computer’s name is present in the request, as showed below:
NTLM Response: F2988187EC1C67496EDF4F46313F401E08F688325DC541A8
Length: 24
Maxlen: 24
Offset: 158
Domain name: DOMAINNAME
Length: 18
Maxlen: 18
Offset: 72
User name: TestUser
Length: 32
Maxlen: 32
Offset: 90
Host name: COMPUTER1
Length: 12
Maxlen: 12
Offset: 122
Session Key: 33724B7018EADC94650FCAAB1F6741EF
Length: 16
Maxlen: 16
Offset: 182
Flags: 0xe2888215
5. Conclusion
The problem was not with the Microsoft LDAP Standard, neither was a security vulnerability in the system. The problem was on this particular LDAP Application that was using an unsecure authentication method. This is another prove that security is not only one piece, when we think about security we have to cover all areas. In this case there was an extreme concern about protecting the domain with security policies, do not leave breaches, be diligent!!! However, the main company’s application was using clear text authentication method.