Re: Political Analysis of Security Products

[Charles 'core' Stevenson <core () bokeoa com>]

"R. DuFresne" wrote:
> Marcus Ranum, if I recall correctly, has an outstanding reward for anyone
> with proof that fw-1 was ever backdoored by the Israeli's, it has never
> bee collected nor has any evidence of such a backdoor ever really been
> offered up.  It remains an unsubstantiated rumor, perhaps initiated by
> those competing with fw-1, years back.  An open backkdoor should be able
> to be gleened from port mapping techniques, the port has to be openly
> accesible for it to be used, yes?  A review/audit of the code for the
> product might further provide evidence, but, would require much more time
> as well as skill level <i.e. one would need to know C or C++ quite well,
> or whatever code base the application./device was written in>  An
> examination of theunderlying OS, before and after install, if this is not
> a drop and place and configure blackboox device might prove useful also.
> Most of the blackbox designs might prove hard to thouroughly audit from an
> OS/source perspective as they owner/writers might not be too willing to
> provide particulars of their design.

It's really hard to say. For example there's a piece of code on
packetstorm call cd00r.c from which I will paste the header comments:


/* cdoor.c 
 * packet coded backdoor
 * 
 * FX of Phenoelit <fx () phenoelit de>
 * http://www.phenoelit.de/  
 * (c) 2k 
 *
 * $Id: cd00r.c,v 1.3 2000/06/13 17:32:24 fx Exp fx $
 *
 *
    'cd00r.c' is a proof of concept code to test the idea of a 
    completely invisible (read: not listening) backdoor server. 

    Standard backdoors and remote access services have one major
problem: 
    The port's they are listening on are visible on the system console
as 
    well as from outside (by port scanning).

    The approach of cd00r.c is to provide remote access to the system
without 
    showing an open port all the time. This is done by using a sniffer
on the 
    specified interface to capture all kinds of packets. The sniffer is
not 
    running in promiscuous mode to prevent a kernel message in syslog
and 
    detection by programs like AnitSniff. 
    To activate the real remote access service (the attached code starts
an 
    inetd to listen on port 5002, which will provide a root shell), one
has to 
    send several packets (TCP SYN) to ports on the target system. Which
ports 
    in which order and how many of them can be defined in the source
code.

    When port scanning the target, no open port will show up because
there is 
    no service listening. After sending the right SYN packets to the
system, 
    cd00r starts the listener and the port(s) is/are open. One nice side
effect 
    is, that cd00r does not care whenever the port used as code is open
or not. 
    Services running on ports used as code are still fully functional,
but it's 
    not a very good idea to use these ports as explained later.

    The best way to send the required SYN packets to the system is 
    the use of nmap:
    ./nmap -sS -T Polite -p<port1>,<port2>,<port3>  <target>
    NOTE: the Polite timing ensures, that nmap sends the packets serial
as
    defined.

    Details:
    Prevention of local detection is done by several things:
    First of all, the program gives no messages et all. It accepts only
one 
    configurable command line option, which will show error messages for 
    the sniffer functions and other initialization stuff before 
    the first fork(). 
    All configuration is done in the first part of the source code as
#defines. 
    This leaves the target system without configuration files and the
process 
    does not show any command line options in the process table. When
renaming 
    the binary file to something like 'top', it is nearly invisible.

    The sniffer part of the code uses the LBNL libpcap and it's good
filter 
    functionality to prevent uninteresting traffic from entering the
much 
    slower test functions. By selecting higher, usually not used, ports
as 
    part of the code, the sniffer consumes nearly no processing time et
all.

    Prevention of remote detection is primary the responsibility of the 
    'user'. By selecting more then 8 ports in changing order and in the 
    higher range (>20000), it is nearly impossible to brute force these 
    without rendering the system useless. 
    Several configurable options support the defense against remote
attacks: 
    cd00r can look at the source address and (if defined) resets the
code if 
    a packet from another location arrives. By not using this function,
one 
    can activate the remote shell by sending the right packets from
several 
    systems, hereby flying below the IDS radar. 
    Another feature is to reset or not reset the list of remaining ports 
    (code list), if a false packet arrives. On heavy loaded systems this 
    can happen often and would prevent the authorized sender to activate 
    the remote shell. Again, when flying below the IDS radar, such 
    functionality can be counterproductive because the usual way to 
    prevent detection by an IDS is to send packets with long delays. 

    What action cd00r actually takes is open to the user. The function 
    cdr_open_door() is called without any argument. It fork()s twice 
    to prevent zombies. Just add your code after the fork()s.

    The functionality outlined in these lines of terrific C source can 
    be used for booth sides of the security game. If you have a system 
    somewhere in the wild and you don't like to show open ports (except 
    the usual httpd ;-) to the world, you may consider some
modifications, 
    so cd00r will provide you with a running ssh. 
    On the other hand, one may like to create a backchanel, therefor
never
    providing any kind of listening port on the system.

    Even the use of TCP SYN packets is just an example. Using the
sniffer,
    one can easily change the opening conditions to something like two
SYN, one 
    ICMP echo request and five UDP packets. I personally like the
TCP/SYN stuff
    because it has many possible permutations without changing the code.

 Compile it as:

 gcc -o <whatever> -I/where/ever/bpf -L/where/ever/bpf cd00r.c -lpcap

 of for some debug output:

 gcc -DDEBUG -o <whatever> -I/where/ever/bpf -L/where/ever/bpf cd00r.c
-lpcap

 */


