Palo Alto Networks' research team publishes malware analysis, especially on Apple platforms, exploit kits and cryptocurrency mining scripts.
HN links it for its XcodeGhost analysis, the Trojanized Xcode that infected iOS apps including WeChat.
> The organizations with enough resources to hack iOS devices aren't interested in sending mass emails to steal bank account details. The average iOS user who keeps their device up to date simply doesn't have to worry about malware and suggesting otherwise is misleading.
Again, no. Here's another counterexample (which is recent and appears to have been active on the App Store for ~1yr):
https://researchcenter.paloaltonetworks.com/2016/03/acedeceiver-first-ios-trojan-exploiting-apple-drm-design-flaws-to-infect-any-ios-device/
"These malicious iOS apps provide a connection to a third party app store controlled by the author for user to download iOS apps or games. It encourages users to input their Apple IDs and passwords for more features, and provided these credentials will be uploaded to AceDeceiver’s C2 server after being encrypted."
That's not state actor stuff.
However, I shouldn't have to keep providing counterexamples to convince you of your absurd claims of practical invulnerability. Apple has not made any kind of security quantum leap: no one has. Apple's systems are vulnerable to the same types of flaws, by the same types of attackers, as any other system in wide use. The main difference is that Apple has restricted their platform to the extent they have an easier time implementing security best practices. iOS is still vulnerable to flaws Apple doesn't know about or hasn't patched, and those flaws can be exploited for as long as Apple remains unaware or fails…
Lookout Security describes it as malware[2] and as malicious, as does Palo Alto Networks[3], Ars[4], Reuters[5] and The NY Times[6].
From here[1]:
> Remote control security risks
> XcodeGhost can be remotely controlled via commands sent by an attacker from a Command and control server through HTTP. This data is encrypted using the DES algorithm in ECB mode. Not only is this encryption mode known to be weak, the encryption keys can also be found using reverse engineering. An attacker could perform a man in the middle attack and transmit fake HTTP traffic to the device (to open a dialog box or open specific app for example).
> Read and write from clipboard
> XcodeGhost is also able, each time an infected app is launched, to store the data written in the iOS clipboard. The malware is also able to modify this data. This can be particularly dangerous if the user uses a password management app.
> Hijack opening specific URLs
> XcodeGhost is also able to open specific URLs when the infected app is launched. Since Apple iOS and OS X work with Inter-App Communication URL mechanism (e.g. 'whatsapp://', 'Facebook://', 'iTunes://'), the attacker can open any apps installed on the compromised phone or computer, in the case of an infected macOS application. Such mechanism could be harmful with password management apps or even on phishing websites.
> Stealing user device information
> When the infected app is launched, either by using an iPhone or the simulator inside Xcode,…
Tencent security team just posted a write-up on this issue on its blog. http://security.tencent.com/index.php/blog/msg/96
Here's the English translation:
---
Sep 12 - When we were tracking down a bug, we discovered that there was suspicious encrypted traffic sent from one/some app(s) to one/some particular domain(s) when the app(s) was/were launched or closed. Front-end security team immediately followed the issue.
Sep 13 - Tencent product team released an updated version of the app(s). We notified CNCERT of the issue.
Sep 14 - CNCERT issued a pre-warning on its website. [1]
Sep 16 - We discovered that 76 of the top 5000 apps on App Store were infected. We notified Apple and most of the app vendors of the infected apps of the issue.
Sep 17 - Palo Alto Networks also discovered the issue and published a report of their preliminary findings[2], and so did Ali mobile security team[3].
Analysis
1. Infected apps send the following information to attackers' servers: app name, app version, iOS version, locale, device type, country code, IDFV. The domain used is icloud-analysis.com. We also discovered three other domains that are not used.
2. Attackers can identify every infected iOS device and issue commands to be executed via the openURL API.
3. Attackers can invoke a customized alert box on infected iOS devices, showing whatever they want.
4. The malicious remote control module itself is vulnerable to MiTM attack.
It should be noted that multiple versions of the…
Seriously!
Here is technical analysis of one of the malware used.
http://researchcenter.paloaltonetworks.com/2015/07/unit-42-technical-analysis-seaduke/
Why does everyone thinks that only Russians can write such a malware, that too in python!
Also, does it dawns on anyone that anyone can actually take this malware up and reverse engineer it and repurpose it. All it takes is changing one JSON blob embedded in the code to point to your own servers for CNC, use your own AES IV/Key.
Also, I find it funny that they use embedded time stamps and resource locales as a proof of anything. Didn't anyone ever use Resource Hacker or 'strings' command? Is it really this hard to scrub or falsify timestamps in a DLL/EXE?
The most damning proof would have been some SSL certificate reused in a known compromised server for CnC. I heard rumors around it but nowhere in the analysis this was highlighted or discussed.
Private companies like Crowdstrike would probably love to reveal their analysis however they would be restricted by the actual data owners (e.g. the DNC) and I would guess ongoing government investigations. Plus why blow all of your signatures when they still work?
Outside of that, there's tons of data online already regarding Russian government hacking activity:
http://researchcenter.paloaltonetworks.com/2016/06/unit42-new-sofacy-attacks-against-us-government-agency/
https://www.fireeye.com/content/dam/fireeye-www/global/en/current-threats/pdfs/rpt-apt28.pdf
https://securelist.com/blog/research/72924/sofacy-apt-hits-high-profile-targets-with-updated-toolset/
http://researchcenter.paloaltonetworks.com/2016/09/unit42-sofacys-komplex-os-x-trojan/
Do you think understanding the tools, infrastructure, coding styles, activities, targets of these groups allows them to perform attribution?
I do not think it was the build server, though. According to this analysis[1], the developer used a different key to sign the build (all Mac apps need to be signed or the default behavior is to reject that App. You can permanently disable this behavior in settings, or just for on app by holding control while opening the App, which a lot users who use transmission probably do because not all legitimate Apps are signed). Anyways, since the app was signed by a third party's certificate (which was approved by Apple), chances are only the website was compromised. If the build server had been compromised, the attack would have had access to the developer's certificate and they would most likely have used that.
[1]: http://researchcenter.paloaltonetworks.com/2016/03/new-os-x-ransomware-keranger-infected-transmission-bittorrent-client-installer/