We’re not sure how we managed to miss this one, but better late than never, right? This is Trinteract, a 3-DOF input device that’s both open-source and Arduino compatible. There’s even a neat 3D-printed clip to add it to the side of your laptop.

Imagine navigating 2D and 3D environments, or flying around in Minecraft with ease. [Görkem]’s custom PCB features a Hall effect sensor which picks up readings from the magnet embedded in the bottom of the joystick. You can use any magnetic object as input. In the video below the break, [Görkem] shows a 3D-printed sphere with a disc magnet trapped inside as an alternative. The super-neat part is that the thing moves around entirely on flexures. You know how much we love flexures around here.

[Görkem] has written up a fantastic guide for those who must have one of their own. As a bonus, the guide details the background and thought process behind the design, which we love to see.

Don’t like magnets? This space mouse uses an accelerometer and a spring.

youtube.com/embed/YoGgdORVARs?…

Thanks for the tip, [James]!

hackaday.com/2025/01/17/trinte…

Touch screen head units are pretty much the norm these days. Many compromise with annoying on-screen volume controls or tiny buttons. If you find yourself with such a unit, you might like to hack in a real volume knob. [Daniel Ross] shows us how to do just that.

The build uses an ATMega328 as the heart of the operation, though [Daniel] notes an Arduino Uno or Mini would have done just fine. It’s set up with a 74HC14 hex Schmitt trigger, and a CD4066 quad bilateral switch on a custom PCB. As for the volume knob itself, it’s not a real analog pot, instead it’s using a rotary encoder with a center push button. The way it works is that the Arduino reads the encoder, and figures out whether you’re trying to turn the volume up or down based on the direction you’re turning it. It then sends commands to the CD4066 to switch resistors in and out of circuit with lines going to the stereo to emulate the action of volume buttons on the steering wheel.

[Daniel’s] guide explains how everything works in greater detail, and how you can calibrate your head unit to accept these signals while preserving the function of your actual steering wheel volume buttons. Then you just have to find a neat way to integrate the knob into your existing dashboard.

We don’t see as many car stereo hacks in this era when infotainment systems rule all, but we’ve seen some great stuff from older vehicles over the years. Video after the break.

youtube.com/embed/dR6vM4ohU5A?…

hackaday.com/2025/01/17/androi…

As per a recent Bambu Lab blog post, its FDM printers in the X1 series will soon receive a firmware update that adds mandatory authentication for certain operations, starting with the firmware update on January 23rd for the aforementioned FDM printers. These operations include performing firmware upgrades, initiating a print job (LAN or cloud), remote video access and adjusting parameters on the printer. Using the printer directly and starting prints from an SD card are not affected.

As reasoning for this new feature Bambu Lab points to recent exploits that gave strangers access to people’s printers, though cheekily linking to an article on an Anycubic printer exploit. While admittedly a concern, this mostly affects internet-exposed printers, such as those that are tied into a ‘cloud’ account. Even so, LAN-based printing also falls under this new mandatory authentication system, with Bambu Lab offering a new tool called Bambu Connect for those who insist on using non-Bambu Lab branded software like OrcaSlicer. This allows for exported G-code files to be sent to a (property authenticated) Bambu Lab printer.

For those who do not wish to use this feature, not upgrading the firmware is currently the only recourse. Although this firmware update is only for X1-series printers, Bambu Lab promised that it’ll arrive for their other printers too in due time. While Bambu Lab printer owners consider installing the alternative X1 Plus firmware, the peanut gallery can discuss the potential security issues (or lack thereof) of an open Fluidd or similar UI on their LAN-connected, Klipper-based FDM printers.

Thanks to [mip] for the tip.

hackaday.com/2025/01/17/new-ba…

OpenAI ha svelato un nuovo modello linguistico, GPT-4b, in grado di progettare proteine ​​per la riprogrammazione cellulare. In collaborazione con la startup biotecnologica Retro Biosciences, fondata dal CEO Joe Betts-LaCroix, l’intelligenza artificiale ha ideato versioni migliorate dei fattori Yamanaka, aumentandone l’efficacia di oltre 50 volte. I fattori Yamanaka sono proteine ​​in grado di trasformare le cellule normali in cellule staminali, il che apre prospettive nel ringiovanimento, nella creazione di organi e nel trattamento delle malattie legate all’età.

Il progetto è iniziato un anno fa come iniziativa di Retro Biosciences , che mira ad aumentare di 10 anni l’aspettativa di vita umana sana. L’azienda è focalizzata sullo sviluppo di terapie mirate ai meccanismi dell’invecchiamento per prevenire e invertire le malattie legate all’età.

Il CEO di OpenAI, Sam Altman, ha investito personalmente 180 milioni di dollari in Retro Biosciences, consentendo all’azienda di ottenere una prima prova di concetto e di garantire operazioni per i prossimi 10 anni.

Il modello GPT-4b è stato addestrato sui dati della sequenza proteica e sulle loro interazioni. A differenza del modello AlphaFold , che prevede la struttura delle proteine, GPT-4b propone cambiamenti nelle sequenze di aminoacidi per migliorare la funzione delle proteine. Le proposte del modello sono state testate nel laboratorio Retro Biosciences, dove i cambiamenti degli aminoacidi hanno portato a miglioramenti significativi nelle prestazioni dei fattori Yamanaka.

I risultati non sono ancora stati pubblicati, ma le aziende prevedono di farlo in futuro. Esperti esterni, come Vadim Gladyshev, ricercatore sull’invecchiamento dell’Università di Harvard, sottolineano l’importanza di tali sviluppi nella creazione di nuovi metodi per la riprogrammazione delle cellule, in particolare per casi complessi e diverse specie animali.

Il progetto ha anche sollevato dubbi su possibili conflitti di interessi, dato il coinvolgimento di Altman nel finanziamento di Retro Biosciences e di altre società. Tuttavia, OpenAI sottolinea che le loro decisioni non sono legate agli investimenti del CEO.

L'articolo Gpt-4 prolungherà la vita umana? L’IA migliora di 50 volte le proteine capaci di generare cellule staminali proviene da il blog della sicurezza informatica.

Regular roller blades go way back, relying on a number of wheels mounted in a line and relying on regular bearings. [The Q] came up with an altogether more interesting design by handcrafting some tall skates with two hubless wheels apiece.

The build eliminates the hard work of creating the shoe part of the skates. Instead, an existing pair of roller blades was used, and modified to run the alternative hubless setup. The hubless wheels themselves were built by essentially wrapping a few large ball bearings with foam tires from an existing scooter wheel. The ball bearings have a large internal diameter, which creates the hubless look. They’re then mounted to a replacement steel frame that was mounted to the original skates.

