Apple at its "Let Loose" event today announced a new Magic Keyboard for the latest iPad Pro models, with a thinner, lighter design.
Apple says the Magic Keyboard has been redesigned to be thinner and lighter, while maintaing the same floating design.
Two colors are available that match the new iPad Pro. New features include a function row with screen brightness controls, an aluminum palm rest, and a larger trackpad with haptic feedback. Apple claims that thanks to the trackpad, working on iPad Pro "feels just like using a MacBook." The new Magic Keyboard can be pre-ordered today and will be available starting Wednesday, May 15, with the 11-inch model priced at $299 and the 13-inch version costing $349.
We want to verify connectivity and traffic flow towards:
Gateway of Server3.
Server1.
Server2.
Server4.
Let’s start with the gateway. The gateway is at 10.0.0.1 and has a MAC address of 0001.0001.0001:
server3:~$ ip neighbor | grep 10.0.0.1
10.0.0.1 dev bond0 lladdr 00:01:00:01:00:01 STALE
This is an anycast gateway MAC. When initiating a ping towards 10.0.0.1, it can go to either Leaf1 or Leaf2. I will run Ethanalyzer on the switches to confirm which one is receiving the ICMP Echo Request:
Leaf1# ethanalyzer local interface inband display-filter "icmp" limit-captured-frames 0
Capturing on 'ps-inb'
Leaf2# ethanalyzer local interface inband display-filter "icmp" limit-captured-frames 0
Capturing on 'ps-inb'
Then initiate ping from Server3:
server3:~$ ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=255 time=1.19 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=255 time=1.29 ms
^C
--- 10.0.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.192/1.242/1.292/0.050 ms
This is the effect of hashing on Server3. As anycast gateway is used, both switches can respond.
Now let’s ping Server2, which is connected to Leaf2:
server3:~$ ping 10.0.0.22
PING 10.0.0.22 (10.0.0.22) 56(84) bytes of data.
64 bytes from 10.0.0.22: icmp_seq=1 ttl=64 time=0.702 ms
64 bytes from 10.0.0.22: icmp_seq=2 ttl=64 time=0.847 ms
^C
--- 10.0.0.22 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1008ms
rtt min/avg/max/mdev = 0.702/0.774/0.847/0.072 ms
There’s two paths the packet can take here:
Server3 sends ICMP towards Leaf2 and Leaf2 switches the frame locally.
Server3 sends ICMP towards Leaf1 and Leaf1 switches it across the vPC peer link.
This is shown in the diagram below:
Leaf2 has the MAC address of Server2 locally:
Leaf2# show mac add add 0050.56ad.f48d
Legend:
* - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
age - seconds since last seen,+ - primary entry using vPC Peer-Link,
(T) - True, (F) - False, C - ControlPlane MAC, ~ - vsan,
(NA)- Not Applicable
VLAN MAC Address Type age Secure NTFY Ports
---------+-----------------+--------+---------+------+----+------------------
* 20 0050.56ad.f48d dynamic NA F F Eth1/3
Leaf1 has it across the vPC peer link:
Leaf1# show mac add add 0050.56ad.f48d
Legend:
* - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
age - seconds since last seen,+ - primary entry using vPC Peer-Link,
(T) - True, (F) - False, C - ControlPlane MAC, ~ - vsan,
(NA)- Not Applicable
VLAN MAC Address Type age Secure NTFY Ports
---------+-----------------+--------+---------+------+----+------------------
+ 20 0050.56ad.f48d dynamic NA F F vPC Peer-Link
Next, let’s try connectivity towards Server1:
server3:~$ ping 198.51.100.11
PING 198.51.100.11 (198.51.100.11) 56(84) bytes of data.
64 bytes from 198.51.100.11: icmp_seq=1 ttl=63 time=2.33 ms
64 bytes from 198.51.100.11: icmp_seq=2 ttl=63 time=2.48 ms
^C
--- 198.51.100.11 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 2.334/2.407/2.481/0.073 ms
Once again, there are two paths here:
Server3 sends ICMP towards Leaf1 and Leaf1 routes the packet and forwards it to Server1.
Server3 sends ICMP towards Leaf2 and Leaf2 routes the packet and forwards it across the vPC peer link.
This is shown in the diagram below:
There is a potential pitfall here, which I will describe in the next section, but first let’s look at when things are working. Leaf1 has a route locally:
Leaf1# show ip route 198.51.100.11 vrf Tenant1
IP Route Table for VRF "Tenant1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
198.51.100.11/32, ubest/mbest: 1/0, attached
*via 198.51.100.11, Vlan10, [190/0], 00:58:00, hmm
It also has the MAC address for 198.51.100.11 in the ARP cache:
Leaf1# show ip arp vrf Tenant1
Flags: * - Adjacencies learnt on non-active FHRP router
+ - Adjacencies synced via CFSoE
# - Adjacencies Throttled for Glean
CP - Added via L2RIB, Control plane Adjacencies
PS - Added via L2RIB, Peer Sync
RO - Re-Originated Peer Sync Entry
D - Static Adjacencies attached to down interface
IP ARP Table for context Tenant1
Total number of entries: 3
Address Age MAC Address Interface Flags
10.0.0.22 00:04:01 0050.56ad.f48d Vlan20 +
10.0.0.33 00:00:26 828b.b6cf.badf Vlan20
198.51.100.11 00:02:05 0050.56ad.8506 Vlan10
Leaf2 also has a local route:
Leaf2# show ip route 198.51.100.11 vrf Tenant1
IP Route Table for VRF "Tenant1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
198.51.100.11/32, ubest/mbest: 1/0, attached
*via 198.51.100.11, Vlan10, [190/0], 00:05:20, hmm
Let’s check the ARP cache:
Leaf2# show ip arp vrf Tenant1
Flags: * - Adjacencies learnt on non-active FHRP router
+ - Adjacencies synced via CFSoE
# - Adjacencies Throttled for Glean
CP - Added via L2RIB, Control plane Adjacencies
PS - Added via L2RIB, Peer Sync
RO - Re-Originated Peer Sync Entry
D - Static Adjacencies attached to down interface
IP ARP Table for context Tenant1
Total number of entries: 3
Address Age MAC Address Interface Flags
10.0.0.22 00:01:09 0050.56ad.f48d Vlan20
10.0.0.33 00:02:34 828b.b6cf.badf Vlan20 +
198.51.100.11 00:04:14 0050.56ad.8506 Vlan10 +
Notice the plus sign in the Flags column which indicates that this ARP entry has been learned via CFS. This entry is reachable via Po12:
Leaf2# show fabric forwarding ip local-host-db vrf Tenant1
HMM host IPv4 routing table information for VRF Tenant1
Status: *-valid, x-deleted, D-Duplicate, DF-Duplicate and frozen,
c-cleaned in 00:08:01
Host MAC Address SVI Flags Physical Interface
* 10.0.0.22/32 0050.56ad.f48d Vlan20 0x420201 Ethernet1/3
* 10.0.0.33/32 828b.b6cf.badf Vlan20 0x420201 port-channel33
* 198.51.100.11/32 0050.56ad.8506 Vlan10 0x420201 port-channel12
Note that the entry is from HMM, while the entry for 198.51.100.44 is via BGP:
Leaf2# show l2route evpn mac-ip evi 10
Flags -(Rmac):Router MAC (Stt):Static (L):Local (R):Remote
(Dup):Duplicate (Spl):Split (Rcv):Recv(D):Del Pending (S):Stale (C):Clear
(Ps):Peer Sync (Ro):Re-Originated (Orp):Orphan (Asy):Asymmetric (Gw):Gateway
(Piporp): Directly connected Orphan to PIP based vPC BGW
(Pipporp): Orphan connected to peer of PIP based vPC BGW
Topology Mac Address Host IP Prod Flags Seq No Next-Hops
----------- -------------- --------------------------------------- ------ ---------- ---------- ---------------------------------------------------------
10 0050.56ad.8506 198.51.100.11 HMM L, 0 Local
10 0050.56ad.7d68 198.51.100.44 BGP -- 0 203.0.113.4 (Label: 10000)
The ARP suppression cache is also populated:
Leaf2# show ip arp suppression-cache detail
Flags: + - Adjacencies synced via CFSoE
L - Local Adjacency
R - Remote Adjacency
L2 - Learnt over L2 interface
PS - Added via L2RIB, Peer Sync
RO - Dervied from L2RIB Peer Sync Entry
Ip Address Age Mac Address Vlan Physical-ifindex Flags Remote Vtep Addrs
198.51.100.11 00:01:18 0050.56ad.8506 10 port-channel12 L
198.51.100.44 1d15h 0050.56ad.7d68 10 (null) R 203.0.113.4
10.0.0.33 00:00:09 828b.b6cf.badf 20 port-channel33 L
10.0.0.22 00:00:09 0050.56ad.f48d 20 Ethernet1/3 L
Finally, let’s ping Server4, which is connected to Leaf4:
server3:~$ ping 198.51.100.44
PING 198.51.100.44 (198.51.100.44) 56(84) bytes of data.
64 bytes from 198.51.100.44: icmp_seq=1 ttl=62 time=21.3 ms
64 bytes from 198.51.100.44: icmp_seq=2 ttl=62 time=5.92 ms
^C
--- 198.51.100.44 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 5.924/13.631/21.338/7.707 ms
There are several paths the packet can take:
Server3 sends ICMP towards Leaf1 and Leaf1 routes the packet towards Leaf4.
Server3 sends ICMP towards Leaf2 and Leaf2 routes the packet towards Leaf4.
This is shown in the diagram below:
Note that Leaf4 can send the packet both towards Leaf1 and Leaf2 based on ECMP for the Anycast VTEP.
Leaf1 and Leaf2 both have a route to 198.51.100.44 via Leaf4:
Leaf1# show ip route 198.51.100.44 vrf Tenant1
IP Route Table for VRF "Tenant1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
198.51.100.44/32, ubest/mbest: 1/0
*via 203.0.113.4%default, [200/0], 5d19h, bgp-65000, internal, tag 65000, segid: 10001 tunnelid: 0xcb007104 encap: VXLAN
Leaf2# show ip route 198.51.100.44 vrf Tenant1
IP Route Table for VRF "Tenant1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
198.51.100.44/32, ubest/mbest: 1/0
*via 203.0.113.4%default, [200/0], 5d20h, bgp-65000, internal, tag 65000, segid: 10001 tunnelid: 0xcb007104 encap: VXLAN
The route is from EVPN:
Leaf1# show bgp l2vpn evpn 198.51.100.44
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 192.0.2.6:32777
BGP routing table entry for [2]:[0]:[0]:[48]:[0050.56ad.7d68]:[32]:[198.51.100.44]/272, version 8
Paths: (2 available, best #1)
Flags: (0x000202) (high32 00000000) on xmit-list, is not in l2rib/evpn, is not in HW
Advertised path-id 1
Path type: internal, path is valid, is best path, no labeled nexthop
Imported to 3 destination(s)
Imported paths list: Tenant1 L3-10001 L2-10000
AS-Path: NONE, path sourced internal to AS
203.0.113.4 (metric 81) from 192.0.2.11 (192.0.2.1)
Origin IGP, MED not set, localpref 100, weight 0
Received label 10000 10001
Extcommunity: RT:65000:10000 RT:65000:10001 ENCAP:8 Router MAC:00ad.7083.1b08
Originator: 192.0.2.6 Cluster list: 192.0.2.1
Path type: internal, path is valid, not best reason: Neighbor Address, no labeled nexthop
AS-Path: NONE, path sourced internal to AS
203.0.113.4 (metric 81) from 192.0.2.12 (192.0.2.2)
Origin IGP, MED not set, localpref 100, weight 0
Received label 10000 10001
Extcommunity: RT:65000:10000 RT:65000:10001 ENCAP:8 Router MAC:00ad.7083.1b08
Originator: 192.0.2.6 Cluster list: 192.0.2.2
Path-id 1 not advertised to any peer
Leaf2# show bgp l2vpn evpn 198.51.100.44
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 192.0.2.6:32777
BGP routing table entry for [2]:[0]:[0]:[48]:[0050.56ad.7d68]:[32]:[198.51.100.44]/272, version 8
Paths: (2 available, best #1)
Flags: (0x000202) (high32 00000000) on xmit-list, is not in l2rib/evpn, is not in HW
Advertised path-id 1
Path type: internal, path is valid, is best path, no labeled nexthop
Imported to 3 destination(s)
Imported paths list: Tenant1 L3-10001 L2-10000
AS-Path: NONE, path sourced internal to AS
203.0.113.4 (metric 81) from 192.0.2.11 (192.0.2.1)
Origin IGP, MED not set, localpref 100, weight 0
Received label 10000 10001
Extcommunity: RT:65000:10000 RT:65000:10001 ENCAP:8 Router MAC:00ad.7083.1b08
Originator: 192.0.2.6 Cluster list: 192.0.2.1
Path type: internal, path is valid, not best reason: Neighbor Address, no labeled nexthop
AS-Path: NONE, path sourced internal to AS
203.0.113.4 (metric 81) from 192.0.2.12 (192.0.2.2)
Origin IGP, MED not set, localpref 100, weight 0
Received label 10000 10001
Extcommunity: RT:65000:10000 RT:65000:10001 ENCAP:8 Router MAC:00ad.7083.1b08
Originator: 192.0.2.6 Cluster list: 192.0.2.2
Path-id 1 not advertised to any peer
Leaf4 has a local route for 198.51.100.44:
Leaf4# show ip route 198.51.100.44 vrf Tenant1
IP Route Table for VRF "Tenant1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
198.51.100.44/32, ubest/mbest: 1/0, attached
*via 198.51.100.44, Vlan10, [190/0], 9w2d, hmm
It is also known in the ARP cache:
Leaf4# show ip arp vrf Tenant1
Flags: * - Adjacencies learnt on non-active FHRP router
+ - Adjacencies synced via CFSoE
# - Adjacencies Throttled for Glean
CP - Added via L2RIB, Control plane Adjacencies
PS - Added via L2RIB, Peer Sync
RO - Re-Originated Peer Sync Entry
D - Static Adjacencies attached to down interface
IP ARP Table for context Tenant1
Total number of entries: 1
Address Age MAC Address Interface Flags
198.51.100.44 00:04:01 0050.56ad.7d68 Vlan10
With connectivity verified, in the next blog post we’ll take a brief look at fabric peering.
Virtual private networking (VPN) companies market their services as a way to prevent anyone from snooping on your Internet usage. But new research suggests this is a dangerous assumption when connecting to a VPN via an untrusted network, because attackers on the same network could force a target’s traffic off of the protection provided by their VPN without triggering any alerts to the user.
Image: Shutterstock.
When a device initially tries to connect to a network, it broadcasts a message to the entire local network stating that it is requesting an Internet address. Normally, the only system on the network that notices this request and replies is the router responsible for managing the network to which the user is trying to connect.
The machine on a network responsible for fielding these requests is called a Dynamic Host Configuration Protocol (DHCP) server, which will issue time-based leases for IP addresses. The DHCP server also takes care of setting a specific local address — known as an Internet gateway — that all connecting systems will use as a primary route to the Web.
VPNs work by creating a virtual network interface that serves as an encrypted tunnel for communications. But researchers at Leviathan Security say they’ve discovered it’s possible to abuse an obscure feature built into the DHCP standard so that other users on the local network are forced to connect to a rogue DHCP server.
“Our technique is to run a DHCP server on the same network as a targeted VPN user and to also set our DHCP configuration to use itself as a gateway,” Leviathan researchers Lizzie Moratti and Dani Cronce wrote. “When the traffic hits our gateway, we use traffic forwarding rules on the DHCP server to pass traffic through to a legitimate gateway while we snoop on it.”
The feature being abused here is known as DHCP option 121, and it allows a DHCP server to set a route on the VPN user’s system that is more specific than those used by most VPNs. Abusing this option, Leviathan found, effectively gives an attacker on the local network the ability to set up routing rules that have a higher priority than the routes for the virtual network interface that the target’s VPN creates.
“Pushing a route also means that the network traffic will be sent over the same interface as the DHCP server instead of the virtual network interface,” the Leviathan researchers said. “This is intended functionality that isn’t clearly stated in the RFC [standard]. Therefore, for the routes we push, it is never encrypted by the VPN’s virtual interface but instead transmitted by the network interface that is talking to the DHCP server. As an attacker, we can select which IP addresses go over the tunnel and which addresses go over the network interface talking to our DHCP server.”
Leviathan found they could force VPNs on the local network that already had a connection to arbitrarily request a new one. In this well-documented tactic, known as a DHCP starvation attack, an attacker floods the DHCP server with requests that consume all available IP addresses that can be allocated. Once the network’s legitimate DHCP server is completely tied up, the attacker can then have their rogue DHCP server respond to all pending requests.
“This technique can also be used against an already established VPN connection once the VPN user’s host needs to renew a lease from our DHCP server,” the researchers wrote. “We can artificially create that scenario by setting a short lease time in the DHCP lease, so the user updates their routing table more frequently. In addition, the VPN control channel is still intact because it already uses the physical interface for its communication. In our testing, the VPN always continued to report as connected, and the kill switch was never engaged to drop our VPN connection.”
The researchers say their methods could be used by an attacker who compromises a DHCP server or wireless access point, or by a rogue network administrator who owns the infrastructure themselves and maliciously configures it. Alternatively, an attacker could set up an “evil twin” wireless hotspot that mimics the signal broadcast by a legitimate provider.
ANALYSIS
Bill Woodcock is executive director at Packet Clearing House, a nonprofit based in San Francisco. Woodcock said Option 121 has been included in the DHCP standard since 2002, which means the attack described by Leviathan has technically been possible for the last 22 years.
“They’re realizing now that this can be used to circumvent a VPN in a way that’s really problematic, and they’re right,” Woodcock said.
Woodcock said anyone who might be a target of spear phishing attacks should be very concerned about using VPNs on an untrusted network.
“Anyone who is in a position of authority or maybe even someone who is just a high net worth individual, those are all very reasonable targets of this attack,” he said. “If I were trying to do an attack against someone at a relatively high security company and I knew where they typically get their coffee or sandwich at twice a week, this is a very effective tool in that toolbox. I’d be a little surprised if it wasn’t already being exploited in that way, because again this isn’t rocket science. It’s just thinking a little outside the box.”
Successfully executing this attack on a network likely would not allow an attacker to see all of a target’s traffic or browsing activity. That’s because for the vast majority of the websites visited by the target, the content is encrypted (the site’s address begins with https://). However, an attacker would still be able to see the metadata — such as the source and destination addresses — of any traffic flowing by.
KrebsOnSecurity shared Leviathan’s research with John Kristoff, founder of dataplane.org and a PhD candidate in computer science at the University of Illinois Chicago. Kristoff said practically all user-edge network gear, including WiFi deployments, support some form of rogue DHCP server detection and mitigation, but that it’s unclear how widely deployed those protections are in real-world environments.
“However, and I think this is a key point to emphasize, an untrusted network is an untrusted network, which is why you’re usually employing the VPN in the first place,” Kristoff said. “If [the] local network is inherently hostile and has no qualms about operating a rogue DHCP server, then this is a sneaky technique that could be used to de-cloak some traffic – and if done carefully, I’m sure a user might never notice.”
MITIGATIONS
According to Leviathan, there are several ways to minimize the threat from rogue DHCP servers on an unsecured network. One is using a device powered by the Android operating system, which apparently ignores DHCP option 121.
Relying on a temporary wireless hotspot controlled by a cellular device you own also effectively blocks this attack.
“They create a password-locked LAN with automatic network address translation,” the researchers wrote of cellular hot-spots. “Because this network is completely controlled by the cellular device and requires a password, an attacker should not have local network access.”
Leviathan’s Moratti said another mitigation is to run your VPN from inside of a virtual machine (VM) — like Parallels, VMware or VirtualBox. VPNs run inside of a VM are not vulnerable to this attack, Moratti said, provided they are not run in “bridged mode,” which causes the VM to replicate another node on the network.
In addition, a technology called “deep packet inspection” can be used to deny all in- and outbound traffic from the physical interface except for the DHCP and the VPN server. However, Leviathan says this approach opens up a potential “side channel” attack that could be used to determine the destination of traffic.
“This could be theoretically done by performing traffic analysis on the volume a target user sends when the attacker’s routes are installed compared to the baseline,” they wrote. “In addition, this selective denial-of-service is unique as it could be used to censor specific resources that an attacker doesn’t want a target user to connect to even while they are using the VPN.”
Moratti said Leviathan’s research shows that many VPN providers are currently making promises to their customers that their technology can’t keep.
“VPNs weren’t designed to keep you more secure on your local network, but to keep your traffic more secure on the Internet,” Moratti said. “When you start making assurances that your product protects people from seeing your traffic, there’s an assurance or promise that can’t be met.”
A copy of Leviathan’s research, along with code intended to allow others to duplicate their findings in a lab environment, is available here.
Some networking vendors realized that one way to gain mindshare is to make their network operating systems available as free-to-download containers or virtual machines. That’s the right way to go; I love their efforts and point out who went down that path whenever possible1 (as well as others like Cisco who try to make our lives miserable).
However, those virtual machines better work out of the box, or you’ll get frustrated engineers who will give up and never touch your warez again, or as someone said in a LinkedIn comment to my blog post describing how Junos vPTX consistently rejects its DHCP-assigned IP address: “If I had encountered an issue like this before seeing Ivan’s post, I would have definitely concluded that I am doing it wrong.”2
Log in
