This is probably a kludge because I am not super familiar with TLS
socket programming or SET generally, but it achieves the result, which
is not to shutdown the (HTTPS) socket server when a TLS client responds
to a TLS Server Hello message with a fatal Alert message.
One example of a client that does this is recent Firefox. What this
means is that if you run SET with `WEBATTACK_SSL=ON` and
`SELF_SIGNED_CERT=ON`, your victim can turn off your HTTPS server simply
by navigating to your attack page.
This is caused by the underlying OpenSSL library raising an error that
`pyopenssl`, in turn, `raise`s through the socket server libraries.
Ultimately, it bubbles up to the `harvester` module through its
`shutdown_request` method, called by the underlying socket server's
`_handle_request_noblock` method. See the backtrace printed in the
comments of Pull Request #696 for a complete example.
The bottom line is that this unhandled exception ultimately causes the
HTTPS server to die before it gets a chance to be useful. Since I assume
that SET doesn't particularly care what certificate validation alerts the
client is sending us, this patch addresses the issue by ignoring every
raised exception from the underlying libraries except for a
`KeyboardInterrupt` so that the SET user can cause a server shutdown
themselves, with the expected `C-c` interrupt signal.
There is probably a more graceful way to handle this, though? Also, note
that this only fixes the HTTPS issues for Python 3. Python 2 exhibits a
different error altogether.
Per Debian policy, Python versions 3 and greater must be called from the
`python3` executable, not the `python` executable. This means
Debian-based systems with Python 3 installed but not Python 2 will fail
to launch SET through `seautomate` because the `python` executable is
hard-coded into the call to `pexpect.spawn()`.
This commit uses the standard library's
`distutils.spawn.find_executable()` method to locate the correct path to
`python3` or, failing that, the correct path to the `python` executable
and uses the result of that call as the first command line word with
which to invoke `setoolkit`.
The `distutils.spawn.find_executable()` method is available at that
exact name in both Python 2 and 3, so this should be portable across all
Python versions.
Note that the shebang line references `python`, and so Python 3-only
systems such as newer Debian-based builds may need to invoke
`seautomate` using an explicit interpreter for it to work:
```sh
sudo python3 ./seautomate /path/to/script/file.txt
```
This resolves the first issue in a line of several preventing the
SSL-capable server from spinning up correctly as described in the
referenced issue number. The cause is simply a missing import when
`setoolkit` is run under Python 3.
See also pymssql/pymssql#668 which describes the discontinuance of the
pymssql project.
This commit addresses the issue by simplistically pinning the dependency
on pymssql to an existing version.
Mass Mailer Attack, SET throws an error:
Something went wrong, printing the error: No module named 'cStringIO'
This fixes it, the change to socket.py fixes the module name,
and the change to smtp_web fixes the exception name.
This commit fixes a bug in the credential harvester Web attack
method that prevented these attacks from being successful.
Specifically, files needed for these attacks (e.g., `source.js`) in
the Web server's document root (`web_clone` folder) were treated as
though they were path traversal attacks, resulting an HTTP 404 sent
back to the (victim) browser; these attacks would fail.
In fact, files requested via URLs such as `/source.js` are valid
paths, but since they were not explicitly checked for in the same way
that the `index.html` and `index2.html` files were, these helper files
were not being served.
This fix improves URL handling by using Python's `os.path.relpath()`
method to ensure that all requested URLs are treated as relative to
the Web server's document root (`webroot` variable). This also
reliably prevents path traversal attacks because the
`requested_file` variable is always prepended with the Web root after
path calculations (normalizing `../` sequences, etcetera) have been
performed. As a result, the explicit check for the path traversal
detection is no longer needed; such requests will always error 404.
