Lack of Binary Protection at Asus “Vivo Baby” and “HiVivo” for Android that could Result of Several Security Issues (CVE-2017-17944 & CVE-2017-17945)

Author: YoKo Kho | Posted in Bug Report, Mobile Apps, Write-Up No comments

Lack of Binary Protection at Asus VivoBaby and HiVivo Application for Android

In the name of Allah, the Most Gracious, the Most Merciful.

Please kindly visit this simple paper directly to looking this release (for a simple look):

[English Version] Asus – Lack of Binary Protection at Asus “Vivo Baby” and “HiVivo” for Android that could Result of Several Security Issues

For completing some of the explanation (the used of information at the application binary), we upload the unlisted video at Youtube for two scenarios:

Note: Issues that mentioned is not a critical or high risk issue. This paper only shows how we could do another thing from the very low of issue (lack of obfuscation).

I. ABSTRACT

As quoted from Asus VivoBaby Information at PlayStore, ASUS VivoBaby is a all-day portable movement monitor for baby. Which employs to alerts parents when your loved ones need you in anywhere and anytime. With ASUS unique development on KoodOS, VivoBaby assists parents to have advanced-monitoring on baby’s continuous skin temperature, heart rate and movement rate in real-time. To easier parents to accessing the device, then Asus create the VivoBaby application for Android and iOS.

But the problem exists when the Asus VivoBaby Application for Android doesn’t implement one of the best practice security yet (binary obfuscation). By using this situation, then the Attacker could extract some of sensitive information that could result of several security issues (explained later at this report).

II. INTRODUCTION

For understanding the report completely, we put some of definition or reference at this section.

2.1. Lack of Binary Protection – OWASP Mobile Top 10 2014 – M10
Quoted by OWASP official page, A lack of binary protections within a mobile app exposes the application and it’s owner to a large variety of technical and business risks if the underlying application is insecure or exposes sensitive intellectual property. A lack of binary protections results in a mobile app that can be analyzed, reverse-engineered, and modified by an adversary in rapid fashion. However, an application with binary protection can still be reversed by a dedicated adversary and therefore binary protection is not a perfect security solution.

At the end of the day, binary protection only slows down a security review.  It is extremely common for apps to be deployed without binary protection. The prevalence has been extensively studied by a large number of security vendors, analysts, and researchers.

2.2. Definition of Brute Force Attack
We are pretty sure if the readers have very well knowledge related the definition of Brute Force Attack. But for completing the detail, we also try to explain in simple about the definition.

Based on the Wikipedia summaries, Brute Force Attack a brute-force attack consists of an attacker trying many passwords with the hope of eventually guessing correctly. The attacker systematically checks all possible passwords and passphrases until the correct one is found. Briefly, the harder the password used by the user, the more difficult it is for the Attacker to take over the account.

In reality, the attack also can be addressed to the possibility of the username. When the username is unknown or difficult to guess, then the attacker’s job to gain the access from this way of attack is more difficult.

2.3. Definition of CAPTCHA
CAPTCHA stands for “Completely Automated Public Turing Test to tell Computers and Humans Apart”. In simple, this feature is frequently used to distinguish the activity conducted between computer and human. (Of course, the reader remembers about the Turing’s test with similar purpose. The only difference at this point is: “this test is conducted by a computer. That’s why this test is known as a Reverse Turing Test”). In the application, the feature needs one simple step conducted by the user, such as typing some letters shown in the picture.

III. AFFECTED VERSION

The affected version of this vulnerability could be found at:

  • Asus Vivobaby for Android v.1.0.30 built September 06th, 2017 – (< v.1.1.09 build Nov 29th, 2017);
  • Asus HiVivo for Asus Watch v.5.6.22 built October 06th, 2017 – (< v.5.6.27 built Nov 29th, 2017).

Please kindly note, the other affected things are not depends into the specific version since several vulnerabilities are found at the Asus’ Web Service.

IV. SUMMARY OF ISSUE

As it has been described before, the security issue in this report could allow the Attacker to extract some of sensitive information from the unprotected binary of Asus Vivo Baby Application for Android. Several security issues that could be triggered by that main issue are:
4.1. Bypassing the CAPTCHA protection at registration page of ASUS Account;
4.2. Bypassing the CAPTCHA protection at login page of ASUS Account to launch a brute force attack;
4.3. Found the Hardcoded DESede key that probably used for protecting the user’s password;
4.4. Found the custom Authorization Header (Bearer) that showing if the custom header is not really works;
4.5. Fail to validate the Digital Certificate;
4.6. Found the Full Path Disclosure

