Simple App to-end security vulnerability of any debugging vulnerabilities, the middleman hijacking vulnerability and the encryption algorithm vulnerability-vulnerability warning-the black bar safety net

ID MYHACK58:62201681704
Type myhack58
Reporter 佚名
Modified 2016-12-01T00:00:00


Last week to introduce to the APP-end backup feature is turned on vulnerability and local denial of service vulnerability this week to introduce the completion of the last of the three common App-side vulnerabilities: arbitrary debugging vulnerabilities, MiTM hijacking vulnerability and the encryption algorithm vulnerability.

Any debug vulnerability

Say to any debugging vulnerability 我们 就要 提到 AndroidManifest.xml it is each Android application must file. It is located in the entire project's root directory, the description of the package exposed to the components, activities, services, etc., and their respective implementation class, a variety of data to be processed and the start position. In addition to the statement in the program Activities, ContentProviders, Services, and Intent Receivers,can also specify permissions and instrumentation, safety control and testing.

And in the AndroidManifest. xml file, debuggable attribute value is set to true the default is false, the program may be any of debug, which will produce any debugging vulnerability.

Any debugging vulnerability of hazards:

Can be dynamically debugging, adds the apk is cracked, analysis of the risk. The current dynamic debug function is very powerful, if the debuggable attribute to true, you can easily be debugged, usually used for important code logic analysis, to hack a paid feature.

The following figure is the IDA of the debugging interface, you can lower the breakpoint, single-step execution, the Debug process can see the contents of variables, even if there is no java code, reverse compiled smali code is also relatively easy reading, plus dynamic debugging, the App reverse analysis will become much easier.


HTTPS MiTM hijacking vulnerability

The middle attack refers to an attacker with the communications at both ends, respectively, to create the separate contact, and exchange their received data, so that communication at both ends think they are by an intimate connection with each other in direct dialogue, but in fact the entire session is the attacker's full control. In-the-middle attack, the attacker can intercept the communication between the two sides of the call and insert the new content.

HTTPS man in the middle attacks vulnerability the following sources:

  • Lack of SSL certificate validation.
  • No domain name to check.
  • Certificate authority(Certification Authority)is attacked, resulting in the private key leak, etc.


  • Implementation of the X509TrustManager interface of the Java code fragment 【wherein the checkServerTrusted()method implementation is empty, i.e. does not check whether the server is trusted】:



  • Accept any name in the Java code fragment


Attack effects: A App add a shipping address, the use of the middleman hijacking can get the phone number, address, name and other sensitive information.


We attack from above results it can be seen, the use of the middleman hijacking vulnerability, an attacker can MiTM attacks such as the use of fishing WiFi, steal account passwords in plaintext, chat, content, communication address, telephone number, and credit card payment information and other sensitive information, even through an intermediary hijacking the original information is replaced with the malicious link or malicious code program, in order to achieve remote control, malicious chargeback and other attacks intended.

In major vulnerabilities on the platform, there is a large presence of the HTTPS certificate does not check vulnerability, such as domestic most of the Android APP there is a trust All certificate vulnerabilities, Amazon latest official Android version there is a trust All certificate vulnerabilities, Yahoo Yahoo in-country visits encountered SSL man in the middle attacks, Ctrip travel network the latest Android client https does not verify certificates resulting in https traffic content is fully captured.

Encryption algorithm vulnerability

The following types of behavior will produce the encryption algorithm vulnerability risk:

  • Use AES/DES/DESede encryption algorithm, if using the ECB Mode is susceptible to the risk of attack, resulting in information disclosure.
  • Code to generate the secret key using plaintext hard-coded, and easy to be easily cracked.
  • The use of insecure Hash algorithms(MD5/SHA-1)encryption of information, easy to be cracked.
  • Generate a random number with certainty, the presence of the crack risk.

While the encryption information is after the break, the resulting harm is self-evident: the encrypted information is compromised. If the encryption is account, password, Bank cards, ID cards and other information, after the break may be criminals for fraud, theft, stolen brush.

[1] [2] next