todb-r7 (23)
Last Login: December 13, 2022
todb-r7's Latest (13) Contributions
Technical Analysis
The key feature of this bug in @agalauner-r7’s assessment here is, “Don’t let anybody disassemble your machine.” I’m calling this issue “authenticated” because if you’re in a position to turn some screws on the case, you’re practically authenticated. :)
Technical Analysis
Here’s a few of links:
https://twitter.com/j00ru/status/1258066559765004295
https://bugs.chromium.org/p/project-zero/issues/detail?id=2002
https://security.samsungmobile.com/securityUpdate.smsb
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,
Note, Apple is refuting the bug.
Updated my original assessment due to the lies.
Final reply for now: There is also no evidence verified outside of the claims made by https://twitter.com/zecops . It’s unclear if Reuters could verify the bug.
Also, there are a /lot/ of unknowns about this, like “Easy to exploit,” who knows? All we know is 1) A researcher rediscovered this after analyzing in-the-wild attacks, and 2) there are in-the-wild attacks.
Technical Analysis
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).
Technical Analysis
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.
Technical Analysis
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.
W74Life
All I’m complaining about is that it’s /not/ RCE. It’s certificate — and therefore, identity — spoofing. It doesn’t seem to me that being able to sign a binary with a trusted cert is “remote code execution,” it’s faking the source of the binary, /in order/ for you to run the executable yourself.
Now, there can be an attack involved that a) fakes the identity of an update service on the internet that b) delivers a fake update binary that c) is run automatically…. but that’s two different certs you’re forging in order to get the desired results, and neither attack feels like “RCE” to me.
I dunno. It’s a big(gish) deal (for APT sorts who can pull off that kind of attack), but it’s not RCE in the way we usually think about RCE bugs.
Technical Analysis
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.
One mitigation strategy here is to either turn off your phone, or switch to Airplane Mode (without WiFi), if you know you’re not going to be paying attention to it for a while. At least, until your carrier releases the Samsung patch to you.
On the bright(?) side: this is a bug that is nearly perfect for law enforcement that has a phone in custody and no other way to access stored photos and messages given a warrant to do so.