Tuesday, June 23, 2015

Adobe Flash Zero-Day Attack!
Update To v18.0.0.194 NOW


Adobe Flash has yet-another active zero-day exploit out-in-the-wild. Adobe has therefore pushed out an 'out-of-band' update of Flash to the world today. Get it and install it NOW.

It is version

Apparently, Adobe has not yet finished an update to AIR, which always requires updating whenever Flash is updated. AIR incorporates Flash. Therefore, watch for an AIR update in the very near future.


From Adobe's Security Bulletin for this update: 
Adobe is aware of reports that CVE-2015-3113 is being actively exploited in the wild via limited, targeted attacks. Systems running Internet Explorer for Windows 7 and below, as well as Firefox on Windows XP, are known targets. 
. . . 
These updates resolve a heap buffer overflow vulnerability that could lead to code execution (CVE-2015-3113).  
At this point in time, the CVE's description, beyond what Adobe provides above, is blank. This happens while a developer is working to stop the CVE (Common Vulnerabilities and Exposures) and doesn't want to hand hackers any further clues to its exploitation.

Adobe's details don't note an exploit for OS X. But Adobe provides an OS X Flash update typically because the same exploit is possible on OS X as well.

Me Grumbling

This is what it's like on the bleeding edge of these situations:

This morning I learned that Adobe had finished and released Flash v18.0.0.194. But I couldn't get it via the usual method of going to Adobe's website and clicking the 'Flash Player' link in the bottom right of the page. Adobe kept telling me I was already up-to-date. But I wasn't.

So I went to the System Preferences pane for Flash Player, clicked the 'Updates' tab, then clicked the 'Check Now' button. It too told me I was up-to-date. But I wasn't.

I downloaded what was linked on the Adobe Flash update page anyway. What I got was a barely functional installer that just sat there and did nothing. My guess is that I was running the installer at the time Adobe was pulling down the old update and putting up the new update. Therefore, there was nothing for the installer to download and install.

So I waited around then went back to the Flash update page.  Finally, the Adobe website noted that version was available. But as usual, Adobe said nothing about why the update was available on their update page. I hate that.

Therefore, I went over to Adobe's Security Bulletins page:

But there was no new security bulletin for Flash v18.0.0.194. All they had was the older bulletin from their second-Tuesday-of-the-month update, which was not related. So I waited a few hours and went back again. There, at last, was the relevant security bulletin. It took them long enough! 

Summary: Adobe announced the release of v18.0.0.194 before anyone could download it. When it was available to download, there was no security bulletin to tell you what the update was for. I hate that.

Apple has, in the past, done the same sort of blundering. It's a lack of coordination within a company. If this messing about was regarding some minor feature update, who cares? But when the update is all about blocking an exploit in the wild, we users deserve everything to 'just work' in a hurry. Waiting around for a company to get their security release and explanation together is not professional, at least not IMHO. So Adobe, please get your act together for the benefit of your victims, oops I mean users.

BTW: The usual warning

Adobe Flash is the second most dangerous software you can run on your Mac over the Internet. It's second only to Oracle's ruined version of Java for the Internet. If you don't need to run either of these Internet plugins, uninstall them and trash them.


Wednesday, May 20, 2015

Apple's First Watch OS Security Update: v1.0.1


Apple has released the first security update for the Watch via Watch OS 1.0.1 You can read the security content document here:

About the security content of Watch OS 1.0.1

Included in the update are eight Watch OS Kernel patches, some of which are critical. There are also another couple patches that protect Kernel data. Also patched was the good old FREAK/Logjam security hole caused by the potential use of decrepit RSA encryption algorithms in HTTPS Internet communication.

For fun, here is the document for CVE-2015-1067, 'FREAK':


The document provides links to all of Apple's previous FREAK patches.

If you're interested in why FREAK/Logjam remains a worldwide problem, as well as its more recent implications, Dan Goodin at Ars Technica wrote a relevant article last week:

