Component Communication Security
What is local denial of service?
Before understanding local denial of service, let’s briefly understand denial of service attacks (dos attacks) and distributed denial of service attacks (ddos).
The so-called denial of service attack is to occupy all the service threads of the server or the network bandwidth, so that normal service requests cannot be responded to, causing the server to be paralyzed. DoS attacks are generally aimed at WWW servers, SMTP servers, etc. As we all know, a normal TCP session can only be completed through three negotiation handshakes. First, the client sends a session request with SYN to the target server, then the server sends a reply message to the client, and finally the client needs to send back a confirmation message. If the source IP address in the request packet sent by the client is an unreachable IP address, the reply message sent by the server will never be confirmed. At this time, the server thinks that there is a problem such as network congestion, and keeps waiting for confirmation messages and resending messages, and the time cycle is getting longer and longer. Imagine if the client sends a large number of such invalid requests, then the server’s service threads will be instantly occupied.
A distributed denial of service attack is a malicious behavior that floods the target server or its surrounding infrastructure with large-scale Internet traffic to destroy the target server, service or normal network traffic. DDoS attacks use multiple compromised computer systems as attack traffic sources to achieve the attack effect. The machines used can include computers or other networked resources (such as IoT devices).
From this, we can understand that such attack methods all forge false requests/parameters to paralyze the server/device. If we take the Android application as a whole, we can roughly understand the principle of local denial of service.
The Android system provides components such as Activity, Service, and Broadcast Receiver, and provides an Intent mechanism to assist in the interaction and communication between applications. Intent is responsible for describing the action, action-related data, and additional data of an operation in the application. The Android system is responsible for finding the corresponding component based on the description of this Intent, passing the Intent to the called component, and completing the call of the component. The Android application local denial of service vulnerability stems from the fact that the program does not capture the exception when processing the exception or malformed data obtained by Intent.getXXXExtra(), which causes the attacker to send such empty data, abnormal or malformed data to the victim application to crash the application. Simply put, the attacker sends empty data, abnormal or malformed data to the victim application through intent, causing it to crash.
Protection strategy:
(1) For components that do not need to be exported, explicitly set their exported attribute to “false” to reduce the attack surface of the application.
(2) After getIntent(), use try…catch to handle exceptions when calling Intent.getXXXExtra().
(3) Set permission control (android:permission attribute) for the exported components to prevent any third-party applications from accessing them.
(4)For dynamically registered BroadcastReceivers, use the registerReceiver() method as little as possible. If communication is only within this application, use the registerReceiver() method of LocalBroadcastManager for local registration. If it must be exported to an external application, specify the corresponding access permissions when using registerReceiver().
Network communication security
Android software usually uses WIFI network to communicate with the server. WiFi is not always reliable. For example, in an open network or a weakly encrypted network, the accessor can monitor the network traffic; the attacker may set up WIFI phishing by himself. In addition, after obtaining root privileges, network data can also be monitored in the Android system. For example, when using the HTTP protocol to log in to an account or exchange data, the attacker configures a DNS server in the phishing network set up by himself, and resolves the server domain name to be connected by the software to another server of the attacker. This server can obtain the user login information, or act as an intermediary between the client and the original server to forward the data of both parties.
The solution to this kind of problem is obvious - use HTTPS based on SSL/TLS to transmit sensitive data.
In SSL/TLS communication, the client determines whether the server is trustworthy through a digital certificate, and uses the public key of the certificate to encrypt communication with the server. However, in order to solve the problem of SSL certificate error (after using the self-generated certificate, the client finds that the certificate cannot form a trust chain with the system’s trusted root CA, and CertificateException and other exceptions occur), developers will use the method of trusting all certificates in the client in the client code:
SSLSocketFactory sf = new MySSLSocketFactory(trustStore);
sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
In the client, Google’s default certificate check mechanism (X509TrustManager) is overwritten, and there is no code related to verifying the validity of the SSL certificate in the code:
1 | public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException { |
If a malicious certificate is installed in the user’s mobile phone, then the user’s communication can be eavesdropped and the data in the request or response can be modified through a man-in-the-middle attack. In the phishing Wifi network, similarly, the attacker can set the DNS server to make the client communicate with the specified server. The attacker deploys another certificate on the server. During the session establishment phase, the client will receive this certificate. If the client ignores the exception on this certificate or accepts this certificate, the session will be successfully established and encrypted communication will begin. However, the attacker has the private key, so he can decrypt the plaintext data sent by the client. The attacker can also simulate the client, contact the real server, and act as a middleman to monitor.
Protective measures:
It is feasible to use a CA to issue a certificate, but if combined with the actual situation, the time and cost are too high, so this method is rarely used. Since the mobile application server is actually fixed, the certificate is also fixed. The “certificate or public key locking” method can be used to protect the problem of unverified certificate validity.
(1) Public key locking:
Write the certificate public key into the client apk, and check whether the certificate public key is consistent with the apk during https communication (implementing the X509TrustManager interface).(2) Certificate locking:
That is, issue a public key certificate to the client and store it in the mobile client. During https communication, load the certificate information in the client code (using keystore) and then verify it.