Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

WebDriverError / "Unknown error while attempting to screenshot" #488

Closed
BeanBagKing opened this issue Jul 7, 2020 · 6 comments
Closed

WebDriverError / "Unknown error while attempting to screenshot" #488

BeanBagKing opened this issue Jul 7, 2020 · 6 comments

Comments

@BeanBagKing
Copy link

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

New/Weekly build of Kali (kali-linux-2020-W28-installer-amd64) / Linux hostname 5.6.0-kali2-amd64 #1 SMP Debian 5.6.14-2kali1 (2020-06-10) x86_64 GNU/Linux

I did not install eyewitness via apt. I cloned the repo and ran setup.sh

Pastebin link to error you are encountering

./EyeWitness.py --single 192.168.1.107

Attempting to screenshot http://192.168.1.107
[*] WebDriverError when connecting to http://192.168.1.107

Correcting for this results in a screenshot being taken, but a report with an error message of "Unknown error while attempting to screenshot" in the column where the screenshot should be.

Expected behavior (vs. what you encountered)

Plethora of screenshots

Any additional information

This is some pretty old IoT stuff that I'm attempting to inventory. I have the feeling that this is related to SSL/TLS ciphers, but I just can't get things to work. Visiting the page in Firefox results in the following error:

Secure Connection Failed

An error occurred during a connection to 192.168.1.107. SSL received a record with an incorrect Message Authentication Code. Error code: SSL_ERROR_BAD_MAC_READ

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
    Please contact the website owners to inform them of this problem.

Learn more…

Chromium results in:

This site can’t provide a secure connection
192.168.1.107 sent an invalid response.
ERR_SSL_PROTOCOL_ERROR

So my thought was to proxy traffic through Burp and let Burp handle the TLS connection. After installing the certificate and configuring proxy settings, I can now get to the login page on either Firefox Or Chromium. However, when trying to screenshot the page, I get odd behavior. The report seems to finish successfully, but I have the error "Unknown error while attempting to screenshot" in my report

Report Generated on 07/07/2020 at 16:30:17
Web Request Info	Web Screenshot
http://192.168.1.107
Unknown error while attempting to screenshot

I also see the following error lines on the terminal:

