Kerio 2.1.5 vulnerability

[Hassan I Sahba]

Crosposted to: comp.security.firewalls and alt.comp.freeware

Awhile ago in comp.security.firewalls a poster called Kerodo posted
this article:

http://makeashorterlink.com/?Z42A146B9

which contains a link to this 1999 advisory:

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

which I believe was based on this 1998 paper:

Insertion, Evasion, and Denial of Service: Eluding Network Intrusion
Detection
http://www.snort.org/docs/idspaper/

As I used Kerio I put it in the 2do list as something to play with,
and recently got round to checking it out.

I went to the grc Shields UP site and passed their scan with all ports
"stealthed". They then told me "From the standpoint of the passing
probes of any hacker, this machine does not exist on the Internet."

Kerio was configured to Log Packets Addressed to Unopened Ports and
Log Suspicious Packets. Then I made a new rule to block ALL incoming
and outgoing TCP connections and moved it to the top of Kerio's rule
set. Then I made another rule to block ALL ICMP, and made it second
in the list. Both these rules were set to log and alert.
TYPSoft FTP Server Version 1.10 was used to open port 21.

All the following packets are TCP sent by hping2 on Linux to an XPpro
(SP2) machine running Kerio 2.1.5.

When sending a SYN to an open or closed port I got no reply. Kerio
logged it and showed an alert. Kerio's red (traffic denied) arrow
flashed in systray.
This is the only good result here.

When I sent a FIN, ACK or RST to an open or closed port I got no
reply. Kerio did not log it. or show an alert. The green (traffic
allowed) arrow flashed.
I can understand Kerio not logging this but not why it was allowed.

When I sent a PUSH or an URG to an open or closed port I received a
RST, ACK in reply. Kerio did not log it or show an alert. The green
arrow flashed. Ethereal logged the return packet as a [Tcp Zero
Window] segment.
A return packet. There goes "stealth" out the window. This clearly
shows there is a machine behind the firewall.

When I sent a SYN with the fragment bit set to a closed port I got a
RST, ACK (port closed) back. Kerio did not log it or show an alert.
The green (traffic allowed) arrow flashed.
It's getting worse!!

When I sent a SYN with the fragment bit set to an open port (21) I got
a SYN, ACK (connection accepted) back. Kerio did not log it or show an
alert. The green (traffic allowed) arrow flashed. The ftp server
logged the attempted connection and asked for a user name. Then I
tried again with netcat listening on 21, and netcat saw the incoming
packet and returned a SYN, ACK.
Aaaaarrrggghh!!!!!!!! An accepted connection through the firewall.
All our Kerio's are belong to them :'-(

I had planned to try ICMP packets next, but what's the point?

So it seems any packet with the fragment bit set goes straight through
the firewall, and kerio only logs plain SYN packets.
This vulnerability is nearly 7 YEARS OLD, so there must be people
exploiting it by now. Nice one Kerio. How long have they known this?
Do they not try and enumerate their own firewall?
If they didn't know they are fools and I can no longer trust them.
If they did know and didn't withdraw Kerio I can no longer trust them.

The above may seem complicated to some but this is basic scanning, and
I'm no expert. One day I finally got round to setting up a Linux box,
the next day I played with Hping2 and found this, yet I found nothing
on Google describing this. Surprising to say the least.

So what next I thought. ZoneAlarm of course. I got
zls-free-Setup51033000.exe and installed it. I had to clean kerio
from the registry by hand first as it didn't uninstall cleanly.
ZoneAlarm wasn't vulnerable (but I don't like it). Next I tried Kerio
4.1.1. Not vulnerable (but my trust is gone).

With info from the above links and a little knowledge of Kerio it's
easy to locate and connect to Kerio 2.1.5 boxes.
What next? It's format and reinstall windows for me.

HiS

 

[Kerodo]

So it seems any packet with the fragment bit set goes straight through
the firewall, and kerio only logs plain SYN packets.
This vulnerability is nearly 7 YEARS OLD, so there must be people
exploiting it by now. Nice one Kerio. How long have they known this?
Do they not try and enumerate their own firewall?
If they didn't know they are fools and I can no longer trust them.
If they did know and didn't withdraw Kerio I can no longer trust them.

I am the one who originally wrote about the fragmented packet
vulnerability. I noticed it here many months ago, and have never been
able to get anyone else to listen or verify it. I will not use Kerio
2.1.5 any more because of this problem. It's clear to me that Kerio
2.1.5 does NOT handle fragmented packets properly, and that they DO get
in thru the firewall.

