[Resolved] filtered by ABE: <LOCAL> Deny

Discussions about the Application Boundaries Enforcer (ABE) module
wxman1
Junior Member
Posts: 44
Joined: Tue Dec 08, 2015 8:11 pm

[Resolved] filtered by ABE: <LOCAL> Deny

Post by wxman1 » Tue Aug 09, 2016 9:29 pm

I just update by browser to FF based v48.0.0.1 Comodo IceDragon and got this blockage:

GET "http://"widget.quantcast.com/p-e2qh6t-Out2Ug/10 <<< "http://"widget.quantcast.com/p-e2qh6t-Out2Ug/10, "http://"www.drudgereport.com/ -7) filtered by ABE: <LOCAL> Deny

What's LOCAL 'bout that? Do I need some sorts of SELF rule? Or is this a surrogate issue, i.e., wrt quantcast, so its pointing to the host? I never seen that before. I looked in the browser console, but didn't see anything related to ABE. Of course may not be lookin' at the correct tab output.
Mozilla/5.0 (Windows NT 5.2; rv:48.0) Gecko/20100101 Firefox/48.0

barbaz
Senior Member
Posts: 9781
Joined: Sat Aug 03, 2013 5:45 pm

Re: filtered by ABE: <LOCAL> Deny

Post by barbaz » Tue Aug 09, 2016 9:43 pm

IceDragon is not a supported browser, please test Firefox 48 and let us know if the issue occurs there.

(IIRC those Comodo browsers try to use their own DNS. Glitches in DNS can wreak havoc with ABE..)
*Always* check the changelogs BEFORE updating that important software!
-

wxman1
Junior Member
Posts: 44
Joined: Tue Dec 08, 2015 8:11 pm

Re: filtered by ABE: <LOCAL> Deny

Post by wxman1 » Tue Aug 09, 2016 9:55 pm

FWIW: I'm not using Comodo Secure DNS; Drudge had been reported as a malicious site preventing navigation to it. Furthermore, I've not had ANY prollems with NoScript / ABE and I've been using IceDragon since FF base v26. Moreove, given that I'm zipped tight as a drum with CIS proactive paranoid HIPS / FW, I've NEVER seen a peep of malicious activity at Drudge.

The page seems to function o.k., just have the blockage message at the top.
Mozilla/5.0 (Windows NT 5.2; rv:48.0) Gecko/20100101 Firefox/48.0

barbaz
Senior Member
Posts: 9781
Joined: Sat Aug 03, 2013 5:45 pm

Re: filtered by ABE: <LOCAL> Deny

Post by barbaz » Tue Aug 09, 2016 10:43 pm

wxman1 wrote:FWIW: I'm not using Comodo Secure DNS;

Not saying that's the only thing that could cause a IceDragon-specific problem, only suggesting one possibility of what might be happening in this case.

wxman1 wrote:I've NEVER seen a peep of malicious activity at Drudge.

Being tightly protected from compromise will *not* always make you unable to see malicious activity trying to happening. Maybe you've just been lucky for a while.. unfortunately every streak of luck runs out at some point. Just sayin. Image

wxman1 wrote:The page seems to function o.k., just have the blockage message at the top.

The ABE notification showing in this circumstance is a known bug: viewtopic.php?f=23&t=18996
If you reproduce the problem in a supported browser, can you please check the Browser Console (Ctrl-Shift-J) when this issue happens and post here the message(s) from ABE?
*Always* check the changelogs BEFORE updating that important software!
-

wxman1
Junior Member
Posts: 44
Joined: Tue Dec 08, 2015 8:11 pm

Re: filtered by ABE: <LOCAL> Deny

Post by wxman1 » Tue Aug 09, 2016 11:18 pm

Thanx for the URL to the known prollem discussion; searching is not a function / feature, its an art.

