HTTPS services on ports like 8443 not detected during service discovery, causing HTTP modules to be skipped

[Gauravsharma2040]

While testing a new Apache OFBiz module on port 8443 specifically CVE-2023-51467, I noticed that Nettacker's service discovery does not detect HTTP services running over TLS.

The HTTP detection logic in port.yaml relies on plaintext HTTP response patterns such as:

HTTP/1.1
Content-Type
Server

However, when connecting to HTTPS services (e.g. port 8443), the socket receives TLS handshake bytes instead of HTTP headers. As a result, none of the HTTP regex patterns match and the service remains:

default_service: unknown

Because of this, modules that declare:

library: http
are removed during module scheduling when service discovery fails to detect HTTP.
The module itself works correctly when service discovery is bypassed using:

python3 nettacker.py -i localhost -m apache_ofbiz_cve_2023_51467_vuln -d

which confirms that the payload and detection logic are functioning as expected. The issue appears to be limited to the service discovery stage.

Additional issue
Attempting to bypass this by using another library such as:
library: network
causes a crash:

KeyError: 'network'

in:
nettacker/core/module.py line 105
This appears to be caused by the engine assuming that payload["library"] always exists in discovered_services.
Possible Improvements

Add HTTPS detection signatures in port.yaml based on TLS handshake bytes.
Make module scheduling resilient to libraries not present in discovered_services.
Allow HTTP modules to run on ports declared in their fuzzer configuration even when service detection fails.

[notReallySouvik]

Hi @Gauravsharma2040 ,

I was able to reproduce this issue in my local environment while testing Nettacker.

From my investigation, the problem seems related to how ports are handled during module execution. In particular:

1. Some ports in the YAML module definitions appear to be hard-coded. Using {{ports}} instead allows the engine to correctly substitute the target ports and prevents the exception.
2. A small adjustment in module.py and socket.py appears to resolve the behavior during module execution.

I’m currently testing a patch locally to confirm the fix.

@securestep9 , if this approach looks reasonable, I’d be happy to work on a PR. Could this issue be assigned to me?

[Aarush289]

HI @notReallySouvik , Can you please elaborate more , I didn't get your first point .

[notReallySouvik]

Hi @Aarush289 ,

Sure, I’ll clarify what I meant.

While debugging the issue locally, I noticed that some module YAML files define ports explicitly (for example 8443 or 80). When the engine schedules modules, it relies on the results from the service discovery phase (discovered_services) to determine which modules should run.

If a module hard-codes a port instead of using {{ports}}, the engine may attempt to execute the module without correctly mapping it to the discovered service set. In cases where service discovery fails (like HTTPS services on 8443 not being detected as HTTP due to TLS handshake bytes), the module scheduler removes HTTP-based modules before execution.

Using {{ports}} allows Nettacker to dynamically substitute the ports that were actually identified during scanning. This keeps the module aligned with the engine’s discovery logic and avoids the exception during execution.

In my local tests, replacing hard-coded ports with {{ports}} prevented the crash and allowed the module to proceed when service discovery was handled correctly.

I’m still testing a small patch that adjusts the behavior in module.py and socket.py to make this more robust, especially when HTTPS services are involved.

Let me know if you’d like me to share the specific changes I’m testing.

[Aarush289]

Can you please share the screenshot of what crash you are facing .

[notReallySouvik]

@Aarush289 this is the issue I’m referring to..

In the current module configuration, the port is effectively hard-coded. Because of that, the module execution path doesn’t always align with the ports discovered during the scanning phase.

One quick workaround is to explicitly add port 8443 in the module configuration (as shown in the second screenshot). This allows the module to run against the expected HTTPS endpoint.

However, I think a better approach would be to rely on the port value already provided by the engine using:

input_format: "{{schema}}://{target}:{{ports}}"

This way the module dynamically uses the port supplied during execution rather than relying on a fixed value. It keeps the module consistent with Nettacker’s scheduling logic and avoids mismatches between service discovery and module execution.

I’m currently testing this approach locally to confirm it resolves the issue without introducing side effects.

[Aarush289]

This Is not an issue , The module is expected to run on the ports specified in it or if you want to run on other ports then just give that in arguments ?

[notReallySouvik]

@Aarush289

Pardon me — when I took the earlier screenshot I had forgotten that I had already applied a small patch locally to test HTTPS detection.

Without the patch, the behavior looks like this:

The issue occurs earlier during service discovery, not during module execution.

When Nettacker scans a service running HTTP over TLS (for example Apache OFBiz on port 8443), the detection in port.yaml attempts to match plaintext HTTP response patterns such as:

• HTTP/1.1
• Content-Type
• Server

However, when connecting to an HTTPS service, the socket receives TLS handshake bytes instead of HTTP headers, so none of the HTTP regex signatures match. As a result the port remains classified as:

default_service: unknown

Because of this classification, modules that declare:

library: http

are filtered out during module scheduling, since Nettacker assumes there is no HTTP service running on that port.

[Aarush289]

Yeah , there is this issue that the tool sends garbage data in port scan and might not be able to detect all the services , I have worked upon payload_based_probes for around 1 month and is yet to be reviewed by the maintainer so you may ignore this issue for now because once we implement the payload_based_probes in out tool then all such issues will get fixed .

[notReallySouvik]

This Is not an issue , The module is expected to run on the ports specified in it or if you want to run on other ports then just give that in arguments ?

Hi @Aarush289,

I understand that modules are expected to run on the ports specified in their configuration or those supplied through arguments.

However, I’m still a bit unsure how passing the port through arguments would work in cases where the module itself defines a fixed port.

For example, if a module hard-codes a port (e.g. 8443) instead of using {{ports}}, then even if the user runs Nettacker with -p to specify a different port, the module would still attempt to use the hard-coded value.

Am I missing a configuration step here?

[Aarush289]

I am not telling that giving the ports through cli explicitly would fix this issue ( that was the case when your question wasn't clear ) , As I told - currently random bytes are being used in port scan and have very limited matching regexes so it will often miss the services which ignores unexpected bytes , and to fix that I have worked upon payload_based_probes which would be able to detect much wider range of services .

[notReallySouvik]

Hi @Aarush289,

Got it, thanks for explaining.

If payload_based_probes improves service detection then that should solve this more broadly. I was testing a small patch locally to improve the current behavior without changing the scanning logic. If it’s useful, I can open a small PR for it.