
Hosted by Sean OConnel · EN

This Weeks Topics This week I discuss Mavricks and iOS 7, the rumor mill of badBIOS, hoax, bad day or something else. Finally, you can expect to hear more regular podcast in the future. A project that was a game changer for Magmatic has now been completed. We expect 2014 to be a real game changer for us. We have lots of tools and ideas we are really excited about. iTunes Preview

This Weeks Topics This week I discuss Oracle's Java 1.7.0_09 for Mac OSX. While the System Preference Pane is a welcome addition it would be nice if it actually worked. After several months of using Gatekeeper it is official, I love it and you should too. Gatekeeper provides a host of protection against rouge developers. Best of all it stops rouge Java APPS in their tracks. Sandy reminds us all of what is important, that includes having a backup of critical data and the capability to keep your customer facing resources up and running. iTunes Preview

This Weeks Topics Adobe Flash, Reader, Acrobat and Shockwave UpdatesiOS SMS Spoofing and Phishing This week we discuss the recent Adobe updates. While no specific threat in the wild currently targets Mac OSX there are zero days targeting unpatched versions on the Windows platform. Criminals have regularly used the Adobe update cycle as cover to fool Mac users into installing malicious software, usually in the form as a Flash Player. SMS protocol is vulnerable to spoofing, this includes all version of iOS. A recent release of a tool to make this process easier can allow a criminal to create SMS Phishing messages, what is called SMiShing. The pattern is similar to email phishing as are the defenses, do not visit links sent via unsecure comminication. There are a host of tools that this proof of concept was built off of. Some that requirer your iPhone to be Jail Broken, something you should never do. (See Reference Links) I consider this really low risk. Using iMessage prevents this form of attack, so for clients or users that are Mac/iOS based use iMessage. Lastly I have some thoughts on Cloud based services. It is important that businesses and users realize that while the data is in the cloud, the responsibility for compliance and security is completely their responsibility. iTunes Preview

This Weeks Topics Social Engineering iCloud, The Curious Case of Mat Honan.Gatekeeper Code Signing. Summary This week I give my take on the Apple ID account compromise of Former Journalist for Gizmodo, Mat Honan. I address some of the issues companies have to consider when working with Free-lancers who bring their own devices or their own eco-systems into your security umbrella. There are various Risk that need to be considered from a host of perspectives. I explain why it is important to have control over your backups. Next I touch on the issue of code signing in Mountain Lion. User can override and set exceptions but the only way to manage these exceptions from the administrator perspective is via a command line tool called spctl. I argue that for most users and organizations, code signing make security sense and eliminates RISK, especially if code review is outside the scope of your business. Finally, my commentary on why now is the day to turn off Java on your Mac, eliminate the RISK of crime ware using Java. iTunes Preview

This Weeks Topics Drop Box SpamIcon DecoysJava RISK and Updates Summary This week I address something old and something new. What do we need to consider after the recent revolation by Dropbox that an employee was compromised resulting in malicious actors gaining access to the email addresses of account holders. I then discuss the social engineering method of Icon Decoying. A method that has been used over the last several months by criminals with mixed success. Last we discuss Java and touch on how to manage RISK using the Java Preferences.app. iTunes Preview

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.

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 var...

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.

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. <span class="thumbnail-image-bl...

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.