HTTPS-crippling attack threatens tens of thousands of Web and mail servers
Diffie-Hellman downgrade weakness allows attackers to intercept encrypted data.
The weakness is the result of export restrictions the US government mandated in the 1990s on US developers who wanted their software to be used abroad. The regime was established by the Clinton administration so the FBI and other agencies could break the encryption used by foreign entities. Attackers with the ability to monitor the connection between an end user and a Diffie-Hellman-enabled server that supports the export cipher can inject a special payload into the traffic that downgrades encrypted connections to use extremely weak 512-bit key material. Using precomputed data prepared ahead of time, the attackers can then deduce the encryption key negotiated between the two parties.
"Logjam shows us once again why it's a terrible idea to deliberately weaken cryptography, as the FBI and some in law enforcement are now calling for," J. Alex Halderman, one of the scientists behind the research, wrote in an e-mail to Ars. "That's exactly what the US did in the 1990s with crypto export restrictions, and today that backdoor is wide open, threatening the security of a large part of the Web."
IOW: Politics as a security hole. :-P


Monday, May 18, 2015

LUSER Factor Strikes Again


The most appalling term I use on this blog is 'LUSER'. I capitalize it to emphasize it. The LUSER Factor is that one security hole that can never be patched. All we can do is guard against it as a problem source from others and a problem source from ourselves. 

Brian Krebs wrote a great article last week specific to the LUSER Factor:

Starbucks Hacked? No, But You Might Be
... Those customers had all chosen to tie their debit accounts to their Starbucks cards and mobile phones. Sullivan allowed in his story one logical explanation for the activity: These consumers had re-used their Starbucks account password at another site that got hacked, and attackers simply tried those account credentials en masse at other popular sites — knowing that a fair number of consumers use the same email address and password across multiple sites.
Protect yourself from yourself and sort out your passwords. All of them must be different. All of them must be as random and unguessable as possible. Store them all up in a password protection program like 1Password or LastPass. Learn how to put the OS X Keychain to good use.


Tuesday, May 12, 2015

Installer Adware Infestations: MPlayerX...


An old plague on the Windows platform is now infesting the Mac platform: Nefarious ADWARE.

I want to bring attention to Thomas Reed's 'The Safe Mac' new article about an adware infection in the MPlayerX installer:

MPlayerX adware behaving like malware!

Marketing moron crooks are making it tougher to stop them from shoving adware onto victim's Macs or to identify when the infecting installers are dangerous. This is the same bad attitude as the spamrats. Therefore, my new term for these vermin is adwarerats.

As I've covered previously, it's important to avoid software download websites that deliberately infect installers with malware. At this point, these are the three safe download sources I use every day:

MajorGeeks Mac
Apple's Mac App Store

Evil Download Mirror Sites

Recently, I've seen mirror sites for innocuous application downloading infesting those downloads with 'installers' that hide the actual application you wanted to install behind an adware installer. I personally experienced this when attempting to download the FrostWire application from it's source website. For the download, my browser was passed along to a mirror site that then dumped on me a fraudulent installer. (FrostWire does not actually have an installer! It's installation is simply a drag and drop into your Applications folder). Knowing something was wrong, I dug into the 'Installer' and found it was simply a script that triggered the further downloading of:

A) ZipCloud adware.
B) FrostWire AFTER the adware had been installed.

Installing the ZipCloud garbage was required before I could actually get at the FrostWire installation.

IOW: We're now in a state of Man-In-The-Middle meddling with the installation of Mac software.

If you've been the victim of CNET's AWFUL Downloads.com (formerly dear old VersionTracker), you know this story already. This intervention between you and what you want to download and install is now standard at that horror of a website.