Are there any benefits to hubless wheels in this application? Probably not, other than aesthetics. These skates are far heavier than before, and with poorer rolling resistance. However, we will note that the softer foam tires and large rolling diameter would probably offer some benefits on rougher surfaces. They even appear to work on hard-packed dirt, which is pretty impressive.

In any case, it’s always neat to see oddball designs that challenge our perception of what can and can’t be achieved on a mechanical level. These things don’t always have to make sense from an efficiency standpoint to be fun.

youtube.com/embed/M1pFmh8PQqY?…

hackaday.com/2025/01/17/you-ca…

It’s podcast time again, and this week Dan sat down with Elliot for a look back at all the cool hacks we’ve written about. We started off talking about Hackaday Europe, which is coming up in March — seems unlikely that it’s just around the corner, but there it is. There’s also good news: the Hack Chat is back, and we started things off with a bang as Eben Upton stopped by to talk all things Pi. Separately, we talked about fault injection attacks, including how to find the hidden cup of 0xC0FFEE in an RP2350.

We saw a very cool piece of LED jewelry that does a fluid simulation, a direct conversion radio that’s all laid out in front of you, and the scrunchiest mechanical digital clock you’ll ever see. We saw blinkenlights for blinkenlights’ sake, all the ways to put threads in your prints, and how to ditch to coax and wire up your antennas with Cat 6 cable. Plus, it’s an Al Williams twofer in the Can’t-Miss Articles, with a look back at life before GPS and how you can tune into digital ham radio, no radio required.

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 zero-calorie MP3.

Episode 304 Show Notes:

News:

• Hackaday Europe 2025 Tickets On Sale, and CFP Extended Until Friday
• Eben Upton Hack Chat Transcript

What’s that Sound?

• Congratulations to [Egon] for getting the Ross ice shelf, and not some sci-fi computer at all.

Interesting Hacks of the Week:

• All The Attacks On The RP2350
• A Direct Conversion Receiver Anyone Can Build
  
  • Amateur Radio Homebrewing Hack Chat
  • Make Your Own Variable Inductor
  • DIY Tuning Capacitors From Washers And 3D-Printed Parts
  • A Variable Capacitor For Not A Lot

  
  

• Fluid Simulation Pendant Teaches Lessons In Miniaturization
• Using The ESP8266 For Low-Cost Fault Injection
• Comparing Ways To Add Threads To Your 3D Prints
• Springs And Things Make For A Unique Timepiece
  
  • Unique Clock Finally Unites Hackers And Sequins

  
  

Quick Hacks:

• Elliot’s Picks
  
  • Avian-Inspired Drones: How Studying Birds Of Prey Brings More Efficient Drones Closer
  • Audio On A Shoestring: DIY Your Own Studio-Grade Mic
  • Second CNC Machine Is Twice As Nice

  
  

• Dan’s Picks:
  
  • Forget The Coax, Wire Up Your Antennas With Cat 6 Cable
  • Procedurally Generated Terrain In OpenSCAD
  • Blinkenlights-First Retrocomputer Design

  
  

Can’t-Miss Articles:

• Before GPS There Was LORAN
• No Ham License? Listen Anyway In Your Browser

hackaday.com/2025/01/17/hackad…

Up first, go check your machines for the rsync version, and your servers for an exposed rsync instance. While there are some security fixes for clients in release 3.4.0, the buffer overflow in the server-side rsync daemon is the definite standout. The disclosure text includes this bit of nightmare fuel: “an attacker only requires anonymous read access to a rsync server, such as a public mirror, to execute arbitrary code on the machine the server is running on.”

A naive search on Shodan shows a whopping 664,955 results for rsync servers on the Internet. Red Hat’s analysis gives us a bit more information. The checksum length is specified by the remote client, and an invalid length isn’t properly rejected by the server. The effect is that an attacker can write up to 48 bytes into the heap beyond the normal checksum buffer space. The particularly dangerous case is also the default: anonymous access for file retrieval. Red Hat has not identified a mitigation beyond blocking access.

If you run servers or forward ports, it’s time to look at ports 873 and 8873 for anything listening. And since that’s not the only problem fixed, it’s really just time to update to rsync 3.4.0 everywhere you can. While there aren’t any reports of this being exploited in the wild, it seems like attempts are inevitable. As rsync is sometimes used in embedded systems and shipped as part of appliances, this particular bug threatens to have quite the long tail.

My Gmail is My Passport, Verify Me

Here’s an interesting question. What happens to those “Log In With Google” accounts that we all have all over the Internet, when the domain changes hands? And no, we’re not talking about gmail.com. We’re talking about myfailedbusiness.biz, or any custom domain that has been integrated with a Google Workspace. The business fails, the domain reverts back to unclaimed, someone else purchases it, and re-adds the admin@myfailedbusiness.biz Google Workspace account. Surely that doesn’t register as the same account for the purpose of Google SSO, right?

The answer to this question is to look at what actually happens when a user uses Google Oauth to log in. The service sends a message to Google, asking Google to identify the user. Google asks the user for confirmation, and if granted will send an ID token to the service. That token contains three fields that are interesting for this purpose. The domain and email are straightforward, and importantly don’t make any distinction between the original and new users. So when the domain and email change hands, so does ownership of the token.

Oauth does provide a sub (subject) field, that is a unique token for a given user/service combination. Seems like that solves the issue, right? The problem is that while that identifier is guaranteed to be unique, it’s not guaranteed to be consistent, and thus isn’t widely used as a persistent user identifier. Google is aware of the issue, and while they initially closed it as a “Won’t fix” issue, the concept did eventually earn [Dylan Ayrey] a nifty $1337 bounty and a promise that Google is working on unspecified fixes. There is no immediate solution, and it’s not entirely clear that this is strictly a Google problem. Other SSO solutions may have the same quirk.

Fortigate Under Attack

Fortiguard has reported that a vulnerability in FortiOS and FortiProxy is under active exploitation. Fortiguard lists quite a few Indicators of Compromise (IoCs), but as far as the nature of the vulnerability, all we know is that it is an authentication bypass in an Node.js websocket module that allows a remote attacker to gain super-admin privileges. Yoiks.

Actic Wolf has more details on the exploit campaign, which was first found back in early December, but appears to have begun with widespread scanning for the vulnerability as early as November 16. Attackers moved slowly, with the goal of establishing VPN access into the networks protected behind the vulnerable devices. Arctic Wolf has provided additional IoCs, so time to go hunting.

Ivanti Connect, Too

