Live data from Hacker News

A deep dive into iOS Exploit chains found in the wild

googleprojectzero.blogspot.com

151–160 of 202 posts

Re: A deep dive into iOS Exploit chains found in the wild

#151
From about 2016-2018 I was wondering why my iMessages became fodder for strangers to parrot back to me at coffee shops in the small USA town in which I was living. Of course, I explored the idea that the other parties of these iMessage conversations (usually thousands of miles away with no apparent connection to people in my locale) had somehow betrayed me. This was likely not the case, as I confronted those parties and they adamantly denied discussing or sharing our conversations.

It’s likely that my devices were owned and on display for hackers in my local community. This article is a reminder of the trauma experienced as a result of the paranoia and mistrust I experienced, and a reminder that we are not to trust our consumer devices to really care about our privacy.

If Apple cared about user security they’d build robust defenses into the devices that empower the end user to have a degree of confidence regarding security. Instead, the iPhone on which I’m typing could be at this time could be 100% owned and leaking data in real time and I’m afforded no visual indication of that possibility. The camera and microphone could be hot and transmitting and Apple refuses to offer any way to confirm this in a robust, hardware-visual, unhackable way. That computer camera activity led’s can be hacked (or could be in previous iterations) is indicative of the level of irresponsibility going on.

The blob that is the combination of a modem that interacts with cell towers, and the vastly complex computer tied to it, affords zero insight into what the phone is doing or whether it is betraying me.

And, such privacy breaches are enough to ruin lives. World is full of malicious folks who enjoy hurting others if they can get away with it.

Re: A deep dive into iOS Exploit chains found in the wild

#153

Ever worst part is this “they really do POST everything via HTTP (not HTTPS) and there is no asymmetric (or even symmetric) encryption applied to the data which is uploaded. Everything is in the clear. If you're connected to an unencrypted WiFi network this information is being broadcast to everyone around you, to your network operator and any intermediate network hops to the command and control server.” So not only…

Surprising. Is it really that much more effort to make a HTTPS call instead?

Re: A deep dive into iOS Exploit chains found in the wild

#154
post #78
post #54

Earlier quoted context omitted.

> 2FA makes it profoundly more difficult to compromise an account. Just because the attacks are dumb. If your computer is pwned, it should wait for you to 2FA, and then when you "log out"-- don't, do malicious stuff instead.

That's why 2FA should be performed at transaction confirmation time for sensitive operations, not just at login or periodically.

Even then; substitute the transaction they want for another transaction.

If the device you are using is compromised, you're in for a bad time.

You could send some simple transaction summary to the other device to acknowledge, which is getting better. Even so that doesn't completely eliminate the opportunity for tomfoolery.

Re: A deep dive into iOS Exploit chains found in the wild

#155

Earlier quoted context omitted.

IANAL but shouldn’t this be a requirement within the GDPR? As a data operator, an organisation has the obligation to disclose any loss/leak of data, so this should be enforced.

I'm wondering about this too. The GDPR requires a public notification. Why the hell is this coming from flippin' Google?! Why don't we have numbers on how many users were affected? Why isn't there a way to see if you're the one affected?

There was no Apple data breached. User endpoints were attacked, using various well crafted exploits against their software. This isn't a GDPR (privacy) issue, no company data was leaked, its end user data from their device. Apple tries to protect your data on their devices, but all software has bugs. Bad guys will try to exploit these bugs to reach their goals.

Google does research into making it hard for attackers to compromise user devices. That is the purpose of PZ team. There are no numbers because nobody has these numbers except for the attacker. I am guessing Google has some ball park numbers based on search traffic or web analytics.

If you want to know if you were affected, you need to ask yourself if powerful adversary wants access to your data, possibly because of civil unrest occurring in their territory; and if you visit strange websites related to this. Only the adversary knows for sure, not Apple, Not Google.

Re: A deep dive into iOS Exploit chains found in the wild

#156
post #131
post #111

Earlier quoted context omitted.

I guess you'd have to worry about malware breaking out of the VM as well, but are there many exploits that do that these days?

That's hard to say, but both VirtualBox and VMware were hacked this year[1]. Definitely most secure would be both dedicated PC and running everything facing outside from VM. (and using SELinux or AppArmor as well). [1]: https://securityaffairs.co/wordpress/82702/breaking-news/pwn...

What about a VM that is actually an emulator like Bochs?

Re: A deep dive into iOS Exploit chains found in the wild

#157

Ever worst part is this “they really do POST everything via HTTP (not HTTPS) and there is no asymmetric (or even symmetric) encryption applied to the data which is uploaded. Everything is in the clear. If you're connected to an unencrypted WiFi network this information is being broadcast to everyone around you, to your network operator and any intermediate network hops to the command and control server.” So not only…

That's not the worst part. The worst part is the attacker getting the data. The slight chance that while you're infected you also happen to be on a public wifi in the same room at the same time as a random opportunistic hacker, or that an ISP employee is risking their job by combing through petabytes of transient customer data, is much less concerning.

Re: A deep dive into iOS Exploit chains found in the wild

#158
post #60
post #55

The list of apps being monitored which are hardcoded directly in the implant[1] include : com.yahoo.Aerogram com.microsoft.Office.Outlook com.netease.mailmaster com.rebelvox.voxer-lite com.viber com.google.Gmail ph.telegra.Telegraph com.tencent.qqmail com.atebits.Tweetie2 net.whatsapp.WhatsApp com.skype.skype com.facebook.Facebook com.tencent.xin [1] https://googleprojectzero.blogspot.com/2019/08/implant-teard...

These are all social networking services. Maybe, just maybe, this was tied to the PRISM program led by the NSA?

Wasn't PRISM mostly to spy on Americans? Most of the apps there aren't very popular in the US, and half of them are just straight up Chinese. Seems more like it would be a PRISM-like program but in some Asian country or China.

Re: A deep dive into iOS Exploit chains found in the wild

#159
post #116

Earlier quoted context omitted.

Hopefully a popularity surge will translate into the app getting better. It's notably less pleasant to use than Telegram, which I'd think of as its closest competitor.

What features of Telegram are more pleasant? I don't use Telegram much due to its makeshift encryption scheme and bad defaults (no E2E by default), but I've found Signal extremely usable in the last year or two.

Opening up the picker for sending a picture was notably slow. Approximately a three second count from pressing the button to having the pictures available to choose from. Then similar occasional lags throughout the process (e.g. hitting "back" from a picture to return to the library and select a second picture).

By contrast, Telegram has a quick selection of the last few pictures available immediately, and the general picker opens quicker if you request it -- maybe because it's using the stock iOS picker rather than the custom one Signal implements?

Since sending a picture to a contact was a super common action of mine, this was incredibly frustrating.

Signal also had notification issues if I was running the desktop client at the same time. It'd sometimes clear notifications from my phone before I'd actually read them in either location.

Re: A deep dive into iOS Exploit chains found in the wild

#160

Earlier quoted context omitted.

Either that or they have specialized web-crawlers that emulate various browsers.

Emulating a browser wouldn't be good enough for most exploits. Most stealthy malware immediately deactivates itself if it thinks it is on an emulated or virtualized system.

First, most malware is not that sophisticated. While some does vm detection, most (as is the case here) does not. Second, VM detection is an arms race. See for example the vmcloak project. Third, with the rise of BYOD and VDI, vm detection is less common in sophisticated malware as the target is frequently virtualized. Fourth, vm detection is harder for arm than x86. Fifth, vm detection detection via static analysis is very effective.
Post reply on HN