Recently SafetyNet checks started failing on one of my test devices.
The cause is that the request for the "attestation ID" is failing, with error status -129.
The status code -129 corresponds to a failed Binder transaction. The service backing the called Binder interface is 'KeyAttestationApplicationIdProviderService'.
The specific method is `getKeyAttestationApplicationId`.
Is anybody used such an issue where the Binder ...
... interface IPC call fails? Any guidance on how to fix or further investigate this is welcome!
Throughout last days, I struggled instrumenting Google SafetyNet protected apps with @fridadotre (meanwhile 14.0.6), because SafetyNet's "basic integrity" check failed.
The test device runs LineageOS + Magisk.
Let me share how I approached this issue
The root issue was an outdated version of "Google Play Services", which was fixed by installing the most recent version of "Open GApps". This bumped GMS to version 20.39.15
In order to pass the SafetyNet basicIntegrity check, "MagiskHide" comes to help. It has to be applied to the Google Play Services (formerly known as Google Mobiles Services aka GMS)
About one and a half years ago, I disclosed several security issues affecting @Logitech wireless peripherals (mainly "Unifying" brand, but others - e.g. "G-Series Lightspeed" - are affected too).
Because of recent requests, I want to briefly review the flaws
1/n
1) CVE-2019-13053 covers a an issue, which allows an attacker to inject encrypted keystrokes over the air, without knowing the actual encryption keys. The root cause is unproper protection against counter reuse for underlying AES CTR.
In order to exploit this ...
2/n
... is required to get knowledge of about 8 keypresses while sniffing encrypted wireless traffic. This step is only required once. If the victim uses a clicker - for example - an attacker could get knowledge on a pressed key sequence, by observing how the slides ...
3/n
If you are interested in what data Android Apps push out to AppsFlyer, it might be a good idea to utilize @fridadotre to hook the 'af*' methods of class 'com.appsflyer.AFLogger'.
The screenshot shows an example of the app 'Bild'
1/n
The screenshot contains to events, related to outbound http requests.
1) The one starting with "url:", which contains a request URI 2) The next event starting with "data:", which contains the **unecrypted** content, which is sent out ("appsflyerkey" redacted)
2/n
If you inspect the corresponding HTTPS request, the actual data is encrypted (at least it should be).
So if you have to proof the the data from "AFLogger" is contained in the request, you have to decrypt the body content
Some months I reported "HTTP request smuggling" vulnerabilities to various VDPs.
All of them fixed the issue in the meantime. There was one interesting exception which taught me how careful you have to act, even with VDPs: A German company which is described like this
When I found the first issue with this company, I publicly asked on where and how to report.
It didn't take long till I got a direct contact and was directed to a private VDP on the major bounty platform. I agreed to use it (which meant NDA) because my contact was trustworthy
The report was pending for about two weeks (no managed program). During this time I started to work out related issues in other public web pages from the same company, when the initial report was closed as "not being applicable" without any explanation.
@K_Plattform_f_R@th0rst3n@heutejournal@ClausKleber@Falafelkid Nochmal falsch. Die Genauigkeit der Entfernungsschätzung bei BLE 4.0 liegt nicht bei 10m. Die Gesammte Betriebsreichweite liegt etwa bei 10-15m. Ich denke du verwechselst Entfernungschätzung mit Positionsbestimmung.
Du möchtest nur Wissen ob ein BLE Beacon (oder anderer Advertiser, wie Smartphone) sich in der Nähe befindet. Dazu genügt es festzustellen, ob du Advertisements empfängst. Die Genauigkeit liegt dann bei 10-15m (keine Verwendung von RSSI)
Du betrachtest nicht nur *OB* du Advetisements empfängst, sondern auch die RSSI und errechnest daraus eine Entfernungsschätzung zum Empfänger. Ungenauigkeit 1-2m (je mehr Messungen, umso besser können fehler herausgerechnet werden.
If a user should do injection by accident and the attack should succeed before intervention (f.e. device looking like flashdrive), typing has to be fast (and will still be noticed).
1/n
@_MG_@ektoplant@Korsakoff1@campuscodi@LucaBongiorni If you have interactive control on injection (point in time when it should happen; speed; actual payload to type), typing speed is less a concern. Injection could be carried out when the user doesn't notice it (f.e. injection implants in legit devices).
2/n
@_MG_@ektoplant@Korsakoff1@campuscodi@LucaBongiorni In both variants, first infection stage (the one typed out) should require only a few characters. This is esp. true for Internet connected targets (f.e. short download cradles in stage 1).
3/n