Tencent Security Center · 2014/02/24 15:45

0 x00 preface

In the middle of October last year, Tencent security Center found in the routine terminal security audit that the vast majority of APPS using HTTPS communication on the Android platform did not securely use the API provided by Google, which directly led to the leakage of sensitive information in HTTPS communication and even remote code execution. After audit, the terminal security team found that this vulnerability exists in some Tencent products and 13 mainstream apps selected in the industry.

In addition, through this loophole, we found that there are many deficiencies in dealing with security issues in the whole industry in China, such as lagging security intelligence, security warnings not getting due attention, and the lack of benign communication environment in the security industry. Tencent Security Center hopes to discuss and improve with industry peers and white hat through TSRC platform, so as to create a benign security ecological environment, improve the security of our products and bring better security guarantee to our users.

0x01 Principle Analysis

Google’s official documentation details several ways to use HTTPS on the Android platform. When developers use these codes to develop and test HTTPS functions of their own products, they will find many types of HTTPS exceptions. I believe that many experienced white hats have also encountered similar problems. Simply put, the root cause is that Google’s API checks HTTPS certificates for validity. HTTPS certificates in development or test environments generally fail the validity check.

The API check includes the following four aspects:

1. Check whether the signature CA is valid. 2. Check whether the domain names match. 3. Whether the certificate is self-signed; 4. Check whether the certificate expires.Copy the code

Once any exceptions are found, the request is terminated and the appropriate exception is thrown. What do you do in product development or testing? An audit by the end security team found that the vast majority of products overrode Google’s default certificate checking mechanism (X509TrustManager) to address this issue. A typical solution is as follows:

I’m sure many white hats have seen this code and figured out what the problem is: by overriding the default certificate checking mechanism, the onus is on our own code to check that the certificate is valid. However, the vast majority of apps, after choosing to override the default security mechanism, do not carry out the security check on the certificate, and directly accept all abnormal HTTPS certificates, without warning the user of the security risk, and do not terminate the dangerous connection. In fact, all web browsers now handle HTTPS exceptions and warn users of security risks. A typical reminder is shown in the following figure.

A similar problem can also be found in the HostnameVerifier (Certificate domain name checker) section, which is very similar to the above, so it will not be described here.

0x02 Malicious Scenario

To exploit this vulnerability, we need to be able to do traffic hijacking to intercept and modify the HTTPS handshake packet: replace the certificate issued by the server at the time of the handshake with our forged fake certificate. Then all of the HTTPS data is under our surveillance, and we can even tamper with the contents of packets if we want. Let’s look at a typical malicious scenario.

1. Fake public wifi for hijacking

One day, a hacker took his laptop full of “weapons” and activated aircrack, which had been prepared for a long time. He sat quietly in Starbucks for a whole afternoon. When the sun was setting, the hacker disappeared into the crowd with a cup of Starbucks coffee in his hand, hiding his achievements and reputation. Later, anyone who made an online purchase at Starbucks in the afternoon found that all the cash in their bank cards had been transferred without notice. This is not alarmist, this article discusses the loophole, can do exactly this effect. Dear friends, please refer to the following figure for our audit of the HTTPS vulnerability bound to an app credit card. All the credit card information (card number, validity period, CVV, password and verification code) is leaked. With this information, how difficult is it to steal your cash?

Technically, using sophisticated wifi forgery tools like Aircrack, hackers were able to create a wifi signal identical to starbucks’ official wi-fi signal. Ssids, MAC addresses, routing parameters, they can all be forged. For the average user, it’s impossible to tell whether the wifi in front of you is Starbucks or Chimpbak.

enter link description here

At the 2013 Taiwan Hacker Conference, the organizers set up a wifi “sheep wall” (i.e. collecting the passwords of people around through forged wifi) to remind people of the security of public wifi. Throughout the session, it caught a lot of passwords in plain text, including administrative passwords like phpMyAdmin (shown below).

So, friends, in an untrusted wifi environment, do not do sensitive operations. Or, just don’t use an app you don’t trust.

2. Traffic hijacking in other forms, such as man and DNS

Forgery of wifi is a relatively easy traffic hijacking scheme to implement. Although traffic hijacking, DNS request hijacking, routing link hijacking and other attacks at the exit of man are relatively difficult, once successfully implemented, their impact will be disastrous. Remember the DNS hijacking attack by Iranian hackers in 2010? What are the catastrophic consequences of the HTTPS vulnerability we discussed today?

0x03 Vulnerability Status

To understand the current situation of this vulnerability in the industry, we analyzed 13 Android apps that use HTTPS communication, all from major companies in the industry. Analysis results show that all 13 apps have sensitive information leakage vulnerabilities described above. In the leaked information, passwords in plain text, chat messages, credit card numbers and CVV numbers can be found everywhere. We even found the same problem with HTTPS communication used in the automatic upgrade process of some apps. After hijacking traffic and replacing the URL of the upgrade package, the app would download malicious upgrade package and automatically upgrade, directly causing remote code execution.

We believe that the vast majority of apps in the industry that use HTTPS have similar vulnerabilities. After the discovery of this vulnerability, we have immediately synchronized the technical details of the vulnerability to the National Internet Emergency Response Center (CNCERT) and the friends who discovered the vulnerability.

0 x04 afterword.

In the process of discovering, repairing and tracing the vulnerability, we found that the whole industry in China has many deficiencies in dealing with security issues.

1. Lagging security information

In the process of tracing the source, we found that this type of vulnerability has existed since the Java era, but it has not been widely spread. Then, with the use of DalviKVM Java VIRTUAL machine into the Android platform, it has been spread more and more widely with the popularity of Android. In foreign countries, CCS ’12 appeared the first systematic discussion of this vulnerability of Android platform 1. In September 2012, “Programmer” published “Android Software Security Development Practice” 2 first mentioned this kind of security problem. Google’s official API document 3 also warns that customized TrustManger must be implemented carefully, otherwise it may cause serious security problems.

However, it is a pity that these discussions have not been paid due attention by us and our peers in the industry. Even one year later, there are still a large number of such vulnerabilities in domestic APPS. CCS ’12 reports that 17.3% of Apps using HTTPS on Google Play have such vulnerabilities. According to statistics from audit colleagues of Tencent Security Center, the proportion of such security vulnerabilities in Domestic apps is much higher than that in foreign countries.

2. The security industry lacks a benign communication environment

In fact, whether at home or abroad, there are many superior white hats, do their best to contribute to the safety of the Internet environment, but their voice, often drowned in the ocean of Internet information. The power and influence of individuals is ultimately limited, and the white hats need a platform to make their voices heard, so that the security problems they find are given due attention and fixed as soon as possible. TSRC is an attempt of such a benign communication platform. Admittedly, we are not doing enough now, but we are always striving for this goal.

Tencent security center has the responsibility and obligation to give the majority of users a safe Internet environment. In the future, no matter the security intelligence or security team found security problems, we will immediately synchronize to the National Internet Emergency Response Center (CNCERT) and the affected friends, to help the industry counterparts to repair the security problems as soon as possible. TSRC also calls on the industry to put down the barriers between companies and organizations and work together to create a good communication environment.

Domestic security industry is a long way to go, Tencent security center with the whole industry together, we are on the road.

0x05 Related links

1 http://www2.dcsec.uni-hannover.de/files/android/p50-fahl.pdf 2 http://www.programmer.com.cn/15036/ 3 http://developer.android.com/training/articles/security-ssl.html

Hacking Storm: Android HTTPS sniffing for hijacking vulnerabilities