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.
BleedingTooth
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.
Cisco Hardware Out of Support
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.
Clubhouse Leaks
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 Vulnerability
Source Engine Games on Steam have a problem. It’s possible to send a malicious invite, that once accepted, leads to code execution.
Two years ago, secret club member @floesen_ reported a remote code execution flaw affecting all source engine games. It can be triggered through a Steam invite. This has yet to be patched, and Valve is preventing us from publicly disclosing it. pic.twitter.com/0FWRvEVuUX
— secret club (@the_secret_club) April 10, 2021
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.
The Bad List
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.
Android Worm
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 FBI Probably Breaks the Law
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.
Suppose that I owned a home, and it caught fire. If someone “trespassed” by running across the lawn to extinguish the fire, I wouldn’t be mad. That’s how I see the FBI’s actions. As long as they don’t stick around afterwards to snoop or install spyware, I don’t have any objections.
Yeah, but in this case they’d blow a fire extinguisher on it and walk away, leaving the electrical fault that started the fire untouched…
Re:FBI
What I’m reading is that 60,000 exchange servers were either vulnerable or compromised by the original attack. Microsoft eventually released a patch that fixed the vulnerabilities, but compromised machines needed the owner to take action to remove the infection. Microsoft released tools to scan for the exploit, but the FBI got a court order to remove infections.
What I’m not seeing is how the FBI knew there were hundreds of servers still infected. Did they scan all 60,000+ servers? I’m also not seeing how they ran web shell scripts against those machines? Did Microsoft give them a backdoor? Supposedly it was too hard for server owners to find out if they were affected but it was easy for the FBI to backdoor/crack into these privately owned servers, find the infection and remove it?
Regardless of this being helpful, the box is now open and we’re sliding down the slope. The US government has been looking for an excuse to set the precedent for the public to accept government backdoors and/or system cracking. I would have thought they’d wait for a bigger issue than a few hundred sysadmins not running a system scan?
What am I missing?
“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.”
Didn’t one white hat end up doing this?
Yes. On principle, I’m less worried about an individual bending or breaking the rules to do something good. Also, I don’t know that a white hat has ever done something similar openly. It’s usually anonymous.
So if that exact same action was taken by another country, lets say that this action was taken by the Investigative Committee of Russia (Russia’s equivalent of the FBI) ?
Or even the Federal Security Service (formerly the KGB, probably the US equivalent would be the DHS, but without people vanishing from the street and being imprisoned, as often).
Or China’s MSS (Ministry of State Security), would be the equivalent of … well lets say that the FBI and the CIA has a baby that would be the MSS.
What an unholy union that would be. Yikes.
I thought they named their baby Dee Aich Ess.
Actually, it may have been twins, you are familiar with Tee Essay?
Anyway, inre: The Bad List;
Some of the companies have revoked their actions and allowed the info to be published.
Even though their initial action was bad, taking steps back should (IMHO) move them to a “Dishonorable Mention” list.