Okay, you have to see the gallery to appreciate it, but this keyboard was designed to resemble a red cedar tree with the green shell and wood bottom and the copper PCB showing through the tree cutouts on the sides.

Oh, and are those Nintendo Switch joysticks above the PS2 buttons? Those are for the mouse and vertical/horizontal scrolling. Honestly, this seems like a great amount of thumb controls. The basics are there (presumably), and there isn’t any thumb-extending excess, like keys on the insides by the mouse.

This bad mama jama runs on an RP2040 and has 50 hand-wired Cherry Brown switches plus the PS2 buttons. In the build guide, you can read all about [WesternRedCdar]’s troubles with integrating those. The Nintendo Switch joysticks weren’t terribly easy, either, since the ribbon connector can’t be soldered directly.

The final issue was one of weight. Since many of the switches stand quite tall, it sort of jostles the keyboard to actuate them. [WesternRedCdar] opined that that the ideal solution would have been to use metal base plates instead of wood, but took care of the issue by adding layers of 1/8″ steel flat bar inside the case.

Gone in 60 Seconds: the Micro Journal Rev. 7 From Tindie

Don’t know what took me so long to find r/writerDeck, but here we go! [WorkingAmbition7014] was quite excited to announce there that [Background_Ad_1810] aka [Un Kyu Lee]’s Micro Journal rev. 7 was up on Tindie. It’s already sold out, but that’s okay because previous versions are already open-source, and it’s just a matter of time before this new revision makes its way to the ole GitHub.

This distraction-free machine is based on the ESP32-S3 microcontroller. It starts up right away, and you can start typing pretty much immediately on the ePaper screen. There are a pair of knobs that go a long way toward its typewriter looks; the left one wipes the screen and puts the machine to sleep, and the right knob clears the screen in the case of too much ghosting.

Files are saved on the SD card that sits behind the screen, or you can send them to Google Drive. Now, it doesn’t come with that cool clip light, but it doesn’t have a backlight, either, so you’ll probably want to bring your own. You will also have to source your own 18650. Be sure to check out the overview after the break.

The Centerfold: Purple Paradise

I love these setup pictures, but I have to wonder, does anyone really keep their desk this clean and tidy? Of course not, it’s for the shot, you’re saying. But that’s my point. Why does everyone always tidy up so hard first? I want to see battle stations in their true forms sometimes. I feel like we got sorta close last week in the one with all the screens. So do I need to inspire centerfold submissions by showing my own battle station one of these times? I don’t know if y’all really want that.

Do you rock a sweet set of peripherals on a screamin’ desk pad? Send me a picture along with your handle and all the gory details, and you could be featured here!

Historical Clackers: the Ford Typewriter

Isn’t this machine a beauty? And no, inventor Eugene A. Ford bore no relation to Henry Ford the automobile maker. But wouldn’t this look grand while perched briefly on the running board of your Model T for a quick daguerreotype?

Lovely as she was, the 1895 Ford was no fun for the typist. The Space bar-placed Shifts required real pressure to properly operate, and the keys are evidently springy and wobbly. “Springy” sounds intriguing; “wobbly” does not.

Additionally, the advancing lever doesn’t allow going backwards or forwards a line at a time. But the one great thing about the Ford was that it’s a visible writer, whereas most machines of the time were blind writers, meaning you were unable to see what you were typing without stopping and doing something first. It wasn’t the first visible writer, but it might be the easiest to look at.

What it did do first is use aluminium in its construction, although there were two versions, one with an all-aluminium frame and carriage, and the other with a black, enameled cast iron frame and and an aluminium carriage. The cast iron went for $75, and the lighter-weight aluminium machine for $85. Both were lateral thrust machines, which means that the type bars are spread out like a fan and move horizontally to strike the platen.

Eugene Ford had quite the career. After putting his typewriter on the market in 1895, he worked with IBM for the rest of his life, and became chief development engineer of the New York laboratories in 1911. During his tenure, he developed improvements to various punched card accounting machines, sorters, and counters.

Finally, a Keyboard for Cat Lovers

Cats and keyboards go together like peanut butter and jelly. When they’re not straight up walking across it, they’re fluffing it up. Well, why not admit defeat and get this cozy cat-themed keyboard?

This is the Dry Studio Petbrick 65, which comes in calico and black, which is called the odd-eyed design, presumably because the kitty on the Escape key has heterochromia.

