fooling wired network access control

IT Security

Fooling wired Network Access Control

Bernhard Thaler, BSc

Fooling wired Network Access Control | ITSeCX 2014 | Bernhard Thaler, BSc

whoami

Bernhard Thaler

studied at Fachhochschule St. Pölten

University of Applied Sciences

working in a CERT team of a major

Austrian IT service provider

special interests

OSI Layer 2 and 3 related topics

OS Hardening (Linux, Windows)

Web App Penetration Testing


Why are we here?

You

obviously because you are interested in network security

maybe you are operating a NAC solution

you are interested in security testing, breaking into networks

and/or physical penetration testing

Me

want to raise awareness for an already discussed method of

bypassing NAC controls (first presented in 2004)

deep-dived into the topic while working on my master thesis

will perform a LIVE DEMO at the end to demonstrate a tool I

developed for testing NAC solutions


What‘s NAC?

NAC = Network Access Control

Primary goal

make it harder / impossible for malicious insiders to use foreign

hardware / rogue devices in your network

malicious insiders ?= your employees

make sure your networked devices comply with all your policies

various proprietary holistic NAC solutions by different

vendors (e.g. Cisco NAC, Microsoft NAP, …)

NAC world commonly categorized in 2 types of solutions

pre-admission NAC

post-admission NAC

today we are not talking about features, pro / cons of NAC solutions of different vendors

we are interested in the „secrity technologies“ these solutions use to secure the network on

your switches

e.g. Port-Security, 802.1X


Pre-Admission NAC

test if you are allowed / eligible to use the network when you

initially connect

e.g. some NAC solution with 802.1X based enforcement

you connect your system to a network

you need to pass 802.1X authentication successfully

(you may need to pass some added security checks concerning your

systems integrity and compliance to company policy)

you will get access to a static or dynamically assigned VLAN

you can use the network because your are „allowed“ to

periodic re-authentication assures that „you are still who you

say you are“

above process repeated as scheduled by policy (e.g. every hour)


Pre-Admission NAC

Pro

widely available; standardized technologies such as 802.1X or

others may be used

allow for thorough checks directly when you try to access the

network the first time

Con

you will need to set up some means for per-user auth (password)

or strong auth (certificates)

you may need some type of agent on every device for thorough

checks

that may be especially bad in ever increasing BYOD scenarios


Post-Admission NAC

initially allows access to the network

monitors device behavior

maybe monitors the type of traffic

a device creates

maybe monitors which resources

a device tries to access

maybe looks for „signs of compromise“

of a network device

restricts access to the network as soon as it thinks your device

„behaves badly“ or „does not comply“

Source: http://commons.wikimedia.org/wiki/File:CCTV-Lysaker.jpg


Post-Admission NAC

Pro

analyzes information from sensors such as IDS/IPS, NetFlow,

event correlation on SIEMs for you

maybe allows for detection of compromised endpoints beyond

compliance checking

especially interesting for BYOD environments where you may not

be able to put an „agent“ / authentication on foreign devices

Con

AFAIK not yet standardized; detection quality may be very

dependent on actual implentation / vendor dependent

apparently you need to put some sensors in your network to

collect data needed for behavior analysis

„behavior analysis“ maybe evadable (same as for IPS)


Trusted Network Connect (TNC)

Trusted Computing Group (TCG) has released an

„interoperatibilty specification“ giving an overview of

components of NAC deployments

we focus on Network Access Enforcer

Source: http://www.trustedcomputinggroup.org/resources/tnc_architecture_for_interoperability_specification


Wired NAC

focus on „wired NAC“

we will talk about classic wired LAN

(sorry no WLAN today )

you may assume that an attacker already

has physical access to one of your network

plugs / networked systems

attacker will „drop“ a box to perform a

physical man-in-the-middle attack between

one of your networked systems and the

network plug


That could not possibly happen?!

so you have none of these / all of these properly secured?

unlocked office spaces, unattended notebooks plugged into the

network (even when in standby), ….

printers in (semi-)public spaces such as hallways

(semi-public) info-terminals, Kiosk-PCs, …

time registration / access terminals

mounted access points

Source: http://commons.wikimedia.org/wiki

/File:Access-point-wireless.jpg


OK…but what‘s the problem here?

attacker has access to one of your network endpoints, so what?

well (NAC-)secured office PC / notebook

your users may notice a second, unknown notebook on their desk

they will raise an alarm, no intrusion possible

not-so well secured networked device (e.g. printer)

unplug the device, fake its MAC and IP and put in a foreign device

your users will notice (why is the printer not working any more?!)

no way an attacker will be successful / stay undected long term


We clearly need a more stealthier attack

we need an attack methodology able to

use our rogue / foreign device within the network

bypass any pre-admission NAC-type restriction in place

have the legitimate victim device still be reachable so nobody will