Would you like to open the report now? [Y/n]
y
<snip>
user@hostname:~/EyeWitness/Python$ [25603:25603:0707/163038.151501:ERROR:edid_parser.cc(102)] Too short EDID data: manufacturer id
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
[25644:25644:0707/163038.432194:ERROR:vaapi_wrapper.cc(480)] vaInitialize failed: unknown libva error
[25644:25644:0707/163038.489196:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process.

user@hostname:~/EyeWitness/Python$

However, there is a correct screenshot within the "screens" folder. I'm not sure at all why it's saying Unknown error. I'm not sure if it's related to using Burp, thus the annoyingly long background story for this. TL;DR I guess is that it works, however, this report will include a massive number of systems, so it's desirable to have the screenshot in the report, and not have to manually sort through the screens folder.

The Burp options are pretty much at their default now, intercept is off, but it still takes a -long- time to request these pages (longer than I feel it should, thus the 60 second timeout).

I know the original problem was related to SSL/TLS settings, so I'm including the testssl.sh results below in case they are useful regarding the webdrivererror issue.

###########################################################
    testssl.sh       3.1dev from https://testssl.sh/dev/
    (6071ae9 2020-07-07 15:53:49 -- )

      This program is free software. Distribution and
             modification under GPLv2 permitted.
      USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!

       Please file bugs @ https://testssl.sh/bugs/

###########################################################

 Using "OpenSSL 1.0.2-chacha (1.0.2k-dev)" [~179 ciphers]
 on hostname:./bin/openssl.Linux.x86_64
 (built: "Jan 18 17:12:17 2019", platform: "linux-x86_64")


 Start 2020-07-07 15:38:24        -->> 192.168.1.107:443 (192.168.1.107) <<--

 rDNS (192.168.1.107):    --
 Service detected:       HTTP


 Testing protocols via sockets except NPN+ALPN

 SSLv2      not offered (OK)
 SSLv3      not offered (OK)
 TLS 1      offered (deprecated)
 TLS 1.1    offered (deprecated)
 TLS 1.2    not offered and downgraded to a weaker protocol
 TLS 1.3    not offered and downgraded to a weaker protocol
 NPN/SPDY   not offered
 ALPN/HTTP2 not offered

 Testing cipher categories

 NULL ciphers (no encryption)                      not offered (OK)
 Anonymous NULL Ciphers (no authentication)        not offered (OK)
 Export ciphers (w/o ADH+NULL)                     not offered (OK)
 LOW: 64 Bit + DES, RC[2,4], MD5 (w/o export)      not offered (OK)
 Triple DES Ciphers / IDEA                         not offered
 Obsoleted CBC ciphers (AES, ARIA etc.)            offered
 Strong encryption (AEAD ciphers) with no FS       not offered
 Forward Secrecy strong encryption (AEAD ciphers)  not offered


 Testing server's cipher preferences

 Has server cipher order?     yes (OK)
 Negotiated protocol          TLSv1.1
 Negotiated cipher            AES256-SHA
 Cipher per protocol

Hexcode  Cipher Suite Name (OpenSSL)       KeyExch.   Encryption  Bits     Cipher Suite Name (IANA/RFC)
-----------------------------------------------------------------------------------------------------------------------------
SSLv2
 -
SSLv3
 -
TLSv1 (server order)
 x35     AES256-SHA                        RSA        AES         256      TLS_RSA_WITH_AES_256_CBC_SHA
 x2f     AES128-SHA                        RSA        AES         128      TLS_RSA_WITH_AES_128_CBC_SHA
TLSv1.1 (server order)
 x35     AES256-SHA                        RSA        AES         256      TLS_RSA_WITH_AES_256_CBC_SHA
 x2f     AES128-SHA                        RSA        AES         128      TLS_RSA_WITH_AES_128_CBC_SHA
TLSv1.2
 -
TLSv1.3
 -


 Testing robust forward secrecy (FS) -- omitting Null Authentication/Encryption, 3DES, RC4

 No ciphers supporting Forward Secrecy (FS) offered


 Testing server defaults (Server Hello)

 TLS extensions (standard)    (none)
 Session Ticket RFC 5077 hint no -- no lifetime advertised
 SSL Session ID support       yes
 Session Resumption           Tickets no, ID resumption test failed
 TLS clock skew               Random values, no fingerprinting possible
 Signature Algorithm          SHA1 with RSA -- besides: users will receive a strong browser WARNING
 Server key size              RSA 1024 bits (exponent is 65537)
 Server key usage             --
 Server extended key usage    --
 Serial / Fingerprints        C383 / SHA1 <redacted>
                              SHA256 <redacted>
 Common Name (CN)             <redacted>
 subjectAltName (SAN)         missing (NOT ok) -- Browsers are complaining
 Issuer                       <redacted>
 Trust (hostname)             certificate does not match supplied URI
 Chain of trust               NOT ok (chain incomplete)
 EV cert (experimental)       no
 ETS/"eTLS", visibility info  not present
 Certificate Validity (UTC)   6266 >= 60 days (2010-11-03 17:01 --> 2037-09-02 17:01)
                              >= 10 years is way too long
 # of certificates provided   1
 Certificate Revocation List  --
 OCSP URI                     --
                              NOT ok -- neither CRL nor OCSP URI provided
 OCSP stapling                not offered
 OCSP must staple extension   --
 DNS CAA RR (experimental)    not offered
 Certificate Transparency     --


 Testing HTTP header response @ "/"

 HTTP Status Code             200 OK
 HTTP clock skew              +3 (± 1.5) sec from localtime
 Strict Transport Security    365 days=31536000 s, just this domain
 Public Key Pinning           --
 Server banner                exists but empty string
 Application banner           --
 Cookie(s)                    (none issued at "/")
 Security headers             X-Frame-Options sameorigin
                              X-XSS-Protection 1; mode=block
                              X-Content-Type-Options nosniff
                              X-Content-Security-Policy "allow 'self'"
                              Cache-Control no-store, no-cache, must-revalidate, private, post-check=0, pre-check=0
 Reverse Proxy banner         --


 Testing vulnerabilities

 Heartbleed (CVE-2014-0160)                not vulnerable (OK), no heartbeat extension
 CCS (CVE-2014-0224)                       likely VULNERABLE (NOT ok), suspicious error code "33" returned. Please report
 Ticketbleed (CVE-2016-9244), experiment.  not vulnerable (OK), no session ticket extension
 ROBOT                                     VULNERABLE (NOT ok)
 Secure Renegotiation (RFC 5746)           Not supported / VULNERABLE (NOT ok)
 Secure Client-Initiated Renegotiation     not vulnerable (OK)
 CRIME, TLS (CVE-2012-4929)                not vulnerable (OK)
 BREACH (CVE-2013-3587)                    no gzip/deflate/compress/br HTTP compression (OK)  - only supplied "/" tested
 POODLE, SSL (CVE-2014-3566)               not vulnerable (OK), no SSLv3 support
 TLS_FALLBACK_SCSV (RFC 7507)              Rerun including POODLE SSL check. Downgrade attack prevention NOT supported
 SWEET32 (CVE-2016-2183, CVE-2016-6329)    not vulnerable (OK)
 FREAK (CVE-2015-0204)                     not vulnerable (OK)
 DROWN (CVE-2016-0800, CVE-2016-0703)      not vulnerable on this host and port (OK)
                                           make sure you don't use this certificate elsewhere with SSLv2 enabled services
                                           https://censys.io/ipv4?q=<redacted> could help you to find out
 LOGJAM (CVE-2015-4000), experimental      not vulnerable (OK): no DH EXPORT ciphers, no DH key detected with <= TLS 1.2
 BEAST (CVE-2011-3389)                     TLS1: AES256-SHA AES128-SHA
                                           VULNERABLE -- but also supports higher protocols  TLSv1.1 (likely mitigated)
 LUCKY13 (CVE-2013-0169), experimental     potentially VULNERABLE, uses cipher block chaining (CBC) ciphers with TLS. Check patches
 RC4 (CVE-2013-2566, CVE-2015-2808)        no RC4 ciphers detected (OK)


 Running client simulations (HTTP) via sockets

 Android 4.4.2                TLSv1.1 AES256-SHA, No FS
 Android 5.0.0                TLSv1.1 AES256-SHA, No FS
 Android 6.0                  TLSv1.1 AES256-SHA, No FS
 Android 7.0 (native)         TLSv1.1 AES256-SHA, No FS
 Android 8.1 (native)         TLSv1.1 AES256-SHA, No FS
 Android 9.0 (native)         TLSv1.1 AES256-SHA, No FS
 Android 10.0 (native)        TLSv1.1 AES256-SHA, No FS
 Chrome 74 (Win 10)           TLSv1.1 AES256-SHA, No FS
 Chrome 79 (Win 10)           TLSv1.1 AES256-SHA, No FS
 Firefox 66 (Win 8.1/10)      TLSv1.1 AES256-SHA, No FS
 Firefox 71 (Win 10)          TLSv1.1 AES256-SHA, No FS
 IE 6 XP                      No connection
 IE 8 Win 7                   TLSv1.0 AES256-SHA, No FS
 IE 8 XP                      No connection
 IE 11 Win 7                  TLSv1.1 AES256-SHA, No FS
 IE 11 Win 8.1                TLSv1.1 AES256-SHA, No FS
 IE 11 Win Phone 8.1          TLSv1.1 AES256-SHA, No FS
 IE 11 Win 10                 TLSv1.1 AES256-SHA, No FS
 Edge 15 Win 10               TLSv1.1 AES256-SHA, No FS
 Edge 17 (Win 10)             TLSv1.1 AES256-SHA, No FS
 Opera 66 (Win 10)            TLSv1.1 AES256-SHA, No FS
 Safari 9 iOS 9               TLSv1.1 AES256-SHA, No FS
 Safari 9 OS X 10.11          TLSv1.1 AES256-SHA, No FS
 Safari 10 OS X 10.12         TLSv1.1 AES256-SHA, No FS
 Safari 12.1 (iOS 12.2)       TLSv1.1 AES256-SHA, No FS
 Safari 13.0 (macOS 10.14.6)  TLSv1.1 AES256-SHA, No FS
 Apple ATS 9 iOS 9            No connection
 Java 6u45                    TLSv1.0 AES128-SHA, No FS
 Java 7u25                    TLSv1.0 AES128-SHA, No FS
 Java 8u161                   TLSv1.1 AES256-SHA, No FS
 Java 11.0.2 (OpenJDK)        TLSv1.1 AES256-SHA, No FS
 Java 12.0.1 (OpenJDK)        TLSv1.1 AES256-SHA, No FS
 OpenSSL 1.0.2e               TLSv1.1 AES256-SHA, No FS
 OpenSSL 1.1.0l (Debian)      TLSv1.1 AES256-SHA, No FS
 OpenSSL 1.1.1d (Debian)      No connection
 Thunderbird (68.3)           TLSv1.1 AES256-SHA, No FS


 Rating (experimental)

 Rating specs (not complete)  SSL Labs's 'SSL Server Rating Guide' (version 2009q from 2020-01-30)
 Specification documentation  https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide
 Protocol Support (weighted)  0 (0)
 Key Exchange     (weighted)  0 (0)
 Cipher Strength  (weighted)  0 (0)
 Final Score                  0
 Overall Grade                T
 Grade cap reasons            Grade capped to T. Uses SHA1 algorithm
                              Grade capped to T. Issues with the chain of trust (chain incomplete)
                              Grade capped to M. Domain name mismatch
                              Grade capped to F. Vulnerable to ROBOT
                              Grade capped to C. TLS 1.2 is not offered
                              Grade capped to B. TLS 1.1 offered
                              Grade capped to B. TLS 1.0 offered
                              Grade capped to B. Forward Secrecy (FS) is not supported
                              Grade capped to A. Does not support TLS_FALLBACK_SCSV
 Grade warning                Secure renegotiation is not supported

 Done 2020-07-07 15:54:21 [ 958s] -->> 192.168.1.107:443 (192.168.1.107) <<--
@ChrisTruncer
Copy link
Contributor

First off, I'd love to congratulate you on probably the most detailed bug report we have ever received. It is super helpful to see all the information that you provided, so thank you.

I do have one question, if you use EyeWitness to scan other sites, do they work?

As for why you might be seeing the screenshot but not in the report, EyeWitness makes two requests to each web page in order to generate the report. One request attempts to capture the screenshot, the other captures the source code, headers, etc. It's possible that the screenshot part is working (it's using firefox headlessly to capture it), but the python request to capture the other information is what is failing and therefore resulting in that being shown in the report.

