Update: even the regex is not blocking this query from the phone.
There's clearly something here I'm not understanding!
There's clearly something here I'm not understanding!
Worth a try.
Install tcpdump:
sudo apt install tcpdump
And let below one run on Pi-hole for a while until your sure it captured one of those oooogles from the Samsung device (CTRL-C to break):
sudo tcpdump -l -nt -i eth0 udp port 53 > dnsdump.txt
And post results here for below one (replace the 10.0.0.2 IP address with the Samsung IP):
grep '^IP 10.0.0.2.*ogle.com' dnsdump.txt | tail -1 | awk '{print $7}' | hexdump
Not sure if its going to capture odd characters!
And a try from a normal computer with ping from a command line?
C:\WINDOWS\system32>ping gooogle.com
Ping request could not find host gooogle.com. Please check the name and try again.
C:\WINDOWS\system32>ping goooooooooooooooogle.com
Ping request could not find host goooooooooooooooogle.com. Please check the name...
C:\WINDOWS\system32>ping goooooooooooooooooooooooooooooooogle.com
Ping request could not find host goooooooooooooooooooooooooooooooogle.com. Please check...
C:\WINDOWS\system32>ping goooooooooooooooooooooooooooooooooooooooooooooooooooogle.com
Ping request could not find host goooooooooooooooooooooooooooooooooooooooooooooooooooogle.com.
The result as expected is here:
a www. before doesn't matter. Requests from Firefox are blocked too.
Oops. Right. And finally gooo+gle is sufficient too.
Interesting: Just tested with my Samsung Tab A6 via its browser and found that a few o's too much will lead to a query google.com, wich Pihole answers normally but the brower says 'Site not reachable' anyway. 
thanks! -- I've set that up under screen (and changed to wlan0 as it's a pizero-w). Waiting for an event now...
Thanks pisome. All those pings get blocked from a normal computer (192.168.0.6). In the log below, 192.168.0.205 is the samsung phone (and those get forwarded)
Feb 28 12:47:32 dnsmasq[14274]: query[A] www.goooooooooooooooooooooooooooooooooooooooooooooooooooooooooogle.com from 192.168.0.205
Feb 28 12:47:32 dnsmasq[14274]: forwarded www.goooooooooooooooooooooooooooooooooooooooooooooooooooooooooogle.com to 1.0.0.1
Feb 28 12:47:32 dnsmasq[14274]: reply www.goooooooooooooooooooooooooooooooooooooooooooooooooooooooooogle.com is <CNAME>
Feb 28 12:47:32 dnsmasq[14274]: reply goooooooooooooooooooooooooooooooooooooooooooooooooooooooooogle.com is 184.168.221.42
Feb 28 13:51:52 dnsmasq[14274]: query[A] goooooooooooooooogle.com from 192.168.0.6
Feb 28 13:51:52 dnsmasq[14274]: /etc/pihole/regex.list goooooooooooooooogle.com is 0.0.0.0
Feb 28 13:53:44 dnsmasq[14274]: query[A] goooooooooooooooooooooooooooooooogle.com from 192.168.0.6
Feb 28 13:53:44 dnsmasq[14274]: /etc/pihole/regex.list goooooooooooooooooooooooooooooooogle.com is 0.0.0.0
Feb 28 13:54:41 dnsmasq[14274]: query[A] goooooooooooooooooooooooooooooooooooooooooooooooooooogle.com from 192.168.0.6
Feb 28 13:54:41 dnsmasq[14274]: /etc/pihole/regex.list goooooooooooooooooooooooooooooooooooooooooooooooooooogle.com is 0.0.0.0
... and the result is
pi@raspberrypi:~ $ grep '^IP 192.168.0.205.*ooogle.com' dnsdump.txt | awk '{print $7}' | hexdump
0000000 7777 2e77 6f67 6f6f 6f6f 6f6f 6f6f 6f6f
0000010 6f6f 6f6f 6f6f 6f6f 6f6f 6f6f 6f6f 6f6f
*
0000030 6f6f 6f6f 6f6f 6f6f 6f6f 6f6f 6f6f 676f
0000040 656c 632e 6d6f 0a2e
0000048
so nothing unexpected as far as I can see.
Yeah if I do lookups for pi.hole and the oooooogle, I get below resulting dump:
pi@phb5:~ $ cat dnsdump.txt
IP 10.0.0.2.49531 > 10.0.0.4.53: 22090+ A? pi.hole. (25)
IP 10.0.0.4.53 > 10.0.0.2.49531: 22090* 1/0/0 A 10.0.0.4 (41)
IP 10.0.0.2.56056 > 10.0.0.4.53: 32445+ A? www.goooooooooooooooooooooooooooooooooooooooooooooooooooooooooogle.com. (88)
IP 10.0.0.4.53 > 10.0.0.2.56056: 32445 2/0/0 CNAME goooooooooooooooooooooooooooooooooooooooooooooooooooooooooogle.com., A 184.168.221.47 (184)
IP 10.0.0.2.51065 > 10.0.0.4.53: 37256+ A? pi.hole. (25)
IP 10.0.0.4.53 > 10.0.0.2.51065: 37256* 1/0/0 A 10.0.0.4 (41)
Running that through the grep results in same output as you:
pi@phb5:~ $ grep '^IP 10.0.0.2.*ogle.com' dnsdump.txt | tail -1 | awk '{print $7}' | hexdump
0000000 7777 2e77 6f67 6f6f 6f6f 6f6f 6f6f 6f6f
0000010 6f6f 6f6f 6f6f 6f6f 6f6f 6f6f 6f6f 6f6f
*
0000030 6f6f 6f6f 6f6f 6f6f 6f6f 6f6f 6f6f 676f
0000040 656c 632e 6d6f 0a2e
0000048
Outa ideas.
Does this help anything?
root@pi-hole:/var/log# cat a.txt
0000000 7777 2e77 6f67 6f6f 6f6f 6f6f 6f6f 6f6f
0000010 6f6f 6f6f 6f6f 6f6f 6f6f 6f6f 6f6f 6f6f
*
0000030 6f6f 6f6f 6f6f 6f6f 6f6f 6f6f 6f6f 676f
0000040 656c 632e 6d6f 0a2e
root@pi-hole:/var/log# xxd -r a.txt
ww.wogoooooooooooooooooooooooooooooooooooooooogoelc.mo
.root@pi-hole:/var/log# xxd -r a.txt | cat -v
ww.wogoooooooooooooooooooooooooo^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@oooooooooooooogoelc.mo
In this spirit I get
pi@raspberrypi:~ $ grep '^IP 192.168.0.205.*ooogle.com' dnsdump.txt | cat -v
IP 192.168.0.205.39504 > 192.168.0.32.53: 7 A? www.goooooooooooooooooooooooooooooooooooooooooooooooooooooooooogle.com. (88)
p
so no hidden characters coming up (how was a.txt generated?)
greping the text file may not be accurate, many things could try to normalize the chars. I'm wondering if there's some hidden IDN going on in the Samsung requests.
Back to google/duckduck 
Interesting:
pi@noads:~ $ whois goooooooooooooooooooooooooooooooooooooooooooooooooooooooooogle.com
[..]
Registrar: GoDaddy.com, LLC
Not surprising.
1 Like
Below one writes hex output:
sudo tcpdump -lntXq -i eth0 udp port 53 and src 192.168.0.205 > dnsdump.txt
Eg:
pi@phb5:~ $ cat dnsdump.txt
IP 10.0.0.2.33714 > 10.0.0.4.53: UDP, length 25
0x0000: 4500 0035 2aad 0000 4011 3c06 0a00 0002 E..5*...@.<.....
0x0010: 0a00 0004 83b2 0035 0021 03f7 207e 0100 .......5.!...~..
0x0020: 0001 0000 0000 0000 0270 6904 686f 6c65 .........pi.hole
0x0030: 0000 0100 01 .....
IP 10.0.0.2.49823 > 10.0.0.4.53: UDP, length 88
0x0000: 4500 0074 2bb8 0000 4011 3abc 0a00 0002 E..t+...@.:.....
0x0010: 0a00 0004 c29f 0035 0060 d983 57f8 0100 .......5.`..W...
0x0020: 0001 0000 0000 0000 0377 7777 3e67 6f6f .........www>goo
0x0030: 6f6f 6f6f 6f6f 6f6f 6f6f 6f6f 6f6f 6f6f oooooooooooooooo
0x0040: 6f6f 6f6f 6f6f 6f6f 6f6f 6f6f 6f6f 6f6f oooooooooooooooo
0x0050: 6f6f 6f6f 6f6f 6f6f 6f6f 6f6f 6f6f 6f6f oooooooooooooooo
0x0060: 6f6f 6f6f 6f6f 6f6f 676c 6503 636f 6d00 oooooooogle.com.
0x0070: 0001 0001 ....
I think it must be a malformed request. In the log segments below the request in the early hours of the morning was from the mysterious source on the phone (see below for the suspect), the one around midday was from a web browser on the same phone (chrome and firefox give the same result). Clearly the logs of the requests are identical, but the actions are very different. Interestingly, the ip address of the site has now changed from 184.168.221.42 to 50.63.202.61
Feb 29 02:52:00 dnsmasq[14274]: query[A] www.goooooooooooooooooooooooooooooooooooooooooooooooooooooooooogle.com from 192.168.0.205
Feb 29 02:52:00 dnsmasq[14274]: forwarded www.goooooooooooooooooooooooooooooooooooooooooooooooooooooooooogle.com to 1.0.0.1
Feb 29 02:52:00 dnsmasq[14274]: reply www.goooooooooooooooooooooooooooooooooooooooooooooooooooooooooogle.com is <CNAME>
Feb 29 02:52:00 dnsmasq[14274]: reply goooooooooooooooooooooooooooooooooooooooooooooooooooooooooogle.com is 50.63.202.61
Feb 29 12:09:09 dnsmasq[14274]: query[A] www.goooooooooooooooooooooooooooooooooooooooooooooooooooooooooogle.com from 192.168.0.205
Feb 29 12:09:09 dnsmasq[14274]: /etc/pihole/black.list www.goooooooooooooooooooooooooooooooooooooooooooooooooooooooooogle.com is 0.0.0.0
Here is the log from my unifi USG, which runs IPS blocking and seems to block this request successfully (but according to the above, it gets through, so maybe IPS is blocking something else that is sent out simultaneously)
Feb 29 02:52:00 USG kernel: IPS BLOCK: IN=eth1 OUT=pppoe0 SRC=192.168.0.32 DST=1.0.0.1 LEN=71 TOS=0x00 PREC=0x00 TTL=63 ID=24427 DF PROTO=UDP SPT=13718 DPT=53 LEN=51
Feb 29 02:52:03 USG kernel: IPS BLOCK: IN=eth1 OUT=pppoe0 SRC=192.168.0.32 DST=1.0.0.1 LEN=64 TOS=0x00 PREC=0x00 TTL=63 ID=24549 DF PROTO=UDP SPT=56758 DPT=53 LEN=44
Feb 29 02:52:03 USG kernel: IPS BLOCK: IN=eth1 OUT=pppoe0 SRC=192.168.0.32 DST=1.0.0.1 LEN=64 TOS=0x00 PREC=0x00 TTL=63 ID=24559 DF PROTO=UDP SPT=31422 DPT=53 LEN=44
Feb 29 02:52:03 USG kernel: IPS BLOCK: IN=eth1 OUT=pppoe0 SRC=192.168.0.32 DST=1.0.0.1 LEN=71 TOS=0x00 PREC=0x00 TTL=63 ID=24560 DF PROTO=UDP SPT=13718 DPT=53 LEN=51
The corresponding alert message is
IPS Alert 1: Potential Corporate Privacy Violation. Signature ET DNS Non-DNS or Non-Compliant DNS traffic on DNS port Reserved Bit Set. From: 192.168.0.32:29067, to: 1.0.0.1:53, protocol: UDP
The rest of the traffic from the phone during that second was (from the pihole log):
2020-02-29 02:52:00 A google.com galaxy-s10e.localdomain OK (forwarded)
2020-02-29 02:52:00 PTR 216.58.202.4.in-addr.arpa galaxy-s10e.localdomain OK (forwarded)
2020-02-29 02:52:00 SOA google.com galaxy-s10e.localdomain OK (forwarded)
2020-02-29 02:52:00 A google.com galaxy-s10e.localdomain OK (cached)
2020-02-29 02:52:00 A google.com galaxy-s10e.localdomain OK (cached)
2020-02-29 02:52:00 A google.com galaxy-s10e.localdomain OK (cached)
2020-02-29 02:52:00 A google.com.onion galaxy-s10e.localdomain OK (forwarded)
2020-02-29 02:52:00 A google.com galaxy-s10e.localdomain OK (cached)
2020-02-29 02:52:00 A google.com galaxy-s10e.localdomain OK (forwarded)
2020-02-29 02:52:00 A google.com galaxy-s10e.localdomain OK (forwarded)
2020-02-29 02:52:00 PTR 216.58.202.4.in-addr.arpa galaxy-s10e.localdomain OK (forwarded)
2020-02-29 02:52:00 A google.com galaxy-s10e.localdomain OK (forwarded)
2020-02-29 02:52:00 A *google.com galaxy-s10e.localdomain OK (forwarded)
2020-02-29 02:52:00 A www.goooooooooooooooooooooooooooooooooooooooooooooooooooooooooogle.com galaxy-s10e.localdomain OK (forwarded)
2020-02-29 02:52:00 A google.com galaxy-s10e.localdomain OK (forwarded)
That google.com.onion request looks odd too. I found this and this which shed some light. By this evidence, the underlying culprit seems to be a Samsung tool called MobileWips, though how it gets through Pi-hole is another question. I've blacklisted google.com.onion -- maybe this will suppress the IPS alerts (update: it doesn't!)
This is so disappointing. Just use a canary domain that can be blocked if the owner wishes. Hiding the domains behind some trickery just makes it look like Samsung intends for it to be force fed.
So do we conclude that this Pi-hole-tunnelling trickery and associated shenanigans by Samsung is probably benign, at least as much as shouting "fire!" in packed theatre to test reaction is benign?
1 Like
I believe it is intended behavior and not "malicious" in the sense of a 3rd party attack. But it's craptastic behavior. More like Chunk making barf noises in the balcony kind of things.
Thanks Dan, all. So in conclusion we don't know how that goo..ogle.com query gets through Pi-hole, but it's not something to worry about.