The only reason why I noticed it is because the Messenger spammers are
using this exploit to get spam packets thru firewalls that don't handle
fragmented packets properly. They typically come in with a fragmented
packet to port 1026. In Kerio 2, you will see an outbound ICMP type 3
as a result of the inbound packet getting thru.

At any rate, what you are seeing there is true. I have verified it here
many times.

So what next I thought. ZoneAlarm of course. I got
zls-free-Setup51033000.exe and installed it. I had to clean kerio
from the registry by hand first as it didn't uninstall cleanly.
ZoneAlarm wasn't vulnerable (but I don't like it). Next I tried Kerio
4.1.1. Not vulnerable (but my trust is gone).

Strangely enough, Kerio 4.x.x does NOT have the same problem. I'm using
Kerio 4.1.2 right now with my Kerio 2 rule set without any problems,
other than poor logging. I believe they re-wrote Kerio 4 from scratch
so it does not have the fragmented packet processing problem that Kerio
2 does. Or if it is based on Kerio 2, then they fixed the problem.
I've tested it quite a bit.

With info from the above links and a little knowledge of Kerio it's
easy to locate and connect to Kerio 2.1.5 boxes.
What next? It's format and reinstall windows for me.

HiS

Kerio 2.1.5 (and earlier) is the only firewall I've found that has
problems with fragmented packets, and I've tried MANY others and
checked. I think you can probably trust most of the others, including
Sygate, ZoneAlarm, VisNetic, Outpost, Jetico and so on..

Until I discovered that problem, Kerio 2.1.5 was my favorite firewall.
I hated parting with it. I have not seen any harmful exploits of this
vulnerability yet, and I doubt that most people would anyway, but it
bothers me enough to discontinue it's use and switch to something more
secure.

 

[Hassan I Sahba]

I am the one who originally wrote about the fragmented packet
vulnerability. I noticed it here many months ago, and have never been
able to get anyone else to listen or verify it. I will not use Kerio
2.1.5 any more because of this problem. It's clear to me that Kerio
2.1.5 does NOT handle fragmented packets properly, and that they DO get
in thru the firewall.

I remember Does anyone else here use Kerio 2.1.5 on a LAN? If
more people confirm this more people will listen. Here's the links for
Hping2 if any ones interested:
Linux: http://www.hping.org/hping2.0.0-rc3.tar.gz
Win32: http://wiki.hping.org/uploadedfiles/86/hping2.1-rc2-win32.zip
(Requires WinPCap and Cygwin1.dll)
Mac: http://www.hping.org/macosx/hping2-macosx-rc2-bin

The only reason why I noticed it is because the Messenger spammers are
using this exploit to get spam packets thru firewalls that don't handle
fragmented packets properly. They typically come in with a fragmented
packet to port 1026. In Kerio 2, you will see an outbound ICMP type 3
as a result of the inbound packet getting thru.

Interesting. Do you have any Ethereal logs of these packets?
I get a few UDP's to 1026 and used to see outbound ICMP type 3 using
2.1.5 but they all went to my DNS server as far as I can remember.

I have a rule to alert on inbound 1026 to remind me I am still online
(dial-up).

At any rate, what you are seeing there is true. I have verified it here
many times.


Strangely enough, Kerio 4.x.x does NOT have the same problem. I'm using
Kerio 4.1.2 right now with my Kerio 2 rule set without any problems,
other than poor logging. I believe they re-wrote Kerio 4 from scratch
so it does not have the fragmented packet processing problem that Kerio
2 does. Or if it is based on Kerio 2, then they fixed the problem.
I've tested it quite a bit.

I've still got 4.1.1 installed, not sure I'll keep it though.

Kerio 2.1.5 (and earlier) is the only firewall I've found that has
problems with fragmented packets, and I've tried MANY others and
checked. I think you can probably trust most of the others, including
Sygate, ZoneAlarm, VisNetic, Outpost, Jetico and so on..

I haven't used Sygate or Outpost for years, so I'll have a look at
them.

Until I discovered that problem, Kerio 2.1.5 was my favorite firewall.
I hated parting with it. I have not seen any harmful exploits of this
vulnerability yet, and I doubt that most people would anyway, but it
bothers me enough to discontinue it's use and switch to something more
secure.

You wouldn't see them in Kerio because it's FUBAR, lets the packets
through and doesn't log them. Which is probably why they scrapped it
and started a new version. How much more harmful can you get?

HiS

 

[Kerodo]

