1
00:00:07,240 --> 00:00:09,530
Sorry about the slight delay.

2
00:00:12,370 --> 00:00:18,150
My name is Ophir Arkin, and during this talk, I will be releasing XProbe 2.0.3.

3
00:00:19,510 --> 00:00:24,720
Prior to that, I will be talking about several aspects of doing active voice fingerprinting.

4
00:00:25,590 --> 00:00:36,090
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.

5
00:00:36,490 --> 00:00:46,190
A bit about myself, I'm the founder of the C-Security Group, also founder of NCITEC, I'm the Chief Technical Officer there.

6
00:00:46,930 --> 00:00:57,810
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.

7
00:00:58,850 --> 00:01:00,770
So, what is OS detection?

8
00:01:00,770 --> 00:01:10,930
OS detection is basically the process of trying to determine what is the underlying operating system of a certain remote element.

9
00:01:11,370 --> 00:01:26,070
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.

10
00:01:26,070 --> 00:01:40,570
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.

11
00:01:41,930 --> 00:01:57,230
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.

12
00:02:00,670 --> 00:02:06,270
There are several tools out there that does active OS fingerprinting.

13
00:02:07,130 --> 00:02:11,270
Nmap, for example, is a good tool doing that, Xpub2 and others.

14
00:02:11,270 --> 00:02:19,410
Basically, these tools vary with the way of operation, usually because of the different tests they are using.

15
00:02:19,410 --> 00:02:29,030
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.

16
00:02:32,030 --> 00:02:36,710
Why is that important for us, to identify the underlying operating system?

17
00:02:36,710 --> 00:02:41,510
Well, I guess that for each and one of us, it's something different.

18
00:02:43,330 --> 00:03:00,890
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.

19
00:03:01,870 --> 00:03:14,690
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.

20
00:03:14,710 --> 00:03:18,110
We can control what parameters that we would like to scan.

21
00:03:18,110 --> 00:03:25,870
We can control the speed that we perform the scan, the initiation of the scan, the time of the initiation.

22
00:03:27,350 --> 00:03:36,570
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.

23
00:03:38,150 --> 00:03:40,610
Several companies use these kind of tools.

24
00:03:40,710 --> 00:03:45,050
They might scan from one single point to a multipoint.

25
00:03:45,050 --> 00:03:49,590
This is where the tool is installed on one element on the network and scans multiple.

26
00:03:49,590 --> 00:04:01,650
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.

27
00:04:02,750 --> 00:04:03,950
That's basically it.

28
00:04:03,950 --> 00:04:05,330
These are all the strengths.

29
00:04:05,330 --> 00:04:06,750
There are a lot of weaknesses.

30
00:04:08,330 --> 00:04:12,190
The weaknesses go into different categories.

31
00:04:13,190 --> 00:04:29,690
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.

32
00:04:30,470 --> 00:04:35,110
So let's start by looking at the scanning conditions and the environment effect.

33
00:04:38,390 --> 00:04:49,030
Basically, when we perform an OS detection or basically any other scan, we do not control the quality of the scan.

34
00:04:49,030 --> 00:04:51,590
We cannot control over anything, basically.

35
00:04:51,930 --> 00:04:57,590
Whatever is between us to the target may determine what we're going to get back.

36
00:04:57,910 --> 00:05:00,490
So probably most of you know this.

37
00:05:00,490 --> 00:05:04,650
If you scan an element on a local network, this is one thing.

38
00:05:04,650 --> 00:05:08,890
If you scan an element that is on the Internet, that is something else.

39
00:05:09,690 --> 00:05:15,690
And basically, those locations of the target systems will determine what you're getting.

40
00:05:15,690 --> 00:05:21,990
It's most likely that when you scan an element that is on your local network, you'll get better results.

41
00:05:21,990 --> 00:05:26,550
When you scan an element that is on the Internet, you'll get, well, sometimes nothing.

42
00:05:26,550 --> 00:05:34,510
And also the path between the scanning element to the target also determines what we will be getting.

43
00:05:34,990 --> 00:05:46,130
The problem currently is that we do not have any kind of intelligence about what do we have between us to the target.

44
00:05:46,130 --> 00:06:01,750
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.

45
00:06:04,410 --> 00:06:19,070
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,

46
00:06:19,070 --> 00:06:20,330
meaning it will be up.

47
00:06:20,330 --> 00:06:33,310
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.

48
00:06:33,310 --> 00:06:53,090
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.

49
00:06:53,210 --> 00:06:56,330
This is also true if you have personal firewall installed on a machine.

