0x05 It is generally not recommended to do leaf certificate site certificate locking

Author: Slim蛟Dance

Keywords: IoT SSL/TLS

0x01 SSL Benefits

0x05 It is generally not recommended to do leaf certificate site certificate locking

Security enhancement, effectively counteracting the vast majority of man-in-the-middle attacks

● Some scenarios of man-in-the-middle attack

● HTTP hijacking

● DNS hijacking

● ARP spoofing

● Phishing WIFI

● Pseudo-base station

The main goal of TLS is to make SSL more secure and to make the protocol specifications more precise and perfect. This article uses SSL generally.

0x02 IoT Classification

The device ROM release is much more complex than the app release, so the certificate verification scenario complexity of the device is higher. First, abstract the device into two major categories

● General-purpose operating systems with built-in certificates, such as AndroidTV.
● The system does not have a pre-installed certificate real-time operating system (RTOS).

If the device is a first-class general-purpose operating system, it is easier to handle

● If the certificate is issued by a CA, it is sufficient to trust the system certificate, and it is best to also enable system partition protection.
● If the certificate is self-signed, in addition to trusting the system certificate, you only need to trust this self-signed certificate. Do not blindly trust all certificates just to get the business running. Some businesses may not have purchased certificates at the beginning of development, so the initial code● It was originally trusted all certificates, but later, after purchasing a formal certificate, I forgot to fix the certificate trust code. For example, before purchasing the certificate, curl used the -k parameter, but after purchasing the certificate, I forgot to remove this parameter uniformly.

 -k, --insecure Allow connections to SSL sites without certs (H)

If the device is a second-class RTOS, you first need to confirm whether it supports SSL and whether the business running on it requires SSL. If it is needed and supported, you can proceed by preparing the root certificate yourself.

0x03 Error Demonstration

0x02 has already demonstrated a simple SSL error, and now let's talk about another error development case.

Encountered the following error提示 when developing related to SSL, which is that the certificate verification failed.

curl_easy_perform failed: SSL peer certificate or SSH remote key was not OK

The project is in a hurry to go online, so use the methods suggested on the Internet to solve this error. It seems to solve the problem, but in fact, it leaves a security隐患.

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);

Because the verify parameter is set to 0, all certificate-related errors will be ignored at this time, which means that all certificates will be trusted. If an attacker performs certificate injection hijacking, he will be able to see plaintext communication, and SSL loses its original function.

#include <curl/curl.h>

CURLcode curl_easy_setopt(CURL *handle, CURLOPT_SSL_VERIFYPEER, long verify);

The effect after being hijacked is as follows, the communication information of the device is completely exposed to the attacker.

How did we quickly locate this vulnerability? Here is a recommendation for Xiaomi's security development MiEye automation IoT security testing system, which can completely capture such vulnerabilities.

https://eye.dun.mi.com/

Finally, summarize this kind ofIncorrect operation:

● curl uses the -k parameter
● wget uses the --no-check-certificate parameter
● In libcurl, set CURLOPT_SSL_VERIFYPEER and CURLOPT_SSL_VERIFYHOST to false
● Override the checkServerTrusted method in the X509TrustManager class without performing certificate chain verification, which is commonly expressed by setting this method to empty
● Trust all hostnames setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);

0x04 Solve the problem

The above incorrect operation will make the device be at security level 0, it is recommended that IoT devices should be at level 2 or 3 according to the business.

Although this article is not purely theoretical, for the convenience of everyone to grasp the key points, some basic knowledge points are still mentioned. The SSL handshake process (RSA) is shown in the figure below, and the negotiation details are slightly different due to the different key exchange algorithms used, but the overall is similar

The key to the trust chain: the common root certificate of both parties ensures the reliability of the key negotiation.

Similarly, the key to using the API is the certificate handling process.

The correct SSL certificate verification settings are as follows, it is the default setting, and if you want to modify it, you need to be veryCautious.

curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 1L);
curl_easy_setopt(curl, CURLOPT_SSL_VERIFYHOST, 2L);

