macof.py is now available

In this article:

macof.py is now available

macof.py is a MAC address table overflow utility.

The traditional tool for MAC table overflow attacks is macof from the dsniff project. However I was not satisfied with this tool.

In particular:

macof has no rate limit mechanism, it sends the packets as fast as the local CPU and the network adapter can support it.

This leaves no room for a proper interception of users data.
Half of the packets generated by macof violates the Ethernet protocol by having the multicast bit set on the sender’s MAC address.

As a result, these packets are considered corrupted and silently dropped by the first encountered switch.

In other words, half of the packets generated by macof are generated for nothing.
macof constantly uses random MAC addresses for generated packets, meaning that a given source MAC address is rarely used more than once.

This means that switches’ MAC table aging system will regularly clean the table from all malicious entries. Of course, the table will fill up again in a few seconds, but these seconds may be enough for the switch to learn a few more legitimate addresses. As a result data destined to these addresses won’t be broad-casted anymore.

In other words the interception process is, here again, unreliable.

Most of these issues are probably due to the fact that this tool is now quite old and seemingly unmaintained (last update in 2000).

I therefore decided to implement my own version, macof.py, compatible with most options from dsniff’s macof:

macof.py allows to tune the frame emission rate to minimize the impact on the attacker’s host and the network resources as much as possible.

This offers a more reliable propagation of the forged MAC addresses throughout the switched network and a more efficient interception of broadcast data.
macof.py sends only valid frames, effectively updating switches MAC address tables.
macof.py first locally pre-generates a certain amount of Ethernet frames, each with a unique random source MAC address, and then replays this same set of frames in loop for all the attack duration.

This effectively simulate genuine devices activity, forcing the switches to regularly reset the associated aging-timers, keeping their MAC address table filled without interruption.

In addition macof.py functionalities can be easily included in larger Python projects.

Get it

macof.py is freely available (GPL v3).

Latest news on the project can be found on the project’s main page.

Install it

macof.py and its accompanying man page can be installed system-wide using the following commands:

install -m 755 -D -t /usr/local/bin ./macof.py
mkdir -p /usr/local/share/man/man1
gzip -c ./macof.py.1 >/usr/local/share/man/man1/macof.py.1.gz

Documentation

The macof.py(1) man page describes macof.py usage and options. It also provides advices and examples covering the most common use-cases.
You can also read this practical use-case, part of a series on network layer 2 exploitation and protection.

Report an issue

Please send bug reports to the macof.py issues page on GitHub.

The main practical difference between a legacy hub and a switch is that the switch will do its best to forward ethernet frames only on the port allowing to reach the recipient, it won’t blindly forward everything everywhere as as a dumb hub would do.

To achieve this, upon reception of a frame the switch stores the senders MAC address associated to its input port in an internal memory, usually implemented as a CAM table. Thanks to this information, would a packet have the same address as recipient, the switch will now forward this packet only to this port and not the other ones.

I already wrote a more focused article on MAC table overflow within the context of GNS3 simulated environments, which resulted in patch being submitted upstream and initiated the development of the macof.py tool. The original article is available here.

In this article I detailed …

Continue

How to build a virtual pentest lab

Standalone virtual machines are both a cheaper and more practical solution to test systems as they doesn’t need to dedicate hardware and are easier to handle than physical installation (actions such as cloning, doing a snapshot or a rollback become trivial).

Network virtualization goes a step further and apply the same system to a whole network, including workstations, servers, and all networking devices such as switches, routers and firewalls. A virtual network can be of any size and topology, and can mimic any real-life situation such as Active Directory domains, remote-access or site-to-site VPNs or test protocols of every network plane.

Such virtual network can be either fully isolated or have one or several link to physical devices and networks, its all up to you to decide.

Hardware

Prerequisites

The goal of a virtual lab is to be able to quickly setup the environment which will allow you to …

Continue

Practical network layer 2 exploitation: passive reconnaissance

This post is part of a series about practical network layer 2 exploitation.

Now is the time to change your network administrator hat for the attacker one. Your own, known network now becomes an unfamiliar target.

Before rushing and banging against the nearest devices, it may wiser to just stand back and listen.

On switched networks, users are somewhat isolated from each other thanks to the separation of collision domains. All that remain is some kind white noise… but this white noise in itself can bring invaluable information to an attacker!

In particular we will see how, simply by passively listening to this white noise, an attacker will be able to detect several weaknesses affecting the network and plan his next steps.

In this lab no interaction will occur with either the Admins or the Servers VLANs, the User_1 workstation will be required only for the DHCP Discover messages part …

Continue

Spanning Tree Protocol exploitation

As we saw in the previous post, Wireshark revealed us the presence of STP messages.

The Spanning Tree Protocol is used to detect topology loops and build the most efficient forwarding path between interconnected switches. Topology loops are not a mistake but a way to add redundancy to a topology. Would a link break, the STP protocol detects it and recalculate a new most efficient tree.

In sane networks, access ports should not deliver STP messages to end-devices, but this is not the default and, as Wireshark told us, not the case in our lab. This lets the attacker the possibility to simulate a topology change by sending maliciously crafted STP messages.

For this lab we will need at least the User_1 and Server_1 devices to be available:

STP lab topology

Warning

The support of STP in the IOU images I tested was very buggy, STP port state was ignored and frames systematically …

Continue

Introduction to z/OS and IBM mainframes world and security

Mainframes are often designated as “legacy platforms”. This triggers the mental image of those old 80’s era enormous bulky computers which can be found in any good computers museum and vintage videos, and leaves a mixed feeling about the place of such machines in todays computing world.

However, nothing could be such wrong:

A lot of the technologies which made today’s computing what it is actually owe to the mainframe world.

Things like non-executable memory, process isolation, virtualization and symmetric multiprocessing to name just a few are all technologies that were first developed for mainframes environments, and only then ported onto other architectures.
Today’s mainframes hardware has nothing in common with antique computers, they evolved as the rest of the computer world did.

They are bulky but not as much as one may imagine, the size of a large fridge to give a rough idea. They remains …

Continue

Popular tags ^{see all}

WhiteWinterWolf Practical IT security, *nix systems & networking