Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Kerio 2.1.5 Vulnerability

11 views
Skip to first unread message

Kerodo

unread,
May 28, 2004, 4:17:40 PM5/28/04
to
I'm posting this message because I believe I have found a vulnerability
in Kerio 2.1.5 and that I should share this with other Kerio users who I
believe are vulnerable to this exploit, even though I can't explain it
all very well. I'll do my best.. What it boils down to is that a
malicious person is able to get packets to any port past the firewall if
they wish.

Some time ago, I turned on logging of ICMP in Kerio and noticed that
there was ICMP Type 3 outbound to various IP addresses, other than my
DNS servers. I wasn't worried about Type 3 to my DNS servers since this
appeared to be fairly safe and common, but the other destinations
bothered me. Why would my machine be sending Type 3 to seemingly random
IPs?

I researched this and posted in varous Kerio forums, and found out that
this was an indication that UDP was somehow getting in thru the
firewall. Some suggested it was getting past my rules. I did however,
try various rule sets without any change, and I also found that this
problem DOESN'T exist in the newer Kerio 4.xx with the same rule set.
So the rule set wasn't the problem. And they appear to have fixed the
problem in Kerio 4.xx.

Further, I noted that most, but not all, of the outbound icmp type 3 was
destined to 66.90.xx.xx IP addresses.

It bothered me that packets might be getting in thru the firewall
somehow, so I uninstalled Kerio and installed Sygate 5.5 instead, which
didn't have this problem. Later, I noticed some UDP packets coming in
in Sygate which Sygate allowed via a "non-first fragment" rule. Then
immediately following these UPD packets was another packet to port 1026.
So this was apparently an attempt by the Messenger spammers to get in
thru the firewall. These packets were also coming from the noted
66.90.xx.xx IP ranges for the most part, as in Kerio. Sygate, however,
wasn't fooled and blocked it. But Kerio 2.1.5 WAS fooled, and allowed
the 2nd packet. So I researched this and found out some very
interesting info. I think this is what is happening to Kerio 2.1.5.

Since I'm not very well versed in network stuff, you'll have to read
this and figure it out for yourself, but here is a link that explains
the exploits. It relates to Linux firewalls, but I believe that this
can happen in any OS and that this is what is happening to Kerio 2.1.5
and that packets are indeed getting in thru the firewall. If this is
true, then a malicious person could theoretically get packets thru Kerio
to any port.

Please read this link for details:

http://linuxtoday.com/news_story.php3?ltsn=1999-08-02-021-10-SC

Comments anyone? I know this won't be popular with Kerio 2.1.5 users,
as I myself love Kerio 2.1.5 above all the others and hate to part with
it. But I believe that the above is what's happening here. I would
invite any Kerio 2.1.5 users to turn on logging of ICMP Type 3 and watch
for a while to see if they see any outbound type 3 to IPs other than
their DNS servers. This is the result of the UPD packets getting thru
the firewall. If so, then it's happening to you too and Kerio is not
secure.

I've since switched to Sygate, which for me is the next best thing to
Kerio since it seems to know how to handle everything and is somewhat
configurable, and does a good job.

Any comments are appreciated... I felt that I owed it to the community
to share this since it seems to be a real problem with Kerio 2.1.5,
which is quite popular and used by many people.

--
Kerodo

Italy Anonymous Remailer

unread,
May 28, 2004, 8:15:55 PM5/28/04
to

Does not happen here.

Description: Other ICMP

Protocol: ICMP

Direction: Both

Set ICMP...

[0] Echo Reply, [3] Destination Unreachable, [4] Source Quench,
[5] Redirect, [6] Alternate Host Address, [9] Router Advertisement,
[10] Router Solicitation, [11] Time Exceeded, [12] Parameter Problem,
[13] Timestamp, [14] Timestamp Reply, [15] Information Request,
[16] Information Reply, [17] Address Mask Request,
[18] Address Mask Reply, [30] Traceroute, [31] Datagram Conversion Error,
[32] Mobile Host Redirect, [33] IPv6 Where-Are-You, [34] IPv6 I-Am-Here,
[35] Mobile Registration Request, [36] Mobile Registration Reply,
[37] Domain Name Request, [38] Domain Name Reply, [39] SKIP,
[40] Photuris, [xx] All ICMP Codes

