NOTE: This was coordinated with human right activists, vulns reported, etc.
Previous blog posts you might have missed and maybe you would like to read first for background:
The OWASP Mobile Application Security Verification Standard classifies the flaw explained in this blog post, under section V5: Network Communication Requirements, as follows:
MSTG-NETWORK-1: Data is encrypted on the network using TLS. The secure channel is used consistently throughout the app.
Detailed information and steps to test for this kind of issue can be found in the OWASP Mobile Security Testing Guide:
- (General) Testing Network Communication
- Android Testing Network Communication
- iOS Testing Network Communication
So, how seriously does MOIBA take SSL / TLS?
Well, as I write this blog post in 2019 and I am trying to add links to their website, I notice that:
- The main site uses clear-text HTTP and does not even redirect to HTTPS: http://moiba.net
- https://www.moiba.or.kr/ uses an invalid certificate
So, if they do that with their website now, what did they do with their apps when we tested them? now you know where this is going 🙂
SSL? What is it? 🙂
So, as we started to review this app, we reviewed the decompiled sources and found that the app, this app that was supposed to protect children, was just sending all data over clear-text HTTP. This was also confirmed at runtime: All web traffic and API requests were sent over clear-text HTTP.
Object obj1 = “http://ssweb.moiba.or.kr/pushAlarm”;
When you review a mobile app, you should always look for TLS usage to protect network communications between the app and the backend servers.
Mobile phones favor Wi-Fi over LTE as typically Wi-Fi is free, while LTE/4G/etc. costs money or you usually have a cap of X GB / month in your data plan.
This means that in places like an airport, hotel, restaurant or anywhere else where public Wi-Fi is offered, data sent from a parent or child app would be leaked over clear-text HTTP for anybody to see over the air.
Here is a snippet from the public report about it:
SMS-01-003 No use of any SSL/TLS-based transport security ( High )
All network requests made by the Smart Sheriff mobile app are executed using insecure clear-text HTTP, hence sending personal information, mobile numbers, passwords, etc. without any cryptographic protection such as SSL/TLS. This is especially concerning in a mobile app, given that mobile devices generally favor WiFi over mobile data usage.
The test could not identify a single HTTP request using the scheme https:// at runtime and a number of searches on the reversed APK yielded no results for “https”-URLs:
grep -r moiba.or.kr source/ | tr '”‘ ” ” | tr ” ” ”\n” | grep https | wc -l
0 <– NO SSL used, at all, in the entire project!!!
This finding shows that the entire architecture employed by the app was constructed with no attention to transport security whatsoever. Since there are no encrypted connections being used, anyone with access to the network that a Smart Sheriff user is operating in can almost arbitrarily manipulate phone and app via MitM.
Hack Smart Sheriff to pieces with us!
NOTE: Attendants will get lifetime access to our training portal with:
– Unlimited course updates & Step-by-step lab video recordings
– Lots of real-world apps to practice with, such as:
+ Government-mandated and police apps in various countries
+ Many other excitingly vulnerable real-world apps!
+ IoT apps controlling Toys, Drones, etc.
- Global AppSec Amsterdam, EU: 23-25 September 2019
- c0c0n, Kochi, India: 25-26 September 2019
- LASCON, Austin, TX, USA: 22-23 October 2019
Cannot make it? ping email@example.com for training portal access.
Recorded Talk 3: BruCON
I believe the third time Fabian and myself presented this was at BruCON. As this was after the summer, at this stage Fabian had done more research about Smart Dream and other similar apps (during his summer stay at Citizen Lab):
Next blog post:
Hacking Mandated Apps – Part 4: How NOT to implement SSL [ MSTG-NETWORK-2 ]