Members of Pixelbar woke up to shocking news on Wednesday morning this week as they learned that a fire had destroyed the building housing their Rotterdam hackerspace. Pictures of the fire are pretty dramatic and show the entire building ablaze. We’re not familiar with Pixelbar specifically, but most hackerspaces seem to share space with other businesses in repurposed warehouses and other industrial buildings, and it looks like that was the case here. Local coverage doesn’t indicate that a cause has been determined, but they do say that “large batches of wood” were stored in or near the structure, which likely contributed to the dramatic display. There don’t seem to be reports of injuries to civilians or first responders, so that’s a blessing, but Pixelbar seems to have been completely destroyed. If you’re in a position to help, check out their GoFundMe page. As our own Jenny List, who currently lives in The Netherlands, points out, spaces suitable for housing a hackerspace are hard to come by in a city like Rotterdam, which is the busiest port in Europe. That means Pixelbar members will be competing for space with businesses that have far deeper pockets, so anything you can donate will likely go a long way toward rebuilding.
Where this gets ugly is in how much damage that one infection caused. The virus, now named fractureiser, installs itself into every other Minecraft-related .jar on the compromised system. It also grabs credentials, cookies, cryptocurrency addresses, and the clipboard contents. Once that information was exfiltrated from the LPS developer, the attacker seems to have taken manual actions, using the purloined permissions to upload similarly infected mod files, and then marking them archived. This managed to hide the trapped files from view on the web interface, while still leaving them exposed when grabbed by the API. Once the malware hit a popular developer, it began to really take off.
It looks like the first of the malicious .jar files actually goes all the way back to mid-April, so it may take a while to discover all the places this malware has spread. It was first noticed on June 1, and investigation was started, but the story didn’t become public until the 7th. Things have developed rapidly, and the malware fingerprints has been added to Windows Defender among other scanners. This helps tremendously, but the safe move is to avoid downloading anything Minecraft related for a couple days, while the whole toolchain is inspected. If it’s too late and you’ve recently scratched that voxel itch, it might be worth it to take a quick look for Indicators of Compromise (IoCs).
Microsoft’s Threat Intelligence group has announced a new naming scheme for threat actors. It sounds great, naming groups after weather phenomenon, based on the groups motivations or nation of origin. Then each discreet group is given an additional adjective. That’s where things get interesting.
It seems like the adjectives were chosen at random, giving rise for some suitably impressive names, like Ghost Blizzard, Ruby Sleet, or Granite Typhoon. Some of the other names sound like they should be desserts: Caramel Tsunami, Peach Sandstorm, Aqua Blizzard, or Raspberry Typhoon. But then there the really special names, like Wine Tempest and Zigzag Hail. But the absolute winner is Spandex Tempest. No word yet on whether researchers managed to keep a straight face when approving that name.
Chrome 0-day Double
A pair of Chrome browser releases have been minted in the past week, both to address vulnerabilities that are actively being exploited. Up first was CVE-2022-2033, type confusion in the V8 JS engine. That flaw was reported by Google’s Threat Analysis Group, presumably discovered in the wild, and the fix was pushed as stable on the 14th.
Then, on th 18th, yet another released rolled out to fix CVE-2023-2136, also reported by the TAG, also being exploited in the wild. It seems likely that both of these 0-days were found in the same exploitation campaign. We look forward to hearing the details on this one. Continue reading “This Week In Security: Spandex Tempest, Supply Chain Chain, And NTP”
You’ve probably heard about Google Chromebooks. Like Android, Chrome OS is based on some variant of Linux, but it is targeted at the “cloud first” strategy so Chromebooks typically don’t have a huge amount of storage or compute power. If you have a real Chromebook, you can also use it to run certain other kinds of programs via virtualization. However, Google has recently pushed out Chrome OS Flex which is meant to install on a spare laptop you might happen to have hanging around. Seems attractive to take that only Windows 7 laptop and repurpose it to run Chrome OS, especially if you can run Linux apps on it. Unfortunately, Chrome OS Flex has a very different use case and I would only recommend installing it if you meet the exact use case it addresses.
The other option, of course, is to just install Linux on that old hardware. There are several distributions that are made for that purpose and, honestly, even most of the major distributions will work fine on older hardware with a little tweaking to turn off some of the more resource-costly features. That assumes you know how to install, tweak, and maintain Linux.
Arguably one of the most important pieces of software to have in your hardware hacking arsenal is a nice serial terminal emulator. There’s plenty of choice out there, from classic command line tools to flashier graphical options, which ultimately all do the same thing in the end: let you easily communicate with gadgets using UART. But now you’ve got a new choice — instead of installing a serial terminal emulator, you can simply point your browser to the aptly-named serialterminal.com.
Well, maybe. As of this writing it only works on Chrome/Chromium (and by extension, Microsoft Edge), so Firefox fans will be left out in the cold unless Mozilla changes their stance on the whole Web Serial API concept. But assuming you are running the appropriate browser, you’ll be able to connect with your serial gadgets with a simple interface that should be familiar to anyone who’s worked with more traditional terminal software. In a quick test here at the Hackaday Command Center, we were able to bring up the Bus Pirate UI with no problems using Chrome on Linux. Continue reading “Web Serial Terminal Means It’s Always Hacking Time”
Most Chrome users will have come across a neat little Easter egg when their Internet connection has gone down – a game known as “T-Rex” where a dinosaur must be jumped over cactii. Whether or not this is accurate in terms of the evolutionary timeline, it’s a bit of fun, and Volos Projects educator [Danko Bertović] decided to port the game to the ESP32.
The game runs on the LILYGO TTGO T-Display development board, which pairs the powerful microcontroller with a 1.14-inch color LCD. His clone goes as far as authentically replicating the “No Internet” page from within Google Chrome, before kicking into the game at the press of a tactile button.
The game is built using a sprite-based engine, which enables gameplay with a minimum of flickering on the screen. Transparency is included to stop the sprites from occluding other screen elements unnecessarily. [Danko] hasn’t yet released a full tutorial on using sprites on the ESP32, but code is available for your own digestion.
Linux users are more likely than most to be familiar with Chromium, Google’s the free and open source web project that serves as the basis for their wildly popular Chrome. Since the project’s inception over a decade ago, users have been able to compile the BSD licensed code into a browser that’s almost the same as the closed-source Chrome. As such, most distributions offer their own package for the browser and some even include it in the base install. Unfortunately, that may be changing soon.
A post made earlier this month to the official Chromium Blog explained that an audit had determined “third-party Chromium based browsers” were using APIs that were intended only for Google’s internal use. In response, any browser attempting to access features such as Chrome Sync with an unofficial API key would be prevented from doing so after March 15th.
To the average Chromium user, this doesn’t sound like much of a problem. In fact, you might even assume it doesn’t apply to you. The language used in the post makes it sound like Google is referring to browsers which are spun off of the Chromium codebase, and at least in part, they are. But the search giant is also using this opportunity to codify their belief that the only official Chromium builds are the ones that they provide themselves. With that simple change, anyone using a distribution-specific build of Chromium just became persona non grata.
Unhappy with the idea of giving users a semi-functional browser, the Chromium maintainers for several distributions such as Arch Linux and Fedora have said they’re considering pulling the package from their respective repositories altogether. With a Google representative confirming the change is coming regardless of community feedback, it seems likely more distributions will follow suit.