There’s another security device under attack this week, as watchTowr labs has yet another fun romp through vendor mis-security. This time it’s a two-part series on Ivanti Connect Secure, and the two buffer overflows being used in the wild.

Ivanti has already released a patch, so the researchers ran a diff on the strings output for the patched and unpatched binary of interest. Three new error messages are in the new version, complaining about client data exceeding a size limit. The diaphora binary diffing tool found some interesting debbuging data, like Too late for IFT_PREAUTH_INIT. “IF-T” turns out to be an open VPN standard, and that term led to a statement about backwards compatibility in Ivanti code that had terrible “code smell”.

The IF-T protocol includes the optional clientCapabilities field, and Ivanti’s implementation used a fixed length buffer to store it when parsing incoming connections. The client code almost gets it right, using a strlen() check on the data, and strncpy() to ensure the right number of bytes are copied. Except both of those best-practices are completely useless when the result from strlen() is fed directly into strncpy() as the maximum byte count, without checking whether it overflows the buffer.

The second watchTowr article goes through the steps of turning the vulnerability into a real exploit, but doesn’t actually give away any exploit code. Which hasn’t really mattered, as Proof of Concepts (PoCs) are now available. The takeaway is that Ivanti still has security problems with their code, and this particular exploit is both fully known, and being used in the wild.

Pentesting Mushrooms

The folks at Silent Signal have an off-the-beaten-path write-up for us: How to get hired as a pentester. Or alternatively, the story of hacking Mushroom Inc. See, they built an intentionally vulnerable web application, and invited potential hires to find flaws. This application included cross-site scripting potential, SQL injection, and bad password handling, among other problems. The test was to take 72 hours, and find and document problems.

Part of the test was to present the findings, categorize each vulnerability’s severity, and even make recommendations for how the fictional business could roll out fixes. Along the way, we get insights on how to get your job application dismissed, and what they’re really looking for in a hire. Useful stuff.

Bits and Bytes

Secure Boot continues to be a bit of a problem. Microsoft signed a UEFI application that in turn doesn’t actually do any of the Secure Boot validation checks. This is only an issue after an attacker has admin access to a machine, but it does completely defeat the point of Secure Boot. Microsoft is finally rolling out fixes, revoking the signature on the application.

And if compromising Windows 11 is of interest to you, HN Security has just wrapped a four-part series that covers finding a vulnerability in an old Windows kernel driver, and turning it into a real read/write exploit that bypasses all of Microsoft’s modern security hardening.

Do you have a website, and are you interested in how your API is getting probed? Want to mess with attackers a bit? You might be interested in the new baitroute tool. Put simply, it’s a honeypot for web APIs.

And finally, the minds behind Top10VPN have released another vulnerability, this time in tunneling protocols like IPIP, GRE, and 6in4. The problem is a lack of validation on incoming tunnel packets. This allows for easy traffic injection, and using the tunnel servers as easy proxies. One of the worst cases is where this flaw allows accessing an internal network protected behind a consumer router.

hackaday.com/2025/01/17/this-w…

Google sta utilizzando attivamente i propri strumenti basati sull’intelligenza artificiale per modernizzare le proprie basi di codice interne. In un recente articolo scientifico, gli specialisti dell’azienda hanno descritto come i modelli linguistici di grandi dimensioni (LLM) abbiano contribuito a ridurre di centinaia di volte i tempi di migrazione del codice su progetti di grandi dimensioni. Questi processi includevano attività complesse come la migrazione a ID a 64 bit in Google Ads, l’aggiornamento da JUnit3 a JUnit4 e la sostituzione di Joda con Java Time.

Il compito di passare agli identificatori a 64 bit ha richiesto più di 500 milioni di righe di codice in decine di migliaia di file. Un’implementazione manuale avrebbe richiesto centinaia di anni-uomo di lavoro e un coordinamento complesso tra i team. Tuttavia, grazie ai sistemi LLM, Google è riuscita a ridurre significativamente la quantità di lavoro manuale. Gli strumenti di intelligenza artificiale hanno apportato automaticamente modifiche, che sono state poi controllate e riviste dagli ingegneri. I dati finali hanno mostrato che l’80% delle modifiche sono state apportate dall’IA e l’87% di esse è stato accettato senza modifiche.

Ci sono voluti solo tre mesi per migrare da JUnit3 a JUnit4. Durante questo periodo sono stati aggiornati 5.359 file e modificate circa 150mila righe di codice. Allo stesso modo, il passaggio da Joda a Java Time ha consentito di risparmiare l’89% del tempo necessario per completare manualmente l’attività.

Gli autori sottolineano che i LLM non solo accelerano la modernizzazione, ma integrano anche i tradizionali metodi di migrazione come l’uso di alberi di sintassi e script di ricerca. Tuttavia, a causa dei costi elevati legati all’elaborazione di grandi quantità di dati, si consiglia di utilizzare l’intelligenza artificiale insieme ad altri strumenti.

Google rileva che l’uso dell’intelligenza artificiale per tali compiti ha già cambiato l’approccio allo sviluppo: la quantità di codice creato utilizzando l’intelligenza artificiale ora supera la quantità di codice scritto manualmente. Ciò dimostra il potenziale significativo della tecnologia per automatizzare compiti complessi nelle grandi aziende.

L'articolo Da centinaia di anni a un paio di mesi: Google Trasforma lo sviluppo del software con i LLM proviene da il blog della sicurezza informatica.

Una vulnerabilità UEFI Secure Boot bypass (CVE-2024-7344) associata a un’applicazione firmata Microsoft può essere utilizzata per installare bootkit nonostante la protezione Secure Boot sia abilitata. L’applicazione UEFI vulnerabile viene utilizzata in diversi strumenti di ripristino del sistema di terze parti.

Il problema è dovuto al fatto che l’applicazione utilizza un bootloader PE personalizzato, che consente di caricare eventuali binari UEFI, anche se non sono firmati. In genere, le applicazioni UEFI si basano su LoadImage e StartImage, che controllano i file binari tramite il database di fiducia (db) e il database di revoca (dbx). Tuttavia, l’applicazione vulnerabile non esegue questa operazione.

In questo contesto, reloader.efi decodifica “manualmente” e carica in memoria i file binari da cloak.dat, che contiene l’immagine PE crittografata XOR. Di conseguenza, un utente malintenzionato può sostituire il bootloader del sistema operativo standard nella partizione EFI con il vulnerabile reloader.efi e inserire il dannoso cloak.dat. All’avvio del sistema, un bootloader personalizzato decodificherà ed eseguirà il file binario dannoso senza controllare il Secure Boot.

