Proxy predefined content inspection exceptions allow phishing sites.
I came across some Office 365 phishing sites using a url similar to this fake-login-com-login.microsoftonline.com.PhishingDOMAIN.com.
Even though the real domain is phishingdomain.com, the proxy is allowing the connection becuase login.microsoftonline.com is in the predefined content inspection exemption list.
Even if I try to deny phishindomain.com with the web blocker excpetions, the content inspection exceptions overrule. So I would have to uncheck but this seems like a bug. Tested on 12.5.2 U1. m370
1
Sign In to comment.
Comments
Can you post the real domain that has issues?
keep a space between the dot, such as this:
fake-login-com-login. microsoftonline. com. PhishingDOMAIN. com
That way we can see the real domain, and test it against our XTM config.
Try this https://my-domain-com-login.microsoftonline.com.gloveswears. com
Remove space before .com to test.
I see your point - a BUG.
2020-03-04 18:36:29 Allow 10.0.1.2 66.70.201.177 https/tcp 61482 443 1-Trust-VLAN 0-External ProxyAllow: HTTPS content inspection exception list match (HTTPS-proxy-for-Bruce-PC-00) HTTPS-Client-DPI proc_id="https-proxy" rc="590" msg_id="2CFF-000A" proxy_act="HTTPS-Client-DPI" sni="my-domain-com-login.microsoftonline.com.gloveswears.com" cn="*.microsoftonline.com.gloveswears.com" exception_rule="login.microsoftonline.com" action="allow" geo_dst="CAN" Traffic
Thanks for reporting. I'll get this bugged...
in the meantime, disable the two predefined exception rules then create Allow Pattern Match rules by adding /* to the end of the pattern. This should prevent the override and still skip inspection. You can then catch it by blocking the Newly Registered Domains category or by adding WebBlocker domain exception rule.
How will "Allow Pattern Match rules by adding /* to the end of the pattern" prevent the problem domain ?
Shouldn't this be a Deny?
And be above the current entry ?
We're replacing pre-defined exception rules to prevent matching.
-disable *.microsoftonline.com and login.microsoftonline.com. This gets rid of erroneous matching
-add *.microsoftonline.com/ * and login.microsoftonline.com/ * Domain Name rules with Allow action. This replaces disabled rules to ensure Content Inspection is skipped.
*The authority section of the URI ends after microsoftonline.com
*The forum isn't displaying * correctly. Added a space in the pattern
OK, so I may be being stupid here, but to me, .microsoftonline.com/ is not a domain name, and thus should never match a domain name check.
Help me understand my confusion.
Hello Bruce,
Let's concentrate on just one rule. As noted by the OP, "....the proxy is allowing the connection becuase login.microsoftonline.com is in the predefined content inspection exemption list......". If we disable the pre-defined rule, that stops the exception from matching and we can block the phishing domain.
Now we have to setup a new rule that will skip Content Inspection for the domain and prevent the rule from matching the phishing domain. An Allow Pattern Rule for login.microsoftonline.com/* accomplishes both requirements.
1) how does one allow the desired domain? This has not been suggested.
2) I am used to a URL having a /* at the end for a match. I am not used to seeing a /* at the end of a domain name for a match
If the suggested entry was for login.microsoftonline.com.*, I can understand this
Help me understand the suggested Deny match string
The workaround does seem to work which was to uncheck the two predefined rules as noted above and manually add and allow them using the domain names list on the content inspection tab.
Bruce I think * .microsoftonline.com/ * works because the system can detect the actual domain name in the url. It's the last top level domain (.com) before the first /. Just a guess though.
The scary thing is, this particular phishing site was pulling in our custom office 365 background and logo.
My other Watchguard firewall without content inspection enabled was blocking the site through the newly discovered domain web blocker category.
There are a lot of predefined exceptions so I hope this bug gets fixed ASAP.
Would this approach apply to ALL of the predefined exception rules?
Does it also affect the Domain Names that we enter ourselves?
For any new exceptions that we add, what format should we use? I assume it now should be
*.excepteddomain.com/
Or do you mean
*.excepteddomain.com/star (I had to write star where the asterisk should be)
Or
*.excepteddomain.com/ *
Gregg Hill
@Bruce_Briggs The suggested workaround would only cover one of the two requirements. /* would not work in a Domain Name rule since we're only matching against the SNI, CN or IP. These are different from standard WebBlocker or HTTP proxy exceptions. So essentially, you'd have to Deny the desired domain via custom Domain Name rules. my-domain-com-login.microsoftonline.com.gloveswears[.]com Deny
@phanaaekIT It may appear the earlier suggested workaround is working because the phishing site is now blocked. If you check your logs while navigating to login.microsoftonline.com, the domain is most likely being inspected (takes the default action) instead of being allowed.
@Greggmh123 See my response to Bruce above
Regarding format, I just saw where Ralph said:
An Allow Pattern Rule for login.microsoftonline.com/* accomplishes both requirements. I will change all of my current custom exceptions to that format.
Gregg Hill
@Ralph
The reason for my question related to the /* format is there is nothing that I see in the docs that says anything about this. There is no specific discussion of SNI entry formats - only for Domain Names.
In fact, it says this: "*.example.com/ is not a valid domain name."
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/proxies/https/https_domain_names_c.html?Highlight=sni
And here:
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/proxies/examples/routing_action_https_no-ci.html?Highlight=sni
it says: "Domain name rules must match a domain name and cannot contain a path."
It would be exceeding helpful for the docs to reflect what is really possible as the docs are what most of us go by when trying to configure our firewalls.
How does this issue affect FQDNs that we add to an alias that is applied to a rule? I cannot add *.domainname.net/ * (remove the space...dang this forum!) because it gives me a "The domain name is invalid" message. I can add *.domname.net to an alias. So would that domain be vulnerable to this same exploit?
Gregg Hill
Ralph,
To be clear, you are stating that the pre-defined rules suffer this issue, and so do any DPI exception rules we add, correct? So all of my dozens of added Allow exceptions need to have /* added to the end of the pattern?
I exported my exceptions to XML so that I can easily edit the Allow exception patterns to add /* at the end. I am also adding it to the rule names so that they match the pattern for aesthetics.
Gregg Hill
I went ahead and added a /* to the end of all of my custom HTTPS DPI Allow exceptions, fully expecting it to break something, and it didn't let me down!
I just found and fixed an issue with Outlook and Office 365. While connected to my IKEv2 VPN from Starbucks, and having autodiscover entries with a /* at the end of the exception, Outlook cannot connect. It just flashes an error window so fast that I cannot see what is it. It keeps doing this until it finally pops up a window saying there is an error with my autodicover SSL cert.
I went back and removed the /* from the following exceptions and Outlook was able to connect again.
I removed the /* that I added because of the reported issue above from these custom DPI exceptions, and Outlook works again:
autod.ms-acdc.office.com
autod.ha.office365.com
autodiscover.outlook.com.glbdns.microsoft.com
autodiscover.outlook.com
autodiscover.myowndomainname.net
The issue does NOT happen on the LAN. It seems related to a similar Outlook problem when using SSLVPN, but that is managed by adding the default gateway of the SSLVPN subnet to the TAP adapter.
Gregg Hill
Sure wish the proper use of /* was documented.......
Hello Greg,
Domain Name rules are domain based and are matched against the SNI or CN, if SNI isn't available. URL style patterns will not match in this instance. We're working on a fix.
You'd have to create a Deny Domain Name rule to block the example posted by the OP.
If "Domain Name rules are domain based and are matched against the SNI or CN", how are the pre-defined exceptions matched? I assumed they were the same matching.
Also, you suggested adding an exception of login.microsoftonline.com/ * (without the space) to Domain Name rules with Allow action. "This replaces disabled rules to ensure Content Inspection is skipped."
If "Domain Name rules are domain based and are matched against the SNI or CN, if SNI isn't available. URL style patterns will not match in this instance." is true, then why add the /* to your given Domain Name exception Allow rule? Wouldn't it work without it? Should all the Domain Name rules we add, with the exception of autodiscover rules, have the /* at the end, or should they be left as-is?
Gregg Hill
https://www.theregister.com/2021/09/22/microsoft_exchange_autodiscover_protocol_found/
there is a massive list of domains to block. The suggestion is to use the Hosts file in %SYSTEM%\Drivers\Etc on a windows system to block it by appending this massive list https://github.com/guardicore/labs_campaigns/tree/master/Autodiscover
and dropping it to the loop back 127.0.0.1
Clearly there must be a better way to do this in the Firewall but obviously if I block Autodiscover incorrectly I kill setting up new Outlook accounts.
Any suggestions as this seems to be closely related to this bug.
IT@5star...
Agreed, was just wondering this same thing!
How about it @Ralph
Hi dugyodi
Have a ticket open with support at the moment and have pointed them to this discussion to see if we can get this clarified
Earlier suggestions from the list author do not work i.e. to add the list to windows host file (won't work hits hidden limits its 8,000 lines long) Initial Watchguard advice re: importing to the fireware block site list won't work due to the limit of 2048 FQDN in the block list also the list "as is" contains illegal characters and duplicates.
Got a reply and a really useful workaround from Watchguard (nice one Cosmio)
Hi Nick,
Actually you can apply this workaround using a Outgoing DNS Proxy on the Firebox.
Within the DNS Proxy Action settings, you can create "Query Names" rules to explicitly allow your own autodiscover domain first, then block everything else.
Allow: autodiscover.example.net
Deny: autodiscover.*
Hope this helps.
Good advice but points to note: do not do as I did