Чекнул приложение и нашёл такие дыры Code: [Critical] <WebView><Remote Code Execution><#CVE-2013-4710#> [Critical] <Command> Runtime Command Checking Spoiler: Полный список дыр [Critical] <Command> Runtime Command Checking: This app is using critical function 'Runtime.getRuntime().exec("...")'. Please confirm these following code secions are not harmful: => Lcom/geetest/deepknow/f/c;->e()Ljava/lang/String; (0xc) ---> Ljava/lang/Runtime;->exec(Ljava/lang/StringLjava/lang/Process; => Lcom/geetest/deepknow/f/c;->j()[Ljava/lang/String; (0xe) ---> Ljava/lang/Runtime;->exec(Ljava/lang/StringLjava/lang/Process; => Lcom/geetest/deepknow/f/c;->k()[Ljava/lang/String; (0xe) ---> Ljava/lang/Runtime;->exec(Ljava/lang/StringLjava/lang/Process; [Critical] <#BID 64208, CVE-2013-6271#> Fragment Vulnerability Checking: 'Fragment' or 'Fragment for ActionbarSherlock' has a severe vulnerability prior to Android 4.4 (API 19). Please check: (1)http://developer.android.com/reference/android/os/Build.VERSION_CODES.html#KITKAT (2)http://developer.android.com/refere...tivity.html#isValidFragment(java.lang.String) (3)http://stackoverflow.com/questions/19973034/isvalidfragment-android-api-19 (4)http://securityintelligence.com/new-vulnerability-android-framework-fragment-injection/ (5)http://securityintelligence.com/wp-content/uploads/2013/12/android-collapses-into-fragments.pdf (6)https://cureblog.de/2013/11/cve-2013-6271-remove-device-locks-from-android-phone/ You MUST override 'isValidFragment' method in every "PreferenceActivity" class to avoid Exception throwing in Android 4.4: Lme/imid/swipebacklayout/lib/app/SwipeBackPreferenceActivity; All of the potential vulnerable "fragment": Landroid/arch/lifecycle/l; Lcom/bumptech/glide/b/k; Lcom/d/a/c; Lcom/a5th/exchange/lib/base/b; Lcom/bumptech/glide/b/o; [Critical] <Implicit_Intent> Implicit Service Checking: To ensure your app is secure, always use an explicit intent when starting a Service and DO NOT declare intent filters for your services. Using an implicit intent to start a service is a security hazard because you cannot be certain what service will respond to the intent, and the user cannot see which service starts. Reference: http://developer.android.com/guide/components/intents-filters.html#Types => com.google.firebase.iid.FirebaseInstanceIdService [Critical] <SSL_Security> SSL Implementation Checking (Verifying Host Name in Custom Classes): This app allows Self-defined HOSTNAME VERIFIER to accept all Common Names(CN). This is a critical vulnerability and allows attackers to do MITM attacks with his valid certificate without your knowledge. Case example: (1)http://osvdb.org/96411 (2)http://www.wooyun.org/bugs/wooyun-2010-042710 (3)http://www.wooyun.org/bugs/wooyun-2010-052339 Also check Google doc: http://developer.android.com/training/articles/security-ssl.html (Caution: Replacing HostnameVerifier can be very dangerous). OWASP Mobile Top 10 doc: https://www.owasp.org/index.php/Mobile_Top_10_2014-M3 Check this book to see how to solve this issue: http://goo.gl/BFb65r To see what's the importance of Common Name(CN) verification. Use Google Chrome to navigate: - https://www.google.com => SSL certificate is valid - https://60.199.175.158/ => This is the IP address of google.com, but the CN is not match, making the certificate invalid. You still can go Google.com but now you cannot distinguish attackers from normal users Please check the code inside these methods: Lcom/geetest/deepknow/utils/e$1;->verify(Ljava/lang/String; Ljavax/net/ssl/SSLSessionZ [Critical] <SSL_Security> SSL Connection Checking: URLs that are NOT under SSL (Total:2): http://static.geetest.com/static/appweb/app3-index.html => Lcom/geetest/sensebot/dialog/c;->d()V http://www. => Lcom/google/zxing/client/result/optional/NDEFURIResultParser;-><clinit>()V [Critical] <SSL_Security> SSL Certificate Verification Checking: This app DOES NOT check the validation of SSL Certificate. It allows self-signed, expired or mismatch CN certificates for SSL connection. This is a critical vulnerability and allows attackers to do MITM attacks without your knowledge. If you are transmitting users' username or password, these sensitive information may be leaking. Reference: (1)OWASP Mobile Top 10 doc: https://www.owasp.org/index.php/Mobile_Top_10_2014-M3 (2)Android Security book: http://goo.gl/BFb65r (3)https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=134807561 This vulnerability is much more severe than Apple's "goto fail" vulnerability: http://goo.gl/eFlovw Please do not try to create a "X509Certificate" and override "checkClientTrusted", "checkServerTrusted", and "getAcceptedIssuers" functions with blank implementation. We strongly suggest you use the existing API instead of creating your own X509Certificate class. Please modify or remove these vulnerable code: [Confirm Vulnerable] => Lcom/geetest/deepknow/utils/e$a; -> used by: Lcom/geetest/deepknow/utils/e;->a(Ljava/lang/String; [B I)Ljava/lang/String; -------------------------------------------------- [Maybe Vulnerable (Please manually confirm)] => Lio/fabric/sdk/android/services/network/g; -> used by: Lio/fabric/sdk/android/services/network/e;->a(Lio/fabric/sdk/android/services/network/fLjavax/net/ssl/SSLSocketFactory ; => Lcom/a5th/exchange/lib/http/f/c$1; -> used by: Lcom/a5th/exchange/lib/http/f/c;->c()[Ljavax/net/ssl/TrustManager; [Critical] AndroidManifest Critical Use Permission Checking: This app has very high privileges. Use it carefully. Critical use-permission found: "android.permission.RESTART_PACKAGES" [Critical] <WebView><Remote Code Execution><#CVE-2013-4710#> WebView RCE Vulnerability Checking: Found a critical WebView "addJavascriptInterface" vulnerability. This method can be used to allow JavaScript to control the host application. This is a powerful feature, but also presents a security risk for applications targeted to API level JELLY_BEAN(4.2) or below, because JavaScript could use reflection to access an injected object's public fields. Use of this method in a WebView containing untrusted content could allow an attacker to manipulate the host application in unintended ways, executing Java code with the permissions of the host application. Reference: 1."http://developer.android.com/refere....html#addJavascriptInterface(java.lang.Object, java.lang.String) " 2.https://labs.mwrinfosecurity.com/bl...addjavascriptinterface-remote-code-execution/ 3.http://50.56.33.56/blog/?p=314 4.http://blog.trustlook.com/2013/09/0...scriptinterface-code-execution-vulnerability/ Please modify the below code: => Lcom/geetest/sensebot/dialog/c;->d()V (0x1dc) ---> Lcom/geetest/sensebot/dialog/SEWebViewUtils;->addJavascriptInterface(Ljava/lang/Object; Ljava/lang/StringV => Lcom/geetest/sensebot/dialog/GT3GtWebView;->addJavascriptInterface(Ljava/lang/Object; Ljava/lang/StringV (0x1a) ---> Landroid/webkit/WebView;->addJavascriptInterface(Ljava/lang/Object; Ljava/lang/StringV => Lcom/geetest/sensebot/dialog/SEWebViewUtils;->addJavascriptInterface(Ljava/lang/Object; Ljava/lang/StringV (0x1a) ---> Landroid/webkit/WebView;->addJavascriptInterface(Ljava/lang/Object; Ljava/lang/StringV [Warning] External Storage Accessing: External storage access found (Remember DO NOT write important files to external storages): => Lcom/geetest/sensebot/g;->b()Ljava/lang/String; (0x0) ---> Landroid/os/Environment;->getExternalStorageDirectory()Ljava/io/File; => Lcom/github/moduth/blockcanary/b;->b()Ljava/lang/String; (0x3a) ---> Landroid/os/Environment;->getExternalStorageDirectory()Ljava/io/File; => Lcom/github/moduth/blockcanary/b;->b()Ljava/lang/String; (0x58) ---> Landroid/os/Environment;->getExternalStorageDirectory()Ljava/io/File; => Lcom/zxing/a;->a(Landroid/content/Context; Landroid/net/UriLjava/lang/String; (0x66) ---> Landroid/os/Environment;->getExternalStorageDirectory()Ljava/io/File; => Lcom/a5th/exchange/module/safe/fragment/VerifyGoogleStep2Fragment;->al()V (0xa) ---> Landroid/os/Environment;->getExternalStorageDirectory()Ljava/io/File; => Lcom/a5th/exchange/module/assets/activity/DepositActivity;->r()V (0xa) ---> Landroid/os/Environment;->getExternalStorageDirectory()Ljava/io/File; => Lcom/a5th/exchange/module/auth/activity/IdAuthStep2Activity;->u()Ljava/lang/String; (0xa) ---> Landroid/os/Environment;->getExternalStorageDirectory()Ljava/io/File; [Warning] AndroidManifest Exported Components Checking: Found "exported" components(except for Launcher) for receiving outside applications' actions (AndroidManifest.xml). These components can be initilized by other apps. You should add or modify the attribute to [exported="false"] if you don't want to. You can also protect it with a customized permission with "signature" or higher protectionLevel and specify in "androidermission" attribute. service => com.google.firebase.iid.FirebaseInstanceIdService [Warning] <Sensitive_Information> Getting IMEI and Device ID: This app has code getting the "device id(IMEI)" but there are problems with this "TelephonyManager.getDeviceId()" approach. 1.Non-phones: Wifi-only devices or music players that don't have telephony hardware just don't have this kind of unique identifier. 2.Persistence: On devices which do have this, it persists across device data wipes and factory resets. It's not clear at all if, in this situation, your app should regard this as the same device. 3.Privilege:It requires READ_PHONE_STATE permission, which is irritating if you don't otherwise use or need telephony. 4.Bugs: We have seen a few instances of production phones for which the implementation is buggy and returns garbage, for example zeros or asterisks. If you want to get an unique id for the device, we suggest you use "Installation" framework in the following article. Please check the reference: http://android-developers.blogspot.tw/2011/03/identifying-app-installations.html => Lcom/geetest/deepknow/f/c;->g(Landroid/content/ContextLjava/lang/String; (0x2a) ---> Landroid/telephony/TelephonyManager;->getDeviceId()Ljava/lang/String; => Lcom/github/moduth/blockcanary/a/a;-><clinit>()V (0x92) ---> Landroid/telephony/TelephonyManager;->getDeviceId()Ljava/lang/String; [Warning] <Sensitive_Information> Getting ANDROID_ID: This app has code getting the 64-bit number "Settings.Secure.ANDROID_ID". ANDROID_ID seems a good choice for a unique device identifier. There are downsides: First, it is not 100% reliable on releases of Android prior to 2.2 (Froyo). Also, there has been at least one widely-observed bug in a popular handset from a major manufacturer, where every instance has the same ANDROID_ID. If you want to get an unique id for the device, we suggest you use "Installation" framework in the following article. Please check the reference: http://android-developers.blogspot.tw/2011/03/identifying-app-installations.html => Lcom/geetest/deepknow/f/c;->f(Landroid/content/ContextLjava/lang/String; (0x10) ---> Landroid/provider/Settings$Secure;->getString(Landroid/content/ContentResolver; Ljava/lang/StringLjava/lang/String; => Lio/fabric/sdk/android/services/b/i;->f(Landroid/content/ContextZ (0xc) ---> Landroid/provider/Settings$Secure;->getString(Landroid/content/ContentResolver; Ljava/lang/StringLjava/lang/String; => Lcom/google/android/gms/measurement/a/dv;->b(Lcom/google/android/gms/measurement/a/e; Lcom/google/android/gms/measurement/a/ejV (0x810) ---> Landroid/provider/Settings$Secure;->getString(Landroid/content/ContentResolver; Ljava/lang/StringLjava/lang/String; [Warning] <WebView> WebView Local File Access Attacks Checking: Found "setAllowFileAccess(true)" or not set(enabled by default) in WebView. The attackers could inject malicious script into WebView and exploit the opportunity to access local resources. This can be mitigated or prevented by disabling local file system access. (It is enabled by default) Note that this enables or disables file system access only. Assets and resources are still accessible using file:///android_asset and file:///android_res. The attackers can use "mWebView.loadUrl("file:///data/data/[Your_Package_Name]/[File]");" to access app's local file. Reference: (1)https://labs.mwrinfosecurity.com/blog/2012/04/23/adventures-with-android-webviews/ (2)http://developer.android.com/reference/android/webkit/WebSettings.html#setAllowFileAccess(boolean) Please add or modify "yourWebView.getSettings().setAllowFileAccess(false)" to your WebView: Lcom/a5th/exchange/module/global/activity/WebViewActivity;->n()V Lcom/geetest/deepknow/utils/DPWebViewClient;-><init>(Landroid/webkit/WebViewV Lcom/geetest/sensebot/dialog/SEWebViewUtils;->d()V [Warning] <WebView> WebView Potential XSS Attacks Checking: Found "setJavaScriptEnabled(true)" in WebView, which could exposed to potential XSS attacks. Please check the web page code carefully and sanitize the output: => Lcom/geetest/deepknow/utils/DPWebViewClient;-><init>(Landroid/webkit/WebViewV (0x1a) ---> Landroid/webkit/WebSettings;->setJavaScriptEnabled(Z)V => Lcom/geetest/sensebot/dialog/SEWebViewUtils;->d()V (0x10) ---> Landroid/webkit/WebSettings;->setJavaScriptEnabled(Z)V => Lcom/a5th/exchange/module/global/activity/WebViewActivity;->n()V (0x64) ---> Landroid/webkit/WebSettings;->setJavaScriptEnabled(Z)V И теперь такой вопрос, реально взломать сервер приложения ?
Через RCE хоть что можно сделать, вот только я с RCE сталкивался на web приложениях Как его юзать на приложениях под андроид ?