È stato segnalato che la vulnerabilità interessa le applicazioni UEFI utilizzate per il ripristino del sistema, la manutenzione del disco e il backup. Come scrivono gli analisti di ESET, i seguenti prodotti sono vulnerabili:

• Howyar SysReturn (prima della versione 10.2.023_20240919);
• Greenware GreenGuard (fino alla versione 10.2.023-20240927);
• Radix SmartRecovery (fino alla versione 11.2.023-20240927);
• Sistema Sanfong EZ-back (fino alla versione 10.3.024-20241127);
• WASAY eRecoveryRX (fino alla versione 8.4.022-20241127);
• CES NeoImpact (fino alla versione 10.1.024-20241127);
• SignalComputer HDD King (fino alla versione 10.3.021-20241127).

Viene sottolineato che anche se questi programmi non sono installati sul computer preso di mira, gli aggressori possono comunque sfruttare CVE-2024-7344 distribuendo separatamente il vulnerabile reloader.efi. Si consiglia agli utenti di questi programmi di aggiornarli alle versioni più recenti il ​​prima possibile.

“Ora sorge la domanda in che misura tali metodi non sicuri siano diffusi tra i produttori di software UEFI di terze parti e quanti altri bootloader strani ma firmati possano esistere”, scrivono gli esperti di ESET. L’azienda ha pubblicato un video che mostra come la vulnerabilità può essere sfruttata anche su un sistema con Secure Boot abilitato.

Il problema è stato scoperto l’8 luglio 2024, dopodiché ESET ha segnalato l’informazione al Centro di coordinamento CERT (CERT/CC). Attualmente, i fornitori di software hanno già rilasciato patch e Microsoft ha revocato i certificati compromessi e corretto CVE-2024-7344 come parte del Patch Tuesday di gennaio.

L'articolo Secure Boot compromesso: vulnerabilità UEFI consente l’installazione di bootkit! proviene da il blog della sicurezza informatica.

Introduction

This report covers the research of the Mercedes-Benz Head Unit, which was made by our team. Mercedes-Benz’s latest Head Unit (infotainment system) is called Mercedes-Benz User Experience (MBUX). We performed analysis of the first generation MBUX.

MBUX was previously analysed by KeenLab. Their report is a good starting point for diving deep into the MBUX internals and understanding the architecture of the system.

In our research we performed detailed analysis of the first generation MBUX subsystems, which are overlooked in the KeenLab research: diagnostics (CAN, UDS, etc.), connections via USB and custom IPC.

This article would not have been possible without the amazing work of Radu Motspan, Kirill Nesterov, Mikhail Evdokimov, Polina Smirnova and Georgy Kiguradze, who conducted the research, discovered the vulnerabilities, and laid the groundwork for this report.

Special thanks to Mercedes-Benz Group AG for their professionalism and prompt handling of all the identified vulnerabilities.

Diagnostic software

To get a first look at the vehicle architecture, it is helpful to use diagnostic software (which is available to certified users only) to scan the Electronic Control Unit (ECU), identify its version, and test the software’s diagnostic functionality. There are several diagnostic tools which make it possible to connect to the vehicle, using various types of communication. In our research, we used a combination of diagnostic tools: a certain hardware interface and a corresponding software application to communicate with the vehicle through the hardware device. This setup allowed us to establish communication over DoIP (Diagnostic Over Internet Protocol):

Communication between diagnostic software and hardware

The TCP communication between the diagnostic tool and the diagnostic hardware device is performed over Ethernet using custom protocols (Protocol Data Unit, PDU). At the first stage, the diagnostic hardware device uses a custom ASCII-based protocol (CSD). It performs user authentication, version check, configuration setup, and provides the initial environment to process the upper layer protocol (PDU).

The upper layer protocol has a binary format. It is used to send Universal Diagnostic Services (UDS) messages, trigger DoIP communication, and so on. To analyze this protocol, we used a script written in LUA:
[pduparser.lua]. Using this script, UDS commands can be easily distinguished from the regular network traffic of communication between the diagnostic software and hardware:

We examined the diagnostic tool interface and decoded the traffic, which allowed us to find various UDS commands, such as for resetting the ECU, turning off the engine, and locking the doors.

Architecture

The architecture of MBUX is as follows:

The main parts of MBUX are:

• MMB (Multi Media Board) — the main part of the head unit (HU) which contains all the subsystems;
• BB (Base Board) — the part with chips for various network communications;
• CSB (Country Specific Board) — the extended part which communicates with the MMB through internal Ethernet;
• RH850 — the module designed to provide communication between low level buses.

Full information on the MBUX architecture can be found in the KeenLab research.

Test setups

For our research we used two test setups:

• a real car — Mercedes B180;

• a testbed — our own platform for hardware and software testing, which we designed for the purpose of this study.

Anti-Theft

While modeling the testbed, we needed to bypass the original anti-theft feature, because after the actual vehicle is started up, the head unit waits for authentication over the CAN bus. As mentioned in the KeenLab research, specific commands should be sent over CAN to wake up the system. We couldn’t imitate this in our setup, so the head unit was entering anti-theft mode and the user couldn’t communicate with it. Taking an empirical approach, we discovered that some CAN messages force the head unit to reset the anti-theft status. In fact, these messages trigger the anti-theft check. For example, when the head unit tries to turn off the display, the CAN message initiates the anti-theft check, leaving the head unit still accessible for a few seconds. For seamless and stable investigation, we created a script that continuously sent this message in a loop.

As a result, the head unit becomes accessible for a long time, switching between an authenticated state and anti-theft mode.

Firmware

The MMB runs on Linux, and its filesystems are located on the eMMC. We needed to extract the eMMC from the printed circuit board by unsoldering it. Inside, there are several partitions:

MMB files can also be downloaded from a diagnostic tool website that provides updates for specific hardware part numbers.

Unpack update

Nowadays multimedia systems in cars are generally updated over-the-air. Car dealerships are one exception, however, as they can perform offline software updates with the diagnostic tool.

Several outdated update files can still be found online. Update file types can be divided into the following groups by their names:

• files with \*ALL\*, containing *.CFF, *.SMR-F and *.bin files;
• files with \*CFF\*, containing only *.CFF files;
• files with \*SMR-F\*, containing only *.SMR-F files.

In general, *.bin files are containers with a custom file structure. They can be encoded with zlib or other methods.

*.SMR-F files are compressed and they also have a custom file structure. Besides metadata in plaintext, they also contain encrypted data, which the diagnostic tool uses its shared libraries to decrypt. After decryption, the resulting file contains the metadata and a container, just like the *.bin files.

*.CFF files contain the same payload content as the *.SMR-F files, but uncompressed. This format was used for earlier head unit generations.

Custom IPC