Interesting. Do you have any Ethereal logs of these packets?
I get a few UDP's to 1026 and used to see outbound ICMP type 3 using
2.1.5 but they all went to my DNS server as far as I can remember.

No, I don't have any Ethereal logs or anything like that. I noticed the
ICMP type 3 to my DNS servers too, but whenever a fragmented packet got
thru, I also saw an outbound type 3 to wherever it came from. That's
what alerted me to the problem in the first place... seeing the type 3
packets to addresses other than DNS servers.

I have a rule to alert on inbound 1026 to remind me I am still online
(dial-up).

I also noticed the fragments when I ran Sygate for a while. They showed
up as "non-first fragments" in Sygate's logs. A packet along with
another one at the same instant in time to port 1026. Sygate blocked
both, but Kerio let's them thru. That's what's happening here at any
rate. I think it's possible that most people don't notice it because
nobody is exploiting it in their area.

I've still got 4.1.1 installed, not sure I'll keep it though.

I'm experimenting with 4.1.2 right now. There are a lot of bugs left in
4.1.xx, but so far it's tolerable here..

You wouldn't see them in Kerio because it's FUBAR, lets the packets
through and doesn't log them. Which is probably why they scrapped it
and started a new version. How much more harmful can you get?

It's pretty bad, yes..

I don't know if you will be able to get anyone else to listen here, but
hopefully people will. Many people like Kerio 2.x a lot, and would hate
to hear something bad about it. You're likely to get mostly
resistance.. unfortunately. I guess people can continue to use it at
their own risk.. not I though..

 

[Kerodo]

Interesting. Do you have any Ethereal logs of these packets?
I get a few UDP's to 1026 and used to see outbound ICMP type 3 using
2.1.5 but they all went to my DNS server as far as I can remember.

I have a rule to alert on inbound 1026 to remind me I am still online
(dial-up).

Just another thought on the above. Since you're using dial-up, you may
not even see that ICMP type 3 outbound, or the spammers 1026 packets
inbound. I'm on cable here 24/7, so that's another story. That's
probably why I see it and others often don't..

At any rate, your tests are much more convincing than my ICMP type 3..

 

[JP Loken]

I don't know if you will be able to get anyone else to listen here, but
hopefully people will. Many people like Kerio 2.x a lot, and would hate
to hear something bad about it. You're likely to get mostly
resistance.. unfortunately. I guess people can continue to use it at
their own risk.. not I though..

Thanks to both of you!
I didn't understand everything, but enough to be convinced. Kerio 2.x is
now deleted from my home computer.

 

[Aaron]

It's pretty bad, yes..

I don't know if you will be able to get anyone else to listen here, but
hopefully people will. Many people like Kerio 2.x a lot, and would hate
to hear something bad about it. You're likely to get mostly
resistance.. unfortunately. I guess people can continue to use it at
their own risk.. not I though..

You are not the first to mention this. I've seen it mentioned a dozen
times at least even on this group. But there doesn't seem to be any good
choices in the freeware area.

Kerio 4 maybe, but from all reports it still seems a bit buggy.

ZA free is too basic, Outpost free is abandoned, and Sygate has the
problem with loopback rules.

 

[Kerodo]

You are not the first to mention this. I've seen it mentioned a dozen
times at least even on this group. But there doesn't seem to be any good
choices in the freeware area.

Kerio 4 maybe, but from all reports it still seems a bit buggy.

ZA free is too basic, Outpost free is abandoned, and Sygate has the
problem with loopback rules.

Yes, Kerio 4 is very buggy. I've tested it at various times since 4.0
first came out and there's always many unfixed bugs to deal with. ZA,
although perhaps too simple for some, is still a good basic firewall
with stateful inspection. I would think that it would be preferable to
one (like Kerio 2.1.5) which let's traffic thru eroneously.

Another one that's free, at least at the moment, as it's still in beta,
is Jetico Personal Firewall. It's more powerful than Kerio 2.x and
although rather complicated for the average user, it seems to be fairly
good. Whether it will remain freeware after it's final release is
unknown at the moment however..

You can find it at: http://www.jetico.com/

 

[Hassan I Sahba]

No, I don't have any Ethereal logs or anything like that. I noticed the
ICMP type 3 to my DNS servers too, but whenever a fragmented packet got
thru, I also saw an outbound type 3 to wherever it came from. That's
what alerted me to the problem in the first place... seeing the type 3
packets to addresses other than DNS servers.

Do you know what code the type 3's had? Probably code 2 or 3 I would
think. Kerio only informs you of the type, not the code, which is a
pain.

