Twitter just had their biggest security breach in years. Mike warned us about it on Wednesday, but it’s worth revisiting a few of the details. The story is still developing, but it appears that malicious actors used social engineering to access an internal Twitter dashboard. This dashboard, among other interesting things, allows directly changing the email address associated with an account. Once the address is changed to the attacker’s, it’s simple to do a password reset and gain access.
The bitcoin address used in the crypto scam ended up receiving nearly $120,000 USD worth of bitcoin, all of which has been shuffled off into different accounts. It’s an old and simple scam, but was apparently rather believable because the messages were posted by verified Twitter accounts.
A series of screenshots have been posted, claiming to be the internal Twitter dashboard used in the attack. More than a few eyebrows have been raised, as a result of that dashboard. First off, the fact that Twitter employees can directly change an account’s email address is asking for trouble. Even more interesting are the tags that can be added to an account. “Trends Blacklist” and “Search Blacklist” do call to mind the rumors of shadow-banning, but at this point it’s impossible to know the details. Motherboard is reporting that Twitter is removing that screenshot across the board when it’s posted, and even suspending accounts that post it. Of course, they’d do that if it were faked as well, so who knows?
We detected what we believe to be a coordinated social engineering attack by people who successfully targeted some of our employees with access to internal systems and tools.
— Twitter Support (@TwitterSupport) July 16, 2020
SIGRed
CVE-2020-1350 was just announced and fixed as a part of Microsoft’s patch Tuesday push. If you run a Windows Server machine, especially if it has a DNS resolver running, make sure to go patch right away. Yet another CVE scoring a perfect 10, this one is particularly bad as it appears to be a wormable exploit.
Some of the vulnerability details are already available — enough to get an idea of what’s going on. The flaw is in how the DNS daemon handles DNS SIG responses. The code that allocates a buffer for the sig response uses a 16 bit int for the allocation size. It maxes out at 64k characters. As UDP DNS responses have an enforced size limit of 4096 bytes, this seems safe. As you might guess, there’s a catch.
Certain legitimate DNS responses do in fact require more than 4096 bytes, so the spec includes the truncation flag, which means that there is more to this message that didn’t fit in the UDP packet. The proper response is to initiate a TCP connection and make the request again. Once the DNS request is happening over TCP, that message can be up to 64k in length. Still not long enough to trigger the bug. Enter DNS pointer compression. DNS responses can contain a simple type of data compression, usually used to squeeze a message into a single UDP packet. If this compression is used on a TCP DNS query, the final decompressed message size can exceed 64k.
Once the message is decompressed, a buffer is allocated, based on the message size, but because it’s a 16-bit int, if the size is over 64k, that value wraps back around to 0. So a small buffer is allocated, and then 64+ kB of data is copied to it, overwriting the end of the buffer. Because of the security features built into modern versions of Windows Server, there are more steps to a full compromise, but based on the response to this vulnerability, it seems that a sophisticated attacker won’t have too much trouble developing it into a full exploit.
SAP RECON
The third major event of this week is the RECON vulnerability in SAP devices, accompanied by a not very helpful PDF. CVE-2020-6287 scored a severity of 10, as it’s exploitable from the network with no authentication, and easily leads to a full takeover of the system. The flaw is twofold, first is yet another path transversal attack. The “../” operator isn’t properly stripped out of incoming requests. The other half of the vulnerability is the fact that certain URL endpoints on a vulnerable device are accessible without authentication.
A Proof of Concept has been posted to Github, though without the RCE elements. It’s likely that the specifics needed to fully compromise the device will be figured out in short order, so best to get your devices updated right away.
Apple Security Bypass
MacOS has a built in app sandboxing system, known as TCC. The aim of this particular component is to keep an app from accessing the rest of the filesystem without user permission. [Jeff Johnson] discovered a way to bypass that protection, and reported it to Apple, who have yet to fix it. After waiting six months, double the standard disclosure time, he’s published his findings for all to see.
Android Security Updates
The July security updates for Android have been released, and there are a couple of interesting vulns in there, namely CVE-2020-0224 and CVE-2020-0225.
0224 seems to be related to the processing of regular expressions. Based on the limited bug writeup, it’s unclear how this vulnerability would be triggered remotely. This bug is a bit of an older one, first discovered in the Chromium project. Because of the code sharing between projects, it was present in both, and only now getting patched in Android.
0225 is a Bluetooth issue, related to audio over Bluetooth. The details are scarce, but it appears that a 0-length packet can trigger a null pointer access.
The 4 Hour Unc0ver Uncovering
And lastly for this week, [Brandon Azad] at Google’s Project Zero steps us through the story of taking apart the unc0ver jailbreak, designing a PoC, and sending the issue over to Apple. In the case of a big release like that one, there’s something of a race to see who can reverse engineer it first. Brandon couldn’t make heads or tails out of the heavily obfuscated exploit binary, but he had a clever trick up his sleeve. Start the exploit, but kill that app before the install finished. The system was left in an unstable state, crashed, and he was able to trace the crash back to the vulnerability. The full write-up is worth checking out.
No comments:
Post a Comment