On September 15, 2018, Huawei senior technical expert Li Xinzhe shared the speech “Application Security FaQs and Solutions” in “From RESEARCH and Development to Testing: Hand in Hand to Teach you to Build Green Applications”. IT big said as the exclusive video partner, by the organizers and speakers review authorized release.

Read the words: 3315 | 9 minutes to read

To watch the video and PPT, please click t.cn/E2DtMQW

Abstract

This paper is divided into three parts. The first part will introduce the application status of Android, the second part is the common problems of Android (partial vulnerability), and the last part is the privacy security problem.

The state of Android Apps

First, let’s take a look at official statistics. After analyzing all mobile platforms, the National Internet Emergency Response Center found that Android users are the most vulnerable to attacks, with 99.9 percent of malicious apps being used. This is mainly due to the open source mechanism of Android itself, and in recent years, the number of Android users has increased year by year, so that we can see the benefits, thus attracting more and more attackers.

These are some data found in our internal audit. After careful investigation, we found that many applications generally have some vulnerabilities. A few apps will carry viruses and malicious behavior without their knowledge or intent.

Faqs and Solutions for Android applications

Next to introduce this year, we found some loopholes, holes are some inappropriate, actually it’s more like four attack surface, including components, url to bypass, man-in-the-middle attack, the Webview loophole, although it seems very simple, a few questions but including some mainstream APP on mobile phones are very common.

Component problems

The component problem, if only for a reason, has probably been around since android was built. Component exposure is a normal thing, but what is not normal is that many developers like to release unfinished code with the application, which they may feel is not relevant to other components or interfaces, so that users can’t touch them. But in practice, if component exposure is set up, attackers can easily attack the application, including invoking hidden functions, opening backdoors, denial of service, etc.

Component exposure, if it has permissions and is not protected (permissions are not just the traditional Google-defined high-permissions behavior), allows an attacker to do things without the user’s knowledge, like access the component and send a text message,

For example, I saw a financial APP before. Its design is to have a password input interface, which is similar to the protective lock. After the protection lock is verified successfully, private data such as financial information can be obtained. But if the second interface component is exposed, you can bypass validation without locking.

Here is an SDK problem found by certain social software this year. The problem, which was only fixed in July, was found in an audit of more than 14,000 apps on the social software, which has several hundred million users.

The problem was a shared SDK with two exposed components, one of which had a vulnerability that allowed an attacker to access any private component of the app, bypassing Google’s sandbox. A vulnerability in another component not only allows access to private components, but also allows parameters to be passed to components. They cause two main problems, denial of service and invocation of unauthorized interfaces (or even backdoors).

URL bypass problem

URl bypass problem can only be said to be the attack surface, not vulnerability. First of all, there is a path traversal vulnerability. In the case of common problems, applications or SDK use path URL as parameter in a large number of cases, if the validity of the path is not verified, it is easy to cause this problem. The most typical path traversal vulnerability on Android is ZipEntry URl path traversal, which is the same as the traditional Web.

Another problem is url whitelist bypass, with the increase of networking applications, we all like to use webviwe component to load a web page, it needs to load THE URL, and the WebVIwe component itself is very much the problem, there are a lot of sensitive behavior in its permissions, such as obtaining geographic location information.

When using webView, most developers do not want the component to load any web page, so they will implement a whitelist function to restrict the loaded web page. Common constraint functions include contains(), indexOf(), endWith (), getHost(), etc. Since the constraint mechanism is artificially implemented, Therefore, there will be an element of insecurity.

Possible url whitelist scenarios, including Android Scheme properties, exposed components, sweep, comments, chat input.

Scanning the question is more interesting, in accordance with the truth, by scanning the TWO-DIMENSIONAL code and direct web page click URL, if there is a whitelist verification mechanism, should be loaded with the same whitelist function. However, due to the architectural design of the team, different people are in charge of the two parts, resulting in different verification mechanism of the whitelist, which brings some problems.

Man-in-the-middle attack

In fact, man-in-the-middle attack has a long history, which was also in the web platform at the earliest. However, due to the increasing number of Internet connections on The Android platform and the increasing number of users, it has become a serious security problem.

A man-in-the-middle attack can hijack requests made by an app and return something the user does not expect. All HTTP can be attacked by man-in-the-middle because it is inherently insecure network traffic.

HTTPS as a security solution of HTTP, if the implementation is not good enough, there are also many loopholes. At present, the well-known vulnerability locations are X509TrustManager, HostnameVerifier and setHostnameVerifier. For scenarios, the client does not verify SSL certificates or the verification logic is wrong, respectively. The customized HostnameVerifier interface does not check whether the domain name matches the certificate domain name. Use the HostnameVerifier interface that accepts any domain name.

Webvie loopholes

One of the most widespread and increasing Webview vulnerabilities discovered this year is JavaScript interface exposure. About 1/5 of the popular applications that use Webview components have this problem.

There are a lot of exposed JavaScript interfaces in the SDK of one of our application suppliers. Through code tracking, we found that this interface can perform many operations, including sending messages, making phone calls, downloading applications and so on.

The solution to webView vulnerability is mainly to scan the keywords in the code. These are some configurations of WebView, which may not be a problem individually, but together they will cause a lot of problems.

Android application problems and solutions

There must be a lot of privacy data in the application we use, such as name, age, gender, ID number and other information, which can be leaked through the network, SD card storage, SMS, NFC, Bluetooth transmission and other ways.

So what can you do as a developer to prevent these leaks, or to make sure your app doesn’t have these behaviors, which includes determining whether the large number of open source SDKS introduced are malicious.

Flowdroid is a data analysis tool for Android apps. It actually analyzes all possible paths of your information flow, which are divided into source and sink, where source refers to sensitive data and sink refers to leak point.

That’s all for today’s sharing. Thank you!

Editor: IT big guy said, reprint please indicate copyright and source