Now that’s just the keyboard itself that comes in calico and black; soon you’ll be able to get all kinds of fuzzy bezels, which attach with magnets and are hand-washable, thankfully.

The Petbrick 65 isn’t just some cutesy little thing. This is a serious mechanical keyboard with a sandblasted POM plate, a specially-tuned (what? how?) cotton poron switch pad, PET film for the sake of acoustics, and two layers of sound-dampening foam.

The switches are custom-made ‘crystal pinks’ that were developed in-house and look pretty slick. If you don’t like them, the PCB is hot-swappable. And they didn’t stop there — the keycaps have dye-sublimated legends for longevity.

Would I type on this? I would, at least until it became uncomfortable for my RSI situation. I’m interested to try these crystal pink switches and feel the fluffiness of the frame on the heels of my hands.

Got a hot tip that has like, anything to do with keyboards? Help me out by sending in a link or two. Don’t want all the Hackaday scribes to see it? Feel free to email me directly.

In an ideal world, devoid of pesky details like contact resistance and manufacturing imperfections, you would be able to double the current that can be provided to a device by doubling the number of conductors without altering the device’s circuitry, as each conductor would carry the exact same amount of current as its neighbors. Since we do not actually live inside a simplified physics question’s scenario, multi-wire powering of devices comes with a range of headaches, succinctly summarized in the well-known rule that electricity always seeks the path of least resistance.

As recently shown by NVidia with their newly released RTX 50-series graphics cards, failure to provide current balancing between said different conductors will quickly turn it into a practical physics demonstration of this rule. Initially pinned down as an issue with the new-ish 12VHPWR connector that was supposed to replace the 6-pin and 8-pin PCIe power connectors, it turns out that a lack of current balancing is plaguing NVidia GPUs, with predictably melty results when combined with low safety margins.

So what exactly changed that caused what seems to be a new problem, and why do you want multi-wire, multi-phase current balancing in your life when pumping hundreds of watts through copper wiring inside your PC?

Resistance Is Not Futile

In the absence of cheap room-temperature superconducting wires, we have to treat each conductor as a combination of a resistor, inductor and capacitor. These parameters set limitations on properties such as how much current a conductor can carry without changing phase from solid to gaseous. The contact resistance between the conductors of both sides in a connector adds another variable here, especially when a connector wears out or the contacts become corroded.

In the case of the 6-pin and 8-pin PCIe power connector, these are based on the Molex Mini-Fit series, with the commonly used Mini-Fit Plus HCS (high current system) rated for 100 mating cycles in tin plating or 250 cycles in gold, and a current rating of 8.5 A to 10 A per pin depending on whether 18 AWG or 16 AWG wire is used. The much smaller connector of the 12-pin 12VHPWR, and equivalent 12V-2×6, standard is rated for only 30 mating cycles, and 9.5 A per pin. It is based on the Molex Micro-Fit+ connector.

The smaller pin size and lower endurance increases the possibility of poor contact, as first demonstrated with the 12VHPWR connector back in 2022 when NVidia RTX 40-series cards experienced run-away thermal events where this power connector on the GPU side melted. Subsequent research by the team at Gamers Nexus showed this to be due to poor contact within the connector with resulting high resistance and thus a massive thermal hot spot. Following this event, the 12V-2×6 update to 12VHPWR increased the length of the power pins and decreased that of the four sense pins.

The idea behind this change is that by extending the length of the power and ground pins by 0.25 mm and shortening the sense pins by 1.5 mm there’s a higher chance of there being an actual good contact on the ground and power pins when the sense lines signal the GPU that it can start drawing hundreds of watts.

This change did only affect the male side of the connector, and not the cable itself. This made it very surprising to some when after the much higher wattage RTX 5090 GPUs were released and suddenly cables began burning up,with clear melting visible on the GPU and power supply side. What was going on here?

Multi-Phase Balance

Shortly after the first melting cable event involving an RTX 5090 Founders Edition (FE) GPU popped up on the internet, Roman [Der8auer] Hartung reached out to this lucky person and – since both live quite close – borrowed the damaged GPU, PSU and cable for an investigative video. Involved were not only an RTX 5090 FE GPU, but also the PSU with its 12VHPWR connector. On each side the plastic around one pin was completely melted, with the cable having to be forcibly removed.