I know that nothing is bulletproof, that's why its call Host Intrusion Protection and not Prevention. But I'd be seriously impressed that anything can penetrate CIS HIPS / FW; nothing can move on the system without appropriate permissions - default block - and an alert and log entry would be generated. To reiterate, I've never seen a clue of any even suspicious activity from Drudge. But then I've been using NoScript which blocks any JavaScript by default. That inherently mitigates the drive-by-download threat vector. Even if something gets onto the system, something has to execute it - unless its self-executing which will require permission to do so - and whatever is doing the downloading has to have permission to the destination, and then not only execute rights but such rights IN the destination, and then whatever it is having been executed has to have permissions to do anything. O.k., enough of that. :roll:

Frankly, the issue should be easily enough reproduced in default supported browser platform; you just going to Drudge should reproduce it easily enough with default ABE SYSTEM rule-set. I don't have a second browser intalled and am disinclined to install another. That being said, what am I spoda look at in browser console? Which tab is of interest that will contain a bloody knife if one is to be found; everybody knows that 'smoking gun' is just way over the top too dramatic cliche. ;)
Mozilla/5.0 (Windows NT 5.2; rv:48.0) Gecko/20100101 Firefox/48.0

barbaz
Senior Member
Posts: 9781
Joined: Sat Aug 03, 2013 5:45 pm

Re: filtered by ABE: <LOCAL> Deny

Post by barbaz » Wed Aug 10, 2016 12:39 am

wxman1 wrote:I know that nothing is bulletproof, that's why its call Host Intrusion Protection and not Prevention. But I'd be seriously impressed that anything can penetrate CIS HIPS / FW;

Right, you'd see it trying and failing. :twisted: ;)

wxman1 wrote:Frankly, the issue should be easily enough reproduced in default supported browser platform; you just going to Drudge should reproduce it easily enough with default ABE SYSTEM rule-set.

I can't reproduce the problem, something outside my browser is killing Drudge almost completely, turning it into a massive wall of all-caps text :? It did try to load the quantcast frame alluded to in the OP, but unblocking that didn't trigger ABE for me.

So we need to figure out whether it's because of IceDragon, or what DNS lookup of widget.quantcast.com returns on your machine, or something else.
Is the domain listed in your HOSTS file? If not, please post the full output from using nslookup (or dig, if you have it) to look up the domain.

wxman1 wrote:I don't have a second browser intalled and am disinclined to install another.

Same here. That's part of why I run VMs.

Also, Firefox Portable.

wxman1 wrote:That being said, what am I spoda look at in browser console? Which tab is of interest that will contain a bloody knife if one is to be found; everybody knows that 'smoking gun' is just way over the top too dramatic cliche. ;)

It's a JS message that starts with "[ABE]" and looks like a more detailed version of the notification message.
*Always* check the changelogs BEFORE updating that important software!
-

wxman1
Junior Member
Posts: 44
Joined: Tue Dec 08, 2015 8:11 pm

Re: filtered by ABE: <LOCAL> Deny

Post by wxman1 » Wed Aug 10, 2016 2:52 am

Seems as if this is the prollem chil':

iframe frameborder='0' scrolling='no' marginheight='0' marginwidth='0' height='120' width='200' src='http://widget.quantcast.com/p-e2qh6t-Out2Ug/10'></iframe>


After reading the Bug Thread, I toyed around a bit and settled on this solution:

Deny INCLUSION from www.drudgereport.com


Added to the stock SYSTEM ABE rule-set and the The "problem" ABE block notification goes away. My embeddings are:

Forbid Java
block every object from untrusted source


Moreover, I untrusted both QuantServe & QuantCast. That's when I noticed that NS isn't complaining about QuantCast, but its being intercepted by NS ABE deny LOCAL of a redirect. :? WHY argue with success, and who cares WHY its working now. I LIKE works now. Although always-worked is much better, but, meh, I take what I can get.

Then you said HOST file. I used to update HOST file from http://winhelp2002.mvps.org/hosts.htm supplemented with additional entries per SpyBot Search & Destroy Immunize. Guess what? All the various incarnations of Quant servers are mapped to 127.0.0.1 in HOST.

:shock:

:roll:

:oops:

:lol: :mrgreen: :D
Mozilla/5.0 (Windows NT 5.2; rv:48.0) Gecko/20100101 Firefox/48.0

barbaz
Senior Member
Posts: 9781
Joined: Sat Aug 03, 2013 5:45 pm

Re: filtered by ABE: <LOCAL> Deny

Post by barbaz » Wed Aug 10, 2016 3:11 am

wxman1 wrote:Then you said HOST file. I used to update HOST file from http://winhelp2002.mvps.org/hosts.htm supplemented with additional entries per SpyBot Search & Destroy Immunize. Guess what? All the various incarnations of Quant servers are mapped to 127.0.0.1 in HOST.

And there's the prollem chil'.
Firing requests at your local computer is a horrible idea especially for stuff you want blocked for security reasons. ABE is saving you.

The solution is to change all those entries to 0.0.0.0
https://hackademix.net/2009/07/01/abe-warnings-everywhere-omg/
(Note: do *not* use 255.255.255.0 as suggested in that article, when I tried that it caused MASSIVE slowdowns)
*Always* check the changelogs BEFORE updating that important software!
-

wxman1
Junior Member
Posts: 44
Joined: Tue Dec 08, 2015 8:11 pm

Re: filtered by ABE: <LOCAL> Deny

Post by wxman1 » Wed Aug 10, 2016 3:38 am

0.0.0.0 Huh. That's interesting, considering, per the MVPS web-site hosting the HOST file parasite protector:

Important Note: The HOSTS file now contains a change in the prefix in the HOSTS entries to "0.0.0.0" instead of the usual "127.0.0.1".
This was done to resolve a slowdown issue that occurs with the change Microsoft made in the "TCP loopback interface" in Win8.1.

This change in the prefix should not affect users. I've had some feedback that COMODO antivirus, Homer Webserver and System Mechanic seems to have issues with the "0.0.0.0" prefix ... to resolve this issue:

You can use the "Replace" function in Notepad to convert the entries, or HostsMan (see below) has an option for converting the entries from "0.0.0.0" to "127.0.0.1.


Since I AM using CIS integrated w/ Comodo A/V, I deliberately changed default 0.0.0.0 URI mappings to the 127.0.0.1. The thing is I've thought about scrapping HOST completely given that I've got bullet-proof hair-root frollicals. But, I can just hear my infosec instructor wagging his finger at me, but you KNOW the #1 principle of infosec is defense in depth: backstop your backstop your backstop your backstop your backstop your backstop your backstop and your A/V is your final defense, and if that's the interception, HAIL MARY; its ON and / or IN your system. Failing efficacy of A/V eradication, NADA. So, I don't know, maybe not so much.

:|
Mozilla/5.0 (Windows NT 5.2; rv:48.0) Gecko/20100101 Firefox/48.0

barbaz
Senior Member
Posts: 9781
Joined: Sat Aug 03, 2013 5:45 pm

Re: filtered by ABE: <LOCAL> Deny

Post by barbaz » Wed Aug 10, 2016 4:01 am

"issues" is a bit vague, did you actually try 0.0.0.0 and have something specific bad happen?

Otherwise, I would suggest you leave the default SYSTEM rule the way it was default, and then add this at the very top of SYSTEM:

Code: Select all

# comodo av hackery - try to work around ABE notification bug
Site 127.0.0.1
Accept from SELF+
Deny INC

This way you shouldn't have to keep tweaking ABE if your goal is only getting rid of the erroneous notification.

Does that work?
*Always* check the changelogs BEFORE updating that important software!
-

wxman1
Junior Member
Posts: 44
Joined: Tue Dec 08, 2015 8:11 pm

Re: filtered by ABE: <LOCAL> Deny

Post by wxman1 » Wed Aug 10, 2016 7:26 am

I don't like "issues" waiting in the wings. So I just global replaced 0.0.0.0 to 127.0.0.1 to avoid "issues".

