Security

How does SandJacking let attackers load malware on iOS devices?

A security researcher unveiled a new iOS attack technique called SandJacking, which allows someone with physical…

“;
}
});

/**
* remove unnecessary class from ul
*/
$(“#inlineregform”).find( “ul” ).removeClass(“default-list”);

/**
* Replace “errorMessageInput” class with “sign-up-error-msg” class
*/
function renameErrorMsgClass() {
$(“.errorMessageInput”).each(function() {
if ($(this).hasClass(“hidden”)) {
$(this).removeClass(“errorMessageInput hidden”).addClass(“sign-up-error-msg hidden”);
} else {
$(this).removeClass(“errorMessageInput”).addClass(“sign-up-error-msg”);
}
});
}

/**
* when validation function is called, replace “errorMessageInput” with “sign-up-error-msg”
* before return
*/
function validateThis(v, form) {
var validateReturn = urValidation.validate(v, form);
renameErrorMsgClass();
return validateReturn;
}

/**
* DoC pop-up window js – included in moScripts.js which is not included in responsive page
*/
$(“#inlineRegistration”).on(“click”,”a.consentWindow”, function(e) {
window.open(this.href, “Consent”, “width=500,height=600,scrollbars=1”);
e.preventDefault();
});

access to an unlocked iPhone to load malicious apps on the device. The SandJacking attack uses a flaw in XCode 7 regarding certificates. How does the attack exploit this flaw, and how dangerous is SandJacking compared to other iOS threats?

To keep its ecosystem malware free, Apple requires all apps to be distributed via its official App Store. Each app is reviewed to ensure it is reliable, performs as expected and is free of offensive or malicious features; it also runs in a sandbox to prevent other processes from accessing it and its associated data. Each app has to be signed with an Apple Developer ID certificate. These are only available to members of Apple’s Developer Program, who have to go through a verification process, which can include having to provide government-issued photo identification like a driver’s license or passport. On the whole, these security controls work very well, though there have been some notable cases where malware has still managed to infect numerous iOS devices: WireLurker, XcodeGhost and AceDeceiver. SandJacking is now another example.

Before the release of iOS 8.3, one attack technique was to replace a legitimate app with a rogue version by simply assigning the malicious app a similar identifier, known as a bundle ID, and overwriting the original application. IOS 8.3 now prevents the installation of an app that has an ID similar to an existing one. However, while this check prevents a legitimate app from being overwritten and replaced during the installation process, it doesn’t provide any safeguard during the restore process.

Chilik Tamir from Mi3 Security recently demonstrated how an attacker with physical access to an unlocked iPhone can create a backup, remove the legitimate app, install his rogue version of the deleted app and then restore the backup. This SandJacking attack works on non-jailbroken iPhones and gives the attacker access to the sandbox data of the app it replaces. The malicious app still has to be signed, but in Xcode version 7 — a suite of software development tools created by Apple — programmers are allowed to create iOS apps using unvalidated certificates that can be obtained by simply providing an Apple ID and then distributing them directly, avoiding Apple’s application review and store restrictions. Creating an Apple ID is a simple process requiring only a name and an email address.

Although apps created with these unvalidated certificates have limited capabilities compared to regular apps where the developer has been through the formal verification process to obtain a certificate — they can’t access Apple Pay or in-app purchase features for example — they can still access personal data such as the victim’s address book and calendar. They’re also likely to go undetected by the user, who would have to check the app’s certificate and the device’s provisioning settings to verify the developer’s identity.

The SandJacking attack itself is not as dangerous a threat as other iOS threats, such as YiSpecter, XcodeGhost and Backdoor.MAC.Eleanor, which offer the attacker full control of the compromised device, because the attacker would need physical access to the device to pull a SandJacking attack off. It could be used while a phone is being repaired, or by a family member or law enforcement agency who has access to the device. But any type of smartphone that is unlocked and in the possession of someone other than the owner has to be regarded as potentially compromised. What the attack shows is how reliant the internet and technology as a whole is becoming on digital certificates when deciding whether something or someone should be trusted or not. Those who issue digital certificates need to ensure the internet and security systems can actually trust them.

Ask the Expert: Want to ask Michael Cobb a question about application security? Submit your questions now via email. (All questions are anonymous.)

Next Steps

Find out how a pirated app beat Apple’s App Store security

Learn how to avoid mobile application malware and security risks

Discover how your enterprise can defend itself against fake apps


Dig Deeper on Smartphone and PDA Viruses and Threats-Setup and Tools


Source link

Tags

About the author

GG

Add Comment

Click here to post a comment

Your email address will not be published. Required fields are marked *