Inside the head unit, firmware services use custom IPC protocols for communication between their own threads, other services and other ECUs. There are three main widely used protocols:

• thriftme;
• MoCCA;
• GCF.

These protocols can be used at the same time; moreover, each service can use all of them simultaneously. Knowing the internals and API of these protocols, it’s easier to understand the workflow of the services.

thriftme

This RPC protocol is based on the open-source protocol Apache Thrift. Its main distinctive feature is that thriftme allows subscribers to be notified about particular events. The UNIX socket, TCP, UDP, SSL, and so on can be used as a transport for this protocol. The core functionality of this protocol is implemented in the library libthriftme.so.2.7.2.

The base class in the thriftme RPC is “thrift::TServiceBroker”, which isolates the communication with transports and call interfaces of services and clients. In thriftme, the service broker version is the instance of “thrift::lisa::CTLisaServiceBroker”, which inherits from “thrift::TServiceBroker”.

Services in thriftme are inherited from “thrift::lisa::TLisaServerBase” (which, in turn, inherits from “thrift::TServiceProcessor”). Services are registered in the service broker through “thrift::TServiceProcessor::registerService”. Transport used by clients is registered through “thrift::lisa::CTLisaServiceBroker::addServers” (which wraps “thrift::TServiceBroker::addServer”). Service interface functions are registered through “thrift::TServiceProcessor::tmRegisterCallback”. The handler is passed to this export function in arguments, and it is called while processing the client request. So the instance of the service in memory looks as follows:

The “interface1” field contains functions which process the API of the service and their wrappers previously registered through “thrift::TServiceProcessor::tmRegisterCallback”. The “interface2” field contains functions which are called to notify subscribers of this service.

Clients in thriftme are inherited from “thrift::lisa::TLisaClientBase” (which, in turn, inherits from “thrift::TClient”). In fact, client instances are created by the service broker when the transport is successfully created. In our case, the service broker used the factory of a client, which is registered in the service broker through “thrift::TServiceBroker::tmRegCli”. The factory helps clients register handlers for notification about events through “thrift::TClient::tmRegisterCallback”. The sample instance layout of a thriftme client is the following:

The “interface1” field contains the handler is called after transport connection. Usually this handler is used to trigger a subscribe operation to receive event notifications. The “interface2” field contains functions which send requests to the service API. The “interface3” field contains functions which are called before initiating the “notify subscribers” operation of this service. Their wrappers were previously registered through “thrift::TClient::tmRegisterCallback”.

MoCCA

This RPC framework was developed by Harman and is based on the open-source DSI framework. The core functionality is implemented in the “/opt/sys/lib/libSysMoCCAFrameworkSharedSo.so.11” library. This framework is widely used for interthread communication.

During start-up, the service creates component instances through factory functions, for example “CHBApplicationBuilder::theCDiagnosisComponentCreator”. This instance inherits from the class “CHBComponent”. The global variable “CHBComponentInfo::spMap” contains the mapping between additional information about components and their names. The framework allows components to have their own aliases to access another components through “CHBComponentInfo::addComponentMapping”: “CHBComponentInfo::addComponentMapping(&unk_581498, “FsActionHandler”, “FilesystemMainActionHandler”)”. Components can contain multiple services and clients and can communicate with their own services or other component services. The following is the architecture of components:

For communication the following events are used:

An example of a client object is “CTraceServiceClientBase”, which inherits from “CHBClientBase” and uses the proxy object “CTraceServiceProxy” for transport. The proxy object inherits from “CHBProxyBase” and is created through the factory method “CTraceServiceProxy::findOrCreateInstance”. It tries to reuse already created proxy objects inside this component. The general layout of a client object is as follows:

The “IHBEventConsumer” interface is used to process response events in “CTraceServiceClientBase”. The entry point for processing is the “processEvent” method. It uses two values to find a handler, which are called as follows:

• use the “status” field to identify the response: standard response of a service, failed or invalid response;
• use the “internalID” field to identify the API function.

On the service side in our example we used the “CTraceServiceStub” class. Below is its layout:

The request event is processed in the “processEvent” method. It identifies the API function handler using the “internalID” field and calls the identified handler.

GCF

GCF is a custom protocol, which is used for RPC. It allows the services to be registered in the router. The router handles the following messages from services and clients:

• Control message (“CTRL”):
• “REGS” – used to register service;
• “REGF” – used to register RPC function of service;
• “EVNT” – used by service to notify clients about event;
• “CALL” – used by clients to call functionality of service;
• etc.

So during initialization, the services are registered in the router. The internal router table handles the flow of message processing. Finally, clients can send call requests to the router, which trigger predefined functions of registered services. The format of a call request is as follows:
CALL <ServiceName>:<Number> <ServiceCallName> <Params>

Internal network

As mentioned in the KeenLab research, there are some test points on the head unit, which are used by the CSB for connection to the MMB. We removed the default connection and connected the RJ45 cable to access the internal network of the head unit. This connection, labelled as
eth0, has some restrictions, as stated in the corresponding firewall rules in “firewall_prd.policy”:-A INPUT -s [IP]/32 -d [IP]/32 -i eth0 -m state –state NEW -j ACCEPT
-A OUTPUT -s [IP]/32 -d [IP]/32 -o eth0 -j ACCEPT
-A OUTPUT -s [IP]/32 -d [IP]/32 -o eth0 -m state –state NEW -j ACCEPT
Access to services on the MMB is established via an IP address, which is a default address for connecting the CSB to the MMB. The scan results of TCP ports on the MMB are as follows:

After connecting to the test point, we received a huge attack surface and access to the Diagnostic Log and Trace (DLT) subsystem, which is very helpful when testing and debugging:

DLT supports callback injection, which makes it possible to call specific handlers inside services. In the head unit this feature is widely used for product testing.

Identified vulnerabilities

The following findings were used to compromise the testbed. It is necessary for debugging the environment and searching for vulnerabilities in the subsystem that can be exploited in the real car.

CVE-2024-37600 (MoCCA)

The “servicebroker” service is a part of a DSI framework, which is used in MoCCA. This service is used to monitor services and clients.

It sets up HTTP servers using TCP ports. There are several POST commands, which can be processed. One of them is
disconnect, which takes a string as an argument.
The code in the
setup() function tries to parse this command with functions that provide unnecessarily excessive access to memory. According to the disassembled code, it performs read operations using sscanf on a stack buffer. As a result, there can be a stack buffer overflow:

In DLT logs we can identify crashes:

CVE-2023-34404 (GCF)

“MonitorService” is a service which can be accessed over GCF protocol. This service is initialized and started in the “scp” service. The latter, in turn, is a systemd service, which starts with the following configuration:
...