I've been lax in keeping HOSTS updated - its a pain - and it hasn't been updated since 2014; I've been using NoScript. About when I got sick & tired of IE8 being obsolete, tried IceDragon and once I discovered Stylish I was hooked; the lack of any need to maintain a blocked IE downloads CIS HIPS rule-set - to protect against drive-by-downloads - was the clincher. With NoScript JavaScript blockage, that crap just don't happen. I've encountered ransomware web-pages several times. IceDragon just laughs at that crap; it ends up essentially toothless old hag of a static HTML web-page that can be closed with impunity.

The thing with the HOSTS file from MVPS is that its only as good in so far as it goes. Spybot Search & Destroy has the immunize feature - which adds nefarious URI to the Restricted / Untrusted IE zones - which FF based browsers avail themselves of in addition to URI not found in the MVPS base HOSTS file. However, that entails running the MVPS IE Restricted / Untrosted zone INF before S&D immunization; that clears out any blocked URI that are no longer valid. Otherwise its plausible that there can be blocked stuff in the registry that's not in the HOSTS file.

Anyways, I figure I'm still going run with that rigamarole; NoScript will be a good backstop for scripts and ABE for stuff that NOT in HOSTS.
Mozilla/5.0 (Windows NT 5.2; rv:48.0) Gecko/20100101 Firefox/48.0

wxman1
Junior Member
Posts: 44
Joined: Tue Dec 08, 2015 8:11 pm

Re: filtered by ABE: <LOCAL> Deny

Post by wxman1 » Wed Aug 10, 2016 7:50 am

barbaz wrote:...I would suggest you leave the default SYSTEM rule the way it was default, and then add this at the very top of SYSTEM:

Code: Select all

# comodo av hackery - try to work around ABE notification bug
Site 127.0.0.1
Accept from SELF+
Deny INC

This way you shouldn't have to keep tweaking ABE if your goal is only getting rid of the erroneous notification.

Does that work?


After updating HOSTS with current MVPS file, updating SpyBot S&D defs, purging IE Untrusted/Restricted zones, running S&D Immunize - all malignant URI in HOSTS now mapped to default 0.0.0.0 - and making NS ABE SYSTEM rule-set look like:

Code: Select all

# comodo IceDragon - try to work around ABE notification bug
Site 0.0.0.0
Accept from SELF+
Deny INC from www.drudgereport.com
# Prevent Internet sites from requesting LAN resources.
Site LOCAL
Accept from LOCAL
Deny


I no longer have the ABE LOCAL block alert at Drudge. Deny INC w/ out URI doesn't work. However, I've the same problem here, but with c.bing.com:

https://support.microsoft.com/en-us/kb/919746

I checked HOSTS: c.bing.com is in the HOST file mapped to 0.0.0.0 - I wonder why that's in there; who'da thunk bing is a prollem chil' Notwithstanding any of that, the support.MS ABE LOCAL block can't be suppressed; I added c.bing.com URI after www,drudgreport in the Site 0.0.0.0 section, and added stand alone in the default LOCAL section where I originally got DrudgeReport ABE LOCAL block alert to cease. This "error" is a different animal than Drudge "error".
Last edited by barbaz on Wed Aug 10, 2016 1:22 pm, edited 2 times in total.
Reason: kill "wrong" board-generated links
Mozilla/5.0 (Windows NT 5.2; rv:48.0) Gecko/20100101 Firefox/48.0

wxman1
Junior Member
Posts: 44
Joined: Tue Dec 08, 2015 8:11 pm

Re: filtered by ABE: <LOCAL> Deny

Post by wxman1 » Wed Aug 10, 2016 8:57 am

Dunno, but I can't find c.bing.com in the page source. The other thing is that c.bing.com isn't a URI listed in NoScript icon pop-up. I see it listed in recently blocked sites. But when I allow it, it still doesn't show up as an item to forbid.

Here's the ABE low-down from browser console:

Code: Select all

Loading mixed (insecure) display content "http://c.bing.com/c.gif?&ctsa=mr&CtsSyncId=6EDE2F15631544B8AFE330968D601B0E&RedC=c1.microsoft.com&MXFR=135D9C8F6E5667C926C995E26A566111" on a secure page

