Le vulnerabilità rappresentano costantemente un rischio significativo per le aziende e le istituzioni. Molti amministratori di sistema potrebbero ricordare il CVE-2023-34362 dello scorso anno, una vulnerabilità catastrofica in Progress MOVEit Transfer che ha scosso l’industria, colpendo vittime di alto profilo come la BBC e l’FBI.

Dati sensibili sono stati trapelati e distrutti, poiché la banda di ransomware cl0p ha sfruttato vulnerabilità 0day per rubare dati, lasciando infine una scia di caos. Oggi, una nuova minaccia emerge all’orizzonte: la vulnerabilità CVE-2024-5806.

Il passato: CVE-2023-34362

La CVE-2023-34362 (nvd.nist.gov/vuln/detail/CVE-2… ) rappresenta una delle vulnerabilità più critiche che ha colpito Progress MOVEit Transfer, un software ampiamente utilizzato per il trasferimento sicuro dei file. Scoperta e divulgata nel 2023, questa vulnerabilità ha avuto un impatto significativo su diverse organizzazioni di alto profilo, tra cui la BBC e l’FBI.

Descrizione della Vulnerabilità CVE-2023-34362

La CVE-2023-34362 è una vulnerabilità classificata come “Remote Code Execution” (RCE). Questa tipologia di vulnerabilità permette a un attaccante remoto di eseguire codice arbitrario sul sistema bersaglio senza necessità di autenticazione. Nel caso specifico della CVE-2023-34362, la falla risiedeva in una gestione inadeguata delle richieste HTTP da parte del software MOVEit Transfer.

Meccanismo di Sfruttamento CVE-2023-34362

La vulnerabilità poteva essere sfruttata inviando richieste HTTP appositamente create al server MOVEit Transfer. Queste richieste malevole erano in grado di bypassare i controlli di sicurezza e di eseguire comandi arbitrari con i privilegi del processo di esecuzione del server. Questo tipo di attacco poteva essere utilizzato per installare malware, rubare dati, o compromettere ulteriormente la rete interna dell’organizzazione.

Impatto e Danni Causati CVE-2023-34362

L’impatto della CVE-2023-34362 è stato devastante. La vulnerabilità è stata sfruttata dalla gang di ransomware cl0p, che ha utilizzato questa falla per condurre attacchi su vasta scala. Le conseguenze degli attacchi includevano:

1. Furto di Dati Sensibili: Dati altamente sensibili e riservati sono stati sottratti da numerose organizzazioni, tra cui la BBC e l’FBI.
2. Distruzione di Dati: Alcuni dati compromessi sono stati distrutti, causando perdite significative.
3. Interruzione dei Servizi: Le operazioni di molte organizzazioni sono state interrotte, causando disservizi e perdite economiche.

Un nuovo bug di sicurezza su Progress MOVEit Transfer

Recentemente, è stata identificata una nuova vulnerabilità in Progress MOVEit Transfer, classificata come CVE-2024-5806. Questa vulnerabilità è stata etichettata come una debolezza di ‘improper authentication’ (CWE-287).

Si tratta di un problema che consente agli attaccanti di aggirare i meccanismi di autenticazione e ottenere accesso non autorizzato ai dati sensibili. Questo tipo di vulnerabilità è particolarmente preoccupante poiché può essere sfruttata per compromettere gravemente la sicurezza dei dati.

Maggiori dettagli: nvd.nist.gov/vuln/detail/CVE-2…

La Disponibilità di un Proof of Concept (POC) per l’Exploit

Ad aggravare ulteriormente la situazione, è emerso un Exploit Proof of Concept (POC) per il CVE-2024-5806. La disponibilità di un POC significa che gli attaccanti hanno a disposizione un esempio funzionante di come sfruttare la vulnerabilità, aumentando il rischio di attacchi reali.

Il POC può essere utilizzato come base per sviluppare strumenti di attacco più sofisticati e mirati, rendendo la vulnerabilità una minaccia imminente.

Il Rischio di un Nuovo Attacco da Parte di cl0p

Considerando la storia recente, una domanda sorge spontanea: l’attore ransomware cl0p sfrutterà nuovamente questa vulnerabilità?

La gang cl0p, nota per aver utilizzato la vulnerabilità CVE-2023-34362 per attacchi devastanti, potrebbe vedere nella CVE-2024-5806 una nuova opportunità.

Con la loro comprovata esperienza e la disponibilità di un POC, c’è un rischio elevato che cl0p o gruppi simili possano tentare di sfruttare questa nuova falla di sicurezza.

La ransomware gang cl0p

Cl0p è una delle gang di ransomware più temute e sofisticate nel panorama della sicurezza informatica. Questo gruppo criminale è noto per aver condotto attacchi devastanti contro numerose organizzazioni di alto profilo utilizzando tecniche avanzate e vulnerabilità critiche, come la CVE-2023-34362 in Progress MOVEit Transfer.

