Recognize the Fact of Android Endpoints

April 20, 2016

The BYO hypesters that I am exposed to tend to trend strongly toward all things Apple.

Earlier today, a ranking security leader saw a slide highlighting the history of iOS and OSx vulnerabilities and snapped something about the market speaking through Apple’s sales dominance… …as if Apple ‘owned’ our customer, prospect, and employee population.

This seems to happen a lot. I work for an overtly “global” financial services corporation. Leading technologists on staff promote Apple products as the solution to virtually any endpoint challenge (we currently do our business on tens of thousands of Windows endpoints running Windows applications…). The company that pays us is attempting to generate strategic expansion in Latin America and Asia…  We want and need to service people’s financial services needs where they are — meaning strong support for interactions via their mobile devices.  The mismatch is cringe-worthy.

How does this marketplace blind spot afflict so many people who otherwise are intelligent adults?  I really don’t know.  Maybe financial services professionals are becoming prisoners of their own cognitive traps?

MacRumors recently announced that “iOS and Android Capture Combined 98.4% Share of Smartphone Market.” The Apple portion of that global 2015 market share was 17.7% (down from 20.4% in 2014). Android-based mobile devices represented 80.7% of the 2015 market (up from 76.0% in 2015).

Year after year people around the world purchase more Android mobile devices than the competing Apple devices. In 2015 that amounted to more than 4.5 Android mobile devices purchased for every Apple iOS device sold.

Gartner (Feb 2016) reported:

Worldwide Smartphone Sales to End Users by OS in 4Q15 (in Thousands of Units)

           4Q15     4Q15 Market   4Q14      4Q14 Market
        Units Sold  Share %     Units Sold  Share %
Android 325,394     80.7        279,057     76.0
iOS      71,525     17.7         74,831     20.4
Windows   4,395      1.1         10,424      2.8
Blackberry  906      0.2          1,733      0.5
Others      887      0.2          1,286      0.4


Sure, the Android == ‘security hell’ meme has some good reasons for retaining its foothold in business culture. And sure, there are many more ‘ancient’ unpatched/underpatched Android devices compared to the iOS environment. There are attractive and repulsive characteristics of Android/iOS environments that we can argue about, but that avoids the fact that our employees, customers, and prospects buy and use more Android devices.  A lot more.  We will leave a lot of money on the table if we ignore that fact and build software & operations that are tightly-coupled with Apple mobile device products.

OK. I had to get that out of my system…


“iOS and Android Capture Combined 98.4% Share of Smartphone Market.”
By Joe Rossignol, Feb. 18, 2016

“iPhone lost market share to Android in every major market except one.”
Jim Edwards, Jan. 27, 2016


Can Financial Services Explain How Mac OS X Security is Good Enough?

April 29, 2015

After years of attempting to generate love by claiming that a Mac “doesn’t get PC viruses. A Mac isn’t susceptible to the thousands of viruses plaguing Windows-based computers.” ( 2012)”, Apple has introduced technology for at least 4 different approaches to strengthening OS X resistance to hostile malware.

These features include:

  • gatekeeper
  • xprotect
  • OS X sandbox
  • code-signing

Each of these features is an attempt to compensate for and overcome software architectures, designs, and implementations that are overly-permissive — resulting in software that too easily “trusts.”  They represent the type of “bolt on security” that Financial Services enterprises are expected to implement throughout their secure software practices.  “Secure-enough” software needs to be created or adapted with that goal in place throughout the entire SDLC and/or acquisition process and must not treat risk management as something that is applied to software only after it is finished.

There is a lot of evidence that these features are still far too little, too late. In a recent presentation at RSA, Patrick Wardle, Director of Research, Synack, described the current situation as “lots of Macs, feeble anti-malware protections, os x malware, and limited detection/prevention tools.” He then walked the audience methodically through exploits against each of the Apple OS X anti-malware protections, and then outlines a range of approaches to Mac malware persistance. Finally, he mentions a couple tools for detecting OS X malware: knockknock (ui) & blockblock.

Wardel’s presentation references OS X malware/exploit work by fG!. In one relatively recent talk at SyScan15, after 165 slides outlining OS X threat vectors and their exploit he concluded that “Apple product security strategy is reactive not proactive. If they have any strategy at all…”

