Miranda NG Security / Verification of the app and plugins

[nguser]

Hello.

According to my firewall, http protocol is used to download the application and plugins updates. Plugin updater wiki says that hash (not signature) is used for verification, which is again provided via http.

I believe that this is a classical MITM vulnerability. An attacker may spoof the update files to arbitrary code just by controlling victims' network (for example: public wi-fi created by an attacker; cracking vulnerable version of wi-fi; cracking vulnerable router; ISP-sided attacker, etc.)

Dear Miranda NG developers, could you please fix this vulnerability? Or may be there is an additional undocumented integrity verification built in the software?

[Wishmaster]

Yea, there is also a ticket here. Basic problem is that we don't have certiflicates for HTTPS. Implementing it in PluginUpdater would be easy if we would have it.

[nguser]

Got it. However there is a way of evading MITM even without (or in addition to) getting a signed SSL certificate - it's GPG signing. It's free and even more secure than ssl, cause if an attacker compromises the update server, he won't be able to sign the spoofed software with the developer's key.

You may add GPG support fairly quickly in manual manner - just by generating developer's private key and creating signature files to all binary files you're hosting. Users with gpg4win installed may then verify them manually. As an example, there is an instruction of verifying signed files for windows users of Tor software: https://www.torproject.org/docs/verifying-signatures.html.en

In addition, there are plenty of googlable instructions of implementing GPG signing and verifying in automated manner, depending on which environment/framework you are using.

I'm not a coder however, but I can help with manual signing thing and writing instructions for users in Russian and (broken)English.
Please let me know and if such help is needed and specify who to contact.

[Vulpix]

Basic problem is that we don't have certiflicates for HTTPS. Implementing it in PluginUpdater would be easy if we would have it.

https://letsencrypt.org/ , would that work?

[Wishmaster]

nguser, Vulpix, , You would have to contact watcher for the compilation process and Kxepal for https support on miranda-ng.org (they both speak russian).

I'm just a developer, not an admin.

I do not see how GPG signing prevents a man-in-the-middle attac, if signatures and files are hosted on the same server.

[nguser]

You would have to contact watcher for the compilation process

OK, thanks, I will.

I do not see how GPG signing prevents a man-in-the-middle attac, if signatures and files are hosted on the same server.

It will help to all the users who previously downloaded non-compromised software and signature files. Their local GPG software will store the original developer's public key, so downloading a spoofed software update will cause a verification error.

Of course, completely new users who could be attacked on the first download are not protected in this scenario, but GPG signing is still better than nothing.

[AnrDaemon]

Avoiding MITM attack is not an one-step action.
It is a complex of actions that in succession lead to a consistent and secure information exchange.
Binaries needs to be signed (it's rather easy) and timestamped (a little harder, but still doable).
I'm using https://www.universign.eu/en/api/timestamping/ and https://support.comodo.com/index.php?/Knowledgebase/Article/View/68/0/time-stamping-server for stamping.
A signing key must be verifyable through trusted connection.
Of course, if you don't want to go full signing, then at least hash list needs to be accessible through trusted connection.

[AnrDaemon]

As an example study, there's FAQ entry from Cygwin project: http://cygwin.com/faq.html#faq.setup.install-security

[Kxepal]

Hi,

HTTPS is in plans. Actually, @watcher already gave me a SSL certificate, I need to recall what the problems I had last time with it and we can cover some important bits with it.
LetsEncrypt is a good step forward and I really would like to use it instead. So far there are quite enough of success stories, highlighted problems and alternative tools, so that wouldn't be a pathfinder problem.

As for GPG, this is a question for core dev team. I think it's good call to sign Miranda NG binaries. IIRC Windows provides own way to sign executable/files, but I'm not aware about cost of that feature and how it works.

[Kxepal]

I do not see how GPG signing prevents a man-in-the-middle attac, if signatures and files are hosted on the same server.

It doesn't prevents MitM indeed, but it makes impossible to forge your signature. If signature verification failed -> binary is not trusted, all is simple. You need to store your public key on various key servers indeed, to prevent MitM them as well.

[AnrDaemon]

If letsencrypt can provide certificate with necessary OID's, the cost is nothing.
I.e.

this certificate

Code: [Select]

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 18 (0x12)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=RU, L=Moscow, CN=Andrey Repin/emailAddress=anrdaemon@rootdir.org
        Validity
            Not Before: Feb  5 02:58:22 2015 GMT
            Not After : Feb  6 02:58:22 2016 GMT
        Subject: C=RU, L=Moscow, CN=Andrey Repin
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (1024 bit)
                Modulus:
                    00:d6:28:cf:1d:63:ea:05:b8:ba:b0:07:4e:ba:0b:
                    70:3e:1f:f3:87:10:dd:b4:cb:bd:22:9e:72:a2:62:
                    47:03:1c:67:f7:d2:b1:fc:c1:89:80:2a:16:7e:7b:
                    51:70:13:c7:33:6c:a2:a5:a3:e4:b9:0a:a4:98:73:
                    02:1f:ae:af:1a:f1:dd:56:e1:a4:fd:27:48:9f:44:
                    91:f9:1d:e5:ac:9e:27:b9:d0:41:e3:c7:ca:61:28:
                    4e:b6:5f:85:7d:2a:27:61:01:2e:6d:f7:fc:57:cc:
                    77:9e:83:f6:b9:76:67:5f:f9:0c:f1:50:12:3f:ee:
                    55:8c:82:b7:07:46:23:55:73
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature, Non Repudiation, Data Encipherment
            X509v3 Extended Key Usage:
                TLS Web Client Authentication, E-mail Protection, Code Signing
            X509v3 Subject Key Identifier:
                81:FA:6C:44:4A:68:FB:3B:51:79:D8:A8:B5:00:D4:A3:9D:30:47:89
            X509v3 Authority Key Identifier:
                keyid:4D:1E:89:9B:E7:9B:AA:75:2E:99:C9:AE:0C:B8:87:C0:D1:A4:05:63
                DirName:/C=RU/L=Moscow/CN=Andrey Repin/emailAddress=anrdaemon@rootdir.org
                serial:B5:1C:66:2B:1B:0A:E5:1E

            X509v3 Issuer Alternative Name:
                email:anrdaemon@rootdir.org
            Authority Information Access:
                CA Issuers - URI:https://ca.rootdir.org/

            X509v3 CRL Distribution Points:

                Full Name:
                  URI:https://ca.rootdir.org/ca.crl

[close]

is used to sign LiteStep modules built by me.

[AnrDaemon]

(copied from chat log) This is how I sign binaries (VS2013 Express) using a certificate.

Code: [Select]

@signtool.exe sign /a /n "Subject Name" /d "%DESC%" /du "%LINK%" /tr "http://timestamp.comodoca.com/rfc3161" /v %*%DESC% is a description added to the signature.
%LINK% is an URL to the module's web page with more info.
Certificate is installed in the system certificate store as "Personal" certificate, key stored without password, since I'm using this certificate only on one machine for one task. If anything goes wrong with it, revoke and repalce.
Root certificate is also installed, since I'm using private CA.