Cl0p ransomware è ampiamente ritenuto avere origini in Russia o nei paesi dell’ex Unione Sovietica. Le prove indicano che i membri del gruppo parlano russo e operano in fusi orari compatibili con questa regione. Tuttavia, come per molte attività cybercriminali, l’esatta localizzazione geografica dei membri del gruppo può essere difficile da determinare con certezza.

Tecniche, Tattiche e Procedure (TTPs)

Cl0p ransomware gang utilizza un insieme di tecniche, tattiche e procedure altamente sofisticate per condurre i propri attacchi.

Di seguito le principali TTPs associate al gruppo:

1. Exploiting Zero-Day Vulnerabilities: Cl0p è noto per sfruttare vulnerabilità non ancora pubblicamente divulgate (zero-day) per penetrare nei sistemi delle vittime. Un esempio rilevante è la CVE-2023-34362 in Progress MOVEit Transfer.
2. Phishing e Spear-Phishing: Utilizzano campagne di phishing mirate per ottenere accesso iniziale ai sistemi, spesso inviando email che appaiono legittime ma contengono link o allegati malevoli.
3. Lateral Movement: Una volta ottenuto l’accesso a una rete, Cl0p si sposta lateralmente per compromettere ulteriori sistemi, utilizzando strumenti come Mimikatz per estrarre credenziali e guadagnare accesso privilegiato.
4. Data Exfiltration: Prima di criptare i dati, il gruppo esfiltra informazioni sensibili, che utilizza come leva per estorcere ulteriori pagamenti minacciando di pubblicare i dati rubati.
5. Double Extortion: Cl0p pratica l’estorsione doppia, richiedendo un riscatto sia per decriptare i file sia per evitare la pubblicazione dei dati esfiltrati.
6. Ransomware Deployment: Infine, Cl0p distribuisce il ransomware attraverso la rete compromessa, cifrando i file e rendendoli inaccessibili fino al pagamento del riscatto.

Conclusione

La scoperta della vulnerabilità CVE-2024-5806 in Progress MOVEit Transfer rappresenta un serio rischio per la sicurezza delle informazioni aziendali. La presenza di un POC per l’exploit aumenta ulteriormente la minaccia, rendendo cruciale per le organizzazioni adottare misure preventive immediate. La possibilità che il gruppo ransomware cl0p sfrutti questa nuova vulnerabilità non può essere esclusa, rendendo ancora più importante la vigilanza e la preparazione. La sicurezza informatica è una battaglia continua, e solo attraverso la prevenzione e la risposta rapida le aziende possono proteggere i loro asset più preziosi: i dati.

L'articolo Catastrofe Cyber in vista? Il nuovo Bug di Progress MOVEit ha un Exploit PoC Online proviene da il blog della sicurezza informatica.

[Poking Technology] doesn’t think much of his new smartwatch. It is, by his admission, the cheapest possible smartwatch, coming in at about $3. It has very few useful features but he has figured out how to port MicroPython to it, so for a wrist-mounted development board with BLE, it might be useful. You can check it out in the video below.

The first step is a teardown, which reveals surprisingly little on the inside. There’s a tiny battery, a few connections, a display, and a tiny CPU board. There are, luckily, a few test pads that let you get into the CPU. What do you get? A 24 MHz Telink CPU with 512k of flash and 16k of RAM, along with all the other hardware.

Of course, even if you just want a display with some smarts, $3 might be in your price range. The whole thing wound up taped down to a PCB. But the usual debugger didn’t want to connect. Grabbing an oscilloscope revealed that the output from the board had some level problems. He eventually wrote his own debugger interface using a Pi Pico.

He was able to find the onboard CPU’s development tools. The CPU claims to be proprietary but looks suspiciously like a slightly modified ARM. A short investigation shows that the object code is extremely similar to the ARM Thumb instruction set but with a few extra bits set and different mnemonics. But once you put Python on board, who really cares?

The only downside is that it doesn’t appear that the BLE is practically usable because of memory limitations. But there are still places you might use the little watch in a project.

If you want a smartwatch, maybe build your own. While many DIY watches are simple, you can get pretty complicated if you like.

youtube.com/embed/sv58aPvIonw?…

Doubts on the European Commission's claim of an investment gap of at least €174 billion to meet Europe's 2030 connectivity targets have been shed in a document shared with Euractiv by lobby association CCIA Europe, representing Amazon, Google and Meta, among others.

euractiv.com/section/global-eu…

It’s a great joke, and like all great jokes it makes you think. [Søren Fuglede Jørgensen] managed to cram a 15 M parameter large language model into a completely valid TrueType font: llama.ttf. Being an LLM-in-a-font means that it’ll do its magic across applications – in your photo editor as well as in your text editor.

