dradis-saint 3.10.0
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +7 -0
- data/.gitignore +12 -0
- data/CHANGELOG.md +7 -0
- data/CONTRIBUTING.md +3 -0
- data/Gemfile +20 -0
- data/LICENSE +339 -0
- data/README.md +25 -0
- data/Rakefile +1 -0
- data/dradis-saint.gemspec +28 -0
- data/lib/dradis-saint.rb +7 -0
- data/lib/dradis/plugins/saint.rb +11 -0
- data/lib/dradis/plugins/saint/engine.rb +13 -0
- data/lib/dradis/plugins/saint/field_processor.rb +31 -0
- data/lib/dradis/plugins/saint/gem_version.rb +18 -0
- data/lib/dradis/plugins/saint/importer.rb +130 -0
- data/lib/dradis/plugins/saint/version.rb +11 -0
- data/lib/saint/base.rb +29 -0
- data/lib/saint/evidence.rb +18 -0
- data/lib/saint/vulnerability.rb +15 -0
- data/lib/tasks/thorfile.rb +19 -0
- data/spec/dradis/plugins/saint/field_processor_spec.rb +39 -0
- data/spec/dradis/plugins/saint/importer_spec.rb +33 -0
- data/spec/fixtures/files/evidence-01.xml +8 -0
- data/spec/fixtures/files/full_report.xml +45 -0
- data/spec/fixtures/files/host-01.xml +5 -0
- data/spec/fixtures/files/saint_metasploitable_sample.xml +718 -0
- data/spec/fixtures/files/vulnerability-01.xml +17 -0
- data/spec/saint/evidence_spec.rb +8 -0
- data/spec/saint/host_spec.rb +8 -0
- data/spec/saint/vulnerability_spec.rb +8 -0
- data/spec/spec_helper.rb +10 -0
- data/spec/xml_element.rb +10 -0
- data/templates/evidence.fields +5 -0
- data/templates/evidence.sample +8 -0
- data/templates/evidence.template +14 -0
- data/templates/vulnerability.fields +14 -0
- data/templates/vulnerability.sample +35 -0
- data/templates/vulnerability.template +41 -0
- metadata +165 -0
@@ -0,0 +1,718 @@
|
|
1
|
+
<?xml version="1.0" encoding="UTF-8"?>
|
2
|
+
<report>
|
3
|
+
<scan_information>
|
4
|
+
<title>Metasploitable</title>
|
5
|
+
<report_time>Wed Mar 22 13:28:09 2017</report_time>
|
6
|
+
<scan_time>Wed Mar 22 13:22:35 2017</scan_time>
|
7
|
+
<scan_level>heavy vulnerability</scan_level>
|
8
|
+
<scanner_version>8.14.25</scanner_version>
|
9
|
+
</scan_information>
|
10
|
+
<summary>
|
11
|
+
<vulnerabilities_by_severity bar="bar_vulns.png" pie="pie_vulns.png">
|
12
|
+
<reds>2</reds>
|
13
|
+
<yellows>0</yellows>
|
14
|
+
<browns>8</browns>
|
15
|
+
<greens>5</greens>
|
16
|
+
</vulnerabilities_by_severity>
|
17
|
+
<hosts_by_severity bar="bar_hosts.png" pie="pie_hosts.png">
|
18
|
+
<red_hosts>1</red_hosts>
|
19
|
+
<yellow_hosts>0</yellow_hosts>
|
20
|
+
<brown_hosts>0</brown_hosts>
|
21
|
+
<green_hosts>0</green_hosts>
|
22
|
+
<black_hosts>0</black_hosts>
|
23
|
+
</hosts_by_severity>
|
24
|
+
<vulnerabilities_by_class bar="bar_classes.png" pie="pie_classes.png">
|
25
|
+
<web>0</web>
|
26
|
+
<mail>0</mail>
|
27
|
+
<file_transfer>0</file_transfer>
|
28
|
+
<login_shell>0</login_shell>
|
29
|
+
<print_services>0</print_services>
|
30
|
+
<rpc>0</rpc>
|
31
|
+
<dns>0</dns>
|
32
|
+
<databases>0</databases>
|
33
|
+
<networking_snmp>0</networking_snmp>
|
34
|
+
<windows_os>0</windows_os>
|
35
|
+
<passwords>0</passwords>
|
36
|
+
<other>8</other>
|
37
|
+
</vulnerabilities_by_class>
|
38
|
+
<top_vulns bar="bar_topvulns.png">
|
39
|
+
<top_vuln>
|
40
|
+
<rank>1</rank>
|
41
|
+
<vulnerability>server is susceptible to BEAST attack</vulnerability>
|
42
|
+
<no_of_targets>3</no_of_targets>
|
43
|
+
</top_vuln>
|
44
|
+
<top_vuln>
|
45
|
+
<rank>2</rank>
|
46
|
+
<vulnerability>SSL/TLS server supports short block sizes (SWEET32 attack)</vulnerability>
|
47
|
+
<no_of_targets>3</no_of_targets>
|
48
|
+
</top_vuln>
|
49
|
+
<top_vuln>
|
50
|
+
<rank>3</rank>
|
51
|
+
<vulnerability>SSL/TLS server supports RC4 ciphers</vulnerability>
|
52
|
+
<no_of_targets>2</no_of_targets>
|
53
|
+
</top_vuln>
|
54
|
+
</top_vulns>
|
55
|
+
<top_services bar="bar_topservices.png">
|
56
|
+
<top_service>
|
57
|
+
<rank>1</rank>
|
58
|
+
<service>urd (465/TCP)</service>
|
59
|
+
<no_of_targets>1</no_of_targets>
|
60
|
+
</top_service>
|
61
|
+
<top_service>
|
62
|
+
<rank>2</rank>
|
63
|
+
<service>587/TCP</service>
|
64
|
+
<no_of_targets>1</no_of_targets>
|
65
|
+
</top_service>
|
66
|
+
<top_service>
|
67
|
+
<rank>3</rank>
|
68
|
+
<service>SMTP</service>
|
69
|
+
<no_of_targets>1</no_of_targets>
|
70
|
+
</top_service>
|
71
|
+
<top_service>
|
72
|
+
<rank>4</rank>
|
73
|
+
<service>WWW</service>
|
74
|
+
<no_of_targets>1</no_of_targets>
|
75
|
+
</top_service>
|
76
|
+
<top_service>
|
77
|
+
<rank>5</rank>
|
78
|
+
<service>WWW (Secure)</service>
|
79
|
+
<no_of_targets>1</no_of_targets>
|
80
|
+
</top_service>
|
81
|
+
</top_services>
|
82
|
+
</summary>
|
83
|
+
<overview>
|
84
|
+
<hosts>
|
85
|
+
<host>
|
86
|
+
<hostname>192.168.150.163</hostname>
|
87
|
+
<ipaddr>192.168.150.163</ipaddr>
|
88
|
+
<hosttype>Linux 2.6.18 - 2.6.22</hosttype>
|
89
|
+
<reds>2</reds>
|
90
|
+
<yellows>0</yellows>
|
91
|
+
<browns>8</browns>
|
92
|
+
</host>
|
93
|
+
</hosts>
|
94
|
+
<vulnerabilities_summary>
|
95
|
+
<vulnerability>
|
96
|
+
<description>server is susceptible to BEAST attack</description>
|
97
|
+
<no_of_targets>3</no_of_targets>
|
98
|
+
</vulnerability>
|
99
|
+
<vulnerability>
|
100
|
+
<description>SSL/TLS server supports short block sizes (SWEET32 attack)</description>
|
101
|
+
<no_of_targets>3</no_of_targets>
|
102
|
+
</vulnerability>
|
103
|
+
<vulnerability>
|
104
|
+
<description>SSL/TLS server supports RC4 ciphers</description>
|
105
|
+
<no_of_targets>2</no_of_targets>
|
106
|
+
</vulnerability>
|
107
|
+
</vulnerabilities_summary>
|
108
|
+
<vulnerabilities>
|
109
|
+
<host_info>
|
110
|
+
<hostname>192.168.150.163</hostname>
|
111
|
+
<vulnerability>
|
112
|
+
<port>587/tcp</port>
|
113
|
+
<severity>potential</severity>
|
114
|
+
<description>server is susceptible to BEAST attack</description>
|
115
|
+
<class>Other</class>
|
116
|
+
<cve>CVE-2011-3389</cve>
|
117
|
+
<cvss_base_score>4.3</cvss_base_score>
|
118
|
+
</vulnerability>
|
119
|
+
<vulnerability>
|
120
|
+
<port>443/tcp</port>
|
121
|
+
<severity>potential</severity>
|
122
|
+
<description>server is susceptible to BEAST attack</description>
|
123
|
+
<class>Other</class>
|
124
|
+
<cve>CVE-2011-3389</cve>
|
125
|
+
<cvss_base_score>4.3</cvss_base_score>
|
126
|
+
</vulnerability>
|
127
|
+
<vulnerability>
|
128
|
+
<port>25/tcp</port>
|
129
|
+
<severity>potential</severity>
|
130
|
+
<description>server is susceptible to BEAST attack</description>
|
131
|
+
<class>Other</class>
|
132
|
+
<cve>CVE-2011-3389</cve>
|
133
|
+
<cvss_base_score>4.3</cvss_base_score>
|
134
|
+
</vulnerability>
|
135
|
+
<vulnerability>
|
136
|
+
<port>25/tcp</port>
|
137
|
+
<severity>potential</severity>
|
138
|
+
<description>SSL/TLS server supports RC4 ciphers</description>
|
139
|
+
<class>Other</class>
|
140
|
+
<cve>CVE-2013-2566 CVE-2015-2808</cve>
|
141
|
+
<cvss_base_score>4.3</cvss_base_score>
|
142
|
+
</vulnerability>
|
143
|
+
<vulnerability>
|
144
|
+
<port>587/tcp</port>
|
145
|
+
<severity>potential</severity>
|
146
|
+
<description>SSL/TLS server supports RC4 ciphers</description>
|
147
|
+
<class>Other</class>
|
148
|
+
<cve>CVE-2013-2566 CVE-2015-2808</cve>
|
149
|
+
<cvss_base_score>4.3</cvss_base_score>
|
150
|
+
</vulnerability>
|
151
|
+
<vulnerability>
|
152
|
+
<port>25/tcp</port>
|
153
|
+
<severity>potential</severity>
|
154
|
+
<description>SSL/TLS server supports short block sizes (SWEET32 attack)</description>
|
155
|
+
<class>Other</class>
|
156
|
+
<cve>CVE-2016-2183</cve>
|
157
|
+
<cvss_base_score>5.0</cvss_base_score>
|
158
|
+
</vulnerability>
|
159
|
+
<vulnerability>
|
160
|
+
<port>443/tcp</port>
|
161
|
+
<severity>potential</severity>
|
162
|
+
<description>SSL/TLS server supports short block sizes (SWEET32 attack)</description>
|
163
|
+
<class>Other</class>
|
164
|
+
<cve>CVE-2016-2183</cve>
|
165
|
+
<cvss_base_score>5.0</cvss_base_score>
|
166
|
+
</vulnerability>
|
167
|
+
<vulnerability>
|
168
|
+
<port>587/tcp</port>
|
169
|
+
<severity>potential</severity>
|
170
|
+
<description>SSL/TLS server supports short block sizes (SWEET32 attack)</description>
|
171
|
+
<class>Other</class>
|
172
|
+
<cve>CVE-2016-2183</cve>
|
173
|
+
<cvss_base_score>5.0</cvss_base_score>
|
174
|
+
</vulnerability>
|
175
|
+
<vulnerability>
|
176
|
+
<port>587/tcp</port>
|
177
|
+
<severity>service</severity>
|
178
|
+
<description>587/TCP</description>
|
179
|
+
</vulnerability>
|
180
|
+
<vulnerability>
|
181
|
+
<port>25/tcp</port>
|
182
|
+
<severity>service</severity>
|
183
|
+
<description>SMTP</description>
|
184
|
+
</vulnerability>
|
185
|
+
<vulnerability>
|
186
|
+
<port>80/tcp</port>
|
187
|
+
<severity>service</severity>
|
188
|
+
<description>WWW</description>
|
189
|
+
</vulnerability>
|
190
|
+
<vulnerability>
|
191
|
+
<port>443/tcp</port>
|
192
|
+
<severity>service</severity>
|
193
|
+
<description>WWW (Secure)</description>
|
194
|
+
</vulnerability>
|
195
|
+
<vulnerability>
|
196
|
+
<port>465/tcp</port>
|
197
|
+
<severity>service</severity>
|
198
|
+
<description>urd (465/TCP)</description>
|
199
|
+
</vulnerability>
|
200
|
+
<vulnerability>
|
201
|
+
<port>80/tcp</port>
|
202
|
+
<severity>info</severity>
|
203
|
+
<description>Web Directory: /</description>
|
204
|
+
</vulnerability>
|
205
|
+
<vulnerability>
|
206
|
+
<port>443/tcp</port>
|
207
|
+
<severity>info</severity>
|
208
|
+
<description>Web Directory: /</description>
|
209
|
+
</vulnerability>
|
210
|
+
<vulnerability>
|
211
|
+
<port>80/tcp</port>
|
212
|
+
<severity>info</severity>
|
213
|
+
<description>Web Directory: /cgi-bin/</description>
|
214
|
+
</vulnerability>
|
215
|
+
<vulnerability>
|
216
|
+
<port>80/tcp</port>
|
217
|
+
<severity>info</severity>
|
218
|
+
<description>Web Directory: /scripts/</description>
|
219
|
+
</vulnerability>
|
220
|
+
</host_info>
|
221
|
+
</vulnerabilities>
|
222
|
+
</overview>
|
223
|
+
<details>
|
224
|
+
<vulnerability>
|
225
|
+
<description>server is susceptible to BEAST attack</description>
|
226
|
+
<hostname>192.168.150.163</hostname>
|
227
|
+
<ipaddr>192.168.150.163</ipaddr>
|
228
|
+
<hosttype>Linux 2.6.18 - 2.6.22</hosttype>
|
229
|
+
<scan_time>Mar 22 13:22:35 2017</scan_time>
|
230
|
+
<status>new</status>
|
231
|
+
<severity>Potential Problem</severity>
|
232
|
+
<cve>CVE-2011-3389</cve>
|
233
|
+
<cvss_base_score>4.3</cvss_base_score>
|
234
|
+
<impact>
|
235
|
+
A remote attacker with the ability to sniff network traffic could decrypt an
|
236
|
+
encrypted session.
|
237
|
+
</impact>
|
238
|
+
<background>
|
239
|
+
Cipher Block Chaining (CBC) is an encryption mode of operation where the decryption of each block of encrypted text depends on all of the preceding blocks. CBC requires an Initialization Vector, a block of bits which starts the encryption and ensures that the encrypted text is unique. The SSLv3 and TLS 1.0 protocols may encrypt data using Cipher Block Chaining
|
240
|
+
ciphers that use chained initialization vectors.
|
241
|
+
</background>
|
242
|
+
<problem>
|
243
|
+
SSL/TLS CBC Initialization Vector Prediction
|
244
|
+
10/28/11
|
245
|
+
CVE 2011-3389
|
246
|
+
The Browser Exploit against SSL/TLS (BEAST) may allow an attacker to perform
|
247
|
+
a man-in-the-middle attack to obtain plain-text HTTP headers by conducting a
|
248
|
+
blockwise chosen-boundary attack (BCBA) against an HTTPS session.
|
249
|
+
This attack is an extension of two previously
|
250
|
+
disclosed attacks against SSL. The first of these attacks was detailed by
|
251
|
+
Gregory Bard in May 2004 (The
|
252
|
+
Vulnerability of SSL to Chosen Plaintext Attack). This research showed
|
253
|
+
that cipher block chaining mode used by SSL is vulnerable to decryption in
|
254
|
+
cases where the attacker can control part of the plaintext. This attack proved
|
255
|
+
to be difficult to implement against HTTPS sessions due to the attackers'
|
256
|
+
inability to control the contents. This attack method was extended to support
|
257
|
+
TLS 1.0 and improved in April 2006 (A
|
258
|
+
Challenging but Feasible Blockwise-Adaptive Chosen-Plaintext Attack on
|
259
|
+
SSL).
|
260
|
+
In September 2011, Juliano Rizzo and Thai Duong presented a modern iteration
|
261
|
+
of this attack that utilized Java or HTML5 WebSockets as an entry-point for
|
262
|
+
attackers. Using this method, attackers could host a malicious website that,
|
263
|
+
when visited by victims, uses Java or WebSockets to establish a connection to
|
264
|
+
any secured 3rd party website of their choice. If the user has an active
|
265
|
+
session to the targeted 3rd party site, any cookies he or she has saved will also
|
266
|
+
be sent. Since the attacker is initiating this request, he can control the
|
267
|
+
length of the requested resource, allowing him to position the cookie on a
|
268
|
+
block boundary. The attacker also knows part of the cleartext. If this can be
|
269
|
+
done in a man-in-the-middle scenario, the attacker will be able to intercept
|
270
|
+
this encrypted request and decrypt it off-line to obtain the cookie. If the
|
271
|
+
cookie contains an authentication token, this may result in account theft.
|
272
|
+
TLS 1.1 and later have been improved to use an explicit initialization vector
|
273
|
+
strategy, rendering them immune to this type of attack.
|
274
|
+
</problem>
|
275
|
+
<resolution>
|
276
|
+
Most browser vendors have released updates which prevent this attack, but some affected browsers still remain at this time, so it is still advisable also to fix the problem on the server side. SSLv3 and TLS 1.0 should be disabled on the server as follows:
|
277
|
+
Apache: Set the following directive in the Apache configuration file. (The -TLSv1 argument requires Apache 2.2.24 or higher or an update from your Linux vendor.)
|
278
|
+
SSLProtocol all -SSLv2 -SSLv3 -TLSv1
|
279
|
+
IIS: See [http://support.microsoft.com/kb/245030] KB245030 and [https://support.microsoft.com/en-us/kb/187498] KB187498.
|
280
|
+
Note that disabling SSLv3 and TLS 1.0 entirely on the server may affect the usability of the web site, as some web browsers may not yet support TLS 1.1.
|
281
|
+
</resolution>
|
282
|
+
<reference>
|
283
|
+
Thai Duong wrote a detailed [http://vnhacker.blogspot.com/2011/09/beast.html] blog post about this attack, including a video demonstration.
|
284
|
+
Adam Langley wrote a helpful [http://www.imperialviolet.org/2011/09/23/chromeandbeast.html] blog post that helps highlight concerns for both browser vendors and website hosts.
|
285
|
+
Rob VanderBrink of SANS Internet Storm Center [http://isc.sans.edu/diary.html?storyid=11629] posted a blog update detailing TLS 1.1/1.2 support in many common browsers as of September, 2011.
|
286
|
+
Eric Rescorla wrote a [http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html] detailed blog post explaining how the attack works in detail and analyzing the security impact of this vulnerability.
|
287
|
+
</reference>
|
288
|
+
<vuln_details>
|
289
|
+
Service: 587:TCP
|
290
|
+
Server accepted TLS 1.0 CBC cipher: TLS_RSA_WITH_3DES_EDE_CBC_SHA </vuln_details>
|
291
|
+
</vulnerability>
|
292
|
+
<vulnerability>
|
293
|
+
<description>server is susceptible to BEAST attack</description>
|
294
|
+
<hostname>192.168.150.163</hostname>
|
295
|
+
<ipaddr>192.168.150.163</ipaddr>
|
296
|
+
<hosttype>Linux 2.6.18 - 2.6.22</hosttype>
|
297
|
+
<scan_time>Mar 22 13:22:35 2017</scan_time>
|
298
|
+
<status>new</status>
|
299
|
+
<severity>Potential Problem</severity>
|
300
|
+
<cve>CVE-2011-3389</cve>
|
301
|
+
<cvss_base_score>4.3</cvss_base_score>
|
302
|
+
<impact>
|
303
|
+
A remote attacker with the ability to sniff network traffic could decrypt an
|
304
|
+
encrypted session.
|
305
|
+
</impact>
|
306
|
+
<background>
|
307
|
+
Cipher Block Chaining (CBC) is an encryption mode of operation where the decryption of each block of encrypted text depends on all of the preceding blocks. CBC requires an Initialization Vector, a block of bits which starts the encryption and ensures that the encrypted text is unique. The SSLv3 and TLS 1.0 protocols may encrypt data using Cipher Block Chaining
|
308
|
+
ciphers that use chained initialization vectors.
|
309
|
+
</background>
|
310
|
+
<problem>
|
311
|
+
SSL/TLS CBC Initialization Vector Prediction
|
312
|
+
10/28/11
|
313
|
+
CVE 2011-3389
|
314
|
+
The Browser Exploit against SSL/TLS (BEAST) may allow an attacker to perform
|
315
|
+
a man-in-the-middle attack to obtain plain-text HTTP headers by conducting a
|
316
|
+
blockwise chosen-boundary attack (BCBA) against an HTTPS session.
|
317
|
+
This attack is an extension of two previously
|
318
|
+
disclosed attacks against SSL. The first of these attacks was detailed by
|
319
|
+
Gregory Bard in May 2004 (The
|
320
|
+
Vulnerability of SSL to Chosen Plaintext Attack). This research showed
|
321
|
+
that cipher block chaining mode used by SSL is vulnerable to decryption in
|
322
|
+
cases where the attacker can control part of the plaintext. This attack proved
|
323
|
+
to be difficult to implement against HTTPS sessions due to the attackers'
|
324
|
+
inability to control the contents. This attack method was extended to support
|
325
|
+
TLS 1.0 and improved in April 2006 (A
|
326
|
+
Challenging but Feasible Blockwise-Adaptive Chosen-Plaintext Attack on
|
327
|
+
SSL).
|
328
|
+
In September 2011, Juliano Rizzo and Thai Duong presented a modern iteration
|
329
|
+
of this attack that utilized Java or HTML5 WebSockets as an entry-point for
|
330
|
+
attackers. Using this method, attackers could host a malicious website that,
|
331
|
+
when visited by victims, uses Java or WebSockets to establish a connection to
|
332
|
+
any secured 3rd party website of their choice. If the user has an active
|
333
|
+
session to the targeted 3rd party site, any cookies he or she has saved will also
|
334
|
+
be sent. Since the attacker is initiating this request, he can control the
|
335
|
+
length of the requested resource, allowing him to position the cookie on a
|
336
|
+
block boundary. The attacker also knows part of the cleartext. If this can be
|
337
|
+
done in a man-in-the-middle scenario, the attacker will be able to intercept
|
338
|
+
this encrypted request and decrypt it off-line to obtain the cookie. If the
|
339
|
+
cookie contains an authentication token, this may result in account theft.
|
340
|
+
TLS 1.1 and later have been improved to use an explicit initialization vector
|
341
|
+
strategy, rendering them immune to this type of attack.
|
342
|
+
</problem>
|
343
|
+
<resolution>
|
344
|
+
Most browser vendors have released updates which prevent this attack, but some affected browsers still remain at this time, so it is still advisable also to fix the problem on the server side. SSLv3 and TLS 1.0 should be disabled on the server as follows:
|
345
|
+
Apache: Set the following directive in the Apache configuration file. (The -TLSv1 argument requires Apache 2.2.24 or higher or an update from your Linux vendor.)
|
346
|
+
SSLProtocol all -SSLv2 -SSLv3 -TLSv1
|
347
|
+
IIS: See [http://support.microsoft.com/kb/245030] KB245030 and [https://support.microsoft.com/en-us/kb/187498] KB187498.
|
348
|
+
Note that disabling SSLv3 and TLS 1.0 entirely on the server may affect the usability of the web site, as some web browsers may not yet support TLS 1.1.
|
349
|
+
</resolution>
|
350
|
+
<reference>
|
351
|
+
Thai Duong wrote a detailed [http://vnhacker.blogspot.com/2011/09/beast.html] blog post about this attack, including a video demonstration.
|
352
|
+
Adam Langley wrote a helpful [http://www.imperialviolet.org/2011/09/23/chromeandbeast.html] blog post that helps highlight concerns for both browser vendors and website hosts.
|
353
|
+
Rob VanderBrink of SANS Internet Storm Center [http://isc.sans.edu/diary.html?storyid=11629] posted a blog update detailing TLS 1.1/1.2 support in many common browsers as of September, 2011.
|
354
|
+
Eric Rescorla wrote a [http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html] detailed blog post explaining how the attack works in detail and analyzing the security impact of this vulnerability.
|
355
|
+
</reference>
|
356
|
+
<vuln_details>
|
357
|
+
Service: https
|
358
|
+
Server accepted TLS 1.0 CBC cipher: TLS_RSA_WITH_AES_128_CBC_SHA </vuln_details>
|
359
|
+
</vulnerability>
|
360
|
+
<vulnerability>
|
361
|
+
<description>server is susceptible to BEAST attack</description>
|
362
|
+
<hostname>192.168.150.163</hostname>
|
363
|
+
<ipaddr>192.168.150.163</ipaddr>
|
364
|
+
<hosttype>Linux 2.6.18 - 2.6.22</hosttype>
|
365
|
+
<scan_time>Mar 22 13:22:35 2017</scan_time>
|
366
|
+
<status>new</status>
|
367
|
+
<severity>Potential Problem</severity>
|
368
|
+
<cve>CVE-2011-3389</cve>
|
369
|
+
<cvss_base_score>4.3</cvss_base_score>
|
370
|
+
<impact>
|
371
|
+
A remote attacker with the ability to sniff network traffic could decrypt an
|
372
|
+
encrypted session.
|
373
|
+
</impact>
|
374
|
+
<background>
|
375
|
+
Cipher Block Chaining (CBC) is an encryption mode of operation where the decryption of each block of encrypted text depends on all of the preceding blocks. CBC requires an Initialization Vector, a block of bits which starts the encryption and ensures that the encrypted text is unique. The SSLv3 and TLS 1.0 protocols may encrypt data using Cipher Block Chaining
|
376
|
+
ciphers that use chained initialization vectors.
|
377
|
+
</background>
|
378
|
+
<problem>
|
379
|
+
SSL/TLS CBC Initialization Vector Prediction
|
380
|
+
10/28/11
|
381
|
+
CVE 2011-3389
|
382
|
+
The Browser Exploit against SSL/TLS (BEAST) may allow an attacker to perform
|
383
|
+
a man-in-the-middle attack to obtain plain-text HTTP headers by conducting a
|
384
|
+
blockwise chosen-boundary attack (BCBA) against an HTTPS session.
|
385
|
+
This attack is an extension of two previously
|
386
|
+
disclosed attacks against SSL. The first of these attacks was detailed by
|
387
|
+
Gregory Bard in May 2004 (The
|
388
|
+
Vulnerability of SSL to Chosen Plaintext Attack). This research showed
|
389
|
+
that cipher block chaining mode used by SSL is vulnerable to decryption in
|
390
|
+
cases where the attacker can control part of the plaintext. This attack proved
|
391
|
+
to be difficult to implement against HTTPS sessions due to the attackers'
|
392
|
+
inability to control the contents. This attack method was extended to support
|
393
|
+
TLS 1.0 and improved in April 2006 (A
|
394
|
+
Challenging but Feasible Blockwise-Adaptive Chosen-Plaintext Attack on
|
395
|
+
SSL).
|
396
|
+
In September 2011, Juliano Rizzo and Thai Duong presented a modern iteration
|
397
|
+
of this attack that utilized Java or HTML5 WebSockets as an entry-point for
|
398
|
+
attackers. Using this method, attackers could host a malicious website that,
|
399
|
+
when visited by victims, uses Java or WebSockets to establish a connection to
|
400
|
+
any secured 3rd party website of their choice. If the user has an active
|
401
|
+
session to the targeted 3rd party site, any cookies he or she has saved will also
|
402
|
+
be sent. Since the attacker is initiating this request, he can control the
|
403
|
+
length of the requested resource, allowing him to position the cookie on a
|
404
|
+
block boundary. The attacker also knows part of the cleartext. If this can be
|
405
|
+
done in a man-in-the-middle scenario, the attacker will be able to intercept
|
406
|
+
this encrypted request and decrypt it off-line to obtain the cookie. If the
|
407
|
+
cookie contains an authentication token, this may result in account theft.
|
408
|
+
TLS 1.1 and later have been improved to use an explicit initialization vector
|
409
|
+
strategy, rendering them immune to this type of attack.
|
410
|
+
</problem>
|
411
|
+
<resolution>
|
412
|
+
Most browser vendors have released updates which prevent this attack, but some affected browsers still remain at this time, so it is still advisable also to fix the problem on the server side. SSLv3 and TLS 1.0 should be disabled on the server as follows:
|
413
|
+
Apache: Set the following directive in the Apache configuration file. (The -TLSv1 argument requires Apache 2.2.24 or higher or an update from your Linux vendor.)
|
414
|
+
SSLProtocol all -SSLv2 -SSLv3 -TLSv1
|
415
|
+
IIS: See [http://support.microsoft.com/kb/245030] KB245030 and [https://support.microsoft.com/en-us/kb/187498] KB187498.
|
416
|
+
Note that disabling SSLv3 and TLS 1.0 entirely on the server may affect the usability of the web site, as some web browsers may not yet support TLS 1.1.
|
417
|
+
</resolution>
|
418
|
+
<reference>
|
419
|
+
Thai Duong wrote a detailed [http://vnhacker.blogspot.com/2011/09/beast.html] blog post about this attack, including a video demonstration.
|
420
|
+
Adam Langley wrote a helpful [http://www.imperialviolet.org/2011/09/23/chromeandbeast.html] blog post that helps highlight concerns for both browser vendors and website hosts.
|
421
|
+
Rob VanderBrink of SANS Internet Storm Center [http://isc.sans.edu/diary.html?storyid=11629] posted a blog update detailing TLS 1.1/1.2 support in many common browsers as of September, 2011.
|
422
|
+
Eric Rescorla wrote a [http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html] detailed blog post explaining how the attack works in detail and analyzing the security impact of this vulnerability.
|
423
|
+
</reference>
|
424
|
+
<vuln_details>
|
425
|
+
Service: smtp
|
426
|
+
Server accepted TLS 1.0 CBC cipher: TLS_RSA_WITH_3DES_EDE_CBC_SHA </vuln_details>
|
427
|
+
</vulnerability>
|
428
|
+
<vulnerability>
|
429
|
+
<description>SSL/TLS server supports RC4 ciphers</description>
|
430
|
+
<hostname>192.168.150.163</hostname>
|
431
|
+
<ipaddr>192.168.150.163</ipaddr>
|
432
|
+
<hosttype>Linux 2.6.18 - 2.6.22</hosttype>
|
433
|
+
<scan_time>Mar 22 13:22:35 2017</scan_time>
|
434
|
+
<status>new</status>
|
435
|
+
<severity>Potential Problem</severity>
|
436
|
+
<cve>CVE-2013-2566 CVE-2015-2808</cve>
|
437
|
+
<cvss_base_score>4.3</cvss_base_score>
|
438
|
+
<impact>
|
439
|
+
A remote attacker with the ability to sniff network
|
440
|
+
traffic could decrypt an encrypted session.
|
441
|
+
</impact>
|
442
|
+
<background>
|
443
|
+
Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL),
|
444
|
+
are encryption protocols used to ensure confidentiality as
|
445
|
+
information travels across the Internet. They are commonly
|
446
|
+
used between web browsers and web servers to protect
|
447
|
+
sensitive data such as passwords and credit card numbers.
|
448
|
+
At the beginning of a TLS/SSL session, the client and server
|
449
|
+
negotiate the encryption algorithm, known as a cipher. RC4 (Rivest Cipher 4) is a stream cipher which is commonly used in TLS/SSL sessions.
|
450
|
+
</background>
|
451
|
+
<problem>
|
452
|
+
Ciphertext Bias Weakness
|
453
|
+
CVE 2013-2566
|
454
|
+
The encrypted stream which is output by the RC4 cipher contains small biases. This results in ciphertext which isn't truly random when the same plaintext is encrypted with different RC4 keys. This could make it easier for an attacker who can view network traffic to decrypt parts of the plaintext which are typically encrypted many types, such as browser cookies, ultimately leading to session hijacking.
|
455
|
+
Invariance Weakness and Bar Mitzvah attack
|
456
|
+
04/28/15
|
457
|
+
CVE 2015-2808
|
458
|
+
Some RC4 keys contain a pattern which causes part of the state permutation to remain intact throughout the initialization process, resulting in leakage of plaintext bytes. This is known as the Invariance Weakness. This weakness can be used to partially decrypt TLS/SSL sessions which use affected keys in an attack known as Bar Mitzvah. An attacker would need to be able to sniff network traffic in order to exploit this vulnerability, and most RC4 keys do not have this weakness.
|
459
|
+
</problem>
|
460
|
+
<resolution>
|
461
|
+
For Apache mod_ssl web servers, add !RC4 to the [http://httpd.apache.org/docs/2.0/mod/mod_ssl.html#sslciphersuite] SSLCipherSuite
|
462
|
+
directive in the configuration file to disable RC4 ciphers.
|
463
|
+
For Microsoft IIS web servers, disable RC4 ciphers as described in Microsoft knowledge base article
|
464
|
+
[http://support.microsoft.com/kb/245030] 245030.
|
465
|
+
For other types of web servers, consult the web server
|
466
|
+
documentation to find out how to disable RC4 ciphers.
|
467
|
+
</resolution>
|
468
|
+
<reference>
|
469
|
+
For more information on the ciphertext bias weakness, see the blog post [http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html] Attack of the Week: RC4 is kind of broken in TLS.
|
470
|
+
For more information on the Invariance Weakness and Bar Mitzvah attack, see [http://securityaffairs.co/wordpress/35352/hacking/bar-mitzvah-attack-on-rc4.html] Security Affairs and Imperva's paper,
|
471
|
+
[http://www.imperva.com/docs/HII_Attacking_SSL_when_using_RC4.pdf] Attacking SSL when using RC4.
|
472
|
+
</reference>
|
473
|
+
<vuln_details>
|
474
|
+
Service: smtp
|
475
|
+
Server accepted TLS 1.0 RC4 cipher: TLS_RSA_WITH_RC4_128_SHA </vuln_details>
|
476
|
+
</vulnerability>
|
477
|
+
<vulnerability>
|
478
|
+
<description>SSL/TLS server supports RC4 ciphers</description>
|
479
|
+
<hostname>192.168.150.163</hostname>
|
480
|
+
<ipaddr>192.168.150.163</ipaddr>
|
481
|
+
<hosttype>Linux 2.6.18 - 2.6.22</hosttype>
|
482
|
+
<scan_time>Mar 22 13:22:35 2017</scan_time>
|
483
|
+
<status>new</status>
|
484
|
+
<severity>Potential Problem</severity>
|
485
|
+
<cve>CVE-2013-2566 CVE-2015-2808</cve>
|
486
|
+
<cvss_base_score>4.3</cvss_base_score>
|
487
|
+
<impact>
|
488
|
+
A remote attacker with the ability to sniff network
|
489
|
+
traffic could decrypt an encrypted session.
|
490
|
+
</impact>
|
491
|
+
<background>
|
492
|
+
Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL),
|
493
|
+
are encryption protocols used to ensure confidentiality as
|
494
|
+
information travels across the Internet. They are commonly
|
495
|
+
used between web browsers and web servers to protect
|
496
|
+
sensitive data such as passwords and credit card numbers.
|
497
|
+
At the beginning of a TLS/SSL session, the client and server
|
498
|
+
negotiate the encryption algorithm, known as a cipher. RC4 (Rivest Cipher 4) is a stream cipher which is commonly used in TLS/SSL sessions.
|
499
|
+
</background>
|
500
|
+
<problem>
|
501
|
+
Ciphertext Bias Weakness
|
502
|
+
CVE 2013-2566
|
503
|
+
The encrypted stream which is output by the RC4 cipher contains small biases. This results in ciphertext which isn't truly random when the same plaintext is encrypted with different RC4 keys. This could make it easier for an attacker who can view network traffic to decrypt parts of the plaintext which are typically encrypted many types, such as browser cookies, ultimately leading to session hijacking.
|
504
|
+
Invariance Weakness and Bar Mitzvah attack
|
505
|
+
04/28/15
|
506
|
+
CVE 2015-2808
|
507
|
+
Some RC4 keys contain a pattern which causes part of the state permutation to remain intact throughout the initialization process, resulting in leakage of plaintext bytes. This is known as the Invariance Weakness. This weakness can be used to partially decrypt TLS/SSL sessions which use affected keys in an attack known as Bar Mitzvah. An attacker would need to be able to sniff network traffic in order to exploit this vulnerability, and most RC4 keys do not have this weakness.
|
508
|
+
</problem>
|
509
|
+
<resolution>
|
510
|
+
For Apache mod_ssl web servers, add !RC4 to the [http://httpd.apache.org/docs/2.0/mod/mod_ssl.html#sslciphersuite] SSLCipherSuite
|
511
|
+
directive in the configuration file to disable RC4 ciphers.
|
512
|
+
For Microsoft IIS web servers, disable RC4 ciphers as described in Microsoft knowledge base article
|
513
|
+
[http://support.microsoft.com/kb/245030] 245030.
|
514
|
+
For other types of web servers, consult the web server
|
515
|
+
documentation to find out how to disable RC4 ciphers.
|
516
|
+
</resolution>
|
517
|
+
<reference>
|
518
|
+
For more information on the ciphertext bias weakness, see the blog post [http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html] Attack of the Week: RC4 is kind of broken in TLS.
|
519
|
+
For more information on the Invariance Weakness and Bar Mitzvah attack, see [http://securityaffairs.co/wordpress/35352/hacking/bar-mitzvah-attack-on-rc4.html] Security Affairs and Imperva's paper,
|
520
|
+
[http://www.imperva.com/docs/HII_Attacking_SSL_when_using_RC4.pdf] Attacking SSL when using RC4.
|
521
|
+
</reference>
|
522
|
+
<vuln_details>
|
523
|
+
Service: 587:TCP
|
524
|
+
Server accepted TLS 1.0 RC4 cipher: TLS_RSA_WITH_RC4_128_SHA </vuln_details>
|
525
|
+
</vulnerability>
|
526
|
+
<vulnerability>
|
527
|
+
<description>SSL/TLS server supports short block sizes (SWEET32 attack)</description>
|
528
|
+
<hostname>192.168.150.163</hostname>
|
529
|
+
<ipaddr>192.168.150.163</ipaddr>
|
530
|
+
<hosttype>Linux 2.6.18 - 2.6.22</hosttype>
|
531
|
+
<scan_time>Mar 22 13:22:35 2017</scan_time>
|
532
|
+
<status>new</status>
|
533
|
+
<severity>Potential Problem</severity>
|
534
|
+
<cve>CVE-2016-2183</cve>
|
535
|
+
<cvss_base_score>5.0</cvss_base_score>
|
536
|
+
<impact>
|
537
|
+
A remote attacker with the ability to sniff network traffic could decrypt long-lived TLS or SSL sessions.
|
538
|
+
</impact>
|
539
|
+
<background>
|
540
|
+
A Block Cipher is an encryption algorithm which operates on a fixed-size block of data. Plaintext messages which are larger than the block size must be split into multiple blocks before being encrypted by the algorithm.
|
541
|
+
</background>
|
542
|
+
<problem>
|
543
|
+
SWEET32 Attack
|
544
|
+
08/29/16
|
545
|
+
CVE 2016-2183
|
546
|
+
Block ciphers with small block sizes are susceptible to a class of attacks known as birthday attacks.
|
547
|
+
These attacks take advantage of multiple blocks which return identical ciphertext, known as collisions. The probability of collisions occurring becomes significant after a large number of blocks have been encrypted using the same key.
|
548
|
+
The SWEET32 attack is a specific birthday attack which reveals the XOR (exclusive-OR) between a fixed secret and known plaintext, thus allowing the secret to be determined.
|
549
|
+
This attack can be launched in a browser session by javascript code which makes repeated requests containing an authentication token and predictable headers.
|
550
|
+
Successful exploitation requires about 785 GB of data to be captured, and the attacker must be able to inject javascript into a web session and to sniff data from the network.
|
551
|
+
</problem>
|
552
|
+
<resolution>
|
553
|
+
Disable ciphers which have a 64-bit block size, such as Triple-DES as follows:
|
554
|
+
Apache/OpenSSL: Upgrade to OpenSSL 1.1.0, which disables Triple-DES ciphers by default. Alternatively, upgrade to OpenSSL 1.0.1u or 1.0.2i or higher, which classify Triple-DES ciphers as MEDIUM, and insert !MEDIUM in the SSLCipherSuite directive in the appropriate web server configuration file.
|
555
|
+
IIS: Disable DES and 3DES ciphers as described in Microsoft Knowledge Base Article
|
556
|
+
[http://support.microsoft.com/kb/245030] 245030.
|
557
|
+
Note: disabling Triple-DES ciphers may affect compatibility with older clients.
|
558
|
+
</resolution>
|
559
|
+
<reference>
|
560
|
+
For more information on the SWEET32 attack, see
|
561
|
+
[https://sweet32.info] sweet32.info and the
|
562
|
+
[https://bobcares.com/blog/how-to-fix-sweet32-birthday-attacks-vulnerability-cve-2016-2183/] Bobcares Blog.
|
563
|
+
</reference>
|
564
|
+
<vuln_details>
|
565
|
+
Service: smtp
|
566
|
+
Server accepted TLS 1.0 64-bit block size cipher: TLS_RSA_WITH_3DES_EDE_CBC_SHA </vuln_details>
|
567
|
+
</vulnerability>
|
568
|
+
<vulnerability>
|
569
|
+
<description>SSL/TLS server supports short block sizes (SWEET32 attack)</description>
|
570
|
+
<hostname>192.168.150.163</hostname>
|
571
|
+
<ipaddr>192.168.150.163</ipaddr>
|
572
|
+
<hosttype>Linux 2.6.18 - 2.6.22</hosttype>
|
573
|
+
<scan_time>Mar 22 13:22:35 2017</scan_time>
|
574
|
+
<status>new</status>
|
575
|
+
<severity>Potential Problem</severity>
|
576
|
+
<cve>CVE-2016-2183</cve>
|
577
|
+
<cvss_base_score>5.0</cvss_base_score>
|
578
|
+
<impact>
|
579
|
+
A remote attacker with the ability to sniff network traffic could decrypt long-lived TLS or SSL sessions.
|
580
|
+
</impact>
|
581
|
+
<background>
|
582
|
+
A Block Cipher is an encryption algorithm which operates on a fixed-size block of data. Plaintext messages which are larger than the block size must be split into multiple blocks before being encrypted by the algorithm.
|
583
|
+
</background>
|
584
|
+
<problem>
|
585
|
+
SWEET32 Attack
|
586
|
+
08/29/16
|
587
|
+
CVE 2016-2183
|
588
|
+
Block ciphers with small block sizes are susceptible to a class of attacks known as birthday attacks.
|
589
|
+
These attacks take advantage of multiple blocks which return identical ciphertext, known as collisions. The probability of collisions occurring becomes significant after a large number of blocks have been encrypted using the same key.
|
590
|
+
The SWEET32 attack is a specific birthday attack which reveals the XOR (exclusive-OR) between a fixed secret and known plaintext, thus allowing the secret to be determined.
|
591
|
+
This attack can be launched in a browser session by javascript code which makes repeated requests containing an authentication token and predictable headers.
|
592
|
+
Successful exploitation requires about 785 GB of data to be captured, and the attacker must be able to inject javascript into a web session and to sniff data from the network.
|
593
|
+
</problem>
|
594
|
+
<resolution>
|
595
|
+
Disable ciphers which have a 64-bit block size, such as Triple-DES as follows:
|
596
|
+
Apache/OpenSSL: Upgrade to OpenSSL 1.1.0, which disables Triple-DES ciphers by default. Alternatively, upgrade to OpenSSL 1.0.1u or 1.0.2i or higher, which classify Triple-DES ciphers as MEDIUM, and insert !MEDIUM in the SSLCipherSuite directive in the appropriate web server configuration file.
|
597
|
+
IIS: Disable DES and 3DES ciphers as described in Microsoft Knowledge Base Article
|
598
|
+
[http://support.microsoft.com/kb/245030] 245030.
|
599
|
+
Note: disabling Triple-DES ciphers may affect compatibility with older clients.
|
600
|
+
</resolution>
|
601
|
+
<reference>
|
602
|
+
For more information on the SWEET32 attack, see
|
603
|
+
[https://sweet32.info] sweet32.info and the
|
604
|
+
[https://bobcares.com/blog/how-to-fix-sweet32-birthday-attacks-vulnerability-cve-2016-2183/] Bobcares Blog.
|
605
|
+
</reference>
|
606
|
+
<vuln_details>
|
607
|
+
Service: https
|
608
|
+
Server accepted TLS 1.0 64-bit block size cipher: TLS_RSA_WITH_3DES_EDE_CBC_SHA </vuln_details>
|
609
|
+
</vulnerability>
|
610
|
+
<vulnerability>
|
611
|
+
<description>SSL/TLS server supports short block sizes (SWEET32 attack)</description>
|
612
|
+
<hostname>192.168.150.163</hostname>
|
613
|
+
<ipaddr>192.168.150.163</ipaddr>
|
614
|
+
<hosttype>Linux 2.6.18 - 2.6.22</hosttype>
|
615
|
+
<scan_time>Mar 22 13:22:35 2017</scan_time>
|
616
|
+
<status>new</status>
|
617
|
+
<severity>Potential Problem</severity>
|
618
|
+
<cve>CVE-2016-2183</cve>
|
619
|
+
<cvss_base_score>5.0</cvss_base_score>
|
620
|
+
<impact>
|
621
|
+
A remote attacker with the ability to sniff network traffic could decrypt long-lived TLS or SSL sessions.
|
622
|
+
</impact>
|
623
|
+
<background>
|
624
|
+
A Block Cipher is an encryption algorithm which operates on a fixed-size block of data. Plaintext messages which are larger than the block size must be split into multiple blocks before being encrypted by the algorithm.
|
625
|
+
</background>
|
626
|
+
<problem>
|
627
|
+
SWEET32 Attack
|
628
|
+
08/29/16
|
629
|
+
CVE 2016-2183
|
630
|
+
Block ciphers with small block sizes are susceptible to a class of attacks known as birthday attacks.
|
631
|
+
These attacks take advantage of multiple blocks which return identical ciphertext, known as collisions. The probability of collisions occurring becomes significant after a large number of blocks have been encrypted using the same key.
|
632
|
+
The SWEET32 attack is a specific birthday attack which reveals the XOR (exclusive-OR) between a fixed secret and known plaintext, thus allowing the secret to be determined.
|
633
|
+
This attack can be launched in a browser session by javascript code which makes repeated requests containing an authentication token and predictable headers.
|
634
|
+
Successful exploitation requires about 785 GB of data to be captured, and the attacker must be able to inject javascript into a web session and to sniff data from the network.
|
635
|
+
</problem>
|
636
|
+
<resolution>
|
637
|
+
Disable ciphers which have a 64-bit block size, such as Triple-DES as follows:
|
638
|
+
Apache/OpenSSL: Upgrade to OpenSSL 1.1.0, which disables Triple-DES ciphers by default. Alternatively, upgrade to OpenSSL 1.0.1u or 1.0.2i or higher, which classify Triple-DES ciphers as MEDIUM, and insert !MEDIUM in the SSLCipherSuite directive in the appropriate web server configuration file.
|
639
|
+
IIS: Disable DES and 3DES ciphers as described in Microsoft Knowledge Base Article
|
640
|
+
[http://support.microsoft.com/kb/245030] 245030.
|
641
|
+
Note: disabling Triple-DES ciphers may affect compatibility with older clients.
|
642
|
+
</resolution>
|
643
|
+
<reference>
|
644
|
+
For more information on the SWEET32 attack, see
|
645
|
+
[https://sweet32.info] sweet32.info and the
|
646
|
+
[https://bobcares.com/blog/how-to-fix-sweet32-birthday-attacks-vulnerability-cve-2016-2183/] Bobcares Blog.
|
647
|
+
</reference>
|
648
|
+
<vuln_details>
|
649
|
+
Service: 587:TCP
|
650
|
+
Server accepted TLS 1.0 64-bit block size cipher: TLS_RSA_WITH_3DES_EDE_CBC_SHA </vuln_details>
|
651
|
+
</vulnerability>
|
652
|
+
<vulnerability>
|
653
|
+
<description>587/TCP</description>
|
654
|
+
<hostname>192.168.150.163</hostname>
|
655
|
+
<ipaddr>192.168.150.163</ipaddr>
|
656
|
+
<hosttype>Linux 2.6.18 - 2.6.22</hosttype>
|
657
|
+
<scan_time>Mar 22 13:22:35 2017</scan_time>
|
658
|
+
<status>new</status>
|
659
|
+
<severity>Service</severity>
|
660
|
+
<vuln_details>
|
661
|
+
220 mail.securednet.ca ESMTP ready </vuln_details>
|
662
|
+
</vulnerability>
|
663
|
+
<vulnerability>
|
664
|
+
<description>SMTP</description>
|
665
|
+
<hostname>192.168.150.163</hostname>
|
666
|
+
<ipaddr>192.168.150.163</ipaddr>
|
667
|
+
<hosttype>Linux 2.6.18 - 2.6.22</hosttype>
|
668
|
+
<scan_time>Mar 22 13:22:35 2017</scan_time>
|
669
|
+
<status>new</status>
|
670
|
+
<severity>Service</severity>
|
671
|
+
<vuln_details>
|
672
|
+
220 mail.securednet.ca ESMTP ready </vuln_details>
|
673
|
+
</vulnerability>
|
674
|
+
<vulnerability>
|
675
|
+
<description>WWW</description>
|
676
|
+
<hostname>192.168.150.163</hostname>
|
677
|
+
<ipaddr>192.168.150.163</ipaddr>
|
678
|
+
<hosttype>Linux 2.6.18 - 2.6.22</hosttype>
|
679
|
+
<scan_time>Mar 22 13:22:35 2017</scan_time>
|
680
|
+
<status>new</status>
|
681
|
+
<severity>Service</severity>
|
682
|
+
<vuln_details>
|
683
|
+
HTTP/1.1 403 Forbidden
|
684
|
+
Date: Wed, 22 Mar 2017 17:18:01 GMT
|
685
|
+
Cache-Control: no-cache
|
686
|
+
Pragma: no-cache
|
687
|
+
Content-Type: text/html; charset="UTF-8"
|
688
|
+
Content-Length: </vuln_details>
|
689
|
+
</vulnerability>
|
690
|
+
<vulnerability>
|
691
|
+
<description>WWW (Secure)</description>
|
692
|
+
<hostname>192.168.150.163</hostname>
|
693
|
+
<ipaddr>192.168.150.163</ipaddr>
|
694
|
+
<hosttype>Linux 2.6.18 - 2.6.22</hosttype>
|
695
|
+
<scan_time>Mar 22 13:22:35 2017</scan_time>
|
696
|
+
<status>new</status>
|
697
|
+
<severity>Service</severity>
|
698
|
+
<vuln_details>
|
699
|
+
HTTP/1.1 403 Forbidden
|
700
|
+
Date: Wed, 22 Mar 2017 17:18:01 GMT
|
701
|
+
Cache-Control: no-cache
|
702
|
+
Pragma: no-cache
|
703
|
+
Content-Type: text/html; charset="UTF-8"
|
704
|
+
Content-Length: </vuln_details>
|
705
|
+
</vulnerability>
|
706
|
+
<vulnerability>
|
707
|
+
<description>urd (465/TCP)</description>
|
708
|
+
<hostname>192.168.150.163</hostname>
|
709
|
+
<ipaddr>192.168.150.163</ipaddr>
|
710
|
+
<hosttype>Linux 2.6.18 - 2.6.22</hosttype>
|
711
|
+
<scan_time>Mar 22 13:22:35 2017</scan_time>
|
712
|
+
<status>new</status>
|
713
|
+
<severity>Service</severity>
|
714
|
+
<vuln_details>
|
715
|
+
220 mail.securednet.ca ESMTP ready </vuln_details>
|
716
|
+
</vulnerability>
|
717
|
+
</details>
|
718
|
+
</report>
|