Archive for July 30, 2019

Tuesday, July 30, 2019

Updated Hardened Runtime Documentation

Rosyna Keller:

The updated Hardened Runtime docs are out!

The overview includes more information on how to enable it in Xcode and explains that the hardened runtime is designed to stop certain classes of exploits.

If your app absolutely needs to have an exploit class remain available, use a specific, unrestricted hardened runtime entitlement.

Each entitlement doc now includes real-world examples of why you may need an exploit class to remain open and lists ways you can avoid doing so.

For example, the three unsigned memory entitlements go from green (implied, do this) to red (never do this)

[…]

I’m really, really proud of the🚦 docs as they were written based on direct feedback from third-party developers.

Jordan Pittman:

I find it rather interesting that the use of DVDPlayback.framework requires the “Allow Unsigned Executable Memory” entitlement.

Previously:

Debugging the Responder Chain

Jeff Nadeau:

Maybe this will make it easier to see what’s up w/ the responder chain. Pause in the debugger and run

(lldb) e -- (void)[[[NSClassFromString(@"NSDebugMenuResponderChainProvider") alloc] init] toggleResponderChainPanel:nil]

and then continue. (I reserve the right to break this.)

Andy Lee:

I usually add my own method to the app delegate that prints the responder chain, starting with the current first responder. Often I add a temporary menu item that calls that method, and assign it a keyboard shortcut.

And here’s a link to the responder chain documentation, since it’s now in the archive and not easy to find simply by following links. (You’d think it would be linked from the NSResponder page).

Update (2019-08-01): Friedrich Markgraf:

If you need to figure out on which instance in the responder chain an action method (like scrollWheel:) is actually called, you can use a logging symbolic breakpoint like this[…]

Capital One Breach

Joseph Cox and Lorenzo Franceschi-Bicchierai:

The major US bank Capital One disclosed a major data breach on Monday evening, revealing that an individual accessed the personal data of 100 million people in the United States and around 6 million in Canada.

The FBI has already arrested and indicted Paige Thompson, who worked as a software engineer in Seattle, for allegedly hacking Capital One and posting the data to her GitHub account.

[…]

“A firewall misconfiguration permitted commands to reach and be executed by that server, which enabled access to folders or buckets of data in Capital One's storage space at the Cloud Computing Company,” the complaint reads, without explicitly naming the company. The charging documents, however, mention that the stolen data was stored in “S3,” short for a popular piece of Amazon Web Services software. It adds that the file contained code for three commands, indicating the simple process Thompson may have taken to allegedly download the data.

Nick Heer:

Only in an era of gigantic security breaches can the disclosure of over a hundred thousand Social Security Numbers and tens of thousands of bank account numbers be rounded down to none.

Previously:

Update (2019-08-05): Brian Krebs:

What follows is based on interviews with almost a dozen security experts, including one who is privy to details about the ongoing breach investigation. Because this incident deals with somewhat jargon-laced and esoteric concepts, much of what is described below has been dramatically simplified. Anyone seeking a more technical explanation of the basic concepts referenced here should explore some of the many links included in this story.

SwiftOnSecurity:

My coworker doing analysis of this CapitalOne breach has just been absolutely floored by the layers of issues it demonstrates. It’s truly shocking to an experienced security person. I’ll admit my heart has grown dark and I haven’t had the will to fully dive into it.

Teri Radichel:

Anyone who scoffs at Capital One or other large companies trying to secure organizations with multiple lines of businesses and 10,000+ developers better be careful because you might be next. Still.

[…]

What would have been a better solution for Capital One? I don’t know all the details, so this may or may not have solved the problem, but the WAF should never have access to the S3 bucket in a good architectural design, except write-only access to a single bucket to write log files potentially. The WAF is an Internet-facing system and should never have access to any data. In a three-tier architecture, the WAF would interact with a web tier. The web tier interacts with an application tier. The application tier interacts with the data.