Vulnerability
Passive System Fingerprinting using Network Client Applications
Affected
munices
Description
Jose Nazario posted following white paper. Here is his a low-jack
approach to passive network analysis. Passive target
fingerprinting involves the utilization of network traffic between
two hosts by a third system to identify the types of systems being
used. Because no data is sent to either system by the monitoring
party, detection approaches the impossible. Methods which rely
solely on the IP options present in normal traffic are limited
in the accuracy about the targets. Further inspection is also
needed to determine avenues of vulnerability, as well. We
describe a method to rapidly identify target operating systems
and version, as well as vectors of attack, based on data sent by
client applications. While simplistic, it is robust. The
accuracy of this method is also quite high in most cases. Four
methods of fingerprinting a system are presented, with sample data
provided.
Passive OS mapping has become a new area of research in both white
hat and black hat arenas. For the white hat, it becomes a new
method to map their network and monitor traffic for security. For
example, a new and possibly subversive host can be identified
quickly, often with great accuracy. For the black hat, this
method provides a nearly undetectable method to map a network,
finding vulnerable hosts.
To be sure, passive mapping can be a time consuming process. Even
with automated tools like Siphon (a sufficient quantity packets to
arrive to build up a statistically significant reading of the
subjects' operating systems). Compare this to active OS
fingerprinting methods, using tools like nmap and queso, which can
operate in under a minute usually, and only more determined
attackers, or curious types, will be attracted to this method.
Siphon, nmap and queso are available from:
http://www.subterrain.net/projects/siphon/
http://www.insecure.org/nmap/
http://www.apostols.org/
Two major methods of operating system fingerprinting exist in
varying degrees of use, active and passive. Active scanning
involves the use of IP packets sent to the host and the scanner
then monitoring the replies to guess the operating systems.
Passive scanning, in contrast, allows the scanning party to obtain
information in the absence of any packets sent from the listening
system to the targets. Each method has their advantages, and
their limitations.
Active Scanning
===============
By now nearly everyone is familiar with active scanning methods.
The premier port scanning tool, nmap, has been equipped for some
time now with accurate active scanning measures. This code is
based off of an earlier tool, queso, from the group The Apostols.
Nmap's author, Fyodor, has written an excellent paper on this
topic in the e-zine Phrack (issue 54 article 9). Ofir Arkin has
been using ICMP bit handling to differentiate between certain
types of operating systems. Because ICMP usually slips below the
threshold of analysis, and most of the ICMP messages used are
legitimate, the detection of this scanning can be more difficult
than, say, queso or nmap fingerprinting.
The problems with active scanning are mainly twofold: first, we
can readily firewall the packets used to fingerprint our system,
obfuscating the information; secondly, we can detect it quite
easily. Because of this, it is less attractive for a truly
stealthy adversary.
Passive Scanning
================
In a message dated June 30, 1999, Photon posted to the
nmap-hackers list with some ideas of passive operating system
fingerprinting (this note is available from the MARC archives of
the nmap-hackers list). He set up a webpage with some of his
thoughts, which has since been taken down. In short, by using
default IP packet construction behavior, including default TTL
values, the presence of the DF bit, and the like, one can gain a
confident level of the system's OS.
These ideas were quickly picked up by others and several lines of
research have been active since then. Lance Spitzer's paper dated
May 24 2000:
http://www.enteract.com/~lspitz/pubs.html
on passive fingerprinting included many of the data needed to
build such a tool. In fact, two quickly appeared, one from Craig
Smith and another tool called p0f from Michael Zalewski:
http://www.enteract.com/~lspitz/passfing.tar.gz
http://lcamtuf.hack.pl/p0f.tgz
One very interesting tool that is under active development,
extending the earlier work, is Siphon. By utilizing not only IP
stack behavior, but also routing information and spanning tree
updates, a complete network map can be built over time. Passive
port scans also take place, adding to the data. This tool
promises to be truly useful for the white hat, and a patient black
hat.
One limitation of these methods, though, is that they only provide
a measure of the operating system. Vulnerabilities may or may not
exist, and further investigations must be undertaken to evaluate
if this is the case. While suitable for the white hat for most
purposes (like accounting), this is not suitable to a would-be
attacker. Simply put, more information is needed.
An Alternative Approach
=======================
An alternative method to merely fingerprinting the operating
system is to perform an identification by using client
applications. Quite a number of network clients send revealing
information about their host systems, either directly or
indirectly. We use application level information to map back to
the operating system, either directly or indirectly.
One very large advantage to the method described here is that in
some situations, much more accurate information can be gained
about the client. Because of stack similarities, most Windows
systems, including 95, 98 and NT 4.0, look too similar to
differentiate. The client application, however, is willing to
reveal this information.
This provides not only a measure of the target's likely operating
system, but also a likely vector for entrance. Most of these
client applications have numerous security holes, to which one
can point malicious data. In some cases, this can provide the key
information needed to begin infiltrating a network, and one can
proceed more rapidly. In most cases it provides a starting point
for the analysis of vulnerabilities of a network.
One major limitation of this method, however, comes when a system
is emulating another to provide access to client software. This
includes Solaris and SCO's support for Linux binaries. As such,
under these circumstances, the data should be taken with some
caution and evaluated in the presence of other information. This
limitation, however, is similar to the limitation that IP stack
tweaking can place on passive fingerprinting at the IP level, or
the effect on active scanning from these adjustments or
firewalling.
Four different type of network clients are discussed here which
provide suitable fingerprinting information. Email clients, which
leave telltale information in most cases on their messages;
Usenet clients, which, like mail applications, litter their posts
with client system information; web browsers, which send client
information with each request; and even the ubiquitous telnet
client, which sends such information more quietly, but can just
as effectively fingerprint an operating system.
Knowing this, one now only needs to harvest the network for this
information and map it to source addresses. Various tools,
including sniffers, both generic and specialized, and even web
searches will yield this information. A rapid analysis of systems
can be quickly performed. This works quite well for the white hat
and the black hat hacker, as well.
In this paper is described a low tech approach to fingerprinting
systems for both their operating system and a likely route to
gaining entry. By using application level data sent from them
over the network, we can quickly gather accurate data about a
system. In some cases, one doesn't even have to be on the same
network as the targets, they can gather the information from afar,
compile the information and use it at their discretion at a later
date.
Mail Clients
------------
One of the largest type of traffic the network sees is electronic
mail. Nearly everyone who uses the Internet on a regular basis
uses email in those transaction sessions. They not only receive
mail, but also send a good amount of mail, too. Because it is
ubiquitous, it makes an especially attractive avenue for system
fingerprinting and ultimately penetration.
Within the headers of nearly every mail message is some form of
system identification. Either through the use of crafted message
identification tags, as used by Eudora and Pine, or by explicit
header information, such as headers generated by OutLook clients
or CDE mail clients.
The scope of this method, both in terms of information gained and
the potential impact, should not be underestimated. If anything,
viruses that spread by email, including ones that are used to
steal passwords from systems, should illustrate the effectiveness
of this method.
Pine, for example, itself is one of the worst offenders of any
application for the system it is on. It gives away a whole host
of information useful to an attacker in one fell swoop. To wit:
Message-ID: <Pine.LNX.4.10.9907191137080.14866-100000@somehost.example.ca>
It is clear it's Pine, we know the version (4.10), and we know the
system type. Too much about it, in fact. This is a list of the
main ports of Pine as of 4.30:
a41 IBM RS/6000 running AIX 4.1 or 4.2
a32 IBM RS/6000 running AIX 3.2 or earlier
aix IBM S/370 AIX
aos AOS for IBM RT (untested)
mnt FreeMint
aux Macintosh A/UX
bsd BSD 4.3
bs3 BSDi BSD/386 Version 3 and Version 4
bs2 BSDi BSD/386 Version 2
bsi BSDi BSD/386 Version 1
dpx Bull DPX/2 B.O.S.
cvx Convex
d54 Data General DG/UX 5.4
d41 Data General DG/UX 4.11 or earlier
d-g Data General DG/UX (even earlier)
ult DECstation Ultrix 4.1 or 4.2
gul DECstation Ultrix using gcc compiler
vul VAX Ultrix
os4 Digital Unix v4.0
osf DEC OSF/1 v2.0 and Digital Unix (OSF/1) 3.n
sos DEC OSF/1 v2.0 with SecureWare
epx EP/IX System V
bsf FreeBSD
gen Generic port
hpx Hewlett Packard HP-UX 10.x
hxd Hewlett Packard HP-UX 10.x with DCE security
ghp Hewlett Packard HP-UX 10.x using gcc compiler
hpp Hewlett Packard HP-UX 8.x and 9.x
shp Hewlett Packard HP-UX 8.x and 9.x with Trusted Computer Base
gh9 Hewlett Packard HP-UX 8.x and 9.x using gcc compiler
isc Interactive Systems Unix
lnx Linux using crypt from the C library
lnp Linux using Pluggable Authentication Modules (PAM)
slx Linux using -lcrypt to get the crypt function
sl4 Linux using -lshadow to get the crypt() function
sl5 Linux using shadow passwords, no extra libraries
lyn Lynx Real-Time System (Lynxos)
mct Tenon MachTen (Mac)
osx Macintosh OS X
neb NetBSD
nxt NeXT 68030's and 68040's Mach 2.0
bso OpenBSD with shared-lib
sc5 SCO Open Server 5.x
sco SCO Unix
pt1 Sequent Dynix/ptx v1.4
ptx Sequent Dynix/ptx
dyn Sequent Dynix (not ptx)
sgi Silicon Graphics Irix
sg6 Silicon Graphics Irix >= 6.5
so5 Sun Solaris >= 2.5
gs5 Sun Solaris >= 2.5 using gcc compiler
so4 Sun Solaris <= 2.4
gs4 Sun Solaris <= 2.4 using gcc compiler
sun Sun SunOS 4.1
ssn Sun SunOS 4.1 with shadow password security
gsu SunOS 4.1 using gcc compiler
s40 Sun SunOS 4.0
sv4 System V Release 4
uw2 UnixWare 2.x and 7.x
wnt Windows NT 3.51
Pine system types used in Message-ID tags as of Pine 4.30. This
table was gathered from the supported systems listed in the Pine
source code documentation, in the file pine4.30/doc/pine-ports,
and was edited for brevity.
Hence, with the above message ID, one knows the target's hostname,
an account on that machine that reads mail using Pine, and that
it's Linux without shadowed passwords (the LNX host type). Hang
out on a mailing list, maybe something platform agnostic, and
collect targets. In this case, one could use a well known exploit
within the mail message, grab the system password file and send it
back to ourselves for analysis. This can easily scaled to as many
clients as has been fingerprinted; one mass mailing, and sit back
and wait for the password files to come in.
This is not to say that other mail clients are not vulnerable to
such information leaks. Most mail clients give out similar
information, either directly or indirectly. Direct information
would be an entry in the message headers, such as an X-Mailer tag.
Indirect information would be similar to that seen for Pine, a
distinctive message ID tag. When this information is coupled to
the information about the originating host, a fingerprint can
occur rapidly.
Some examples:
User-Agent: Mutt/1.2.4i
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc
X-Mailer: PMMail 2000 Professional (2.10.2010) For Windows 2000 (5.0.2195)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Message-ID: <4.3.2.7.2.20001117142518.043ad100@mailserver3.somewhere.gov>
While not all clients give out their host system or processors,
such as Mutt or Outlook Express, this information can be used by
itself to get a larger vulnerability assessment. For example, if
we know what version strings appear only on Windows, as opposed
to a MacOS system, we can determine the processor type. The
dtmail application is entirely too friendly to someone determining
vulnerabilities, giving up the processor and OS revision. Given
the problems that have appeared in the CDE suite, and in older
versions of Solaris, an attack would be all too easy to construct.
There are two main avenues for finding this information for lots
of clients quickly. First, we can sniff the network for this
information. Using a tool like mailsnarf, ngrep or any sniffer
with some basic filtering, a modest collection of host to client
application data can be gathered. The speed of collection and the
ultimate size of this database depends chiefly on the amount of
traffic your network segment sees. This is the main drawback to
this method, a limited amount of data.
A much more efficient method, and one that can make use of this
above information, is in offline (for the target with respect to
the potential attacker) system fingerprinting, with an exploit
path included. How do we do this? We search the web, with it's
repleat mailing list archives, and we turn up some boxes.
Altavista: 2,033 pages found (for pine.ult)
Google results 1-10 of about 141,000 for pine.lnx
Altavista: 16,870 pages found (for pine.osf)
You get the idea. Tens of thousands of hits, thousands of
potentially exploitable boxes ready to be picked. Simply evaluate
the source host information and map it to the client data and a
large database of vulnerable hosts is rapidly built.
The exploits are easy. Every week, new exploits are found in
client software, either mail applications like Pine, or methods
to deliver exploits using mail software. Examples of this
include the various buffer overflows that have appeared (and
persist) in Pine and OutLook, the delivery of malicious DLL files
using Eudora attachments, and such. We know from viruses like
ILOVEYOU and Melissa that more people than not will open almost
any mail message, and we know from spammers that it's trivial to
bulk send messages with forged headers, making traceback
difficult. These two items combine to make for a very readily
available exploit.
In a manner similar to electronic mail, Usenet clients leave
significant information in the headers of their posts which
reveal information about their host operating systems. One great
advantage to Usenet, as opposed to email or even web traffic, is
that posts are distributed. As such, we can be remote and collect
data on hosts without their knowledge or ever having to gain entry
into their network.
Among the various newsreaders commonly used, copious host info is
included in the headers. The popular UNIX newsreader 'tin' is
among the worst offenders of revealing host information. Operating
system versions, processors and applications are all listed in the
'User-Agent' field, and when coupled to the NNTP-Posting-Host
information, a remote host fingerprint has been performed:
User-Agent: tin/1.5.2-20000206 ("Black Planet") (UNIX) (SunOS/5.6(sun4u))
User-Agent: tin/pre-1.4-980226 (UNIX) (FreeBSD/2.2.7-RELEASE (i386))
User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.13(i686))
NNTP-Posting-Host: host.university.edu
The standard web browsers also leave copious information about
themselves and their host systems, as they do with HTTP requests
and mail. We will elaborate on web clients in the next section,
but they are also a problem as Usenet clients:
X-Http-User-Agent: Mozilla/4.75 (Windows NT 5.0; U)
X-Mailer: Mozilla 4.75 (X11; U; Linux 2.2.16-3smpi686)
And several other clients also leave verbose information about
their hosts to varying degrees. Again, when combined with the
NNTP-Posting-Host or other identifying header, one can begin to
amass information about hosts without too much work:
Message-ID: <Pine.LNX.4.21.0010261126210.32652-100000@host.example.co.nz>
User-Agent: MT-NewsWatcher/3.0 (PPC)
X-Operating-System: GNU/Linux 2.2.16
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Bryce Canyon)
X-Newsreader: Microsoft Outlook Express 5.50.4133.2400
X-Newsreader: Forte Free Agent 1.21/32.243
X-Newsreader: WinVN 0.99.9 (Released Version) (x86 32bit)
Either directly or indirectly, we can fingerprint the operating
system over the source host. Other programs are not so
forthcoming, but still leak information about a host that can be
used to determine vulnerability analysis.
X-Newsreader: KNode 0.1.13
User-Agent: Pan/0.9.1 (Unix)
User-Agent: Xnews/03.02.04
X-Newsreader: trn 4.0-test74 (May 26, 2000)
X-Newsreader: knews 1.0b.0 (mrsam/980423)
User-Agent: slrn/0.9.5.7 (UNIX)
X-Newsreader: InterChange (Hydra) News v3.61.08
None of these header fields are required by the specifications
for NNTP, as noted in RFC 2980. They provide only some additional
information about the host which was the source of the data.
However, given that more transactions that concern the servers are
between servers, this data is entirely extraneous. It is, it
appears, absent from RFC 977, the original specification for NNTP.
On interesting possibility to exploiting a user agent like Mozilla
is to examine the accepted languages. In the below example, we
see not only English is supported, but that the browser is linked
to Acrobat. Given potential holes, and past problems, with
malicious PDF files, this could be another avenue to gaining entry
to a host.
X-Mailer: Mozilla 4.75 (Win98; U)
X-Accept-Language: en,pdf
While this may seem that we're limited to fingerprinting hosts, or
out of luck if they are using a proxy, this is not the case. We
can also retrieve proxy info from the headers:
X-Http-Proxy: 1.0 x72.deja.com:80 (Squid/1.1.22) for client 10.32.34.18
While in this case the proxy is disconnected from the client's
network, if this were a border proxy, we could use this to gain
information about a possible entry point to the network and, over
time and with enough sample data, information about the network
behind the protected border.
A remarkably simple and highly effective means of fingerprinting
a target is to follow the web browsing that gets done from it.
Most every system in use is a workstation, and nearly everyone
uses their web browsers to spend part of their day. And just
about every browser sends too much information in it's
'User-Agent' field.
RFC 1945 notes that the 'User-Agent' field is not required in an
HTTP 1.0 request, but can be used. The authors state, "user
agents should include this field with requests." They cite
statistics as well as on the fly tailoring of data to meet
features or limitations of browsers. The draft standard for HTTP
version 1.1 requests, RFC 2616, also notes similar usage of the
'User-Agent' field.
We can gather this information in two ways. First, we could run
a website and turn on logging of the User-Agent field from the
client (if it's not already on). Simply generate a lot of hits
and watch the data come in. Get on Slashdot, advertise some
pornographic material, or mirror some popular software (like
warez) and you're ready to go. Secondly, we can sniff web traffic
on our visible segment. While almost any sniffer will work, one
of the easiest for this type of work is urlsnarf from the dsniff
package from Dug Song. This package is available at
http://www.monkey.org/~dugsong/dsniff/
Examples of browsers that send not only their application
information, such as the browser and the version, but also the
operating system which the host runs include:
- Netscape (UNIX, MacOS, and Windows)
- Internet Explorer
One shining example of a browser that doesn't send extraneous
information is Lynx. On both 2.7 and 2.8 versions, only the
browser information is sent, no information about the host.
The User-Agent field can be important to the web server for
legitimate reasons. Due to implementations, both Netscape and
Explorer are not equivalent on many items, including how they
handle tables, scripting and style sheets. However, host
information is not needed and is sent gratuitously.
A typical request from a popular browser looks like this:
GET / HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/4.08 (X11; I; SunOS 5.7 sun4u)
Host: 10.10.32.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8
The User-Agent field is littered with extra information that we
don't need to know: the operating system type, version and even
the hardware being used.
Instantly we know everything there is to know about compromising
this host: the operating system, the host's architecture, and even
a route we could use to gain entry. For example a recent problems
in Netscape's JPEG handling.
Using urlsnarf to log these transactions is the easiest method to
sniff this information from the network. A typical line of output
is below:
10.10.1.232 - - "GET http://www.latino.com/
HTTP/1.0" - - "http://www.latino.com/" "Mozilla/4.07 (Win95; I ;Nav)"
We can also use the tool ngrep to listen to this information
on the wire. A simple filter to listen only to packets that
contain the information 'User-Agent' can be set up and used to
log information about hosts on the network. ngrep can be obtained
from the PacketFactory website:
http://www.packetfactory.net/Projects/Ngrep/
A simple regular expression filter can do the trick:
ngrep -qid ep1 'User-Agent' tcp port 80
This will print out all TCP packets which contain the case
insensitive string User-Agent in them. And, within this field,
for too many browsers, is too much information about the host.
With the above options to ngrep, typical output will look like
this:
T 10.10.11.43:1860 -> 130.14.22.107:80
GET /entrez/query/query.js HTTP/1.1..Accept: */*..Referer: http://www.
ncbi.nlm.nih.gov/entrez/query.fcgi?CMD=search DB=PubMed..Accept-Langua
ge: en-us..Accept-Encoding: gzip, deflate..If-Modified-Since: Thu, 29
Jun 2000 18:38:45 GMT; length=4558..User-Agent: Mozilla/4.0 (compatibl
e; MSIE 5.5; Windows 98)..Host: www.ncbi.nlm.nih.gov..Connection: Keep
-Alive..Cookie: WebEnv=FpEB]AfeA>>Hh^`Ba@<]^d]bCJfdADh@(j)@ =^a=T=EjIE=b<F
bg<....
Even more information is contained within the request than
urlsnarf showed us, information including cookies.
In much the same way as one can use the strings sent during
requests by the clients to determine what system type is in use,
one can follow the replies sent back by the server to determine
what type it is. Again we will use ngrep, this time matching the
expression 'server:' to gather the web server type:
T 192.168.0.5:80 -> 192.168.0.1:1033
HTTP/1.0 200 OK..Server: Netscape-FastTrack/2.01..Date: Mon, 30 Oct 20
00 00:15:31 GMT..Content-type: text/html....
While specifics about the operating system information are lost,
this works to passively gather vulnerability information about
the target server. This can be coupled to other information to
decide how best to proceed with an attack.
This information will not be covered as this paper is limited to
client applications and systems being fingerprinted.
While telnet is no longer in widespread use due to the fact that
all of its data is sent in plain text, including authentication
data, it is still used widely enough to be of use in
fingerprinting target systems. What is interesting is that it not
only gives us a mechanism to gather operating system data, it
gives us the particular application in use, which can be of value
in determining a mechanism of entry.
The specification for the telnet protocol describes a negotiation
between the client and the host for information such as line
speed, terminal type and echoing (for descriptive information on
these options and their negotiations, please see RFCs 857, 858,
859, 860, 1091, 1073, 1079, 1184, 1372, and 1408. Also, see TCP
Illustrated, Volume 1: The Protocols by W. Richard Stevens). What
is interesting to note is that each client behaves in a unique
way, even different client applications on the same host type.
Similarly, the telnet server, running a telnet daemon, can be
fingerprinted by following the negotiations with the client. This
information can be viewed from the telnet command line application
on a UNIX host by issuing the 'toggle options' command at the
telnet> prompt.
This information can be gather directly, using a wedge application
or a honey-pot as demonstrated on the network at Hope2k, or it can
be sniffed off the network in a truly passive fashion. We discuss
below gathering data about both the client system and the server
being connected to. The same principles apply to both host
identification methods.
The negotiations described above, and in the references listed,
can be used to fingerprint the client based upon the options set
and the order in which they are negotiated. Table 1 describes
the behavior of several telnet clients in these respects. Their
differences are immediately obvious, even for different clients
on the same operating system, such as Tera Term Pro and Windows
Telnet on a Windows 95 host.
In this table, all server commands and negotiation options are
ignored and only data originating from the client is shown.
Table is omitted in this version, please see:
http://www.crimelabs.net/docs/passive.html
for pdf or/and .ps
Obviously, the most direct method to fingerprint a server would
be to connect to it and examine the order of options and their
values as a telnet session was negotiated. However, as this
study is concerned with passive scanning of clients, we will
leave it to the reader to map this information and learn what to
do with it.
Solution
In this paper has been illustrated the effectiveness of target
system identification by using the information provided by network
client applications. This provides a very efficient and precise
measure of the client operating system, as well as identifying a
vector for attack. This information is sent gratuitously and is
not essential to the normal operation of many of these
applications.
The main limitation of this information is found when a host is
performing emulation of another operating system to run the
client software. While this is rare, it could lead to a false
system identification. This mainly falls in the open software
world, however, and only for some operating systems.
For web browsers, which are ubiquitous and used by nearly everyone
on the Internet, the host operating system should not be sent.
Ideally, information about what protocols are spoken, what
standards are met and what language are supported (ie English,
German, French) should suffice. Lynx behaves nearly ideally in
this regard, and both Netscape and Explorer should follow this
lead.
With respect to Usenet and electronic mail clients, again only
what features are supported should be provided. Pine is an
example of how bad it can get, providing too much information
about a host too quickly. There is no reason why any legitimate
client should know what processor and OS is being run on the
sending host.
Telnet clients are far more difficult. It is tempting to say that
all telnet applications should support the same set of features,
but that is simply impossible.
Proxy hosts should be used, if possible, to strip off information
about the originating system, including the workstation address
and operating system information. This will help obscure needed
information to map a network from outside the perimeter. Coupled
with strong measures to catch viruses and malicious code, such as
in a web page script, the risks should be greatly reduced.
The best solution is for application authors to not send
gratuitous information in their headers or requests. Furthermore,
client applications should be scrutinized to the same degree as
daemons that run with administrative privilidges. The lessons of
RFC 1123 most certainly apply at this level.
First: The admin/user must not be able to alter/remove the ident
strings that are sent out by the application. This is the case
for most of Windows apps and even where it is possible people
usually do not take any measures in this departement. So we can
move on.
Second: The information displayed must actually be correct. This
is when the fun begins. To take a really good example, the Pine
on most Linux systems *always* sends messages with a Message-Id
that contains "LNX" although we think most are using shadow
passwords.
Also, most mail agents are quite good at rewriting headers if we
ask them to, MTAs being another hidden champions of this. If you
ever happen to receive a mail from me with a From: header that
says root, do not even for a second think that it was actually
sent from that account.
Also, you do not seem to adequately account for the fact that many
people are not running mail servers on their systems. So if you
eg see: Outlook Express, than fine, you know that the sender
machine was running this MUA. But it also makes it more than
likely that the email address you found is not actually that on
the sending machine but rather one on a big mail server, which may
be running anything. You have no knowledge of how mail collection
at that site works, so you cannot be sure that your exploit will
actually work. (eg person can make an email enquiry with their
browsers email client after clicking on a link but use someting
else for "normal" mail and may not even be aware of the difference
and yes, we have seen a setup like this.)
Also, emulation is (or rather can be) a quite big issue with
lesser known OSs for which not enough native applications exist.
Eg there is no Netscape binary of the current release available
for any BSD operating system. (With BSDi support having been
dropped after 4.75) so if you want to use Netscape on any BSD,
you have to use emulation. But if you go after the presumably
old, 2.0.x kernel based Linux system it reports itself as, you
will be in for a surprise). But the real kicker is using Wine
(Windows emulation package for UNIX) and a windows-based
web-browser... (yes ppl have done things like this. Sometimes
you are forced to, eg if there is not even a Linux port of the sw
you need to run).
For proxies: It is known that there exist proxies that hide your
real IP address and cannot be detected any easy way (because they
do not insert an X-Forwarded-IP field). The proxy may or may not
be local, so you do not necessarily have the entrance to the
network either.
Also, web search engines can be helpful for finding
vulnerabilities in servers but to compile lists of target hosts
from mailing list archives is fragile... there may not be many
live hits from those. (Even for server fingerprinting, some
surpriese are in the game: eg Walmart was suspected of forging
their server signature because at least on one occassion they
reported themselves as Microsoft-IIS/4.0 (Unix) mod_ssl/2.6.6
OpenSSL/0.9.5.. outright funny. So the point is: although the
information may be there, it may already be forged intentionally
or otherwise incorrect.
Also, the fact that you found eg Mutt does not tell a lot to you
unless you have a specific exploit... because many of these
programs run on many UNIX/UNIX-like systems plus on DOS/Windows.
So you do not know a lot.
And finally: with all this information you have to go out and do
some actual scanning to verify/gather more information and this is
where you can already get caught.
But, yes, even with the above points made, considering the average
Windows/Mac user and admin, information leakage can be a cause
for many an interesting occurance... why, at this rate we got the
idea for a paper titled: "utilizing information gleaned from
Internet-accessible support pages of various big organizations
and institutions in network incidents..." It is at least as
interesting a topic as this one.
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
