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.

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

[Security][SSL] Self signed certificate seems to be always accepted. #3283

Closed
jklmnn opened this issue May 26, 2015 · 15 comments
Closed

[Security][SSL] Self signed certificate seems to be always accepted. #3283

jklmnn opened this issue May 26, 2015 · 15 comments
Labels
p2-high Escalation, on top of current planning, release blocker Security

Comments

@jklmnn
Copy link

jklmnn commented May 26, 2015

Expected behaviour

When a self signed certificate is used and the warning is shown, clicking Cancel should not build up a connection.

Actual behaviour

When the warning is shown, a connection is build up, even if you have clicked Cancel.

Steps to reproduce

  1. Run ownCloud desktop client.
  2. Intercept traffic and set up mitm attack.
  3. Wait for certificate warning and click Cancel.
  4. See traffic in mitm.

Server configuration

Operating system: Debian 8.0

Web server: Apache 2.4

Database: Sqlite 3.8

PHP version: 5.6

ownCloud version: 8.0.3

Storage backend: SQLite

Client configuration

Client version: 1.8.1+dfsg-1

Operating system: Debian Stretch

OS language: German

Installation path of client: /usr/bin/owncloud

@LukasReschke
Copy link
Member

@jklmnn Thanks for reporting this issue back to us. Generally speaking please always contact security@owncloud.com in case of a potential security bug. For now we will handle this one public though.

cc @danimo Can you take a look? THX.

@danimo
Copy link
Contributor

danimo commented May 26, 2015

@jklmnn I've just tried your steps to reproduce (although with our package repo, and on Ubuntu 14.04), but I have not been able to get any data transferred to mitmproxy so far. @LukasReschke will give it another try.

@LukasReschke LukasReschke self-assigned this May 26, 2015
@danimo
Copy link
Contributor

danimo commented May 26, 2015

@jklmnn Are you using bandwidth limiting? Does this link against Qt4 or Qt5?

@jklmnn
Copy link
Author

jklmnn commented May 26, 2015

I'm not using a bandwith limit, and it's linking against Qt5.

@jklmnn
Copy link
Author

jklmnn commented May 26, 2015

I examined it further and it does not appear if the connection was mitmed before owncloud was started. when you start the client and cancel the certificate it shows an ssl error (as expected). But when you already have a connection that is getting hijacked then the new certificate will be used, either if you accepted it or not.

@LukasReschke
Copy link
Member

Couldn't reproduce as well. What I did:

  1. Install Debian 8.0 without any GUI
  2. Login
  3. Install Gnome using tasksel install gnome-desktop --new-install
  4. Reboot
  5. sudo su
  6. apt-get install owncloud-client
  7. Start the ownCloud client (owncloud --logwindow) and connect against a HTTPS protected host
  8. Try to sync files: Works
  9. Install Ettercap on another machine: apt-get install ettercap-graphical
  10. Edit /etc/ettercap/etter.conf and change ec_uid and ec_gid to 0, also comment out the redir_command_on and redir_command_off iptable rules
  11. sysctl -w net.ipv4.ip_forward=1 + echo 1 > /proc/sys/net/ipv4/ip_forward
  12. Start ettercap, the first IP is the gateway IP the later the IP of the Debian host with ownCloud client: ettercap --text -i eth0 --mitm arp:remote //10.211.55.1// //10.211.55.17// -a /etc/ettercap/etter.conf
  13. Wait a little bit till it is in effect, see certificate warning -> Click cancel

Following error appears in the log output:

05-27 16:41:42:646 void Mirall::AbstractNetworkJob::slotFinished() 6 "SSL handshake failed" 
05-27 16:41:42:647 SSL-Errors happened for url  "https://cloud.ostsinn.ch/remote.php/webdav/" 
05-27 16:41:42:647  Error in  QSslCertificate( "3" , "e7:81:df:a0:09:6b:5d:1c:52:d1:90:b9:8a:da:55:a2" , "vqXftJTVqleg4Dj9HPh48Q==" , "COMODO CA Limited" , "" , QMap() , QDateTime("Thu Apr 2 00:00:00 2015") , QDateTime("Sun Apr 1 23:59:59 2018") ) : "The host name did not match any of the valid hosts for this certificate" ( "The host name did not match any of the valid hosts for this certificate" ) 
05-27 16:41:42:648  Error in  QSslCertificate( "3" , "e7:81:df:a0:09:6b:5d:1c:52:d1:90:b9:8a:da:55:a2" , "vqXftJTVqleg4Dj9HPh48Q==" , "COMODO CA Limited" , "" , QMap() , QDateTime("Thu Apr 2 00:00:00 2015") , QDateTime("Sun Apr 1 23:59:59 2018") ) : "The issuer certificate of a locally looked up certificate could not be found" ( "The issuer certificate of a locally looked up certificate could not be found" ) 
05-27 16:41:42:648  Error in  QSslCertificate( "3" , "e7:81:df:a0:09:6b:5d:1c:52:d1:90:b9:8a:da:55:a2" , "vqXftJTVqleg4Dj9HPh48Q==" , "COMODO CA Limited" , "" , QMap() , QDateTime("Thu Apr 2 00:00:00 2015") , QDateTime("Sun Apr 1 23:59:59 2018") ) : "The root CA certificate is not trusted for this purpose" ( "The root CA certificate is not trusted for this purpose" ) 
05-27 16:41:42:649  Error in  QSslCertificate( "3" , "e7:81:df:a0:09:6b:5d:1c:52:d1:90:b9:8a:da:55:a2" , "vqXftJTVqleg4Dj9HPh48Q==" , "COMODO CA Limited" , "" , QMap() , QDateTime("Thu Apr 2 00:00:00 2015") , QDateTime("Sun Apr 1 23:59:59 2018") ) : "No certificates could be verified" ( "No certificates could be verified" ) 
05-27 16:41:42:649 Certs not trusted by user decision, returning. 
05-27 16:41:42:650 void Mirall::AbstractNetworkJob::slotFinished() 6 "SSL handshake failed" 
05-27 16:41:42:653 Sync state changed for folder  "ownCloud" :  "Not availabe" 
05-27 16:41:42:653 SocketApi:  Broadcasting to 0 listeners:  "UPDATE_VIEW" 

ettercap is not receiving any further requests.

@jklmnn Would it possible to provide more detailled reproduction steps? Thanks.

@jklmnn
Copy link
Author

jklmnn commented May 28, 2015

