Last Login: May 27, 2020
todb-r7's Contributions (13)
Here’s a few of links:
Samsung devices are among the most popular Android platforms out there. They last a long, long time, and often quietly go EOL / end of support, and keep on trucking for years. So, for many millions of targets, this is effectively forever-day.
One downside for attackers is that it does seem to require a fair bit of time to exploit — the video demo shows exploitation taking about an hour and a half or so, and it leaves a few hundred unread MMS messages in the queue. This time cost and the attendant lack of stealth means that attacks need to happen specifically when the user isn’t active on the phone — kind of the opposite of “requires user interaction,” but close enough for the ding on scoring, above.
Maybe a middle-of-the-night attack, with a follow-up cleanup, would be enough to avoid detection, but you might need to chain another exploit for a privilege escalation to get you write/delete access to the message queue — the attacker assumes the privileges of Samsung Messages, which is pretty good, but it’s not root,
Update April 24, 2020
Turns out, Apple and HD are both of the opinion that the vulnerability doesn’t exist. See the reporting at Ars:
What’s the lesson here? PoC||GTFO, and let the vendors do their jobs as part of coordinated vulnerability disclosure. Updating the high-value/low-value indicators here.
Original Report Below
It technically “requires user interaction” but that interaction is merely opening a malicious email. It doesn’t sound like you need to click on anything.
According to the report, Apple has confirmed the existence, but we haven’t seen a patch or a CVE or anything like that.
This is super-duper high value, IMO. Million dollar bug. Own any-ish iPhone, assuming they’re using Mail.app, which most are (there are 3rd party email applications, like Gmail and Yahoo! Mail, but they are somewhat rare in the iPhone / iPad ecosystem).
Just to drop in my panicky two cents: Exchange Administrators are historically hesitant to patch Exchange without extensive planning and often physical presence to reboot / restore if needed. Exchange patching isn’t usually just a matter of patch, reboot, move on with your life — many sites need to deprovision an Exchange server to fail over, then again to do it the other way. Even when everything goes well, sometimes the patch doesn’t actually apply, which means administrators either don’t notice, or actively check and test (which means more time).
So, in short, there’s a trust gap for this particular patch, and I believe that’s what we see reflected in the low patch numbers. Even if the patch is easy and clean and works great, an experienced Exchange admin isn’t going to trust it.
First, note that this vuln is in RDP Gateway, not RDP Server, and those are different things. RDGateway is less common than plain ol’ RDP Server, but my guess is that it is designed to be deployed right smack on the internet, where we tend to advise people against deploying RDP Server on the internet (people do anyway, but thats-none-of-my-business.jpg).
Anyway, because it’s RD Gateway, the maintainers of such servers probably are already aware that they need to keep up on their patches in the same way a typical IIS administrator does, so I’m not super worried about this bug — but it all depends on timely patches. Getting root on an RD Gateway server would be super useful for all sorts of internet crime, and this is an ideal sort of vulnerability for just that — pre-auth, on first connection.
This is a vuln in the way crypt32.dll on recent builds of Windows validates ECC certificates. Yes, it’s bad for cryptography. But, an attacker has to be in a position already to get you to either a) run an exe they give you (and then pass the cert check for a trusted publisher), or b) MITM your HTTPS connection (somehow) so their fake website looks like the real website. So… this kinda bugs me that it’s being called “RCE.” It’s not in any useful sense of the term. It’s an identity spoofing bug.