During Roman’s testing with another RTX 9050 FE and 12VHPWR cable he found that two of the six 12V wires were significantly warmer than the rest, courtesy of these carrying over 22 A versus around 2 A for the others while the PSU-side connector side hit a blistering 150 °C. This result was replicated by some and seems to be fully due to how the NVidia RTX 9050 FE card handles the incoming power, by tying all incoming power lines together. This is a practice that began with the RTX 4090, but the RTX 5090 is the first to pull close to the rated 600 watts of the 12VHPWR/12V-2×6 connector. This was explained quite comprehensively in a comparison video by Buildzoid.

Because with the RTX 4090 and 5090 FE GPUs – as well as some GPUs by third-party manufacturers – these 12V lines are treated as a singular line, it is essential that the resistance on these lines is matched quite closely. If this is not the case, then physics does what it’s supposed to and the wires with the lowest resistance carry the most current. Because the 12V-2×6 connector on the GPU side sees only happy sense pins, it assumes that everything is fine and will pull 575 watts, or more, through a single 16 AWG wire if need be.

Meanwhile the Asus RTX 5090 Astral GPU does have individual shunt resistors to measure the current on the individual 12V lines, but no features to balance current or throttle/shutdown the GPU to prevent damage. This is actually a feature that used to be quite common, as demonstrated by this EVGA RTX 3090 Ti GPU:

On the top right the triple sense resistors (shunts) are visible, each of which is followed by its own filter coil and feeding its own set of power phases, marked in either red, green or blue. The yellow phases are for the RAM, and are fed from the PCIe slot’s 75 Watt. The bottom right controller controls the phases and based on the measured currents can balance the current per channel by shifting the load between parts of the phases.

This is a design that is completely omitted in the RTX 5090 FE design, which – as Igor Wallossek at Igor’s Lab describes it – has been minimized to the point where crucial parts have begun to be omitted. He also covers an MSI RTX 3090 Ti Suprim card which does a similar kind of phase balancing before the RTX 4090 and RTX 5090 versions of MSI’s GPUs begin to shed such features as well. It would seem that even as power demands by GPUs have increased, crucial safety features such as current balancing have been sacrificed. As it turns out, safety margins have also been sacrificed along with these features.

Safety Margins

The ugly truth about the switch from 8-pin PCIe connectors to 12-pin 12VHPWR connectors is that while the former is rated officially for 150 watts, this power level would be hit easily even by the cheapest implementation using crummy 18 AWG wiring. With the HCS connectors and 16 AWG wiring, you are looking at 10 A × 12 V × 3 = 360 watts, or a safety margin of 2.4. With cheaper connectors and a maximum of 7 A per wire it would still be a safety margin of 1.68.

Meanwhile, the 12VHPWR/12V-2×6 with the required 16 AWG wiring is rated for 9.5 A × 12 V × 6 = 684 watts, or a safety margin of 1.14. In a situation where one or more wires suddenly decide to become higher-resistance paths this means that the remaining wires have to pick up the slack, which in the case of a 575 watt RTX 5090 GPU means overloading these wires.

Meanwhile a 8-pin PCIe connector would be somewhat unhappy in this case and show elevated temperatures, but worst case even a single wire could carry 150 watts and be happier than the case demonstrated by [Der8auer] where two 12V-2×6 connector wires were forced to carry 260 watts each for the exact same wire gauge.

This is also the reason why [Der8auer]’s Corsair PSU 12V-2×6 cable is provided with two 8-pin PCIe-style connectors on the PSU side. Each of these is rated at 300 watts by Corsair, with Corsair PSU designer Jon Gerow, of JonnyGuru PSU review fame, going over the details on his personal site for the HCS connectors. As it turns out, two 8-pin PCIe connectors are an easy match for a ‘600 watt’ 12VHPWR connector, with over 680 watt available within margins.

There’s a good chance that this was the reason why [Der8auer]’s PSU and cable did not melt, even though it clearly really wanted to do so.

Balance Is Everything

Although it is doubtful that we have seen the last of this GPU power connector saga, it is telling that so far only GPUs with NVidia chips have gone full-in on the 12VHPWR/12V-2×6 connectors, no doubt also because the reference boards provided to board partners come with these connectors. Over in the Intel and AMD GPU camps there’s not even a tepid push for a change from PCIe power connectors, with so far just one still-to-be-released AMD GPU featuring the connector.