50
00:06:56,330 --> 00:06:58,730
That will prevent OS detection from working.

51
00:06:58,990 --> 00:07:02,890
You'll never get any active OS detection working like that.

52
00:07:02,890 --> 00:07:23,110
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.

53
00:07:23,110 --> 00:07:26,490
Well, the initial approach of voice fingerprinting will not work here.

54
00:07:27,010 --> 00:07:31,910
Some of those load balancers will answer themselves through the probe.

55
00:07:31,910 --> 00:07:49,170
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.

56
00:07:51,730 --> 00:08:02,710
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.

57
00:08:04,950 --> 00:08:13,070
Sometimes, when we send packets to the target, there is something along the way, like a scrubber, a firewall.

58
00:08:13,290 --> 00:08:23,910
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.

59
00:08:23,910 --> 00:08:31,650
And those kind of alterations will prevent us from determining what is the underlying OS there.

60
00:08:32,910 --> 00:08:50,250
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.

61
00:08:50,250 --> 00:08:58,530
So some examples would include some weird TCP-IP flag combinations, like SYNFIN, SYNRESET.

62
00:08:58,530 --> 00:09:03,630
Those will never go through an IPS and will never be able to reach the target.

63
00:09:04,210 --> 00:09:16,890
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.

64
00:09:16,890 --> 00:09:36,490
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.

65
00:09:36,490 --> 00:09:43,130
Especially, we can name printers, we can name print servers, and things like that.

66
00:09:43,930 --> 00:09:53,450
And of course, there are some other smart people out there that want to obscure the way that their operating system works.

67
00:09:53,710 --> 00:10:03,530
So they change the characteristics of the TCP-IP stack behavior by altering some kernel parameters, tunable kernel parameters.

68
00:10:03,530 --> 00:10:14,950
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.

69
00:10:14,950 --> 00:10:18,230
Also, on Linux, it's very easy to perform these kinds of things.

70
00:10:22,020 --> 00:10:26,800
So let's go into some signature-based related issues.

71
00:10:27,980 --> 00:10:33,460
The signature database is the most important piece of any OS detection tool.

72
00:10:33,460 --> 00:10:54,480
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.

73
00:10:54,680 --> 00:10:59,640
Still, the results that the tool will be performing will be poor.

74
00:11:00,440 --> 00:11:13,720
This is a traditional argue between those who strictly control their signature database to those who allow people to submit signatures for their tool.

75
00:11:14,200 --> 00:11:19,380
My approach is that if I want to insert a signature, I want it to work.

76
00:11:19,380 --> 00:11:26,910
In most cases, I won't insert a signature that someone sent me off a firewall device because there is no use of it.

77
00:11:29,510 --> 00:11:31,030
That's music.

78
00:11:32,170 --> 00:11:36,330
So basically, my approach takes it to the extreme.

79
00:11:36,330 --> 00:11:40,250
Basically, I need to go and I need to see the device.

80
00:11:40,250 --> 00:11:42,550
I need to verify the OS.

81
00:11:42,550 --> 00:11:48,070
I need to verify, in some cases, what it is actually running.

82
00:11:48,890 --> 00:11:52,470
The lab environment is the best way to do this.

83
00:11:52,470 --> 00:12:00,290
And therefore, when you enter the signature in question to the signature database, it will work in most of the cases.

84
00:12:01,410 --> 00:12:16,050
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.

85
00:12:16,050 --> 00:12:24,470
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.

86
00:12:25,250 --> 00:12:32,890
So we can strictly control the process of inserting signatures into the database.

87
00:12:32,990 --> 00:12:35,510
Sure, it has its downside.

88
00:12:35,890 --> 00:12:37,430
It's a slower process.

89
00:12:37,470 --> 00:12:45,870
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.

90
00:12:45,990 --> 00:12:49,610
And the one plus of it is that it is extremely accurate.

91
00:12:49,610 --> 00:12:56,490
On the other hand, if we do not control the signature database, then signatures are inserted because they are there.

92
00:12:56,970 --> 00:13:00,330
The creation process is not controlled.

93
00:13:01,090 --> 00:13:09,550
If those signatures are created in a wrongfully manner, then we have a corrupted database and not a controlled one, which is extremely inaccurate.

94
00:13:12,370 --> 00:13:20,430
When we do OS fingerprinting, we fingerprint the way that the software reacts to the probes that we send.

95
00:13:20,430 --> 00:13:27,170
When we fingerprint a hardware-based device, basically we fingerprint the way the firmware actually answers us.

96
00:13:27,170 --> 00:13:45,190
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.

