Forwarded from: H VC <overclocking_a_la_abuelaat_private> [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 majordomoat_private with 'unsubscribe isn' in the BODY of the mail.
This archive was generated by hypermail 2b30 : Wed Jan 29 2003 - 02:51:04 PST