$arr_19 ), array( 3, false, $arr_20, $arr_24 ), array( 2, false, "\" />", $arr_25 ) ) ); ?> $arr_27 ), array( 3, false, $arr_28, $arr_30 ), array( 2, false, "\" />\n\n", $arr_31 ) ) ); ?> array( 2, false, false, $arr_9 ), array( 4, $arr_10, "if", $arr_245, $arr_248 ), array( 2, false, "\n", $arr_249 ) ) ); ?> rr_466 ), array( 4, $arr_467, "if", $arr_482, $arr_484 ), array( 2, false, "\n", $arr_485 ) ) ); ?> Huge Hole in Yoggie USB Stick Firewall » Linux Magazine
 

Huge Hole in Yoggie USB Stick Firewall

May 30, 2008

A full-fledged Linux computer on a USB stick: Yoggie uses this astonishing hardware trick to protect Windows machines against Web-based attacks. But there are some things that do not work as intended by the developers as an exhaustive test in Linux Magazine #94 / September will reveal. Just a few simple tricks were all it took to work around the firewall.

In our lab Linux Magazine author Jörg Fritsch discovered a major vulnerability in the Yoggie gatekeeper, Pico version 1.3.8 that gives attackers the ability to work around the firewall and directly attack the target system. The only requirement was for the attacker to be on the same subnet as the target system's physical interface. This is the case on an enterprise LAN, for example, but also on an Ethernet network at a hotel, or a WLAN hotspot at an airport. Of course, these are exactly the kind of hostile environment in which Yoggie is designed to protect users. The proof-of-concept attack involved four steps:

Step 1: A Nessus scan of the Yoggie-protected system would seem to indicate that the IP address belonging to the physical interface is perfectly protected – the system does not react to any kind of packets sent to it. Surprisingly a UDP traceroute revealed the internal IP address belonging to the Yoggie stick, that is, the address the stick uses to communicate with the host system.

Step 2: Initially it is impossible to scan the internal address, as its subnet is unknown and not routed. Our test team chose a suitable group 16 subnet mask that would work in any case and set up a route to the subnet on the attacking machine. The physical interface of the protected system was used as the gateway address.

Step 3: An Nmap scan of the new routed group 16 subnet revealed two addresses: the Yoggie firewall appliance's internal address and that of the new virtual host adapter.

Step 4: The final Nessus scan of both IP addresses revealed the vulnerability: the host system state is visible to Nessus as if Yoggie wasn't in place. There would be nothing to stop an attacker exploiting any vulnerabilities on the host system.

 

The author immediately disclosed the vulnerability to Yoggie (in the night of March 16/17 2008), and the manufacturer developed an update to version 1.3.9 with 36 hours to remove the security hole. The response time is fast, but the vendor's information policy is anything but exemplary. The company responded negatively to various inquiries as to when Yoggie would be releasing an advisory on the vulnerability, stating that Yoggie automatically installs updates and this was far more than a classical advisory could ever hope to achieve. The only reference to the security disaster is in a history file on the firmware:

1.3.9 (18 March 2008)
-------------------------------
Fixed:
------
Issue #1008: Critical security update; device hardening including network
interfaces and improved Firewall stealth mode

This is not a convincing argument. If a stick does not have an online connection, the system is still vulnerable; and even if a connection exists, there is still a race condition that leaves the host vulnerable. As the attacker has to be on the LAN, situations where the system would be vulnerable to attacks while the gatekeeper was installing an update are conceivable. Corporate mode also gives the administrator the ability to say which updates are installed on sticks. The terse comment quoted above makes it impossible for users to realize the full potential of the threat. An Yoggie has still not revealed the bug two months after the event.

Yoggie failed to give a full explanation of the vulnerability at first, but then confirmed our author's, and Linux Magazine's suspicions. Basically, the gatekeeper acts as a NAT router like any normal Linux firewall, the only exception being the connection to the Windows system. This means that all precautions that apply to the firewall configuration apply here, too. The Yoggie stick created netfilter rules but without specifying interfaces: the »-i« and »-o« parameters thus only applied to the IP addresses.

The proof-of-concept attack sent packets directly targeted at the internal address to the external interface. The Linux kernel's internal routing algorithms correctly forwarded the packets without a firewall rule intervening.

The full article with an exhaustive test of the Yoggie Pico Gatekeeper will be available in Linux Magazine #94 / September.

comments powered by Disqus

Issue 152/2013

Tag Cloud

Bruce Byfield Gnome KDE Kernel Linux Linux Pro Magazine Open Source Projects Red Hat Ubuntu events foss free software google

News