That said, the connector itself is not terrible by itself, with Jon Gerow making the case here quite clearly too. It’s simply a very fiddly and somewhat fragile connector that’s being pushed far beyond its specifications by PCI-SIG. Along the way it has also made it painfully clear that current balancing features which used to exist on GPUs have been quietly dropped for a few years now.

Obviously, adding multiple shunts and associated monitoring and phase balancing is not the easiest task, and will eat up a chunk of board real-estate while boosting BOM size. But as we can see, it can also prevent a lot of bad publicity and melting parts. Even if things should work fine without it – and they usually will – eating into safety margins and cutting components tends to be one of those things that will absolutely backfire in a spectacular fashion that should surprise absolutely nobody.

Featured image: [ivan6953]’s burnt cables.

Ho-hum — another week, another high-profile bricking. In a move anyone could see coming, Humane has announced that their pricey AI Pin widgets will cease to work in any meaningful way as of noon on February 28. The company made a splash when it launched its wearable assistant in April of 2024, and from an engineering point of view, it was pretty cool. Meant to be worn on one’s shirt, it had a little bit of a Star Trek: The Next Generation comm badge vibe as the primary UI was accessed through tapping the front of the thing. It also had a display that projected information onto your hand, plus the usual array of sensors and cameras which no doubt provided a rich stream of user data. Somehow, though, Humane wasn’t able to make the numbers work out, and as a result they’ll be shutting down their servers at the end of the month, with refunds offered only to users who bought their AI Pins in the last 90 days.

How exactly Humane thought that offering what amounts to a civilian badge cam was going to be a viable business model is a bit of a mystery. Were people really going to be OK walking into a meeting where Pin-wearing coworkers could be recording everything they say? Wouldn’t wearing a device like that in a gym locker room cause a stir? Sure, the AI Pin was a little less obtrusive than something like the Google Glass — not to mention a lot less goofy — but all wearables seem to suffer the same basic problem: they’re too obvious. About the only one that comes close to passing that hurdle is the Meta Ray-Ban smart glasses, and those still have the problem of obvious cameras built into their chunky frames. Plus, who can wear Ray-Bans all the time without looking like a tool?

Good news for everyone worried about a world being run by LLMs and chatbots. It looks like all we’re going to have to do is wait them out, if a study finding that older LLMs are already showing signs of cognitive decline pans out. To come to that conclusion, researchers gave the Montreal Cognitive Assessment test to a bunch of different chatbots. The test uses simple questions to screen for early signs of impairment; some of the questions seem like something from a field sobriety test, and for good reason. Alas for the tested chatbots, the general trend was that the older the model, the poorer they did on the test. The obvious objection here is that the researchers aren’t comparing each model’s current score with results from when the model was “younger,” but that’s pretty much what happens when the test is used for humans.

You’ve got to feel sorry for astronomers. Between light pollution cluttering up the sky and an explosion in radio frequency interference, astronomers face observational challenges across the spectrum. These challenges are why astronomers prize areas like dark sky reserves, where light pollution is kept to a minimum, and radio quiet zones, which do the same for the RF part of the spectrum. Still, it’s a busy world, and noise always seems to find a way to leak into these zones. A case in point is the recent discovery that TV signals that had been plaguing the Murchison Wide-field Array in Western Australia for five years were actually bouncing off airplanes. The MWA is in a designated radio quiet zone, so astronomers were perplexed until someone had the bright idea to use the array’s beam-forming capabilities to trace the signal back to its source. The astronomers plan to use the method to identify and exclude other RFI getting into their quiet zone, both from terrestrial sources and from the many satellites whizzing overhead.

And finally, most of us are more comfortable posting our successes online than our failures, and for obvious reasons. Everyone loves a winner, after all, and admitting our failures publicly can be difficult. But Daniel Dakhno finds value in his failures, to the point where he’s devoted a special section of his project portfolio to them. They’re right there at the bottom of the page for anyone to see, meticulously organized by project type and failure mode. Each failure assessment includes an estimate of the time it took; importantly, Daniel characterizes this as “time invested” rather than “time wasted.” When you fall down, you should pick something up, right?

