Tor Relay, DNS and PiHole - Pumpkin and Honey Bunny

by Balhau

Tor Relay?

So...

In a previous post we had an overview about tor. We did a quick walk of what we can do with, and the main goals behind Tor's design, and also saw some weaknesses. Today we will explore some tools that give us interesting/useful data. A cheap and effective way to gather valuable information without actively go in the pursuit for it. But first, what is a tor relay?

Remember the previous conversation we had in which we described how tor manages our traffic from/to the destination server? So the relays are the middle man in the path. By following a tutorial like this we can also be a tor relay. In particular an exit tor relay.

In my particular case I setup one of my raspberry pi computer as a tor relay node. Things get interesting when we are a tor relay, more specifically a tor exit relay. There is no much interest when we act as middle relay because in this case we are just proxying encrypted traffic to another middle/exit tor relay. Not much you can get from here. When you are a tor exit relay this is all another talk.

Exit Relays - the Dark Side

First of all, the connection between the exit relay and the final service is not necessary encrypted. This brings the attention of a fair amount of hackers. Why? Ideally all communications should be done under the protection of https cryptography layer. Unfortunately not every web service has support for secure communications. This means that the communication between the service and the exit relay is not necessary encrypted, hence an easy target for man in the middle attacks.

Yeah. But we are pretty much secure beause Tor by default connects through https and http is very limited.

Well, you are more or less correct. Yeah more or less. The fact is that there are tools that can be configured on relay nodes that can exploit some vulnerabilities. Like these

  • Route https to http traffic
  • Spoof ssl certificates with fake ones

This is not a theoretical exercise, there are several articles like this one that concretely reports how and who are the tor relay exit nodes that try to spy on your traffic. More ssl is completely useless if you override the certificate chain mechanism and accept all https connections even when your client says the certificate is invalid. In many of the cases an invalid certificate is not of a big deal. It can just mean that the server didn't manage correctly the certification process and can, for instance, expire the certificate. On other situations an invalid certificate means that the one used to establish the communication is a fake one. This last means that you are under a MITM attack. There is no silver bullet for unconscious users without a minimal knowledge about cryptographic protocols.

DNS as Sherlock Holmes

But if you cannot (or want) to spy on users traffic, being a tor exit relay isn't so interesting, right?

Well, in fact it is. You know, being an exit node means that you need to proxy incoming tor requests to the destination endpoints/servers. But this implies a previous step. Yeah, you figure it out, we need to resolve the endpoint names.

What is the interest of this!?

Well if you spy on the name resolution you got two interesting features

  • You know who are the destination servers that your exit relay is connecting to
  • You don't spy the users content

And what's the point of that?

Well, you get a cheap way of finding interesting web services without an active and intrusive fiddling of the tor users data. This is ethical and very attractive from the discovery viewpoint of an hacker mind.

Yeah but surely that is a lot of trouble without guarantee return on the investment.

Actually, in my case, it isn't. To avoid ISP DNS denial of services in case of some specific domains (those that they don't like) and, mainly, to avoid name resolution for spamware related domains I had installed in the same raspberry pi a PiHole instance.

But wtf is PiHole? That sound's bad as hell...

Well PiHole is basically a dns server that has a big database of blacklisted domain names. This tool help you filter out most of the unwanted domains associated with shitty stuff.

Above you can have a peek over the pi-hole dashboard. Conceptually it is pretty simple. When a device asks for a name resolution for subdomain.domain.tld Pi-Hole will match it against his blacklist database and if it is there a match it will be resolved to the local internal ip of the pi-hole running machine. This will render the name resolution invalid, in practical terms.

The example above shows the blacklisting of the spam related domains.

Yeah sure but how is this related with the relay?

By setting up a node to run as a relay it will, sometimes, act as an exit relay and in this particular case it will need to resolve the service names. We just need to force it to use pi-hole. And turns out that this is pretty easy. You can set up your relay machine to use the node where pi-hole instance is running as a default dns resolver. But there is a better approach. If you manually set up the relay node to point to the pi-hole instance, you need to repeat this process any time you change pi-hole node. So a better approach consists of setting your router to resolve names through pi-hole instance. A very nice feature of this name resolution strategy is that computers usually delegate for the router this task. So if you set up the router to call the pi-hole instance instead of your ISP name servers you had done the trick.

So you use your dashboard to get interesting domains?

Well you can. But there is a better, and lightweight way. You can just 

tail -f /var/log/pihole.log

All the name resolution queries will be logged out to that file so you can just filter the contents and listen for interesting connections

    forwarded eddIe4.nl to 208.67.222.222
    query[A] eddIe4.nl from 192.168.1.1
    forwarded eddIe4.nl to 208.67.220.220
    forwarded eddIe4.nl to 208.67.222.222
    query[AAAA] EDdiE4.NL from 192.168.1.1
    forwarded EDdiE4.NL to 208.67.220.220
    forwarded EDdiE4.NL to 208.67.222.222
    reply eddIe4.nl is 87.233.192.220
    reply EDdiE4.NL is NODATA-IPv6
    query[PTR] 69.70.193.193.in-addr.arpa from 192.168.1.1
    cached 193.193.70.69 is NXDOMAIN
    query[PTR] 69.70.193.193.in-addr.arpa from 192.168.1.1
    cached 193.193.70.69 is NXDOMAIN
    query[AAAA] EXPLODiE.Org from 192.168.1.1
    forwarded EXPLODiE.Org to 208.67.220.220
    forwarded EXPLODiE.Org to 208.67.222.222
    reply EXPLODiE.Org is NODATA-IPv6
    query[A] WWw.hUO.Hr from 127.0.0.1
    forwarded WWw.hUO.Hr to 208.67.220.220
    forwarded WWw.hUO.Hr to 208.67.222.222
    reply WWw.hUO.Hr is <CNAME>
    reply hUO.Hr is 178.218.172.19
    query[AAAA] INFErno.dEMonOiD.oOo from 192.168.1.1
    forwarded INFErno.dEMonOiD.oOo to 208.67.220.220
    forwarded INFErno.dEMonOiD.oOo to 208.67.222.222
    query[AAAA] INFErno.dEMonOiD.oOo from 192.168.1.1
    forwarded INFErno.dEMonOiD.oOo to 208.67.220.220
    forwarded INFErno.dEMonOiD.oOo to 208.67.222.222
    reply INFErno.dEMonOiD.oOo is NODATA-IPv6
    query[A] query.yahooapis.com from 192.168.1.1
    forwarded query.yahooapis.com to 208.67.220.220
    forwarded query.yahooapis.com to 208.67.222.222
    query[A] query.yahooapis.com from 192.168.1.1
    forwarded query.yahooapis.com to 208.67.220.220
    forwarded query.yahooapis.com to 208.67.222.222

