'Ruskie' malware pwns iOS 7 Attackers, perhaps of Russian origin are infecting the iPhones linked to government, defence and media sectors with dangerous spy malware capable of breaching non-jailbroken devices, researchers say. The XAgent malware part of attacks unveiled last year against Windows devices has moved to iOS targeting iOS 7 and to much …
The ability to 'hide' is something whose time is long past, and should be removed from all operating systems. Roll the stuff the user shouldn't care about into a 'system' category if you like, but there should be no OS-coded ability whatsoever for any program or process to conceal its presence.
"The ability to 'hide' is something whose time is long past, and should be removed from all operating systems."
It is. The problem is computing devices are contain General Processing Units and software can be programmed to make a General Processing Unit do what the hell you want and your only protection against someone bad doing what the hell he wants is other software secure enough to defend the GPU and bug free enough it provides no means whereby other software can break it / trip it up. You can't have it all ways.
Think of it along the lines of this analogy. The system is like theatre where backstage is where system stuff that keeps the theatre running is done and where the offices which determine which shows can be shown is. Backstage is protected by security. Security is tasked with ensuring no bad actors can get backstage. But security is a bunch of people like any other. Now you can say, hold on backstage is protected by a security team, let's just lock that team in place and encase the whole of backstage, security team and all, in epoxy resin, so nothing can be changed and we can ensure there no bad actors can get in and change the show. Problem is (apart from the feasibility of this analogy as everyone would die - but assuming they wouldn't) then you can't ever change or upgrade how backstage works. So then you have no ability to upgrade your system or OS. So then maybe you say "well let's not encase all of backstage in resin" some of it should be modifiable. But hold on, then you have backstage system functions where security has to be tight and ensure no one can be replaced by a bad actor. So then you have the question "how much should be modifiable?" And when you really study that question you get to design a system pretty much as we already have them today. Flexibility wins over security, when for most people and most things they need to do, security is good enough and if it is found to be deficient you can patch it. If you have no flexibility, you have no flexibility and it cannot be changed (and also if there are any security bugs where bad actors can affect the "show" they also cannot be changed - a problem for some early devices on the Internet of things that have security flaws).
What I am actually pointing out is in the final analysis, security is a logical problem, you start this immensely flexible system running and you must provide no gap in operations where bad actors can slip in. No logical gap in a system running trillions of logical operations according to millions if not trillions of backstage security critical logical rules (it's not actually the number of operations but the logic of those rules; any human error can be fatal and there will ALWAYS be human error somewhere in the set. The question is if the bad actors can find and exploit those errors).
So the answer to your assertion is that, that is exactly what the systems builders are trying to do.
One note on the above, and one way in which what you say is right. I said above if you were to design a system from the ground up, you would get pretty much what we have. I said "pretty much" because actually historically computers and their general processing capability have evolved from systems that were completely and wholly permissive. Consequently these systems contain something that can be defined as "technical debt" to the permissive model. That is they contain a significant pile of tried and trusted logic from a time when system design didn't have the same approach to security as we have right now today. It's debatable however how big and how extensive this technical debt is. I doubt it's quite as great as many might suppose.
So let's be clear about the magnitude of this threat. You have to have physical access to the device, and it has to be running a version of iOS before iOS 8 to be practically effective.
My assumption is already that a pro funded hacker with physical access to your device, is always, likely to be able to gain access to it. So for me, against that assumption, this registers a zero uptick on the personal threat-o-meter.
"we have seen one instance wherein a lure involving XAgent simply says 'tap here to install the application'."
So... no physical access required.
You keep telling yourself there's no threat, Apple will not have anyone demanding better security and the various criminal gangs and nefarious government agencies will continue to hone their skills until one day they will get you, and you will have no defence against their attacks.
Apple kit is expensive. Therefore it is reasonable to assume that Apple owners have money. That makes you a target. Targets get attacked. Enough attacks and the walls will come down.
"So... no physical access required."
Sorry no banana. You've fallen for The Register's default setting of melodrama.
Read the next sentence after this one:
""we have seen one instance wherein a lure involving XAgent simply says 'tap here to install the application"
It says:
"That attack relied on Cupertino's ad hoc provisioning used by app developers to enable installation with a link."
So the attackers need to set you up in developer mode with an ad-hoc provisioning profile. They need access to your device to get the device ID and set-up a provisioning profile for the app.
1. Physical access is required (unless you go round emailing out your device ID, which you have no reason to do and, indeed, Apple have made it impossible to find by accident)
2. Provisioning profiles are for developers and are limited to 100 device ID's so, this is hardly a threat that can be scaled
3. Even if you write scripts to set up multiple provisioning profiles, you would need multiple Apple Developer accounts to do so. So it would cost a fair amount, again meaning it can't be scaled to a general purpose attack.
4. Assuming you have the scripts and the money to target many users, presumably as soon as compromised devices surface using your developer account Apple would disable it, so you would have to spend a lot of money and have sophisticated shadow credit card accounts
Conclusion. This is only relevant for professional targeted hacks where you can gain access to the device and only then iOS7. Yet again The Register's security reporting sensationalises instead of trying to present the truth.
If so then distribution can be halted just by Apple revoking the certificate. Ars also believes that the malware is explicitly tap-to-install (with the usual UAC-style "do you trust corporation X?" prompts), with no sort of drive-by installation or remote injection. So it's a trojan.
The security flaws are whatever under iOS 7 allows this application to hide and to block its own deletion. It doesn't manage those things under iOS 8 but it's not necessarily that security is better, it could just be that the similarly insecure components have shuffled around a bit and the detected version of the malware is out of date.
When the "click here to install application" part is accepted, it is followed by a message "Untrusted App Developer" that asks if you trust developer xxx to install apps on your phone. In order to even allow your phone to do that the device ID must be registered with Apple's developer site - so this means it can only be used for targeted attacks. If I did whatever to try to install this app it would refuse to do so.
So this is a complete non-issue for the average iOS user (they need to get my device ID to target me) It is a very serious issue for clueless CEOs and politicians who have iPhones and don't know better than to refuse to install apps despite the warning "Untrusted App Developer", assuming the hackers have a way to get the target's device ID via social engineering (or maybe hacking the PC he runs iTunes on, so they can grab the device ID from it)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