In Al Williams’s marvelous rant he points out a number of the problems with speaking to computers. Obvious problems with voice control include things like multiple people talking over each other, discerning commands from background conversations, and so on. Somehow, unlike on the bridge in Star Trek, where the computer seems to understand everyone just fine, Al sometimes can’t even get the darn thing to play his going-to-sleep playlist, which should be well within the device’s capabilities.

In the comments, [rclark] suggests making a single button that plays his playlist, no voice interaction required, and we have to admit that it’s a great solution to this one particular problem. Heck, the “bedtime button” would make fun project in and of itself, and it’s such a limited scope that it could probably only be an weekend’s work for anyone who has touched the internals of their home automation system, like Al certainly has. We love the simplicity of the idea.

But it ignores the biggest potential benefit of a voice control system: that it’s a one-size-fits-all solution for everything. Imagine how many other use cases Al would need to make a single button device for, and how many coin cell batteries he’d be signing himself up to change out over the course of the year. The trade-off is that the general purpose solution tends not to be as robust as a single-tasker like the button, but also that it can potentially simplify the overall system.

I suffer this in my own home. It’s much more a loosely-coupled web of individual hacks than an overall system, and that has pros and cons. Each individual part is easier to maintain and hack on, but the overall system is less coordinated than it could be. If we change the WiFi password on the home automation router, for instance, I’m going to have to individually log into about eight ESP8266s and change their credentials. Yuck!

It’s probably a matter of preference, but I’ll still take the loose, MQTT-based system that I’ve got now over an all-in-one. Like [rclark], I value individual device simplicity and reliability above the overall system’s simplicity, but because our stereo isn’t even hooked up to the network, I can’t play myself to sleep like Al can. Or at least like he can when the voice recognition is working.

This week Hackaday Editors Elliot Williams and Tom Nardi start things off with updates on the rapidly approaching Hackaday Europe and the saga of everyone’s favorite 3D printed boat.

From there they’ll cover an impressive method of seeing the world via WiFi, Amazon’s latest changes to the Kindle ecosystem, and an alternate reality in which USB didn’t take over the peripheral world. You’ll also hear about a multi-level hack that brings the joys of Linux into the world of Animal Crossing, 3D printed circuit components, and the imminent release of KiCAD 9.

Stick around until the end to learn about a unique hardened glass from East Germany and the disappointing reality of modern voice control systems.

Download the DRM-free MP3 for safe keeping.

Episode 309 Show Notes:

News:

• Hackaday Europe 2025: Speakers, Lightning Talks, And More!
• 3DBenchy Sets Sail Into The Public Domain

What’s that Sound?

• Know that sound? Fill out this form for a chance to win a Hackaday Podcast t-shirt!

Interesting Hacks of the Week:

• Octet Of ESP32s Lets You See WiFi Like Never Before
  • Building Your Own SDR-based Passive Radar On A Shoestring
  • Open-Source Passive Radar Taken Down For Regulatory Reasons
  • [2502.09405] ESPARGOS: An Ultra Low-Cost, Realtime-Capable Multi-Antenna WiFi Channel Sounder

• Auto-Download Your Kindle Books Before February 26th Deadline
• In A World Without USB…
• Give Your Animal Crossing Villagers The Gift Of Linux
  • Because You Can: Linux On An Arduino Uno
• A Unique Linear Position Sensor Using Magnetostriction
  • 2024 :: fischertechnik Community

• MIT Demonstrates Fully 3D Printed, Active Electronic Components

Quick Hacks:

• Elliot’s Picks:
  • You Know This Font, But You Don’t Really Know It
  • Measuring Local Variances In Earth’s Magnetic Field
  • Probably The Most Esoteric Commodore 64 Magazine
• Tom’s Picks:
  • Get Ready For KiCAD 9!
  • Vacuum Forming With 3D Printed Moulds And Sheets
  • Belfry OpenSCAD Library (BOSL2) Brings Useful Parts And Tools Aplenty

Can’t-Miss Articles:

• The “Unbreakable” Beer Glasses Of East Germany
  • The High-Tech Valor Glass Vials Used To Deliver The Coronavirus Vaccine

• Be Careful What You Ask For: Voice Control

OpenSSH has a newly fixed pair of vulnerabilities, and while neither of them are lighting the Internet on fire, these are each fairly important.