[Service]ExecStart=/opt/comm/swmp/wicome/bin/scp -f /var/opt/swmp/pss_config.cfg -s
wicome_config -r /opt/comm/swmp/wicome/bin -k VerboseLevel=5
ExecStop=/bin/kill $MAINPID
Environment=LD_LIBRARY_PATH=/opt/sys/lib:/opt/comm/swmp/wicome/lib
Environment=LOGNAME=root
EnvironmentFile=/opt/etc/lisa_env
Type=simple
Restart=on-failure
RestartSec=2
WatchdogSec=240
...
“MonitorService” uses the following configuration file “/var/opt/swmp/pss_config.cfg” to fine-tune its operation:
MonitorService.TimestampEnable = 1
MonitorService.ReceiveEnable = 1
MonitorService.MonitoringEnable = 1
MonitorService.MessageBufferSize = 1000
MonitorService.MessageBufferMemory = 512000
#1-file, 2-dlt, 3-both
MonitorService.LogMode = 2
#MonitorService.LogMode = 0
MonitorService.LogFileSize = -1
MonitorService.LogFileName = /tmp/wicom.log
MonitorService.LinefeedEnable = 1
MonitorService.HeaderEnable = 1
MonitorService.FileHeaderEnable = 1
#RH
MonitorService.Port = 2021
The “MonitorService.Port” variable handles the number of the TCP port that will be used by the server. The “MonitorService.ReceiveEnable” variable defines whether the server is able to handle requests from clients. Accordingly, “MonitorService”, containing the head unit configuration, can receive GCF messages from the client and transfer them through the GCF router.

The list of registered services in the GCF router includes “NetworkingService”. It has the following registered handlers:

The “NWS_PF_setMacAddrExceptionIP” handler adds rules to the firewall policy. It uses the following arguments:

• macAddress – MAC address for the rule;
• direction – defines the direction of rule: inbound or outbound;
• fate – defines the type of rule: allow or deny;
• command – the action to be performed: add the rule or remove it from the policy.

