Is the Weyland-Yutani Bot going to target password managers?

[munkery]

While reading about the Weyland-Yutani Bot (WYB) toolkit, I wondered if there was a connection to it with MACDenfender. The two pieces of malware both have origins in Russia and somewhat compliment each other.

MACDefender is a piece of scareware that largely targets Safari. It has received a lot of media attention and given it's nature, being rogue AV software, was going to do so. Did the press from MACDefender drive users to another browser?

The WYB toolkit is made to facilitate the easy development of malware for Firefox and Chrome. Apparently, the developer of this toolkit has avoided Safari due to difficulties in relation to it's exploit paradigm. So, users being driven away from Safari helps the success of WYB.

What vector exists in Firefox and Chrome that is not an issue in Safari? A big difference in these browsers is their password management system.

Safari is integrated with Keychain Access and appears to be durable from manipulation by malware that exposes web login passwords. Access controls associated with keychain items prevent abuse by malicious software.

Chrome provides decent protection in that public disclosure concerning a way to manipulate the function of the password management system has not occurred. But, malware on the system could potentially collect passwords for logins set by the user.

Firefox password manager has issues if the user has not set a master password even if the service is not being used. The password manager function is modifiable to cause the service to automatically collect all passwords including those for SSL logins for websites that don't allow autocomplete. This was used recently against Firefox for Windows and the fundamentals of the problem have not been fixed.

The exploitability of password manager services in these third party browsers could potentially be the target of the WYB. If so, then it benefits from users migrating away from Safari.

Is there a connection? Most likely there is no direct connection but maybe MACDefender and WYB are the products of the same developer trying to develop malware that targets most of the browser market share of Mac OS X.

 

[GGJstudios]

Interesting thought. Of course, only time will tell if there is any connection between the two, but it sounds like a reasonable theory. The message for Mac users is, as always: be vigilant, stay informed, and exercise caution and prudent thought when using your Mac, especially when installing software.

 

[munkery]

Interesting thought. Of course, only time will tell if there is any connection between the two, but it sounds like a reasonable theory. The message for Mac users is, as always: be vigilant, stay informed, and exercise caution and prudent thought when using your Mac, especially when installing software.

If scraping password managers is the method used by the WYB, then the payload could be delivered via a client-side exploit. This specific method applied to Firefox is new in the Windows realm but given that it applies to other OSs, I suspect it will be seen in the wild for Mac OS X.

Safari is safe from this issue. The user would have to actively store logins and modify the access controls of the keychains that the data is stored in to become vulnerable. Also, Safari does not store logins for websites that do not allow autocomplete, such as online banking logins.

Chrome would only give up less sensitive logins, because it does not store logins for websites that prohibit autocomplete, and only if the user has opted to store those logins unless a method is found to bypass the automatic storage and autocomplete protections.

Methods have been found to bypass those protections in Firefox so the user has to set a master password even if the service is not being used or the browser is vulnerable. Given this vulnerability, Firefox should require that a master password be set by default. Supposedly, Mozilla is working on integrating Firefox's password management with keychain on OS X. This will not solve this issue in Windows.

I don't recommend using the default password management services in any browser because of the reduction caused in the computer's "local" measure of security. But, the issue with some password management systems is potentially usable in malware.

As far as I am concerned, I wouldn't use any browser other than Safari. I have always used Safari because it just seemed better to me without any real justification. At least, now I have justification.

 

[munkery]

Your misconception is thinking that ssl connections protect your data from client programs. They are only intended to protect your data from a third party spying the network. The client doesn't need to hack system APIs nor to have system privileges. The client program is the one who reads data from the user, encrypts it and sends it to the server. SSL encryption occurs after the application has already read the data. The client may use APIs or it may provide its own SSL implementation.

Ok, thanks. I will read about this further.

So, NSSecureTextField does not provide any protection in the client? If it does, is NSSecureTextField required to interact with password input fields on webpage logins?

As you stated before, the practicality of this method is the limiting factor. Users would have to choose the malicious browser over more mainstream alternatives unless the method could be used to hijack browsers already installed on the targets system.

Using this method, you could modify an open source browser, such as Firefox or Chrome, and transplant the binary onto the target's system. If the payload was delivered via email, the process could potentially be obsured to the user.