If you download an application from any website (as opposed to Apple's Mac App Store), and you're confronted with an 'Installer', BE WARY. 

If that 'installer' attempts to download and dump on you ANYTHING other than what you intended to install, STOP THE INSTALLATION and complain to the source download website.

Adware is NEVER acceptable, unless you specifically ASK for it to be installed. Never let an installer shove that crap on you, with or without asking you.

Yes, marketing morons ARE out to get us. It's called Customer Abuse. Please join in the effort to wipe this crap out of the Mac community.

One concept: If you run into one of these evil mirror sites for download, post their URL here as a comment. I'll happily test them out, share my results, and raise a loud noise to have that site firebombed, metaphorically speaking.

And as usual, the best way to find and remove adware from your Mac is to use Thomas Reed's Adware Medic. It's donationware. It's excellent.



Wednesday, April 29, 2015

100,000+ iOS Apps Compromised
By Bad AFNetworking Libraries.
The list of affected apps and bugs grows.


Right off the bat, here is what you need to know:

*Where to check if you're running bug affected iOS apps*

Enter the name of the developer of an iOS app you use over the Internet on your iOS devices. Hit the Search button. SourceDNA will then check that manufacturer against its [secret] list of AFNetworking bug affected apps and let you know if your iOS devices are currently in danger. It an app is affected, DON'T USE IT until it has been patched to AFNetworking library v2.5.3. Keep checking at the Report page or check with the iOS app developer to find if a specific app has been patched.

The TWO AFNetworking library security bugs, found in versions 2.5.1 AND 2.5.2

NOTE: The AFNetworking bugs do NOT affect iOS 8 itself, or any of the native Apple iOS apps, including Safari. Apple does not use AFNetworking. Apple apps are entirely safe to use. You may wish to fall back to using iOS Safari for your Internet work, as opposed to bug affected third party apps, until this situation ends.

I read about the first of these iOS app security problems last week, but sensed the scenario was not yet complete. At the end of last week, another great big shoe dropped, making the situation considerably more dangerous. Let me walk you through a few news articles about the AFNetworking bugs, in chronological order:

March 26, 2015, Simone Bovi and Mauro Gentile at Minded Security

SSL MiTM attack in AFNetworking 2.5.1 - Do NOT use it in production!
During a recent mobile application security analysis for one of our clients, we identified a quite unobvious behaviour in apps that use the AFNetworking library.

It turned out that because of a logic flaw in the latest version of the library, SSL MiTM attacks are feasible in apps using AFNetworking 2.5.1.

The issue occurs even when the mobile application requests the library to apply checks for server validation in SSL certificates.

Given that AFNetworking library is one of the most popular networking library for iOS and OS X and it is used by Pinterest, Heroku and Simple among others, the problem could affect a very high number of mobile users. . . .
April 20, 2015, Dan Goodin at Ars Technica
1,500 iOS apps have HTTPS-crippling bug. Is one of them on your device?
Apps downloaded two million times are vulnerable to trivial man-in-the-middle attacks.
About 1,500 iPhone and iPad apps contain an HTTPS-crippling vulnerability that makes it easy for attackers to intercept encrypted passwords, bank-account numbers, and other highly sensitive information, according to research released Monday. . . .

Although AFNetworking maintainers fixed the flaw three weeks ago with the release of version 2.5.2, at least 1,500 iOS apps remain vulnerable because they still use version 2.5.1. That version became available in January and introduced the HTTPS-crippling flaw. . . .
According to research published Monday by SourceDNA, about 1,500 iOS apps remain vulnerable to man-in-the-middle attacks that can decrypt HTTPS-encrypted data. To exploit the bug, attackers on a coffee shop Wi-Fi network or in another position to monitor the connection of a vulnerable device need only present it with a fraudulent secure sockets layer certificate. Under normal conditions the credential would immediately be detected as a counterfeit, and the connection would be dropped. But because of a logic error in the code of version 2.5.1, the validation check is never carried out, so fraudulent certificates are fully trusted.
Dan's original article, quoted above, cited a blog posting by SourceDNA that had been released earlier that day, April 20th. SourceDNA's post has since been considerably updated as further information has been collected. Originally, the blog posting noted at least 1,500 iOS apps had been found to be affected by the AFNetworking library bug. That figure has currently progressed to 'over 100,000'. Below I quote the posting as of this moment. Keep an eye on it as revelations of this specific AFNetworking library v2.5.1 bug problem progresses.

April 20, 2015... SourceDNA
You know there's a security flaw hidden in over 100,000 iOS apps out of the 1.4 million total, but which ones are actually vulnerable? How would you find out?

SourceDNA is constantly scanning apps from the app stores, analyzing and indexing their binary code. This lets us search for apps by their behavior and the tools & libraries they were built with.

AFNetworking recently had a major security flaw. Due to lack of SSL cert validation, the proverbial coffee shop attacker could easily bypass SSL and see all your app's user credentials and banking data. We decided to track down apps that were still using the vulnerable version of AFNetworking and notify their developers so they could patch the flaw.

First, we had to determine the vulnerability window. We found the AFNetworking flaw was present in the Github repo from January 24 through March 25. More importantly, it had been released as version 2.5.1 on February 12 before being fixed in version 2.5.2. Any developer who updated their app during that window could have integrated the vulnerable library.


A new security bug was found in both v2.5.1 and the updated AFNetworking library v2.5.2.

April 24, 2015... SourceDNA
AFNetworking Strikes Back: 25,000+ Apps
... A few weeks ago, we found that version 2.5.2 did fix this issue, but there was another flaw nearby in the same code. Domain name validation could be enabled by the validatesDomainName flag, but it was off by default. It was only enabled when certificate pinning was turned on, something too few developers are using.

This meant that a coffee shop attacker could still eavesdrop on private data or grab control of any SSL session between the app and the Internet. Because the domain name wasn't checked, all they needed was a valid SSL certificate for any web server....

We've updated Searchlight to show which apps are still vulnerable, and we'll continue to publish new results there as affected apps are updated....
April 24, 2015, Dan Goodin at Ars Technica
Critical HTTPS bug may open 25,000 iOS apps to eavesdropping attacks
Just when you thought it was safe to use AFNetworking apps, a new threat emerges.
At least 25,000 iOS apps available in Apple's App Store contain a critical vulnerability that may completely cripple HTTPS protections designed to prevent man-in-the-middle attacks that steal or modify sensitive data, security researchers warned. 
...The bug resides in AFNetworking, an open-source code library that allows developers to drop networking capabilities into their iOS and OS X apps. Any app that uses a version of AFNetworking prior to the just-released 2.5.3 may expose data that's trivial for hackers to monitor or modify, even when it's protected by the secure sockets layer (SSL) protocol. The vulnerability can be exploited by using any valid SSL certificate for any domain name, as long as the digital credential was issued by a browser-trusted certificate authority (CA).
"The result is an attacker with any valid certificate can eavesdrop on or modify an SSL session initiated by an app with this flawed library," Nate Lawson, the founder of security analytics startup SourceDNA, told Ars. "The flaw is that the domain name is not checked in the cert, even though the cert is checked to be sure it was issued by a valid CA. For example, I can pretend to be 'microsoft.com' just by presenting a valid cert for 'sourcedna.com.'"

Lawson estimated that the number of affected iOS apps ranged from 25,000 to as high as 50,000. SourceDNA has provided a free search tool that end users and developers can query to see if their apps are vulnerable. To make it harder for attackers to exploit the vulnerability maliciously, SourceDNA isn't providing a comprehensive list of vulnerable apps. . . .
iOS users should immediately check the status of any apps they use, especially if the apps convey bank account numbers or other sensitive personal information. It may take the developers of vulnerable apps a few days to release an update that incorporates the AFNetworking fix, so users should be prepared to avoid any vulnerable versions for the time being. The AFNetworking error affects only apps that use the code library. The device itself and other apps, including browsers, aren't affected by the flaw, even if one or more apps on the device are vulnerable.
(All emphasis above is mine). The way this series of bugs is progressing, I'd count on 50,000+ iOS Apps affected.

Some of the iOS apps testing positive for this second AFNetworks library v2.5.2 bug include:

Bank of America
Wells Fargo
JP Morgan Chase

Meanwhile, ALL Microsoft iOS apps have tested positive for the original AFNetworks library v2.5.1 security bug.

DEVELOPERS: Update your iOS apps to AFNetworks library v2.5.3 immediately.

iOS USERS: Check ALL the iOS apps you use over the Internet via the Source DNA testing page. Bop back up to the top of this article for the link to the Source DNA iOS Security Report page where you can check for affected developers and their applications. But here is the link again for your pleasure and convenience:

* Note that I will provide updates near the top of this post if/when further information about the AFNetworking bugs is available.


Thursday, April 23, 2015

Not In-The-Wild:
iOS 8 SSL Certificate Parsing Bug:
Crash, Crash, Crash


Interest Level: Background

The system used to encrypt data sent across the Internet has had a bad time this past year. A parade of bugs and exploits have been found. Related problems in hash functions have been found. Fraudulent security certificates have been forged by questionable certificate authorities. Google has injected a level of paranoia as well as demands for technology improvements, while itself ignoring its own aspirations. The result is a complicated and confusing mess that leaves users wondering what is safe and what is not.

On Wednesday, Dan Goodin of Ars Technica reported a new twist in the Internet encryption contortions by way of a report and public presentation from the company Skycure. They have found a bug in iOS 8 that allows an attack on iOS devices over Wi-Fi through the use of a malicious SSL security certificate. This attack can trigger Apple devices running iOS 8 to go into an endless crash loop while in the connection vicinity of the offending Wi-Fi network.

Note that this bug is NOT yet being exploited in the wild. It is at this point simply of interest while we wait for Apple to patch the bug and prevent it from becoming a real problem for users.

Below, I have linked both Dan Goodin's article and the source blog post from Skycure.

If you're interested in higher level Mac and iOS security, this is well worth a read. Otherwise, it's in the background as only a potential problem to iOS users.

iOS bug sends iPhones into endless crash cycle when exposed to rogue Wi-Fi
SSL cert parsing error allows attackers to create "No iOS Zone," researchers say.
- Dan Goodin, Ars Technica

“No iOS Zone” – A New Vulnerability Allows DoS Attacks on iOS Devices
- Yair Amit, Skycure

Both articles provide videos illustrating the SSL certificate bug.

Share and Enjoy,


Upcoming Changes To The Mac-Security Blog


In order for me to continue this blog amidst the other work I do, I'm going to make two basic changes.

The first is that this blog is going to generally change from longer posts with my commentary to shorter informative posts that act as alerts to those interested in what's going on in Macintosh and iOS security. This allows me to be more spontaneous and not have to spend a great deal of time writing.

The second is that the geek-level of this blog is going to increase considerably. Translation: I'm going to raise the level of what I post to that of my own level of understanding and interest in Mac and iOS security. This allows me to be more spontaneous and closely fit my blog posts with what I am discussing on the net with others about Mac security.

As such, I expect this blog will at times challenge the understanding and comprehension of some readers. I also expect criticism that the blog draws attention to esoteric and unimportant aspects of Mac security. The usual phrase used in such criticism is FUD: Fear, Uncertainty and Doubt. This means that taking my posts too seriously may mean that they sound needlessly alarmist. We will hopefully sort out how to address this situation as my new approach progresses.

The overall reason for these changes is that my time is limited, but I still want to share the latest news regarding all aspects of Mac and iOS security. I regularly chatter about computer security with several people on the Internet. I'd like save myself time and effort by synchronizing my blog posts with my background security chatter.

We'll see how well this works over time. For the moment, it's a strategy that allows me to be more active on the blog and may well help many readers keep up with what's going on both on important and esoteric levels.

Please feedback at me to help me know the impact of this new approach.