Imuler.C Uses Icon Decoy method- LOW RISK

Imuler.c, reported by Intego, is a low risk icon decoy social engineering attack. In MacOSX the user you can simply copy an icon to another file by using "File>Get Info (Comand-I)" in the Finder.

Summary

Within a zip file the criminals hide an Application with an icon that looks like an image along with other image files. The decoy is an attempt to get the user to click on the Application and run the malicious file. 

 FACTS

• This is a social engineering attack based on an attack method dating back to Mac OS 7 (Pre-OSX).
• The stratergy of the attacker is Icon Decoying. 
• Users can turn on view extensions or use detail list to see the file type. (This is not really needed.)
• MacOSX will prompt the user if they try to open a file for the first time downloaded from the internet.
• You need to be the administrator to install or run the malicious application. Enterprise managers should manage these options in Mac OSX.

Figure 1: Warning Dialog for downloaded Application from Internet

RISK

Imuler.C as all of it's previous versions are VERY LOW RISK. The attack method is similar to the PDF decoy in September 2011. The Application with the Icon Decoy is an attempt to use tactics decades old. 

MITIGATION

• Do all your computing as a general user, not the administrator. This stops most malicious installers in there tracks.
• Do not open files from un-trusted sources. 
• Make sure that if you open an Application that you downloaded that you confirm the (HASH). 
• When you first open a file downloaded from the internet you will recieve the dialog in Figure 1, make sure that you trust that application.
• Optional : Turn on "Show all applications extensions" in Finder>Preferences>Advance.
• Enterprise administrator can manage what applications user can and cannot run. 
• Enterprise adminstrators should rely on the priciple of least privileged for application exectuion for users.

OSX Mountain Lion Gatekeeper

Apple has announced today a new System Preference Pane and Core Service called Gatekeeper along with other features of OX Mountain Lion. Gatekeeper will allow the user or Mac Systems Administrator to control the installation of software allowing them to ensure that only software signed by an Apple developer from the Mac APP store can be installed. 

The iPhone ecosystem has been making it's way on to the desktop of Mac OSX users and developers for sometime. Mobile operating systems are influencing what we can expect in the coming years on our laptops, desk tops, servers, PaaS and computing devices. (For my PC friends, wait until you see Metro.) Gatekeeper will be a game changer because Apple has the capability to implement it effectively. It is my thinking that this adds a layer of protection and control that is long over due. Basically, this control will, at the user's/admin's discretion, result in the Mac OSX platform to truely mimic the iOS application code signing ecosystem. (Only code signed by a Mac developer can be installed with additional options.) Clearly as has been demonstrated by iOS sand-boxing approach, what once was thought of as restrictions now are considered an excellent balance of protection verse features. But why stop there? 

I have long been an avocate for administrators creating their own seat-belt profile files(.sb) to enhance the settings already used in MacOSX. I expect additional controls including seat-belt in a very user friendly control pane as well in the not to distant future. Many applications and users do not need access to the file system, particular frameworks or networking. (Yes, there are other way to control this and Apple has added these controls to XCode for developers to implement. Figure 1) Allowing users and administrators a simple manner in which to manage these very complicated controls over applications and their privileges seems a logical next step in porting some of the security features from iOS to the desktop.  

Currently XCode 4.2.1 build 4D502 allows developers various sandboxing controls as of Lion.

Of course, Gatekeeper is not a perfect solution, nothing is, once you create a system there are flaws. Gatekeeper provides the user/administrator with an additional technical tool to enhance Mac OSX's security robustness. The technology is not new and various technical aspects have been discussed for some time by many researchers. Apple's controls at various levels including development, distribution, installation and administrator has lots of potential. However as with any security schema the devil is in the implementation. What makes this a game changer is that Apple, largely due to the success of the iOS ecosystem, is extremely capable of implementing Gatekeeper along with these other security controls in a way that will matter.

Date & Time Bug In iOS 5.x Allows access to Camera Roll When Locked

Ade Barkah has posted on his site Peekay.com details about his discovery of a bug in iOS which allows access to the camera roll when the device is locked. Rolling back the Date & Time will allow unauthorized access to any photos that were already taken on any future Date & Time. 

