Application filtering problem

Using Win98SE2, webwasher and LnS 2.04p2

Since Opera announced a security hole in their browser software, I decided to give the fixed and latest version 7.02 a chance next to my beloved version 6.05. Which means that now I have installed both versions on the same harddrive, but in separate subdirectories.
Ok, after starting the new Opera7 LnS came up asking for permission to let opera.exe (version7) on the web. I allowed it, so far so good!

BUT I use a specific rule in the Internet filtering of LnS to only allow 3 apps connecting via port 80/443. These apps are Netscape.exe, Mozilla.exe and OPERA.EXE (version 6 !!)
However, now I am able to surf via port 80 using the new OPERA.EXE (version 7), which is located in a different subdirectory

This reminds me that there are little apps out trying to hide by using the same file name as the standard browser file name... and trying to leak out contacting their "script creator"....

Any ideas on this one

Thomas

 

Hi Thomas,
have you checked your "special rule" to include two Opera.exe's? There should be an additional one available to include there.
If LnS stumbles on this, you can try and rename one of the opera.exe's and see if it still works and you get hold of both versions in LnS application filtering and in the "specify apps on which to activate the rule" dialogue.
Just an idea, don't know if it works.
Andreas

 

Hi,

This is due to a weak checksumming. Other firewalls are using MD5, SHA1
or other hash algorithms as used in encryption. Furthermore one will
notice, that LnS doesn't show the exact version and build number of
the application, as other firewalls do.
This needs serious rework!
Another serious issue is the correct detection of the connection state
at any time for the proper functioning of the stateful packet inspection.
Especially dial-up users will notice after some time that this is not
the case. It would be too long to descripe here when this happens.
I can only advise to regularily compare the connection states with
netstat!
Possibly this effects also the internet filter and give a clue as to
unexplainable results with online-scans.

bluenose

 

Hi Thomas,

as I said, poor checksumming. Simply speaking, the Applications are not
protected to prevent masquerading by a strong signature generated by
a strong hash algorithm. So Opera 1 and Opera 2...etc. are seen by
LnS as one and the same application.

bluenose

 

Thomas said the following:

So the issue is not a "masquerading"/"strong signature" issue.
Actually Look 'n' Stop did detect the new Opera.

Frederic

 

Let's assume that LnS has no checksumming problem (some words about the algorithm used would help to convince everyone of this, tho) - then there would be two entries in LnS's application database named "Opera.exe" and each would have a different signature checksum. But could the problem be caused by the fact that there's nothing in that rule i quote above that tells LnS which of those two "opera.exe"s is the one that we mean...?
If this is the case, then the renaming trick should help and maybe a future version could get an additional field in the rule description that indexes the listed applications less ambiguously.

Thoughts about this?
Andreas

 

Actually, the application names in the Internet Filtering don't refer directly to the exe on the harddisk but to the applications already allowed in the Application Filtering.

So an Internet filtering rule is activated only after the Application Filtering has allowed first the application to cionnect.

I'm not sure it is useful to have two instances of the same application allowed in the Application filtering and one allowing some Internet rules and the other allowing different Internet rules.
I confirm it is not possible to do so with the current version of Look 'n' Stop.

If you think there is a security issue there, please explain.

Frederic.

 

As Frederic mentioned that Look ‘n’ Stop refers not to the executable on the HDD but the Executable which had been Authorized to Application Filtering Layer. Therefore this is a good example why people shouldn’t state Informatics of situations where they know very little of, invalid informatics might I add.

For an Example use the most recently Updated “MooLive.exe” v1.5.1.1058 and MooLive v1.5.1.1052 which you can download from http://www.moosoft.com/updates now if you hadn’t already executed MooLive.exe from The Cleaner’s directory do-so now and you’ll see Look ‘n’ Stop Application Filtering Layer bringing up Alert dialog to Authorize or DENY. Now Execute the MooLive.exe v1.5.1.1052 which you downloaded from the site manually and you’ll see it bringing up Look ‘n’ Stop Application Filtering Layer Alert.

Now replace the MooLive.exe found in either directory with something else spamming as MooLive.exe and execute, you’ll see it show the Look ‘n’ Stop Application Filtering Alert with the following;

Look ‘n’ Stop : Application Filtering
--------------------------------------------
C:\*\MooLive.exe

The application signature has changed. Do you want to authorize it again ?


|Authorize| | Block|
-----------------------------------------------

Now where do you see a flaw in Look 'n' Stop's Application Filtering Layer?

 

Hi Frederic,
while i also don't think this to be a very grave issue, here's the way i see it:

1. a couple of applications connect to the internet, provided they are allowed to do so (which LnS checks by strong (?) checksums and their pathname).
2. The TCP/IP stack wants to initiate/receive a communication for which there is a rule and this rule has certain applications specified which enable the rule when they're running. So
3. LnS checks the names of all running apps if they match one of the names specified in the rule. Yes - the rule is activated, no - it isn't.

so far so good (i am not sure about step 3. Does the list of allowed apps come in again at this point?).
The problem (if it is one) surfaces when there is an application running which has a name that is specified in the rule, but which isn't the one that was supposed to activate the rule. That was a different one, only with the same name (so i suppose).
Then you'd have a rule active although it shouldn't be, since none of the applications you have specified to activate it are running - just one with the same name.

The multi-version Opera.exe is one example, other examples could be files called "update.exe" or "guard.exe" - i think that there are many (net-relevant) small apps with these names and that would increase the chances of inadvertently activating certain rules. (Imagine a scenario where you'd like certain IPs blocked/allowed just when a certain update.exe of a certain "mother program" is active.)
If finally you consider this to be worth fixing/improving, toute l'affaire could be prevented if the application parameters in the internet rules would provide not (only) the app's name, but (addidtionally) a pointer into the list of allowed applications to the exact entry, where also Path and Checksum are available. I know that this would probably mean a lot of work in the interface and checking (step 3 above) logic, but "conceptually" it's not a big thing.

But maybe Thomas, Bluenose or someone else also wants to voice their opinion on this.

Bottomline: No "serious" security issue, just a more or less theoretical trap to (maybe) avoid.

CU,
Andreas

 

Now in reference to the “Rule-Base Application Filtering” (Rule Applies only when Running and/or Connecting with *.exe) Feature, just keep in mind it doesn’t matter what rule with Authorized Application is specified, when in use anything other-than those Applications you specified can access the outside resources if using the following ports as the rule authorizes.

For an Example, you authorized Internet Explorer, and Opera and you create a rule to specify Internet Explorer, and u execute Internet Explorer and then use Opera you see Opera is capable of accessing the Outside through the current Internet Explorer Rule session.

 

The issue exists with Applications being capable of taking advantage of “Rule-Base Application Filtering” Feature, when a rule which has this feature currently in use another Application whether or not it uses the same name is capable of accessing the outside resources depending if it uses the ports which a rule authorizes for a specified Application which currently in session. My Opinion is this Feature requires major improvement, until it does it’s pointless to even use.

 

Ok, I understand and I agree with that.

But the case you explained is different from the one exposed by Thomas:

It is not possible to have a troyan application just using OPERA.EXE as filename to activate some internet rules, because the application (with the full pathname) should be allowed first by the application filtering.
This was only my point. And there is nothing about checksumming involved in that.

Frederic.

 

Yes, this makes sense to me! Thanks Frederic!

On the other hand I just tried to repeat the experiment suggested by "Ph33r": I have an application rule to block all activity from IExplore.exe. So I changed this application rule from block to allow IExplore.exe. And now my Internet Explorer perfectly connects to the web via my unchanged port 80 internet filtering rule! BUT again, as defined in this rule I only want Mozilla. Opera and Netscape to use port 80!!

So basically each of the "allowed" applications in my application list can connect to the web through all ports, which I allow through my Internet filtering rules. And this special button in the "rule editing window" of each Internet filtering rule called "application" could be removed, it has no meaning at the moment It is not possible at the moment to block a specific port for an allowed application, when this port is allowed by any other app.

Please Frederic tell me, that I am wrong

Thomas

 

I'm afraid you're (almost) right. Frederic may of course still confirm or deny this. I say "almost" because yet the button has a function, just not the one you're used to by other fw's like Tiny/Kerio/ZAP/etc.: While you cannot so-to-say limit the rules which apply to a certain app (like: let Opera use the port-80-rule, but not the port-443-rule when) (or maybe you can or maybe in some constellations only), the actual function of this is - like it says - to activate a rule only when a certain app is running. Take that stupid ident service as an example: Normally you're not running any servers so you drop all incoming connection attempts. OTOH, irc, smtp and maybe some other common services get back to you on port 113 before they continue and you get more or less serious problems if you continue to drop these requests. So you can add a rule that allows incoming connections on port 113 (the OS's tcpip stack will reject them anyway if there's no server app listening there on your comp.), but in order not to have that open all the time (and spoil your "stealth" status) you can specify that you want this rule valid only when your irc/mailclient are launched...

AFAIU, Frederic's argument about the issue you're talking of, was "either you trust an app or you don't. Opera could still tunnel its https traffic thru port 80" (in the example above), but i think he's keeping it on the todo-list for a future version.

HTH,
Andreas

 

Hi everybody,

I like to bring something to the attention of the group which, when I
read bluenose's comments, sounded familiar to me.
Similar to Thomas's reasons for upgrading opera, I had to upgrade from
ie6 to ie6 sp1 for the last cummulative security update to accept the
the ie version. So I replaced ie6 with ie6 sp1.

Neither ie6 sp1 nor oe6 sp1 have been detected by LnS as a new app.
This is definitely a checksum problem.

I wonder what would have happened, when Thomas had replaced opera 6
with opera 7 in the same directory.
Another thing I took note of was bluenose's mentioning of identifying
applications as "iexplore version-number built-number" instead of
just directoryname/iexplore.exe.

I don't really bother about these issues, because I am using another
firewall (only tried LnS :-}).