97
00:13:45,190 --> 00:13:54,630
Usually it depends either on their role, or the manufacturer decides that he wants one firmware or two.

98
00:13:54,830 --> 00:13:57,390
So there are a few examples with that.

99
00:13:58,930 --> 00:14:13,190
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.

100
00:14:13,190 --> 00:14:13,430
Why ?

101
00:14:13,430 --> 00:14:22,210
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.

102
00:14:22,510 --> 00:14:24,610
There are other nice examples.

103
00:14:24,890 --> 00:14:43,610
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.

104
00:14:44,710 --> 00:14:53,590
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...

105
00:14:54,190 --> 00:15:11,950
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,

106
00:15:11,950 --> 00:15:13,110
not the model.

107
00:15:17,730 --> 00:15:29,790
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.

108
00:15:30,850 --> 00:15:41,590
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.

109
00:15:42,410 --> 00:15:47,850
If we do not control what is inside the database, then we are unable to update that.

110
00:15:48,010 --> 00:15:57,850
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.

111
00:15:58,270 --> 00:16:02,750
And, of course, there is one other small issue, which is a political issue.

112
00:16:03,470 --> 00:16:19,470
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.

113
00:16:20,030 --> 00:16:33,430
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.

114
00:16:34,850 --> 00:16:57,350
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,

115
00:16:57,350 --> 00:17:00,810
enjoy what they have done, and basically don't pay them anything.

116
00:17:03,430 --> 00:17:10,710
There are some issues that relate to the way the OS fingerprinting tool actually works.

117
00:17:12,790 --> 00:17:17,170
Scanning results needs to be matched with the signature database.

118
00:17:17,750 --> 00:17:19,830
There are actually two ways of doing that.

119
00:17:19,830 --> 00:17:21,950
Actually, there can be more.

120
00:17:21,950 --> 00:17:38,030
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,

121
00:17:38,030 --> 00:17:42,030
even if some of those tests had failed.

122
00:17:42,590 --> 00:17:45,090
So these are the two approaches that we have.

123
00:17:47,910 --> 00:18:00,370
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.

124
00:18:00,370 --> 00:18:06,830
So theoretically, somewhere along the line, the number of possible matches should be reached.

125
00:18:06,830 --> 00:18:27,250
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.

126
00:18:27,250 --> 00:18:50,190
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.

127
00:18:53,690 --> 00:19:04,930
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.

128
00:19:06,310 --> 00:19:25,830
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.

129
00:19:28,890 --> 00:19:32,010
I've touched this slightly beforehand.

130
00:19:32,290 --> 00:19:41,390
This is the problem of having slight differences between the TCPIP Stacks of newly released operating systems to an older one.

131
00:19:42,350 --> 00:19:49,430
XPSP2, for example, and Windows 2003 share the same characteristics of the stack.

132
00:19:49,430 --> 00:19:56,570
So does Windows 2000 and XP with no OSP and SP1.

133
00:19:56,810 --> 00:20:00,890
And so does some Linux kernels share the same characteristics.

134
00:20:01,290 --> 00:20:05,930
This actually brings us to the point that we cannot have granular results.

135
00:20:05,930 --> 00:20:16,450
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.

136
00:20:19,430 --> 00:20:34,070
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.

137
00:20:34,970 --> 00:20:46,990
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.

138
00:20:58,310 --> 00:21:04,370
When we're using a tool, we would like to have the maximum flexibility with the tool.

139
00:21:04,470 --> 00:21:07,670
We would like to have the ability to control what models it is using.

140
00:21:07,670 --> 00:21:16,710
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.

141
00:21:16,750 --> 00:21:33,350
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.

142
00:21:37,370 --> 00:21:50,650
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.

143
00:21:50,730 --> 00:22:01,230
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.

144
00:22:01,430 --> 00:22:06,490
And that will cause the element to crash or use extra packets.

145
00:22:08,070 --> 00:22:12,050
I have a Kyocera Amida FS-1900 printer in my office.

146
00:22:12,190 --> 00:22:18,490
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.

147
00:22:22,550 --> 00:22:33,550
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.

148
00:22:34,470 --> 00:22:42,710
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.

149
00:22:44,950 --> 00:23:03,250
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.

150
00:23:08,640 --> 00:23:24,460
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.

151
00:23:24,460 --> 00:23:38,200
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.

152
00:23:38,660 --> 00:24:02,020
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.

153
00:24:02,140 --> 00:24:10,720
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.

154
00:24:10,720 --> 00:24:31,720
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.

155
00:24:32,600 --> 00:24:53,620
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.