alert just because of this

be as stealthy / undetected as possible and maybe able to

remote control our rogue device from outside the building

an attack like this is already known since 2004 and was

gradually improved by various authors

let‘s go through history and attribute authors for their great work

(i hope I didn‘t forget to mention anybody)


Related Work

2004 Svyatoslav Pidgorny published an article

„Getting Around 802.1x Port-based Network Access

Control Through Physical Insecurity”

http://sl.mvps.org/docs/802dot1x.htm

Proposed attack

use an Ethernet-Hub to share an authenticated 802.1X

connection between two devices

fake MAC and ip address of authenticated device

be able to use stateless protocols (ICMP, UDP) and in

some cases TCP to interact with network

at the time / with the tools of the time a great idea


Related Work

2011 Alexandre Bezroutchko from Gremwell

Security released a tool called „Marvin“

„Tapping 802.1x Links with Marvin”

http://www.gremwell.com/marvin-mitm-tapping-dot1x-

links

great Man-in-the-Middle Tool for in-person testing

testing man-in-the-middle attacks on fat clients

wire-tapping in 802.1X-secured environments

even had a nice and easily comprehensable GUI

currently no active development as it seems


Related Work

2011 Skip Alva Duckwall gave an amazing talk at

Defcon 19

„A Bridge Too Far. Defeating Wired 802.1X with a

Transparent Bridge Using Linux”

great presentation going very much into detail

https://www.defcon.org/images/defcon-19/dc-19-

presentations/Duckwall/DEFCON-19-Duckwall-

Bridge-Too-Far.pdf

brought Pidgorny‘s attack to a new level

he demoed how to use a notebook / small computer

as a man-in-the-middle device within a 802.1X NAC

secured network


Related Work

Duckwall released a set of scripts as „8021xbridge“

https://code.google.com/p/8021xbridge/

his solution was obviously included in the great

„PwnieExpress“ PenTest devices as „NAC/802.1x

bypass“

unfortunately no active development on the

released scripts as it seems


Related Work

2014 Jan Kadijk started to work on a tool for NAC

bypass as well

„NAC-bypass (802.1x) or Beagle in the Middle”

http://shellsherpa.nl/nac-bypass-8021x-or-beagle-in-the-

middle

is using „BeagleBone Black“ and USB ethernet

devices to perform the attack

new idea for handling local subnet traffic to overcome

some of 8021xbridge‘s problems

released his code „BitM“ and recently started to

actively develop the tool further

unfortunately I got aware of his work in the middle

of my research and development


Back to the basics….

so we know there is some tools / scripts out there, but what are

they really doing?

I asked this question myself and started to do some research…

led to development of my tool „bypassNAC“ trying to

overcome problems / „lessons-learnt“ from other great tools

e.g. communication with host in local subnet directly instead of using the

default gateway as reflector (noisy ICMP redirects)

make it fit for modern networks ( IPv4 + IPv6 ready)

stay stealthy in order not to be detected by basic traffic analysis

due to easy patterns such as OS specific TCP Window Size, TCP Options,

TTLs, …

give the tool the required logic to auto-configure itself based on a

short dump of network traffic



How can an ethernet switch ensure traffic originates from the

authenticated device?

actually it can‘t

you perform the authentication step cryptographically secured

after authentication, there is nothing the authentication step is tied to

then you transmit „normal ethernet“ and IP packets without any

reference to the authentication step other than the MAC address used

for authentication

but both MAC and IP address can be easily spoofed



„NORMAL“ ETHERNET FRAMES FLOW

Initial Authentication

Re-Authentication

Tim

e

Images based on: http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/identity-

based-networking-services/deploy_guide_c17-663760.html



Hypothesis for 802.1X

after authentication you need to spoof the MAC and IP

address of the authenticated endpoint

authentication is valid until link-down event or deliberate log off

by endpoint (see 802.1X PAE Authenticator State Machine)

generally speaking

NAC solutions unable to securely/cryptographically link

transferred packets to authentication step will be prone to this

flaw


So all I need to do is to use a switch

and spoof addresses?

unfortunately it is not that easy

Have you ever put a „normal“ ethernet switch between the

802.1X Supplicant (legitimate device) and the Authenticator?

802.1X authentication is not working any more

EAP-Frames are transmitted but not forwarded by the switch


Source: http://standards.ieee.org/getieee802/download/802.1D-2004.pdf

So all I need to do is to use a switch

and spoof addresses?

the reason is 802.1D

there is a class of „reserved MAC addresses „ not allowed to be

forwarded

EAP-Frames use this one of these


Choose your hardware…

multiple network interfaces (2 or 3, Gigabit capable)

extensible (WLAN, 3G, <next-wireless-technology>)

reasonably cheap

small, inconspicuous, easily hideable

fanless

low power needs (battery packs!)