I also noticed the fragments when I ran Sygate for a while. They showed
up as "non-first fragments" in Sygate's logs. A packet along with
another one at the same instant in time to port 1026. Sygate blocked
both, but Kerio let's them thru. That's what's happening here at any
rate. I think it's possible that most people don't notice it because
nobody is exploiting it in their area.

This is worth a read, it's quite short for an RFC:

Security Considerations for IP Fragment Filtering
http://rfc.net/rfc1858.html

"Fortunately, we do not need to remove all fragments of an offending
packet. Since "interesting" packet information is contained in the
headers at the beginning, filters are generally applied only to the
first fragment. Non-first fragments are passed without filtering,
because it will be impossible for the destination host to complete
reassembly of the packet if the first fragment is missing, and
therefore the entire packet will be discarded."

Non-first fragments can be sent with Hping2 with this option:
-g --fragoff set the fragment offset
Set it to 1.

I found another packet crafting tool called Frameip but I haven't
tried it out yet. www.frameip.com

His

 

[Hassan I Sahba]

Thanks to both of you!
I didn't understand everything, but enough to be convinced. Kerio 2.x is
now deleted from my home computer.

Well done mate. You're better of without it.

HiS

 

[Hassan I Sahba]

You are not the first to mention this. I've seen it mentioned a dozen
times at least even on this group. But there doesn't seem to be any good
choices in the freeware area.

Kerio 4 maybe, but from all reports it still seems a bit buggy.

ZA free is too basic, Outpost free is abandoned, and Sygate has the
problem with loopback rules.

After googling a bit harder I found posts going back to 1991 referring
to Tiny firewall and fragments. I'm suprised it's not more widely
known.

I agree with your ZoneAlarm comment. I intended to look at Outpost and
Sygate. I won't bother with Outpost if it's abandoned, and I'll Google
the Sygate loopback problem. Thanks.

HiS

 

[Hassan I Sahba]

Just another thought on the above. Since you're using dial-up, you may
not even see that ICMP type 3 outbound, or the spammers 1026 packets
inbound. I'm on cable here 24/7, so that's another story. That's
probably why I see it and others often don't..

At any rate, your tests are much more convincing than my ICMP type 3..

I remember seeing ICMP type 3 outbound and incoming UDP 1026 in the
logs. Ethereal confirmed the 1026's were Messenger spam. I didn't get
round to checking out the type 3's though.

On a lighter note my local exchange is ADSL enabled now, so as soon as
I find a suitable provider I'll subscribe. We got a gas connection and
ADSL in the same month. What more could a cold modem user want?

HiS

 

[Kerodo]

Do you know what code the type 3's had? Probably code 2 or 3 I would
think. Kerio only informs you of the type, not the code, which is a
pain.

No, unfortunately I don't.. Kerio doesn't offer that info. Others do,
for example Jetico and Outpost I believe does, but no such luck in
Kerio.

This is worth a read, it's quite short for an RFC:

Security Considerations for IP Fragment Filtering
http://rfc.net/rfc1858.html

"Fortunately, we do not need to remove all fragments of an offending
packet. Since "interesting" packet information is contained in the
headers at the beginning, filters are generally applied only to the
first fragment. Non-first fragments are passed without filtering,
because it will be impossible for the destination host to complete
reassembly of the packet if the first fragment is missing, and
therefore the entire packet will be discarded."

Non-first fragments can be sent with Hping2 with this option:
-g --fragoff set the fragment offset
Set it to 1.

I found another packet crafting tool called Frameip but I haven't
tried it out yet. www.frameip.com

Very intersting. Someone in another forum has voiced the opinion that
this exploit could not really be used to establish a concurrent TCP
session (whatever that means?). So in his opinion, all this is not
really a serious problem. Whether or not this is true, I don't know,
but I don't feel comfortable with any firewall that allows packets thru,
harmful or not. It's a firewall's job to keep packets out.

I'm using VisNetic Firewall now. It's a straightfoward rules based
stateful inspection firewall. No outbound app control, but it should be
all I need assuming I practice safe computing.

 

[Kerodo]

After googling a bit harder I found posts going back to 1991 referring
to Tiny firewall and fragments. I'm suprised it's not more widely
known.

I agree with your ZoneAlarm comment. I intended to look at Outpost and
Sygate. I won't bother with Outpost if it's abandoned, and I'll Google
the Sygate loopback problem. Thanks.

Sygate is pretty good. A little more resource (CPU and RAM) intensive
than most, but it's not bad. I didn't like Sygate's logging though.
Too much information in the logs, without any way to exclude parts of
it. I don't need to see EVERYTHING that's happening..