156
00:24:54,280 --> 00:24:55,840
Something along the lines of...

157
00:24:55,840 --> 00:24:58,800
you can't see this because it's all screwed...

158
00:24:59,620 --> 00:25:24,380
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.

159
00:25:25,340 --> 00:25:27,240
Questions until this point?

160
00:25:28,660 --> 00:25:30,080
No questions.

161
00:25:30,140 --> 00:25:30,980
Okay.

162
00:25:30,980 --> 00:25:39,680
So, for the past four years, I've been one of the developers of Xprog2, which is an active OS fingerprinting tool.

163
00:25:40,020 --> 00:25:45,780
Open source, remote active OS fingerprinting tool that you can use... I mean, if you like it, you use it.

164
00:25:45,780 --> 00:25:47,080
If you don't, you don't.

165
00:25:48,980 --> 00:25:54,380
The project represents our take, our beliefs, and basically it's our fund to create it.

166
00:25:54,380 --> 00:25:55,340
If you use it, great.

167
00:25:55,340 --> 00:25:57,920
If not, again, it's your choice.

168
00:25:59,000 --> 00:26:03,240
It was voted one of the top 75 network security tools.

169
00:26:03,240 --> 00:26:06,920
It replaced Nmap as the OS detection engine for Nessus after...

170
00:26:07,940 --> 00:26:16,100
if you're familiar with Nessus, Nessus uses SMB, NTP, and then it will use the OS fingerprinting test that I found with Xprog2.

171
00:26:17,480 --> 00:26:18,440
Yeah.

172
00:26:23,500 --> 00:26:24,740
Unfortunately, yes.

173
00:26:24,740 --> 00:26:29,280
If you are the application layer, they will play with some of those parameters as well.

174
00:26:32,660 --> 00:26:36,940
Xprog2 basically uses less packets than any other OS fingerprinting tool.

175
00:26:36,940 --> 00:26:38,420
Well, we at least try to.

176
00:26:39,020 --> 00:26:41,800
It does not disturb the operation of the target system.

177
00:26:42,300 --> 00:26:44,600
You can control whatever models you would like to use.

178
00:26:44,600 --> 00:26:53,340
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.

179
00:26:54,340 --> 00:26:55,540
I'll skip this slide.

180
00:26:55,540 --> 00:26:58,320
Basically, what we did along the four years.

181
00:27:00,220 --> 00:27:02,960
The different software models that we have there.

182
00:27:03,080 --> 00:27:11,760
Basically, we have some discovery models, some information gathering models, and some OS detection models, of course.

183
00:27:14,380 --> 00:27:21,520
The tool has a very extensive command line options, which I will not go into, because you didn't come for this now.

184
00:27:21,520 --> 00:27:27,640
The tool is able to detect if there are obstacles between the tool and the target system.

185
00:27:27,640 --> 00:27:32,160
So, for example, if you have a proxy between you and the target system, it is able to detect that.

186
00:27:33,220 --> 00:27:35,740
And other gizmos that I will go through.

187
00:27:36,540 --> 00:27:41,060
So, very fast, discovery models basically are designed to perform host detection.

188
00:27:41,700 --> 00:27:56,280
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.

189
00:27:56,280 --> 00:28:02,300
This is important because when you are scanning something, you don't want to timeout too fast on that one.

190
00:28:03,000 --> 00:28:05,640
There is also a port scanner with the tool.

191
00:28:06,080 --> 00:28:13,660
You can specify ports to be scanned, either capital T or capital U for UDP and TCP, respectively.

192
00:28:13,760 --> 00:28:15,960
There are some examples for that.

193
00:28:15,960 --> 00:28:21,900
So you get a list with any other tool of the open ports, closed ports and filtered ports.

194
00:28:23,320 --> 00:28:38,600
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.

195
00:28:40,180 --> 00:28:45,500
Before this version, we introduced another OS fingerprinting model called ResetAct.

196
00:28:45,500 --> 00:28:52,220
Basically what we do there is we send two scenes to a closed port and we compare them.

197
00:28:52,220 --> 00:29:03,340
That test actually allowed us to differentiate between the different groups of the Linux kernels and we can actually divide them into seven groups.

198
00:29:03,780 --> 00:29:18,560
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.

199
00:29:19,260 --> 00:29:36,720
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.

200
00:29:36,720 --> 00:29:48,740
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".

201
00:29:48,740 --> 00:29:52,000
Okay, that you can do yourself at home, you can play with it.

202
00:29:54,180 --> 00:30:06,920
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.

203
00:30:06,920 --> 00:30:20,480
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.