should run recent Linux kernel release

3.2: „group_fwd_mask“ to forward „reserved MAC addresses“

3.7: NAT66 needed for IPv6 scenarios

3.13: nftables is long term interesting for this attack


Choose your hardware…

PC Engines APU best fitted my needs

wanted to install KALI Linux effortlessly

work with recent kernels without cross-compiling /

applying vendor specific patches

good alternatives as well

MikroTik RB953GS-5HnT

GlobalScale Mirabox

very cheap (< EUR 30) alternatives (still testing them)

TP-Link TL-WR710N

NEXX WT3020H


The Operating System…

any Linux Distribution will do, recent kernel recommended

used Kali Linux due to the tools pre-installed you may need

in a security test

You will need to be able to set this kernel flag

e.g. „echo 49144 > /sys/class/net/br0/bridge/group_fwd_mask

allows forwarding of „reserved MAC addresses“


The Operating System…

just in case you need IPv6

iptables 1.4.17++ and kernel 3.7++ introduces NAT66

bug in the ethernet bridge module prevents successful

use of NAT66 on top of a bridge currently

developed a patch for the kernel and submitted it to

netfilter-devel but it is not yet in any kernel release

so for now you will need to patch manually

http://marc.info/?l=netfilter-devel&m=141081723815966&w=2

still working on this one…hopefully it will be adopted

in any of the next kernel releases by maintainers


Attack setup…

introduce rogue device (red)

connect to rogue device to use access to network


Where to hide rogue device?


„bypassNAC“ in a few words…

ethernet bridge to let the legitimate host traffic flow

„non 802.1D“ compliant to forward reserved MACs