As you can see a properly hidden backdoor could be impossible to detect.
I'm not sure if fw-1 was distributed as source or as a binary. I know a
lot of the critical infrastructure is running it though. Anyways if a
binary was created with trojaned tools as mentioned in the previous
message then a source code audit would do you no good. Scary eh ;)

Best Regards,
Charles Stevenson
 
> Thanks,
>
> Ron DuFresne
>
> On Tue, 5 Feb 2002 pentestlist () hushmail com wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> > I have never seen anything like this on the list so if it does not make it through I understand. I have a very 
> > large client right now who is paying for
> > a company wide (offices in 16 countries with 26 differant networks) audit
> > of their security infrastructure. Nothing really out of the ordinary here.
> >
> > What is differant for us at least is this client has asked us to review their
> > security products from a national security point of view. The case here is that
> > they run or are evaluating several products from Israel and one from South Korea and want us to evalute how likely 
> > it is that a sovereign state (in this
> > case Israel or South Korea) may have manipulated these products in order to gain
> > access to them remotely for their intel services.
> >
> > I remember reading years ago discussions like this about Firewall-1 and for the most part nothing of interest ever 
> > came from it. Does anyone have any evidence which can be publicly cited that something like this has ever happened? 
> > And does anyone here have any idea how we would go about performing a review like this without looking like 
> > conspiracy theorists?
> >
> >
> >
> > Hush provide the worlds most secure, easy to use online applications - which solution is right for you?
> > HushMail Secure Email http://www.hushmail.com/
> > HushDrive Secure Online Storage http://www.hushmail.com/hushdrive/
> > Hush Business - security for your Business http://www.hush.com/
> > Hush Enterprise - Secure Solutions for your Enterprise http://www.hush.com/
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: Hush 2.1
> > Note: This signature can be verified at https://www.hushtools.com
> >
> > wmAEARECACAFAjxgG0AZHHBlbnRlc3RsaXN0QGh1c2htYWlsLmNvbQAKCRCRKy2sIa3M
> > 7XHOAJ9HqkJR344rGzuxGwz2SfUE95E1ugCeN99PvLaIOVJJk7dSsHb1/wCJHjo=
> > =vhtz
> > -----END PGP SIGNATURE-----
> >
> >
> > ----------------------------------------------------------------------------
> > This list is provided by the SecurityFocus Security Intelligence Alert (SIA)
> > Service. For more information on SecurityFocus' SIA service which
> > automatically alerts you to the latest security vulnerabilities please see:
> > https://alerts.securityfocus.com/
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>         admin & senior security consultant:  sysinfo.com
>                         http://sysinfo.com
>
> "Cutting the space budget really restores my faith in humanity.  It
> eliminates dreams, goals, and ideals and lets us get straight to the
> business of hate, debauchery, and self-annihilation."
>                 -- Johnny Hart
>
> testing, only testing, and damn good at it too!
>
> ----------------------------------------------------------------------------
> This list is provided by the SecurityFocus Security Intelligence Alert (SIA)
> Service. For more information on SecurityFocus' SIA service which
> automatically alerts you to the latest security vulnerabilities please see:
> https://alerts.securityfocus.com/

----------------------------------------------------------------------------
This list is provided by the SecurityFocus Security Intelligence Alert (SIA)
Service. For more information on SecurityFocus' SIA service which
automatically alerts you to the latest security vulnerabilities please see:
https://alerts.securityfocus.com/