by Ch1can0 BEOWULF (beowulf@matarese.com)



This is some testing I did with queSO. 
QueSO means cheese in spanish, but does also mean que-SO or what-OS. 
If that was some useful news then send me a postcard.

Now, for the statistical performance of cheese : I say it gets the OS right 
most of the time. I wouldnt run any risks though. A friendly advice : don't use
it around and start trying to hack every page you see because as you may tell 
from the data below, some corporations are getting pretty tricky with their 
s3curity. 

Notice Microsoft : it has (probably) put a hacked version of NT online because 
the shipping version isn't good enough. The information returned from MSFT
confuses the queso fingerprint recognition and several computer systems are
innacurately detected. This is a case where trying a Solaris exploit would have
failed and, most likely, logged as a suspected connection. You know, the 
packets sent by cheese arent the everyday type....please see below for packet
information.


I think it would be useful to mention /proc here, as it is very closely 
related to all network-related commands in Linux.

/proc NOTES 

The proc filesystem is a special case of virtual disk access. When reading
info from /proc you are not accessing any block device, but some kernel
data structures in memory. These take the form of virtual files and they are:

 *  cmdline: agrs passed to kernel at bootup
 *  devices: controllers for devices included in kernel
 *  interrupts: hardware interrupts used by devices
 *  cpuinfo: exactly that
 *  dma: channels used by controllers
 *  filesystems: the fs's recognized by this kernel
 *  ioports: just what you read
 *  kcore: kernel memory
 *  kmsg: last messages issued by kernel see also the command 'dmesg'
 *  loadavg: system load summary and averages
 *  locks: files locked summary
 *  modules: see man page for 'lsmod' - list loaded modules
 *  meminfo: memory statistics 

If you compiled the kernel with profiling support you might see a 'profile'
directory under /proc. 

Other information found under /proc are mounts, pci device listinbg, real time 
clock info (in '/proc/rtc') various statistics compiled in /proc/stat, multi-
processor status in 'smp', system 'uptime' and kernel 'version'.


Queso depends on a proc filesystem being present. This doesnt really matter
much anymore as most compilations of the Linux kernel do offer support the
proc filesystem. Notice that the Linux 'ps' also needs to read information
from /proc. This might be useful when securing the system : by chmodding 700 
/proc you only allow root to read and write from the files therein, so that
'ps' won't reveal anything you don't want it to. The kernel wont even 
notice changes in userland file permissions. Programs lique queso, ps and 
netstat will be restricted to use by root.

Eg.  (tcpip.c from queso source)

if ((f = fopen ("/proc/net/route", "r")) == NULL)
    {
          perror ("opening /proc/net/route");
          exit (EXIT_FAILURE);
    }


Eg.  (output from 'strace netstat')
     
open("/proc/net/ipx", O_RDONLY)         = -1 ENOENT (No such file or directory)
open("/proc/net/ax25", O_RDONLY)        = -1 ENOENT (No such file or directory)
open("/proc/net/ax25", O_RDONLY)        = -1 ENOENT (No such file or directory)
open("/proc/net/nr", O_RDONLY)          = -1 ENOENT (No such file or directory)



FINAL NOTES

The test drives for queso went alright. It is a nice tool, but as security
improves in commercial bloatware such as NAI's and Norton's(Symantec has been
hacked recently!) many administrators will have an easy queso-detection tool. 
Even if their skill level isn't very advanced. As you may see below the sequence
of packets sent is not very common, and that's the whole point to queso. If the
behavior expected from the receival of a type of packet is not well defined then
there is a tendency to have a different implementation from each vendor or 
developers(in the case of Linux as it's not a commercial OS). Thats where the
fingerprint is stamped on each packet. See below for the packet summary.


From queso_README, or www.apostols.org/projectz/queso page:

"...

what packets does QueSO send?

        0 SYN           * THIS IS VALID, used to verify LISTEN
        1 SYN+ACK
        2 FIN
        3 FIN+ACK
        4 SYN+FIN
        5 PSH
        6 SYN+XXX+YYY   * XXX & YYY are unused TCP flags

        All packets have a random seq_num and a 0x0 ack_num.
							
..."



Some interesting results pulled from various sites:


[root@ozzy security]# queso www.microsoft.com
207.46.130.149:80       * Standard: Solaris 2.x, Linux 2.1.???, MacOS
207.46.130.150:139	* Dead Host, Firewalled Port or Unassigned IP
207.46.131.13:80	*- Unknown OS, pleez update /usr/local/etc/queso.conf
207.46.131.15:53	* Dead Host, Firewalled Port or Unassigned IP
207.46.131.137:80	* Gandalf Xpressway/XpressStack (by aland@striker.ottawa.on.ca)


[root@ozzy security]# queso www.altavista.com
204.152.190.70:80       *- Unknown OS, pleez update /usr/local/etc/queso.conf
204.152.190.70:80	*- Unknown OS, pleez update /usr/local/etc/queso.conf
204.152.190.70:80	* Berkeley: usually Digital Unix, OSF/1 V3.0, HP-UX 10.x
204.152.190.70:80	*- Unknown OS, pleez update /usr/local/etc/queso.conf


[root@ozzy security]# queso www.ddj.com
199.125.85.76:80        * BSDi 3.0, IBM S/390
199.125.85.76:80	* BSDi 3.0, IBM S/390
199.125.85.76:80	* CISCO-IOS 11.0  
199.125.85.76:80	*- Unknown OS, pleez update /usr/local/etc/queso.conf


[root@ozzy security]# queso www.insecure.org
170.1.69.198:80 * IRIX 6.x?
204.71.107.21:80	* FreeBSD, NetBSD, OpenBSD  
170.1.69.198:80	*- Firewalled host/port or network congestion  
204.71.107.21:80	* FreeBSD, NetBSD, OpenBSD  


[root@ozzy security]# queso www.transmeta.com
206.184.214.11:80       *- Unknown OS, pleez update /usr/local/etc/queso.conf
206.184.214.11:80	* Linux 1.3.xx, 2.0.0 to 2.0.34 
206.184.214.11:80	* Linux 1.3.xx, 2.0.0 to 2.0.34 
206.184.214.11:80	* Linux 1.3.xx, 2.0.0 to 2.0.34 


Tests run using :

[root@ozzy bin]# queso -v
$Id: queso.c,v 1.20 1998/09/22 20:35:43 savage Exp $
$Id: tcpip.c,v 1.15 1998/09/22 20:35:43 savage Exp $









This page was created Wed Aug 11 12:50:22 EDT 1999


Using Linux
 version 2.0.32
 on an i586

unix   linux   networking   c   c++   operating systems     Copyright (C) 1999 - Matarese.com