bennettwarner
commented
4 months ago I have also come across this bug. From my digging it seems that if a template runs multiple openssl scans, if the first scan fails, subsequent scans will also fail. This is the case for templates like weak-cipher-suites.yaml.
To demonstrate this issue I am using the following template:
id: ssl-test
info:
name: SSL Test
author: ben
severity: info
description: test
reference:
- https://www.acunetix.com/vulnerabilities/web/tls-ssl-weak-cipher-suites/
metadata:
max-request: 4
tags: ssl,tls
ssl:
- address: "{{Host}}:{{Port}}"
min_version: tls10
max_version: tls10
extractors:
- type: dsl
dsl:
- "tls_version, cipher"
- address: "{{Host}}:{{Port}}"
min_version: tls13
max_version: tls13
extractors:
- type: dsl
dsl:
- "tls_version, cipher"This template fails to run if the server does not support TLSv1.0 as can be seen in the following output:
$ nuclei -u www.TARGET.com -id ssl-test -t ./temp -debug
__ _
____ __ _______/ /__ (_)
/ __ \/ / / / ___/ / _ \/ /
/ / / / /_/ / /__/ / __/ /
/_/ /_/\__,_/\___/_/\___/_/ v3.2.2
projectdiscovery.io
[INF] Current nuclei version: v3.2.2 (outdated)
[INF] Current nuclei-templates version: v9.8.5 (latest)
[WRN] Scan results upload to cloud is disabled.
[INF] New templates added in latest release: 142
[INF] Templates loaded for current scan: 1
[WRN] Loaded 1 unsigned templates for scan. Use with caution.
[INF] Targets loaded for current scan: 1
[WRN] [ssl-test] Could not execute step: [ssl-test,auto:RUNTIME] [ctls:RUNTIME] remote error: tls: protocol version not supported <- could not do handshake; [ztls:RUNTIME] remote error: protocol version not supported <- could not do tls handshake; [OpenSSL3.0.2,OpenSSL3.0.2:RUNTIME] failed to response from openssl <- Command: /usr/bin/openssl s_client -connect www.TARGET.com:443 -servername www.TARGET.com -tls1 <- failed to parse openssl response. original response is:
{/usr/bin/openssl s_client -connect www.TARGET.com:443 -servername www.TARGET.com -tls1 CONNECTED(00000003)
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 135 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1714679079
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
---
40A7DC63E37F0000:error:0A00042E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:../ssl/record/rec_layer_s3.c:1584:SSL alert number 70
} <- no server certificates found <- could not connect to host <- could not connect to server
[INF] No results found. Better luck next time!However, if I remove the TLS 1.0 check like the following:
id: ssl-test
info:
name: SSL Test
author: ben
severity: info
description: test
reference:
- https://www.acunetix.com/vulnerabilities/web/tls-ssl-weak-cipher-suites/
metadata:
max-request: 4
tags: ssl,tls
ssl:
- address: "{{Host}}:{{Port}}"
min_version: tls13
max_version: tls13
extractors:
- type: dsl
dsl:
- "tls_version, cipher"It runs successfully, as can be seen in the following output:
$ nuclei -u www.TARGET.com -id ssl-test -t ./temp -debug
__ _
____ __ _______/ /__ (_)
/ __ \/ / / / ___/ / _ \/ /
/ / / / /_/ / /__/ / __/ /
/_/ /_/\__,_/\___/_/\___/_/ v3.2.2
projectdiscovery.io
[INF] Current nuclei version: v3.2.2 (outdated)
[INF] Current nuclei-templates version: v9.8.5 (latest)
[WRN] Scan results upload to cloud is disabled.
[INF] New templates added in latest release: 142
[INF] Templates loaded for current scan: 1
[WRN] Loaded 1 unsigned templates for scan. Use with caution.
[INF] Targets loaded for current scan: 1
[DBG] [ssl-test] Dumped SSL request for www.TARGET.com address=www.TARGET.com
[DBG] [ssl-test] Dumped SSL response for www.TARGET.com
{"timestamp":"2024-05-02T19:31:36.759730009Z","host":"www.TARGET.com","ip":"TARGET","port":"443","probe_status":true,"tls_version":"tls13","cipher":"TLS_AES_256_GCM_SHA384","not_before":"2023-10-26T19:42:24Z","not_after":"2024-11-26T19:42:24Z","subject_dn":"CN=*.TARGET.com","subject_cn":"*.TARGET.com","subject_an":["*.TARGET.com","TARGET.com"],"domains":["TARGET.com"],"serial":"37:4B:6B:17:48:78:AD:1D","issuer_dn":"CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O=GoDaddy.com\\, Inc., L=Scottsdale, ST=Arizona, C=US","issuer_cn":"Go Daddy Secure Certificate Authority - G2","issuer_org":["GoDaddy.com, Inc."],"fingerprint_hash":{"md5":"dd3d68ed277c460084dbc7a1834a81f8","sha1":"bee9fb1554401d0a5f4acd589149c47551293964","sha256":"e5454ec4d51e2209b912277f88c0d4a4b2f76710bc30208b9f42cd86feae650d"},"wildcard_certificate":true,"tls_connection":"ctls","sni":"www.TARGET.com"}
[ssl-test] [ssl] [info] www.TARGET.com:443 [[tls13 TLS_AES_256_GCM_SHA384]]This creates a scenario of false negatives where there could be a cipher finding on TLSv1.3 that is silently not checked.
Nuclei version:
main|dev
Current Behavior:
SSL sequential requests fails due to SSL connection errors. Within SSL context this might be not the wanted behavior as the SSL itself is being tested.
Expected Behavior:
Sequential execution (similar to logic OR)
Steps To Reproduce:
Template 9.1.3.yaml