What magic, we hear you ask? Say you have some text, written in some non-AI-enabled font. Highlight that, and swap over to llama.ttf. The first thing it does is to change all “o” characters to “ø”s, just like [Søren]’s parents did with his name. But the real magic comes when you type a length of exclamation points. In any normal font, they’re just exclamation points, but llama.ttf replaces them with the output of the TinyStories LLM, run locally in the font. Switching back to another font reveals them to be exclamation points after all. Bønkers!

This is all made possible by the HarfBuzz font extensions library. In the name of making custom ligatures and other text shaping possible, HarfBuzz allows fonts to contain Web Assembly code and runs it in a virtual machine at rendering time. This gives font designers the flexibility to render various Unicode combinations as unique glyphs, which is useful for languages like Persian. But it can just as well turn all “o”s into “ø”s or run all exclamation points through an LLM.

Something screams mischief about running arbitrary WASM while you type, but we remind you that since PostScript, font rendering engines have been able to run code in order to help with the formatting problem. This ability was inherited by PDF, and has kept malicious PDFs in the top-10 infiltration vectors for the last fifteen years. [Citation needed.] So if you can model a CPU in PDF, why not an LLM in TTF? Or a Pokemon clone in an OpenType font?

We don’t think [Søren] was making a security point here, we think he was just having fun. You can see how much fun in his video demo embedded below.

youtube.com/embed/Q4bOyYctgFI?…

This week Jonathan Bennett and Doc Searls chat with Igor Pecovnik and Ricardo Pardini about Armbian, the Debian-based distro tailor made for single-board computers. There’s more than just Raspberry Pi to talk about, with the crew griping about ancient vendor kernels, the less-than-easy ARM boot process, and more!

youtube.com/embed/y4UXp7Uw0lo?…

– armbian.com/
– github.com/armbian

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

play.libsyn.com/embed/episode/…

Direct Download in DRM-free MP3.

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

Places to follow the FLOSS Weekly Podcast:

• Spotify
• RSS

Meshtastic is a way to build mesh networks using LoRa that is independent of cell towers, hot spots or traditional repeaters. It stands to reason that with an SDR and GNU Radio, you could send and receive Meshtastic messages. That’s exactly what [Josh Conway] built, and you can see a video about the project, Meshtastic_SDR, below. The video is from [cemaxecuter], who puts the library through its paces.

For hardware, the video uses a Canary I as well as the WarDragon software-defined radio kit which is an Airspy R2 and a mini PC running Dragon OS — a Linux distribution aimed at SDR work — in a rugged case. GNU Radio, of course, uses flows which are really just Python modules strung together with a GUI.

The GNU blocks send and receive data via TCP port, so using the radio as a data connection is simple enough. The flow graph itself for the receiver looks daunting, but we have a feeling you won’t change the default very much.

If you’ve wanted to dip your toe into Meshtastic or you want a meaty example of using GNU Radio, this would be a fun project to duplicate and extend. While Meshtastic is generally a mesh protocol, you can set up a node to act as a repeater. You never know when decentralized communications might save the day.

youtube.com/embed/L1VgO1OZWbs?…

If you take public transport in many of the world’s cities, your ticket will be an NFC card which you scan to gain access to the train or bus. These cards are disposable, so whatever technology they use must be astonishingly cheap. It’s one of these which [Ken Shirriff] has turned his microscope upon, a Montreal Métro ticket, and his examination of the MiFare Ultra Light it contains is well worth a read.

The cardboard surface can be stripped away from the card to reveal a plastic layer with a foil tuned circuit antenna. The chip itself is a barely-discernible dot in one corner. For those who like folksy measurements, smaller than a grain of salt. On it is an EEPROM to store its payload data, but perhaps the most interest lies in the support circuitry. As an NFC chip this has a lot of RF circuitry, as well as a charge pump to generate the extra voltages to charge the EEPROM. In both cases the use of switched capacitors plays a part in their construction, in the RF section to vary the load on the reader in order to transmit data.

He does a calculation on the cost of each chip, these are sold by the wafer with each wafer having around 100000 chips, and comes up with a cost-per-chip of about nine cents. Truly cheap as chips!

If NFC technology interests you, we’ve taken a deep dive into their antennas in the past.

The basics of keyboard design are tried and true at this point, but there are still a few aspects yet unconquered. One of them is making your keyboards wireless. You might think it’s easy, but if you just slap a wireless-enabled microcontroller onto your board, you’ll soon be left with a dead battery. Rejoice – [Pete Johanson], creator of ZMK, tells all that you want to know about making your keyboard low-power.

In a lengthy blog post, he goes through everything that a typical keyboard consists of, and points out factor after factor that you never knew could cause a spike in power consumption. Are you using muxes or config options that will force your MCU to always stay alert? Is your voltage regulator’s quiescent current low enough, and can the same be said about other parts you’re using? Does your MCU have to work extra hard transmitting bytes because you’ve put a copper fill under its antenna? Most importantly, is the firmware you’re using designed to optimize power consumption at its core?