Summary

If the Date & Time IS ROLLED BACK on an iOS device running 5.x a malicious actor will have unauthorized access to the photos with future dates and times in the camera roll. 

FACTS

• Rolling back the Date & Time on a device running iOS 5.x will allow access to the camera roll on a locked device to images with only with future dates and times. 

RISK

There is a RISK that if you travel across time zones and your Date & Time is rolled back a malicious actor with physical access to your device can access your camera roll without the need for a Passcode and access photos taken between the two times.  

Overall RISK: LOW RISK

Mitigation 

General Users

Make sure that Set Automatically is enabled in General>Date&Time to ensure that your device has the current Date & Time for your current Time Zone.

Set Automatically Date & Time

This will ensure correction by your location's temporal condition until Apple's update.

Result-Residual RISK: Extremely Low RISK (Pending Update.)

High Value Users

Restricting the Camera ensures that this bug will not be triggered. High value users should considered this option when traveling. This can further be managed by using Configuration and Provisioning Profiles which includes the capability to configure Restrictions on iOS devices. Enterprise managers can manage restrictions using the iPhone Configuration Utility. 

iOS 5 and Carrier IQ Software Facts

The site blog.chpwn.com has reported that there is a version of Carrier IQ within Apple's iOS 5.x.x. I am sure that by now you have read the reports about Carrier IQ being discovered on mobile devices by Trevor Eckhart. The analysis on blog.chpwn.com is missing some key details as it relates to iOS 5.x.x that are useful in managing any RISK. To help users make informed decisions and understand the risk involved we will provide full details related to Apple's "Diagnostic & Usage Data."

Summary

In iOS 5.x.x you do not need to Jail Break the Phone and finding the information collected does not require technical expertise. (Just have to know where to look.) What is most important to note is that the data is anonymous and users have complete control. Turning off "Diagnostics and Usage" along with System Services Location will prevent any reporting. Users can view and disable the sharing of data on their iOS device running 5.x.x at anytime. What is collected, transmitted and how a user manages the collection of data is clearly stated in Apple's "About Diagnostics and Privacy" statement. 

The improvements in the management of the data can be traced back to April 2011, when it was discovered that Apple was in fact tracking users location data. The result of that discovery has resulted in Apple providing a clear and concise way in which users can manage "Diagnostic & Usage Data."  So after all there is something to be said for a company being scared straight. 

Checking Your Diagnostic & Usage Files and Settings

Apple iOS 5.x.x during the inital setup phase will ask the user if they would like to share "Diagnostic & Usage Data." (This is disabled by default.) If a user enables this option data about the phone including location data related to cell service will be anonymously collected and sent to Apple. It is really easy to turn this option on and off and to review the data that has been collected and transmitted if the option is enabled. 

 If you go into Setting>General>About>Diagnostic & Usage you are presented with the following screen. On this device below automatically send diagnostic and usage data is turned on.

Diagnostics & UsageIf you select "Diagnostic & Usage Data" you will see a list of files the collected data if the phone had "Automatically Send" enabled at some point. The file format is awdd_<Data><Time>xxx.metriclog which is consistent with Carrier IQ. 

aawd File ListIn addition to crash logs and calibration information the files contain information about the iOS 5.x.x device but all device information remains anonymous. Apple clearly explains what data is collected and how a user can manage it, more on that in a moment.

awdd Example one

Notice that the isAnonymous key <value is set to TRUE. You can also view all of the other key <value> pairs within the file.  Cell service information at your location is collected if that option is enabled in Location Services. This data is includes cellularXXXCellInfo, channels, band, hybrid_active_channel, etc. The deviceId value is the SysInfoCrashReporterKey which does not contain information that is device specific such as the MAC address, serial number, IMEI/MEID or the ICCID. Physical access to the device or to an un-encrypted backup allows an individual access to the deviceId (theSysInfoCrashReporterKey.) 

awdd Example Two

This awdd data files also contain diagnostic information related to applications and hardware, the example below is specific to the camera. 