These guys don’t represent an isolated fringe of the the professional risk management world.  They are serious professionals, attempting to help others “get it.”  Their work seems to be a shout for recognition that OS X malware-enabled exploits represent a foundational and (for most Financial Services enterprises) critically-important risk.

Why is this such a big deal?  Remember, each of our organizations needs to be diligent and effective at resisting attack along all vectors, while attackers need only be successful against one of them.  Attackers know that Macs are vulnerable via a number of vectors, that Mac security products are not great, and that Mac users are finding ways to “plug them into” corporate environments.

For many Financial Services enterprises, request by request, exception by exception, members of the workforce have been hosting an increasing range of business activities on Macs (on both unmanaged, and under-managed endpoints).  They are granted remote access.  They are plugged into our “trusted” internal networks.  And they get the same “trusted” access as heavily-managed, standard Windows endpoints.  Sometimes an organization has a fog of “managed” or “secured” and authorized Macs that mask this core risk management issue — which, for the most part, remains the same.

As a result, we need to help our leaders carefully think through:

  • Whether this is risk-appropriate for any given Financial Services use case,
  • What alternatives to current Mac-enabled practices exist, and should we migrate to them? Are isolation techniques “good-enough?”
  • How we are going to protect our assets and operations from the threat vector Mac endpoints pose?
  • How are we going to tell our Mac endpoints risk management story to all relevant stakeholders?