If you’ve ever thought about designing low-power keyboards, hell, any low-power device, you seriously should read this post – it will set you at ease by giving you a checklist of things to do, and it also links to quite a few other useful resources, like the ZMK power profiler. Perhaps, if you’re building a wireless keyboard or just creating battery-powered device, you should consider ZMK, as it sure seems to be written with energy efficiency in mind.

Want to learn more about what it takes to build a low-power device? Our 2023 Low-Power Contest attracted a wide range of entrants, and they’ve shared a flurry of methods and tricks you can use to build any sort of battery-juice-sipping gadget.

In a bid to cast the upcoming EU space law in a favourable light, Commission officials pitched it as a competitiveness driver for the continent's industry during the European Space Forum in Brussels.

euractiv.com/section/digital/n…

Have you ever read about something and thought, “Gee whiz! Why did I never think about that?” That was my reaction to reading about a feature commonly associated with Klipper called adaptive bed leveling or adaptive mesh leveling. Too bad I don’t typically use Klipper, but it all worked out, and I’ll show you how it might work for you.

What Is It?

Time to tram your bed!
Once a luxury, most 3D printers now come with some kind of bed level sensor. The idea is that the printer can probe the bed to determine the shape of the build plate and then adjust the build plate accordingly. So if a particular spot on the bed is 0.5 mm too high, the nozzle can rise 0.5 mm when it is in that area. There are several techniques Marlin firmware uses, including what I usually use: UBL. Some people scan the bed once and hope it won’t change much. Others will do a time-consuming scan before each print.

However, adaptive bed leveling is a bit different. The idea is that the printer only probes the area where the part is going to print. If your print bed is 235 mm x 235 mm but your part is 50 mm square, you could just probe the points under the 50 mm square.

This does several things. For a given number of points, there is less motion, so it should be faster. Also, for the same number of points, you will have a much denser mesh and, thus, a better idea of what the bed is at any given point. You could even reduce the number of points based on the size of the part you are printing.

When you think about it, it is a dead simple idea. What’s not to love? For most print jobs, you’ll have less work for the printer, faster prints, and a denser mesh. But how do you do it?

How Do You Do It?

Can you make this work with your printer? Maybe. The trick is you need a way to tell your printer firmware to restrict the mesh area. You also need a way to have the slicer output a bounding box for the part, but that’s usually not hard. If you had to, you could even post process your Gcode and figure that out, but you probably won’t have to.

I
Giving your sensor less distance to travel is a good thing
f you use linear or bilinear leveling, you are in business. That’s because the G29 command for bilinear accepts an L, R, F, and B parameter that lets you set the left, right, front, and back measurements of the probing grid. You can also set the number of probe points with H. Actually, H sets one side of the square, so if H=5, you will probe 25 points in the area.

However, I use UBL, and on one of my printers, I think I’m out of luck without changing something in the firmware. While there is a mesh inset setting, it is set when you build the firmware, so it won’t be practical to change it on the fly.

However, two of my printers are Ender 3 v2 Neo machines. By themselves, they use some odd variant of normal leveling, but I long ago flashed them with the excellent “professional” firmware by [mriscoc]. This is Marlin configured for these machines and — at least the version I use — has UBL set. But, there’s a catch.

The firmware has some custom Gcodes that start with C. C29 sets the mesh size and location very much like other versions. For some reason, it also sets the temperature. Here’s the documentation:

C29 Ln Rn Fn Bn Tn Nn Xn Ym : set probing mesh inset (Left, Right, Front, Back) in mm. T is the probing temperature (T0 doesn’t change the current bed temperature) and N is the density or amount of grid points NxN, it is posible to set a NxM density by using X and Y. In UBL use G29 S# to save to a mesh slot number #.

Try It!

Just as an experiment, I sent the following to the printer via a terminal:
C29 L100 R150 F100 B150 T0 N5
Nothing happened. But when I performed a G29 P1 to probe the bed, it obeyed the new restriction. All that was left was to make the slicer output the correct startup code. Of course, if you are using bilinear levelling, you’ll use G29 instead and have to change a few of the arguments.

Engage Start Up Sequence

Most slicers allow you to put placeholder variables in your Gcode scripts. You may have to look it up for your slicer. There are also plugins that can do the work, but you’d need to change their G29 to C29 (in my case). I mostly use SuperSlicer, which is forked from PrusaSlicer, which is forked from Slic3r.

Here’s part of my startup code:
G28 ; home all
C29 L{first_layer_print_min[0]} R{min(190,first_layer_print_max[0])} F{first_layer_print_min[1]} B{min(180,first_layer_print_max[1])} T0 N5
G29 P1 ; probe
G29 A ; activate (may not be needed?)
G29 F2 ; Fade height 2mm (or whatever you want)
That’s it. If you have a line that purges your nozzle, you might want to correct it using similar logic or just add a few skirt loops in the slicer and forget about it. Note that I probe 25 points, which might be a bit much for a small part. It would be nice to write a script to detect how big a part is and adjust things. Note that Prusa has enough power to do this totally in the start code, but it would be different in Slic3r or Cura. If you look around, there are a few different examples of doing this for both slicers and various firmware that you will — no doubt — have to adapt to your circumstances.

