Fooling wired Network Access Control - IT SeCX

Transcription

IT Security
Fooling wired Network Access Control
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
Fooling wired Network Access Control | ITSeCX 2014 | Bernhard Thaler, BSc
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
today we are not talking about featu
we are interested in the „secrity tech
your switches
e.g. Port-Security, 802.1X
 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
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
Source: http://commons.wikimedia.org/wiki/File:CCTV-Lysaker.jpg
 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“
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-dot1xlinks
 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-19presentations/Duckwall/DEFCON-19-DuckwallBridge-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-themiddle
 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
Initial Authentication
Time
„NORMAL“ ETHERNET FRAMES FLOW
Re-Authentication
Images based on: http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/identitybased-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
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
Source: http://standards.ieee.org/getieee802/download/802.1D-2004.pdf
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
LIVE-DEMO
LIVE-DEMO
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-themiddle 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
 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/identitybased-networking-services/deploy_guide_c17-663760.html
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/identitybased-networking-services/deploy_guide_c17-663760.html
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
Source: http://standards.ieee.org/getieee802/download/802.1AE-2006.pdf
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 - IT SeCX

Transcription

Similar documents

Proceedings of the Seminars Future Internet

Das NeulandMAGAZIN Nr. 34 • Frühling 2007