Remote endpoint Address type: Any address

Rule valid: Always

Action: Deny

Log when this rule matches

mhicaoidh

unread,
May 29, 2004, 3:10:09 AM5/29/04
to
Taking a moment's reflection, Italy Anonymous Remailer mused:
|
| Does not happen here.

Seconded.


Alan Illeman

unread,
May 29, 2004, 10:08:45 AM5/29/04
to

"Italy Anonymous Remailer" <nob...@See.Comments.Header> wrote in message
news:C2SYDSCA3813...@anonymous.poster...

If I block outgoing Echo Reply [0], by ISP closes down my (dialup)
connection.

Alan Illeman

unread,
May 29, 2004, 10:19:57 AM5/29/04
to

"Kerodo" <kerodono...@hotmail.com> wrote in message
news:MPG.1b213e3d6...@news.west.cox.net...

> I'm posting this message because I believe I have found a vulnerability
> in Kerio 2.1.5 and that I should share this with other Kerio users who I
> believe are vulnerable to this exploit, even though I can't explain it
> all very well. I'll do my best.. What it boils down to is that a
> malicious person is able to get packets to any port past the firewall if
> they wish.
>
> Some time ago, I turned on logging of ICMP in Kerio and noticed that
> there was ICMP Type 3 outbound to various IP addresses, other than my
> DNS servers. I wasn't worried about Type 3 to my DNS servers since this
> appeared to be fairly safe and common, but the other destinations
> bothered me. Why would my machine be sending Type 3 to seemingly random
> IPs?

I allow [8] IN and [0] OUT (else my ISP folds my dialup connection) and
all other types are blocked IN and OUT, and logged - but no log entries
of any of the blocked types.


BoB

unread,
May 30, 2004, 9:51:49 AM5/30/04
to

How odd. Mine is set just the opposite, [0] IN and [8] OUT, with a
few others, and my ISP never drops my connection.

Different stokes for different ISPs. :-)

BoB

Alan Illeman

unread,
May 30, 2004, 11:30:19 AM5/30/04
to

"BoB" <m...@privacy.net> wrote in message
news:eaojb0lm42gkc2cms...@4ax.com...

Thanks Bob, mine IS: [0] IN and [8] out.

Stalks

unread,
May 30, 2004, 11:39:27 AM5/30/04
to
Alan Illeman wrote:

(snip)

> If I block outgoing Echo Reply [0], by ISP closes down my (dialup)
> connection.
>

Little OT:

Try enabling a specific rule to allow all ICMP, but log packets. Look at the log to see where the
ICMP Echo Requests are originating from and then add another rule to allow ICMP Requests only from
that origin, then "deny all icmp" afterwards, this would increase the stealth of your firewall
somewhat but not have your ISP disconnect you for apparent inactivity.

--
May the ping be with you ....

Registered Linux user number: 355729

Alan Illeman

unread,
May 30, 2004, 7:06:07 PM5/30/04
to

"Stalks" <so...@dont.want.spam.tv> wrote in message
news:Penuc.5601328$iA2.6...@news.easynews.com...

> Alan Illeman wrote:
>
> (snip)
>
> > If I block outgoing Echo Reply [0], by ISP closes down my (dialup)
> > connection.
> >
>
> Little OT:
>
> Try enabling a specific rule to allow all ICMP, but log packets. Look at
the log to see where the
> ICMP Echo Requests are originating from and then add another rule to allow
ICMP Requests only from
> that origin, then "deny all icmp" afterwards, this would increase the
stealth of your firewall
> somewhat but not have your ISP disconnect you for apparent inactivity.

I thought of that, but the server address varies.

0 new messages