On Android and iOS, accessibility features are available to help people use their smartphones: audio comments, subtitles, custom display… Some mobile applications designed with an inclusive approach are compatible with accessibility services.
To enable these services in an application, it requires the accessibility permission. But this permission gives applications full access to the user’s device. Today, more and more cybercriminals are leveraging it to take control of smartphones and tablets. When this happens, users find themselves in a bind, unable to uninstall the app or even reset their device.
Recently, the Pradeo Security solution neutralized an application using Android accessibility services for malicious purposes on a protected device. The identified malware was installed through a phishing link. It pretends to be a QR code scanning application but actually exploits the accessibility permission to perform fraudulent banking transactions.
The risks of mobile accessibility services
An application can use the android.permission.BIND_ACCESSIBILITY_SERVICE permission in order to benefit from advanced features facilitating accessibility to users with disabilities. With this permission, an application can control the whole screen (clicks, moves…) as well as the keyboard, read what is displayed and close or open applications.
These features are sensitive because they enable the control of almost all layers of a device. When a malicious application is granted the accessibility permission, it can send all the information displayed on the screen and typed on the keyboard to a remote server, prevent its own removal or a system reset, and even launch itself automatically when the device is rebooted. Unfortunately, the distribution channels used by hackers such as unofficial application stores and messaging services (SMS) do not provide any protection against this threat.
Case study: QR-Code Scanner
Name of the analyzed app: QR-Code Scanner
Package name: com.square.boss
OS: Android
The “QR-Code Scanner” application appears as a QR code scanning application. Its icon and name are not suspicious. However, when launched, no QR code scanning functionality is offered.
Immediately, the application sends a notification that urges to grant the accessibility option, which is necessary for the execution of its attack. As long as the user does not allow it, it continuously sends the same permission request.
Once authorized, the malware can silently approve its own permission requests in place of the user. Thus, it grants itself all the permissions that will allow it to carry out its attack.
In this case, our analysis of the malware suggests that the goal of the hacker behind the application is to commit fraud, by collecting data that the user types or displays on his screen (login, password, credit card numbers …) and intercepting the temporary authentication code sent.
First, the QR-Code Scanner application accesses the list of applications installed on the victim’s device to gauge interest. When banking or e-commerce applications are used, there is a greater chance that banking data is manipulated by the user. When it happens, the hacker collects them.
To enter the victim’s account or make a payment with his credit card, the hacker intercepts the one-time password contained in an SMS or a notification. Hence, he bypasses all security measures that authenticate payments and connections using a code. Only verification protocols that use biometric data are safe at this point.
Finally, the application uses the victim’s phone to spread to other devices. To do this, it sends an SMS containing a phishing link to the entire contact list. This way, the message comes from a known number and has a better chance of convincing the recipients to install the malware.
Throughout the attack, the malware exploits accessibility services to:
- Spy on users activity
- Grant and prevent the rejection of the permissions it needs
- Prevent removal of the application, either from the homepage or from the settings
- Prevent factory reset, even from a third-party device
- Prevent sleep or shutdown of its process
- Launch at startup
The permissions used by the malware are the following:
android.permission.QUERY_ALL_PACKAGES
android.permission.QUICKBOOT_POWERON
android.permission.RECEIVE_LAUNCH_BROADCASTS
android.permission.GET_TASKS
android.permission.SYSTEM_ALERT_WINDOW
android.permission.RECEIVE_SMS
android.permission.READ_SMS
android.permission.WRITE_SMS
android.permission.SEND_SMS
android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS
android.intent.action.BOOT_COMPLETED
com.htc.intent.action.QUICKBOOT_POWERON
android.intent.action.QUICKBOOT_POWERON
android.permission.RECEIVE_BOOT_COMPLETED
android.permission.QUICKBOOT_POWERON
Protective measures
Despite the undeniable need for accessibility services, the advanced rights they offer on the system mean that they must be used (on the developer side) and authorized (on the user side) with due consideration.
Today, only a few tools and remediation actions are effective to neutralize the analyzed malware:
- Blocking the application before launching it with Pradeo Security
- Forcing the uninstallation of the application with Pradeo Security for Samsung
- Uninstalling via a device management solution (UEM, MDM)
- Uninstalling via ADB command
OpenSSL Announces “Critical” Fix Slated For Next Week
Posted in Commentary with tags OpenSSL on October 28, 2022 by itnerdThe OpenSSL project team put out an announcement earlier this week that a “critical” fix was coming next week:
Now of course OpenSSL isn’t going to say what the issue is before the fix is available. But the fact that they called it “critical” means that it is not good and that if you use OpenSSL, you should upgrade to this release ASAP. Another data point, the last time that OpenSSL issued a critical vulnerability patch was in 2016, and this is just the second patch to be assigned a critical rating. So you know it’s bad. Whatever it is.
Mattias Gees, Container Product Lead at Venafi had this comment:
The announcement of the new OpenSSL critical vulnerability immediately brought back not-so-fond memories of Heartbleed or – more recently – the Log4J vulnerability. Heartbleed had a significant impact on all operations teams worldwide, and since then IT infrastructure has become 10 times more complicated. When Heartbleed was discovered, the majority of IT organizations were using dedicated hardware or virtual machines (VMs). But now we are in the Cloud Native era, which has created advanced containers and serverless architectures.
The attack vector has become a lot larger, and rather than just having to examine their VMs, organizations need to start preparing to patch all their container images in response to this announcement. Hopefully, the Log4J vulnerability triggered a lot of teams to audit their dependencies. If this is the case, these steps will help teams quickly roll out a targeted fix on their infrastructure. SBOMs (Software Bill of Materials) of all container images are a great start to gaining those insights into the dependencies in your applications and infrastructure.
We also now know that OpenSSL versions prior to 3.0 are not impacted, and a lot of operating systems use OpenSSL 1.1, so these environments won’t be impacted. This knowledge will allow cybersecurity and operations teams to dismiss large sections of their infrastructure, and hopefully make the impact of this vulnerability smaller than initially expected. But platform engineering teams should keep investing in better auditing of their environments and their dependencies for the next threat, which is always just around the corner.
If this applies to you, I would keep an eye out on November 1st for this release and be prepared to apply patches as it is a safe bet that the bad guys are going to reverse engineer what this patch addresses and use it to launch attacks. I say that because if this was an active attack vector, I suspect that the patch would be out immediately. Thus while sysadmins have some time, it likely will not be a lot of time to patch this once the patch is out.
1 Comment »