Our app has been in the Play Market for 4 years.
Before the last build, we added AppMetrica in the app:
implementation 'com.yandex.android:mobmetricalib:3.13.1'
implementation 'com.android.installreferrer:installreferrer:1.1.2'
implementation 'com.yandex.android:mobmetricapushlib:1.5.1'
The project with these instruments was successfully uploaded into the Play Market without any notifications (errors or warnings). In a few weeks after that, I made minor changes in sending reports in the AppMetrica and received the following notification from Google:
"We reviewed XXX, with package name XXX, and found that your app uses software that contains security vulnerabilities for users. Apps with these vulnerabilities can expose user information or damage a user’s device, and may be considered to be in violation of our Malicious Behavior policy.
Below is the list of issues and the corresponding APK versions that were detected in your recent submission. Please migrate your apps to use the updated software as soon as possible and increment the version number of the upgraded APK.
Vulnerability TrustManager You can find more information about TrustManager in this Google Help Center article."
We don't use TrustManager and his classes in the project.
What can be the possible reason for rejecting? Is it possible that this rejection was made by mistake? How can we find out what is the reason for that? Can AppMetrica cause this setback and should we stop using it?
Also, in the rejection text they said you can set up the network config (https://developer.android.com/training/articles/security-config) in the app -- how can it help?
We are fighting this trouble for two weeks and we hope for your help
Related
Just made an installer (using QTIFW) for my Qt project but when I tried to install it on other machine the 360 Total Security interrupted the installation process.
It pops up and complains about d3dcompiler_47.dll, asking the user to allow/block the file. If user do nothing, or don't allow, it
seems to be preventing QTIFW of writing it as part of the application installation.
That led to following error
Can't create C:\Program Files\company\project\d3dcompiler_47.dll"
That's quite terrible. I'm wondering how to deal with this situation?
False Positives: False positives from maleware scanners can be quite hard to deal with. To check using more than one malware scanner you can upload the release files individually as well as the complete setup to https://www.virustotal.com. This service runs many malware scanners on the submitted files so you can see what malware scanners flag which binary. There are a few other such anti-malware online scanners such as Kaspersky, Avira, etc...
Update: And then there is Process Explorer. Check this tweet chain for how to check your running application for malware hits per process and loaded file.
When you see the scope of the problem (how many files are flagged), you should work backwards to see how you could go about solving the problem. This can involve getting the files whitelisted by the malware vendor(s), eliminating them from your setup, or fixing technicalities that flag the files, etc... There are some options listed and elaborated below.
Fixes: There are both technical and practical fixes you can try. Don't expect it to be easy. The issue of false positives is a very serious deployment problem. The proposed fixes and workarounds below are in random order:
Compiler Settings: Sometimes you can actually choose different compiler settings to avoid the problem, but often you are not so lucky. I have seen this with files compiled with special Spectre / Meltdown mitigation settings. They were flagged as unknown by malware scanners.
Dangerous API-calls: You should also check what API-calls are made in the problem file(s) that could be known to cause security warnings (unusual and / or dangerous API-methods) - and remove them if you can. I have heard of cases where malware vendors want to refuse to whitelist your binary because what the binary does makes no sense to them (try calling a firmware update for an embedded system as part of your setup installation or some low-level call triggered by a security tool you are installing).
Eliminate Files: Removing certain components from your application can also help sometimes - especially if they are third-party components added to your application for convenience only. In other words your application works fine without them. Removing a problem can be much simpler than fixing it.
Vanilla Installer: Sometimes you can split problem components into a separate setup so your main setup installs without issues. This can help enormously with support issues or overall application approval in corporate settings. You can also make 2 full setups where one has all probable false-positive triggers removed - your "vanilla setup" that should install without drama in all cases.
Digital Signatures: Signing the file with a digital signature can help since a proper certificate "buys trust outright" in reputation-based score systems such as Microsoft SmartScreen. Note that this needs to be an EV-level certificate. Please check for updated information here as technology evolves. Certificate / signing technologies always seem to cause something unexpected.
Malware Scanner Whitelisting: Submit file for white listing. Then there is the formal approach with the malware vendors as explained by Bogdan Mitrache of Advanced Installer here: Antivirus Whitelisting Pains. You submit files to them for white-listing. The article explains real-world experience with binaries flagged as malware when delivering software. Mandatory reading.
Microsoft SmartScreen: Microsoft has their own way to submit files for analysis and white-listing: https://www.microsoft.com/en-us/wdsi/filesubmission. They state: "Microsoft security researchers analyze suspicious files to determine if they are threats, unwanted applications, or normal files. Submit files you think are malware or files that you believe have been incorrectly classified as malware.".
Unique Executable Per Customer: Sometimes a unique executable is used for every customer by auto-generating an installer for each sale. I would advise against this since the installer executable - even when signed - will be a "new encounter" for malware scanners. You could run into trouble you do not need. There is also an added risk for each generated installer executable to actually be infected by real malware, and there is also the QA-issue that every installer should be tested before release.
Signed Malware: Whatever you do, make sure the file in question isn't actually real malware! Obviously your own files can get infected. Test well. If you sign malware and deliver to your client the digital signature is proof positive that you delivered the malware to them. Not good. And then.
More on Digital Signatures: Some information and links to get your setup and / or files signed:
https://www.advancedinstaller.com/user-guide/faq-digital-signature.html
https://knowledge.digicert.com/generalinformation/INFO1119.html
https://www.thawte.com/resources/getting-started/how-code-signing-works/
Installshield Custom Dialogue Installer
I have been using different techniques for jailbreak detection and it was working fine till iOS 11.4. However when I upgraded my iOS to latest 11.4.1 it is showing me the device is jailbroken when the device is not. This issue we are facing only in iOS 11.4.1 and iOS 12 Beta.
Following were the techniques we are using:
1.Process forking
2."CydiaApp" Scheme Detection
3.Check for suspicious/root folders and files
4.Check for folders that was created during the jailbreak process
5.Check for write permission for non user folder
Is there any thing related to these files and folder access permission we are doing wrong to detect the jailbreak detection?
Any help will be appreciated.
But which one is actually gives you false positive?
If I were to guess, I would say that checking write permissions is not reliable. The way that iOS protects unauthorized access to system files is not with permissions but mainly with sandbox profiles. With that in place Apple can assign any permissions they want to system files, sandboxing will still protect the system. Even when you jailbreak your phone you still have sandboxing in place (don't remember any jailbreak that would disable sandboxing completely) and often limited by it when, for example, injecting your CydiaSubstrate dylibs into system daemons/applications that operate under sandbox profiles. That's the whole security of iOS - code signing, entitlements, sandboxing, IPC. No need for POSIX permissions which Apple actually doesn't use that much.
Checking for suspicions directories and files could also give you false positives and is not very reliable in general. Apple often changes it's root file system, you never know what might be in the new iOS version. Of course, if it's related to Cydia then it should be ok.
And that's, in part, why Apple doesn't like AppStore apps checking for jailbreak and often rejects them because of it. Not only you try to access something you shouldn't, which makes it hard to distinguish between jailbreak detection and actual usage of private API to circumvent iOS security. But given that jailbreak is all about very specific kernel patches and things that you wouldn't have access inside AppStore app due to sandboxing anyway (launching unsigned binaries, modifying root partition), there's no reliable way of detecting jailbreak in general. Forking, Cydia, support for CydiaSubstrate - all of that is optional and depends on specific jailbreak implementation. With recent jalbreaks that's even more relevant - all of them are very different and not completely finished lacking some features that were standard in the past. Even more importantly, if Apple decides to change something in iOS, in might trigger jailbreak detecting code by accident. False positive is much worse than false negative.
In the end, no matter what you do, every jailbreak detection code can be easily patched or hooked. When you're in control of the system, apps are no longer able to protect themselves. That's all offtopic but it's a good reason to just ignore jailbreak.
I haven't had much success searching for this. I'm developing an Android Things application that will connect to a user phone to do certain things. I want to use this for delivering app updates as well.
So far, my crude searches on this have just discussed OTA via the Console and thus internet.
My gut has said that I could just build this - I could have a new version of the APK, transfer it to my device via bluetooth, and then just have the device copy it over the old one and reboot. But, not sure. I was hoping maybe there was an API for this and I'm just not wise enough to know how to find it via the searches.
I developed an app that'll stream a rtmp video. Before I used VitamioBundle-master. I upload my app in play store it shows some warning message for upgrading my app that has to use vitamio latest version. I download it from the link shown in that alert message. Now I develop the app using vitamio 5.0.2 downloaded from the link https://www.vitamio.org/en/Download/. Once I upload the app play store shows the same alert message
Security alert
Your app utilizes a version of Vitamio, a multimedia library used for playing various types of media files, containing a security vulnerability.
Please upgrade your app(s) as soon as possible and increment the version number of the upgraded APK. Beginning 14 March 2016, Google Play will block publishing of any new apps or updates that use pre-5.0 versions of Vitamio.
The vulnerability was addressed in Vitamio v5.0. The latest versions of Vitamio can be downloaded on the Vitamio website. You can confirm your Vitamio version by checking if the SDK includes libs/armeabi-v7a/libvinit.so or libs/armeabi/libvinit.so. If either file is present, the SDK needs to be upgraded. For help upgrading, see the Vitamio support documentation. If you’re using a 3rd party library that bundles Vitamio, please notify the 3rd party and work with them to address this.
To confirm you’ve upgraded correctly, submit the updated version to the Developer Console and check back after five hours. If the app hasn’t been correctly upgraded, we will display a warning.
The vulnerability is due to the Vitamio SDK containing world-writable code. For more information about the vulnerability, please see this NowSecure blog post. For other technical questions, you can post to Stack Overflow and use the tags “android-security” and “vitamio.”
While these specific issues may not affect every app that uses Vitamio, it’s best to stay up to date on all security patches. Apps with vulnerabilities that expose users to risk of compromise may be considered in violation of our Malicious Behavior policy and section 4.4 of the Developer Distribution Agreement.
Apps must also comply with the Developer Distribution Agreement and Developer Program Policies. If you feel we have sent this warning in error, contact our policy support team through the Google Play Developer Help Center.
I gone through several solutions mentioned in different tutorial but not yet get a clear idea. Can anyone tell me the step by step procedure for updating my vitamio sdk version, or else is there any other lib for streaming rtmp video in my Android app?
Unfortunately, Vitamio 5.0.2 added back the old libvinit.so file, so it gets flagged as an old version of Vitamio. You can just delete libvinit.so and it should work.
I am trying to connect my tessel to firebase, and I have tried everything. Is anyone else having a similar problem? I have read that the tessel uses different web sockets than firebase, but I am really new and don't know much about that. Could anyone help me out?
Glad to hear that people are interested in using Firebase with the Tessel. I'm one of the Firebase engineers who has been working with the Tessel folks to make this happen. There are two Tessel Forum posts that give some more detail on the problem:
Firebase cannot be compiled by Colony
Websockets on Tessel
The Firebase node packages uses faye-websockets, which the Tessel compiler couldn't support. We got nodejs-websockets to compile, and built a version of the Firebase library to test the concept. I was able to read and write from Firebase using the Tessel, but we were very hesitant to release a separate version of Firebase to NPM just for use on the Tessel, especially since nodejs-websockets is not as well maintained as faye-websockets. I then spent an evening working with the Tessel folks to get faye-websockets working, and it now compiles, with the changes sitting out on a branch (tessel/runtime/JH-HTTPParser). I don't have a timeframe on these getting merged into Master and being shipped out to production, but I know there are a good number of SSL and websocket based API's who are waiting on these changes to hit the main branch.
TL;DR: Firebase compiles on the Tessel (you can build the code off the above branch), and it can either read or write (not both at the same time). When I get some more time, I will be debugging Tessel + Firebase to get this working correctly.
With the acquisition I haven't had much time to try. Last time I checked, things were compiling and running for some operations (I haven't tested everything) if we used a non-minified version of the Firebase library (not currently provided to end users). The issue here is that the minification puts all the variables in the same line, and the Tessel Lua VM would complain that there were more than 200 variables and wouldn't like it. I can play around with it some over the next week and see where things are, otherwise I can ping Jon and the Tessel folks to see how we can best move this issue along.
I am using SynergyKit for realtime communication. You can download Node.js library, which is fully supported by tessel platform and using websocket library, which is one of few libraries written in pure javascript.
You will be able to live observing all data in collections and sending messages. There is documentation for Node.js.