lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
From: mr at german-secure.de (Marko Rogge | German-Secure) Subject: Vulnerability ZoneAlarm Pro 4.5.532.000 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
Powered by blists - more mailing lists