Sorry about the slight delay.
My name is Ophir Arkin, and during this talk, I will be releasing XProbe 2.0.3.
Prior to that, I will be talking about several aspects of doing active voice fingerprinting.
Basically, we're going to discuss the problems that are usually associated with active voice fingerprinting,
and we'll see how we can remedy that.
A bit about myself, I'm the founder of the C-Security Group, also founder of NCITEC,
I'm the Chief Technical Officer there.
I've done some research about infrastructure discovery, voice over IP security, and OS detection,
and I'm also a member of the Voice Over IP Security Alliance.
So, what is OS detection?
OS detection is basically the process of trying to determine what is the underlying operating system of a certain remote element.
Traditional approach will send some packets, will examine the stack behavior,
usually with IP, UDP, TCP, and ICP, in order to draw some conclusions about that underlying OS.
Usually, when results are received from a target element, those results will be compared to a certain signature database,
a certain tool will have, in an effort to find a match.
Just because the traditional approach is to use TCP IP stack-based fingerprinting, usually limited to those protocols I've mentioned,
doesn't mean that we cannot use the application layer also to provide us with information about the OS.
There are several tools out there that does active OS fingerprinting.
Nmap, for example, is a good tool doing that, Xpub2 and others.
Basically, these tools vary with the way of operation, usually because of the different tests they are using.
Basically, the packets they are sending to the target host, trying to enumerate the operating system,
the number of packets they are sending, and the way of operation.
Why is that important for us, to identify the underlying operating system?
Well, I guess that for each and one of us, it's something different.
Some need that to do vulnerability assessment, some like to have some context about their network,
and there are some companies who use OS detection as a means to have some context for their network intrusion detection systems and network intrusion prevention systems.
If we go and look at the strength of doing remote active OS fingerprinting,
then one of the things that is the most important is that we can control everything.
We can control what parameters that we would like to scan.
We can control the speed that we perform the scan, the initiation of the scan, the time of the initiation.
Usually such a tool will provide with fast results if there are no obstacles on the way,
and then of course it can also cover entire IP ranges.
Several companies use these kind of tools.
They might scan from one single point to a multipoint.
This is where the tool is installed on one element on the network and scans multiple.
And there are some other implementations where a scanning tool will be installed on different parts of the network and will scan from there other parts of the network.
That's basically it. These are all the strengths.
There are a lot of weaknesses.
The weaknesses go into different categories.
The biggest problem is the scanning conditions and the environment effects on the scan,
the way that the OS detection tool operates, the signature database is not a major caveat,
and also some other tool-related issues.
So let's start by looking at the scanning conditions and the environment effect.
Basically, when we perform an OS detection or basically any other scan,
we do not control the quality of the scan.
We cannot control over anything, basically.
Whatever is between us to the target may determine what we're going to get back.
So probably most of you know this.
If you scan an element on a local network, this is one thing.
If you scan an element that is on the Internet, that is something else.
And basically, those locations of the target systems will determine what you're getting.
It's most likely that when you scan an element that is on your local network, you'll get better results.
When you scan an element that is on the Internet, you'll get, well, sometimes nothing.
And also the path between the scanning element to the target also determines what we will be getting.
The problem currently is that we do not have any kind of intelligence about what do we have between us to the target.
There is currently no tool that is going to tell us,
or something else that prevents us or changed the way either our packet or the returning packet had arrived to us.
In order to have good results with any OS fingerprinting tool, you have to have the target machine willing to talk to you,
meaning that your packets will arrive to the target machine,
and also that the target machine will be operational on the network, meaning it will be up.
And of course, if you don't have elements such as network-based firewalls, host-based firewalls,
not-enabled devices, load balancers, and other things between you to the target.
So, just a quick example, if the scanning machine scans a local network,
there is a firewall between the scanning machine to one of the networks,
and it prevents the sending packets through to targets that part of the network will not be identified,
and those hosts will not be listed by the tool.
This is also true if you have personal firewall installed on a machine.
That will prevent OS detection from working.
You'll never get any active OS detection working like that.
Another example is that if some of you, not hinting, sits at home and wants to scan www.companythatyoulike.com,
and that company that you like.com has load balancers in front of its web servers.
Well, the initial approach of voice fingerprinting will not work here.
Some of those load balancers will answer themselves through the probe.
Some of them will change some of the parameters that will go back to the scanner,
and some of them even, if there is no one OS that operates on the web servers behind the load balancers,
then you might get funny results back.
So basically, the result will be that if the packets that you need in order to draw conclusions about the OS is being dropped,
then you'll not get anything.
Sometimes, when we send packets to the target, there is something along the way, like a scrubber, a firewall.
I don't know how many of you are familiar with checkpoint firewall,
but that firewall can scrub several fields inside a packet that comes back.
And those kind of alterations will prevent us from determining what is the underlying OS there.
Sometimes, if a tool uses malformed packets, those packets will also be dropped by an intrusion prevention system
or other system that checks for the legitimacy of the packet.
So some examples would include some weird TCP-IP flag combinations, like SYNFIN, SYNRESET.
Those will never go through an IPS and will never be able to reach the target.
So of course, if the tool that you are using is using crafted packets and is sending crafted packets throughout the Internet,
then that tool will not be able to provide good results.
The other problem that we have there is that sometimes those malformed packets may have another hidden effect
that might cause some TCP-IP stacks to crash, especially when those stacks don't need to do too many things.
Especially, we can name printers, we can name print servers, and things like that.
And of course, there are some other smart people out there that want to obscure the way that their operating system works.
So they change the characteristics of the TCP-IP stack behavior by altering some kernel parameters, tunable kernel parameters.
So if you are familiar with several commands, for example, the CCTL command and the NDD command on Sun,
then you are able to tune the parameters. Also, on Linux, it's very easy to perform these kinds of things.
So let's go into some signature-based related issues.
The signature database is the most important piece of any OS detection tool.
If the signature database will be corrupted, if the signatures will not be inserted to the signature database in a correct manner,
then at the end of the day, you'll have a corrupted signature database, and it will not help the tool,
even if the tool is using the most admirable test out there.
Still, the results that the tool will be performing will be poor.
This is a traditional argue between those who strictly control their signature database
to those who allow people to submit signatures for their tool.
My approach is that if I want to insert a signature, I want it to work.
In most cases, I won't insert a signature that someone sent me off a firewall device because there is no use of it.
That's music.
So basically, my approach takes it to the extreme.
Basically, I need to go and I need to see the device. I need to verify the OS.
I need to verify, in some cases, what it is actually running.
The lab environment is the best way to do this.
And therefore, when you enter the signature in question to the signature database, it will work in most of the cases.
Some of the other tools that are out there simply would say,
okay, there is a webpage here, let's submit some signatures,
and then you don't know what was the actual test there and that this signature was produced at.
And you try to run a certain test, and at the end of the day,
what you get is a mixed result that never comes close to the reality.
So we can strictly control the process of inserting signatures into the database.
Sure, it has its downside. It's a slower process.
It has a limit on the number of signatures and devices that you can insert into the database
because we can't buy them all or we can't access them all.
And the one plus of it is that it is extremely accurate.
On the other hand, if we do not control the signature database,
then signatures are inserted because they are there.
The creation process is not controlled.
If those signatures are created in a wrongfully manner,
then we have a corrupted database and not a controlled one,
which is extremely inaccurate.
When we do OS fingerprinting, we fingerprint the way that the software reacts
to the probes that we send.
When we fingerprint a hardware-based device,
basically we fingerprint the way the firmware actually answers us.
And this is a common mistake when we go and we try to do this thing
because if you are familiar with hardware-based devices,
then most of them will, for the same manufacturers,
most of them will run either the same firmware or a slightly different firmware.
Usually it depends either on their role,
or the manufacturer decides that he wants one firmware or two.
So there are a few examples with that.
Cisco 7200 will be fingerprinting as 2950, as the Switch 2950,
as a 6500 running iOS, and even as the Aeronet's wireless access points.
Why? Because they are all running iOS,
and with traditional TCP-IP-based stack fingerprinting,
we're not able to tell the difference of their roles.
There are other nice examples.
Foundry Networks usually run the same OS,
sorry, the same firmware on all of their systems,
and also the printers, if you're familiar with HP printers,
those will also run the same firmware or a slightly different firmware,
depending on the year and the updates.
But, unfortunately, some OS fingerprinting tools
don't take this into account,
and at the end of the day, it also brings them to the...
for having a corrupted database,
when you do a fingerprinting of HP,
what you get is not that this is an HP printer,
you get that it might be a home printer,
a corporate printer, or whatever else printer and other things,
but at the end of the day, that's the firmware, not the model.
When we want to expand and use other fingerprinting tests,
and we want to expand what we have,
then we need to go through the entire signature database
and we need to update it.
If we need to do so, as part of the signatures
or part of the tool evolution,
then we need to go through the entire signatures
and update them with new tests.
If we do not control what is inside the database,
then we are unable to update that.
So, we might have new tests that we want to have,
we might have new things that we want to introduce,
but at the end of the day, we can't do that,
because we don't have control of that.
And, of course, there is one other small issue,
which is a political issue.
The political issue is that many open source tools
basically are abused,
because many commercial companies do not read the license
and they take the signature database
and they claim it as their own.
There are some examples for that,
but at the end of the day,
when you contribute something to the open source community
and you hope that it is actually being used,
then you don't want your work to be stolen as well.
This is actually causing some guys that manufacture,
that actually develop open source tools,
not to insert the entire knowledge into those tools,
or sometimes not to insert their entire signature database
into those tools, because they know
that people will just go download the signature database,
enjoy what they have done,
and basically don't pay them anything.
There are some issues that relate to the way
the OS fingerprinting tool actually works.
Scanning results needs to be matched
with the signature database.
There are actually two ways of doing that.
Actually, there can be more.
Either you do strict signature matching,
where you search for a 100% match
between what you've got to the signature database,
or that you use statistical analysis approach,
which basically says we'll find the best match for you,
and we will present you with the best match,
even if some of those tests had failed.
So these are the two approaches that we have.
Another problem is that Stacks looks alike
with new released operating systems,
and there are only n number of tests,
or n number of parameters that we can look for.
So theoretically, somewhere along the line,
the number of possible matches should be reached.
Although this number is still currently high,
there are classes of different operating systems
that even when we use several new OS fingerprinting tests
or old OS fingerprinting tests,
we're still unable to distinguish between their Stacks
because the tests that we're using are insufficient to do so.
So what we need to have is the ability of a tool
to have fingerprinting tests that have multiple parameters inside of them,
that they represent different OSs,
that many parameters are different among the TCPIP Stack,
and that allows us to receive better overall results.
Another problem that we have is that
when some tests are regarded better than others,
it means that if they would fail,
then the quality of results that we will have will be lowered.
For example, if we would not receive SYNAC response
for a SYN request to an open port,
or we'll not get this kind of response at all,
or we'll not receive port enrichable for UDP packet,
then basically the way that we'll have results
will not have too much.
I've touched this slightly beforehand.
This is the problem of having slight differences
between the TCPIP Stacks of newly released operating systems
to an older one.
XPSP2, for example, and Windows 2003
share the same characteristics of the stack.
So does Windows 2000 and XP with no OSP and SP1.
And so does some Linux kernels share the same characteristics.
This actually brings us to the point
that we cannot have granular results.
What we have is just grouped results
that at the end of the day might say,
okay, this is a Windows system,
but actually it will not list the underlying OS.
Another problem that we have is that the type of information
that we are able to extract using traditional TCPIP Stack
fingerprinting is limited,
and one of the examples can be shown
with the different Windows operating system service packs.
Traditional TCPIP-based tools
are not able to tell the service pack in most of the cases,
and this is a problem if you want to use the information
for other tools like vulnerability assessment.
When we're using a tool,
we would like to have the maximum flexibility with the tool.
We would like to have the ability to control what models it is using.
So if we know that we operate against a web server,
we're not going to use tests that we assume
that will be dropped or not be answered.
So an active OS fingerprinting tool needs to have
all of its models controlled
and has to allow the user to specify exactly
which models you want to use
and what types of packets you want to send
to the host.
Another problem,
and this is the last of the row,
is that sometimes active OS fingerprinting tools
will pose an out-of-service condition
to those elements they're scanning.
The problem is that sometimes those will use
non-RFC compliant packets
or the pace of the scan will be too fast
for the element to handle.
And that will cause the element to crash
or use extra packets.
I have a Kyocera Amida FS-1900 printer in my office.
If I scan it with nmap,
the printer crashes to the point that I have to go
and I have to power off the printer and power it on.
So,
the summary for this is that
we need to understand the Terran,
we need to understand what we're scanning,
we need to understand what's between us to the target.
If we cannot meet the conditions that we need
in order to get good results, then basically
we're not going to get any kind of results.
We need to understand those conditions
in order to build better tools that will allow us
to receive results even if we're operating
against a well-fortified element
sitting behind different
kind of security mechanisms.
There are some other
approaches that came and said, okay, let's decide
or let's see if we can bypass those problems and
basically what they have said is that, okay, let's take one protocol,
we try to analyze that and we'll use only that protocol
in order to draw conclusions about what we see.
So there are some researchers,
if you heard about a tool called TBIT,
basically they look for the current state
of TCP implementation or TCP implementations
on web servers. So they took the tool and said,
okay, this is something that we can use
in order to do OS fingerprinting,
but the problem is that using
multiple tests only against an open
TCP port, it actually doesn't do anything
because you're still at the point
which the Windows operating
system as a group will be identified. And we can actually
perform these kind of tests
only with one packet when we do not need
all of those packets in order to do that.
So if we look at the needed solution,
then we need intelligence in scanning, we need to understand
the terrain that we operate against, and we need
the active OS fingerprinting tool to understand the quality of received
results in order to react to the received
results with proper targeted
OS detection tools.
So at the end of the day, what we're looking for
is we're looking for a tool that will have
the ability not only to perform
stack-based OS fingerprinting, the traditional
approach, but also to have the ability
to have application-based
fingerprinting tests along with the tool.
Something along the lines of...
you can't see this because it's all screwed...
something along the lines of
we send several packets, we analyze what we receive
back, we see which ports are open, what
services, what type of family of operating
system we're operating against, and then
the tool will be able to launch automatically the kind of
application-based fingerprinting
test that needs to be run against those family
of operating systems. Questions
until this point?
No questions. Okay.
So, for the past
four years, I've been one of the developers of
Xprog2, which is an active OS fingerprinting tool.
Open source, remote active OS fingerprinting
tool that you can use... I mean, if you like it, you use it.
If you don't, you don't.
The project represents our take, our beliefs,
and basically it's our fund to create it. If you use it,
great. If not, again, it's your choice.
It was voted one of the top
75 network security tools. It replaced Nmap
as the OS detection engine for Nessus after...
if you're familiar with Nessus, Nessus uses
SMB, NTP, and then it will use
the OS fingerprinting test that I found with Xprog2.
Yeah.
Unfortunately, yes. If you are
the application layer, they will play with some of those
parameters as well.
Xprog2 basically uses
less packets than any other OS fingerprinting tool.
Well, we at least try to. It does not
disturb the operation of the target system.
You can control whatever models you would like to use. And of course,
at the end of the day, if you use it in the lab against
whatever you put there, you'll see that it will give you more accurate results
than any other tool.
I'll skip this slide. Basically, what we did
along the four years.
The different software models that we have there.
Basically, we have some discovery models,
some information gathering models, and some
OS detection models, of course.
The tool has a very extensive command line options,
which I will not go into, because you didn't come for this now.
The tool is able to detect if there are obstacles
between the tool and the target system.
So, for example, if you have a proxy between you and the target system,
it is able to detect that.
And other gizmos that I will go through.
So, very fast, discovery models basically are designed
to perform host detection.
Their aim is not only to see that the host is alive,
but also to aid the automatic
receive timeout mechanism in understanding
what is the timeout that needs to be automatically selected for
the target host. This is important because when you
are scanning something, you don't want to timeout too fast on that one.
There is also a port scanner
with the tool. You can specify
ports to be scanned, either capital T or
capital U for UDP and TCP, respectively.
There are some examples for that.
So you get a list with any other tool
of the open ports, closed ports and filtered ports.
So, if you want perfect
results, you need to have an open TCP
port, a closed TCP port, a closed UDP port
and either receive replies
for echo request, timestamp request
and address request.
Before this version, we introduced another
OS fingerprinting model called ResetAct. Basically
what we do there is we send two
scenes to a closed port and we compare them.
That test actually allowed us to differentiate
between the different groups of the Linux
kernels and we can actually divide them into
seven groups.
This is a very useful tool if you need to
have the understanding if this is a 2.4
based kernel or a 2.6 based kernel and also go
inside those families of kernels and have
some information there.
Some other useful command line options
by default, if you run xprog2 with
"-v and "-b", it automatically will try to enumerate
several ports, so you don't need to
specify a port scan, you just do
lower v, uppercase B and the IP address.
You are also able to automatically generate signatures
using the capital F command line
and you can save the information using the
"-o command line".
Okay, that you can do yourself at home, you can play with it.
The version that
we are releasing today is available
for download, you can either go to my website or
directly go to our page at
sourceforge.org.
Basically what we have
is we have two new application-based
OS fingerprinting models inserted to the tool
in order to help the tool operate better
in different scanning conditions.
We also have new signatures and we also have several bug fixes.
The first app-based
OS fingerprint model that we have entered
and it's not something new, but it's good to have in a tool.
It's an SMB-based model, basically very good
against Microsoft Windows-based machines that have
their file and print sharing working.
It basically retrieves the native OS
and native Lundman parameters
from the SMB session setup and NX replies.
And it helps us differentiate between
different Windows OSes such as
Windows XP in 2003 between several
problems that we have between 2000 and XP.
And basically it allows us granularity when it comes to
Windows operating systems. So we have different
you have new keywords that you specify the information there
called SMB underscore Lundman and SMB underscore
native OS. You put the information there
it all works. This is an example
not using the SMB
model at the end of the day what you see is the results
are all mixed up. XP with 2000 and we
can't see really the differentiation.
This model works automatically when you tell the
model to use port 139 when you port scan
port 139. So you specify the minus T
139 with the command line. It's
automatically executed and at the end of the day the results are
Windows 2000 because this is a Windows 2000 service pack
for a machine. Another model
that we have inserted is SNMP based
model. Mostly it's good when
it is used against
well, those elements that use SNMP but also
when you have certain kind of
an element which is a hardware based and you want to
extract that information in order to help you
detect what's the underlying operating system.
SNMP based model. Currently only SNMP v2 is
being supported but the next version will have v1 and v3
as well. And it needs to have
UDP port 161 open in order to operate.
So this is an example with
FreeBSD 5.3. You can see if you can
look at it actually, that the SNMP
community stream was public.
There you can look at the export2.conf
and specify there and what the information was
extracted from the FreeBSD 5.3
based machine. You can see that this actually contributed
to the fact that we got FreeBSD 5.3
with 100% and the other FreeBSDs
with less percentage than that.
We have also new signatures for
the different Apple Mac OS X.
We have missed those signatures for quite a long time.
We have updated the signatures for Linux, FreeBSD and OpenBSD
and we also have fixed several bug fixes that we have with the tool.
And we would like to take the tool to
a different level by automating the scans,
by understanding the Terran, but
I guess it will take us a bit of time to do that.
Questions? Yes.
If you use SMB and SNMP
and you do port scan, you are not stealth.
Any IDS, IPS or
anything that will look for these kind of parameters
will pick you up easily.
That's the problem as well. If you are not
having the information prior, then
you cannot really be stealth.
Yes.
Any test actually
has its own weight inside
the BigPi of OS fingerprinting
tests. Each parameter has its own weight as well.
So if one of them is not being matched
or there is a problem matching that parameter
with the signature database, that will take
the percentage of hit
to be less than 100%.
One other thing that I want to mention,
this is a project that
my fellow co-authors are doing.
It's called STIF. It stands for
Security Tools Integration Framework.
It basically is a platform to automate
security analysis. You can check
that project
with the URL that is being
shown at the bottom. It's a very cool project.
Very cool guys. You should check their project as well.
Other questions?
Thank you for having me today.
Enjoy the conference.