******** VU中的SSL漏洞＃582497 [英] SSL Vulnerability in ******** VU#582497

问题描述

最近收到一封警告信，表明我的应用安全受到威胁。

Recently received a warning letter that my application security threatened.

  ---------- Forwarded message ----------
    From: CERT Coordination Center <[e-mail]>
    Subject: SSL Vulnerability in ********* VU#582497
    Cc: [e-mail]

这封信包含以下信息：
我们最近一直在评估CERT Tapioca
http://www.cert.org/blogs/certcc/post.cfm?EntryID=203 使用SSL
由Android应用程序提供。通过自动化测试，我们正在记录
导致通过HTTPS连接发送或接收流量的应用程序，该连接具有
无效的SSL证书链。以下应用程序证明了这种不正确的行为。

The letter contains the following information: We've recently been evaluating with CERT Tapioca http://www.cert.org/blogs/certcc/post.cfm?EntryID=203 the use of SSL by Android apps. Through automated testing, we are logging apps that cause traffic to be sent or received over an HTTPS connection that has an invalid SSL certificate chain. The following application has demonstrated this incorrect behavior.

可能会影响测试结果影响的一些注意事项：

Some caveats that may affect the impact of the test results:

1）我们尚未调查通过无效SSL证书链通过HTTPS
发送的内容。如果信息不是
敏感信息，那么可能会认为该漏洞实际上不会对b $ b产生影响。但是，另一个论点是使用
未经验证的SSL是一个需要更正的漏洞，无论发送或接收的内容是什么，都是
。

1) We have not yet investigated the content that is sent over HTTPS with an invalid SSL certificate chain. If the information is not sensitive, one might argue that the vulnerability does not really have an impact. However, the other argument is that the use of unvalidated SSL is a vulnerability that needs to be corrected, regardless of the content sent or received.

2）可能是您的应用程序本身正确使用SSL，但是
包括第三方库，它本身会进行不正确的SSL
验证。在这种情况下，这个第三方库需要更新
。或者，如果修复程序不可用，则应通知库的作者
，让他们知道他们需要修复
库。

2) It could be that your application itself uses SSL properly, but it includes a third-party library that itself does improper SSL validation. In such a case, this third-party library would need to be updated. Or if a fix isn't available, the library's author should be notified to let them know that they need to fix the library.

3）由于动态测试中使用的UI自动化我们执行了b $ b，应用程序使用的应用程序或
浏览器组件很可能在之前正确警告
用户诉讼。如果UI自动化确实发生了点击
，即使证书无效也需要继续按钮，那么
这可能被视为误报。如果您认为这是
，请回复并告诉我们。

3) Due to the UI automation used in the dynamic testing that we performed, there is a small chance that the application or the browser components used by the application did correctly warn the user before proceeding. If the UI automation did happen to click the button required to proceed despite an invalid certificate, then this could be considered a false positive. If you believe this to be the case, please respond and let us know.

对于请求，我使用robospice-spring-android。 ssl用法：

For request, I use robospice-spring-android. ssl usage:

 static {
        try {
            SSLContext sslc = SSLContext.getInstance("TLS");
            TrustManager[] trustManagerArray = {new NullX509TrustManager()};
            sslc.init(null, trustManagerArray, null);
            HttpsURLConnection.setDefaultSSLSocketFactory(sslc.getSocketFactory());
            HttpsURLConnection.setDefaultHostnameVerifier(new NullHostnameVerifier());
        } catch (Exception e) {
        }
    }

private static class NullX509TrustManager implements X509TrustManager {
        public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException {
        }

        public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {
        }

        public X509Certificate[] getAcceptedIssuers() {
            return new X509Certificate[0];
        }
    }

    private static class NullHostnameVerifier implements HostnameVerifier {
        public boolean verify(String hostname, SSLSession session) {
            return true;
        }
    }

任何人都可以就此问题提出建议。我的错是什么？

Can anyone suggest on this issue. What is my fault?

推荐答案

任何人都可以就此问题提出建议。我的错是什么？

Can anyone suggest on this issue. What is my fault?

您可以有效地禁用TLS内置的任何类型的身份验证。因此，攻击者可以轻松地发起中间人攻击或网络钓鱼攻击，即侦听和操纵加密流量或声称是真实服务器。

You effectively disable any kind of authentication built into TLS. An attacker can thus easily mount a man-in-the-middle attack or a phishing attack, that is listen to and manipulate the encrypted traffic or claim to be the real server.

通常可以通过本地局域网或公共WLAN内的ARP或DHCP欺骗轻松完成，因此所描述的问题不是理论问题，而是实际问题。

Such can usually easy be done with ARP or DHCP spoofing inside the local LAN or a public WLAN, so the problem described is not a theoretical but a real problem.

详细信息：

        TrustManager[] trustManagerArray = {new NullX509TrustManager()};
        sslc.init(null, trustManagerArray, null);

在此处，如果证书由受信任的CA签名，则禁用检查。攻击者现在可以使用任何自签名证书或由不受信任的CA签署的证书而不是真实证书。

Here you disable the check if the certificate is signed by a trusted CA. The attacker can now use any self-signed certificate or a certificate signed by an untrusted CA instead of the real one.

        HttpsURLConnection.setDefaultHostnameVerifier(new NullHostnameVerifier());

在此处禁用检查以针对您要访问的主机验证证书中的主机名。示例：

Here you disable the check to verify the hostname inside the certificate against the host you want to access. Example:

• 您要访问的网站是super-secure.example并且您为其购买了证书


• 攻击者拥有site attacker.example并为其购买了证书

通常客户端将验证该名称证书与客户端连接的名称匹配。但是您使用上面的代码明确禁用了此检查，因此攻击者证书被接受。

Usually the client will verify that the name in the certificate matches the name the client connected to. But you explicitly disabled this check with the code above and thus the attackers certificate gets accepted.

您的主要错误可能是您刚从某处复制了一些代码而未了解它是什么确实。在任何情况下都是错误的想法，尤其是与安全相关的任何事情。

You main fault is probably that you just copied some code from somewhere without understanding what it does. Bad idea in any case, but especially for anything related to security.

这篇关于******** VU中的SSL漏洞＃582497的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！