[ISN] $1 Million hacking contest in danger

From: InfoSec News (isnat_private)
Date: Wed Jan 29 2003 - 00:32:32 PST

  • Next message: InfoSec News: "RE: [ISN] DoD offering admin privileges on .mil Web sites"

    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]
    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.
    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, 
    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 
    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 
    Hugo Vázquez Caramés & Toni Cortés Martínez
    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