Our first story this week comes courtesy of the Pwn2own contest. For anyone not familiar with it, this event is held twice a year, and features live demonstrations of exploits against up-to-date software. The one exception to this is when a researcher does a coordinated release with the vendor, and the update containing the fix drops just before the event. This time, the event was held virtually, and the attempts are all available on Youtube. There were 23 attacks attempted, and only two were outright failures. There were 5 partial successes and 16 full successes.

One of the interesting demonstrations was a zero-click RCE against Zoom. This was a trio of vulnerabilities chained into a single attack. The only caveat is that the attack must come from an accepted contact. Pwn2Own gives each exploit attempt twenty minutes total, and up to three attempts, each of which can last up to five minutes. Most complex exploits have an element of randomness, and exploits known to work sometimes don’t work every time. The Zoom demonstration didn’t work the first time, and the demonstration team took enough time to reset, they only had enough time for one more try.

We first covered BleedingTooth almost exactly six months ago. The details were sparse then, but enough time has gone by to get the full report. BleedingTooth is actually a trio of vulnerabilities, discovered by [Andy Nguyen]. The first is BadVibes, CVE-2020-24490. It’s a lack of a length check in the handling of incoming Bluetooth advertisement packets. This leads to a buffer overflow. The catch here is that the vulnerability is only possible over Bluetooth 5.

The next of the trio of bugs is CVE-2020-12352, AKA BadChoice. It appears to be a logic error, where an obscure code path assembles a Bluetooth error packet that includes uninitialized memory. This information leak is important for using the other bugs to build a true exploit. The last vulnerability is BadKarma, CVE-2020-12351. This one is a simple type confusion.

The catch here is that the type confusion bug has a tendency to panic the kernel before the exploits can trigger. It seems like a problem, but in fact, an attacker can simply request a change in channel mode to avoid the crash. The three bugs together allow an attacker to write a payload to memory, leak enough information to overcome kernel randomization, and then finally re-use another function as an jumping point to get code execution. Check out the link for the hairy details.

A handful of Cisco routers have a serious problem, a CVSS score of 9.8. CVE-2021-1459 is a remote code execution in the web interface of the routers. The bug is pre-authentication, and since the routers are normally used as VPN endpoints, most of the installs are probably vulnerable. The real kicker? The routers are past their end-of-support date. The official word is that there are no updates, and no workarounds. So maybe go poke around in your office’s network closet, and look for a RV110W, RV130, RV130W, or RV215W. Find one, and send the Cisco advisory over to whoever handles IT or security. If that’s you, then it’s time to buy a new router.

Remember the Facebook leak that went public last week? Clubhouse seems to have the same problem now. A public API exposes a bunch of information that is somewhere between public and private. Rather than implement a technical limit on API scraping, Clubhouse simply included a line in the TOS about data scraping. As should be obvious, the Terms of Service don’t stop anyone from grabbing data, and a database of 1.3 million users is now available online.

Source Engine Games on Steam have a problem. It’s possible to send a malicious invite, that once accepted, leads to code execution.

The strange bit about this vulnerability is how old it is. First reported June 5 of 2019, the bug is a vanilla buffer overflow, and considered a 9.0 severity. As of April 12, 2021, the bug still works in CS:GO. Now imagine a worm that sends malicious invites to all your friends. Yep, it’s a wormable flaw in the most widely installed video game launcher in the world, unpatched for nearly two years.

Every once in a while, we cover some really bad behavior from big companies. When a researcher finds a vulnerability and reports it privately, rather than doing an anonymous dump online or selling on a forum, it’s nice to get a “thank you”, or even better, a bug bounty. Sometimes though, researchers get hit with a threat of legal action instead. This has the predictable effect of ticking the entire community off, putting the guilty parties on a metaphorical “bad list”. A recent effort has turned this into a literal list. Know of similar bad behavior that hasn’t made the list? Go make a pull request.

An odd combination of quirks in the Android OS and the WhatsApp application were leveraged to create a new malicious worm. The application in question was FlixOnline, an obvious attempt to look like the official Netflix app. The app requested overlay and notification permissions. The ability to interact with notifications gives an application a broad reach into everything, now that in-notification replies are a ubiquitous feature. To add insult to that injury, the overlay permission was used to make uninstalling the app next to impossible for the average user. It spread through auto-responding to incoming messages with a spam message and a link to install from the play store. Thankfully Check Point Research caught the app before it was widely installed, and Google has de-listed it from the store. It was a clever-yet-infuriating collection of tactics, and a reminder that a bit of paranoia is warranted regarding what permissions you give to an app.

The news broke on the 13th that the FBI had begun taking an unprecedented action in response to the widespread MS Exchange attacks. Armed with a court order, the FBI began using the vulnerability to break in to compromised servers, and remove a particular strain of remote access malware. Notably, this action didn’t include installing the patch to fix those servers, so many of them may be re-infected in short order.

This action is rather stunning to many, particularly because there doesn’t seem to be any legal justification for modifying the contents of private computers en masse. I’ve seen arguments both for and against the aggressive action. Let us know your thoughts on this potentially controversial decision.

Source: Hackaday

Powered by NewsAPI.org