Disney+ domain being sinkholed as DNS tunneling domain

[jlieberman]

This morning I starting noticing that my threat logs are filling up with

sinkhole actions for the following

Suspicious DNS Query (search-api-disney.svcs.dssott.co)

Suspicious DNS Query (dssott.com)

Threat Type

spyware

Threat Name

DNS Tunneling Domain

ID	109001001 (View in Threat Vault)

Category

dns-security

Content Version

AppThreat-0-0

Severity

high

Repeat Count

1

File Name

URL	Suspicious DNS Query (search-api-disney.svcs.dssott.co)

To get the site working again I have added a DNS signature exception for thread-id 109001001

Is it possible to except certain domains rather than the entire threat-id?  I fear that I am excepting more than just the domains I'm interested in.

[flintrock]

I have the same issue, I tested @jlieberman 's hypothesis about opening too much. A little wiresharking and I can confirm the FQDN below, search-api-disney.svcs.dssott.com, IS used for delivering the Disney+ service. The domain is owned by Disney as well.

After adding an exception using threat-id 109001001 to the Anti-Spyware -> DNS Signatures -> Exceptions, service to the site was restored, but I now bypass the DNS security completely it seems, note the test that is supposed to be blocked is now open as well:

Resolves correctly and service is restored:

fb@GREYSMB ~ % dig @8.8.8.8 search-api-disney.svcs.dssott.com +short

search-api-disney.bamgrid.com.

dgel2a5rs1evz.cloudfront.net.

143.204.35.80

143.204.35.34

143.204.35.113

143.204.35.125

Testing URL provided by Palo Alto- This should fail and point to sinkhole, but instead resolves.

fb@GREYSMB ~ % dig @8.8.8.8 test-dnstun.testpanw.com +short         

72.5.65.115

Normally the test URL looks like this and gets "sinkholed":

fb@GREYSMB ~ % dig @8.8.8.8 test-dnstun.testpanw.com +short

sinkhole.paloaltonetworks.com.

Faulty Rule catching the legitimate domain FQDN:

fb@GREYSMB ~ % dig @8.8.8.8 search-api-disney.svcs.dssott.com +short

sinkhole.paloaltonetworks.com.

[mivaldi]

This was caused by domain dssott[.]com being marked malicious.

The issue was resolved on 5/3, and should no longer be observed.

[mivaldi · Accepted solution]

Given that adding an exception to 109001001 would disable the signature altogether if you want to add temporary exceptions you can actually do that per-firewall using CLI commands:

Check the status of the domain verdict by the following command 
> show dns-proxy dns-signature cache | match abc.com
*.abc.com                         C2          109000001   86327       0

Change the status of the domain verdict to benign by the following command. Please note that you are adding this domain as a whitelist on your PaloAlto Firewall on the management plane. This entry will only be effective on your Firewall locally.
> debug dnsproxyd dns-signature response verdict <new verdict you want> fqdn <FQDN> ttl <Time to live> gtid <preferably higher number>

Example for abc.com
> debug dnsproxyd dns-signature response verdict Whitelist gtid 420000700 ttl 30758400 fqdn abc.com

You can confirm the domain is been changed to benign. The last number zero indicates the number of hit to this domain.   
> show dns-proxy dns-signature cache | match abc
*.abc.com                         White list  420000700   30758373       0  

You can also confirm from data plane
> debug dataplane show dns-cache print | match abc
abc.com, wildcard: yes, ttl: 0/331353/0, temp: 0, verdict benign, utid: 420000700

Remove entry from the dns-proxy dns-signature cache
> clear dns-proxy dns-signature cache fqdn abc.com

[jlieberman]

I can confirm what @mivaldi has said.  After removing the exception, traffic to the domain is no longer being flagged.