AVG (the encrypted DNS puzzle)

Security at home is a challenge... Organisations have a wide range of technologies to protect/assess/interpret/defend/respond, but in most cases at a significant cost. Most home users are left with an ISP-provided router/firewall and a hope that it protects them from attacks. The sad reality is that at best it protects against simple incoming network threats and does very little (if anything at all) to protect against threats within your network. Being a security consultant you try to find a middle ground, using the tools available to you in order to keep your skills sharp while observing what the technology you use does behind the scenes. On occasion though, you spot something out of the ordinary...

The Initial Alert

One of the many techniques for monitoring communication on a network is to capture the DNS requests being sent from each device. These requests are used primarily to convert a domain name (i.e., lifeofstu.com) to a usable IP address. You can approach this type of capture typically by running your own DNS server and logging the requests (tip: PiHole is great for this and allows you to block a lot of advertising on the internet), or you can examine each packet traversing the network to see if its a DNS request and subsequently log its details. The latter has the advantage that it catches 'DNS Bypass', whereby a system ignores the local DNS you have specified it to use and instead tries to contact its own one directly. In my environment I take both approaches, and have detections/alerting covering both.
One of the detections I have configured is around encrypted DNS, as in theory none of my systems should be trying to hide their DNS requests. I was surprised when the alert triggered on not one but two of my devices, one of which is used very little. Immediately I needed to figure out what was happening as the last thing anyone wants is their data to exfiltrated.

A Closer Look

Knowing that the alert had triggered for two systems helped me narrow down the scope somewhat. They were both Apple devices (albeit used for different purposes), and were both on separate (isolated) networks (so lateral movement/infection between them was unlikely). The list of applications that each device has installed is also significantly different, which would make tracking down the source application somewhat more difficult. Examining the logs at least highlighted where the data was being sent, even if the payload was encrypted. Validating the results by means of a packet capture from a different system confirmed that the DNS data was definitely encrypted and wasn't due to a bad initial capture. Examining the reverse DNS entry for the target IP addresses revealed that these belong to AVG, which while breathing a sigh of relief initially, didn't fill me with confidence.

An Email Conversation

It took a few emails with AVG to get clarification on what the encrypted traffic is, though you have to take it at face value... After enquiring about why I was seeing encrypted DNS traffic bypassing the local DNS server and trying to send to them directly I was informed that its part of their Internet Security package, specifically for Web/Mail/Payments. On the one hand I can see why their app would need frequent contact with their servers in order to ascertain if a site is legitimate, however in some cases (during testing) the requests I was capturing heading outbound were when I didn't have a browser open and was in fact opening standalone applications that require no internet access (and don't even try, as that is also logged separately). With no ability to read the encrypted data, you can't be certain as to what information is being sent. The only provided resolution by AVG was to disable the functionality of their app, the parts that were being paid for (the main differentiator between free and paid).

The Frustrations

At this point it's easy to think: Why is this even a problem? It's your anti-virus doing its job!... The problem here is that of how can you be sure that it is doing what it says it is? From an organisational standpoint, internal systems should never be able to communicate to external systems directly (wherever possible), and if they do, the details of what is being sent should be logged and checked accordingly. For DNS, centralised servers are used to capture each request and block as required (while also being logged and examined). For applications that require API communication they typically go via a proxy rather than direct, where an organisation can intercept the traffic and decrypt it before it leaves the network, ensuring that bad things aren't happening.
Here, this isn't possible due to the nature of how the data is being sent. It isn't possible to put a proxy in front because it isn't using industry standard REST requests, it's deliberately encrypting its payload and attempting to send direct, bypassing the common security measures that you would see within an organisation. Worse, if you don't like this approach of hiding data (and aren't willing to turn a blind eye), you have to disable the functionality you are paying for. From an audit perspective, turning a blind eye gets you into a very bad place, and allowing encrypted traffic out of your organisation with no way to verify what it actually contains, especially from potentially tens of thousands of systems, also isn't something that ends well.
Over the years we have seen that apps capture data they shouldn't (and that users weren't aware of), only to send it to a 3rd-party covertly. It wasn't that long ago that a certain company was found to be capturing the SSIDs of wireless networks wherever you were with your phone, and sending the data to their servers. It's also commonplace to see anti-virus software targeted by attackers as a means to an end, which further increases the risk of bad things happening with your data.

The Future

As the world is becoming all to familiar with supply chain attacks and data breaches in large organisations, the approach companies take (and the transparency to said approaches) has to change. Applications that attempt to sneak data out of an environment and don't provide a means to check what that data is should be prevented from releasing/publishing, as not only do they lack transparency to the end-user/organisation, they are taking an approach of security by obscurity which frankly provides a false sense of security to all involved.