I need to crack into the firmware for my other printer to see if a similar C command is feasible to add. But that’s for another day, especially since the C29 command is provided as object code only, so I’ll have to start from scratch. Luckily, I’m used to building (and rebuilding) Marlin for all the machines, especially that one, since it is a custom blend of many parts. I may switch out to bilinear leveling. Or, I could break down and go to Klipper, I suppose.

We want to try fast scanning next. Of course, things are simple if you tram your flat bed once and forget it. That is until something changes.

Recentemente è emerso un allarme nel mondo della sicurezza informatica: un attore malintenzionato ha annunciato la vendita di una vulnerabilità 0-Day di tipo Use After Free (UAF) nel kernel Linux su un noto forum del dark web. Questa vulnerabilità, se sfruttata, permetterebbe l’esecuzione di codice con privilegi elevati, rappresentando una seria minaccia per i sistemi affetti.

Dettagli della Vulnerabilità

Il post dell’attore malintenzionato specifica che la vulnerabilità riguarda la versione 6.6.15-amd64 del kernel Linux. Le vulnerabilità 0-Day UAF si verificano quando la memoria precedentemente liberata viene successivamente utilizzata, permettendo ad un attaccante di eseguire codice arbitrario con privilegi elevati (Local Privilege Escalation), bypassando le normali misure di sicurezza del sistema operativo​.

Modalità di Vendita

Nell’annuncio affermano: “selling 0day Use-after free in the Linux Kernel, you can use it to do a Privileged Code Execution ( LPE (Local Privilege Escalation), or execute code with root privileges ), ( Data Leakage)..etc”

L’annuncio include anche il prezzo per l’acquisto della vulnerabilità, fissato a 150.000 USD. I pagamenti accettati sono esclusivamente in criptovalute, specificamente Monero (XMR) o Bitcoin (BTC). L’uso di criptovalute è probabilmente scelto per garantire l’anonimato delle transazioni.

Immagine del post rinvenuto nel darkweb

Intermediario

Nel post, viene menzionato un altro attore malintenzionato, noto con l’alias IntelBroker, che agisce come intermediario e dunque ne facilita la transazione. L’uso di un intermediario può servire a garantire una certa trasparenza e fiducia tra le parti coinvolte, sebbene operino comunque nell’anonimato.

La vendita di vulnerabilità 0-Day rappresenta una minaccia significativa per la sicurezza informatica globale. Gli amministratori di sistema e i professionisti della sicurezza devono essere costantemente vigili e pronti ad applicare patch di sicurezza non appena queste diventano disponibili. La comunità di sicurezza deve inoltre collaborare per identificare e mitigare tali minacce il più rapidamente possibile.

Conclusioni

La scoperta di questa vendita di una vulnerabilità 0-Day nel kernel Linux sottolinea ancora una volta l’importanza della sicurezza informatica e la necessità di rimanere vigili contro le minacce emergenti. La comunità tecnologica deve continuare a investire in misure di sicurezza preventive e reattive per proteggere i sistemi e i dati sensibili da attacchi sempre più sofisticati.

L'articolo 150.000 dollari. Il costo di uno 0-Day UAF nel Kernel Linux sul Dark Web proviene da il blog della sicurezza informatica.

Another alarming discovery in the cyber-security landscape shakes the internet. A threat actor put on sale (on BreachForum) a dangerous 0-day vulnerability affecting the Google Chrome browser. This flaw, named “Sandbox RCE”, allows for arbitrary code execution with high privileges, exposing vulnerable systems to an elavated risk.

VULNERABILITY DETAILS

The advertisement specifies that the vulnerability has been tested on two distincts Chrome versions (126.0.6478.128 and 126.0.6478.127) and the targets Windows OS systems (version 21H1 e 21H2). A RCE is a critical vulnerability that permits a bad actor to execute malicious code on a target device remotely, without the victim’s knowledge. The threat is amplified because it bypass the browser’s sandbox, an enviroment designed to isolate browser’s processes from accessing the OS.

PAYMENT METHODS

In the sale announcement the seller states “Selling Chome Sandbox Escape RCE in chrome”, including the price fixed at 1.000.000 USD. The only payment methods allowed are Monero (XMR) or Bitcoin (BTC), cryptocurrency use grant anonymous payments. The elevated cost suggests thatan highly reliable and powerful exploit.

THE MIDDLE MAN

A well-known threat actor called IntelBroker would act as middleman making easy the payment and exploit delivery. Moreover a middleman should provide trust and transparency incentivizing the purchase. This specific couple of buyre and middle-man are the same that provided another advertisment for a Linux Kernel 0-day a few days ago.