I will describe how I have set up the network. I can give you further logs when I'm back at home.

  1. I have one PC with Debian 8.0 installed which is my router. tun0 goes to a VPN and eth1 creates a local network. I'll call this one router.
  2. On the router mitmproxy is installed aptitude install mitmproxy.
  3. The PC with the owncloud client (let's call it just client) has installed Debian testing/strech with KDE.
  4. Installed owncloud client from deb http://download.opensuse.org/repositories/isv:/ownCloud:/community/Debian_8.0/ / aptitude install owncloud-client owncloud-client-l10n
  5. Start owncloud client owncloud (I didn't have logs this time), login and sync
  6. Set up iptables on router iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 443 -j REDIRECT --to-port 8080
  7. Start mitmproxy on router mitmproxy -T --host (starts by default on *:8080)
  8. See certificate warning and click cancel (since it's german i clicked "Abbrechen", idk if this has any relevance)
  9. Wait for owncloud client to connect and sync, view syncs in mitmproxy.

When I get back home (I think this weekend), I'll give you logs, screenshots and more detailed info.

@LukasReschke
Copy link
Member

I performed your steps as well and still experience the expected behaviour. Mitmproxy does not show any requests originated to that host and the ownCloud client fails hard. See attached video:

2015-05-28 16_46_58

@LukasReschke
Copy link
Member

Left: The host that acts as gateway running mitmproxy as well as Wireshark.
Right: The client system.

@jklmnn
Copy link
Author

jklmnn commented May 29, 2015

Here's my screen record: http://jkliemann.de/media/owncloud.ogv
I hope, it's ok, I'm not a master in screen records.

@LukasReschke
Copy link
Member

Interesting. We have some suspicions and to prove those we would really welcome if you could provide us with a test account to your instance as well as the public certificate of the CA that you installed on your system.

Would that be something you could do? – Non-admin account would be fine. My mail address can be found in my profile.

@jklmnn
Copy link
Author

jklmnn commented May 29, 2015

I have contacted you.

@LukasReschke
Copy link
Member

Thanks, @jklmnn for the access credentials. Our investigation has showed that in case of a self-signed certificate that got imported in the client this behaviour can indeed be reproduced.

To be exploitable the following scenarios needs to be fulfilled:

  1. When initially connecting to ownCloud with a self-signed certificate the certificate gets imported into the ownCloud client.
  2. When MITMing the connection and the victim clicks cancel the ownCloud client will ignore this and continue syncing normally

@jklmnn Can you confirm that /home/USERNAME/.local/share/data/ownCloud/owncloud.cfg contains an entry such as the following:

General\CaCertificates="@ByteArray(-----BEGIN CERTIFICATE-----\nMIIFRjCCAy6gAwIBAgICEAEwDQYJKoZIhvcNAQENBQAwcTELMAkGA1UEBhMCREUx\nEDAOBgNVBAgMB1NhY2hzZW4xEDAOBgNVBAcMB0RyZXNkZW4xJjAkBgNVBAoMHXh5\ndWN0IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MRYwFAYDVQQDDA14eXVjdCBSb290\nIENBMB4XDTEzMTEwMzA5MzcwN1oXDTIzMTEwMTA5MzcwN1owYTELMAkGA1UEBhMC\nREUxEDAOBgNVBAgMB1NhY2hzZW4xEDAOBgNVBAcMB0RyZXNkZW4xEjAQBgNVBAoM\nCUpLbGllbWFubjEaMBgGA1UEAwwRSm9oYW5uZXMgS2xpZW1hbm4wggEiMA0GCSqG\nSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4uS4zK6GimXwNeUtOnXjH0UHHMBTHiRhR\nOEy2wCaosj5kENMZy1NefgrKHmNpMHnBihRJkWKMjET//h5m/FLsMfjHXgJnpdVK\nzBi5kpCoMMPvrjlp3gj+MJG3/80sOCvXLHgTiHS07er9cr1GGOEBl9jGeTIIhTwC\n1QNhCdisEvJGXJKvcBXe8sH+lnYADDT8k4o8Z4u/+5rKMUppNmsFuzL8aTZMhLkR\nv/MdcV+nV5PhETdguND51FJViGO9ExDGfosodytisC6obc+A9qsnPsHpP7bm5HL8\nsNgKZ24uSQ/gp5gBsa20vfUxuV45a1XY6owYqWmtbr/7ntqsm3irAgMBAAGjgfcw\ngfQwHQYDVR0OBBYEFMDzCI52+gnN8jQ/fRbYOLGg3ULYMIGjBgNVHSMEgZswgZiA\nFC/L/2dqBKmYrs/QlDf4vy4Bwb8xoXWkczBxMQswCQYDVQQGEwJERTEQMA4GA1UE\nCAwHU2FjaHNlbjEQMA4GA1UEBwwHRHJlc2RlbjEmMCQGA1UECgwdeHl1Y3QgQ2Vy\ndGlmaWNhdGlvbiBBdXRob3JpdHkxFjAUBgNVBAMMDXh5dWN0IFJvb3QgQ0GCCQC/\nYfJgQZCwSTASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBBjAJBgNV\nHREEAjAAMA0GCSqGSIb3DQEBDQUAA4ICAQB7x3TeL+wbqVFvZcsbrKx9PZdndg6W\nSepgNmYqfiE5pBNlRu5BZgb1A/b/KmCzqsRTJDJxqG1i4KOAqRkppS34sVNPwoma\nfBVV18QVWLUTTipNYlN6cKN3wKPWOUEgK6lWH5H/7QiEAeTNwYQ67bDK7LCioPrE\ndRu9BrIN6oCdzT9HBr7Ms9J5X9OODzQbKnPu+IjFVZJZBfHvs1NYV0TYCwLpT/Gu\nyYJy1cDid991xHSThS262Ps/pOzv27vOXTet+M3o/e4SWU5QWPwwf+pCG5kBri2R\nm0R+Qn1diNdwl1k+rP2lL5aB69AWK+oTTv4wfRaWCAEG6E5yKhuXukNCzZhse7kV\nbLc7OmNmICbJ2BB6p+wCdJqHpWYIUOIRCrhNeAvYe9IL3JHLblOtvqtQcFo0V1+D\n1gz3y0elxGb2gOsUcyhJQaC5+w5GGt9I7rQkmAJQyk7XdS2Nuu7OMGNIhuPWjOSG\nkwWp4R2un5R8qSdvc2QtoRHjJ9l6hRUiLpO5GE+jvOMLxxuzWPtDVoq5g0L/52ab\nyno+dLzxu0X3DKxyQlONogFX8vbXa49JQ7uRdk3vdmvqWcUPUlPDONJEBl4iXeX5\nT+BT3WLTKwOKZGKR309QgAv98wq9Jve1iRuYZ/V9AjEZvMbqLtjV7Oc4Q4wpk/fD\n1asSZIou/WbE4Q==\n-----END CERTIFICATE-----\n\n)"

If so would you be able to remove this entry from your client and let us know if you if you experience the same behaviour if the certificate has been imported to the system instead? I were able to import it by putting it into /etc/ssl/certs/ and ran update-ca-certificates. After this no certificate warning should appear when trying to sync and MITM'ing the connection will not longer work. This should as short-term workaround be sufficient.

@cmonteroluque Please schedule this for the next client release. Security considers this as a critical security bug for deployments using self-signed certificates. – This needs to get fixed for all affected releases as soon as possible, I will push advisories as well as soon as we have determined the root cause (as we have a work around)

@jklmnn
Copy link
Author

jklmnn commented May 29, 2015

I had this line in my config and I can confirm that your workaround works.

@LukasReschke LukasReschke removed their assignment May 30, 2015
@dragotin dragotin added the p2-high Escalation, on top of current planning, release blocker label Jun 1, 2015
@dragotin dragotin added this to the 1.8.2 - Bugfix 2 milestone Jun 1, 2015
dragotin added a commit that referenced this issue Jun 2, 2015
ckamm added a commit to ckamm/owncloud-client that referenced this issue Jun 3, 2015
ckamm added a commit that referenced this issue Jun 3, 2015
@dragotin
Copy link
Contributor

dragotin commented Jun 3, 2015

A fix was merged, three people verified that the fix is working.

I am closing this directly instead of adding the ReadyToTest flag.

dragotin added a commit that referenced this issue Aug 14, 2015
This is supposed to fix bug #3283

(cherry picked from commit 75b38d1)
ckamm added a commit that referenced this issue Sep 18, 2015
ckamm added a commit that referenced this issue Sep 18, 2015
ckamm added a commit to ckamm/owncloud-client that referenced this issue Apr 27, 2017
I'm confident this is unnecessary. The original bug in owncloud#3283 was
to call ignoreSslErrors() without an argument in the 'accept'
case, which meant ignoring *all* subsequent SSL errors.

With that fixed, explicitly aborting the reply and resetting QNAM
is not needed since not ignoring the error will lead to the SSL
handshake failing.

See also:
  75b38d1 (workaround introduced)
  89376e1 (real fix)
  76ce5ad (cherry-pick of workaround)
ckamm added a commit that referenced this issue May 4, 2017
I'm confident this is unnecessary. The original bug in #3283 was
to call ignoreSslErrors() without an argument in the 'accept'
case, which meant ignoring *all* subsequent SSL errors.

With that fixed, explicitly aborting the reply and resetting QNAM
is not needed since not ignoring the error will lead to the SSL
handshake failing.

See also:
  75b38d1 (workaround introduced)
  89376e1 (real fix)
  76ce5ad (cherry-pick of workaround)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p2-high Escalation, on top of current planning, release blocker Security
Projects
None yet
Development

No branches or pull requests

4 participants