HTML Report Rendering Error in SOCKS Mode

[Barriuso]

OS Used - ALL Information (architecture, linux flavor, etc.)

Kali Linux

Pastebin link to error you are encountering

N/A

Expected behavior (vs. what you encountered)

A bug has been identified when the tool is executed in SOCKS mode. The issue specifically affects the rendering of images in the HTML report.

Steps to Reproduce:

1. Configure Eyewitness to operate in SOCKS mode.
2. Execute the tool to capture screenshots of target websites.
3. Generate the HTML report.

Expected Result:
The HTML report should display the screenshots correctly, providing a visual representation of the target websites.

Actual Result:
The screenshots are captured correctly, but they do not render properly in the HTML report. This results in missing. An example is shown below.

Any additional information

[Relkci]

We have made some changes to the reporting components in the last /while/ -- can you try running from the GitHub version and see if the issue is resolved?

[Barriuso]

I've downloaded Eyewitness again from GitHub, but the issue persists. The screenshots are captured correctly, but they still don't display in the HTML report. The error remains the same

[Relkci]

This is a duplicate issue of #671

Admittedly, the error is a bit misleading. "Unkown error while attempting to screenshot" is used generically here to say something went wrong. In this case, what went wrong was not the screenshot, but rather the meta data collection (headers, source, etc) with urllib. The process of gathering that metadata is different than the process to capture the screenshot. To have both the metadata + screenshot in the report requires both processes to complete successfully. If they don't we try to identify an error, if we can't you get "Unkown error while attempting to screenshot". -- Even if the screenshot was made.

So there were some changes that allowed EyeWitness to capture screenshots even when it thinks it won't be able to based on a failed meta-data capture (urllib). Previously if the script failed to connect to capture headers and source file, it would assume that selenium would also fail. This was changed to allow selium to still attempt the screenshot under those certain circumstances.

The result is we have screenshots for some systems when no information about the connection is available to be put in the report.

In regards to why urllib would fail to gather metadata, but selium can still get a screenshot... I think it falls under Firefox being more robust than urllib for handling peculiar connections (slow, aysnc, unexpected ciphers, broken connections, timeouts, etc) -- or.. something else. Unfortunately, we see it so rarely that it's difficult to nail down.

--
I think the expected outcome in that situation is that the screenshot be included in the report, even if we can't provide any meta-data with it.

To address this issue for closure, we need to include a screenshot in the report if the screenshot exists, even if the database result for the host shows a badstatus ("Unkown error while attempting to screenshot")

[Relkci]

Actually, can you clarify-- does this happen for every host when proxied over SOCKS, or just certain ones?