204
00:30:20,480 --> 00:30:24,680
We also have new signatures and we also have several bug fixes.

205
00:30:25,180 --> 00:30:32,720
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.

206
00:30:32,980 --> 00:30:40,800
It's an SMB-based model, basically very good against Microsoft Windows-based machines that have their file and print sharing working.

207
00:30:41,380 --> 00:30:51,260
It basically retrieves the native OS and native Lundman parameters from the SMB session setup and NX replies.

208
00:30:51,700 --> 00:31:02,320
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.

209
00:31:02,320 --> 00:31:07,240
And basically it allows us granularity when it comes to Windows operating systems.

210
00:31:07,240 --> 00:31:16,000
So we have different you have new keywords that you specify the information there called SMB underscore Lundman and SMB underscore native OS.

211
00:31:16,000 --> 00:31:18,480
You put the information there it all works.

212
00:31:18,760 --> 00:31:27,760
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.

213
00:31:27,760 --> 00:31:31,620
XP with 2000 and we can't see really the differentiation.

214
00:31:33,100 --> 00:31:39,500
This model works automatically when you tell the model to use port 139 when you port scan port 139.

215
00:31:39,500 --> 00:31:43,620
So you specify the minus T 139 with the command line.

216
00:31:43,960 --> 00:31:51,660
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.

217
00:31:52,280 --> 00:31:57,340
Another model that we have inserted is SNMP based model.

218
00:31:57,540 --> 00:32:17,440
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.

219
00:32:17,440 --> 00:32:17,440
based model .

220
00:32:17,440 --> 00:32:22,960
Currently only SNMP v2 is being supported but the next version will have v1 and v3 as well .

221
00:32:23,760 --> 00:32:27,440
And it needs to have UDP port 161 open in order to operate.

222
00:32:27,580 --> 00:32:32,180
So this is an example with FreeBSD 5.3.

223
00:32:32,180 --> 00:32:40,560
You can see if you can look at it actually, that the SNMP community stream was public.

224
00:32:40,560 --> 00:32:50,360
There you can look at the export2.conf and specify there and what the information was extracted from the FreeBSD 5.3 based machine.

225
00:32:50,360 --> 00:33:00,720
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.

226
00:33:01,440 --> 00:33:07,540
We have also new signatures for the different Apple Mac OS X.

227
00:33:07,540 --> 00:33:10,500
We have missed those signatures for quite a long time.

228
00:33:10,660 --> 00:33:17,060
We have updated the signatures for Linux, FreeBSD and OpenBSD and we also have fixed several bug fixes that we have with the tool.

229
00:33:20,120 --> 00:33:31,280
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.

230
00:33:31,800 --> 00:33:32,820
Questions?

231
00:33:33,300 --> 00:33:34,040
Yes.

232
00:33:34,820 --> 00:33:35,080
If

233
00:33:38,460 --> 00:33:43,760
you use SMB and SNMP and you do port scan, you are not stealth.

234
00:33:45,520 --> 00:33:51,720
Any IDS, IPS or anything that will look for these kind of parameters will pick you up easily.

235
00:33:52,900 --> 00:33:54,500
That's the problem as well.

236
00:33:54,860 --> 00:34:01,720
If you are not having the information prior, then you cannot really be stealth.

237
00:34:03,040 --> 00:34:04,080
Yes.

238
00:34:11,110 --> 00:34:20,130
Any test actually has its own weight inside the BigPi of OS fingerprinting tests.

239
00:34:20,130 --> 00:34:22,450
Each parameter has its own weight as well.

240
00:34:22,450 --> 00:34:36,530
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%.

241
00:34:36,530 --> 00:34:46,470
One other thing that I want to mention, this is a project that my fellow co-authors are doing.

242
00:34:46,470 --> 00:34:47,570
It's called STIF.

243
00:34:47,570 --> 00:34:51,630
It stands for Security Tools Integration Framework.

244
00:34:51,630 --> 00:34:56,950
It basically is a platform to automate security analysis.

245
00:34:56,950 --> 00:35:05,270
You can check that project with the URL that is being shown at the bottom.

246
00:35:05,270 --> 00:35:06,330
It's a very cool project.

247
00:35:06,330 --> 00:35:07,370
Very cool guys.

248
00:35:07,370 --> 00:35:09,410
You should check their project as well.

249
00:35:10,170 --> 00:35:11,250
Other questions?

250
00:35:13,150 --> 00:35:15,090
Thank you for having me today.

251
00:35:15,610 --> 00:35:17,070
Enjoy the conference.