Author: dfqin

Address: https://www.jianshu.com/p/fe0206f8be5b

preface

12306 user information leakage last week, attention continues this week! Recently, news broke that data leaks are true. Last week, some students left a message hoping to see the article about security. Today, let’s learn the analysis of mobile security brought by Dfqin!

Network request – streaking data

No matter the web page or APP, it is inevitable to visit the background service. It may obtain data from the server or submit data to the server. At this time, the client needs to initiate a network request. Because HTTP protocol is simple, flexible and stateless, most applications use HTTP to make network requests. A common network request is shown below:

Security risks everywhere

Because HTTP is transmitted in plaintext, the user name and password are also transmitted in plaintext on the network. Attackers can view plaintext data at any link during the transmission. Of course, many systems do not transmit and save plain-text account passwords, and usually use MD5 values for transmission and storage. The well-known CSDN database leakage before is because the passwords are stored in plain-text, so hackers can easily take them to crash into the database, which aggravates the severity of the event.

In recent years, the ability of MD5 cracking has been improved. For example, when hackers see a large number of passwords in the database, they can try to burst them, and they can also directly use the MD5 value of the password to bump the database. Therefore, nowadays, it is usually necessary to add salt when generating MD5 values. To some extent, it improves security.

An attack does not necessarily require a username or password, but rather tokens and UUIds. As can be seen from the above figure, once the user logs in, the server identifies the user by token. If the token is hijacked by a hacker, he can pretend to be your identity to attack, if the token mechanism is not properly designed, the attacker can even direct violence against the token. Most sites have a similar mechanism. The server identifies a user with a sessionId. Once an attacker obtains this sessionId, he or she can impersonate a legitimate user.

Of course, although the data is transmitted in clear text, if you are not the network management, network operator, it is not easy to get access to the data, otherwise there would not be so many people in public places to open WIFI to go fishing. Just because we can’t capture someone else’s data doesn’t mean we can’t do anything. What can we do? If you can’t capture other people’s data, you can capture your own data, analyze the server interface, and find design loopholes to make a breakthrough. Here are some application scenarios:

  • Wechat vote brushing. Wechat is full of voting events, such as baby contest, most beautiful police officer and dancing star. It’s usually a link to get your public information (nickname, avatar, etc.), and then a scratchy 90s web page. Find the contestant with the corresponding number and check submit. Before you do this, set up your proxy server, look at the request parameters sent during the poll, more often than not you’ll find some problems, verify your ideas with Postman, and write a ballot tool in about half an hour. At this point you can think about how to design the voting process to be more robust.

  • Weibo XSS event. The Weibo API itself is open. Through XSS vulnerability, js scripts are injected to call the API of follow, forward and private message.

  • Wechat, Dianping, Weibo and other robots. In many industries, popular review sites in praise of the merchants, the merchant’s business and word of mouth influence is very big, so there are many water army brush praise and malicious slander competitors, human flesh, and brush comments it is clear that the cost is higher, and the higher the activity of the user level is higher, the higher the level of user comments when the higher weight is rated by the merchant, So at that time, there were a lot of robot trumpets to do illegal activities, until the company invested a lot of resources to set up a dedicated integrity team. Wechat public number also has the same problem, a celebrity public number to send an article only a few hundred reading, so much lose face ah, spend some money to find the water army brush quantity, impression wechat for this matter also from the policy and technology to rectify several times. Without further comment on weibo, I even doubt the official attitude. Clear water means no fish. Even the Apple APP Store is not immune, but only in the form of human flesh and crowdsourcing.

Is everything ok if you use HTTPS

HTTPS includes unidirectional authentication and bidirectional authentication. Most application scenarios are in C/S mode. In this case, unidirectional authentication is used to ensure that the data received by the client is sent from the background. It’s really hard to attack at this point, unless you can trick someone into installing and trusting your certificate, which is not impossible. Many people are prompted to trust something without looking at it when they surf wifi or download some resources online.

Aside from that, the attacks mentioned above rely on the analysis and invocation of the backend interface, and for this type of attacker, it makes no difference whether you use HTTP or HTTPS.

When using a packet capture tool, you can analyze HTTPS requests by installing and trusting the self-signed certificate of the package installation tool on the target device. The following describes the normal HTTPS packet capture and the packet capture after the certificate is configured


Use signing and encrypting data

As can be seen from the above, HTTPS cannot prevent an attacker from analyzing the request interface and launching an attack. To increase the difficulty of analyzing the request, two methods can be used:

Use signatures. That is to add a signature to your request parameters. When the background service receives the request, it verifies the signature first. If the signature is incorrect, it will not be processed. There are various signature rules. The general strategy is to perform some operations according to the request parameters and finally generate a unique string as sign, the signature of wechat payment. https://pay.weixin.qq.com/wiki/doc/api/app/app.php?chapter=4_3

Data encryption. Encrypt data posted to and returned from the server, so that even if an attacker gets hold of your data, he can’t do anything without knowing your encryption algorithm.

The above two methods can be used together, but you need to consider a question: how do you prevent an attacker from getting your signature generation rules and encryption algorithms, such as the AES algorithm you use for encryption, and where do you put your secret keys?

Decompiler your code without secrets

This is the Android project. As you know, many apps, especially PC games, are only available on iOS, not Android. In some online games, user data for Android version and iOS user data are also isolated. This is partly due to the chaotic distribution of Android apps and partly due to the low barriers to decompilation and repackaging.