The central observation made by the Qualsys Threat Research Unit (TRU) was that OpenSSH contains a code paradigm that could easily contain a logic bug. It’s similar to Apple’s infamous goto fail; SSL vulnerability. The setup is this: An integer, r, is initialized to a negative value, indicating a generic error code. Multiple functions are called, with r often, but not always, set to the return value of each function. On success, that may set r to 0 to indicate no error. And when one of those functions does fail, it often runs a goto: statement that short-circuits the rest of the checks. At the end of this string of checks would be a return r; statement, using the last value of r as the result of the whole function.

1387 int
1388 sshkey_to_base64(const struct sshkey *key, char **b64p)
1389 {
1390         int r = SSH_ERR_INTERNAL_ERROR;
....
1398         if ((r = sshkey_putb(key, b)) != 0)
1399                 goto out;
1400         if ((uu = sshbuf_dtob64_string(b, 0)) == NULL) {
1401                 r = SSH_ERR_ALLOC_FAIL;
1402                 goto out;
1403         }
....
1409         r = 0;
1410  out:
....
1413         return r;
1414 }

The potential bug? What if line 1401 was missing? That would mean setting r to the success return code of one function (1398), then using a different variable in the next check (1400), without re-initializing r to a generic error value (1401). If that second check fails at line 1400, the code execution jumps to the return statement at the end, but instead of returning an error code, the success code from the intermediary check is returned. The TRU researchers arrived at this theoretical scenario just through the code smell of this particular goto use, and used the CodeQL code analysis tool to look for any instances of this flaw in the OpenSSH codebase.

The tool found 50 results, 37 of which turned out to be false positives, and the other 13 were minor issues that were not vulnerabilities. Seems like a dead end, but while manually auditing how well their CodeQL rules did at finding the potentially problematic code, the TRU team found a very similar case, in the VerifyHostKeyDNS handling, that could present a problem. The burning question on my mind when reaching this point of the write-up was what exactly VerifyHostKeyDNS was.

SSH uses public key cryptography to prevent Man in the Middle (MitM) attacks. Without this, it would be rather trivial to intercept an outgoing SSH connection, and pretend to be the target server. This is why SSH will warn you The authenticity of host 'xyz' can't be established. upon first connecting to a new SSH server. And why it so strongly warns that IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! when a connection to a known machine doesn’t verify properly. VerifyHostKeyDNS is an alternative to trusting a server’s key on first connection, instead getting the cryptographic fingerprint in a DNS lookup.

So back to the vulnerability. TRU found one of these goto out; cases in the VerifyHostKeyDNS handling that returned the error code from a function on failure, but the code a layer up only checked for a -1 value. On one layer of code, only a 0 was considered a success, and on the other layer, only a -1 was considered a failure. Manage to find a way to return an error other than -1, and host key verification automatically succeeds. That seems very simple, but it turns out the only other practical error that can be returned is an out of memory error. This leads to the second vulnerability that was discovered.

OpenSSH has its own PING mechanism to determine whether a server is reachable, and what the latency is. When it receives a PING, it sends a PONG message back. During normal operation, that’s perfectly fine. The messages are sent and the memory used is freed. But during key exchange, those PONG packets are simply queued. There are no control mechanisms on how many messages to queue, and a malicious server can keep a client in the key exchange process indefinitely. In itself it’s a denial of service vulnerability for both the client and server side, as it can eat up ridiculous amount of memory. But when combined with the VerifyHostKeyDNS flaw explained above, it’s a way to trigger the out of memory error, and bypass server verification.

The vulnerabilities were fixed in the 9.9p2 release of OpenSSH. The client attack (the more serious of the two) is only exploitable if your client has the VerifyHostKeyDNS option set to “yes” or “ask”. Many systems default this value to “no”, and are thus unaffected.

JumbledPath

We now have a bit more insight into how Salt Typhoon recently breached multiple US telecom providers, and deployed the JumbledPath malware. Hopefully you weren’t expecting some sophisticated chain of zero-day vulnerabilities, because so far the answer seems to be simple credential stealing.

Cisco Talos has released their report on the attacks, and the interesting parts are what the attackers did after they managed to access target infrastructure. The JumbledPath malware is a Go binary, running on x86-64 Linux machines. Lateral movement was pulled off using some clever tricks, like changing the loopback address to an allowed IP, to bypass Access Control Lists (ACLs). Multiple protocols were abused for data gathering and further attacks, like SNMP, RADIUS, FTP, and SSH. There’s certainly more to this story, like where the captured credentials actually came from, and whose conversations were actually targeted, but so far those answers are not available.

