Application filtering problem

Discussion in 'LnS English Forum' started by Thomas M, Feb 26, 2003.

Thread Status:
Not open for further replies.
  1. Thomas M

    Thomas M Registered Member

    Joined:
    Jan 12, 2003
    Posts:
    355
    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 :eek:

    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".... :mad:

    Any ideas on this one o_O

    Thomas :)
     
  2. Andreas1

    Andreas1 Security Expert

    Joined:
    Jan 29, 2003
    Posts:
    367
    Location:
    Mainz (Ger)
    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
     
  3. bluenose

    bluenose Guest

    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
     
  4. Thomas M

    Thomas M Registered Member

    Joined:
    Jan 12, 2003
    Posts:
    355
     
  5. bluenose

    bluenose Guest

    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
     
  6. Frederic

    Frederic LnS Developer

    Joined:
    Jan 9, 2003
    Posts:
    4,354
    Location:
    France
    Thomas said the following:
    So the issue is not a "masquerading"/"strong signature" issue.
    Actually Look 'n' Stop did detect the new Opera.

    Frederic
     
  7. Andreas1

    Andreas1 Security Expert

    Joined:
    Jan 29, 2003
    Posts:
    367
    Location:
    Mainz (Ger)
    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
     
  8. Frederic

    Frederic LnS Developer

    Joined:
    Jan 9, 2003
    Posts:
    4,354
    Location:
    France
    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.
     
  9. Ph33r

    Ph33r Guest

    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? :cool:
     
  10. Andreas1

    Andreas1 Security Expert

    Joined:
    Jan 29, 2003
    Posts:
    367
    Location:
    Mainz (Ger)
    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
     
  11. Ph33r

    Ph33r Guest

    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. :'(
     
  12. Ph33r

    Ph33r Guest

    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. :'(
     
  13. Frederic

    Frederic LnS Developer

    Joined:
    Jan 9, 2003
    Posts:
    4,354
    Location:
    France
    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.
     
  14. Thomas M

    Thomas M Registered Member

    Joined:
    Jan 12, 2003
    Posts:
    355
    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 o_O 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 :eek:

    Thomas
     
  15. Andreas1

    Andreas1 Security Expert

    Joined:
    Jan 29, 2003
    Posts:
    367
    Location:
    Mainz (Ger)
    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
     
  16. lurker1

    lurker1 Guest

    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. :)
     
  17. Ph33r

    Ph33r Guest

    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. ;)
     
  18. bluenose

    bluenose Guest

    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!!!
     
  19. Andreas1

    Andreas1 Security Expert

    Joined:
    Jan 29, 2003
    Posts:
    367
    Location:
    Mainz (Ger)
    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
     
  20. Ph33r

    Ph33r Guest

    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… :eek:
     
  21. Thomas M

    Thomas M Registered Member

    Joined:
    Jan 12, 2003
    Posts:
    355
    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 :)
     
  22. Andreas1

    Andreas1 Security Expert

    Joined:
    Jan 29, 2003
    Posts:
    367
    Location:
    Mainz (Ger)
    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
     
  23. tosbsas

    tosbsas Registered Member

    Joined:
    Feb 9, 2002
    Posts:
    789
    Location:
    Lima, Peru
    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
     
  24. Frederic

    Frederic LnS Developer

    Joined:
    Jan 9, 2003
    Posts:
    4,354
    Location:
    France
    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
     
  25. Ph33r

    Ph33r Guest

    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.
     
Thread Status:
Not open for further replies.