SECURITY MEASURES

0-day vulnerabilities define the biggest threat in the digital space, this flaw are unknown to the product supplier and the patch cannot be developed until a proof of the vulnerability gets uncovered. In the context of the Chrome Browser’s Sandbox the potential bypass of the safeguars and the possibility of execute code at OS level expose systems to an high risk. Every user and company should implement available security measures to protect their system. Sharing and collaboration of information inside the infosec community are essential to face dangerous threat like 0-days in an efficient way.

CONCLUSION

Chrome is the most used web browser in the world, with a market share >60%. This means the potential victims range is really wide. Regular updates, security softwareand common sense are required to avoid to be caught by this exploit. Regardless all the mitigation measures active in systems we must remember the zero risk doesn’t exist.

L'articolo 0-day SandBox RCE in Google Chrome on Sale! proviene da il blog della sicurezza informatica.

Negli ultimi mesi, la comunità della sicurezza informatica ha scoperto un nuovo worm noto come P2PInfect che ha iniziato a prendere di mira i server Redis vulnerabili. Questo malware non solo si diffonde rapidamente attraverso una rete peer-to-peer, ma sfrutta anche una vulnerabilità critica per stabilire un controllo persistente sui sistemi infetti. Il worm rappresenta una minaccia significativa sia per i server Linux che Windows, e il suo comportamento sofisticato richiede attenzione immediata da parte degli amministratori di sistema per prevenire possibili compromissioni. Ecco una panoramica dettagliata di come opera P2PInfect e le misure necessarie per mitigare questa minaccia.

Caratteristiche del Worm P2PInfect

P2PInfect è scritto in Rust, un linguaggio che facilita la sua operatività su piattaforme sia Windows che Linux. Il malware sfrutta una vulnerabilità di sandbox escape di Lua (CVE-2022-0543), che consente l’esecuzione di codice remoto sui server Redis vulnerabili. La sua capacità di replicarsi in un ambiente distribuito gli permette di creare una rete peer-to-peer (P2P), eliminando la necessità di un server di controllo centralizzato e rendendo più complesso il tracciamento e l’interruzione delle sue attività​ (SecurityWeek)​​ (SOCRadar® Cyber Intelligence Inc.)​.

Dettagli sulla CVE-2022-0543

CVE-2022-0543 è una vulnerabilità critica che affligge Redis, un database in-memory molto popolare. Questa vulnerabilità è una “sandbox escape” che consente agli attaccanti di eseguire codice arbitrario sul server vulnerabile.

Descrizione della Vulnerabilità

La CVE-2022-0543 è causata da un difetto nella gestione del codice Lua all’interno di Redis. Lua è un linguaggio di scripting leggero utilizzato in Redis per estendere le funzionalità del database. La vulnerabilità si verifica quando un attaccante può sfruttare la sandbox Lua per eseguire comandi non autorizzati sul sistema host. Questo exploit permette l’esecuzione di comandi con i privilegi dell’utente Redis, che spesso è configurato con diritti elevati sul server.

Meccanismo di Attacco

1. Inserimento di Codice Maligno: L’attaccante inserisce un payload Lua dannoso nel database Redis.
2. Esecuzione del Payload: Il payload viene eseguito all’interno del contesto della sandbox Lua, ma a causa della vulnerabilità, riesce a superare le restrizioni della sandbox.
3. Esecuzione di Codice Arbitrario: Una volta evasa la sandbox, l’attaccante può eseguire comandi arbitrari sul server, compreso il download e l’esecuzione di ulteriori malware o la manipolazione dei dati memorizzati.

Impatti

Questa vulnerabilità consente agli attaccanti di prendere il controllo completo del server Redis compromesso, eseguendo qualsiasi comando con i privilegi dell’utente Redis. Questo potrebbe portare a:

• Furto di dati: Accesso non autorizzato e esfiltrazione dei dati memorizzati.
• Compromissione del sistema: Installazione di backdoor, rootkit o altri tipi di malware.
• Interruzione del servizio: Manipolazione o cancellazione dei dati, causando disservizi.

Modalità di Attacco e Persistenza

Una volta compromesso un server Redis, P2PInfect carica un file oggetto condiviso dannoso per ottenere l’accesso alla shell inversa, mantenendo la funzionalità normale del server per evitare sospetti. Il worm utilizza varie tecniche per mantenere il controllo, inclusi aggiornamenti dinamici della configurazione in memoria e meccanismi di persistenza cron per riattivare il payload principale ogni 30 minuti. Inoltre, il malware può sovrascrivere le chiavi SSH autorizzate per prevenire l’accesso legittimo e, se ottiene l’accesso root, modifica le password degli utenti per bloccarli fuori dal sistema​ (SOCRadar® Cyber Intelligence Inc.)​​ (Heimdal Security)​.