Yes, totally agree with you. Every issue that mentioned is not a critical or high risk issue. This paper only shows how we could do another thing from the very low of issue (lack of obfuscation).

V. INFORMATION AND SITUATION OF THIS POC

5.1. 0x01 – Lack of Binary Protection (Obfuscation) – Found Hardcoded Credentials
Generally, this kind of issue will never become a serious issue if there is no sensitive information that could be used to bypass a flow / process of the application or to decrypt an encryption that used by the system. But as stated earlier, since there are several security issues that could be “get” from this issue, then we decided to highlight this issue to be reported.

5.1.1. 0x01 Proof of Concept
Reproducing this issue is not really hard. Also, there are so many write-up with detail step-by-step about this that could be found easily from internet. For a simple way, we used “Show Java” Application for Android to decompile the .apk of ASUS Vivo Baby (and yes, the other reason is since we started to research this application when we on the way to go home).

Structured Directory from Decompiled .APK

After the decompiling process is done, then we conduct a simple analysis and finally arrive at the “AccountServiceInteface.java” and “AccountTaskCallable.java” that located at: “java” > “asus” > “vivobaby” > “libs” > “account“. Without so many deep analysis, its already clear if the binary is not protected with (for example) an obfuscation. Here is the sample result after we copied the decompiled .apk to our Desktop OS.

ClearText of Application’s Flow

For the details of another issue that could be found from this issue, then we could go directly into the next part of this report.

5.1.2. 0x01 Impact
The simple impact that could be explained from this issue is the Attacker could know the flow of the Application and could use that valuable information to launch another scenario of Attack that will be explained at the next Proof of Concept.

5.1.3. 0x01 Additional Information
In simple, the most thing that implemented by so many developer is to obfuscate the binary. At least, this kind of protection could make the “attacker’s job more difficult” to learn the flow of the application.

5.2. 0x02 – Bypassing the CAPTCHA Protection at Registration Page of ASUS Portal
ASUS has integrating their Vivo Baby Account into the Asus main portal. In other words, the account that could be used by the user in this application is the same account that could be registered at Asus Official Portal that located at https://account.asus.com.

When we try to look into Asus Official Portal, we could see if the registration page is protected by the CAPTCHA feature. We are very sure if Asus decided to use this CAPTCHA feature to block the unwanted registration that could be conduct by Bot.

CAPTCHA Feature that could Block the Automated Registration

But the problem in here exists when the CAPTCHA feature could be bypass by the used of information that could be seen via decompiled Vivo Baby .apk. By using this kind of information, then Attacker could register their account or other account as much as they want without get any block from the CAPTCHA feature.

5.2.1. 0x02 Proof of Concept
For reproducing this issue, then we should go back into the “AccountServiceInterface.java” and “AccountTaskCallable.java” that we found from the earlier activity (decompile process). As a reminder, both of files could be located at: “java” > “asus” > “vivobaby” > “libs” > “account“.

Deep Analysis into AccountServiceInterface.java

As we could see, we could understand if the function that stated from this file are used by Asus to let the user do a registering process (“RegisterASUSAccount“). From this file, we also could get the ApiID’s value and the page (awscusinfo.asmx) that could process the account registration.

So, as a recap, from “AccountServiceInterface.java“, we got:

  • The need of 4 (four) parameters to completing the registration, which are AppID, AppKey, ApiID, and ParaJson;
  • The ApiID’s value (which is w000000012);
  • The list of needed Json Parameter at ParaJson for completing the registration (login, country, ip, and passwd);
  • Page for Account Registration (awscusinfo.asmx). The complete path or URL could be get at “AccountTaskCallable.java” as this code showing it.

After we got those several information, then we could go to “AccountTaskCallable.java” as shown at the previous code. From this function, we finally found the complete things that we needed to conduct a registration process.

Deep Analysis into AccountTaskCallable.java

From that function, finally we could get the complete URL, AppKey and AppID parameter.

When we found this complete URL, then we try to open it directly at the browser. As expected, the page showing a complete information about the account registration process.

Web Service that used for Account Registration

