Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

The Grey Line Between Feature and Vulnerability, iOS edition

I do a lot of Mobile Application Penetration testing for some of our largest clients. Mobile is the new sexiness and everybody wants in. This means that there is a lot of misunderstanding of how some of the technology works and with misunderstanding, usually comes security flaws and vulnerabilities.

It was with this in mind that I was taken by surprised a few weeks ago by one of these clients, who, in a panicy phone call to me, asked if I had heard of this new iOS vulnerability floating around. It was horrible, they said, and could allow attackers to intercept and steal any data - ANY DATA - on or passing through any iOS device. Why, it could even be done via a drive by download.

Now, I follow the jailbreak and iOS security community pretty closely, and I had never heard of this. My client said they heard about it at DEF CON and it was causing a riot internally.

The vulnerability? Method Swizzling.

This was a classic case of broken telephone combined with not quite understanding the underlying technology. So, as I did with my client, let me se the record straight:

Method Swizzling is not a vulnerability, but a feature of the Objective C runtime.

What is Method Swizzling?

Method Swizzling is the ability to swap the implementation of a method for an alternate implementation at runtime, using a set of Objective C's reflective API calls. That is, if I have a method foo:withString, I can swap out the implementation of that method to one I wrote, say myFoo:withString. This means instead of the original method being run, mine is. I can then choose to return, or run the roginal method implementation after mine is run.

The effect if similar to method detouring on Windows (think DLL injection with MS Detours), except much easier to do.

It is a nice feature for instrumenting any public API call (and in Objective C, that's almost all of them, even in Apple's core libs) for logging, performance, adding or augmenting features. In the jailbreak community, this is how UI Tweaks are created.

Of course, like any feature, it can be misused. Method detouring on Windows is one of the most common vectors for method hooking and snooping. Reflection on Java is being misused by the current exploit on Java 7 in the wild.

But none of that means swizzling is a vulnerability.

The real issue is the threat model and whether abusing method swizzling is a viable attack vector.

One of the most important things to remember about method swizzling on iOS, is that you can't do it unless you jailbreak the device. The first step in abusing this on the platform is to jailbreak, then install your hooks. The jailbreak can be done by the user or surreptitiously by the attacker, but it must be done to defeat Apple's Codesigning checks (code not signed by Apple will not run on a stock device. Period). Jailbreaking also curretly requires physical access to a device. The remote exploit does not work on iOS devices above 4.2 nor does it work on A5 based devices such as the iPad2. Its not been a viable attack vector for remotely jailbreaking iOS devices for about a year.

For some apps, such as banking apps ironically, this means method swizzling is not likely to be a vector of attack. An attacker would have to jailbreak hundreds or thousands of phones to get at only one individual's banking info per device. It would be much easier to just ARP spoof your local coffee shop, SSLStrip a connections and harvest credentials going across the wire. No need to touch a single device and you can get dozens of credentials at a time.

Retail Point of Sale apps are a different story, for example. I have done a penetration test for a client that was planning to use iOS based handheld devices as point of sale terminals. This presents a whole different threat model. First, jailbreaking a single device is likely to expose the card holder data for possibly hundreds of cards per day. Surreptitiously jailbreaking a device, adding the swizzle code and replacing the device without the retailer's knowledge can take mere minutes. This is an attack where the abuse of method swizzling is a real danger (or course, using a card reader that encrypts at the head will defeat this attack, but not all card readers do this).

This is why threat modeling is important. Method swizzling can be mitigated by ensuring any method that handles or processes sensitive data is written in C not Objective C. Objective C is a superset of C and can call C methods without issue, but C methods cannot be swizzled by the Objective C runtime. This might be overkill for the banking app, but makes perfect sense for the retail POS app (especially if the card reader does't encrypt at the head).

Method Swizzling is not a vulnerability, but, like any other reflective language feature, it can be abused. The real issue in iOS mobile development is not that swizzling is possible, but whether the threat model of your application makes it a danger. If it is, write your method in C.

Latest SpiderLabs Blogs

Welcome to Adventures in Cybersecurity: The Defender Series

I’m happy to say I’m done chasing Microsoft certifications (AZ104/AZ500/SC100), and as a result, I’ve had the time to put some effort into a blog series that hopefully will entertain and inform you...

Read More

Trustwave SpiderLabs: Insights and Solutions to Defend Educational Institutions Against Cyber Threats

Security teams responsible for defending educational institutions at higher education and primary school levels often find themselves facing harsh lessons from threat actors who exploit the numerous...

Read More

Breakdown of Tycoon Phishing-as-a-Service System

Just weeks after Trustwave SpiderLabs reported on the Greatness phishing-as-a-service (PaaS) framework, SpiderLabs’ Email Security team is tracking another PaaS called Tycoon Group.

Read More