Cosa sono i Server Redis

Redis (REmote DIctionary Server) è un database in-memory open source utilizzato come database, cache e broker di messaggi. È noto per le sue alte prestazioni e la sua versatilità, essendo capace di gestire una varietà di strutture dati come stringhe, hash, liste, set e sorted set.

Caratteristiche Principali di Redis

1. In-Memory Storage: Redis memorizza i dati interamente in memoria, il che permette una velocità di accesso estremamente rapida.
2. Strutture Dati Avanzate: Supporta vari tipi di dati avanzati come liste, set, hash, bitmap, e HyperLogLog, tra gli altri.
3. Persistenza: Redis può essere configurato per salvare periodicamente i dati su disco, garantendo la persistenza dei dati anche dopo riavvii del server.
4. Replica e Alta Disponibilità: Supporta la replica dei dati su più nodi, creando configurazioni master-slave per alta disponibilità e failover automatico.
5. Supporto per Script Lua: Redis permette l’esecuzione di script Lua per estendere le sue funzionalità e ottimizzare operazioni complesse direttamente all’interno del database.

Utilizzi Comuni di Redis

• Cache: Utilizzato per memorizzare temporaneamente dati che devono essere rapidamente accessibili.
• Database NoSQL: Utilizzato come database NoSQL per applicazioni che richiedono alte prestazioni.
• Broker di Messaggi: Utilizzato per implementare code di messaggi tra diversi componenti di un’applicazione.
• Session Store: Utilizzato per memorizzare sessioni utente in applicazioni web ad alta scalabilità.

Redis è ampiamente adottato in molti settori grazie alle sue prestazioni elevate e alla sua capacità di scalare orizzontalmente, supportando un gran numero di connessioni simultanee e operazioni al secondo.

Diffusione e Attività Recenti

A partire da agosto 2023, l’attività del botnet P2PInfect ha subito un notevole incremento, con tentativi di accesso iniziale che sono aumentati di 600 volte in settembre. Questo aumento dell’attività è stato accompagnato dall’emergere di nuove varianti del malware, suggerendo un continuo sviluppo da parte degli autori del worm. Le regioni più colpite includono Cina, Stati Uniti, Germania, Singapore, Hong Kong, Regno Unito e Giappone​ (SecurityWeek)​​ (SOCRadar® Cyber Intelligence Inc.)​.

Finalità e Potenziali Rischi

Gli obiettivi finali dei gestori di P2PInfect non sono ancora chiari. Sebbene il worm abbia tentato di scaricare payload per il cryptomining, non è stata rilevata attività di mining effettiva sui dispositivi compromessi. Questo potrebbe indicare che gli operatori stanno ancora testando le fasi finali dell’attacco o che stanno cercando di vendere l’accesso alla rete infetta ad altri cybercriminali​ (SOCRadar® Cyber Intelligence Inc.)​​ (Heimdal Security)​.

Misure di Sicurezza

Per proteggersi da P2PInfect, è essenziale che gli amministratori di server Redis aggiornino le loro istanze con le ultime patch di sicurezza e configurino adeguatamente i firewall per limitare l’accesso ai porti critici. Monitorare costantemente le attività di rete e implementare misure di rilevamento delle intrusioni può aiutare a identificare e mitigare tempestivamente le minacce​ (SecurityWeek)​​ (Heimdal Security)​.

Conclusione

La vulnerabilità CVE-2022-0543 rappresenta una seria minaccia per i server Redis non configurati correttamente o non aggiornati. Sfruttando questa falla, gli attaccanti possono eseguire codice arbitrario e prendere il controllo dei server vulnerabili. Redis, d’altro canto, rimane uno strumento potente e versatile per la gestione dei dati in memoria, essenziale per molte applicazioni moderne. È cruciale che gli amministratori mantengano i loro sistemi aggiornati e seguano le migliori pratiche di sicurezza per mitigare i rischi associati a queste vulnerabilità.

L'articolo P2PInfect: La Nuova Minaccia per i Server Redis proviene da il blog della sicurezza informatica.

Bug reporting doesn’t usually have a lot of visuals. Not so with the visionOS bug [Ryan Pickren] found, which fills a user’s area with screeching bats after visiting a malicious website. Even better, closing the browser doesn’t get rid of them! Better still? Doesn’t need to be bats, it could be spiders. Fun!

The bug has been fixed, but here’s how it worked: the Safari browser build for visionOS allowed a malicious website to fill the user’s 3D space with animated objects without interaction or permission. The code to trigger this is remarkably succinct, and is actually a new twist on an old feature: Apple AR Quick Look, an HTML-based feature for rendering 3D augmented reality content in Safari.
How about spiders, instead?
Leveraging this old feature is what lets an untrusted website launch an arbitrary number of animated 3D objects — complete with sound — into a user’s virtual space without any interaction from the user whatsoever. The icing on the cake is that Quick Look is a separate process, so closing Safari doesn’t get rid of the pests.

