First off, Apple has issued an update for some very old devices. Well, vintage 2013, but that’s a long time in cell-phone years. Fixed are a trio of vulnerabilities, two of which are reported to be exploited in the wild. CVE-2021-30761 and CVE-2021-30762 are both flaws in Webkit, allowing for arbitrary code execution upon visiting a malicious website.
The third bug fixed is a very interesting one, CVE-2021-30737, memory corruption in the ASN.1 decoder. ASN.1 is a serialization format, used in a bunch of different crypto and telecom protocols, like the PKCS key exchange protocols. This bug was reported by [xerub], who showed off an attack against locked iPhone immediately after boot. Need to break into an old iPhone? Looks like there’s an exploit for that now. Continue reading “This Week In Security: Updates, Leaks, Hacking Old Hardware, And Making New”→
It’s a way to Man-In-the-Middle an HTTPS connection, without actually needing to break the encryption. There are two primary observations at the core of the attack. First, multiple subdomains will often share the same TLS certificate. Secondly, TLS is regularly used to protect more than just HTTPS. So what happens if an HTTPS request is redirected to an SFTP server run by the same company? The TLS handshake will complete successfully, but the data returned by the server is not at all what the browser expected.
The specific details are a little light on this one, but the authors identified three broad categories of attack. The first is an upload attack, where the attacker has privileges to upload files to an FTPS server. From what I can tell, an attacker initiates an FTP upload over SSL, using the control port, and then redirects the victim’s connection to the data port on that server. The entirety of the HTML request is then saved, decrypted, on the FTPS server. This request could contain session cookies and other secrets.
The second identified attack is the opposite, the attacker uploads a malicious file, initiates a download, and then redirects a browser’s request to the FTPS data port. The malicious file is grabbed and the browser may interpret it as code to be run. The third is a reflection technique. This one’s a bit different. Essentially the attacker sends a request for DoBadThings();, and then connects the victim browser to the data port. The response is sent, Cannot find file: DoBadThings();and the browser might just execute the script fragment. This isn’t one of those attacks that are going to be applicable to just every server, but in just the right setup, it could lead to problems.
VMWare Flaw Exploited
There is a serious VMWare flaw under active exploit right now. It’s apparently in the VMware vCenter control program, and exploiting it is as simple as six curl commands. The flaw is pre-authentication and only requires access to HTTPS port 443. At least one researcher has already seen his VMware honeypot attacked and observed the web-shell the attacker installed. This one looks like a big deal, so make sure you’re up-to-date if you run VMware.
That Time the FBI Ran a Darknet
AN0M was a popular encrypted communication tool for the underworld, really a network consisting of locked down mobile devices with a specialized app running on them. The reality was a bit different, though, the tool was actually being run as Operation Ironside, a join operation by the FBI and the Australian Federal Police (AFP). The story is a weird one, and really raises some legal and ethical questions, so buckle up.
First off, things got started back in 2018 when Phantom Secure CEO Vincent Ramos was prosecuted for RICO charges, related to his company’s work on secure phones. They specialized in taking Blackberry phones, yanking out all the IO hardware, like camera, microphone, and even GPS chips, and then installing encrypted communication apps. In short, very similar to AN0M. Phantom Secure was walking a very thin line between being a legitimate provider of secure hardware, and actively supporting criminal enterprise. When Ramos told an undercover FBI agent that his phones were specifically for drug smuggling, it became obvious that he had strayed far onto the wrong side of the law. He and many in the company were charged for related crimes.
One employee already had drug charges on his record, and agreed to cooperate with the FBI in exchange for avoiding further charges. That developer had already been developing his own device, which he called AN0M. The deal he cut with the feds was to turn over his work for immunity. A scheme was hatched, apparently over beers between agents, to complete the development of AN0M and distribute the devices, but to include a complete back door for law enforcement. This is actually very similar to what was done with Crypto AG, under Project Rubicon.
The turned developer distributed the devices to his contacts, and law enforcement agencies around the world got involved, quietly helping to make them popular. The devices served their purpose of providing messaging to all recipients. It just wasn’t known at the time that law enforcement agents were BCC’d on every message. It’s not clear what triggered the raids and announcements, but this was definitely a coordinated action.
There is a lingering question, however. Namely, do law enforcement really have the legal authority to develop and distribute a malicious device and application? Did a warrant actually cover this? Can it? There is sure to be much consternation over such questions in the months to come. Just imagine that WhatsApp is eventually revealed to be an app secretly developed by the Chinese government, then how would you feel about it?
Ransomware and Bitcoin Seizure
And in another major victory for the FBI, The majority of the funds paid by the Colonial pipeline have been recovered. It’s not entirely known how the recovery happened, but you can read the FBI Affidavit that describes the path the Bitcoins took. There’s a strange little statment at the end of that document. “The private key for the Subject Address is in the possession of the FBI in the Northern District of California.” One has to wonder a couple of things. First, how was the FBI able to track those bitcoins? And second, just how did they happen to end up in a wallet that they knew the key for? Could The AN0M story be related?
The private key for the Subject Address is in the possession of the FBI in the Northern District of California
Now here’s another angle to this. Colonial was given the choice, to pay in Bitcoin or Ethereum, and they chose Bitcoin, even though there was a 10% extra fee for that currency. They had their networks mostly back up, and they knew the decryptor wouldn’t be very helpful. They were working with law enforcement, and they still paid. This raises the very real possibility that the payment was made specifically to trace the Bitcoin transactions.
Next, remember how proud JBS was of their incident response? Now we find out that they did indeed pay an $11 million ransom. However, that was in cooperation with federal officials, and was not necessary to recover files. Oh, and paid in Bitcoin. Sound familiar? At this point, it’s a fair guess that the FBI or another agency helping them has an angle on tracing Bitcoin transactions. AN0M is one possibility. Another is that the FBI is running a “mixer”, essentially a Bitcoin money laundering service. (Shoutout to @MalwareJake for that idea.) Regardless, there seems to be a more serious stance taken towards ransomware as a result of the high profile hacks of the last few weeks.
Rocket.Chat Goes Boom
Running a Rocket.Chat instance? Go update it! This popular Open Source messaging platform uses a NoSQL backend for managing users. If you thought getting rid of SQL means you don’t have injection vulnerabilities, think again.
The MongoDB database backend passes requests and data in a JSON-like format. The first attack is to stuff a regex pattern into that JSON, and leak the password hash one character at a time. The second vulnerability uses the $where operator in MongoDB in a clever way. Rather than try to leak information directly, they used error messages to get information out. Put both together, and you can go from simply knowing a user’s email address to a shell on the hosting server in seconds. All in all, it’s an impressive hack, and the video demonstration of it is worth the watch:
Agent Smith Takes Over The Matrix
Include Security found an interesting bug in the Unity engine, where a malicious game object can run arbitrary code on the machine running the engine. It’s the sort of thing that game designers don’t think too much about until it’s a problem. I couldn’t help but think of VR Chat, a multiplayer experience that allows players to upload their own avatars. It’s built in Unity, and uses game objects for those avatars. I haven’t been able to confirm whether it has this vulnerability one way or another, but I’m very much reminded of Agent Smith copying himself onto all the other citizens of the matrix. If VR Chat does indeed have this problem, it would be rather trivial to build an avatar worm to do the same thing. Life imitates art.
Don’t Use a Password Manager?
And finally, one of the hallowed bits of cybersecurity wisdom gets challenged by [Tavis Ormandy] of Google project Zero fame. His take? Don’t use a password manager! Well, actually, it’s that you shouldn’t use a password manager that is a browser extension, because websites can actually interact with the hooks that make them work. There’s more to his argument, and his conclusion is simple. Use the password manager built into Google Chrome. Or Firefox, if that’s what you use. His argument is rather compelling, that many of them aren’t as secure as they claim to be.
Cryptologist [Lambros Callimahos] was a victim of his own success. He wrote a trilogy of books called Military Cryptanalytics covering code breaking in 1977. The first two volumes were eventually published, but the NSA blocked the public release of the third volume back in 1992. But last December, it finally saw the light of day.
Of course, some parts of the book are redacted, including parts of the table of contents. That’s pretty bad when even your chapter headings can be classified. [Richard Bean] over on Phys.org has some notes about the book along with some examples of hard-to-solve crypto puzzles.
We occasionally make fun of new security vulnerabilities that have a catchy name and shiny website. We’re breaking new ground here, though, in covering a shiny website that makes fun of itself. So first off, this is a real vulnerability in Apple’s brand-new M1 chip. It’s got CVE-2021-30747, and in some very limited cases, it could be used for something malicious. The full name is M1ssing Register Access Controls Leak EL0 State, or M1RACLES. To translate that trying-too-hard-to-be-clever name to English, a CPU register is left open to read/write access from unprivileged userspace. It happens to be a two-bit register that doesn’t have a documented purpose, so it’s perfect for smuggling data between processes.
Do note that this is an undocumented register. If it turns out that it actually does something important, this vulnerability could get more serious in a hurry. Until then, thinking of it as a two-bit vulnerability seems accurate. For now, however, the most we have to worry about is that two processes can use this to pass information back and forth. This isn’t like Spectre or Rowhammer where one process is reading or writing to an unrelated process, but both of them have to be in on the game.
The discoverer, [Hector Martin], points out one example where this could actually be abused: to bypass permissions on iOS devices. It’s a clever scenario. Third party keyboards have always been just a little worrying, because they run code that can see everything you type, passwords included. The long-standing advice has been to never use such a keyboard, if it asks for network access permissions. Apple has made this advice into a platform rule — no iOS keyboards get network access. What if a device had a second malicious app installed, that did have Internet access permissions? With a covert data channel, the keyboard could shuffle keystrokes off to its sister app, and get your secrets off the device.
So how much should you care about CVE-2021-30747? Probably not much. The shiny site is really a social experiment to see how many of us would write up the vulnerability without being in on the joke. Why go to the hassle? Apparently it was all an excuse to make this video, featuring the appropriate Bad Apple!! music video.
Half-Double’ing Down on Rowhammer
A few days ago, Google announced the details of Half-Double, and the glass is definitely Half-Double full with all the silly puns that come to mind. The concept is simple: If Rowhammer works because individual rows of ram are so physically close together, does further miniaturization enable attacks against bits two rows away? The answer is a qualified yes.
Quick refresher, Rowhammer is an attack first demonstrated against DDR3 back in 2014, where rapid access to one row of memory can cause bit-flip errors in the neighboring row. Since then, there have been efforts by chip manufacturers to harden against Rowhammer, including detection techniques. At the same time, researchers have kept advancing the art through techniques like Double-Sided Rowhammer, randomizing the order of reads, and attempts to synchronize the attack with the ram’s refresh intervals. Half-Double is yet another way to overcome the protections built into modern ram chips.
We start by specifying a particular ram row as the victim (V). The row right beside it will be the near aggressor row (N), and the next row over we call the far aggressor row (F). A normal Rowhammer attack would simply alternate between reading from the near aggressor and a far-off decoy, rapidly toggling the row select line, which degrades the physical charge in neighboring bits. The Half-Double attack instead alternates between the far aggressor and a decoy row for 1000 cycles, and then reads from the near aggressor once. This process is repeated until the victim row has a bit flip, which often happens within a few dozen iterations. Because the hammering isn’t right beside the victim row, the built-in detection applies mitigations to the wrong row, allowing the attack to succeed in spite of the mitigations.
More Vulnerable Windows Servers
We talked about CVE-2021-31166 two weeks ago, a wormable flaw in Windows’ http.sys driver. [Jim DeVries] started wondering something as soon as he heard about the CVE. Was Windows Remote Management, running on port 5985, also vulnerable? Nobody seemed to know, so he took matters into hiis own hands, and confirmed that yes, WinRM is also vulnerable to this flaw. From what I can tell, this is installed and enabled by default on every modern Windows server.
I finally found time to answer my own question. WinRM *IS* vulnerable. This really expands the number of vulnerable systems, although no one would intentionally put that service on the internet.
And far from his optimistic assertion that surely no-one would expose that to the Internet… It’s estimated that there over 2 million IPs doing just that.
More Ransomware
On the ransomware front, there is an interesting story out of The Republic of Ireland. The health system there was hit by Conti ransomware, and the price for decryption set at the equivalent of $20 million. It came as a surprise, then, when a decryptor was freely published. There seems to be an ongoing theme in ransomware, that the larger groups are trying to manage how much attention they draw. On the other hand, this ransomware attack includes a threat to release private information, and the Conti group is still trying to extort money to prevent it. It’s an odd situation, to be sure.
Inside Baseball for Security News
I found a series of stories and tweets rather interesting, starting with the May Android updates at the beginning of the month. [Liam Tung] at ZDNet does a good job laying out the basics. First, when Google announced the May Android updates, they pointed out four vulnerabilities as possibly being actively exploited. Dan Goodin over at Ars Technica took umbrage with the imprecise language, calling the announcement “vague to the point of being meaningless”.
Shane Huntley jumped into the fray on Twitter, and hinted at the backstory behind the vague warning. There are two possibilities that really make sense here. The first is that exploits have been found for sale somewhere, like a hacker forum. It’s not always obvious if an exploit has indeed been sold to someone using it. The other possibility given is that when Google was notified about the active exploit, there was a requirement that certain details not be shared publicly. So next time you see a big organization like Google hedge their language in an obvious and seemingly unhelpful way, it’s possible that there’s some interesting situation driving that language. Time will tell.
The Patch Gap
The term has been around since at least 2005, but it seems like we’re hearing more and more about patch gap problems. The exact definition varies, depending on who is using the term, and what product they are selling. A good working definition is the time between a vulnerability being public knowledge and an update being available to fix the vulnerability.
There are more common reasons for patch gaps, like vulnerabilities getting dropped online without any coordinated disclosure. Another, more interesting cause is when an upstream problem gets fixed and publicly announced, and it takes time to get the fix pulled in. The example in question this week is Safari, and a fix in upstream WebKit. The bug in the new AudioWorklets feature is a type confusion that provides an easy way to do audio processing in a background thread. When initializing a new worker thread, the programmer can use their own constructor to build the thread object. The function that kicks off execution doesn’t actually check that it’s been given a proper object type, and the object gets cast to the right type. Code is executed as if it was correct, usually leading to a crash.
The bug was fixed upstream shortly after a Safari update was shipped. It’s thought that Apple ran with the understanding that this couldn’t be used for an actual RCE, and therefore hadn’t issued a security update to fix it. The problem there is that it is exploitable, and a PoC exploit has been available for a week. As is often the case, this vulnerability would need to be combined with at least one more exploit to overcome the security hardening and sandboxing built into modern browsers.
There’s one more quirk that makes this bug extra dangerous, though. On iOS devices, when you download a different browser, you’re essentially running Safari with a different skin pasted on top. As far as I know, there is no way to mitigate against this bug on an iOS device. Maybe be extra careful about what websites you visit for a few days, until this get fixed.
In what may be a first for watering hole attacks, we’ve now seen an attack that targeted watering holes, or at least water utilities. The way this was discovered is a bit bizarre — it was found by Dragos during an investigation into the February incident at Oldsmar, Florida. A Florida contractor that specializes in water treatment runs a WordPress site that hosted a data-gathering script. The very day that the Oldsmar facility was breached, someone from that location visited the compromised website.
You probably immediately think, as the investigators did, that the visit to the website must be related to the compromise of the Oldsmar treatment plant. The timing is too suspect for it to be a coincidence, right? That’s the thing, the compromised site was only gathering browser fingerprints, seemingly later used to disguise a botnet. The attack itself was likely carried out over Teamviewer. I will note that the primary sources on this story have named Teamviewer, but call it unconfirmed. Assuming that the breach did indeed occur over that platform, then it’s very unlikely that the website visit was a factor, which is what Dragos concluded. On the other hand, it’s easy enough to imagine a scenario where the recorded IP address from the visit led to a port scan and the discovery of a VNC or remote desktop port left open. Continue reading “This Week In Security: Watering Hole Attackception, Ransomware Trick, And More Pipeline News”→
Whether you own any Amazon surveillance devices or not, we know how much you value your privacy. So consider this your friendly reminder that Amazon Sidewalk is going live in a few weeks, on June 8th. A rather long list of devices have this setting enabled by default, so if you haven’t done so already, here’s how to turn it off.
Don’t know what we’re talking about? Our own Jenny List covered the topic quite concretely a few months back. The idea behind it seems innocent enough on the surface — extend notoriously spotty Wi-Fi connectivity to devices on the outer bounds of the router’s reach, using Bluetooth and LoRa to talk between devices and share bandwidth. Essentially, when Amazon flips the switch in a few weeks, their entire fleet of opt-in-by-default devices will assume a kind of Borg hive-mind in that they’ll be able to share connectivity.
A comprehensive list of Sidewalk devices includes: Ring Floodlight Cam (2019), Ring Spotlight Cam Wired (2019), Ring Spotlight Cam Mount (2019), Echo (3rd Gen), Echo (4th Gen), Echo Dot (3rd Gen), Echo Dot (4th Gen), Echo Dot (3rd Gen) for Kids, Echo Dot (4th Gen) for Kids, Echo Dot with Clock (3rd Gen), Echo Dot with Clock (4th Gen), Echo Plus (1st Gen), Echo Plus (2nd Gen), Echo Show (1st Gen), Echo Show (2nd Gen), Echo Show 5, Echo Show 8, Echo Show 10, Echo Spot, Echo Studio, Echo Input, Echo Flex. — Amazon Sidewalk FAQ
Now this isn’t a private mesh network in your castle, it’s every device in the kingdom. So don’t hesitate, don’t wait, or it will be too late. Grab all your Things and opt-out if you don’t want your doorbell cam or Alexa machine on the party line. If you have the Alexa app, you can allegedly opt out on all your devices at once.
Worried that Alexa is listening to you more often than she lets on? You’re probably right.