I have never heard about this being used in the wild. I wonder why? Could it be that it is just easier to install system-level keyloggers in Windows XP admin accounts. Will the cost/benefit analysis in relation to this method tip toward it becoming practical as newer Windows systems become more secure by default?

This really should be a deterrent to using non-default browsers. Or, third party browser should be installed such that the application is only modifiable by the system, like the default browser.

Thank you for teaching me a lesson. I am still surprised that this hasn't been used in the wild.

 

[munkery]

Other descriptions of binary hijacking on a Mac that I have read about only concerned using the technique to gain the privileges of the trusted program to install a trojan, such as a rootkit. Using binary hijacking in this manner would not facilitate the install of system-level keylogger because the binaries open to hijacking do not run with elevated privileges.

In wandering around the package contents of app owned by the user, I have noticed many components that seem critical to the security of the app do not have write privileges given to the user or do not have write privileges at all. Is this a factor in binary hijacking? Could this be the reason that it is not done in the wild?

Also, given that browser hijacking in this manner only applies to third party browsers, the ability to do this kind of makes pwn2own seem not the best test of browser security given that both Chrome and Firefox were not the victims of client-side exploitation but could potentially have their binaries hijacked unless some variable prevents this from occurring.

 

[Member(TM)]

So, NSSecureTextField does not provide any protection in the client? If it does, is NSSecureTextField required to interact with password input fields on webpage logins?

NSSecureTextField simply prevents that passwords are seen by people watching your screen. There is no direct relationship between NSSecureTextField and the web connection. A web browser directly reads the NSSecureTextField and it uses its content to build the http or https request.

This really should be a deterrent to using non-default browsers. Or, third party browser should be installed such that the application is only modifiable by the system, like the default browser.

I think it's not so serious. Trojans will still require user interaction to be installed, even if they don't ask for a password. I prefer that third party applications, including browsers, have the option to be installed without system privileges. This gives advanced users the chance to finely tune their trusts. If all applications require system privileges to be installed, then you only have two categories: applications you absolutely trust and applications you don't trust at all. I like to have an additional category: applications that I moderately trust: I prefer to install and use such applications as a dedicated standard user, so that they don't have the chance to install garbage in common folders.

Thank you for teaching me a lesson. I am still surprised that this hasn't been used in the wild.

I feel a little ridiculous for so obsessively arguing my points. I don't know if it makes business sense to write a Trojan against Mac users, but it surely doesn't make business sense to write a Trojan just to prove a point.

 

[munkery]

I prefer that third party applications, including browsers, have the option to be installed without system privileges.

Ownership and privileges are separated. Safari is owned by system but runs with the current users privileges.

I agree that most applications should not be owned by system given that the only apps that are really vulnerable to this method is web browsers. Having to authenticate every app install would actually placate the user into being more likely to install trojans with system-level privileges.

Is there any limitation to using this against a third party web browser?

I feel a little ridiculous for so obsessively arguing my points. I don't know if it makes business sense to write a Trojan against Mac users, but it surely doesn't make business sense to write a Trojan just to prove a point.

If it is a method that easily applies across several OSs, then it definitely makes sense. The question is why hasn't this occurred in any OS?

Could I get the source code to your trojan?

I want to look at it to see if I can find a limiting factor that prevents third party browsers from being hijacked.

 

[munkery]

If implemented in the third party app, code signing prevents the hijacking of app bundles.

But unlike unsigned code, a signed application cannot be tampered with after installation. If an application from Acme Inc. does something malicious, you can be sure that it's not because it's been hijacked by some other bit of malware. Put another way, well-behaved code will continue to be well-behaved. Any attempt to modify it will stop it from running entirely.

http://arstechnica.com/apple/reviews/2007/10/mac-os-x-10-5.ars/11

Default OS X apps are code signed so this is not an issue with default apps even if permissions have been changed to give admins write privileges. Both Chrome and Opera are code signed.

Firefox does not appear to be so bundle hijacking the web browser may only be an issue for Firefox.

Most third party apps (at least those on my system) are code signed. But, abusing this method to collect online banking logins really only applies to the web browser as users don't log in to these services with other apps.

Edit: There is a lot of mixed information concerning code signing in OS X. From what I gather, by default different flags are applied to different items contained in the app bundle. Resources are signed in such a way that modification causes prompts in relation to keychain, firewall, etc. The actual binary in the bundle is signed such that modification of the binary prevents the app from launching. Anybody tested this to confirm?