How does iMessage and Safari make iOS vulnerable to hacking?

From a well-known well-known operating system, iOS is being used by Apple applications to compromise its security capabilities.

The reputation for security of iOS, the operating system used to be considered the most solid in the world, has been severely broken after a series of vulnerabilities discovered in the past month.

The Black Hat conference last month revealed vulnerabilities that allowed about half a dozen different types of defenseless attacks on iPhones with just one mouse click. The next five series of iOS exploits were put on malicious websites to gain control of the victim’s device. Even the number of vulnerabilities on iOS is now so high that zero-day exploit brokers have to reduce the purchase price of these tricks.

As the company is preparing to launch the 2019 iPhone 11 tonight, it is clear that this is the time when the company will need to not only fix these individual security holes, but also explore the underlying causes. creating this rain of holes. But according to security researchers, this also means looking deeper into two pillars in the iPhone: Safari and iMessage.

Linus Henze, a well-known hacker for revealing a flaw in MacOS called KeySteal earlier this year, and many other iOS researchers said that the security issues of iMessage and WebKit – the browser engine for not only Safari, which all other browsers on iOS – is becoming a problem with this operating system when Apple always prioritizes their own code on other companies.

” Apple trusts their own code more than anyone else, ” Henze said . They don’t want to accept the fact that they are also creating holes in their code . ”

WebKit on iOS

On iOS, Apple requires all browsers to use the same WebKit engine as Safari uses – meaning basically, every browser like Chrome, Firefox, Brave is just Safari with different user interfaces.

According to Henze, this requirement is because of the complexity of websites that run JavaScript, forcing browsers to use a technique called Just-in-Time compilation (JIT) as a trick. save time. While programs running on iOS need to be digitally signed by Apple or a licensed developer, optimizing the browser’s JIT speed does not provide this guarantee.

According to security researchers, the problem with the WebKit engine is that in some respects it is less secure than the Chrome engine.

Amy Burnett, founder of security firm Ret2, who leads training on the exploits of both WebKit and Chrome, said there was no clear difference in which browsers had more exploits. However, Chrome vulnerabilities are fixed faster, usually through techniques such as fuzzing – the process of automatically finding software vulnerabilities by randomly loading different order of data until reveal the gap.

In addition, Google has a generous bounty program for vulnerabilities in Chrome, while Apple does not have such a bonus program for WebKit, unless a flaw on WebKit is integrated into one. Technique targeting deep within iOS.

Burnett adds that Chrome’s sandbox feature – which isolates the browser from the rest of the operating system – also makes it much harder to bypass than Webkit, thus making the Chrome vulnerabilities very small. useful if you want to attack to gain control of a device.

Malicious references

According to independent security researcher Luca Todesco, who has released WebKit hacking techniques and the whole of iOS, WebKit also has a characteristic component in the architecture that makes it possible to be a hackable flaw. .

It is called the document object model, also known as WebCore, which is used by WebKit browsers to render websites. WebCore requires a browser developer to carefully monitor which data objects will become references to another object – a process known as “counting counting”.

The developer just needs to make a mistake and one of those references will point to an object not there. A hacker can then fill that void with a malicious object of his or her own choosing, posing risks of future attacks.

In contrast, Chrome’s own WebCore version includes an additional layer of protection known as the “garbage collector” to clean links to missing objects, so they won’t leave behind. holes for attackers. WebKit, on the other hand, uses an automated reference counting system called a “smart pointer,” but according to Todesco it still has the potential to generate errors.

Apple is also aware of this problem, so for more than a year now, iOS has been equipped with a measure to mitigate the security issue known as isolated heaps, also known as “isoheap”. , designed to make errors in the reference counter untenable. There are also hardware mitigation measures on the iPhone XS and XS MAX and XR.

But both Todesco and Burnett emphasize that, although these measures significantly improve WebCore’s security, it doesn’t completely prevent attacks against the platform. Todesco said that since isoheap was introduced in 2018, there have been more holes in the reference counter.

Vulnerability in iMessage

The vulnerabilities on iOS are much rarer than WebKit. But they are much more powerful and dangerous, so they are often used as the first step in hacking techniques to gain control of a device without interacting with the user.

So it’s no surprise that last month, Natalie Silvanovich, a researcher at Google’s Project Zero team revealed a collection of unprecedented vulnerabilities on iMessage, which could be used in hijacking attacks on iPhone remotely, without users having to click on the link.

More worrying is that the existence of these individual vulnerabilities originates from the same security issue: iMessage exposes the attacker to his “unserializer”, a The component is responsible for opening various types of data sent to the device via iMessage.

Patrick Wardle, security researcher at Jamf, described the flaw as blindly opening any boxes sent to you, which contain the components that have been taken apart and reassemble them together. Do not check if they contain something dangerous or not.

Furthermore, iMessage has priority privileges in iOS over other messaging apps. In fact, non-Apple applications are connected to the rest of the operating system through strict sandboxes. That means if a third-party application like WhatsApp is compromised, hackers will continue to have to find a way to bypass the sandbox to attack further into the device.

Silvanovich, meanwhile, stressed that some of iMessage’s vulnerable components are integrated directly with SpringBoard, a program in iOS that manages the device’s Home screen, but there is no sandbox to protect it.

Linus Henze wrote about iMessage: “ I personally don’t understand why they didn’t put it in the sandbox. They should assume that their own lines of code will also have errors and ensure that their code is sandboxed in the same way that they do the code of other developers, such as WhatsApp or Signal or whatever. any other application. ”

Apple, which is well known for carefully restricting which apps are allowed to put on its App Store, and then carefully isolating those apps inside the phone’s software. But with recent software problems, Apple may need to re-examine its own security system – and treat the code inside their software similar to what they are doing with. others.

Source : GenK