Just wanted to let you know.

 

I could of swore I had seen Frederic mentioned while back that Look ‘n’ Stop uses MD5, and MD5 is much more then matching up Location and filenames…etc

Most likely since newer version of the Application is an Update of the current it contains the same "fingerprint" therefore not triggering any Alarms. And even though the idea of matching files by version Informatics sounds beautiful it’s really quite of pointless since it’s impossible for another program to spam another programs "fingerprint".

Unless you can replace Opera’s Executable with a Trojan Executable or any type of malicious or non-malicious Executables and execute without Look ‘n’ Stop Alerting you shouldn’t be questioning Look ‘n’ Stop’s capabilities.

 

Hi Ph33r,

hold it...hold it. You should do some more reading about fingerprinting!
If only a SINGLE bit is changed, the MD5 fingerprint changes.
It is true that basically the functuality of a file may be the same,
however if only ONE bit of the file is changed, the fingerprint is
different. It's up to you now to figure out how many bits are changed
if the file contains different versions- and built-numbers! Or none
at all!

MANY!!!

 

Lurker and Bluenose,
i don't want to argue about LnS checksumming, just get some info together that might help explain why LnS could have missed the update(s) (if it did miss them). After all, this is not going to be resolved (either way) unless we get a bit more technical.

Can you confirm that those upgrades (ie6 sp1) change the exe file and not just some dll or other resources? (on several occasions i was alerted by LnS after i updated such an exe, only i can't exactly recall what was the app and the upgrade.)

And: do we all agree that MD5 is sufficient if it's used? If something else (crc-?? or maybe even sha-??) is used, we should know it, and then we can discuss about whether it is appropriate or not.

Cheers,
Andreas

 

Actually I do believe bluenose is a bit right…
In Look ‘n’ Stop’s earlier versions it appeared to function quite well, but now it seems not to detect “Updated” Executables that contains the same KB’s in filesize. And using MooLive.exe for an Example updating or downgrading the current MooLive.exe doesn’t trigger any Alarms now… Maybe there’s a conflict within the Look ‘n’ Stop Application that needs to be repaired…

 

Folks,

my LnS detected the new version of opera.exe (version 7) in the application filtering. So this thread here is not about LnS missing anything in the application filtering. At least not for this Opera.exe file.

What really depresses me is that I misunderstood the entire concept of this firewall! If I can not block specific ports for an allowed application makes me thinking to switch to another product (please note that I just wrote "makes me thinking"!! Please help me to find out that the concept of LnS is convincing...)

Thomas

 

I for one have not much to add here: this (the other way) is a functionality that has been asked for a couple of times and Frederic is aware of it, i think he has it on the todo-list for a later version.
Other than this, i have only recently switched to LnS from Kerio. On the one hand, the numerous other options that LnS offers (like filtering on flags, logflood protection and a couple of others) made me not wanting to wait any longer just for that function you've mentioned (and which i'd like to see in LnS too).
On the other hand, i'm in linux most of the time now and so maybe i am more easily willing to run LnS in my win98 sessions.
Finally, that specific function is - as Frederic is IMHO right in insisting - needed primarily if you don't trust your apps (spyware, cracked versions or something like these), and over the past year i've virtually eliminated those apps that i don't trust completely. (I'll admit tho, that there are also some occasions where another motivation for using such a function arises, but i can cope with these).