Outpost Pro is pretty good also. The free version is abandoned, but the
pay version is actively developing. It's logging is very nice. You can
set up filters and so on, to see just what you want. I found it's
stateful inspection a little weird though. It's not clear whether SPI
is in use all the time by default, or whether you have to enable the
option for every single app and port and connection and so on. And the
FAQs didn't clear this up much either.

At any rate, both are good firewalls. I'd consider them superior to
Kerio 2 at this point, given your test results.

 

[Aaron]

Yes, Kerio 4 is very buggy. I've tested it at various times since 4.0
first came out and there's always many unfixed bugs to deal with. ZA,
although perhaps too simple for some, is still a good basic firewall
with stateful inspection.

Moving from a rules based firewall to one where firewall rules are tied
to application only seems to be a very big loss of functionality if not
security.

Another one that's free, at least at the moment, as it's still in
beta, is Jetico Personal Firewall. It's more powerful than Kerio 2.x
and although rather complicated for the average user, it seems to be
fairly good. Whether it will remain freeware after it's final release
is unknown at the moment however..

You can find it at: http://www.jetico.com/

Given the past record of the company, I think it's certain it will go
payware.

 

[Kerodo]

Moving from a rules based firewall to one where firewall rules are tied
to application only seems to be a very big loss of functionality if not
security.

I prefer rules myself too...

Given the past record of the company, I think it's certain it will go
payware.

Quite possibly/probably.. It's quite a powerful little firewall, but
it's a little over-complicated too. And there are still some issues
that I was trying to get them to fix that they don't agree with. When a
TCP packet comes in to a port where a program is listening, it appears
that the firewall is letting the packet in, and then their stateful
inspection, or so they say, is blocking the resulting OS response
outbound (an RST ACK I believe). In my opinion, the firewall should
never allow the packet in to the OS to begin with, if it's not permitted
by the user. They seem to either disagree with me or not understand
what I'm saying.

Oh well..

 

[mhicaoidh]

Taking a moment's reflection, Hassan I Sahba mused:
|
| The green (traffic allowed) arrow flashed.

I believe the green and red arrows on the Kerio icon in the System Tray
merely indicate inbound (green) and outbound (red) traffic. This is
somewhat of a standard as Kerio, ZA, and perhaps Sygate used this same
format. I do not believe they indicate "allowed" or "blocked" traffic.

 

[Hassan I Sahba]

Very intersting. Someone in another forum has voiced the opinion that
this exploit could not really be used to establish a concurrent TCP
session (whatever that means?). So in his opinion, all this is not
really a serious problem. Whether or not this is true, I don't know,
but I don't feel comfortable with any firewall that allows packets thru,
harmful or not. It's a firewall's job to keep packets out.

If Kerio returns a SYN ACK that's 2 thirds of the handshake completed,
but Hping2 doesn't send an ACK to complete the connection.
I installed OpenBSD on an old P133, but it couldn't find the network
card. When I get time to get it sorted I'll install fragrouter and
find out for sure.

I'm using VisNetic Firewall now. It's a straightfoward rules based
stateful inspection firewall. No outbound app control, but it should be
all I need assuming I practice safe computing.

I like app control. My keyboard wants to connect out to port 80

HiS.

 

[Hassan I Sahba]

Taking a moment's reflection, Hassan I Sahba mused:
|
| The green (traffic allowed) arrow flashed.

I believe the green and red arrows on the Kerio icon in the System Tray
merely indicate inbound (green) and outbound (red) traffic. This is
somewhat of a standard as Kerio, ZA, and perhaps Sygate used this same
format. I do not believe they indicate "allowed" or "blocked" traffic.

You can check it with the ping command. If you allow all ICMP and ping
someone the green arrow flashes. If you deny all ICMP and ping someone
the red arrow flashes.
If it was green for inbound and red for outbound both arrows would
flash as you sent a request and received a reply.

 

[Kerodo]

Taking a moment's reflection, Hassan I Sahba mused:
|
| The green (traffic allowed) arrow flashed.

I believe the green and red arrows on the Kerio icon in the System Tray
merely indicate inbound (green) and outbound (red) traffic. This is
somewhat of a standard as Kerio, ZA, and perhaps Sygate used this same
format. I do not believe they indicate "allowed" or "blocked" traffic.

I think that you might at minimum have it backwards.. When I used to
run Kerio and go to grc.com to run the tests, as they were running I
would see the red arrow flashing constantly, which means either blocked
traffic or inbound traffic.