Date: Wed, 4 Dec 2019 22:37:33 -0800 From: Colm MacCárthaigh <colm@...costs.net> To: oss-security@...ts.openwall.com Subject: Re: [CVE-2019-14899] Inferring and hijacking VPN-tunneled TCP connections. I work on Amazon Linux, which enables reverse path filtering on all existing interfaces and is not impacted by this issue, however in examining this issue we did notice some additional areas that may be of heightened concern to operating systems or VPNs that are impacted. The report cleverly uses educated guesses about traffic and error messages to work its way up to injection of a packet into an open TCP connection. TLS on that TCP connection would thwart this attack, but it’s a significant combination of tactics with important security consequences. Unfortunately, by combining this issue with DNS spoofing, this issue can be improved upon into a more serious threat. Suppose that “service.company.corp” is a known service running on a corporate network, accessed by employees using roaming laptops, phones or other mobile devices. When an employee opens their laptop, some software may make queries for this DNS name in the background; and it may or may not resolve. That depends on whether the company publishes its internal DNS entries to a “public” DNS view. At this point an untrusted network (e.g. an access point that has been owned) could trivially poison the response, with a high-TTL entry, and control what the name resolves to. If they have the name resolve to an IP of their choosing, they can MITM the traffic. Because of this risk, it is normal for VPNs to flush the DNS cache when a VPN is established (my corporate laptop does this), or for DNS caches to be flushed when a system resolver is changed; and the threat is mitigated. CVE-2019-14899 resurrects this threat. Using the CVE-2019-14899, an untrusted network can watch for traffic patterns that correlate to a DNS request and a DNS reply. These are easy to profile based on size; and the exact plaintext even may already be known; either because the query was also made before the VPN was established, or because it’s not that hard to learn or guess the service naming details of a large corporate network. When the query and reply is observed, the encrypted packet containing the reply can be buffered and effectively “paused” by the untrusted network. The untrusted network can then use the UNM-BBG issue to spoof a large number of forged DNS replies towards the target for the query. Note that due to the UNM-BBG techniques the source IP and dest IP are likely known, and that DNS clients – especially stub resolvers – typically use a restricted port range. DNS requests and DNS replies have a queryid that must match, but this is only 16-bits in size. The number of replies that need to be sent to gain a match are measured as [stub resolver source port-range] * 2^16, which is likely in the 100s of millions. This would take 10s of seconds to transmit over a 1Gbit LAN.An attacker need only succeed once to “own” the DNS response for a period of their desire (they can set a high TTL on their spoofed responses). Wifi has much lower PPS (802.11ac is just 75k pps) and would take more attempts. Either way the numbers are well below the safety boundaries of a typical security protocol and an attacker may be able to gain control of “trusted” network DNS. Hijacking traffic via DNS is usually much more powerful than payload injection; for example an attacker can observe all connections but choose to target only connections that do not use TLS. This is more flexible and helps evade detection. Some notes: - DNS packets are often the “first” traffic in a sequence, and even when the size is obfuscated by padding, they can be identified through timing analysis alone. - DNS between stub resolvers and recursive resolvers is not protected by DNSSEC and DNSSEC does not thwart this attack. - Well-configured TLS does prevent poisoned DNS from being used to MITM TLS traffic, but there are gaps such as users over-riding warnings, or protocols not using TLS. - Some browsers and applications may keep their own DNS caches; if these DNS caches are not also flushed when VPNs are established, they are vulnerable to the other, older, issue. Although unrelated, this CVE may call attention to these issues. -- Colm
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.