Once a machine is compromised at the kernel level, all further patches mean nothing. It’s a joke.
A deep dive into iOS Exploit chains found in the wild
181–190 of 202 posts
Re: A deep dive into iOS Exploit chains found in the wild
#182Earlier quoted context omitted.
This is an odd list. Some big messaging apps like Signal and Line are notably missing, while tools like Mail Master and Voxer seem like pretty minor players compared to the rest. Is there a particular region of the world or community where this specific list makes most sense?
I suppose this list must be combined with the following explanation: "To be targeted might mean simply being born in a certain geographic region or being part of a certain ethnic group."[^1] So the suspects are countries that fight against the autonomy of a region where the population is ethnically different. The most obvious suspect is China: they have gulag camps in Xinjiang where Uygurs are interned, up to 1.1 mil…
To shed some more light on the situation, the Uyghurs in the region had affirmative action programs and were exempt from the one child policy. They had more perks than regular Han Chinese.
However, with the spread of Salafism [1] in that region, China started to suffer multiple terrorist attacks a year. With the worst resulting in 35 deaths and hundreds injured [2].
As a result, to stop these terrorist attacks, China started these de-radicalization centres. Since then, there have been no attacks.
1. latimes.com/world/asia/la-fg-china-saudi-arabia-20160201-story.html
2. en.wikipedia.org/wiki/2014_Kunming_attack
Re: A deep dive into iOS Exploit chains found in the wild
#183Earlier quoted context omitted.
This is an odd list. Some big messaging apps like Signal and Line are notably missing, while tools like Mail Master and Voxer seem like pretty minor players compared to the rest. Is there a particular region of the world or community where this specific list makes most sense?
com.tencent.xin makes a lot of sense in China https://en.wikipedia.org/wiki/Tencent_QQ
This proves it’s not China since Tencent would just give their information to the government.
Re: A deep dive into iOS Exploit chains found in the wild
#184Earlier quoted context omitted.
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.
Chinese companies would just give the data to the government. So there would be no need to spy on them.
Re: A deep dive into iOS Exploit chains found in the wild
#185Given the depth of China's interest in controlling and accessing dissidents worldwide, I would think it highly likely that China is behind the entire exploit. What I did not see in the articles (too many to read everything) is the requirement to inject the implant from a website. Did the article indicate what sites were compromised?
It’s probably the CIA.
Looking at the list of apps monitored, there were several Chinese apps on there.
Chinese companies already share all data with the government, so it doesn’t make sense China would need to waste resources and spy on them.
Re: A deep dive into iOS Exploit chains found in the wild
#186Earlier quoted context omitted.
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.
If you sign with a 2FA I can not see how a compromised computer can make that insecure. Though I will say, the UX on 2FA signing needs to get better, but it is secure enough.
Re: A deep dive into iOS Exploit chains found in the wild
#187Earlier quoted context omitted.
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.
Attacker already got the data http or https. But by publishing over http...other sniffers of public traffic also get your data.
Maybe just to get data broadcasted is the goal, and having that reaching a centralised server is not the primary goal; imagine an operational theatre.
Re: A deep dive into iOS Exploit chains found in the wild
#188I'm always impressed by Google's Project Zero team, but I'm also impressed by abilities of the implementer(s). What's interesting is that (for most of these cases) I find that I can understand the process of the reverse engineering, but I am completely stupefied as to the process of the initial implementation. I understand finding relatively superficial vulnerabilities (e.g., an SQL injection attack [1]), but I don't…
I mean that's the thing, they're layers deep but those layers can largely be approached individually, and swapped as needed.
You don't have to wait until you find a JS exploit to start work on a payload achieving further privilege escalation, you use existing development tools and privileges.
And what's really so different in concert between SQL injection and the lack of proper checks on the binary data header field in the beginning of the first post?
One of the latter posts in the linked series goes through how the initial stage stuff is in one case taken verbatim from the JS test case in the webkit commit fixing the bug (and only reaching users months later).
(Not at all saying it's not incredibly impressive or that I could do any of it, haha)
Re: A deep dive into iOS Exploit chains found in the wild
#189Earlier quoted context omitted.
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.
If you sign with a 2FA I can not see how a compromised computer can make that insecure. Though I will say, the UX on 2FA signing needs to get better, but it is secure enough.
If the 2FA doesn't contain the actual transaction detail, pretty simply.
When user tries to transfer $1,000 of cash from user's investment account to user's bank account, instead, initiate transferring $100,000 to EvilGuy's bank account. Rewrite elements so it appears that $1,000 is being transferred to user's bank account, and wait for user to receive their 2FA code and authenticate. This may be as easy as string replacement both ways.
Re: A deep dive into iOS Exploit chains found in the wild
#190From 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…
You sound like you might also be interested in the Librem 5 phone coming out this year.