June 18, 2015 at 00:12XARA Vulnerabilities in OS X and iOS
Today, a report of a group of information security specialists dedicated to the study of attacks based on how various applications on OS X and iOS communicate with each other (XARA, from Cross-App Resource Access) was released . For those who are too lazy to read all 26 pages of the original article , I decided to prepare a short review of it.
For starters, two short points:
And now more about vulnerabilities:
1. Interception of data transmitted through URL schemes.
In iOS (as, indeed, in OS X), applications can communicate with each other through URL schemes. How it looks:
For an example, let’s take a situation when an e-mail containing some address is received in our favorite mobile BlaBlaPost mail client . Our mailer is smart enough, and by clicking on this address it redirects the user to, say, the BlaBlaKarta navigation application . The only way to implement such a transition in iOS is to call in the first application a link of the form:
blablamaps: // 55,678 + 32,432
The system catches the call to such a URL and checks which of the installed applications can handle it. If such an application is found, then the transition occurs, and the program that opens already decides how to deal with the data (in our case, the coordinates).
All the fun begins when not one but two applications claim to work with this kind of URL. The authors determined the following operating system behavior rules:
A curious point is that, unlike the same Android, the user is not given a choice which of the applications should open. There are no additional authentication mechanisms, nothing.
Thus, the vulnerability is exploited as follows:
We create our application, BlaBlaHijack , in whose properties we indicate the ability to process the blablamaps URL scheme , and give it to the user. Unlike BlaBlaMaps , our malicious program does not open the map, but simply sends these coordinates to our server.
The same scheme works with any data transferred between applications - for example, tokens received during authorization via Facebook or Twitter.
The weak link in such schemes usually lies in the method of transferring the malicious program to the attacked user. What is especially remarkable is that Apple does not maintain any general catalog of URL schemes, so such an application will calmly undergo moderation and will be available for download.
2. Modification of keychain access rights on OS X
Unlike iOS, each of the properties stored in Keychain on OS X can be set additional access rights (Access Control List), which will list which applications are granted access to it. We illustrate the vulnerabilities associated with this mechanism on the next representatives of the BlaBlaSoftware family .
A user downloads a very popular application from the Mac App Store, BlaBlaBook- Hipster social network. Like any other decent application, when entering authorization data, it tries to save them in Keychain. And here another mechanism comes into effect - before creating a new record, the system will check if there are already records in the keyring with such parameters. This is done so that when updating programs user data does not fly off. If such an entry is found, then its contents will be overwritten; if not, a new one will be created. And if in the second case the BlaBlaBook application defines the ACL , then in the first the ACL will not change.
So, back to the vulnerability. The day before installing BlaBlaBook, a user downloaded another application, the one we already mentioned BlaBlaHijacker. This malware was the first to add an entry to Keychain with the same parameters as the original application required, and added all rights to the ACL. Thus, when a user tries to save his password, two applications will have access to it - both BlaBlaBook and BlaBlaHijacker .
Interestingly, a malicious application does not have to be installed first - any third-party application has the ability to delete a specific entry in Keychain and overwrite it with its own.
3. Access to the sandbox
It is well known that all applications in OS X work within their own sandbox and do not have access to other programs. These sandboxes are represented in the file system by folders, the name of which is the unique identifier of the application. The Mac App Store, when checking all published programs, checks this ID for uniqueness, so it would seem that there should be no repetition.
Difficulties make it possible to include additional routines in the original application - helpers, frameworks, and anything else that has its own Bundle ID. Each of these routines works in its own sandbox. The vulnerability is that Apple does not check for the uniqueness of the identifiers of these helpers - as a result of which two different applications can work in the same sandbox and gain full access to each other's data.
This vulnerability is best demonstrated by the case of the popular password manager 1Password and its extension 1Password Mini .
4. Vulnerabilities in communication via WebSocket
In short, WebSocket is a protocol by which a server can communicate with a client. It is integrated as part of the HTML5 standard, and allows WebView content in a browser to access any other application on the system by forwarding data through a specific TCP port. And, of course, there is no authentication in this case - anyone can listen to this port. An extension in the browser can’t verify in any way with whom exactly it communicates.
An example of exploiting a vulnerability - as in the previous case, 1Password. Its browser extension collected passwords and credit card numbers entered by the user in various forms, and sent them to the application via port 6263. Further actions are simple - we write a program that listens to the same port, log all the data received, and collect a good base. Again, all this quietly passes the test in the App Store.
Apple has been aware of all the mentioned vulnerabilities since the fall of last year - and, according to information from the report, it takes at least six months to fix these vulnerabilities.
Once again I will mention that iOS concerns only the first of the considered vulnerabilities.
Useful links:
For starters, two short points:
- Firstly, most of the revealed vulnerabilities relate to OS X. In iOS, everything is much calmer.
- Secondly, everything is actually quite sad.
And now more about vulnerabilities:
1. Interception of data transmitted through URL schemes.
In iOS (as, indeed, in OS X), applications can communicate with each other through URL schemes. How it looks:
For an example, let’s take a situation when an e-mail containing some address is received in our favorite mobile BlaBlaPost mail client . Our mailer is smart enough, and by clicking on this address it redirects the user to, say, the BlaBlaKarta navigation application . The only way to implement such a transition in iOS is to call in the first application a link of the form:
blablamaps: // 55,678 + 32,432
The system catches the call to such a URL and checks which of the installed applications can handle it. If such an application is found, then the transition occurs, and the program that opens already decides how to deal with the data (in our case, the coordinates).
All the fun begins when not one but two applications claim to work with this kind of URL. The authors determined the following operating system behavior rules:
- OSX will transfer the user to the application, which was the first to state that it works with this scheme.
- iOS will transfer the user to the application, which was the last to declare that it works with this scheme.
A curious point is that, unlike the same Android, the user is not given a choice which of the applications should open. There are no additional authentication mechanisms, nothing.
Thus, the vulnerability is exploited as follows:
We create our application, BlaBlaHijack , in whose properties we indicate the ability to process the blablamaps URL scheme , and give it to the user. Unlike BlaBlaMaps , our malicious program does not open the map, but simply sends these coordinates to our server.
The same scheme works with any data transferred between applications - for example, tokens received during authorization via Facebook or Twitter.
The weak link in such schemes usually lies in the method of transferring the malicious program to the attacked user. What is especially remarkable is that Apple does not maintain any general catalog of URL schemes, so such an application will calmly undergo moderation and will be available for download.
2. Modification of keychain access rights on OS X
Unlike iOS, each of the properties stored in Keychain on OS X can be set additional access rights (Access Control List), which will list which applications are granted access to it. We illustrate the vulnerabilities associated with this mechanism on the next representatives of the BlaBlaSoftware family .
A user downloads a very popular application from the Mac App Store, BlaBlaBook- Hipster social network. Like any other decent application, when entering authorization data, it tries to save them in Keychain. And here another mechanism comes into effect - before creating a new record, the system will check if there are already records in the keyring with such parameters. This is done so that when updating programs user data does not fly off. If such an entry is found, then its contents will be overwritten; if not, a new one will be created. And if in the second case the BlaBlaBook application defines the ACL , then in the first the ACL will not change.
So, back to the vulnerability. The day before installing BlaBlaBook, a user downloaded another application, the one we already mentioned BlaBlaHijacker. This malware was the first to add an entry to Keychain with the same parameters as the original application required, and added all rights to the ACL. Thus, when a user tries to save his password, two applications will have access to it - both BlaBlaBook and BlaBlaHijacker .
Interestingly, a malicious application does not have to be installed first - any third-party application has the ability to delete a specific entry in Keychain and overwrite it with its own.
3. Access to the sandbox
It is well known that all applications in OS X work within their own sandbox and do not have access to other programs. These sandboxes are represented in the file system by folders, the name of which is the unique identifier of the application. The Mac App Store, when checking all published programs, checks this ID for uniqueness, so it would seem that there should be no repetition.
Difficulties make it possible to include additional routines in the original application - helpers, frameworks, and anything else that has its own Bundle ID. Each of these routines works in its own sandbox. The vulnerability is that Apple does not check for the uniqueness of the identifiers of these helpers - as a result of which two different applications can work in the same sandbox and gain full access to each other's data.
This vulnerability is best demonstrated by the case of the popular password manager 1Password and its extension 1Password Mini .
4. Vulnerabilities in communication via WebSocket
In short, WebSocket is a protocol by which a server can communicate with a client. It is integrated as part of the HTML5 standard, and allows WebView content in a browser to access any other application on the system by forwarding data through a specific TCP port. And, of course, there is no authentication in this case - anyone can listen to this port. An extension in the browser can’t verify in any way with whom exactly it communicates.
An example of exploiting a vulnerability - as in the previous case, 1Password. Its browser extension collected passwords and credit card numbers entered by the user in various forms, and sent them to the application via port 6263. Further actions are simple - we write a program that listens to the same port, log all the data received, and collect a good base. Again, all this quietly passes the test in the App Store.
Apple has been aware of all the mentioned vulnerabilities since the fall of last year - and, according to information from the report, it takes at least six months to fix these vulnerabilities.
Once again I will mention that iOS concerns only the first of the considered vulnerabilities.
Useful links:
- Original report (required reading, seriously)
- Discussion on 1Password Forums