Skip to main content
LPIC-3 Exam 303

Using ngrep Capturing Unencrypted Network Traffic

By June 8, 2018September 12th, 2022No Comments

ngrepAs we continue our series look at the LPIC-2 303 exam from the LPI and Linux Security we now turn our attention to packet captures. Although not specifically mentioned in the objective for Network Hardening for the LPI, ngrep is a tool you will want to know. Like its big brother, tcpdump, ngrep can capture packets from the network. The great feature of ngrep, that sets itself apart, is that we can search for extended regular expressions in the captured data. Learning this technique makes it incredibly easy to see the data that you want by filtering on the data not just the port.

Ngrep is available in CentOS from the EPEL respository and on Ubuntu 18.04 it is in the standard repositories. We will use ngrep to demonstrate the importance of using encrypted protocols or secure tunnels on your network. We will capture packets destined for port 389 the LDAP server port. We will show the effects of using both LDAP and LDAPS and how with LDAP the password is easily read and unecrypted.

If you want to get yourself a quick and easy LDAP Server then download a virtual image from  TurnkeyLinux .

I am using a CentOS 7 client where I have installed, first the EPEL repository.

$ sudo yum install -y epel-release

With this installed we can then add the openLDAP clients and ngrep.

$ sudo yum install -y ngrep openldap-clients

Making sure that your openLDAP server is up and running and you know the IP Address and the domain you created. This is an easy wizard at the startup of the TurnKey openLDAP system. We will add these details to the file $HOME/.ldaprc. In this way we can get away with typing less at the command line to execute LDAP queries. Many of the options being read from this file rather than from options at the command line. The following is the .ldaprc file that is in my home directory and used for the demonstartion:

BASE dc=example,dc=com
HOST 192.168.56.152
BINDDN cn=admin,dc=example,dc=com
PORT 389
TLS_REQCERT never

BASE The search base on the LDAP server and can be overwritten with the option -b from the ldap client

HOST The hostname or IP address of the LDAP server which can be overwritten with the -H option

BINDDN This repesents the option -D in the ldap clients and allows us to preset the login name

PORT 389 is the default port for LDAP and can also be used for LDAPS with  the STARTTLS function

TLS_REQCERT There is a self-signed X.509 certificate in the TrustKey Linux appliance. This would not be trusted by the ldap client. Although it will not allow us to authenticate the server when we connect by turning the certication validation off it is good for the demo. The traffic will still be encrypted but not authenticated.

We can test that everything workd by issuing and LDAP search to the server. From the CentOS system we can issue this command to list Nodes or OUs in the Directory:

$ ldapsearch -x -LLL -s sub "objectclass=organizationalUnit" ou -W

Enter LDAP Password: 
dn: ou=Groups,dc=example,dc=com
ou: Groups

dn: ou=Users,dc=example,dc=com
ou: Users

dn: ou=Hosts,dc=example,dc=com
ou: Hosts

dn: ou=Idmaps,dc=example,dc=com
ou: Idmaps

dn: ou=Aliases,dc=example,dc=com
ou: Aliases

These objects or entries all live in the TurnKey Linux server by default. Now that we know the our query and openLDAP server are both working, we can open another terminal and run ngrep to capture packets. Use the interface on your system that faces the openLDAP server, n my case this is enp0s8 and is denoted with the -d option to ngrep:

$ sudo ngrep  -q -d enp0s8 'cn=admin' port 389

interface: enp0s8 (192.168.56.0/255.255.255.0)
filter: ( port 389 ) and ((ip || ip6) || (vlan && (ip || ip6)))
match: cn=admin

The screen will stay active whilst it is capturing data. When we are finished capturing data, we use CTRL+C to end the capture. For the moment leave it running.

Returning to the initial terminal we can re-issue the ldapsearch command:

$ ldapsearch -x -LLL -s sub "objectclass=organizationalUnit" ou -W

Again, you will be prompted to enter the password and you will see the results displayed. Jumping back to the second teminal we will be able to see the packets that matched our filter:

T 192.168.56.150:43148 -> 192.168.56.152:389 [AP]
  0/…`*…..cn=admin,dc=example,dc=com..Password1

We can now end the capture using CTRL+C.

Using plain text of the network with HTTP, LDAP, or any plain text protocol ,we can see data very easily and quickly. The danger here is that the data stream contained the username and password which are clearly visible.

We now want to contrast this with LDAPS that we will still use over port 389. This is possible on later openLDAP servers that implement STARTTLS. In this way, if the client requests an encrypted session with LDAP they are upgraded to LDAPS without the need of two ports being open. Normally, port 389 is used for LDAP and port 636 is used for LDAPS. Using STARTTLS we only need port 389.

Staying on the second teminal we can re-issue the same ngrep capture for the admin account:

$ sudo  ngrep  -q -d enp0s8 'cn=admin' port 389

interface: enp0s8 (192.168.56.0/255.255.255.0)
filter: ( port 389 ) and ((ip || ip6) || (vlan && (ip || ip6)))
match: cn=admin

Return, now, to the first terminal and run the ldapsearch again but this time we add the -Z option to ensure we request STARTTLS. Don’t forget to add the -Z option, if you don’t, the stream will still be unencrypted.

$ ldapsearch -x -LLL -s sub "objectclass=organizationalUnit" ou -W -Z

Again, enter your password and view the output. It will be the same as before; nothing has changed except the transfer was encrypted and your credentials protected. We can see this by returning to the capture terminal, the screen will look the same with no extra data captured and no password shown. The data stream is now encrypted and there is no cn=admin in the payload to capture.

We can see this in more detail by removing the filter looking the cn=admin, so we just capure all traffic on port 389. Use CTRL+C to stop the capture and restart it without the text filter:

$ sudo ngrep  -q -d enp0s8 port 389

interface: enp0s8 (192.168.56.0/255.255.255.0)
filter: ( port 389 ) and ((ip || ip6) || (vlan && (ip || ip6)))

Returning to the initial terminal we issue the same ldapsearch using the option -Z and you will now see the complete encrypted stream. Here, we show just the inital few lines from the capture:

T 192.168.56.150:43158 -> 192.168.56.152:389 [AP]
  0....w...1.3.6.1.4.1.1466.20037                                                             

T 192.168.56.152:389 -> 192.168.56.150:43158 [A]
  ......                                                                                      

T 192.168.56.152:389 -> 192.168.56.150:43158 [AP]
  0....x........                                                                              
T 192.168.56.150:43158 -> 192.168.56.152:389 [AP]
.......................@j.zp#.............#....0.,.(.$.............k.j.i.h.9.8.7.6.........2  ...*.&.......=.5...
/.+.'.#.............g.@.?.>.3.2.1.0.........E.D.C.B.1.-.).%.......<./...A  .....................................
C.......................#...........................

No data is readable, the first few lines setup the STARTTLS request but then everything is encrypted from that point onwards. There is no readable username, passords or data here.

When you see how easy it is to grab clear text passwords you will tend to steer clear of those devices and certainly not implement them on your own systems.

The video follows