If there is no corresponding root certificate in the device, it is necessary to find the root certificate of the corresponding domain name first, which can be observed through the browser. For example, in this case, the certificate is from Godaddy. Then download the Godaddy Root Certificate Authority - G2 root certificate and embed it in the device.

Download address of Godaddy root certificates: https://ssl-ccp.godaddy.com/repository?origin=CALLISTO

If the certificate obtained by referring to the method in the curl documentation is a site certificate with a shorter validity period, and the release cycle of IoT devices is long, it is easy to cause a decrease in availability. Therefore, this article has always focused on root certificates.

Note: The certificate obtained by the following command is a site certificate with a shorter validity period rather than a root certificate.

openssl s_client -servername www.example.com -connect www.example.com:443 < /dev/null | sed -n "/-----BEGIN/,/-----END/p" > www.example.com.pem

Of course, a device may access many domains, and then it is necessary to pre-prepare many root certificates. Assuming another commonly used root is DigiCert, go to DigiCert to download the corresponding root certificate and embed it in the device.

Download address of DigiCert root certificates: https://www.digicert.com/digicert-root-certificates.htm

A root certificate can be specified using CURLOPT_CAINFO.

   CURLOPT_CAINFO - path to Certificate Authority (CA) bundle

In addition, there are similar certificates such as aosp.pem, apple.pem, microsoft.pem, java.pem, and mozilla.pem as supplements. The built-in certificates of Firefox are as follows

https://wiki.mozilla.org/CA/Included_Certificates

You can append missing certificates to the certificate list, or consider using Mozilla's certificate list directly

cat newcert.pem >> /etc/pki/tls/certs/ca-bundle.crt

You can also use CURLOPT_CAPATH to specify the corresponding root certificate directory, and if multiple CAs need to be added, consider it (new)

CURLOPT_CAPATH - specify directory holding CA certificates

   #include <curl/curl.h>

   CURLcode curl_easy_setopt(CURL *handle, CURLOPT_CAPATH, char *capath);

0x05 It is generally not recommended to do leaf certificate site certificate locking

SSL pinning adds new anti-scenario:

The client installs a malicious certificate, and such a scenario is extremely rare on IoT devices.
- ● Some Wi-Fi requires you to add root certificate trust to use the internet
- ● Some websites require you to add root certificate trust to avoid repeated red cross prompts
Other CAs maliciously issued site certificates
- ● WoSign and Symantec have both had a period of time when the certificates issued were not trustedhttps://news.mindynode.com/zh/events/50 (including StartCom and CNNIC)

The most common is to use HTTPS with SSL and TLS for encryption in communication, and then perform http transmission. In addition to http, SSL/TLS can also protect other protocols such as FTP, IMAP, POP3, SMTP, etc.

However, it is generally not recommended to use CURLOPT_PINNEDPUBLICKEY, and other libraries are similarly not recommended to do site certificate locking on IoT devices. It has also been mentioned before that the validity period of site certificates is too short, while the release cycle of IoT devices is long, and it is extremely cost-effective to implement a reliable certificate fingerprint update scheme. A slight mistake can lead to business unavailability.

NAME
       CURLOPT_PINNEDPUBLICKEY - set pinned public key

SYNOPSIS
       #include <curl/curl.h>

       CURLcode curl_easy_setopt(CURL *handle, CURLOPT_PINNEDPUBLICKEY, char *pinnedpubkey);

The document does not mention support for intermediate & root certificate pin, so the locking built into curl only supports leaf certificate pinning

https://curl.haxx.se/docs/todo.html

13.11 Support intermediate & root pinning for PINNEDPUBLICKEY
CURLOPT_PINNEDPUBLICKEY does not consider the hashes of intermediate & root certificates when comparing the pinned keys. Therefore, it is not compatible with 'HTTP Public Key Pinning' as there can also be intermediate and root certificates pinned. This is very useful as it prevents webadmins from 'locking themselves out of their servers'.

For more details on certificate pinning, refer to my other articleSSL.Pinning.Practice