Network Templates with multiple CRLF-separated lines read only the first response

[mhmdiaa]

Nuclei version:

3.3.0

Current Behavior:

When a network template sends multiple messages separated by CRLF sequences and the server responds to each individually, the engine only reads the first response.

This pattern can lead to potential false negatives. For example, the ftp-weak-credentials template uses this pattern:

...
  - inputs:
      - data: "USER {{username}}\r\nPASS {{password}}\r\n"
...

Some FTP servers respond to the USER command with a message like a server banner or Please specify the password. They then read the PASS command and, if the credentials are correct, return the 230 Login successful response that the template matches against. If the engine doesn't read the second response, it won't catch this.

Expected Behavior:

The engine should keep listening on the connection after the first response.

Steps To Reproduce:

1. Write the following template to test-tcp-conn.yaml:

id: test-tcp-conn

info:
  name: Test TCP Connection
  author: mhmdiaa
  severity: info
self-contained: true

tcp:
  - inputs:
      - data: "USER anonymous\r\nPASS anonymous\r\n"
    host:
      - ftp.ietf.org:21

    matchers:
      - type: word
        words:
          - "230 Login successful"

2. Run nuclei -t test-tcp-conn.yaml -debug
3. Notice that the template doesn't get a match even though the server supports anonymous login and the debug output only contains the first response 220 (vsFTPd 3.0.5).

nuclei -t test-tcp-conn.yaml -debug

...
00000000 55 53 45 52 20 61 6e 6f 6e 79 6d 6f 75 73 0d 0a |USER anonymous..|
00000010 50 41 53 53 20 61 6e 6f 6e 79 6d 6f 75 73 0d 0a |PASS anonymous..| address=ftp.ietf.org:21
[DBG] [test-tcp-conn] Dumped Network response for ftp.ietf.org:21

00000000 32 32 30 20 28 76 73 46 54 50 64 20 33 2e 30 2e |220 (vsFTPd 3.0.|
00000010 35 29 0d 0a |5)..|
[INF] No results found. Better luck next time!

Anything else:

I was about to take a stab at fixing this but noticed a couple of things:

• Other templates, like ftp-anonymous-login, use a slightly different pattern where the commands are separated into different requests (which makes a lot of sense for a protocol like FTP), which remediates the problem.

  - inputs:
      - data: "USER anonymous\r\n"
        read: 1024
      - data: "PASS anonymous\r\n"
        read: 1024

• There's already a function that seems to handle this very well in projectdiscovery/utils, but it's only used if the template's read size field is set to -1 (not sure why). So if we add a read-size: -1, the above template works.

id: test-tcp-conn

info:
  name: Test TCP Connection
  author: mhmdiaa
  severity: high
self-contained: true

tcp:
  - inputs:
      - data: "USER anonymous\r\nPASS anonymous\r\n"
    host:
      - ftp.ietf.org:21


    matchers:
      - type: word
        words:
          - "230 Login successful"
     read-size: -1

So I held off on the PR because there seem to be a few potential fixes to consider:

1. Update the templates that use the "single data field" pattern to use multiple fields with separate read values.
2. Replace network.ConnReadNWithTimeout() with github.com/projectdiscovery/utils/reader.ConnReadNWithTimeout() throughout.
3. Modify network.ConnReadNWithTimeout() to continue reading until the connection is closed.

[tarunKoyalwar]

@mhmdiaa we have read-all for this very purpose it reads all available data whatever is available in connection

we earlier set this as default for every template which broke some templates so this should be used only when the template requires it

[mhmdiaa]

Thanks for your reply @tarunKoyalwar; I totally missed read-all. However, from a quick look at the code, it seems to do something similar to what I did in the second template, where it sets the buffer size to -1, allowing util.reader.ConnReadNWithTimeout() to handle the request. I was hoping for a solution that allows reading multiple responses while still maintaining a size limit for safety purposes (to avoid OOM issues).

I can work around this using the multiple data fields pattern used in ftp-anonymous-login, but it might be worth revisiting this default behavior since the read-all field doesn’t seem to be used in any network templates in projectdiscovery/nuclei-templates and a few of them use one data field with CRLF separators. It seems like a "gotcha" that’s easy to overlook.

Cheers