Source NAT (SNAT to spoof MAC and IP addresses

traffic into the network

spoof the MAC and IP address of the legitimate host

traffic to legitimate client

spoof the MAC and IP address of any other routable IP

handle some traffic in userspace with Python and Scapy to

modify as needed


Some Preparations…

we will find out which addresses to SNAT to dynamically later

but need a source to SNAT from

should „invalid“ addresses not used in any network

using DOCUMENTATION networks should be safe

MAC: 00:00:5e:00:53:00

IPv4:192.0.2.1

IPv6:2001:db8:0:f101::1

set a default route to bridge device


traffic into the network

spoof the MAC and IP address of the legitimate host

SNAT from internal invalid addresses to addresses of legitimate client

(same for IPv6 but left out to keep graphic simple)


traffic to legitimate client

spoof the MAC and IP address of any routable host

SNAT from internal invalid addresses to any known address

(same for IPv6 but left out to keep graphic simple)


How to find out what to spoof?

dump the network traffic for a minute or so

a lot of interesting information to find

extract from seen packets

MAC address of the legitimate host

MAC address of the default gateway

IPv4/IPv6 address of the legitimate host

find out or calculate the local subnet IPv4/IPv6 network address


How to find out what to spoof?

MAC address of legitimate host

usually easy; it will be the one MAC on the host side of your bridge

simple some algorithms for MAC address of the gateway

MAC address that gets the most IP traffic

MAC address with the most different IP addresses associated

MAC address with the most IP packets with differing TTL values

MAC address with the most IP packets with uneven TTL values

IPv4/IPv6 address of legitimate host

the addresses the MAC address of the host uses most often


How to communicate with other hosts?

Problem

no „default gateway“ IP we can easily set / use

not even a „valid“ IP address set on our bridge

all we know is „the bridge can reach everything“

„invalid“ addresses and a default route to bridge interface make

IP stack think everything is reachable locally

need to handle ARP and NDP manually to imitate „routing“

original ARP and NDP packet does not leave device

is re-written or answered by script


„ARP/NDP“ Handler

to communicate with a a host in remote network, answer the

ARP request with the MAC address of the default gateway

to communicate with host in the local subnet

re-write the „invalid“ MAC and IP addresses in the ARP/NDP Payload

with addresses of legitimate client

send out the ARP request

wait for real reply and re-write it internally again

„noisy“ alternative

send everything to the default gateway and let him deliver the packets

he will answer with ICMP redirects (could attract attention)


Missing Link: Local Subnet address

need it to know

which traffic is destined for the local subnet

which traffic is destined for remote subnets

currently extracting local subnet address and subnet mask from

DHCP packets

SLAAC Router Advertisements

alternative

calculate local subnet based on already seen ARP requests

mis-calculation leads to ICMP redirect problem explained before


How to imitate the legitimate device?

fingerprinting tools such as „p0f“ could easily detect attack

injected packets

different ephemeral port ranges used by different operating systems

operating systems set different default TTLs (IPv4) / HLIM (IPv6)

TCP/IP stacks set different initial window size and use different options

in TCP SYN packets

need to „wash clean“ these values for every packet leaving

but need to extract „clean values“ to use from packet capture first

currently implemented with Python/scapy in Userland, so major

performance hit


LIVE-DEMO


Host services within the network…

using Destination NAT we can even host services / open

listening ports to the network

pose to be a webserver running on the legitimate device

lure any device in the network into downloading malicious content

pose to be any service on any routable IP to the legitimate host

make the legitimate host believe to download malicious code from a website

with high reputation

may cause some sleepless nights for incident responders and forensics

of course we can divert/redirect traffic as well to man-in-the-

middle it….


Conclusion

Don‘t panic, this is attack is not new (but maybe new for

some)

a new/somewhat improved tool on the horizon

security testers / network admins can hopefully use it in the

future to raise awareness of the issue

use Port-Security, 802.1X and NAC solutions wisely and

know about their shortcomings

take this attack into account when performing risk based

analysis / deciding about investments on security

technologies


Recommendations for environments with

„normal“ security needs

NAC only your first-line-of-defense

it secures your unused active network plugs

for your network plugs with active endpoints

you

need other layers of security

dedicated attacker will bypass your NAC

decide how much time and money to

invest into the NAC-solution

reserve time and money for further layers

of defense


Invest in „classic“ security practices

physical security

limit physical access to network plugs in public spaces (easy to say)

try to put them into VLANs not attached to any internal network

fine-grained network segmentation (e.g. using VLANs)

classify devices based on their access needs

segment them into own VLANs for basic protection

don‘t mix devices with good physical protection (employee PCs) with

semi-public devices (internet kiosk, printers, ..)

firewalling within the internal network

Do you have rules in place limiting traffic only to allowed paths?

e.g. your printer may not need to be able to reach your domain

controllers / servers on all ports but only some file and printer servers

e.g. not every employee will need access to all resources within the



physical security

limit physical access to network plugs in public spaces (easy to say)

try to put them into VLANs not attached to any internal network

fine-grained network segmentation (e.g. using VLANs)

classify devices based on their access needs

segment them into own VLANs for basic protection

don‘t mix devices with good physical protection (employee PCs) with

semi-public devices (internet kiosk, printers, ..)



strict firewalling within the internal network

limit attacker to uninteresting local subnet

only allow access to remote locations on a per-need basis

e.g. printer may not need to reach domain controllers on all ports but

only some file and printer servers on some ports

e.g. not every employee will need access to all resources within the

network

monitor network for anomalies (at least with basic tools)

use firewall logs (dropped packets) to gain visibility

activate (unsampled) NetFlows where possible for further insight

use SIEM (sort of) solutions to do correlation/alerting work for you


Recommendations for environments with

„high“ security needs

The measures already proposed do not fit your needs and you

have higher security needs…

make MAC and IP spoofing detectable

currently there are two viable alternatives

use a VPN technology such as IPSec on higher layers

e.g. Microsoft NAP with IPSec Enforcement Mode

use a technology such as 802.1X-2010 leveraging „MACSec“

„new“ revision of of the 802.1X standard

Unfortunately not so broadly supported on switch hardware / vendors


802.1X-2010 / 802.1AE („MACSec“)

„normal“ 802.1X authentication step

additional RADIUS attributes sent from AAA Server to

Authenticator

contain shared secret between Supplicant and AAA server

to secure key derivation in next steps with

Image based on: http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/identity-



802.1X-2010 / 802.1AE („MACSec“)

second step after authentication to derive key material

using MKA („MACSec“ Key Agreement) Protocol

derived key can be used to secure / authenticate ethernet

frames transmitted later on

Image based on: http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/identity-


Fooling wired Network Access Control | ITSeCX 2014 | Bernhard Thaler, BSc Source: http://standards.ieee.org/getieee802/download/802.1AE-2006.pdf

802.1X-2010 / 802.1AE („MACSec“)

key derived in 802.1X-2010 MAK key exchange can then

be used to integrity protect / encrypt every ethernet frame

switch will then only accept ethernet frames he is able to

link to authenticated entities

„simple“ MAC and IP spoofing will not work any more


Status of development of „bypassNAC“

as many security testing tools needs more work

works good in testbeds

was tested in some real world environments

needs further testing in different setups and NAC environments

has some already known bugs / shortcomings still to solve

currently a mix of BASH and Python leveraging iptables

Framework

plan to rewrite it to pure Python using nftables bindings

but for small plattforms (OpenWRT) BASH core and optional python

improvement scripts may be better architecture


Status of development of „bypassNAC“

will be released shortly (end of november)

https://github.com/bthaler/bypassNAC

want to clean code and fix some known issues

document all issues for discussion

prepare some how-to documentation

possibly implement some new ideas

if you need it earlier / urgently, drop me a line


Thank you for your attention!

Thank you to Mr. Johann Haag and FH St. Pölten

If you have any questions, please ask now or talk to me

privately…

fooling wired network access control

Documents