[HN Gopher] Technical Analysis - Improper Use of Private iOS API...
___________________________________________________________________
Technical Analysis - Improper Use of Private iOS APIs in Vietnamese
Banking Apps
Author : quyleanh
Score : 72 points
Date : 2025-03-28 07:04 UTC (3 days ago)
(HTM) web link (blog.verichains.io)
(TXT) w3m dump (blog.verichains.io)
| quyleanh wrote:
| Original hightlight from @opa334, developer of TrollStore [0].
| There are also some sharing about that on his page like sandbox
| escape published by @wh1te4ever [1]
|
| 0: https://infosec.exchange/@opa334/114224756352953362
|
| 1:
| https://gist.github.com/wh1te4ever/c7909dcb5b66c13a217b49ea3...
| petesergeant wrote:
| So, the post author makes software for checking if bad apps are
| running on the phone, and is complaining that the banks are using
| their own home-grown system that they say violates Apple's rules
| for checking for malicious apps, rather than doing is safely like
| the software the author sells does.
| lmz wrote:
| I think some people pointed to them as the vendor behind the
| home grown system, and this is their denial.
| Onavo wrote:
| For these sort of large, well connected, or state owned
| companies in Asia (banks, big local unicorns etc.), Apple has a
| lot of carve-outs and exceptions (see do-everything apps that
| contain mini app stores). They have to play nice else they find
| themselves "under investigation" or worse lose access to the
| entire market. There's no rule of law for them to litigate over
| breach of contract.
| jjani wrote:
| > Apple has a lot of carve-outs and exceptions (see do-
| everything apps that contain mini app stores)
|
| Which ones are you thinking of? Does Grab operate this way?
|
| The China case is well-known, but that's really its own
| beast. KakaoTalk (Korea), while more of an 'everything' app
| than those in the West, is still a far cry from containing a
| mini app store. A user can't choose to add any new
| functionality by installing something - it's all included
| right from the get-go. My (limited) experience with Line
| (Japan, Taiwan, Thailand) is similar. So I'm curious if
| there's any non-Chinese apps you can name.
|
| FWIW I'm not arguing against your fundamental premise, would
| just like to know which do-everything apps you mean.
| alephnerd wrote:
| Grab isn't a good example of an "everything app". Zalo is
| probably the closest to WeChat and Line.
| agos wrote:
| there might be no rule of law but it's important to point out
| these exceptions because it weakens Apple's position when
| they harass other developers with the excuse of maintaining
| whatever it is that the walled garden provides
| alephnerd wrote:
| Sadly, it goes well beyond BIDV and Agribank as well. There is a
| lot of similar hacky fingerprinting done by all the Vietnamese
| banking apps.
|
| My understanding is it's because there was some regulatory change
| in the last 1-2 years requiring identity fingerprinting using
| banking apps, and partially related with the new biometrics
| rollout [0]
|
| [0] - https://xaydungchinhsach.chinhphu.vn/huong-dan-cai-dat-
| sinh-...
| NotPractical wrote:
| So the law is now requiring that you find zero day exploits in
| iOS in order to make a banking app? Are there banking websites
| you can use instead? Are criminals incapable of using these
| websites for malicious purposes?
| a012 wrote:
| The banking apps exploited non-public APIs to provide
| "protection" for users, it doesn't sound right
| alephnerd wrote:
| It's due to regulatory mandates around device fingerprinting
| and biometrics.
|
| VN is in the process of rolling out a China style biometrics
| validation system.
| Zak wrote:
| A quick web search of the list of apps it's checking for
| suggests it's jailbreak-related, not general fingerprinting.
| Only banks get to escape Apple's restrictions, not end-users.
| bradyriddle wrote:
| I'm curious about this. I'm familiar with reversing http api
| calls using a mitm proxy. But this ain't that.
|
| Are they able to load a .so/dylib file during runtime and just
| call a method on it as long as they know the name of the method?
| How does iOS even allow that? How does an iOS even get to load
| those files? Seems like that would be locked down.
| saagarjha wrote:
| There's not really any way to stop it, considering Apple's apps
| need to make these calls.
| Rohansi wrote:
| Surely Apple could just make those libraries inaccessible to
| third party apps. Why would they be required to make them
| accessible to all apps?
| saagarjha wrote:
| Because their public frameworks depend on it.
| musjleman wrote:
| > Are they able to load a .so/dylib file during runtime and
| just call a method on it as long as they know the name of the
| method?
|
| Yes, usually that's the entire point of an .so/.dylib/.dll - to
| load it and call it's functions by name?
|
| > How does iOS even allow that? How does an iOS even get to
| load those files? Seems like that would be locked down.
|
| Because it's something that higher level apple interfaces might
| rely on. It's not a security issue in the first place - if you
| submit an app obviously using them the message you get is:
|
| > The use of non-public APIs is not permitted on the App Store
| because it can lead to a poor user experience should these APIs
| change.
| bradyriddle wrote:
| Man, this is gonna reveal some ignorance. But here goes.
| Please correct me where I'm wrong
|
| .so/.dylib/.dll's typically get linked at load time, right?
| Like we aren't all manually loading dylibs in our source
| code. I guess I'm surprised on a platform as locked down as
| ios that they even allow you to link anything at run time.
|
| chatgpt gives me this snippet but I have no way of knowing if
| this is roughly how it would look.
|
| Class SBApplication = objc_getClass("SBApplication");
|
| SEL launchSel = sel_registerName("launch");
|
| id app = [SBApplication
| getAppWithBundleID:@"com.example.app"];
|
| objc_msgSend(app, launchSel);
| freeone3000 wrote:
| You can put in an autoload section and the runtime linker
| will load it for you, but you absolutely can load a DLL and
| its symbol names at runtime. Usually this is done for
| boring reasons like compatibility with multiple versions of
| an external library.
| musjleman wrote:
| Showing a 5000$ bounty example of "enumerating all apps" sounds a
| bit disingenuous when this is more of a "check if this exact app
| by bundle name was installed not through store.
|
| I also don't think that this deserves to be called anything as
| scary as an "zero day exploit", "sandbox escape".
| bri3d wrote:
| There seems to be some weird beef in the background here with
| the TrollStore developers and Verichains, but Verichains come
| out looking much better here by naming the exploit what it
| actually is rather than misleading puffery around "sandbox
| escape 0days!!!111"
|
| I think app enumeration info leaks generically might be
| eligible for that bounty, though, so mentioning it doesn't seem
| too wild.
___________________________________________________________________
(page generated 2025-03-31 23:01 UTC)