OWASP Mobile Top 10 Risks (2024) | Detailed Explaination with Examples | Payatu

Keep up with the constantly evolving mobile security landscape by exploring the emerging risks part of the latest OWASP Mobile top 10.
ℹ Webinar Outline:
- Noteworthy updates to the OWASP Mobile Top 10 Risks
- Understanding the risks with scenarios and examples
- Other security risks not covered in the OWASP Top 10
Webinar Outcome:
🎯 Participants will get familiar and gain a high-level understanding of the latest iteration of OWASP Mobile top 10 risks
🎯 Practical insights into several top 10 risks and associated vulnerabilities
Who should watch the Webinar?
Developers, security professionals, organizations aiming to build resilient mobile apps and anyone interested in keeping up with the latest mobile application risks
Tools:
MobSF, Jadx-GUI, apktool
For more webinars like this join our Payatu's exclusive Cybersecurity WhatsApp community:
➡️ chat.whatsapp.com/GRRfW8wcd1g...

[@adilhashmi7608]

please provide the link for the smali chellenges apk

[@payatu]

The smali challenges application that was used for demonstration in the webinar is not publicly available. We will be introducing smali patching challenges in the future releases of Payatu’s BugBazaar Android application.
As of now, you can attempt to tackle the smali patching challenge in another publicly available vulnerable app for Android - allsafe (github.com/t0thkr1s/allsafe).
You can also take up the challenge of writing a small application of your own in Android Studio and then attempt to patch and rebuild that application’s smali code. The following blog can serve as a guide to help you navigate this task.
payatu.com/blog/an-introduction-to-smali/

[@mcnekss4904]

Nice ! u have any groupchat or any platform so i can catch any updates

[@payatu]

Hello! For frequent updates and more cybersecurity content like this join our exclusive Cybersecurity WhatsApp community:
➡️ chat.whatsapp.com/GRRfW8wcd1gJqimor8dcMI

[@newuser2474]

If all vulnerabilities are tested in rooted device but in real world almost everyone has non rooted device so how these attacks are feasible in real world scenarios

[@payatu]

Your question about requirement for rooted device for testing vulnerabilities is quite broad, however I will try to address it using examples covered in the video.
A rooted device with all the necessary utilities and attack frameworks is an attacker’s preferred tool/setup for pentesting an application. Pentesters require root access to evaluate the application’s security. This access is required for bypassing certificate pinning, necessary for intercepting HTTP communication between the app and a remote server. Root access is also vital for examining security best practices like secure data storage and secrets handling practices.
Dynamic instrumentation (runtime manipulation) tools like frida also require device root access for utilization of the tool’s full capability and features.
However, not all vulnerabilities require a rooted device to be tested.
The vulnerabilities that are discovered are classified according to severity, context and the feasibility of exploitation. The target of vulnerabilities is either the application itself (code, server and other infra) or the application’s users. Usually, when something is classified as a vulnerability - a scenario of exploitation is demonstrated or the security risk is highlighted.
For example, the pincode bypass attack demonstrated in the video was attempted on a rooted device and a dynamic instrumentation/runtime manipulation tool (frida) was used to alter a specific block of the application’s code at runtime. The exploitation of this particular vulnerability will not be possible without the attacker having physical access to the victim’s device. Runtime manipulation is can still be attempted with physical access to the victim’s non-rooted device using a tool like frida-gadget (mas.owasp.org/MASTG/techniques/android/MASTG-TECH-0026/). Although the severity of this vulnerability will be adjusted according to the likelihood of exploitation, which is low in this scenario and the impact is limited because physical access to the victim’s device is required. The primary flaw here is that the application is not secured against runtime manipulation and the impact would allow an attacker to bypass the logic of the pin-based authentication.
In another example, a scenario was demonstrated where a deep link can be crafted that triggers an unsafe state-changing action during it’s handling and leads to a vulnerability. In this case, the victim/target is another user of the vulnerable application and whether the attack is delivered to the victim user via a rooted or non-rooted device is irrelevant. Successful exploitation can be achieved by crafting the exploit (deep link) and delivering it to the victim’s device via a phishing page/social messenger/email and for the victim to click on that deep link.
I hope this information helped clarify your doubts to an extent about the role of rooted and non-rooted devices in testing android application vulnerabilities.

[@newuser2474]

@@payatu hi thanks! For the detailed explanation. To some extent it clarifies my doubt. I will research more on this. Thank you once again.