Remember the end of GandCrab we talked about a couple weeks back? A new wrinkle to this story is the news that a coalition of law enforcement agencies and security researchers have released a decrypter and the master decryption keys for that ransomware. It’s theorized that researchers were able to breach the command and control servers where the master keys were stored. It’s yet to be known whether this breach was the cause for the retirement, or was a result of it.
Apple’s Secure Enclave is Broken?
A Youtube video and Reddit thread show a way to bypass the iPhone’s TouchID and FaceID, allowing anyone to access the list of saved passwords. The technique for breaking into that data? Tap the menu option repeatedly, and cancel the security prompts. Given enough rapid tries, the OS gives up on the validation and simply shows the passwords!
The iPhone has an onboard security chip, the Secure Enclave, that is designed to make this sort of problem nearly impossible. The design specification dictates that data like passwords are encrypted, and the only way to decrypt is to use the Enclave. The purpose is to mitigate the impact of programming bugs like this one. It seems that the issue is limited to the iOS 13 Beta releases, and you’d expect bugs in beta, but a bug like this casts some doubt on the effectiveness of Apple’s Security Enclave.
URL Scheme Hijacking
Our next topic is also iOS related, though it’s possible the same issue could effect Android phones: URL scheme problems. The researchers at Trend Micro took a look at how iOS handles conflicting app URLs. Outside of the normal http: and https: URLs, applications can register custom URL schemes in order to simplify inter-process communication. The simplest example is something like an email address and the mailto: scheme. Even on a desktop, using one of these links will open a different application to handle that request. What could go wrong?
One weakness in using URL schemes like this is that not all apps properly validate what launched the request, and iOS allows multiple apps to use the same URL scheme. In the example given, a malicious app could register the same URL handler as the target, and effectively launch a man-in-the-middle attack.
Bluekeep, and Patching Systems
It has been five weeks since Bluekeep, the Remote Desktop Protocol vulnerability, was revealed. Approximately 20% of the vulnerable systems exposed to the internet have been patched. Bitsight has been running scans of the remaining vulnerable machines, and estimates about 800,000 remaining vulnerable systems. You may remember this particularl vulnerability was considered so problematic that even the NSA released a statement encouraging patching. So far, there hasn’t been a worm targeting the vulnerability, but it’s assumed that at least some actors have been using this vulnerability in attacks.
So the classical “click it until it gives up” trick works for something that is intended to be far more hardware based? Now I wonder how Apple has actually implemented their system….
The URL feature thing seems like an oversight… Generally, packing more functionality into something can at a lot of times also drag in security risks. Though, not being an especially much of a “power user” myself, I almost doesn’t understand what this feature is even supposed to really be useful for…
And in regards to patching security flaws in systems, turns out a lot of users simply don’t care, or know, or mind about fixing security issues in their system. Not really that much of a surprise.
I haven’t patched the Win7 partition of my laptop or PC, mostly because I haven’t booted them to Windows since the patch came out.
Yes, but you also don’t have it running and online with the RDP port exposed to the internet, so you’re not counted here. This is the count of live systems that are online.
Once you start automating things by simulating mouse clicks and key presses, you’ll find that a lot of software (looking at you adsk) quickly and consistently turns into a large fireball when simply clicking on something 0.1 second after it pops up, proving completely unhanded (or mishandled) scheduling situations in the interface.
Knock knock
Race condition
Who’s there?
Lol, I see what you did there!
One of the most annoying things Apple does with security is not allowing iPads and iPhones to be wiped and reactivated if they’re connected to Find My Device – but NOT reported lost or stolen. You inherited Grandma’s iPad but she took her password to the grave? Sucks to be you. Apple won’t unlock it for you. You can update iOS and wipe it, but it will still be locked. There are DNS hacks that will allow them to be used as a web tablet but you don’t get access to apps or the app store, and then there’s the sketchiness of a DNS located who knows where.
What Apple ought to do is allow a found or used iDevice to be brought to an Apple Store where they’d check to see if it’s reported lost or stolen. If not, attempt to contact the last registered owner to see if they want it back. If they don’t, wipe and unlock it and hand it back to the person that brought it in. But they’ll never do that because the “green” company wants as many of their old devices taken out of use as possible so they can sell more new ones. Apple say they’ll take old devices back for recycling, but they don’t go to any great effort to advertise that. Further tarnishing their “green” propaganda is how so many of their devices are sealed shut so that it cost more in labor to carefully take them apart to salvage components than the components are worth. Even to rip them apart destructively to remove the batteries for safe shredding costs more in labor than the recoverable materials are worth.
Meanwhile a Chromebook can be “power washed” simply by booting it, pressing the right 4 keys, then clicking the power wash button. In a couple of minutes you have a usable Chromebook. Also, many Chromebooks can run regular Android apps, with support being added to more Chrome devices each year.
If you have the receipt from when you purchased it you can ask Apple to remove the iCloud lock iirc.
As for the “found iDevice”, that doesn’t make any sense. That’s the point of activation locks. If the owner doesn’t want it anymore when contacted, he/she can unlock it themselves remotely.
As for the sealed shut device, iPhones are relatively easy to open compared to the sealed android counterparts so that really isn’t a point. It’s literally 2 screws, a suction cup, and a spudger. I don’t know how you’d need to take them apart “destructively” to get in.
I was going to say I’ve not bought an apple product for more than two decades, but upon further thought, I don’t think I’ve EVER bought an apple product. Since that company came into existance oh so long ago, they have not released a single product (or given any incentive) to convince me otherwise.
Products that are overpriced, short lived and a bi*ch to maintain if you do want them to last a few weeks more than the warranty.
No thanks.
This data comes from TZ0 where SEPOS runs and provides IOS a key service through the mailbox interface(basically like the TPM on your x86 box except it’s on SOC die with the AP itself). It’s just AP kernel interface grabbing data SEP isn’t defeated.. Not to be confused with the kernel monitoring done from TZ1.
Apple SEP has been dumped and defeated for years privately along with every protection in IOS and the kernel protection in TZ1..
By the way silicon and clock hardening is the only difference that matters between an A7 and A12. All defeated privately by multiple governments and researchers and bounty programs..
Keep up the interesting security articles.