HTH,
Andreas

 

I don't understand anything about the tech - stuff but in my case IE 6sp1 (if I remeber right) was found and Opera 7 too, as there where many other changed apps - all found

Ruben

 

Yes, there is currently no option in Look 'n' Stop to allow specific port for a specific application.
Our motivation is that you should trust an application globally. Otherwise what you will do is: open one port and block others, and then nothing will prevent the application (if it is a malicious one) to use the only port you allowed to perform malicious operations.

The application selection feature in the Internet filtering doesn't replace at all the port selection at application level.
The purpose of the feature is only to block the maximum of ports when there is no need to open them.

2.03 and previous versions didn't include this feature, and this didn't prevent Look 'n' Stop to offer a high level of security.
So this new 2.04 feature is just a plus to have more cases where packets can be blocked in the packet filter.
This is useful for all applications that open sockets in server mode (Irc with the ident, FTP, Web Servers...) and this is useful for people that would like to use applications like NetMeeting (that uses a lot of ports) but don't want to let many ports open as soon as the application is no longer connected.

Anwyay, the port selection at application level is something that we will introduce in a future version (I know I've already said that before, but we think the other features we introduced are more interesting).

Frederic

 

To be accurate this Feature had been extremely Requested Feature since the start of the old Look ‘n’ Stop Forum on Becky’s. Customers and their Time and Efforts put forth into creating threads requiring this Feature and explaining why it’s necessary to them. And I can absolutely ensure Frederic that I’ve known quite a number of people switching to another Software Firewall because of this particular Feature we are currently discussing. As Andreas(W) said this Look ‘n’ Stop contains much Features that other Software Firewalls “still” doesn’t have implemented yet. And that’s why I’m using this reliable, Firewall which runs smoothly and speedy and giving me absolutely nearly nothing much to want. But don’t tell me this Feature isn’t absolutely beneficial Feature, with all my Kn0wledge I can ensure you this will prevent all my issues with Spywares, and others peoples issues like Trojan Infections. And like it or not it’s nearly impossible for the Average Joe to download programs that doesn’t contain Spywares, many very popular beautiful programs many people uses contains Spywares and Look ‘n’ Stop isn’t capable of functioning in this field to protect users against Trusted Applications unauthorized Outbounds.

Back in the old days of ConSeal PC Firewall, I use to specify what Applications can access what port or ports, mIRC specified to use port 6667tcp, Internet Explorer specified to use port 80tcp, Outlook Express specified to use ports 25, 110, mIRC specified to Authorize 113tcp inbounds… and I specify Source Port/IP and Destination Port/IP and so forth, and nothing other-than the selected Application was capable of intercepting the packets.

Look ‘n’ Stop’s Feature you cannot authorize or DENY with specified Application without haven major conflicts with other Applications connecting. You Block Internet Explorer or Opera only then execute the denied Application and attempt to connect to a webpage and try opening Non-specified browser and surf, you’ll find it very difficult to make Connection even though you specified the rule to only apply to Internet Explorer or Opera browser rather then other-than which had not been selected.

Now try Authorizing only Internet Explorer or Opera and Execute & surf, while executing Non-selected browser, again the Other Applications capable of using the same rule to gain Access to the Internet Resources even though we didn’t specify the use of this here Non-Selected browser.