The control flow for processing this request is located in the following binaries: “MonitorService”, “libwicome_monitorservice.so” and “libwicode_gcf_core.so”. The call stack is the following:
sub_EE6E8 (NWS_PF_setMacAddrExceptionIP)
sub_E9D0C (sNWS_PF_setMacAddrExceptionIP)
sub_F275C (CGCFStub_PF::setMacAddrExceptionIP)
sub_F7AF4 (CGCFStub_PF::_int_setMacAddrExceptionIP)
snprintf
sub_F7EB4 (systemExec)
system
The
sub_F7AF4 function executes the system() call with arguments to the iptables binary:/* ... */
if ( v10 )
{
v11 = (const char *)PAL::CString::raw(direction);
v12 = (const char *)PAL::CString::raw(mac);
if ( snprintf(v22, 0xFFuLL, "iptables -%s %s -m mac --mac-source %s -j
%s ", (const char *)&v21, v11, v12, v20) < 0 )
{
/* ... */
v18 = 0;
}
if ( v18 )
{
if ( (unsigned __int8)systemExec(a1, v22) != 1 )
{
/* ... */
return 0;
}
}
}
/* ... */
When processing the request, the MAC address is neither checked nor restricted. That means an attacker can perform command injection during the
iptables command execution.

Privilege escalation

The head unit uses the outdated system Polkit, which is vulnerable to CVE-2021-4034. This is a local privilege escalation vulnerability that can result in unprivileged users gaining administrative rights on the target machine. There are a lot of publicly available exploits targeting it, enabling the execution of arbitrary commands as the user “phone” of group “comm”.

After successfully exploiting this vulnerability, an attacker can run commands to modify network interfaces, mount filesystems, and perform other privileged activities. Although some restrictions are imposed, a potential attacker can access the systemd command to further escalate their privileges.

The partition with root filesystem was mounted as a read-only filesystem. As mentioned in the KeenLab research, the head unit doesn’t have any enabled disk integrity protection features. That means the filesystem can be remounted with read and write rights, and the bash scripts that are run during start-up can be modified.

USB

USB is the most popular attack vector in terms of physical access. The head unit is built on a microservice architecture, where each service is rather isolated and communicates through an API. Each microservice of the head unit provides some internal functionality and one or more thriftme services, through which other microservices can communicate with it. This fact enables the emulation of a USB subsystem using QEMU user-mode version.

Preparation

The “DeviceManager” service is responsible for handling USB events: adding, removing, mounting or updating. Other services can subscribe to “DeviceManager” and use notify callbacks to perform actions when USB events occur. For example, such a service can start searching for specific files when the USB filesystem is mounted.

The “GDVariantCodingService” service is a frontend of variant coding. Other services use it to identify the parameters of the head unit and car.

Both of these services should be emulated to run a self-hosted USB subsystem. This task can be performed by emulating corresponding thriftme services. So, for successful emulation, we should perform the following actions:

1. Prepare the network for IP addresses used by services.
2. The services “DeviceManager” and “GDVariantCodingService” use UNIX sockets for transport. To emulate them, it’s easier to use TCP sockets so that we aren’t dependent on the filesystem. Perform forwarding using socat.
3. Run the emulated thriftme services. In our case, we created devicemgr.py, vehicle.py and varcoding.py. In devicemgr.py, the mounting of the USB filesystem is emulated to the path “/opt/sys/bin/aaaaa”.
4. Use QEMU user emulation in a “transparent” fashion.
5. In the chroot environment prepare folders and devices.

The USB subsystem is emulated.

Emulation of data export, import and tracing

The head unit has the functionality to import or export user profile files (seat position, favorite radio stations, etc.) to or from a USB storage. This task is handled by the “UserData” service — to be more precisely, by the thriftme service “CSystemProfileServiceImpl”.

The user profiles backup looks like a folder with the following directory structure:
.
└── MyMercedesBackup
├── shared
├── system
│ ├── rse.ud2
│ └── system.ud2
└── udxprofiles
├── profile0
│ ├── commuterroute.ud2
│ ├── emotions.ud2
│ ├── navidata.ud2
│ ├── pud.ud2
│ ├── uapreds.ud2
│ ├── vt_ab.ud2
│ └── vt_tuner.ud2
└── profileindex.xml
Some of the files are generated by “UserData” itself, but most of them are generated and processed by other services, like “CAPServer”. The most important component of data import and export processes is the thriftme service “UserDataExchangeService” in “UserData”. Services subscribe for notifications about data import and export in UserDataExchangeService.

“CSystemProfileServiceImpl” performs the following workflow when exporting the profiles backup:

1. Run timer for 100 seconds.
2. Notify client services through “UserDataExchangeService” using events that request data export. Such events contain the information about the exported data.
3. Services call API functions that verify the success of the data export. Their arguments are a data key and a path to the file.
4. “UserData” collects all received files, encodes them and stores them in the mounted USB filesystem.

The scheme is similar for the profile backup import:

1. “UserData” copies files from the USB to the local system and decodes them.
2. It notifies client services through events that request data import.
3. If the client service is handling the data key, it imports the data.
4. Services call API functions that verify the success of the data import.

The backup contains XML files and binary files. Binary files are considered more useful for vulnerability hunting:

When triggering backup import (restore) and export (backup), the following scripts were created:
triggerRestore.py and triggerBackup.py.
Almost all the services of the head unit support the trace system
HBTracePersistence, which allows tracing to be turned on and off for a specific module or function.
The “hbtc” file contains the tracing system configuration and determines the function tracing method. An example of the “hbtc” file is provided below:
HBTracePersistence 1.0.0
imp 00 08
imp_userdata_private_CSystemProfileManager ff 08
imp_userdata_private_CUserDataVehicleInformationAdapter ff 08
imp_userdata_private_CUserDataIF2Impl ff 08
imp_common_streamhelper_StreamHelper ff 08
imp_userdata_private_CUDXStructure ff 08
As mentioned previously, files in the backup are encoded — the algorithm is proprietary. The “CPUserDataEncodingHandler” class handles it. The script
ud2codec.py was prepared to be able to encode and decode files.

Identified vulnerabilities

The following vulnerabilities were tested on a real car.

CVE-2024-37601

The process of decoding files with the
*.ud2 extension contains the heap buffer overflow vulnerability.
“UserData” represents encoded data through the “CHBString” object, which processes data as a UTF string. Then the UD2-specific decoding characters should be deleted, and their indexes should remain constant. For this task we used the “CHBString::const_iterator::incrementSteps” function to get the pointer on the desired character and “CHBString::remove” to remove the character from the string. “CHBString::const_iterator::incrementSteps” incorrectly processes the character with code
0xe7: it will be decoded as 1 byte. But according to the table “UTF8LookUpTable”, which is used in “CHBString::remove” and “CHBString::CHBString”, the character with code 0xe7 is encoded with 3 bytes.
As a result, when performing the “CHBString::remove” function, the calculated pointer can be outside of the allocated buffer after UTF decoding with “UTF8LookUpTable”. The memmove function will be called with the third argument (size of buffer) equal to -1.
Without further exploitation by the attacker, this vulnerability triggers the crash of the “UserData” service during data import. This puts the system into a frozen state, which can be fixed only through an ECU hard reset.

CVE-2023-34402

As mentioned previously, the
vt_ab.ud2 file was decoded as vt_ab.xml during the profile backup export for vulnerability searching. This file’s contents resemble a binary and it is processed by the text-to-speech service.
The
vt_ab.xml file contains another file, describing which service will be dropped during processing. For this task it contains the name of the file to drop. This action is performed in the “UserDataExchangeServiceClient::unpackVoiceTagArchiveOptimized” function:

• get the content of the file describing what to drop;
• get the name of the file to drop and perform the dropping.

Because the checks are not being performed, an attacker can control the path which is used to write controllable content. As a result, the attacker can access arbitrary file writing with the same rights the service has.

CVE-2023-34399

After decoding, the
uapreds.ud2 file in the profile folder “MyMercedesBackup/udxprofiles/profile0” takes the form of uapreds.db. The system recognizes it as an SQLite database, which is parsed in the service that uses machine learning for creating efficient routes. The decoded file is processed in “capthrift::CapServer::requestImportBinaryData”, then it calls “capthrift::CapServer::setProfile” to load the database.
All values in the SQLite database tables are serialized as an archive to match the boost library. The format of this archive can be either XML or plain text. We used the plain text mode. Here is an example of an archive in the
learning_kernel row of the kvpair_table table:22 serialization::archive 11 0 2 0 1 0 0 1 0 1 0 0 0 0 1
0.00000000000000000e+00 0 0 0 0 0 0 0 0 1.00000000000000000e+00
...
The last publicly available version of the boost library, 1.81 (at the time of research), contains the integer overflow vulnerability. This vulnerability can be exploited when processing an entity pointer:

In (1), the value
cid was obtained from the attacker-controllable data. After that, in (2), this value is used as an array index to get the cobject_id object. (3.1) and (3.2) introduce restrictions for cid:

• whether the value of cid equals -1;
• whether the value of cid is greater than the size of the cobject_id_vector array.

These restrictions can be bypassed using the assigned value of
cid. This is possible because the definition of class_id_type is assigned an integer:

So if we assign the “–3” value to
cid, then the pointer co.bpis_ptr (2) will be corrupted.
Lastly, the triggered vulnerability in the debugger looks as follows:
Thread 63 hit Breakpoint 2, 0x0000004002f3cea4 in ?? ()
# cid value
(gdb) i r x2
x2 0xfffffffffffffffd -3
# cobject_id_vector size
(gdb) x/1hx $x20 + 0x58
0x405c01b278: 0x000e
# cobject_id_vector pointer
(gdb) x/1gx $x20 + 0x60
0x405c01b280: 0x000000405c017f00
# 1 element in the cobject_id_vector
(gdb) x/3gx *(void **)($x20 + 0x60) + 0 * 0x18
0x405c017f00: 0x000000400147f1c8 0x0000000000000000
0x405c017f10: 0x0000010000000002
# refferenced element
(gdb) x/3gx *(void **)($x20 + 0x60) + -3 * 0x18
0x405c017eb8: 0x5f72696170766b5f 0x00315f656c626174
0x405c017ec8: 0x0000000000000035
(gdb) c
Continuing.

Thread 63 received signal SIGSEGV, Segmentation fault.

Exploitation notes

At the first stage, it is assumed that the image base address is fixed and the vulnerability code is loaded to a specific address in the memory. We analyzed the vulnerability code and checked exactly how all the pointers are dereferenced and where the virtual call is performed. Here are the steps:

• By controlling the id, we can move the pointer (by moving it to negative offsets relative to the beginning of the array in the heap);
• By moving the pointer, we will get to an address where another address containing an object for bis_ptr is located;
• The address for bis_ptr should contain the address of the virtual call table.

Controlling only the offset to the corresponding object, we need to get to the address in the heap which contains a pointer to the pointer with the associated virtual table.

We can implement such a scenario using a spray of DDL entries inside the SQLite database that we can control. For such a spray, we need to create a lot of tables with long names. As a result, structures of a proper format will appear in the heap and a negative index will allow us to get to these structures.

Below is an example of such a SQLite-based file (the entry in
sqlite_schema is a table creation request):

So we can create a lot of tables with long names, which gives us a heap spraying primitive.

Using the heap spraying technique, an attacker can fully control the execution:

To import the
uapreds.db database to the “CAPServer” service, we need to copy it to the service’s working directory. Then “CAPServer” tries to load the database from its own working directory. As a result, if an attacker managed to import the database which triggers the vulnerability in the head unit, then each start-up of “CAPServer” will try to load it and crash. The “CAPServer” service gets started by “systemd” and is configured as follows:
[Service]ExecStart=/opt/prediction/bin/CAPServer /var/opt/prediction/
ExecStop=/bin/kill $MAINPID
Environment=LD_LIBRARY_PATH=/opt/sys/lib
EnvironmentFile=/opt/etc/lisa_env
Type=notify
WatchdogSec=30
Restart=on-failure
RestartSec=2
This means that after the crash, “systemd” will try to restart “CAPServer”. This triggers an infinite loop of service crashes, which can be helpful when trying to brute force the image base address.

Inside SQLite database, there is a pragma section which contains SQL commands to create tables. This feature can be used to create controllable data out of tables in the database based on the current time. The following script can be used to automate the process of creating an SQLite database, which might trigger this vulnerability according to the current time:
#!/bin/bash
DBPATH=test.db
STOP_TIME=$(date --date='-2 hours +10 seconds' +"%H:%M:%S")

echo "Trigger until < $STOP_TIME, clean after >= $STOP_TIME";

poc_value="CRASH the system"
clean_value="system work"

check() {
sqlite3 $DBPATH << EOF
SELECT strftime ('Time of database: %H:%M:%S', 'now');
select * from target_table;
.exit
EOF
}

rm $DBPATH

sqlite3 $DBPATH << EOF
CREATE VIEW target_table AS SELECT "key" AS varkey, "$poc_value" AS varval
WHERE TIME() < "$STOP_TIME" UNION SELECT "key" AS varkey, "$clean_value" AS
varval WHERE TIME() >= "$STOP_TIME";
.exit
EOF

check

sleep 10

check
As a result, an attacker can run image base address brute forcing for some time.

Attack vectors

During our research, we managed to compromise the testbed of the head unit and found several vulnerabilities for a real car via physical access.

The testbed compromise has three potential use cases:

• a criminal wanting to disable the anti-theft protection in a stolen head unit;
• a car owner tuning and unlocking prepaid services on their vehicle;
• a pentester conducting research to find new vulnerabilities.

In the case of a real car, the identified vulnerabilities can be triggered through an exposed USB service that is available to the general user.

Vulnerability list

During the process of vulnerability disclosure with the vendor, the following CVE IDs were assigned:

CVE-2024-37602
CVE-2024-37600
CVE-2024-37603
CVE-2024-37601
CVE-2023-34406
CVE-2023-34397
CVE-2023-34398
CVE-2023-34399
CVE-2023-34400
CVE-2023-34401
CVE-2023-34402
CVE-2023-34403
CVE-2023-34404

The CVE details will be published here: github.com/klsecservices/Advis….

securelist.com/mercedes-benz-h…

Kids love their Power Wheels and other ride-on electric cars. Indeed, [Ashwin]’s son was digging his little ATV, but soon found that some care was needed on the pedal. It had no proper throttle control, instead turning the motor hard on or off and scaring the poor kid in the process. The solution? A bit of an upgrade from some off-the-shelf electronics.

Inspiration came from—where else—the /r/PowerWheelsMods subreddit. The main tweak was to install an off-the-shelf soft-start circuit to stop the motor banging hard on when the accelerator was pushed. Instead, when the accelerator is pushed, the module gradually ramps up its PWM output to the motor to smooth out the acceleration curve. This would make the ATV much easier to ride.

Implementing this off-the-shelf solution did take some doing, though. The first attempt ended with a short circuit and a blown fuse. However, [Ashwin] wasn’t deterred—a trip back online to do some research did the trick. With some careful wiring that took into account the crude forward and reverse circuit, [Ashwin] had a much smoother running ride-on for his son.

While most of the mods we see for these little ride-ons are all about power and speed, we do appreciate the occasional attempt to make the things a bit safer for younger drivers. If you’re brewing up your own fancy kidmobile at home—don’t hesitate to let us know!

hackaday.com/2025/01/17/moddin…

Microsoft ha ampliato i test della protezione dell’amministratore in Windows 11 consentendo agli utenti di Windows Insider di abilitare la funzionalità tramite le Impostazioni di sicurezza di Windows.

Introdotta per la prima volta in ottobre per il canale Canary, la Protezione amministratore utilizza un meccanismo nascosto per l’elevazione temporanea dei diritti e le richieste di autenticazione tramite Windows Hello, consentendo l’accesso ai diritti amministrativi solo quando necessario. La protezione ha lo scopo di impedire l’accesso non autorizzato alle risorse critiche del sistema.

Quando questa funzionalità è abilitata, gli amministratori che hanno effettuato l’accesso dispongono dei diritti utente standard e devono autenticarsi utilizzando Windows Hello (PIN o dati biometrici) quando installano nuove app o apportano modifiche al registro. Le richieste di autenticazione sono più difficili da aggirare rispetto al meccanismo esistente di controllo dell’account utente (UAC), rendendo più difficile la penetrazione di malware e aggressori.
Esempio di finestra delle credenziali con una nuova area colorata (più grande) sopra la descrizione dell’applicazione ( Microsoft)
La funzionalità è disabilitata per impostazione predefinita e può essere abilitata dagli amministratori tramite criteri di gruppo o strumenti di gestione come Intune.

Inoltre, ora gli utenti possono abilitarlo autonomamente tramite le impostazioni di sicurezza di Windows nella sezione Aggiornamento e sicurezza – Sicurezza di Windows – Protezione dell’account. La modifica richiede il riavvio del sistema.

Questa funzionalità è disponibile per i Windows Insider nel canale Canarie che hanno installato Windows 11 Insider Preview Build 27774. Microsoft prevede inoltre di introdurre presto una nuova funzionalità denominata Ripristino rapido sistema, che consente agli amministratori di risolvere in remoto i problemi che rendono inutilizzabili i dispositivi dopo gli aggiornamenti di Windows.

La nuova funzionalità, come molte altre opzioni di sicurezza, funziona come parte della Secure Future Initiative.

L'articolo Basta Privilege Escalation! Microsoft Potenzia Windows 11 contro le LPE proviene da il blog della sicurezza informatica.