@BeanBagKing
Copy link
Author

Yes, EyeWitness can scan other sites, report populates as expected. I just tried a different kind of IoT'ish device and got a screenshot (still going through Burp as well). Exact command was:

/EyeWitness.py --single 10.10.10.244 --proxy-ip 127.0.0.1 --proxy-port 8080 --timeout 240

I'm playing with python requests for other scripts (I have an idea for using ssdeep to identify same systems even if the page is slightly different, I was tossing around how EyeWitness might leverage it). Requests do seem to work for me, so long as you use verify=false, e.g.

page = requests.get('https://192.168.1.107', verify=False)

@BeanBagKing
Copy link
Author

Got it to work, sort of. I didn't realize when i posted my comment above you were using urllib.requests, not the requests library, so the verify false won't work. It does look like you're using the equivalent for urllib.requests though (about line 191).

First, I traced the problem back to selenium_module.py, this part here, and note the debug stuff I inserted:

# Starting at line 222 in selenium_module.py
    except urllib.error.URLError as e:
        if '104' in str(e.reason):
            headers = {'Error': 'Connection Reset'}
            http_object.error_state = 'ConnReset'
            return http_object, driver
        elif '111' in str(e.reason):
            headers = {'Error': 'Connection Refused'}
            http_object.error_state = 'ConnRefuse'
            return http_object, driver
        elif 'Errno 1' in str(e.reason) and 'SSL23' in str(e.reason):
            headers = {'Error': 'SSL Handshake Error'}
            http_object.error_state = 'SSLHandshake'
            return http_object, driver
        elif 'Errno 8' in str(e.reason) and 'EOF occurred' in str(e.reason):
            headers = {'Error': 'SSL Handshake Error'}
            http_object.error_state = 'SSLHandshake'
            return http_object, driver
        else:
            print("------- e printed below ---------")  # I inserted some debug code here
            print(e)
            print("------- headers printed below ---------")
            print(headers)
            headers = {'Error': 'HTTP Error...'}
            http_object.error_state = 'BadStatus'
            return http_object, driver

