XARA vulnerabilities in OS X and iOS
Today a report was published by a group of information security specialists devoted to the study of attacks based on the ways of communicating with each other various applications on OS X and iOS - (XARA, from Cross-App Resource Access) . 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 a start, two short points:
And now more about the vulnerabilities:
1. Interception of data transmitted via URL schemes.
In iOS (as well as in OS X), applications can communicate with each other through URL schemes. What it looks like:
As an example, let us take a situation where an e-mail arriving at our favorite mobile email service, BlaBalPochta , contains an address. Our mailer is smart enough, and when you click on this address, it pushes the user to, say, the BlaBlaKarta navigation application. The only way to implement such a transition in iOS is to call the following link in the first application:
blablamaps: // 55,678 + 32,432
')
The system picks up a call to such a URL and checks which of the installed applications can handle it. If such an application is found, then a transition occurs, and the opened program itself decides how to deal with the data (in our case, the coordinates).
All the fun begins when not one, but two applications declare that they work with a URL of this kind. The authors identified the following operating system rules:
The curious point is that, unlike the same Android, the user is not given the choice of 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 blablamaps URL scheme, and give it to the user. Unlike BlaBlaMaps , our malware will not open the map, but simply send these coordinates to our server.
The same scheme works with any data transmitted between applications - for example, tokens received during authorization via Facebook or Twitter.
The weak link of 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 common directory of URL schemes, so this application will quietly be moderated and will be available for download.
2. Modify keychain permissions on OS X
Unlike iOS, each of the properties stored in Keychain on OS X can be assigned 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 members of the BlaBlaSoftware family.
A user downloads a very popular application from the Mac App Store, BlaBlaBook is a hipster social network. Like any other decent application, when entering authorization data, it tries to save them to Keychain. And here another mechanism comes into effect - before creating a new record, the system will check if there is already a record in the keyring with such parameters. This is done so that when updating software, user data does not fly. If such a record is found, its contents will be overwritten, if not, a new one will be created. And if in the second case the ACL is set by the BlaBlaBook application, then in the first case - the ACL will not change.
So, back to the vulnerability. The day before installing BlaBlaBook, the user downloaded another application, BlaBlaHijacker , already mentioned by us. This malware first added an entry to Keychain with the same parameters that are required by the original application, and added all the rights in the ACL. Thus, when a user tries to save his password, two applications already have access to it - BlaBlaBook and BlaBlaHijacker .
Interestingly, the malicious application does not have to be installed first - any third-party application has the ability to delete a specific entry in Keychain and rewrite it with its own.
3. Access to the sandbox
It is well known that all applications in OS X work within their sandbox and do not have access to other programs. These sandboxes are represented in the file system by folders named with the unique identifier of the application. Mac App Store when checking all published programs checks this ID for uniqueness, therefore, it would seem, there should be no repetitions.
It is difficult to include additional subroutines in the original application - helpers, frameworks, whatever, which has its own Bundle ID. Each of these routines runs in its sandbox. The vulnerability lies in the fact 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 get full access to each other's data.
This vulnerability is best demonstrated by the case of the popular 1Password password manager and its 1Password Mini extension .
4. WebSocket communication vulnerabilities
In short, WebSocket is a protocol through which a server can communicate with a client. It is integrated as part of the HTML5 standard, and allows WebView content in the browser to access any other application in the system, passing data through a specific TCP port. And, of course, there is no authentication, and in this case, anyone can listen to this port. The extension in the browser can not check with whom exactly it communicates.
Example exploitation of vulnerabilities - as in the previous case, 1Password . Its browser extension collected the user-entered passwords and credit card numbers in various forms, and sent them to the application through port 6263. Further actions are simple - we write a program that listens to the same port, logs all the data, and collect a good database. Again, all this is quietly tested in the App Store.
Apple has been aware of all the mentioned vulnerabilities since last fall - 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 a start, two short points:
- First, most of the publicly disclosed vulnerabilities concern OS X. Everything is much calmer in iOS.
- Secondly, everything is actually quite sad.
And now more about the vulnerabilities:
1. Interception of data transmitted via URL schemes.
In iOS (as well as in OS X), applications can communicate with each other through URL schemes. What it looks like:
As an example, let us take a situation where an e-mail arriving at our favorite mobile email service, BlaBalPochta , contains an address. Our mailer is smart enough, and when you click on this address, it pushes the user to, say, the BlaBlaKarta navigation application. The only way to implement such a transition in iOS is to call the following link in the first application:
blablamaps: // 55,678 + 32,432
')
The system picks up a call to such a URL and checks which of the installed applications can handle it. If such an application is found, then a transition occurs, and the opened program itself decides how to deal with the data (in our case, the coordinates).
All the fun begins when not one, but two applications declare that they work with a URL of this kind. The authors identified the following operating system rules:
- OSX will transfer the user to the application that first declared that it works with this scheme.
- iOS will transfer the user to the application that last stated that it works with this scheme.
The curious point is that, unlike the same Android, the user is not given the choice of 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 blablamaps URL scheme, and give it to the user. Unlike BlaBlaMaps , our malware will not open the map, but simply send these coordinates to our server.
The same scheme works with any data transmitted between applications - for example, tokens received during authorization via Facebook or Twitter.
The weak link of 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 common directory of URL schemes, so this application will quietly be moderated and will be available for download.
2. Modify keychain permissions on OS X
Unlike iOS, each of the properties stored in Keychain on OS X can be assigned 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 members of the BlaBlaSoftware family.
A user downloads a very popular application from the Mac App Store, BlaBlaBook is a hipster social network. Like any other decent application, when entering authorization data, it tries to save them to Keychain. And here another mechanism comes into effect - before creating a new record, the system will check if there is already a record in the keyring with such parameters. This is done so that when updating software, user data does not fly. If such a record is found, its contents will be overwritten, if not, a new one will be created. And if in the second case the ACL is set by the BlaBlaBook application, then in the first case - the ACL will not change.
So, back to the vulnerability. The day before installing BlaBlaBook, the user downloaded another application, BlaBlaHijacker , already mentioned by us. This malware first added an entry to Keychain with the same parameters that are required by the original application, and added all the rights in the ACL. Thus, when a user tries to save his password, two applications already have access to it - BlaBlaBook and BlaBlaHijacker .
Interestingly, the malicious application does not have to be installed first - any third-party application has the ability to delete a specific entry in Keychain and rewrite it with its own.
3. Access to the sandbox
It is well known that all applications in OS X work within their sandbox and do not have access to other programs. These sandboxes are represented in the file system by folders named with the unique identifier of the application. Mac App Store when checking all published programs checks this ID for uniqueness, therefore, it would seem, there should be no repetitions.
It is difficult to include additional subroutines in the original application - helpers, frameworks, whatever, which has its own Bundle ID. Each of these routines runs in its sandbox. The vulnerability lies in the fact 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 get full access to each other's data.
This vulnerability is best demonstrated by the case of the popular 1Password password manager and its 1Password Mini extension .
4. WebSocket communication vulnerabilities
In short, WebSocket is a protocol through which a server can communicate with a client. It is integrated as part of the HTML5 standard, and allows WebView content in the browser to access any other application in the system, passing data through a specific TCP port. And, of course, there is no authentication, and in this case, anyone can listen to this port. The extension in the browser can not check with whom exactly it communicates.
Example exploitation of vulnerabilities - as in the previous case, 1Password . Its browser extension collected the user-entered passwords and credit card numbers in various forms, and sent them to the application through port 6263. Further actions are simple - we write a program that listens to the same port, logs all the data, and collect a good database. Again, all this is quietly tested in the App Store.
Apple has been aware of all the mentioned vulnerabilities since last fall - 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 the 1Password forums
Source: https://habr.com/ru/post/260557/
All Articles