Serious bugs in Jetico and Kerio 2.1.5

Discussion in 'other firewalls' started by RWA, Oct 1, 2005.

Thread Status:
Not open for further replies.
  1. RWA

    RWA Guest

    I like both Jetico and Kerio 2.1.5 firewalls because they are free and very resource-friendly compared to many other firewalls. However, I have problems with both.

    Jetico bug: it works fine initially and then gets confused about process identification *after* certain security events. For example, with Jetico active, I run Opera 8.5 which initially works fine. I then open a command prompt. I then run my own program that generates a security alert (modifying one of ANY another process, totally unrelated to Opera) and tell Jetico allow it. After this, Jetico issues a network alert everytime Opera tries to access a website, but Jetico identifies Opera as "CMD.EXE".

    Jetico bug #2: I already replaced Jetico with Kerio 2.1.5 so I cannot confirm it but I think Jetico's firewall doesn't differentiate between different programs launched from the command prompt. Note that in the above example, Opera was launched normally (start menu) so this is a separate issue.

    Kerio 2.1.5 bug (Firewall Engine Version: 2.1.5 and Driver Version: 3.0.0):
    try this simple test:
    1. in command prompt, try "ping" and you'll correctly see:
    "Pinging [] with 32 bytes of data:
    Reply from bytes=32 time=67ms TTL=48"
    2. click "Stop all traffic" from the kerio tray icon menu
    3. in command prompt, try "ping -l 5000" and you'll see that network activity isn't blocked:
    "Pinging [] with 5000 bytes of data:
    Reply from bytes=5000 time=222ms TTL=48"

    So basically, Kerio 2.1.5 seems incapable of preventing a local program requesting and then receiving response from a remote machine on the internet even while Kerio's "Stop all traffic" option is selected.

    Are there there any solid alternatives to these 2 firewalls? I just want something very resource-friendly to work well on Windows 2000 sp4. I want the firewall to do its core functionality well instead of bundling a bunch of non-firewall features that I can get from other products.
  2. FastGame

    FastGame Registered Member

    Are you sure the "ping -l 5000" is correct ? it does nothing for me.
  3. Kerodo

    Kerodo Registered Member

    One popular solution amoung people I know is to run CHX as your basic packet filter. CHX has great features, however, there is no traditional outbound control. So, in place of the usual outbound control, you can also run Antihook, which should catch anything before it even gets to connect outbound. The CHX/AH combo is a pretty good one.

    Here's a link to CHX (it's free also): Read thru the online docs to get a good overview of it. It's an excellent program. And you just can't beat it for low resource usage. It runs as a kernel service.

    Then there is also Harden-It and Samurai to add a little system hardening on top of the above. With all in place, things are pretty tight.
  4. RWA

    RWA Guest

    I don't think CHK is free anymore. I clicked on PRODUCTS, then PACKET FILTER. At the bottom of the page below the DOWNLOAD TRIAL button, it says:

    "* The trial version will expire in 30 days."
  5. Kerodo

    Kerodo Registered Member

    Yes, CHX is definitely free. You just need to register and obtain a code. But it is free. I believe even the new version 3 (which is currently in beta) is also free. At their site, go to Products, Packet Filter, Registration.
  6. noway

    noway Registered Member

    That's interesting...on my machine your example works for ping packets 1473 bytes and larger. Whether this is critical for someone is open for debate...I guess if one unwittingly downloads a trojan, runs it, and the trojan pings various machines hoping to find a machine vulnerable to ping packets...I don't think the "stop all traffic" would allow TCP/UDP outbound/inbound to pass. I was surprised to find that even with filter rules blocking ICMP, that these particularly large ping packets were still sent out and a response received. It would be nice to have the bug fixed, but 2.1.5 is no longer in development. Let us know if you ever see/read anything like this for TCP/UDP. Every firewall I have ever used has can move to another firewall but the new one will not be free of issues either (ie. BSODs, memory leaks esp. with p2p, poor/quirky/bloated GUI, high memory use under normal circumstances, unable to block apps that use a local proxy-->I think I have covered the most popular current personal firewalls!) so if you switch software every time you find a bug it is a vicious circle and you may be back to where you started.
  7. RWA

    RWA Guest

    I read that Kerio 2.1.5 also has the fragmented packet problem with TCP and UDP--not just ICMP. So this isn't a problem that should be ignored simply because we love Kerio 2.1.5's price, speed/footprint, and GUI. For example, this flaw can be used by an attacker to determine that your pc exists (which is one important reason we usually DROP packets instead of REJECTing them).

    I found a workaround and confirmed it on Windows 2000 so I don't have to lose all my beloved Kerio 2.1.5 rules. I'll post in new thread.
  8. Rmus

    Rmus Exploit Analyst

    So, what would happen then? What could an attacker do, knowing that you exist on the internet at that IP for that session?


    ~~Be ALERT!!! ~~
  9. Kerodo

    Kerodo Registered Member

    There are many who say that a hacker has ways to tell if you're there even when you are stealthed on and so on. So they say that all the stealth business is complete nonsense. Just visit the newsgroup and ask there about it. You'll get some old hands lecturing you on what a waste of time stealth is..
  10. FastGame

    FastGame Registered Member

    Guess I'll say this again.......

    "ping -l 5000" with Kerio 2.1.5 does nothing, with "Stop All Traffic" my Kerio does exactly that, nothing gets through.
  11. RWA

    RWA Guest

    >>>So, what would happen then? What could an attacker do, knowing that you exist on the internet at that IP for that session?

    They could focus on mounting attacks targetting your machine instead of moving on to the next random ip address. For more specifics, ask an attacker but this is probably the case in general:

    Common tactic:

    choose predefined ip address list (maybe targeting specific cable/dsl ISP)
    if computer detected at current ip address, then
    try os-fingerprinting, latest 0-day/unpublished vulnerabilities, dns poisoning, and more
    else ignore "dead" ip address
    get next ip address
    repeat loop

    Fortunately, I have a workaround which allows me to continue using Kerio 2.1.5 and not have to worry about fragmented packets--and without running yet-another-process that would eat resources or switching to more bloated firewalls. With the workaround, the previously successful large packet pings no longer work with "Stop all traffic". Successfully tested on Windows 2000 with "ping -l 5000" from the Kerio-protected pc and "ping -s 5000" from a remote Linux box. Haven't tested yet using other protocols, but will try as soon as time allows so I can post the solution with more confidence. Good luck.
  12. RWA

    RWA Guest


    Can you cut/past the output from your ping command?

    What OS are you running? I tested with Windows 2000 sp4.

    What ping.exe are you running? Mine is c:\WINNT\system32\ping.exe

    What does your Kerio About box say? Mine says "Firewall Engine Version: 2.1.5 and Driver Version: 3.0.0". The version of Kerio 2.1.5 I used was downloaded yesterday directly from

    And finally, did you successfully resolve the ip address before "Stop all traffic" was enabled? ping needs to know the ip address.
  13. pcalvert

    pcalvert Registered Member

    This works as expected.

    This did not work for me. After a long delay, I got this response:
    "Unknown host"

    At least for me, KPF is working fine. I suspect that you may have a problem with your installation and/or configuration.

  14. Rmus

    Rmus Exploit Analyst

    The attached image shows a probable worm attack looking to sneak in a trojan.

    I don't see whether or not it matters that an attack is aimed at a particular IP address, or is random, as long is it is blocked. The IP address will change on next login anyway.


    ~~Be ALERT!!! ~~

    Attached Files:

  15. Rmus

    Rmus Exploit Analyst

    It's also not permitted according to IETF standards


    (scroll to "Stealth-mode Firewall)

    "This hyper-paranoid approach to security causes some difficulties.
    For a start, Internet standard RFC 1122 states categorically about ICMP Echoes (ping): Echo Request/Reply: RFC-792

    Every host MUST implement an ICMP Echo server function that receives
    Echo Requests and sends corresponding Echo Replies."


    "A commonly heard objection to allowing ICMP Echo Replies is that it gives
    away information to hackers that there is a live connection on this IP
    address. Such objections are not well-founded, and can be safely ignored.
    There is no evidence in practice that any hacker has been aided by the
    presence of an ICMP Echo Reply. Hackers do not typically write code that
    tests an address with ICMP Echo before launching a hostile probe: they
    always send the hostile probe directly: either it works or it doesn't, and
    information from ICMP adds nothing to the analysis."

    Kerodo, you will remember this:

    "Some firewalls make a virtue out of sending no reply, and they even
    invented a new term for it: "stealth". This may be great for a marketing
    brochure, but is quite useless in the real world, especially if you have any
    service at all open on your machine, with any protocol. Even worse, this
    breaks some RFC's - not that that ever stopped the marketroids."


    ~~Be ALERT!!! ~~
  16. FastGame

    FastGame Registered Member

  17. Kerodo

    Kerodo Registered Member

    Well said Rmus...
  18. Arup

    Arup Guest

    CHX+Kerio 2.15 can be combined to make your system totally stealth and have outbound protection as well, CHX takes very little resources so the impact on the system is nil. I have done it like that for months when I was using Kerio 2.15
  19. ghost16825

    ghost16825 Registered Member

    Firstly, I'm guessing RWA was using the DNS Client Service. already had a resolving enty in the cache so ping didn't fail to resolve the domain name. (Which is what always happens when Disable traffic is set)

    I can almost say any ICMP data size will fail if the address needs to be resolved (when Disable traffic is set). However I did get some weird input on one occasion when pinging the domain name (one reply):

    Pinging [] with 32 bytes of data:

    Reply from bytes=32 time=327ms TTL=50
    Request timed out.
    Request timed out.
    Request timed out.

    An attempt with a larger size and only the the IP address resulted in also strange behaviour:

    Pinging with 5000 bytes of data:

    Request timed out.
    Request timed out.
    Reply from bytes=5000 time=2732ms TTL=50
    Reply from bytes=5000 time=404ms TTL=50

    Then Kerio seemed to allow all replies:

    Pinging with 5000 bytes of data:

    Reply from bytes=5000 time=448ms TTL=50
    Reply from bytes=5000 time=407ms TTL=50
    Reply from bytes=5000 time=404ms TTL=50
    Reply from bytes=5000 time=421ms TTL=50

    This is a very important point/clue. What this points to guessed it...behaviour due to fragmented packet handling.

    Ethernet has a Maximum Transmission Unit of 1500 bytes. 20 bytes are reserved for the IP header and 8 bytes are allocated for the ICMP Echo Request header. Windows by default (registry entry) I believe has a MTU of 1500 bytes for all non-local addresses. What happens when the total packet size you want to send is above this? You guessed it - fragmentation. And Kerio 2x doesn't seem to handle fragmentation well. I think that's the problem.
  20. Rmus

    Rmus Exploit Analyst

    What types of exploits could occur due to this?

    Any known occurrences that you are aware of?

  21. Rmus

    Rmus Exploit Analyst

    OK, I did a test here.

    ~~Be ALERT!!! ~~
  22. ghost16825

    ghost16825 Registered Member

    No-one could really do much with ICMP; perhaps create an inefficient covert channel which has been done. The bigger issue is how Kerio handles TCP/UDP packets both inbound and outbound which are fragmented, regardless of size. (I don't know) If you are concerned, setting appropriate registry settings to disable fragmented packet sending and receiving might be prudent. That is, if you rarely need to handle packet sizes over the default MTU of 1500 bytes. (Which is usually the case)
  23. ghost16825

    ghost16825 Registered Member

    That's 32 bytes though - no need to fragment it.
  24. Rmus

    Rmus Exploit Analyst

    I'm not sure - I've seen posts about this but have never seen an example of how this could be exploited.

    EDIT: OK, I misunderstood. Pinging with 1500 bytes went through.

    ~~Be ALERT!!! ~~
    Last edited: Oct 1, 2005
  25. ghost16825

    ghost16825 Registered Member

    I haven't seen conclusive proof that Kerio 2x allows fragmented TCP/UDP regardless of the ruleset and/or Stop Traffic option only some limited tests that say fragmented packets are not logged.
Thread Status:
Not open for further replies.