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.

html5-player.libsyn.com/embed/…
Where to Follow Hackaday Podcast

Places to follow Hackaday podcasts:

• iTunes
• Spotify
• Stitcher
• RSS
• YouTube
• Check out our Libsyn landing page

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

hackaday.com/2025/02/21/hackad…

One-wheels use motion-tracking hardware and fine motor control to let you balance on a single wheel. That’s neat and all, but [Michael Rechtin] had another idea in mind—what if a one-wheel used a track instead?

The idea behind the track was to make the one-wheel more capable on surfaces where wheels simply can’t compete. The tracked drivetrain was largely 3D printed, including some massive gears that are supplemented by a big old 150 mm ball bearing which sits around the drive motor itself. If you love planetary gear trains with a 4:1 reduction, this project is for you. Carbon-fiber reinforced filament was used for many of the parts to give them some additional strength. Control is a little different than a traditional one-wheel, since the flat-bottomed track means lean controls won’t work. Instead, a wireless hand throttle was constructed to enable the rider to command the direction of travel.

It’s not easy to ride, but the one-track does actually work. It’s capable of crawling its way around on grass and snow quite well. There were some issues with the printed tracks and rollers, particularly when turning, but tweaks to round out the track profile helped solve that issue to a degree. There’s a reason we often use wheels instead of tracks, but somehow tracks are still just cool.

youtube.com/embed/VicrABEfr3U?…

hackaday.com/2025/02/21/buildi…

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.

hackaday.com/2025/02/21/this-w…

Negli ultimi tempi, il mondo imprenditoriale veneto è stato ripetutamente preso di mira da attacchi informatici di grande portata. Questa volta la vittima è Fashion Box, multinazionale con sede a Casella d’Asolo, nota per il suo celebre marchio di abbigliamento Replay.

L’azione degli hacker è iniziata il 29 gennaio con una tecnica di brute force riporta il Corriere Del Veneto, un metodo che consiste nel tentare innumerevoli combinazioni di password per ottenere accesso ai sistemi aziendali. Nonostante le misure di sicurezza implementate, i criminali informatici sono riusciti a oltrepassare le difese, compromettendo i server della sede centrale di Asolo. I dati sottratti riguardano informazioni sensibili legate all’attività logistica e commerciale dell’azienda, mentre le consociate estere sembrano essere rimaste al riparo dall’attacco. La criticità della situazione è legata soprattutto alla gestione di dati di dipendenti, collaboratori e fornitori provenienti da diverse parti del mondo.

Le organizzazioni sindacali hanno espresso forte preoccupazione per le conseguenze di questa incursione informatica. I rappresentanti di Filctem Cgil e Femca Cisl hanno evidenziato come Fashion Box abbia agito tempestivamente per arginare il danno e proteggere i lavoratori. Secondo le prime dichiarazioni, al momento non risultano impatti diretti sull’occupazione, ma la situazione resta fluida e in evoluzione. Anche il sindaco di Asolo ha sottolineato l’importanza dell’azienda per l’economia locale, sottolineando come un attacco di questa portata possa mettere in difficoltà numerose famiglie del territorio.

Le analisi condotte dagli esperti di sicurezza informatica di Fashion Box hanno evidenziato che i dati trafugati includono informazioni personali e finanziarie di dipendenti ed ex dipendenti, oltre a documenti di riconoscimento e codici bancari di fornitori. La sottrazione di questi dati potrebbe rallentare significativamente le operazioni logistiche dell’azienda, costringendola a ricostruire parte delle informazioni compromesse. Nel frattempo, sono in corso attività per rafforzare i sistemi di sicurezza informatica e prevenire ulteriori intrusioni.

Fashion Box ha immediatamente segnalato l’accaduto alle autorità competenti sia in Italia che nei paesi coinvolti, come Austria, Francia, Germania, Spagna e Regno Unito. Inoltre, è stata presentata una denuncia alla magistratura per avviare un’indagine ufficiale sul caso. L’attacco rappresenta un ulteriore segnale di allarme sulla crescente vulnerabilità delle aziende del territorio di fronte alle minacce cyber.

Il caso di Fashion Box si inserisce in un contesto preoccupante in cui le imprese venete, nonostante investimenti in sicurezza, continuano a essere bersaglio privilegiato di attacchi informatici. Questo episodio evidenzia la necessità di strategie ancora più avanzate per la protezione dei dati e una maggiore sensibilizzazione su queste minacce, che possono avere impatti economici e occupazionali rilevanti.

L'articolo Il Marchio Replay nel Mirino degli Hacker: Violati i Server dell’Azienda Italiana Fashion Box! proviene da il blog della sicurezza informatica.

Un aneddoto che vale la pena riproporre qui su Friendica, anche se lunghetto... 😆

La backroom

Un'alta carica della P.A. che non sembra avere chiaro un concetto, come dire... Piuttosto intuitivo.

Il Direttore Generale: #brevestoriatriste

Avevo sentito del tentativo di colpo di Stato di Bolsonaro ai danni di Lula, ma una cosa è ssentire la notizia, altra cosa è conoscere i dettagli.

Aveva affidato ad un gruppo militare il compito di UCCIDERE Lula. Come? Era indifferente, andava bene anche l'avvelenamento. In alternativa il Vicepresidente. E anche il Giudice della corte costituzionale, De Moraes, che da sempre indaga sui reati dell'estrema destra. Ma gli elettori dell'estrema destra qualche domanda non se la fanno mai? Mai mai?

Ma ci rendiamo conto? Questi sono gli amici della Meloni, che ovviamente non dice una parola su tutto questo.

Fortuna che ci restano podcast come questo.

open.spotify.com/episode/3phhc…

#bolsonaro #meloni #internazionale #podcast #notizie #brasile #colpodiStato