24 ms·
A deep dive into iOS Exploit chains found in the wild
- radicaldreamer 7y agoThis is terrifying... most people do not hard reset their phones ever (even when upgrading). What are the odds that these payloads are floating around despite the exploits being patched?
- ds 7y agoFrom the article, a reboot will do it. You dont need a hard reset : "The implant binary does not persist on the device; if the phone is rebooted then the implant will not run until the device is re-exploited when the user visits a compromised site again. "
- jen_h 7y agoThe implant is gone, but the attacker still has keychain data and can/did/does use it to continue downloading data in clear text: “The implant uploads the device's keychain, which contains a huge number of credentials and certificates used on and by the device. ... The keychain also contains the long-lived tokens used by services such as Google's iOS Single-Sign-On to enable Google apps to access the user's account. These will be uploaded to the attackers and can then be used to maintain access to the user's Google account, even once the implant is no longer running. ... There's something thus far which is conspicuous only by its absence: is any of this encrypted? The short answer is no: 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.” (Source: https://googleprojectzero.blogspot.com/2019/08/implant-teardown.html?m=1 https://googleprojectzero.blogspot.com/2019/08/implant-teard...)
- ummonk 7y agoAnyone know what kinds of sites were hacked to target iOS visitors to the sites, and who might have been targeted by these attacks? The blog post hints at the targeting of dissidents, but I'm not sure whether that is a general concern or actually there in these hacks.
- bscphil 7y ago> dissidents If nothing else, that would be a pretty good guess, given that amateurs don't have the skill to come up with "five separate, complete and unique iPhone exploit chains", and a professional team with the skill to create them is either going to report the vulnerabilities (white hat) or sell them on the black market, or at least try to infect a large number of people. The specificity of putting them on a single website with only "thousands" of views per week suggests that someone wanted to target visitors of that site specifically, not just for financial gain.
- jen_h 7y agoJust a wild and crazy guess here...but if you take this tweet thread: https://twitter.com/adrianzenz/status/1145778611242319874 https://twitter.com/adrianzenz/status/1145778611242319874 in context with the following hint: "To be targeted might mean simply being born in a certain geographic region or being part of a certain ethnic group." (https://googleprojectzero.blogspot.com/2019/08/a-very-deep-dive-into-ios-exploit.html https://googleprojectzero.blogspot.com/2019/08/a-very-deep-d...) ...and then if you think about what's been going on in Hong Kong recently -- search iPhone and Hong Kong in both languages and you'll find some interesting posts on Twitter that appear not to want folks to know that: "All that users can do is be conscious of the fact that mass exploitation still exists and behave accordingly; treating their mobile devices as both integral to their modern lives, yet also as devices which when compromised, can upload their every action into a database to potentially be used against them." (https://googleprojectzero.blogspot.com/2019/08/a-very-deep-dive-into-ios-exploit.html https://googleprojectzero.blogspot.com/2019/08/a-very-deep-d...) ...it kind of reveals itself.
- lawnchair_larry 7y agoWhat’s the relation to the first link though? That looks like an old twitter thread.
- jen_h 7y agoDid you look at the screenshot and read the translation? Appears to be a real-time tracking database of Uighurs...
- deleted 7y ago[deleted]
- pryce 7y agoThese are fascinating. It would be very interesting to know what the character and subject matter of the infecting sites were. Outside of the great tech writeup, what is particularly interesting about this, to me, from a geopolitical perspective is the level of restraint. The malicious actors in this case leveraged zero-days for iOS for years and yet do not seem to have overextended themselves or risk exposure by overly widening their intended targets. What I mean by this is: they clearly could have chosen to gain a massive infection rate by combining this with hacking a well-known popular site, or even pulling more visits from (say) social media, but instead the malicious actor chose to limit their intended recipients to run the exploits for a smaller set of targets for much longer while remaining undetected. This, to me, hints at a state-actor with specific intent.
- fortran77 7y agoIf you are under constant attack from well funded enemies who want to destroy you, attacking iOS with well focused exploits is a good way of getting intelligence. The enemy may be lulled into a false sense of security on iOS and if the exploit goes undiscovered for a long time, a lot of intelligence can be obtained.
- js2 7y ago> Earlier this year Google's Threat Analysis Group (TAG) discovered a small collection of hacked websites. The hacked sites were being used in indiscriminate watering hole attacks against their visitors, using iPhone 0-day. Crazy that the Implant was never detected directly on a phone. It's certainly visible to iOS itself, but apparently iOS isn't looking for unexpected processes running on the phone. As well, the Implant is sending network traffic that no one ever noticed or never tracked down. And presumably it has some affect on battery life. But all of this just disappears into the noise of everything else going on on an iPhone. I wonder if the Implant ever showed up in any of the crash reports collected by iOS and uploaded to Apple.
- anon9001 7y agoIt would be fun to check, but the attackers could just turn it off. It's a user-facing option: https://support.apple.com/en-us/HT202100 https://support.apple.com/en-us/HT202100
- gok 7y agoIt's staggering how systematically broken IOKit remains.
- saagarjha 7y agoTechnically these are bugs in IOKit drivers and not the IOKit framework itself: it’s a footgun and not an exploding gun.
- idividebyzero 7y agoTrue, but drivers methods are exposed through IOKit framework, which clearly does not even attempt in reducing the attack surface, and instead, makes the exploitation easier. Thus, its design appears to be fundamentally broken.
- jjirsa 7y agoTime for widespread adoption of mobile EDR.
- XMPPwocky 7y agoWould the extra attack surface from third-party apps looking at sensitive system data outweigh the benefits from an EDR solutions? Poking a hole in the sandbox for "security" or "auditing" seems a bit risky.
- wbl 7y agoMobile EDR is not going to help consumers, especially not when attacker has a kernel write primitive.
- js2 7y agoThis is terrifying. Just thinking about the data on a typical phone... the Implant could easily grab everything it needs to empty all of your financial accounts. The only way to be safe is probably to access your financial sites from a browser running inside a VM, maybe even a dedicated laptop, and never sync the passwords to anywhere outside the VM unencrypted. Ouch.
- bscphil 7y agoWell, you don't necessarily have to jump from one to the other. If you currently do financial stuff on your phone, just enabling 2FA and only browsing them on your laptop is already an enormous step up. There are cases where additional precautions are warranted, but there's no reason to let the perfect be the enemy of the good.
- ikeboy 7y agoSwitching from an iPhone to a laptop is a huge step down in security, even with 2FA. Orders of magnitude more 0-days on whatever software is running on that laptop than on iOS. This is bad advice.
- deleted 7y ago[deleted]
- jijji 7y agomaybe in a windows laptop, but people who run laptops using linux probably have more security in the laptop than on their phone, most browsers are pretty safe.
- deleted 7y ago[deleted]
- maxdamantus 7y agoI find this hard to believe given that security isn't about "having security", but about "not having buggy software". Unless you're a power user, you're probably mostly just using web applications at this point, so your main target points are the OS and the web browser. Someone "using Linux" is likely to be running various things such as SSH/HTTP/file servers, native IRC clients, random build systems (running "npm install" instills a lot of trust on the NPM repository and any packages involved). All of these things increase the attack surface.
- Analemma_ 7y ago> It is worth noting that none of the exploits bypassed the new, PAC-based JIT hardenings that are enabled on A12 devices. I'm surprised Apple doesn't talk more about how they're continuously upgrading the security of iPhones with new chip generations. I remember the BlackHat presentation on iPhone security from a few years ago [0] also found that there were attacks on older iPhones which didn't work on the (then-)newer ones. Is Apple afraid it will give the impression that existing phones are not secure? [0]: https://news.ycombinator.com/item?id=12231758 https://news.ycombinator.com/item?id=12231758
- kccqzy 7y agoIt is also worth noting that PAC is not a panacea. It's just one more thing to break before an attacker takes control. Given that one of the keys used in PAC is shared across all user-space processes including highly privileged unsandboxed processes (it must, as it's used by shared dynamic libraries), it's just a matter of finding one more user-space bug to leak the key and break PAC.
- idividebyzero 7y agoEven if the same key is shared by all processes, keys are stored in registers that are meant to be not accessible to userspace, so a disclosure vulnerability would not help here anyways.
- kccqzy 7y agoYou don't need to get the key per se, depending on your exploit. You just need a single valid signed pointer that's involved in your ROP gadget.
- arthurofbabylon 7y agoTalking about security inevitably triggers fear. That’s fine for some products, but absolutely unacceptable for large consumer brands with positive reputations.
- saagarjha 7y ago
- arkadiyt 7y ago14 iOS exploits, including 0-days, and they upload all data to their C2 using plaintext http? With this level of sophistication I feel like it can only be intentional, but why? edit: their implant is compiled unoptimized, has NSLog statements, serializes data by writing everything as files to /tmp (a "rather odd design pattern", as Ian Beer put it), in addition to the http issue just described. The implant/C2 code was likely written by a separate, less experienced team, than the one that wrote the exploit chains (which might have simply been purchased?).
- pjlnotsecure 7y agoIt leaves me in awe how good some hackers are, until it comes to hardening a Linux Server. The difference is astounding. Not knowing how to setup SSL on Apache, not knowing how to enable UFW (lol it’s “sudo ufw enable”), etc. Never was sure why that dichotomy was there. Then again I’m a terrible pentester but am very good at Linux.
- jen_h 7y agoThey own all the pipes, why bother hiding what passes through them?
- jen_h 7y agoAfter thinking about this a little longer... Not only does the attacker have no one they care about hiding from, but also: the lack of encryption is a secondary attack. Sure, when Vizio did this, it was probably incompetence...but here...trivially encrypting data is simple stuff, why not do it here when siphoning large streams of personal data? Because third parties using this data to attack the tracked victims doesn’t hurt the attacker, it in fact helps them. From the state sponsored actor’s perspective, they are merely using these exploits to track minorities and dissidents, but hey, if a third party happens to find this info and use it and that keeps the victims spun up and less effective at organizing? Win-win.
- lawnchair_larry 7y agoBecause the entity who supplied the exploit has no relation to the entity who supplies the implant and control framework. The latter is commodity developer work, easily done in house or via a defense contractor. It’s not unlikely that the exploit developer had no idea what it was being used in or how.
- krn 7y agoAs a side note: given all the security resources Google has, why Android is still not considered safer than iOS? What mistakes has Google made with Android, and how could they be fixed?
- andrewnicolalde 7y agoI suspect the main issue is that regardless of what Google does, manufacturers still need to make any new updates available, which most do not for anything but their most recent models.
- HNcantBtrustd 7y agoWhy? 2 decades of advertising has misinformed people that Apple products are safer. The longer I live, the more I think nothing is safe.
- plttn 7y agoThe compatibility definition document for Android gets it pretty secure, but realistically the only secure Android devices are Pixels in my opinion.
- chickenbane 7y agoAll things considered, I'd say Apple has done an excellent job wrt security for iOS devices. All modern iOS devices are updated on a regular basis with a high uptake rate, and Apple monitors its store and is increasing its use of bug bounties. And with these exploit chains, Apple has addressed the issues quickly. The downside of Android being an open platform is that Google is limited in forcing vendors to update their devices - and most do not. That said, Android has had regular monthly security releases for years, and the Pixel devices are excellent from a security perspective. Google also monitors its app store - as well as the full Android ecosystem (as far as Google Play Services is installed) for potentially harmful applications. This is why you regularly see articles along the lines of "Google removes malware from the Play Store that has had X installs!" I'd say the biggest vulnerability for Android users given its impressive scale is a vulnerability in a vendor's supply chain. Given the complexity of devices, a vendor likely has multiple places where a malicious actor could insert malware into an Android device. I think this is why US intel has ultimately decided devices from China - Huawei in particular - are untrustworthy. If you can't validate every component of a device and trust the vendor will always audit its security, then it's hard to trust a device, even if it is safe right now.
- RyanAF7 7y agoGod forbid these tech companies build intensional exploits into their software for plausible deniability. If terrorist cells were the shit in 2001 just wait till 2021, we ain't seen nothing yet. Stuxnet + Dark Knight + Pickle Rick
- yamrzou 7y agoThe 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-teardown.html https://googleprojectzero.blogspot.com/2019/08/implant-teard...
- zatkin 7y agoThese are all social networking services. Maybe, just maybe, this was tied to the PRISM program led by the NSA?
- ryanlol 7y agoMaybe, just maybe, this was tied to the space program at NASA? Tremendously unlikely, PRISM was something very different from this.
- londons_explore 7y agoPRISM would have had to migrate to methods like this with the rise in e2e encryption. I doubt they'd have written such shoddy and simple implant code though. At a minimum, they would have encrypted the data uploaded, since intelligence agencies love to steal data from other intelligence agencies, and sniffing wires I'm sure isn't unique to the USA.
- lawnchair_larry 7y agoNo, PRISM had nothing to do with this at all. PRISM didn’t involve any sort of attack or offensive capability, and anything doing that would not be PRISM.
- ehsankia 7y agoWasn'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.
- mrcnkoba 7y agoVery informative writeup! I'm curious if there is a way to see which devices have been affected by these exploits. After reading the disclosure policy, this vulnerability must have been fixed already. I'm guessing this has been fixed in iOS 12.4 or even before?
- londons_explore 7y agoDo you think theres a bank of iPhones at Google loading every webpage on the internet, and looking for unexpected background processes or network traffic?
- dboreham 7y agoYes. Or some virtualized equivalent.
- someguydave 7y agoEither that or they have specialized web-crawlers that emulate various browsers.
- londons_explore 7y agoEmulating 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.
- someguydave 7y agoMaybe. The article seems to imply that this implant was given to all comers, which may explain how Google found it.
- sangnoir 7y agoIt might be good enough to flag "interesting" websites for further research on native (or emulated native) environments
- Godel_unicode 7y agoFirst, 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.
- londons_explore 7y agoIt seems the webkit renderer process goes into an infinite sleep when this exploit is used. Since iOS doesn't use a seperate renderer for different web domains/iframes, that would mean the entire tab will freeze. Surely that would be a pretty big giveaway for the user - "I was just browsing round the bombmaking-for-dummies webpage, and my browser just froze, and I had to kill it and reopen it".
- AnonymousPlanet 7y agoSafari on iOS is pretty much the most unstable browser I have been using in the last ~5 years. I can't count how many times I had to kill and repopen Safari just because it froze on some Youtube video. So, no this is not a big giveaway. Unless something on the Youtube site targeted my own and most of my friends' iOS devices, of course.
- snazz 7y agoReally? The only time I have it freeze is on early betas or when I visit a million-page-long PDF or something. I wonder if it is worse on devices with 1GB of RAM or if I’ve just gotten lucky.
- AnonymousPlanet 7y agoI don't have an iOS device with less than 2GB of RAM. So I don't think memory is an issue.
- dannyw 7y agoNever happened to me.
- londons_explore 7y agoA while ago, Google showed messages at the top of Gmail for some users "We believe state-sponsored attackers might be attempting to compromise your account or computer". If they had send some OAuth tokens for a honeypot gmail account to the C&C server used for these attacks, they could then track the usage patterns of that token, and find all the other attacked users. Perhaps thats how they identified who was being attacked?
- ianhawes 7y agoI was thinking the exact same thing. It's possible that because it has been so long since Google identified this threat actor, they did in fact use a honeypot account to trace the attackers prior to burning them.
- coldcode 7y agoGiven 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?
- jen_h 7y agoNope. But given that the write-up talks about victims being victims merely for being in a geographical region makes me immediately think about wifi portals, and ISP/telecom-injection via DNS hijacking. We already know that ISPs routinely hijack your DNS queries to snarf your search queries, inject ads, redirect you to cached versions of big sites to “speed up your experience”, warn you of virus infection, etc etc. It would be trivial for a state actor to use the same mechanism to redirect you to a site that, say, looks like Google, passes your search query to Google, retuns Google, but also serves up the js that pushes the implant. Really pushes the issue that everyone — especially activists and targeted minority groups — need to be educated about DNS and proper VPN usage (a misconfigured VPN would not help here), and it would be awesome if device makers made checking and verifying this stuff easier for normal-grade users.
- Spooky23 7y agoYou don't need to compromise an ISP to do this stuff. Just use a shady ad-network to deliver malware or links in the same way that targeted ads are delivered. I'm not a sophisticated state actor, but I were going to try to deliver a message to a group of people, I'd use ad networks to target the geography or population that I was interested in. A bad actor could easily get a shitty ad network to deliver all sorts of payloads.
- jen_h 7y agoIf it’s a state actor, as has been alluded to, they’re not compromising the ISP, they are the ISP. But yeah, absolutely, great point - shitty ads are doable AND geo-targetable!
- ga-vu 7y agoTweet for defenders on how to spot the sites: https://twitter.com/craiu/status/1167358457344925696 https://twitter.com/craiu/status/1167358457344925696
- sqldba 7y agoI wonder what happens when Apple distribute the update and it detects this is on your phone. Do they even notify you?
- celeritascelery 7y agoI don’t know the updates would detect this. and Even if it did, I doubt apple would say anything.
- saagarjha 7y agoThe update would restart your device and wipe the malware.
- samsonradu 7y agoIANAL 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.
- methodover 7y agoI'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?
- w3rhn2j34oh5o 7y agoThere 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.
- sgjohnson 7y agoAny way to check if my iPhone is affected? I'm still on 12.1.2, which was released before the fix, so if I'm affected, I should still have the malware on my device. I'm not opposed to jailbreaking to check.
- deleted 7y ago[deleted]
- iandinwoodie 7y agoThe implant binary does not persist on the device; if the phone is rebooted then the implant will not run until the device is re-exploited when the user visits a compromised site again. [1] 1. https://googleprojectzero.blogspot.com/2019/08/implant-teardown.html https://googleprojectzero.blogspot.com/2019/08/implant-teard...
- eranation 7y agoJust important to note that restarting the device is not the end of it. "Given the breadth of information stolen, the attackers may nevertheless be able to maintain persistent access to various accounts and services by using the stolen authentication tokens from the keychain, even after they lose access to the device." I would recommend checking your login history / OAuth permissions to anything you had in your keychain, changing passwords for anything critical you used on your device if you suspect you were infected, a restart won't undo stolen information.
- celeritascelery 7y agoIf you have restarted your iPhone at any point, it will wipe the malware.
- blowhard 7y agoWhy don't these Nick Burns try-hards at Google provide the names of the websites? That would be the responsible thing to do, instead of adding to the hysteria by preventing people from getting a better idea as to whether they might have been affected by these exploits....Uh, You're Welcome!
- iandinwoodie 7y agoI'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 understand how these vulnerabilities are found when they are so many layers deep. If anyone has an insight I would really appreciate it. 1. https://xkcd.com/327/ https://xkcd.com/327/
- htfu 7y agoI 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)
- cryptozeus 7y agoEver 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 your photos, contacts, msgs are stollen but then they are sent to attacker on http so the data is logged probably on every router, modem and wifi sniffers.
- nindalf 7y agoSurprising. Is it really that much more effort to make a HTTPS call instead?
- guelo 7y agoThat'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.
- cryptozeus 7y agoAttacker already got the data http or https. But by publishing over http...other sniffers of public traffic also get your data.
- hooch 7y agoMaybe just to get data broadcasted is the goal, and having that reaching a centralised server is not the primary goal; imagine an operational theatre.
- dannyw 7y agoThis makes sense if a state level actor, with global network visibility (including playback capabilities, aka XKEYSCORE and TEMPORA) is behind it. Even if a C&C server is taken down, they would still be able to persist the data.
- vadansky 7y agoSo as an iPhone user, is it time to go into my password manager and generate new passwords for all my logins?
- cryptozeus 7y agoWhat does this mean ? Should I reset all my passwords just incase ? “Given the breadth of information stolen, the attackers may nevertheless be able to maintain persistent access to various accounts and services by using the stolen authentication tokens from the keychain, even after they lose access to the device.”
- sangnoir 7y agoThe attackers could have stolen your 2FA tokens (e.g. if you use Authy or Google Authenticator) - you need to reset those as well in addition to your passwords
- SimeVidas 7y agoHow exactly were these websites able to install this malicious code?
- lubesGordi 7y agoI must be missing some core concepts here. How is it possible to get arbitrary objective-c code running on your iOS device simply by visiting a web site? EDIT: found the discussion: https://googleprojectzero.blogspot.com/2019/08/jsc-exploits.html https://googleprojectzero.blogspot.com/2019/08/jsc-exploits....
- wannabcodr 7y agoFrom 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.
- kd3 7y agoYou sound like you might also be interested in the Librem 5 phone coming out this year.
- blkhp19 7y agoI’m sorry, what? Strangers at coffee shops in your small town would read your private iMessages to which they somehow had access? That makes literally 0 sense. - how did they know your name / for whom to look up these hacked messages? - how did they know where to find these hacked messages? - why would they reveal their ability to watch your every move by repeating your private messages? - even if they had all of these capabilities and no shame about letting you know, why on earth would they care enough to look at your messages? The scenario you’re convinced happened sounds completely bizarre, and gives me some strong Terry Davis vibes (no disrespect to him - that’s the person he became due to his illness).
- methodover 7y agoDo we have any idea at all about how many users were affected?
- amaccuish 7y ago>The root causes I highlight here are not novel and are often overlooked: we'll see cases of code which seems to have never worked, code that likely skipped QA or likely had little testing or review before being shipped to users. So similar to Stagefright?
- amaccuish 7y ago> It’s difficult to understand how this error could be introduced into a core IPC library that shipped to end users. While errors are common in software development, a serious one like this should have quickly been found by a unit test, code review or even fuzzing. It’s especially unfortunate as this location would naturally be one of the first ones an attacker would look, as I detail below. Wow Google. Like I applaud the Project Zero program and its goals but you never write this sort of stuff when discussing your android vulnerabilities. This is just petty.
- macsucksballs 7y agoIf you have iCloud on and you use a MacBook, you’re fucked. iCloud Drive on? Definitely fucked. It’s syncing all the time. Firefox, chrome, and definitely safari has had so many WebKit and kernel vulns over the last few years it’s sickening. All it takes is one fucked up website to silently compromise your browser and it’s over. Don’t forget mostly everyone who has a Mac runs the machine with the admin user account. Gatekeeper is so trash and by default it is set to allow Apple signed apps and third party apps. THIRD PARTY. Let me ask everyone this: How many of you open keychain access on your Mac? Open spotlight and type keychain and open it. I guarantee you will see a shit ton of unknown self signed certs from who knows where buried in your system. The self signed root certificates are the problem. If your iPhone and Mac are on the same Wi-Fi network, they are communicating no matter if iCloud is on or not. Oh and one more thing... Flashback Trojan is out and spreading in the wild again and no one has any clue. I just found it on a patched up to date Mojave on two MacBook pros. Download the F-Secure flashback removal tool and see for yourself. You are going to want to throw your piece of shit out the window. Apple has no fcking clue what they’re doing. I feel so bad for the old people who are getting their info robbed all day long. The ones who still use aol email addresses. Smh Download Patrick Wardle’s Mac security tools and you’ll cry when you see how bad your fcked. He just released Netiquitte which monitors network traffic going in and out down to the process. Another tool everyone should download for iOS is Guardian Firewall. Fairly new, but it blocks trackers and attempted browser/page hijacking. Oh and PS Everyone go into iOS settings, go to safari-> advanced-> website data Look how many persistent cookies are there. Try to clear them all see what happens. Lmfao we as a race are all about to shit the bed so bad. Say your prayers
- macsucksballs 7y agoOne way to mitigate the situation is to pay for OpenDNS and install their DNS vpn app that will track every query. This can also be done with AdGuard Pro. If it was all being done via HTTP, you can pinpoint the suspect traffic going to a suspect server. Just check the ip’s using threatcrowd.org and see if they hit. Or virus total or both. Or urlscan.io or securitytrails whatever
- macsucksballs 7y agoOne more GEM before I go: Mojave has a weird process that is persistently Installing self-signed certificates in the keychain. This allows teachers to remote into a students laptop. Why the mother fuck is this shit on my computer after I keep deleting it? I delete the cert and the public and private keys. Next day the shit is back with a new set. Brand new cert with key pairs. WHAT??? And the self-signed cert is not verified. I try to make the cert untrusted thinking that will work. NOPE. Created a little snitch rule to block all in and outbound traffic for the studentd process. Still didn’t matter the fucking thing gets remotely installed back into the keychain. Can anyone from Apple please explain to me why this bullshit keeps happening??? I remember when backtomymac was being exploited because it was something no one even knew about. They finally got rid of that but now they got a replacement!
- macsucksballs 7y agoOnce a machine is compromised at the kernel level, all further patches mean nothing. It’s a joke.
- gambiting 7y agoI literally don't understand how do you get the knowledge to write an exploit like this. I'm a c++ programmer working on game engines, so manual memory management is my bread and butter, you have to have a detailed understanding of the underlying hardware architecture to do this job, but I don't understand how you go from where I am to writing a low level exploit like this.
- f00_ 7y agofuzzing using something like AFL possibly? http://lcamtuf.coredump.cx/afl/ http://lcamtuf.coredump.cx/afl/
- badrabbit 7y agoUgh. Blogspot does not render well on mobile for me.