com.apple.camera Example

Turning Off Reporting of Diagnostic & Usage

Turning off the collection of "Diagnostic and Usage Files" is very easy to do, you simply select "Don't Send" in Settings>General>About>Diagnostic and Usage.

Turning Off Diagnostic and Usage DataNo data or crash logs will be shared or sent but the files created will remain on the device for a undetermined period of time (Update Pending). They also remain in any backups of any iOS device backup. If you want to achieve a zero impact foresic foot print as it relates to these files you must setup the device initially with "Don't Send" selected. 

Turning Off Location Services

As stated above a major issue back in April 2011 was the discovery that Apple was collecting location data of users. Location data is a double edge sword no matter the device in question. (When it comes to mobile devices device=user.) The profile of the user predetermines all specific location settings for Applications and System Services. (For example a high value user would have a different location settings profile as compared to a low value.) At the enterprise level these can be managed with iPhone Configuration Utility.app. 

If you have "Diagnostics & Usage" set to "Automatically Send" and enabled the location based services for the system service "Diagnostics & Usage" in the Settings>Location>Services>System Services window, cellular data related to your location is shared anonymously. You can turn this off in Settings>Location>Services>System Services and toggle "Diagnostocs & Usage" to off. 

Location Services System Services 

Apple's Diagnostics and Privacy

Apple has a plain language privacy policy when it comes to diagnostic data collection along with clear instructions on how to turn it off. That infomation can be found on every iOS device running 5.x.x at Settings>General>About>Diagnostics & Usage. If you click the "About Diagnostics and Privacy" on the bottom of the view the following will appear. 

Apple Diagnostics and Privacy

Facts

• iOS 5.x.x Diagnostics & Usage data is anonymous.
• iOS 5.x.x Diagnostics & Usage data reporting can be turned off.
• iOS 5.x.x is Diagnostics & Usage data uses SysInfoCrashReporterKey as a key<value> for the deviceId flag, thus with physical access to the device you can obtain this number.  

RISK

Poor management, limited knowledge and misleading information represent the Highest Degree of RISK related to iOS 5.x.x "Diagnostic & Usage" reporting.

iOS 5.x.x "Diagnostic & Usage" RISK can be mitigated with management of your iOS settings.

The RISK to user privacy is LOW in iOS 5.x.x as it relates to "Diagnostic & Usage" reporting.

Mitigation

Individual user or system profile must determine all Applications and System Services specific location and "Diagnostic & Usage" reporting settings.

It is not recommended to provide any "Diagnostic & Usage" data or location data for any high value system or user. 

General users should consider disabling "Diagnostic & Usage" reporting and turn off location services for this system service. Residual risk remains such as interception and physical access compromise thus consider additional mitigation.

Addition Mitigation

• Encrypt all Backups of iOS devices on your Computer.
• Use a Passcode of Significant strength.
• Enable Find My iPhone if appropriate.
• Ensure that Mobile Wipe is available.

Additional Notes

Test done on iPad 2 and iPhone 4s running iOS 5.0 and 5.0.1. Due to our specific privacy policiy some information has been removed. To contact us please use the following form here. 

iOS 5.0.1 Released

Apple has released iOS 5.0.1 to address an array of concerns including the battery life issue reported by some users.

This update also fixes the unsigned code access to Standard Data Management and Frameworks demonstrated by @0xCharlie (Charlie Miller). His discovery exposed a weakness in Apple's code approval process. There is NO THREAT to the general user population.

The logic error discovered by @0xCharlie  took advantage of failures in mmap system calls checking of flags. This allowed any application to execute code at a level similar to Mobile Safari. Malicious Applications could use objects/classes such as NSURL, NSURLRequest, NSURLConnection and NSXMLParser to fetch additional code to execute in memory from a remote source. 

This opened a possible pathway in which a malicious actor can execute unsigned code or possibly launch a more complex exploit. Charlie Miller's application represents no threat to any user. However malicious actors have the capability and technical knowledge to duplicate his findings very easily. 

Users should update their version of iOS immediately on compatible devices.