Providing immersive 3D via a web browser is a valuable way to deliver interactive content on both desktops and VR headsets; a good example is the fantastic virtual BBC Micro which uses WebXR. But on the Apple Vision Pro the user is always involved and there are privacy boundaries that corral such content. Things being launched into a user’s space in an interaction-free way is certainly not intended behavior.

The final interesting bit about this bug (or loophole) was that in a way, it defied easy classification and highlights a new sort of issue. While it seems obvious from a user experience and interface perspective that a random website spawning screeching crawlies into one’s personal space is not ideal, is this a denial-of-service issue? A privilege escalation that technically isn’t? It’s certainly unexpected behavior, but that doesn’t really capture the potential psychological impact such bugs can have. Perhaps the invasion of personal space and user boundaries will become a quantifiable aspect of bugs in these new platforms. What fun.

Dopo dodici anni di calvario, di cui gli ultimi cinque in un carcere di massima sicurezza inglese in attesa di giudizio, Julian assange, giornalista, è libero. Nessuno potrà restituirgli gli anni perduti, ma nessuno potrà mai restituire un briciolo di dignità ai suoi persecutori e ai loro sottopanza.

spreaker.com/episode/dk-8x31-a…

For Europe and the world to meet their emission reduction targets, SMEs must be placed at the forefront and be supported to better measure their sustainability impacts.

euractiv.com/section/digital/o…

Un’allarmante scoperta nel panorama della cyber-sicurezza scuote le fondamenta del web: un hacker ha messo in vendita, su un rinomato forum del dark web, una pericolosa vulnerabilità zero-day che colpisce il browser Chrome. Questa falla, denominata “Sandbox RCE”, apre la porta all’esecuzione di codice con privilegi elevati, esponendo i sistemi vulnerabili a un rischio elevato.

Dettagli vulnerabilità

L’annuncio specifica che la vulnerabilità è stata testata su due indirizzi IP specifici: 126.0.6478.128, 126.0.6478.127, e il sistema operativo compatibile, ossia Windows (Versioni: 21H1 e 21H2).

Un’ RCE (Remote Code Execution) zero-day nel browser Chrome è una vulnerabilità critica che permette a un malintenzionato di eseguire codice dannoso sul dispositivo dell’utente senza che questi ne sia consapevole. La gravità di questa minaccia è amplificata dal fatto che avviene all’interno della sandbox del browser, un ambiente progettato per isolare i processi web e impedire loro di accedere al sistema operativo o ad altri dati sensibili.

Modalità di vendita

Nell’annuncio affermano: “Selling Chome Sandbox Escape RCE in chrome”

L’annuncio include anche il prezzo per l’acquisto della vulnerabilità, fissato a 1.000.000 USD. I pagamenti accettati sono esclusivamente in criptovalute, specificamente Monero (XMR) o Bitcoin (BTC). L’uso di criptovalute è probabilmente scelto per garantire l’anonimato delle transazioni. Il costo così elevato suggerisce che si tratti di un exploit potente.

Immagine del post rinvenuto nel darkweb

Intermediario

Oltre agli attori già noti, il post menziona un altro soggetto malintenzionato, denominato IntelBroker. Questo broker funge da intermediario, facilitando la transizione tra le parti coinvolte. L’utilizzo di un intermediario può introdurre un elemento di trasparenza e fiducia nello scambio, pur se le parti rimangono anonime.

Misure di sicurezza

Le vulnerabilità zero-day rappresentano una delle minacce informatiche più gravi, in quanto si tratta di falle software sconosciute al fornitore e per le quali non è ancora disponibile una patch. Nel contesto del browser Chrome, una vulnerabilità RCE (Remote Code Execution) zero-day nella sandbox rappresenta un particolare pericolo, in quanto permette di superare le protezioni implementate per isolare i processi web e di eseguire codice arbitrario sul dispositivo dell’utente.

È fondamentale che tutti gli attori coinvolti, dagli individui alle organizzazioni, adottino le misure necessarie per mitigare i rischi e proteggere i propri sistemi. La collaborazione e la condivisione delle informazioni all’interno della comunità di sicurezza sono essenziali per affrontare questa minaccia in modo efficace.

Conclusioni

Chrome è il browser web più utilizzato al mondo, con una quota di mercato superiore al 60%. Ciò significa che un’enorme quantità di utenti è potenzialmente a rischio di essere colpita da questa vulnerabilità. Adottare le opportune precauzioni, come aggiornare regolarmente il software, utilizzare un software di sicurezza e mantenere un sano senso critico, può aiutare a ridurre il rischio di cadere vittima di tali attacchi. Tuttavia, è importante essere consapevoli che il rischio zero non esiste.

L'articolo In vendita una RCE Zeroday Sandbox per il browser Chrome per un Milione di Dollari proviene da il blog della sicurezza informatica.