Please kindly note, when we try to access the “call” function, then we get the complete parameter information that we need to register our own account at Asus Portal.

Complete Information to Register the Account

As a recap, then we finally found:

  • Complete URL to register our own account via Asus web service (located at: https://account.asus.com/ws/awscusinfo.asmx); and
  • The value of AppID (healthc002), AppKey (a32ee2efcd5a4b2dbd5a9125bb450bfb), ApiID (w000000012), and ParaJson (login, country, ip, and passwd).

With this information, then we could go to the next step, which is proofing if the information could be used to register our own account at Asus Portal and we don’t need to face the CAPTCHA feature.

As a simple process to showing the request and response, then we copy all of those information to burpsuite and runs it in the repeater mode. From this activity, finally it brings us to the success result, which is our account has been proceed by Asus and got registered at their portal.

Registration is Success

To proofing if the request is works and the response is right, then we try to check our email account.

Account has been Registered

To showing the registration is works, then we try to login into the Asus Official Portal with this account.

Success to Login into Asus Portal without Verification

5.2.2. 0x02 Impact
The most common reason when the application using a CAPTCHA at their form is to prevent the bot activity. So, when the CAPTCHA at registration process could be bypass by using its own Asus web service, then the Attacker could register their own account or another account as much as they want to flood the application with the junk data (spam) without get any block from the CAPTCHA.

5.2.3. 0x02 Additional Information
For completing the explanation, then we upload the unlisted video at youtube that could be found at: https://youtu.be/a9Yw4Kuo6Q0.

And this is the complete request that used to bypass the CAPTCHA Protection at Registration Page:

POST /ws/awscusinfo.asmx HTTP/1.1
Host: account.asus.com
Content-Type: text/xml; charset=utf-8
Content-Length: 558
SOAPAction: “http://www.asus.com/call”

<?xml version=”1.0″ encoding=”utf-8″?>
<soap:Envelope xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”>
<soap:Body>
<call xmlns=”http://www.asus.com/”>
<AppID>healthc002</AppID>
<AppKey>a32ee2efcd5a4b2dbd5a9125bb450bfb</AppKey>
<ApiID>w000000012</ApiID>
<ParaJson>{“ip”:””,”country”:”USA“,”passwd”:”Your_Password_Here“,”login”:”asus.tstacc2@domain.com“}</ParaJson>
</call></soap:Body></soap:Envelope>

5.3. 0x03 – Bypassing the CAPTCHA Protection at Login Page of ASUS Portal
This one is not too different with the previous one at 0x02. The main different issue at this part is we talked about bypassing the CAPTCHA Protection at Login Page to launch the brute force attack. Please kindly note if the account that we discussed is the same account, which is ASUS Account that located at  https://account.asus.com.

So basically, when we try to login, we will not found any CAPTCHA feature at the login page. But when the user failed so many times to insert the correct information (username and password), then the CAPTCHA feature will be showing up automatically to prevent any brute force behavior.

CAPTCHA Feature that could Block the Automated Login Attempt (Brute Force Attack)

But the problem in here exists when (once more) the CAPTCHA feature could be bypass by the used of information that could be seen via decompiled Vivo Baby .apk. By using this kind of information, then Attacker could know the correct or incorrect account information (brute force) as much as they want without get any block from the CAPTCHA feature.

5.3.1. 0x03 Proof of Concept
For reproducing this issue, then we should go back once more into the “AccountServiceInterface.java” that we found from the earlier activity (decompile process). If previously our focus is located to the “WSResultCode RegisterASUSAccount” class, then at this part, we will focus into “WSLoginResponseInfo Login“.

Deep Analysis into the Login Process

As we could see, this class manage the login status that integrating with the Asus Portal. Everything has the same value except the ApiID and ParaJson, which are:

  • ApiID for login is w000000011;
  • ParaJson Parameter for login are “login” and “passwd“.

So, just like the previous activity, after we get this information, then we will try to proof the if those parameters could be used to knowing the login status.

With the same way of testing, then finally our prediction about knowing the login status is correct. This function (WSLoginResponseInfo Login) let the user / attacker knows if the provided username and password is correct or incorrect.

Provided Credentials are Correct

Since the prediction is correct, then the Attacker just need to change the login with the account that they would like to take over then continue the attack by brute forcing the “passwd” parameter with their own dictionary. In this situation, Attacker doesn’t need to worry to get any block from CAPTCHA since there is no CAPTCHA protection at this process and Asus didn’t implementing the login attempt limitation.

For completing the detail, here are the sample of launched brute force attack that conduct by us into our own test account:

The Sample of Failed Password

If the provided password is wrong, then the total response of the length will be around 752 sizes. The response of failed attempt is like this:

The Response of Failed Attempt

But when the provided information is correct, then the total response of the length will be change into around 1106 sizes. Here is the sample result of the correct response:

The Sample of Correct Response

As we could see from the try, we don’t get any block from the CAPTCHA and also our attempt is not getting block even after 96 tries.

5.3.2. 0x03 Impact
The most common reason when the application using a CAPTCHA at the login page is to prevent the automated activity that would like to take over a valid account. So, when the CAPTCHA at login process could be bypass by using its own Asus web service, then the Attacker could launch the brute force attack into the victim account as much as they want without get any block from the CAPTCHA or the system.

5.3.3. 0x03 Additional Information
For completing the explanation, then we upload the unlisted video at youtube that could be found at: https://youtu.be/KM5rfoCToiM.

And this is the complete request that could be “used” to launch the brute force attack:

POST /ws/awscusinfo.asmx HTTP/1.1
Host: account.asus.com
Content-Type: text/xml; charset=utf-8
Content-Length: 531
SOAPAction: “http://www.asus.com/call”

<?xml version=”1.0″ encoding=”utf-8″?>
<soap:Envelope xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”>
<soap:Body>
<call xmlns=”http://www.asus.com/”>
<AppID>healthc002</AppID>
<AppKey>a32ee2efcd5a4b2dbd5a9125bb450bfb</AppKey>
<ApiID>w000000011</ApiID>
<ParaJson>{“passwd”:”Your_Password_Here“,”login”:”asus.tstacc@domain.com“}</ParaJson>
</call>
</soap:Body>
</soap:Envelope>

5.4. 0x04 – Hardcoded DESede Key at Application
When we tried to analyze the application structure after the decompile process, finally the “userconfig” directory has gaining our attention. After we look for a while, then finally we get the DESede key (stored at “EncryptDecrypt.java” that used by Asus to encrypting or decrypting the password value.

Please kindly note, the “EncryptDecrypt.java” file is located at: “java” > “asus” > “vivobaby” > “libs” > “userconfig“.

Hardcoded DESede Key at Application

To be honest, we don’t get the strong proof if the decryption key will work well since there is another thing that we don’t have (probably such as a vivo watch or the vivo baby device is well). But we are very sure if the value of the key (which is HivivoDonutEncodeDecodes) is valid.

5.4.1. 0x04 Impact
In the very simple situation, the (DESede) encryption that used by Asus to protecting the users’ data (which is password) is not going well since the Attacker could decrypt the value from the hardcoded key that found at application.

5.5. 0x05 – Hardcoded Custom Authorization Header at Application

Generally, the Custom Authorization Header is made by developer for several purposes such as preventing the CSRF attack and also could preventing any IDOR execution. By design, the custom authorization header is filled by the unique token that identical with the active session.

But the problem in this situation exists when the Custom Authorization Header at few function is static and could be found directly at the application (which is hardcoded just like the DESede Key). So, since the value is static, then the value itself doesn’t represent the uniqueness of the active session.

Hardcoded Custom Authorization Header at Application

For proofing our prediction, then we try to intercept the request of the application when creating the “new baby” status (Please kindly see the screenshot for the complete request).

POST /api/api HTTP/1.1
Authorization: Bearer 568HH4342GH55UYH6P983E193G8YG78
DEV_ASUS_AUTH: redacted_some_of_very_long_value_over_here
Content-Type: application/json; charset=utf-8
Content-Length: 316
Host: iotapi.asus.com
Connection: close
Accept-Encoding: gzip, deflate
User-Agent: okhttp/3.0.1

{“BodyMeasurement”:[{“bmi”:””,”bmr”:””,”height”:”0″,”time”:”2017-09-18 05:54:35″,”weight”:”0″}],”CusID“:”REDACTED-0D96-4506-85C6-0016A4703AB9″,”NickName”:”anothertest”,”Pic”:””,”Time”:”2017-09-18 05:54:35″,”birthday”:”2017\/9\/18″,”country”:”USA”,”datasource”:”com.asus.user.newuser”,”gender”:”M”,”language”:”en_US”}

As we could see from the request, there are Custom Authorization Header (in bearer), DEV_ASUS_AUTH (a very long value that probably made as session uniqueness), and also the normal POST parameter.

If we take a look into the request carefully, then there is no cookies in here, which is the session is depends to Custom Authorization Header or DEV_ASUS_AUTH or depends to both of them.

So, for the first attempt, we try to remove the “DEV_ASUS_AUTH” parameter and try to add new baby status. The response was unpredictable, which is everything was going well without this parameter. In other words, the session for every user are static and It just depends to the CusID parameter that located at the POST Request (even its pretty hard to be guessed, but this one is not the point). For completing the explanation, here are the response from the request that has “DEV_ASUS_AUTH” and from the request that doesn’t has “DEV_ASUS_AUTH”.

Request with DEV_ASUS_AUTH Parameter

Request without DEV_ASUS_AUTH Parameter

As we could see, both of those requests has a valid response, which is creating the new baby status that shown at another new “CusID” value (right box – response result).

By this situation, then we try to add the “new baby” status to the account that we have. Here is the final request if we would like to confirm the add of the new baby status.

POST /api/api HTTP/1.1
Authorization: Bearer 568HH4342GH55UYH6P983E193G8YG78
Content-Type: application/json; charset=utf-8
Content-Length: 362
Host: iotapi.asus.com
Connection: close
Accept-Encoding: gzip, deflate
User-Agent: okhttp/3.0.1

{“AcceptedDate”:”2017-09-18 05:54:42″,”AccepterCusID“:”2AA95B88-0D96-4506-85C6-0016A4703AB9″,”ActiveState”:”1″,”CareRelationship“:”1″,”CusID”:”9D5DC24A-4B43-4C10-A098-2B0AC4CB8DFB”,”InvitedDate”:”2017-09-18 05:54:42″,”InvitorCusID“:”2AA95B88-0D96-4506-85C6-0016A4703AB9″,”KinRelationship”:”7″,”Time”:”2017-09-18 05:54:42″,”datasource”:”com.asus.healthcare.care”}

From the request above, we could see if there are “AccepterCusID“, “CareRelationship“, and “InvitorCusID” parameter at the POST Request.

The “AccepterCusID” and “InvitorCusID” has a same value since those parameters act as a main account at the Vivo Baby Application. For example, in this case those parameters represent to the account of circle.idts4@outlook.com account.

Sample of Request for Confirming the Creation of New Baby

And then, the “CareRelationship” parameter is represent the new baby status that was made from the earlier request (shown at the response box). So, by knowing the AccepterCusID (yes we know, it’s hard, but once more, it’s not the point), then the Attacker could add the new baby status into the victim’s account. In other words, Attacker doesn’t need to know the Custom Authorization Header or DEV_ASUS_AUTH Parameter since both of them doesn’t represent as the unique session (and this is our point).

5.5.1. 0x05 Impact
As described earlier, there is no real impact so far since since the Attacker still need to guess the pretty hard AccepterCusID. The main point in this situation is the Custom Authorization Header or DEV_ASUS_AUTH Parameter doesn’t represent as the unique session of the account at some feature.

5.5.2. 0x05 Additional Information

Adding the unique session for every account activity will be a solution to prevent any IDOR execution. In this case, Asus has put the DEV_ASUS_AUTH as a unique value already, but it doesn’t work well as a unique session that has a specific relation with the logged user.

Please kindly note, at the several requests, Asus also using the unique Custom Authorization Header that specific for each user. For example, the request that using this specific value is the request for getting our own information.

Here are the sample requests that could showing the difference between “the request with static custom authorization header” and “the request with unique custom authorization header”.

Static Custom Authorization Header

Just like the previous explanation at PoC part, the picture above showing the used of “Static Custom Authorization Header”.

And this one is the unique custom authorization header:

Unique Custom Authorization Header

Basically, what we would like to say, the used of “Unique Custom Authorization Header” is the correct one (regardless the used of GET / POST HTTP Method).

5.6. 0x06 – Fail to Validate the Digital Certificate (Lack of Cert. Pinning) at Application

Not really much that could be explained at this part, the only thing that we would like to say is we could intercept the request easily by using the custom digital certificate (which is we use the burpsuite’s certificate) without changing anything at the .apk. Even in the real scenario the Attacker needs more user interaction by the victim, then the risk still exists by didn’t implementing this best practice.

5.6.1. 0x06 Impact and Additional Information

The impact from this case could be separate into two point of view, which are:

  • Victim’s point of view = the Attacker that succeed to tricks the victim to use Attacker’s digital certificate could intercept any request that made by the Vivo Baby Application. Please kindly note if this thing could be done without changing anything at the installed .apk.
  • Asus’ point of view = the Attacker could easily learn the flow that made by the application with intercept every request.

Even the use of Cert. Pinning is not guarantee if the application couldn’t be intercept (since there are several ways to bypass it), then it could minimize the risk.

5.7. 0x07 – Full Path Disclosure at the Asus’ Web Service

Just like the previous one, not much that could be explained at this part. The only thing that we need to find out the full path disclosure at the web service that used by Asus is just remove the “ParaJson” parameter before we send it into the server.

Removing the ParaJson Parameter to get the Full Path Disclosure

As we could see from the picture above, the full path of this web service is located at e:\work\MKT\Project\ASUS_ID_2012\AWS_CusInfo\awscusinfo.asmx.

VI. INFORMATION AND SITUATION OF THIS POC

6.1. 0x01 – Lack of Binary Protection at HiVivo – Found Hardcoded Credentials
Generally, the concept of this one is not too different with the previous one. So basically, we could go directly into the proof of concept section to locate the main issue.

6.1.1. 0x01 – Proof of Concept
With the same way, we used “Show Java” Application for Android to decompile the .apk of HiVivo Application.

Directory Structure from Decompiled .APK

After the decompiling process is done, then once more we conduct a simple analysis and finally arrive at the “AsusAccountManager.java” that located at: “java” > “com” > “asus” > “account“. Without so many deep analysis, its already clear if the binary is not protected too with (for example) an obfuscation. Here is the sample result after we copied the decompiled .apk to our Desktop OS.

ClearText of Application’s Flow

At the other part, we also found the hardcoded DESede Key at Application just like we found it at VivoBaby Application.

Found DESede Key at Application

With this kind of result, then we could conduct the same thing such as part 0x02 and 0x03 that previously explained at this report.

VII. ADDITIONAL NOTE

As we could see, Asus has fixed the issue related the “lack of obfuscation” that found at both of android application. But there is another problem related this fix, which is, Asus didn’t change the found and reported hardcoded credentials that used by Asus to communicate to backend via WebService. When we realized this matter, then we tried to report the issue once more and told them if the risk still exist because the hardcoded credentials could be found by downloading the old .apk.

But looks like Asus has implement some hardening things at the related service so they look satisfied with the fixed (and didn’t change the hardcoded credentials, at least when this article was written). Please kindly note, we didn’t check it again. It just our prediction.

Here is the latest response from Asus when we asked the permission about to release the article if Asus has no plan to change the hardcoded credentials:

Permission to Release the Article

As another note, both of the CVE refers to the “Missing SSL Certificate Validation”.

VIII. LESSON LEARNED

One of the main lesson that we learned is, not every big company or famous company has the same secure SDLC process when creating the application.

From this case, we find out if almost all of the pre-installed Asus’ application at their phone has been hardened with the obfuscation. But when we try to check another Asus’ application at PlayStore and took it in random, then we find out if few applications didn’t harden with the obfuscation yet.

This situation could be a reference when we try to test the mobile application. Also, don’t forget to check the old one because there is a possibility if the information that embedded at the old one could be used in the current stage.

IX. REFERENCES

9.1. https://www.owasp.org/index.php/Mobile_Top_10_2014-M10
9.2. https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05c-Reverse-Engineering-and-Tampering.md
9.3. https://en.wikipedia.org/wiki/Brute-force_attack
9.4. https://en.wikipedia.org/wiki/CAPTCHA
9.5. https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
9.6. https://www.owasp.org/index.php/Pinning_Cheat_Sheet
9.7. https://cwe.mitre.org/data/definitions/295.html
9.8. http://cwe.mitre.org/data/definitions/321.html
9.9. https://www.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_(OTG-AUTHZ-004)
9.10. https://tools.ietf.org/html/rfc7235#section-4.2

Add Your Comment