Ivanti Warp-Speed Audit

The preferred method of rediscovering vulnerabilities is patch diffing. Vendors will often announce vulnerabilities, and even release updates to correct them, and never really dive into the details of what went wrong with the old code. Patch diffing is looking at the difference between the vulnerable release and the fixed one, figuring out what changed, and trying to track that back to the root cause. Researchers at Horizon3.ai knew there were vulnerabilities in Ivanti’s Endpoint manager, but didn’t have patches to reverse engineer. Seems like a bummer, but was actually serendipity, as the high-speed code audit looking for the known vulnerability actually resulted in four new ones being found!

They are all the same problem, spread across four API endpoints, and all reachable by an unauthenticated user. The code is designed to look at files on the local filesystem, and generate hashes for the files that are found. The problem is that the attacker can supply a file name that actually resolves to an external Universal Naming Convention (UNC) path. The appliance will happily reach out and attempt to authenticate with a remote server, and this exposes the system to credential relay attacks.

RANsacked

The Florida Institute for Cybersecurity Research have published a post and paper (PDF) about RANsacked, their research into various LTE and 5G systems. This is a challenging area to research, as most of us don’t have any spare LTE routing hardware laying around to research on. The obvious solution was to build their own, using open source software like Open5GS, OpenAirInterface, etc. The approach was to harness a fuzzer to find interesting vulnerabilities in these open implementations, and then apply that approach to closed solutions. Serious vulnerabilities were found in every target the fuzzing system was run against.

Their findings break down into three primary categories of vulnerabilities. The first is untrusted Non-Access Stratum (NAS) control messages getting handled by the “core”, the authentication, routing, and processing part of the cellular system. These messages aren’t properly sanitized before processing, leading to the expected crashes and exploits we see in every other insufficiently hardened system that processes untrusted data. The second category is the uncertainty in the protocol specifications and mismatch between what those specifications seem to indicate and the reality of cellular traffic. And finally, deserialization of ASN.1 data itself is subject to deserialization attacks. This group of research found a staggering 119 vulnerabilities in total.

Bits and Bytes

[RyotaK] at GMO Flatt Security found an interesting vulnerability in Chatwork, a popular messaging application in Japan. The desktop version of this tool is just an electron app, and it makes use of webviewTag, an obsolete Electron feature. This quirk can be combined with a dangerous method in the preload context, allowing for arbitrary remote code execution when a user clicks a malicious link in the application.

Once upon a time, Microsoft published Virtual Machines for developers to use for testing websites inside Edge and IE. Those VM images had the puppet admin engine installed, but no configuration set. And that’s not great, because in this state puppet will look for machine using the puppet hostname on the local network, and attempt to download a configuration from there. And because puppet is explicitly designed to administer machines, this automatically results in arbitrary code execution. The VMs are no longer offered, so we’re past the expiration date on this particular trick, but what an interesting quirk of these once-official images.

[Anurag] has an analysis of the Arechclient2 Remote Access Trojan (RAT). It’s a bit of .NET malware, aggressively obfuscated, that collects and exfiltrates data and credentials. There’s a browser element, in the form of a Chrome extension that reports itself as Google Docs. This is more data collection, looking for passwords and other form fills.

Signal users are getting hacked by good old fashioned social engineering. The trick is to generate a QR code from Signal that will permit the account scanning the code to log in on another device. It’s advice some of us have learned the hard way, but QR codes are just physical manifestations of URLs, and we really shouldn’t trust them lightly. Don’t click that link, and don’t scan that QR code.

This week, Jonathan Bennett talks Rocky Linux with Gregory Kurtzer and Krista Burdine! Where did the project come from, and what’s the connection with CIQ and RESF? Listen to find out!

• CentOS primer
• Migration from CentOS
• Rocky Linux
• RESF FAQ
• CIQ Open Source Ethos

Did you know you can watch the live recording of the show right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or contact the guest and have them contact us! Take a look at the schedule here.

Direct Download in DRM-free MP3.

If you’d rather read along, here’s the transcript for this week’s episode.

Theme music: “Newer Wave” Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License