This is a very interesting way of discover and tinker with lots of new data.

It is true we find lots of shady name resolution. But with this technique I was also, able to find some nice services like these

Catching the Honey Bunny

It is not a secret that, for instance, xiaomi has their android smartphone os filled with spy background services. These are always connecting to the internet and sending whatever they way to their servers.

Since these services are deeply embedded in your operating system there is no much you can do right?

Well, not exactly. But first, a little bit of color. Lets call these dark services our honey bunny and lets try devise a strategy to minimize their action.

Yes, it is true that you cannot block them because they make part of the core miui os services. It gets worst. Whose services are these? How can you, in the first place, identify them? And even if you do, can you block them?

We could use a firewall right? And f4ck those background services?

Well for that to work the firewall would need to be placed at the router level since if you installed it on your smartphone they could have not power enough to block these services. More, even if you had this solved for one of your smartphones you would end up with the need to setup all the devices where our honey bunny lives.

There is a simple strategy, however. To connect to remote servers, our honey bunny needs first to resolve their names. So honey bunny needs to ask for their citizen card which, in technical terms, consists in a DNS resolution.

Isn't this hard work?

Well not exactly. DNS is build around a hierarchical concept so we could use this information to conclude that it these services should connect to something that respect the following pattern something.xiaomi.com. So we just need to find these something subdomains. And that is a trivial job

  cat /var/log/pihole.log | grep xiaomi.com

PiHole is a fairly chatty daemon. The process will log in /var/log/pihole.log all names resolution it was asked for. So, yes, we filter it

    query[A] weatherapi.market.xiaomi.com from 192.168.1.1
    forwarded weatherapi.market.xiaomi.com to 208.67.222.222
    reply weatherapi.market.xiaomi.com is <CNAME>
    reply internet.31cae9ccf4.elb.xiaomi.com is 47.74.139.151
    query[A] sdkconfig.ad.intl.xiaomi.com from 192.168.1.1
    forwarded sdkconfig.ad.intl.xiaomi.com to 208.67.222.222
    reply sdkconfig.ad.intl.xiaomi.com is 47.88.232.184
    query[A] f5.market.xiaomi.com from 192.168.1.1
    forwarded f5.market.xiaomi.com to 208.67.222.222
    reply f5.market.xiaomi.com is <CNAME>
    reply file.market.xiaomi.com.baishan-cloud.net is <CNAME>
    query[A] data.mistat.intl.xiaomi.com from 192.168.1.1
    /etc/pihole/gravity.list data.mistat.intl.xiaomi.com is 192.168.1.170
    query[A] api.ad.intl.xiaomi.com from 192.168.1.1
    forwarded api.ad.intl.xiaomi.com to 208.67.220.220
    forwarded api.ad.intl.xiaomi.com to 208.67.222.222
    query[A] api.ad.intl.xiaomi.com from 192.168.1.1
    forwarded api.ad.intl.xiaomi.com to 208.67.220.220
    forwarded api.ad.intl.xiaomi.com to 208.67.222.222
    reply api.ad.intl.xiaomi.com is <CNAME>
    reply internet.488b649984.elb.xiaomi.com is 47.74.139.176
    query[A] data.mistat.intl.xiaomi.com from 192.168.1.1
    /etc/pihole/gravity.list data.mistat.intl.xiaomi.com is 192.168.1.170
    query[A] account.xiaomi.com from 192.168.1.1
    forwarded account.xiaomi.com to 208.67.222.222
    reply account.xiaomi.com is <CNAME>
    query[A] game.xiaomi.com from 192.168.1.1
    forwarded game.xiaomi.com to 208.67.222.222
    query[A] i.xiaomi.com from 192.168.1.1
    forwarded i.xiaomi.com to 208.67.222.222
    reply game.xiaomi.com is <CNAME>
    reply i.xiaomi.com is <CNAME>
    query[A] i.xiaomi.com from 192.168.1.1
    cached i.xiaomi.com is <CNAME>

Fortunately pihole already does part of this job for us. For instance, for the case of data.mistat.intl.xiaomi.com we can see that the dns resolution had returned 192.168.1.170 which is the node where pihole is running. 

    data.mistat.intl.xiaomi.com is 192.168.1.170

And we can check that also on the web interface

If, for instance, you want to be a little more restricted and block other subdomains like api.ad.intl.xiaomi.com

Yeah but that will only work while you are at home right?

You're completely right! But there are some strategies you can adopt to circumvent this. One of them is to setup a vpn to your home and delegate the name resolution, again, for your router which is proxying dns calls to pihole. Or, if you can/want, expose the pihole dns service to the exterior and setup your device to resolve names through it.