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.
Received on Wed Jan 29 04:53:35 2003