You see blogs, talks, presentations, and tutorials on how to break into boxes all the time. These usually focus on techniques to find vulnerabilities, exploit them, pivot, rinse, and repeat. Sometimes we get so caught up in what we're sending on the wire, we don't spend enough time listening to what hosts are telling us. In preparing for the webcast coming up this Thursday, I wanted to give a practical example of what we can get if we only listen before we even start testing a network.
Much like conversations, if all we do is talk, we never really hear what the other side has to say. By simply connecting to modern networks, most of the participating systems send different types of packets to manage the network connection. Many of these protocols are broadcast. You don't have to perform complex tasks such as Man-In-The-Middle attacks to see them; you only need to be on the same network. Protocols like DHCP help us get our IP address. Other protocols help our computers do things like finding other iTunes libraries, network printers, other Windows servers, or even modern appliances. Even my stereo has a network port these days, and systems want to help us manage these devices as easily as possible.
While I was researching this topic, I was playing around on my Windows machine and noticed a type of broadcast packet that I hadn't seen before. When I brought up Groove (now Microsoft Sharepoint Workspace), it appeared that Groove sent broadcast packets while it was active. I didn't recognise the protocol, but after doing some research, it is using DPP or Device Presence Protocol. The name alone interested me, but all I had was some specs for the WAN version of the protocol. I wasn't able to find anything that exactly matched what I was seeing.
Let's take a look at the packet in Scapy (Click to enlarge):
We can see the entire hierarchy of the packet. We know that it's a broadcast packet, based both on the mac of ff:ff:ff:ff:ff:ff and the destination IP of 255.255.255.255. We can see the destination port of 1211, and we can see the payload under the Raw section. Unfortunately, this Raw section is mostly binary data, and there is no key for figuring out what things are.
The main thing that sticks out is the DPP message. It appears to be terminated with a null character "\x00". So, we now know part of the message structure. There are a number of things that this packet appears to share with it's WAN counterpart. There is a major and minor version of the protocol that is in use, a serial number, and the DPP address. Let's look at the initial binary parts of the message.
>>> pkt[1].load
'\x01\x02\x81dpp:///manbanthyjif4tx97cshgzs5jcqz6r2vfztndea\x00\xbc\t\xc0\x02f\x01\xa8\xc0\x98`\x10\xac2\x00-\x174B4,2,0,2623\x00'
>>> struct.unpack('3B',pkt[1].load[0:3])
(1, 2, 129)
We see the payload of the first packet in our capture starts with "\x01\x02\x81". Using the unpack method of the struct module, we turn the bytes at the beginning into unsigned integers. We see these numbers are 1, 2, and 129. Looking at the WAN version of the protocol, 128 means online, so it makes sense that 129 indicates that this client is not connected to a groove server. The 1 and the 2 are the protocol version, so it's version 1.2. Finally, when we look at the DPP address, we copy the information up to the null, and see that the DPP address is : dpp:///manbanthyjif4tx97cshgzs5jcqz6r2vfztndea
Now that we have the first part of the packet out of the way, we are left with : '\xbc\t\xc0\x02f\x01\xa8\xc0\x98`\x10\xac2\x00-\x174B4,2,0,2623\x00'. Doing some googling, it appears that 4.2.0.2623 is the version number of Groove 2007. So we know the person is using Groove 2007, but as it typically comes with Office 2007, they likely have the Office 2007 suite as well. We now have fingerprinted what version of office the person is using. On a penetration test, this information opens the door to specifically targeted social engineering campaigns. Now we're left, with '\xbc\t\xc0\x02f\x01\xa8\xc0\x98`\x10\xac2\x00-\x174B'. Let's use scapy some more, and figure out what might be in here.
>>> rest = pkt[1].load.split("\x00",1)[1][0:19]
>>> rest
'\xbc\t\xc0\x02f\x01\xa8\xc0\x98`\x10\xac2\x00-\x174B4'
>>> struct.unpack("B"*len(rest),rest)
(188, 9, 192, 2, 102, 1, 168, 192, 152, 96, 16, 172, 50, 0, 45, 23, 52, 66, 52)
We take the rest of the packet that we don't know and assign it to the 'rest' variable. To see what's in the packet, we try to unpack each character in the string as an unsigned character. We have a lot of numbers, but one thing pops out pretty quickly: the machine has two IP addresses. When we were looking at the packet header we noticed the packet came from 192.168.1.102; that number appears in the unpacked data. But, so does another IP address. Immediately following our 192 number, we see another private IP address: 172.16.96.152. Groove is kind enough to let us know what both IPs are.
So why does this matter ? When doing internal penetration tests, we often have scenarios where in order to get the the PCI data or other sensitive data, VPNs are being used. If we want to find hosts that are connected, and Groove is running in the environment, we simply need to listen to the Groove announcements in order to find the hosts we want to target. This will also help us identify users that are running VMs, may have wireless enabled, or are in some other way acting as a potential bridge to other networks.
Going through this process for every packet is tedious: a task nobody wants to do. Scripting this for each exercise seems like a waste of time. So, on the webcast on Thursday, we are going to be talking the Passive Information Gathering or PIG modules for Metasploit that were released at DEF CON last year. We'll look at how to practically use these modules to gather this information about your network, as well as how to extend and contribute back any new protocols that you may find useful while penetration testing or doing systems administration.
If you'd like to see how to do all of this more easily, watch the webcast for a demonstration of how PIG works.