The project structure

In the early stage, Android project did not have its own IDE tool, but used Eclipse and ADT plug-in for development. The project structure is consistent with other Java projects, that is, a workspace represents a project, and a project represents a sub-project. Later, Google launched Android Studio based on IntelliJ IDEA, and the Project structure naturally changed into Project+ Moduled form. While the directory level has changed, the overall structure has not.

Here is a typical Android project. PermissionGrantor is the project name, and there are two subprojects, app and Grantor. The ICONS of the two subprojects look different because one of them is an app project. The other is a library project, which generates an AAR library that can be referenced by other projects.

Let’s take a look at the APP project, namely the application project. The red box is marked with several important directories. Libs is used to store the dependent libraries of the project, Java directory is the code of the project, res is to store resources, including pictures, layout, strings, etc. :

The androidmanifest.xml at the bottom can be interpreted as a configuration file for a project, where the operating system loads an application, where to start executing it, which classes are invoked on each page, and which services and permissions are available. An important takeaway from this is that the entry to the application and the modules and even the classes of the service can be seen here, and must be configured here and the file is attached to the distribution APK.

Compilation and decompilation

2.1 confused

When a project compilers a formal package, obfuscating is turned on by default, that is, the class name and method name will be confused with a, B, C, and D, making it harder to crack. Proguard, the open source solution adopted by Android, only confuses Java classes. Androidmanifest.xml is used to register the Application class and the Activity class in the androidManifest.xml file. So Android default for Application, Activity, Service, UI-related classes are not confused, and some of the generated classes through string reflection can not be confused (network data into local Java objects), and JNI call methods can not be confused. Below is a decompiled Activity and data object for QQ reading.

Through the above analysis, we find that although Android introduces obfuscation technology, due to the defects of the current obfuscation scheme and the extensive use of reflection technology in the Android system framework, many important classes cannot be obfuscated, which greatly reduces the cost of reading source code after decompilation. As mentioned in the previous article, it is not particularly difficult to crack the signature and encryption algorithm. In order to increase the difficulty of cracking, we can put the algorithm into native code, which uses C/C++ to implement the algorithm and call it through JNI.


2.2 build

The project is compiled into APK file, which is mainly divided into the following parts:

  • XML compiles to a binary file. All strings in the XML are put into a resource pool, and the place where strings are used is replaced with the address of the resource. So compiling XML to binary not only takes less space, but also speeds up loading.

  • Generate the resource. Arsc resource index table.

  • Java generates the dex file.

2.3 the signature

After the APP is compiled into an APK package, the package must be signed before it can be installed on the phone. After analyzing the signed package, we can find that there are more manifest. MF, cert. SF and cert. RSA files in it. We open the manifest.mf directly with a text editor as shown below:

This file contains the base64 value of the SHA1 digest for each resource. This can explain why apK cannot be installed when you directly replace a resource in the APK package, because the program validates that the resource digest is inconsistent with the manifest.mf file during installation.

We continue to open cert. SF with a text editor, as shown below:

We can see that the following file is the same as the first file except for the sha1-digest-manifest value at the top. We can test that this value is the base64 value of the SHA1 Digest of the first file manifest.mf.

As mentioned above, if you update the manifest.mf file at the same time, you will not be able to pass cert. SF. What if I change the value in cert. SF at the same time? We can move on to the third file cert. RSA, which we find is a binary file opened with a text editor and can be opened with the following command:

openssl pkcs7 -inform DER -in CERT.RSA -noout -print_certs -textCopy the code

The contents after opening are as follows:

There’s data on the Internet that explains this structure, so we’re not going to analyze it, just know that the top hexadecimal code is the public key of the signature, and the bottom one is the signature, which is the result of encrypting the fields and values in your keystore file with the private key. The program is installed using the above public key for verification, if you do not have the other party’s private key can not be forged signature.

This answers the question raised above. Replacing resources in apK packages with changes to manifest.mf and cert.sf at the same time will not be validated.

But what if I also replace the top public key? The answer is yes, of course. This is because you re-sign the APK using your own private key.

Android uses self-signed certificates, so if someone takes your APP, re-signs it in their keystore and publishes it, the user won’t know if it’s a fake or a genuine copy. This explains why many PC games do not do Android version, you work hard to make a charging game, it is easy for attackers to crack the inside add advertising, and then re-packaged release.

Some users who don’t want to pay for the game just have to put up with the ads to play it for free. From the analysis here, we know that it is very difficult for an attacker to forge our signature, so we can insert signature checking code into the program to raise the threshold of attack.

decompiling

APK structure analysis has been done above, decompiler to do the work is to disassemble. Dex and restore XML files. We can use apkTool to decompile an APK directly and get restored XML files and.smali files. The smali file here can be run on the Android VIRTUAL machine assembly language, it is still a little difficult to read, if you have the need to read the source code, you can directly decompress the APK package, use dex2jar tool directly decompile dex file, you can get the decomcompiled class file. That is, we can get the decomcompiled Java source code.

The encryption algorithm and the secret key mentioned in the previous article can be obtained by analyzing the decompiled source code. In order to prevent others from accessing similarly sensitive information, many people choose to keep this information in lib.so, as we’ll see in the next section.

To be continued!

Question of the day:

How much do you know about mobile security?

Punch card format:

Punch X days, answer: XXX.