[ABE] <LOCAL> Deny on {GET http://c.bing.com/c.gif?&ctsa=mr&CtsSyncId=6EDE2F15631544B8AFE330968D601B0E&RedC=c1.microsoft.com&MXFR=135D9C8F6E5667C926C995E26A566111 <<< http://c1.microsoft.com/c.gif?, https://support.microsoft.com/en-us/kb/919746 - 3}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny INCLUSION from c.bing.com
Deny

Loading mixed (insecure) display content "http://c.bing.com/c.gif?&ctsa=mr&CtsSyncId=DC323283950F4123ACC7F73E7F228DE0&RedC=c1.microsoft.com&MXFR=135D9C8F6E5667C926C995E26A566111" on a secure page

c.microsoft.com : server does not support RFC 5746, see CVE-2009-3555

[ABE] <LOCAL> Deny on {GET http://c.bing.com/c.gif?&ctsa=mr&CtsSyncId=DC323283950F4123ACC7F73E7F228DE0&RedC=c1.microsoft.com&MXFR=135D9C8F6E5667C926C995E26A566111 <<< http://c1.microsoft.com/c.gif?, https://support.microsoft.com/en-us/kb/919746 - 3}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny INCLUSION from c.bing.com
Deny

[ABE] <LOCAL> Deny on {GET https://c.bing.com/c.gif?DI=4050&did=1&t=&ctsa=mr&CtsSyncId=0A93C901A2F2451982B80340CE1D45E8&RedC=c1.microsoft.com&MXFR=135D9C8F6E5667C926C995E26A566111 <<< https://c1.microsoft.com/c.gif?DI=4050&did=1&t=, https://support.microsoft.com/en-us/kb/919746 - 7}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny INCLUSION from c.bing.com
Deny

[ABE] <LOCAL> Deny on {GET https://c.bing.com/c.gif?DI=4050&did=1&t=&ctsa=mr&CtsSyncId=3DDA1B994EB84375ADCB9ED1FD52C71F&RedC=c1.microsoft.com&MXFR=135D9C8F6E5667C926C995E26A566111 <<< https://c1.microsoft.com/c.gif?DI=4050&did=1&t=, https://support.microsoft.com/en-us/kb/919746 - 3}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny INCLUSION from c.bing.com
Deny
Last edited by barbaz on Wed Aug 10, 2016 1:12 pm, edited 1 time in total.
Reason: wrap console messages in code tags
Mozilla/5.0 (Windows NT 5.2; rv:48.0) Gecko/20100101 Firefox/48.0

barbaz
Senior Member
Posts: 9781
Joined: Sat Aug 03, 2013 5:45 pm

Re: filtered by ABE: <LOCAL> Deny

Post by barbaz » Wed Aug 10, 2016 1:20 pm

Please use code tags for posting messages, rules, & the like, it's easier to read that way, thanks.

Instead of c.bing.com, you want to use .microsoft.com in this case (note the leading dot). c.bing.com is the request destination (like quantcast in the other example) not the source (like drudgereport in the other example).

That being said, IIRC you should not be getting *any* ABE notifications for requests to 0.0.0.0. I can confirm that behavior, maybe a bug in NoScript?
*Always* check the changelogs BEFORE updating that important software!
-

barbaz
Senior Member
Posts: 9781
Joined: Sat Aug 03, 2013 5:45 pm

Re: filtered by ABE: <LOCAL> Deny

Post by barbaz » Wed Aug 10, 2016 1:27 pm

BTW, I found this entry in my HOSTS file:

Code: Select all

# try to resolve ip 0.0.0.0 to domain 0.0.0.0
0.0.0.0         0.0.0.0

This is the first 0.0.0.0 entry, and I think I added it to fix packet sniffers saying everything was going to and from some weird or blocked site. Don't know if adding that as the very first 0.0.0.0 entry would fix any 0.0.0.0-related issues you might have?
*Always* check the changelogs BEFORE updating that important software!
-

Post Reply