“Malware Persistence on OS X Yosemite” by Patrick Wardle (
Thursday, April 23, 2015


“BadXNU — A rotten apple!.” by fG!/@osxreverser (



Mac Boot Hacked via Thunderbolt Port

January 14, 2015

Too many of us still have to deal with members of our workforce who hold groundless beliefs about the freedom from risk they enjoy while using their Macs.

Trammell Hudson described his most recent project at the last Chaos Communication Congress in Germany. It is called Thunderstrike and it can infect any modern Mac boot ROM via the Thunderbolt port — ultimately giving the attacker control of the endpoint. This “evil maid” attack gives us all another reason for concern. Anyone with physical access to a worker’s Mac could use this technique (or one of its predecessors) as a foothold into your network, as well as gaining “direct” access into any operations to which that user has been permitted. Traveling executives seem like obvious targets, but virtually any member of the workforce is a candidate.

Mr. Hudson describes the impact of his attack as:

“There are neither hardware nor software cryptographic checks at boot time of firmware validity, so once the malicious code has been flashed to the ROM, it controls the system from the very first instruction. It could use SMM, virtualization and other techniques to hide from attempts to detect it.

Our proof of concept bootkit also replaces Apple’s public RSA key in the ROM and prevents software attempts to replace it that are not signed by the attacker’s private key. Since the boot ROM is independent of the operating system, reinstallation of OS X will not remove it. Nor does it depend on anything stored on the disk, so replacing the hard drive has no effect.”

At a minimum, this should be used as input for traveler’s security awareness training.

It should also be injected into risk analyses of all BYOD scenarios.

“Thunderstrike.” By Trammell Hudson.

“De Mysteriis Dom Jobsivs: Mac EFI Rootkits.” By Snare (Blackhat 2012)

“Apple’s Mac EFI found vulnerable to bootkit attack via rogue Thunderbolt devices.” By Sam Oliver, Dec 22, 2014

“Thunderstrike: The scary vulnerability in your Mac’s Thunderbolt port.” By Christina Warren, Jan 02, 2015

Macs vulnerable to virtually undetectable virus that “can’t be removed” By Adrian Kingsley-Hughes, Jan 12, 2015

Another Reason to Disbelieve The Apple Security Story

September 2, 2014

Some subset of any Financial Services organization’s workforce has BYOD fever.  For many in our business, that fever has infected one or more senior leaders who cannot be ignored.  In Financial Services, we are collectively responsible for protecting $trillions of other people’s assets.

Most of the BYOD fever seems to be associated with new mobile devices.  From what I can observe, many Financial Services organizations are emphasizing their attraction to Apple iPads over Android or other alternatives.  That behavior seems out of phase with our due diligence obligations.

Apple has invested what must be a tremendous amount of resource and effort in building an image that incorporates something like “trust me, but I will not respond to your requests for transparency…”  For some reason, that seems to work.  This is in spite of regular patching of vulnerabilities that could have been discovered at architectural analysis, design, coding, static code security analysis, QA or penetration testing.  Apparently those activities do not incorporate effective secure software practices.

The latest example of Apple’s approach to software security made the news over the last weekend.  A vulnerability in iCloud enabled a trivial attack to discover the passwords of a number of targeted individuals.  Those passwords were then used to steal those user’s iCloud “protected” personal files.  Apple did not enforce a “max attempts” threshold for failed attempts to login to iCloud, which permitted attackers to pound away at the URL$apple_id/initClient with basic auth attempts using scripts or malware that identified itself as ‘User-Agent’: ‘FindMyiPhone/376 CFNetwork/672.0.8 Darwin/14.0.0’.   An easy-to-understand proof-of-concept application is available on github.

Remember, in Financial Services, implementing some type of failed-login governor has been standard practice since we have been using the Internet for business.  Our constituents expect some type of “n-failed-login-attempts-and-you-are-locked-out.”  They may not consciously think through a detailed rationale, it is just a small but essential part of exhibiting a threshold level of Financial Services due diligence.  I assume that one possible root cause was that Apple engineers and architects must have reasoned that either nobody could format a basic auth HTTP POST with some json payload and sling it at their iCloud web service interface, or they believed that their closed ecosystem and black box approach to security implementations would keep their web service interface from being discovered.  Alternatively, they specified a max-failed-login-attempts feature into iCloud designs, but Apple management directed them to remove it based on non-technical rationale.  There could be other root causes of this vulnerability, but with the resources available to Apple, none seem in alignment with their “trust us” story-telling.  Their iCloud authentication implementation was just not fit for Financial Services workforce operating environments — while they have been arguing that “”iCloud is built with industry-standard security practices and employs strict policies to protect your data.”

Brute forcing passwords is a proven, decades-old practice that is highly effective unless resisted (because people, in large numbers, behave so predictably).  Financial Services-grade businesses understand this and implement and enforce policies that generally resist bald, brute force attacks.  It is a small, simple, basic, and essential characteristic of any Internet-ready system hosting non-public resources.  The fact that Apple implemented an Internet-facing authentication interface without resistance to brute force password attack, then failed to implement defense in depth (i.e., instrument the environment with effective IDS/IPS, identity fraud detection, and more) demonstrates — again — their unfitness for the Financial Services workforce environment.

Update 09-03-2014:

Could it be that Apple considers hackappcom’s proof of concept application and demonstrations of its use just another side-show?  They reacted to news about the celebrity data theft using what I read as legalistic and deflecting language:

“None of the cases we have investigated has resulted from any breach in any of Apple’s systems,” Nat Kerris, a company spokeswoman, said in a statement. “We are continuing to work with law enforcement to help identify the criminals involved.”

Update 09-06-2014:

Apple, via CEO Tim Cook continued the Apple ecosystem and its technology are safe theme, blaming users for the recent iCloud vulnerabilities and their exploit, saying in a WSJ interview that Apple would ratchet up user awareness communications about stronger and safer passwords, and apparently will not be investing in more effective engineering:

“When I step back from this terrible scenario that happened and say what more could we have done, I think about the awareness piece,” he said. “I think we have a responsibility to ratchet that up. That’s not really an engineering thing.”

Mr. Cook also said that Apple would would begin sending users email messages and push notifications when certain AppleID events occur or when a user’s account data lands on a new device.

After a 40-hour investigation “concluded that there was no breach of its data servers. The company has said it discovered a number of celebrity accounts were compromised by targeted attacks…”

Sure.  Not ready for Financial Services.



“Hacker leaks dozens of nude celebrity pics in alleged iCloud hack.”
By Cody Lee, Aug 31, 2014

“Apple reportedly patches Find My iPhone vulnerability to hack Apple ID accounts.” By Christian Zibreg, Sep 1, 2014

“ibrute.” By hackappcom

“Apple patches ‘Find My iPhone’ exploit.” By Adrian Kingsley-Hughes, Sep 1, 2014

“iCloud: iCloud security and privacy overview.”

“iCloud Keychain.”

“Privacy Collides With the Wild Web.” By Mike Isaac, Sep 2, 2014 (downloaded Wed 09/03/2014 5:46 AM)

“Apple Says It Will Add New iCloud Security Measures After Celebrity Hack.” By Brian X. Chen, Sep 4, 2014

“Tim Cook Says Apple to Add Security Alerts for iCloud Users — Apple CEO Denies a Lax Attitude Toward Security Allowed Hackers to Post Nude Photos of Celebrities.” By Daisuke Wakabayashi, Sep 5, 2014

“Apple Media Advisory: Update to Celebrity Photo Investigation.” (downloaded Sat 09/06/2014 5:56 PM)

Keylogger Revealed in the Apple iOS Ecosystem

February 25, 2014

In the course of their daily grind, Financial Security professionals dealing with the current BYOD fever often refer to risks associated with use unmanaged endpoints in business operations — especially when this involves using consumer-oriented unmanaged tablets and/or phones running Android or iOS.  A special subset of that risk involves the theft of company credentials — generally still a username/password pair.  Once those credentials are ‘owned’ by hostile actors, a targeted organization is at elevated risk along any dimension associated with the ‘real’ worker’s role.  For example, a hostile who possesses credentials of the chief financial officer, treasury personnel, database administrator, server administrator, or other individual with elevated rights can (in theory) perform all the activities authorized for those individuals — which would result in material risk to your organization.  All risk management professionals and decision-makers at all levels need to keep these risks in mind as they evaluate the appropriateness of BYOD for their organization(s).

In the last month, two separate research teams (from Trustwave and FireEye) have produced proof-of-concept apps to exploit an iOS flaw that allows a hostile party to record every tap and keystroke made on an Apple iOS device — jailbroken or not.  This type of software has been around in the Android marketplace for some time.  But Apple and its ‘marketers’ have been adamant that various features of the iOS operating system architecture provide overlapping layers of protection to prevent this type of activity, and as a final backstop their (opaque) App Store app review practices effectively eliminate the risk of overtly hostile software successfully behaving in a hostile manner in the iOS ecosystem.  In other words, “just trust us…”  A recent example of ‘analysis’ of this type — stating that “there is essentially no iOS malware” — might include “Defending Data on iOS 7.”

Security researchers have identified a vulnerability which allows malicious actors to log your taps & keystrokes (X-Y coordinates) before sending that data to a remote server of their choice.

Mobile specialists on staff of security company FireEye have been collaborating with Apple after creating a proof-of-concept app, and deploying it through the production Apple App Store review process without detection, and then having it successfully exploit a non-jailbroken iOS 7 device after downloading and installing from Apple’s App Store.

In practice, the ‘keylogging’ would be an ‘added feature’ in an otherwise ‘reasonable’ app, and a hostile party would use phishing or other social engineering to mislead victims into installing their software.  Another route would be to exploit another remote vulnerability in iOS itself or in another app to begin the malicious app download process.

According to the authors, the exploit works on non-jailbroken modern iOS devices, including iOS 7.0.5, 7.0.6 and 6.1.x.

In the context of the recent iOS SSL vulnerability — something that any reputable static code security analysis product or service would have caught — it is difficult to support Apple’s opaque ‘trust us…” approach to security details.  I believe that Apple is going to have to be much more transparent to win over the Financial Services markets.

The exploit takes advantage of the way Apple’s exceptions to the iOS settings for “background app refresh.” Security-conscious users can use settings to ‘disable’ specific app’s background refreshing. App authors, though, are allowed to bypass the user’s wishes. One example is permitting an app to play music in the background without turning on its ‘background app refresh’ switch. It appears that in this case, the proof-of-concept app may have disguised itself as a music app to conduct background monitoring. MDM vendors also deploy apps that exhibit analogous behaviors to this ‘backgrounding exception.’ Even when an iOS device is set to deny all ‘Background App Refresh’ the MDM app will continue to run, examining the local device, and ‘calling home’ with results of that assessment.

As we have mentioned before on this blog, the Android app marketplace is still an ‘elevated security risk muddle,’* and there is no ‘Apple security magic.’ Apple has an excellent record of managing their image, but an uneven record at implementing real, or Financial Services-grade resistance to hostile actors.

Until Apple figures this one out, iOS users should avoid at least some of this risk by using the iOS task manager to stop unnecessary apps from running in the background. This will prevent a range of potential elevated risk monitoring that might be occurring.** iOS7 users can press the Home button twice to enter the task manager and see preview screens of apps opened, and then swipe an app up and out of preview to disable unnecessary or suspicious applications running on the background.

*Technical term.
**Remember, an MDM agent is a ‘trusted’ app and is used to qualify endpoints for some types of access to private infrastructure. If your company requires a given MDM agent, I recommend that you let it continue to run.
“Researcher Creates Malware to Captures Every Tap on Your Smartphone or Tablet.” By David Gilbert , January 31, 2014

“New iOS flaw makes devices susceptible to covert keylogging, researchers say — Proof-of-concept app in Apple’s App Store sent keystrokes to remote server.” By Dan Goodin – Feb 24 2014

“Background Monitoring on Non-Jailbroken iOS 7 Devices — and a Mitigation.” By Min Zheng, Hui Xue and Tao Wei, February 24, 2014

“Defending Data on iOS 7. Version 2.0” by Rich Mogull, Securosis.

Apple iPhone 5S TouchID Beat Using Simple Approach

September 23, 2013

Some in Financial Services seemed to think that now, finally, it would be easy to do serious business with Apple’s new iPhone 5S TouchID mobile device.  The advanced biometric authentication would, so the argument goes, secure the environment — the device and its use — in ways that were going to make risk management easy…

…”Oh, those sad Windows users.  What will we do with them?”


The German hacker organization “Chaos Computer Club” (CCC) uploaded a YouTube video appearing to demonstrate a successful hack of the new iPhone TouchID biometric authentication.  In the short video an individual appears to access an iPhone 5S using a fabricated fingerprint.

This new option was promoted by Apple as a better way to protect devices and to protect sensitive information stored on or accessed by them.

Just last week, I heard an industry pundit say — seriously — that “mobile security was solved” because of the strength of Apple’s biometric security.”  When I responded with a muted challenge, the individual’s demeanor suggested pity for me (at best).

CCC member with the pseudonym starbug said on the organization’s site, “For years we have repeatedly warned against the use of fingerprints for access control. We leave fingerprints everywhere, and it is a breeze to create fake fingers from it.”

The CCC approach, as described in their announcement on Sat, Sept. 21st, used materials that are common in most households:

  1. Photograph the fingerprint of a targeted user with a resolution of 2400 dpi.
  2. Invert the photo on your computer
  3. Print on transparency film it using a laser printer at 1200 dpi.
    In a CCC video, the technique appeared to involve etching a PCB board,,, Not everyone has easy access to board etching equipment, but it is not that unusual (maybe as common as lock picks?)
  4. Apply a skin-colored latex milk or white wood glue to the image.
  5. The “pressure lines” create a fingerprint image in the deposited material.
  6. After drying, remove the counterfeit finger.
  7. Moisten the “fingerprint” slightly by breathing on it.
  8. Unlock the targeted iPhone with it.

Frank Rieger, speaker of the CCC, said that “The public should no longer be led around by the biometrics industry with false statements on the nose.  Biometrics is suitable to monitor and control people not to (secure) everyday devices against unauthorized access.”

Biometrics have always been a challenge.  That state continues.

In the case of the Apple 5S TouchID, the Apple marketing may have been a little misdirection as well — as in, ‘Hay! Look at this great new button over here!” — rather than dealing with the difficult block & tackle work of building out secure secure-enough endpoints and supporting cloud infrastructure across their entire life-cycles.  There may be niches in the consumer market for the TouchID, but it seems like the iPhone 5S implementation does not deliver for real business.

If this announcement described the real state of the Apple 5S TouchID technology and implementation, that identity infrastructure is still not ready for broad or routine integration into the operations of Financial Services enterprises.

What do you think?

​”Chaos Computer Club breaks Apple TouchID hacking iphone 5S”
By Rose Sodre, Sep 23, 2013
“Chaos Computer Club hackt Apple TouchID.”
By frank, 2013-09-21 22:04:00
[This page is in German.]
“The iPhone 5s Touch ID hack in detail.”
A video containing more details about the techniques used to copy and misuse a fingerprint against Apple iPhone 5S TouchID]
“Bypassing TouchID was ‘no challenge at all,’ hacker tells Ars — German hacker Starbug tells Ars how he bypassed the fingerprint lock on new iPhones.” by Dan Goodin – Sept 24 2013,
“We’ve cracked Apple’s fingerprint scanner: German hackers .”
Published on South China Morning Post (

“iPhone 5s: About Touch ID security.”

“Investigating Touch ID and the Secure Enclave.”

By Rich Mogull, 23 September 2013
“A Quick Response on the Great Touch ID Spoof.”
By Rich Mogull, 22 September 2013

%d bloggers like this: