$1 Million hacking contest in danger

[InfoSec News <isn () c4i org>]

Forwarded from: H VC <overclocking_a_la_abuela () hotmail com>

[Lack of a lab around here, let alone the Alphashield product doesn't 
allow us to test the validity of the information below, so with that, 
your mileage may vary.  - WK]


Hi,

My name is Hugo Vázquez Caramés I´m a Security Analyst from Barcelona
Spain.  Here you have something that can be of your interest: the most
expected hacking contest is in danger. The "unhackable" Saafnet´s
AlphaShield device has been proved to be vulnerable to many attacks
that could allow bypassing it´s protection.
http://online.securityfocus.com/bid/6637 The next paper is a
description of how we broke this device.

Sincerely,

Hugo Vázquez Caramés




******************************************************
************** ALPHASHIELD SECURITY TEST *************
**************     INFOHACKING 2002      *************
******************************************************


Recently we got a demo unit of Saafnet´s AlphaShield device for evaluation 
purposes. This device comes with some (not very much) technical 
documentation, most of it lauding the AlphaShield features.

Due to the interest of some media on the contest being organized, in which 
Saafnet will be ready to pay a million of dollars to anyone who prove that 
his device is not so safe as they claim to be, we decided to give a chance 
to the AlphaShield and started to test it at our labs.

Firt of all we opened the device to see what it has got inside (there`s not 
public information on this), and we could realize that the chipset was 
entirely been tampered and painted with a black enamel in order to
hide the kind of hardware being used. It taked us five minutes to remove so 
hard protection. This are the chips used:

-3 Realtek´s RTL8019 (used in ethernet interfaces)
-1 Ubicom´s  SX52BD

After some searching for information of the "sx52bd" we found this: "The 
Ubicom SX48BD/SX52BD/SX52BD75/SX52BD100 are
members of the SX family of configurable communications a RISC-based 
architecture, allows high-speed computation, flexible I/O control, and 
efficient data manipulation." We could quicky see that there was not so much 
memory available (no RAM modules...), so probably it would be difficult to 
this device to track user sessions, at least in a serious way. In fact, the 
AlphaShield does something similar to connections tracking but in a 
stateless way.

To decide if an incoming packet belongs to a valid session started from the 
client, the AlphaShield does this:

-for TCP/UDP connections: it keeps track on source/destination ports and 
IP´s, but doen´t matter about sequence numbers.
-for ICMP: on the specific case of echo_request/echo_reply (PING), it only 
looks for the source IP of the echo_reply.
-for ARP: all "ARP replys" and "ARP Requests" are allowed.

This filtering way is not effective, moreover if we consider that the 
AlphaShield stores the source/destination IP´s and ports of any new socket, 
and it will allow any future incoming/outgoing packet matching those IP´s 
and ports. This "packet injection" could be done because of the stateless 
tracking method implemented (AlphaShield doesn´t look the 
SYN/ACK/FYN/RST...), so it never knows if a connection is still active or 
has been closed by any of the two end points.

The tests were done on a ethernet environment as showed below:

Attacker----Swicth-----AlphaShield-----Protected_PC (target)
172.26.0.x                              172.26.0.y


The target machine was running a sniffer in order to see all the packets 
received. On the attacker machine we used the well known software "hping2" 
as packet generator.

-TCP test: a) target machine connects with telnet to a telnet server on the 
Internet, then it closes the connection. b) attacker machine sends this 
packets: source_IP=telnet_server, destination_IP=target, 
source_port=23,destination_port=port_from_wich_target_originated_the_connection. 
Result: AlphaShield allows the incoming packets and we can see them with the 
sniffer on the target machine. No matter if the sent packet by the attacker 
had the SYN/ACK... flag activated, it was allowed.

-UDP test: a) target machine does a DNS query (UDP) to a nameserver on the 
Internet. b) attacker machine sends this packets: source_IP=DNS_server, 
destination_IP=target, source_port=53,
destination_port=port_from_wich_target_originated_the_connection. Result: 
AlphaShield allows the incoming packets and we can see them with the sniffer 
on the target machine.

-ICMP test: a) target machine does a ping (echo_request/echo_reply) to a 
server on the Internet. b) attacker machine sends ICMP´s (echo_reply) with 
source_address=server, destination_address=target. Result: AlphaShield 
allows the incoming packets and we can see them with the sniffer on the 
target machine.

-ARP test (with "arpoison"): a) attacker machine sends "ARP replys" to the 
target machine. It doesn´t matter the source IP, MAC... Result: AlphaShield 
allows the incoming packets and we can see them with the sniffer on the 
target machine. All incoming broadcast "ARP request" are also allowed. An 
ARP spoofing attack could be done easily. All the target traffic could be 
redirected to the attacker machine. (This is not an AlphaShield flaw, but it 
shows the danger of allowing incoming ARP packets without any kind of 
checking.

We have to notice that most of the attacks described above are only possible 
in those scenarios were the target has a routable IP address from the 
attacker machine. But in the worst case (target machine with private address 
and attacker from the Internet with public address), the responsable of 
stopping such attacks would be the forwarding/natting device in front of the 
AlphaShield and not the AlphaShield itself, so it does not apply to the goal 
of this paper: the analisys of the AlphaShield.


With this paper we would like to show real vulnerabilities on the Saafnet 
AlphaShield device that can be exploited remotely.
We would like also to notice that we don´t trust the planned contest by 
Saafnet because we think that probably it will not be done in a real 
enviroment (a real user working in the protected machine). Probably Saafnet 
is not going to pay anyone proving that his device is not working as 
expected,...

Hugo Vázquez Caramés & Toni Cortés Martínez
INFOHACKING TEAM
www.infohacking.com
Barcelona
Spain



-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomo () attrition org with 'unsubscribe isn'
in the BODY of the mail.