I don't think the full dump from headers is really useful, but if you want it, I'll be happy to post it. The error though was

<urlopen error [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol (_ssl.c:1108)>

Ok, odd for something going through Burp, Burp should have added all it's own protocols and corrected for this. however, I knocked the settings in /etc/ssl/openssl.cnf down to TLSv1.0 and re-ran EyeWitness. New error this time:

<urlopen error [SSL: BLOCK_CIPHER_PAD_IS_WRONG] block cipher pad is wrong (_ssl.c:1108)>

At this point, I'm convinced something is wrong with Burp. I ran the latest testssl.sh script with the --proxy flag to send it through Burp. I definitely see new protocols and cipher suites that weren't there before. We have SSLv3 all the way to TLSv1.2, we also have triple DES ciphers, AEAD ciphers, etc. that weren't there yesterday, nothing looks wrong with Burp:

 Testing protocols via sockets except NPN+ALPN 

 SSLv2      not offered (OK)
 SSLv3      offered (NOT ok)
 TLS 1      offered (deprecated)
 TLS 1.1    offered (deprecated)
 TLS 1.2    offered (OK)
 TLS 1.3    not offered and downgraded to a weaker protocol
 NPN/SPDY   not tested as proxies do not support proxying it
 ALPN/HTTP2 not tested as proxies do not support proxying it

 Testing cipher categories 

 NULL ciphers (no encryption)                      not offered (OK)
 Anonymous NULL Ciphers (no authentication)        not offered (OK)
 Export ciphers (w/o ADH+NULL)                     not offered (OK)
 LOW: 64 Bit + DES, RC[2,4], MD5 (w/o export)      not offered (OK)
 Triple DES Ciphers / IDEA                         offered
 Obsoleted CBC ciphers (AES, ARIA etc.)            offered
 Strong encryption (AEAD ciphers) with no FS       offered (OK)
 Forward Secrecy strong encryption (AEAD ciphers)  offered (OK)

New theory at this point is that the first request you mentioned (for the screenshot) is being proxied, but the request for headers and other information is not being proxied. In digging for a way to manually add that for testing, I notice that urllib will automatically respect proxy settings set by environment variable. So I set the following:

export REQUESTS_CA_BUNDLE="/home/user/Documents/Burp_CA_Cert.pem"
export HTTP_PROXY="http://127.0.0.1:8080"
export HTTPS_PROXY="http://127.0.0.1:8080"
export PYTHONWARNINGS="ignore:Unverified HTTPS request"

Rerun EyeWitness, and everything seems to work!

It seems like the root cause is the second python request not respecting the proxy settings. It looks like someone can manually overcome this by setting both the proxy settings when starting EyeWitness (for the screenshot) and the proxy settings in environment variables (for the other information).

ChrisTruncer added a commit that referenced this issue Jul 9, 2020
@ChrisTruncer
Updated urllib.requests to respect proxy settings if set, fix for #488
6a5c10f
@ChrisTruncer
Copy link
Contributor

Pushed a fix for this, thanks for reporting this to us!

@BeanBagKing
Copy link
Author

Sorry, just now getting around to testing out the changes and found one problem. It looks like it's trying to treat the cli_parsed.proxy_port as an int, and then trying to concatenate that with the string:

Traceback (most recent call last):
  File "/usr/lib/python3.8/multiprocessing/process.py", line 315, in _bootstrap
    self.run()
  File "/usr/lib/python3.8/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "./EyeWitness.py", line 283, in worker_thread
    http_object, driver = capture_host(
  File "/home/itss/EyeWitness/Python/modules/selenium_module.py", line 205, in capture_host
    req.set_proxy(cli_parsed.proxy_ip + ':' + cli_parsed.proxy_port, 'http')
TypeError: can only concatenate str (not "int") to str

Wrapping the port in a str() seems to work, but there may be better ways to do this:

        if cli_parsed.proxy_ip is not None:
            req.set_proxy(cli_parsed.proxy_ip + ':' + str(cli_parsed.proxy_port), 'http')
            req.set_proxy(cli_parsed.proxy_ip + ':' + str(cli_parsed.proxy_port), 'https')

@ChrisTruncer
Copy link
Contributor

Yup, you were right, I didn’t handle that correctly. I just pushed in the fix for that too.

Thanks!

shoeper pushed a commit to shoeper/EyeWitness that referenced this issue Jul 21, 2020
@ChrisTruncer @shoeper
Updated urllib.requests to respect proxy settings if set, fix for Red…
469e7b2 
…Siege#488
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ChrisTruncer @BeanBagKing