Last Friday Github saw a supply chain attack hidden in a popular Github Action. To understand this, we have to quickly cover Continuous Integration (CI) and Github Actions. CI essentially means automatic builds of a project. Time to make a release? CI run. A commit was pushed? CI run. For some projects, even pull requests trigger a CI run. It’s particularly handy when the project has a test suite that can be run inside the CI process.

Doing automated builds may sound straightforward, but the process includes checking out code, installing build dependencies, doing a build, determining if the build succeeded, and then uploading the results somewhere useful. Sometimes this even includes making commits to the repo itself, to increment a version number for instance. For each step there are different approaches and interesting quirks for every project. Github handles this by maintaining a marketplace of “actions”, many of which are community maintained. Those are reusable code snippets that handle many CI processes with just a few options.

One other element to understand is “secrets”. If a project release process ends with uploading to an AWS store, the process needs an access key. Github stores those secrets securely, and makes them available in Github Actions. Between the ability to make changes to the project itself, and the potential for leaking secrets, it suddenly becomes clear why it’s very important not to let untrusted code run inside the context of a Github Action.

And this brings us to what happened last Friday. One of those community maintained actions, tj-actions/changed-files, was modified to pull an obfuscated Python script and run it. That code dumps the memory of the Github runner process, looks for anything there tagged with isSecret, and writes those values out to the log. The log, that coincidentally, is world readable for public repositories, so printing secrets to the log exposes them for anyone that knows where to look.

Researchers at StepSecurity have been covering this, and have a simple search string to use: org:changeme tj-actions/changed-files Action. That just looks for any mention of the compromised action. It’s unclear whether the compromised action was embedded in any other popular actions. The recommendation is to search recent Github Action logs for any mention of changed-files, and start rotating secrets if present.

Linux Supply Chain Research

The folks at Fenrisk were also thinking about supply chain attacks recently, but specifically in how Linux distributions are packaged. They did find a quartet of issues in Fedora’s Pagure web application, which is used for source code management for Fedora packages. The most severe of them is an argument injection in the logging function, allowing for arbitrary file write.

The identifier option is intended to set the branchname for a request, but it can be hijacked in a request, injecting the output flag: [url=http://pagure.local/test/history/README.md?identifier=--output=/tmp/foo.bar]http://pagure.local/test/history/README.md?identifier=--output=/tmp/foo.bar[/url]. That bit of redirection will output the Git history to the file specified. Git history consists of a git hash, and then the short commit message. That commit message has very little in the way of character scrubbing, so Bash booleans like || can be used to smuggle a command in. Add the cooked commit to your local branch of something, query the URL to write the file history to your .bashrc file, and then attempt to SSH in to the Pagure service. The server does the right thing with the SSH connection, refusing to give the user a shell, but not before executing the code dropped into the .bashrc file. This one was disclosed in April 2024, and was fixed within hours of disclosure by Red Hat.

Pagure was not the only target, and Fenrisk researchers also discovered a critical vulnerability in OpenSUSE’s Open Build Service. It’s actually similar to the Fedora Pagure issue. Command options can be injected into the wget command used to download the package source file. The --output-document argument can be used to write arbitrary data to a file in the user’s home directory, but there isn’t an obvious path to executing that file. There are likely several ways this could be accomplished, but the one chosen for this Proof of Concept (PoC) was writing a .proverc file in the home directory. Then a second wget argument is injected, using --use-askpass to trigger the prove binary. It loads from the local rc file, and we have arbitrary shell code execution. The OpenSUSE team had fixes available and rolled out within a few days of the private disclosure back in June of 2024.

Breaking Ransomware Encryption

What do you do when company data is hit with Akira ransomware, and the backups were found wanting? If you’re [Yohanes Nugroho], apparently you roll up your sleeves and get to work. This particular strain of Akira has a weakness that made decryption and recovery seemingly easy. The encryption key was seeded by the current system time, and [Yohanes] had both system logs and file modification timestamps to work with. That’s the danger of using timestamps for random seeds. If you know the timestamp, the pseudorandom sequence can be derived.

It turns out, it wasn’t quite that easy. This strain of Akira actually used four separate nanosecond scale time values in determining the per-file encryption key. Values we’ll call t3 and t4 are used to seed the encryption used for the first eight bytes of each file. If there’s any hope of decrypting these files, those two values will have to be found first. Through decompiling the malware binaries, [Yohanes] knew that the malware process would start execution, then run a fixed amount of code to generate the t3 key, and a fixed amount of code before generating the t4 key. In an ideal world, that fixed code would take a fixed amount of time to run, but multi-core machines, running multi-threaded operations on real hardware will introduce variations in that timing.

The real-world result is a range of possible time offsets for both those values. Each timestamp from the log results in about 4.5 quadrillion timestamp pairs. Because the timing is more known, once t3 and t4 are discovered, finding t1 and t2 is much quicker. There are some fun optimizations that can be done, like generating a timestamp to pseudorandom value lookup table. It works well ported to CUDA, running on an RTX 4090. In the end, brute-forcing a 10 second slice of timestamps cost about $1300 dollars when renting GPUs through a service like vast.ai. The source code that made this possible isn’t pretty, but [Yohanes] has made it all available if you want to attempt the same trick.

Github and Ruby-SAML — The Rest of the Story

Last week we briefly talked about Github’s discovery of the multiple parser problem in Ruby-SAML, leading to authentication bypass. Researchers at Portswigger were also working on this vulnerability, and have their report out with more details. One of those details is that while Github had already moved away from using this library, Gitlab Enterprise had not. This was a real vulnerability on Gitlab installs, and if your install is old enough, maybe it still is.

The key here is a CDATA section wrapped in an XML comment section is only seen by one of the parsers. Include two separate assertion blocks, and you get to drive right through the difference between the two parsers.

Paragon

There’s a new player in the realm of legal malware. Paragon has reportedly targeted about 90 WhatsApp users with a zero-click exploit, using a malicious PDF attachment to compromise Android devices. WhatsApp has mitigated this particular vulnerability on the server side.

It’s interesting that apparently there’s something about the process of adding the target user to the WhatsApp group that was important to making the attack work. Paragon shares some similarities with NSO Group, but maintains that it’s being more careful about who those services are being offered to.

Bits and Bytes

We have a pair of local privilege escalation attacks. This is useful when an attacker has unprivileged access to a machine, but can use already installed software to get further access. The first is Google’s Web Designer, that starts a debug port, and exposes an account token and file read/right to the local system. The other is missing quotation marks in Plantronics Hub, which leads to the application attempting to execute C:\Program.exe before it descends into Program Files to look for the proper location.

This is your reminder, from Domain Guard, to clean up your DNS records. I’ve now gone through multiple IP address changes of my “static” IP Addresses. At the current rate of IPv4 exhaustion, those IPs are essentially guaranteed to be given out to somebody else. Is it a problem to have dangling DNS records? It’s definitely not a good situation, because it enables hacks from cross-site scripting vulnerabilities, to cookie stealing, to potentially defeating domain verification schemes with the errant subdomain.

MacOS has quite a fine history of null-pointer dereference vulnerabilities. That’s when a pointer is still set to NULL, or 0, and the program errantly tries to access that memory location. It used to be that a clever attacker could actually claim memory location 0, and take advantage of the bogus dereference. But MacOS put an end to that technique in a couple different ways, the most effective being disallowing 32 bit processes altogether in recent releases. It seems that arbitrary code execution on MacOS as result of a NULL Pointer Dereference is a thing of the past. And yes, we’re quite aware that this statement means that somehow, someone will figure out a way to make it happen.

And Finally, watchTowr is back with their delightful blend of humor and security research. This time it’s a chain of vulnerabilities leading to an RCE in Kentico, a proprietary web Content Management System. This vulnerability has one of my least favorite data formats, SOAP XML. It turns out Kentico’s user authentication returns an empty string instead of a password hash when dealing with an invalid username. And that means you can craft a SOAP authenticaiton token with nothing more than a valid nonce and timestamp. Whoops. The issue was fixed in a mere six days, so good on Kentico for that.

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

[Mikey Sklar] had a problem—namely, running low on the brass material typically used for making PCB stencils. Thankfully, a replacement material was not hard to find. It turns out you can use aluminum business card blanks to make viable PCB stencils.

Why business card blanks? They’re cheap, for a start—maybe 15 cents each in quantity. They’re also the right thickness, at just 0.8 mm, and they’re flat, unlike rolled materials that can tend to flip up when you’re trying to spread paste. They’re only good for small PCBs, of course, but for many applications, they’ll do just fine.

To cut these, you’ll probably want a laser cutter. [Mikey] was duly equipped in that regard already, which helped. Using a 20 watt fiber laser at a power of 80%, he was able to get nice accurate cuts for the stencils. Thanks to the small size of the PCBs in question, the stencils for three PCBs could be crammed on to a single card.

If you’re not happy with your existing PCB stencil material, you might like to try these aluminium blanks on for size. We’ve covered other stenciling topics before, too.

youtube.com/embed/vPO3uMIyp_U?…

hackaday.com/2025/03/21/alumin…

Negli ultimi anni, sempre più persone ricevono telefonate da numeri sconosciuti in cui, al momento della risposta, nessuno parla. In alcuni casi si tratta di errori tecnici o chiamate perse da call center, ma in altri può essere il segnale di un’attività ben più subdola: la verifica della validità del numero per futuri tentativi di truffa o attacchi informatici. In questo articolo approfondiremo due tecniche in particolare: le chiamate di ricognizione per spam e frodi e il war dialing, una metodologia nata negli anni ‘80 e ancora oggi utilizzata in diverse varianti.

Chiamate di Ricognizione per Spam e Frodi

Queste chiamate, a prima vista innocue, hanno uno scopo preciso: verificare se un numero è attivo e se il destinatario è propenso a rispondere. Una volta confermata la validità del numero, viene inserito in liste che possono essere vendute a call center aggressivi, spammer o persino a organizzazioni criminali che si occupano di truffe telefoniche.

Come funzionano?

Le chiamate di ricognizione vengono effettuate in maniera sistematica attraverso:

1. Software automatici di dialer che compongono numeri in sequenza o scelti da database precedenti.
2. Algoritmi che generano numeri casuali con prefissi specifici per colpire zone geografiche mirate.
3. Bot che registrano le risposte umane per capire se il numero è effettivamente attivo.

Se rispondi alla chiamata e rimani in linea per qualche secondo, il sistema conferma che il numero è in uso e lo classifica come “valido”. A quel punto, il tuo contatto può essere:

• Rivenduto a call center per campagne di telemarketing aggressive.
• Utilizzato per tentativi di phishing telefonico (ad esempio, truffe bancarie o falsi supporti tecnici).
• Sfruttato per attacchi basati sull’ingegneria sociale.

In alcuni casi, dopo una chiamata muta, potresti iniziare a ricevere tentativi di truffa più elaborati, come falsi operatori che ti avvisano di un presunto problema con la tua banca o il tuo operatore telefonico.

Perché nessuno parla?

Le telefonate mute possono essere il risultato di due strategie diverse:

• Test di numeri validi: il sistema si limita a verificare se la chiamata va a buon fine e se il destinatario risponde.
• Chiamata automatica senza operatore: in alcuni casi, se rispondi, la chiamata viene inoltrata a un operatore umano che però potrebbe non essere disponibile immediatamente.

Segnali di allarme

Se ricevi più chiamate mute nel giro di pochi giorni, potresti essere finito nel mirino di una campagna di verifica numeri. Altri segnali sospetti includono:

• Chiamate da numeri con prefissi insoliti o internazionali.
• Telefonate ricevute sempre in determinati orari della giornata.
• Tentativi di richiamata automatica se non rispondi subito.

War Dialing: La Tecnica di Scansione dei Numeri Telefonici

Il war dialing è una tecnica utilizzata sin dagli anni ‘80 per trovare numeri telefonici associati a modem, fax o sistemi VoIP vulnerabili. Sebbene oggi gli attacchi siano meno frequenti rispetto al passato, esistono ancora varianti moderne di questa strategia.

Origine del War Dialing

Negli anni ’80 e ‘90, quando le aziende e gli enti governativi utilizzavano modem per collegarsi a sistemi remoti, gli hacker impiegavano software specializzati per chiamare in sequenza numeri di telefono alla ricerca di linee di accesso remoto. Se trovavano un modem attivo, potevano tentare di:

• Forzare l’accesso con password deboli.
• Intercettare comunicazioni non cifrate.
• Accedere a reti aziendali protette solo da autenticazioni telefoniche.

Questa tecnica venne resa popolare dal film WarGames (1983), in cui un giovane hacker scansionava numeri casuali fino a trovare un sistema militare.

Il War Dialing Oggi

Oggi il war dialing viene usato in contesti diversi, ma il concetto di base è lo stesso. Alcuni degli obiettivi moderni includono:

• Individuare numeri VoIP vulnerabili che potrebbero essere sfruttati per attacchi di intercettazione o frodi telefoniche.
• Testare PBX (Private Branch Exchange) aziendali alla ricerca di configurazioni errate o numeri con accesso remoto non protetto.
• Scansionare reti di telefonia mobile per trovare SIM con accessi amministrativi deboli.

Alcuni cybercriminali combinano il war dialing con altre tecniche, come il caller ID spoofing, per far apparire le chiamate provenienti da numeri legittimi e aumentare le probabilità che qualcuno risponda.

Chi è a rischio?

• Aziende con sistemi telefonici VoIP non sicuri.
• Operatori telefonici con infrastrutture vulnerabili.
• Persone con numeri facilmente generabili da algoritmi sequenziali.

Come Proteggersi?

1. Non Rispondere a Numeri Sconosciuti

Se ricevi una chiamata da un numero sospetto e nessuno parla, evita di rispondere nuovamente o di richiamare. Se è una chiamata legittima, chi ha davvero bisogno di te troverà un altro modo per contattarti.

2. Attiva Filtri Antispam e Blocca i Numeri Sospetti

Molti smartphone e operatori offrono servizi di blocco automatico per le chiamate sospette. App come TrueCaller o le impostazioni native di iOS e Android possono aiutarti a identificare chiamate spam.

3. Proteggi il Tuo Numero

• Evita di condividere il tuo numero su siti pubblici o social network.
• Non usare il tuo numero personale per iscrizioni a siti non sicuri.
• Se usi un sistema VoIP aziendale, assicurati che sia configurato correttamente con autenticazione robusta.

4. Segnala i Numeri Sospetti

Se ricevi molte chiamate mute, segnala il numero alle autorità competenti (ad esempio il Garante per la Privacy in Italia o servizi di segnalazione spam).

Essere Consapevoli per Essere Protetti

Le telefonate mute possono sembrare insignificanti, ma in molti casi rappresentano il primo tassello di un piano più ampio di attacco. Capire che dietro questi semplici squilli si nascondono strategie di verifica per truffe e attacchi informatici è essenziale per proteggere la propria privacy e sicurezza economica.

Viviamo in un’epoca in cui il furto di dati personali è diventato una delle principali minacce digitali, e il telefono è una delle porte principali di accesso alla nostra identità. Ignorare queste chiamate, adottare sistemi di filtraggio e segnalare eventuali attività sospette può fare la differenza tra un semplice fastidio e una perdita di denaro o identità digitale.

In un mondo sempre più connesso, la sicurezza inizia dalla consapevolezza.

L'articolo Il mistero delle Telefonate Mute. Arriva il War Dialing: Strategie di Ricognizione per Spam e Frodi proviene da il blog della sicurezza informatica.

Statistics across all threats

In Q4 2024, the percentage of ICS computers on which malicious objects were blocked decreased by 0.1 pp from the previous quarter to 21.9%.

Percentage of ICS computers on which malicious objects were blocked, by quarter, 2022–2024

Compared to Q4 2023, the percentage decreased by 2.8 pp.

The percentage of ICS computers on which malicious objects were blocked during Q4 2024 was highest in October and lowest in November. In fact, the percentage in November 2024 was the lowest of any month in two years.

Percentage of ICS computers on which malicious objects were blocked, Jan 2023–Dec 2024

Region rankings

Regionally, the percentage of ICS computers that blocked malicious objects during the quarter ranged from 10.6% in Northern Europe to 31% in Africa.

Regions ranked by percentage of ICS computers where malicious objects were blocked, Q3 2024

Eight of 13 regions saw their percentages increase from the previous quarter.

Regions and world. Changes in the percentage of attacked ICS computers in Q4 2024

Selected industries

The biometrics sector led the surveyed industries in terms of the percentage of ICS computers on which malicious objects were blocked.

Percentage of ICS computers on which malicious objects were blocked in selected industries

In Q4 2024, the percentage of ICS computers on which malicious objects were blocked decreased across most industries, with the exception of the construction sector.

Changes in the percentage of ICS computers on which malicious objects were blocked in selected industries

Diversity of detected malicious objects

In Q4 2024, Kaspersky’s protection solutions blocked malware from 11,065 different malware families of various categories on industrial automation systems.

Percentage of ICS computers on which the activity of malicious objects from various categories was blocked

Main threat sources

The internet, email clients and removable storage devices remain the primary sources of threats to computers in an organization’s technology infrastructure. Note that the sources of blocked threats cannot be reliably identified in all cases.

In Q4 2024, the percentage of ICS computers on which threats from various sources were blocked decreased for all threat sources described in this report. Moreover, all indicators recorded their lowest values for the observed period.

Percentage of ICS computers on which malicious objects from various sources were blocked

Threat categories

Malicious objects used for initial infection

Malicious objects used for initial infection of ICS computers include dangerous internet resources that are added to denylists, malicious scripts and phishing pages, and malicious documents.

In the fourth quarter of 2024, the percentage of ICS computers on which malicious documents and denylisted internet resources were blocked decreased to 1.71% (by 0.26 pp) and 5.52% (by 1.32 pp), respectively and reached its lowest level since the beginning of 2022.

As noted in the Q3 2024 report, the increase in blocked denylisted internet resources was primarily driven by an increase in the number of newly created domain names and IP addresses used by cybercriminals as command-and-control (C2) infrastructure for distributing malware and phishing attacks.

The decline in the percentage of denylisted internet resources in November–December 2024 was likely influenced not only by proactive threat mitigation measures at various levels – from resource owners and hosting providers to ISPs and law enforcement agencies. Another contributing factor was the tendency of attackers to frequently change domains and IP addresses to evade detection in the initial stages, based on lists of known malicious resources.

In practice, this means that until a malicious web resource is identified and added to a denylist, it may not immediately appear in threat statistics, leading to an apparent decrease in the percentage of ICS computers on which such resources were blocked.

However, in Q4, we also saw a rise in the percentage of the next steps in the attack chain – malicious scripts and phishing pages (7.11%), spyware (4.30%), and ransomware (0.21%).

A significant increase in the percentage of malicious scripts and phishing pages in October was driven by a series of widespread phishing attacks in late summer and early fall 2024, as mentioned in the Q3 2024 report. Threat actors used malicious scripts that executed in the browser, mimicking various windows with CAPTCHA-like interfaces, browser error messages and similar pop-ups to trigger the download of next-stage malware: either the Lumma stealer or the Amadey Trojan.

Next-stage malware

Malicious objects used to initially infect computers deliver next-stage malware – spyware, ransomware, and miners – to victims’ computers. As a rule, the higher the percentage of ICS computers on which the initial infection malware is blocked, the higher the percentage for next-stage malware.

The percentage of ICS computers on which spyware (spy Trojans, backdoors and keyloggers) was blocked increased by 0.39 pp from the previous quarter to 4.30%.

The percentage of ICS computers on which ransomware was blocked increased by a factor of 1.3 compared to the previous quarter, reaching 0.21%, its highest value in two years.

The percentage of ICS computers on which miners in the form of executable files for Windows were blocked decreased by 0.01 pp to 0.70%.

And, the percentage of ICS computers on which web miners were blocked decreased by 0.02 pp to 0.39%, reaching its lowest value in the observed period.

Self-propagating malware

Self-propagating malware (worms and viruses) is a category unto itself. Worms and virus-infected files were originally used for initial infection, but as botnet functionality evolved, they took on next-stage characteristics. To spread across ICS networks, viruses and worms rely on removable media, network folders, infected files including backups, and network attacks on outdated software.

In Q4 2024, the percentage of ICS computers on which worms were blocked increased by 0.07 pp and reached 1,37%. The rate of viruses increased by 0.08 pp to 1.61%.

AutoCAD malware

AutoCAD malware is typically a low-level threat, coming last in the malware category rankings in terms of the percentage of ICS computers on which it was blocked.

In Q4 2024, the percentage of ICS computers on which AutoCAD malware was blocked continued to decrease by losing 0.02 pp and reached 0.38%.

You can find the full Q3 2024 report on the Kaspersky ICS CERT website.

securelist.com/ics-cert-q4-202…

The difference between 3D printing and good 3D printing comes down to attention to detail. There are so many settings and so many variables, each of which seems to impact the other to a degree that can make setting things up a maddening process. That makes anything that simplifies the process, such as this computer vision pressure advance attachment, a welcome addition to the printing toolchain.

If you haven’t run into the term “pressure advance” for FDM printing before, fear not; it’s pretty intuitive. It’s just a way to compensate for the elasticity of the molten plastic column in the extruder, which can cause variations in the amount of material deposited when the print head acceleration changes, such as at corners or when starting a new layer.

To automate his pressure advance calibration process, [Marius Wachtler] attached one of those dirt-cheap endoscope cameras to the print head of his modified Ender 3, pointing straight down and square with the bed. A test grid is printed in a corner of the bed, with each arm printed using a slightly different pressure advance setting. The camera takes a photo of the pattern, which is processed by computer vision to remove the background and measure the thickness of each line. The line with the least variation wins, and the pressure advance setting used to print that line is used for the rest of the print — no blubs, no blebs.

We’ve seen other pressure-advanced calibrators before, but we like this one because it seems so cheap and easy to put together. True, it does mean sending images off to the cloud for analysis, but that seems a small price to pay for the convenience. And [Marius] is hopeful that he’ll be able to run the model locally at some point; we’re looking forward to that.

youtube.com/embed/LptiyxAR9nc?…

hackaday.com/2025/03/21/cheap-…

Gli attacchi informatici contro Cisco Smart Licensing Utility sono in aumento, con i ricercatori che hanno recentemente identificato campagne attive che sfruttano due vulnerabilità critiche risolte circa sei mesi fa. Queste falle permettono ai cybercriminali di ottenere accesso non autorizzato a dati sensibili relativi alle licenze e a funzionalità amministrative del software.

Le vulnerabilità, CVE-2024-20439 e CVE-2024-20440, sono state rese pubbliche a settembre 2024 e hanno entrambe un punteggio CVSS di 9,8. La prima consente a un utente remoto non autenticato di accedere al software tramite credenziali hardcoded, creando di fatto una backdoor. La seconda riguarda un file di registro di debug che espone informazioni sensibili, come le credenziali API.

Il ricercatore di sicurezza Nicholas Starke di Aruba (Hewlett Packard Enterprise) ha individuato una password amministrativa statica all’interno delle versioni vulnerabili del software (dalla 2.0.0 alla 2.2.0). Questa credenziale, Library4C$LU, è integrata nell’autenticazione API, permettendo a un attaccante di ottenere privilegi amministrativi se sfruttata con successo.

Gli specialisti del SANS Institute hanno individuato che gli hacker inviano richieste HTTP create ad hoc per sfruttare queste debolezze. In particolare, gli aggressori mirano all’endpoint API in /cslu/v1/scheduler/jobs, utilizzando credenziali hardcoded per autenticarsi.

Decodificando la stringa Base64 nell’intestazione Authorization, emerge che viene usata l’identità cslu-windows-client:Library4C$LU, confermando l’uso delle credenziali scoperte da Starke. Se l’attacco ha successo, gli aggressori ottengono il controllo amministrativo dell’utility, con la possibilità di gestire licenze e accedere a dati sensibili.

Questi attacchi non sono limitati ai prodotti Cisco: lo stesso gruppo di cybercriminali sta cercando di sfruttare anche altre vulnerabilità, come CVE-2024-0305, che colpisce alcuni sistemi DVR.

Secondo Johannes Ullrich, responsabile della ricerca presso SANS, il fatto che dispositivi IoT a basso costo e software aziendali avanzati soffrano di problemi di sicurezza simili, come l’uso di credenziali hardcoded, dimostra quanto siano diffuse queste criticità.

L'articolo Cisco sotto attacco: sfruttate due vulnerabilità critiche nella Smart Licensing Utility! proviene da il blog della sicurezza informatica.

Ne avevamo discusso di recente, analizzando il caso Paragon in Italia, che ha portato alla sorveglianza di diversi cittadini italiani. Uno scandalo che, come spesso accade, ha sollevato polemiche per poi finire rapidamente nel dimenticatoio.

WhatsApp ha corretto una vulnerabilità zero-day sfruttata per installare lo spyware Graphite di Paragon. Lo Sviluppatore di spyware israeliano Paragon Solutions Ltd. è stata fondata nel 2019. Secondo quanto riportato dai media, nel dicembre 2024 la società è stata acquisita dal gruppo di investimento AE Industrial Partners con sede in Florida.

A differenza dei suoi concorrenti (come NSO Group), Paragon afferma di vendere i suoi strumenti di sorveglianza solo alle forze dell’ordine e alle agenzie di intelligence dei paesi democratici che hanno bisogno di rintracciare criminali pericolosi. Il 31 gennaio 2025, dopo aver risolto la vulnerabilità zero-click, i rappresentanti di WhatsApp hanno notificato a circa 90 utenti Android di 20 Paesi (tra cui giornalisti e attivisti italiani) di essere stati vittime di attacchi da parte dello spyware Paragon, progettato per raccogliere dati sensibili e intercettare i loro messaggi privati.

Come hanno ora rivelato gli esperti di Citizen Lab , gli aggressori hanno aggiunto le future vittime ai gruppi WhatsApp e poi hanno inviato loro un file PDF. Il dispositivo della vittima ha elaborato il file dando accesso all’exploit 0-day che ha consentito l’installazione dello spyware Graphite.

Successivamente il malware è fuoriuscito dalla sandbox di Android e ha compromesso altre app sui dispositivi delle vittime. Inoltre, dopo l’installazione, lo spyware forniva ai suoi operatori l’accesso ai messaggi di messaggistica degli utenti. A quanto si dice, lo spyware può essere rilevato sui dispositivi Android con jailbreak tramite un artefatto denominato BIGPRETZEL. È possibile scoprirlo analizzando i registri dei dispositivi hackerati.

Gli esperti di Citizen Lab hanno mappato l’infrastruttura server utilizzata da Paragon per installare Graphite sui dispositivi delle vittime e hanno trovato possibili collegamenti tra l’azienda e diversi clienti governativi, tra cui Australia, Canada, Cipro, Danimarca, Israele e Singapore. In totale, sono stati in grado di identificare 150 certificati digitali associati a decine di indirizzi IP che, secondo i ricercatori, fanno parte dell’infrastruttura di controllo di Paragon.

“L’infrastruttura includeva server cloud che erano probabilmente stati affittati da Paragon o dai suoi clienti, così come server che potrebbero essere stati ubicati nei locali di Paragon e dei suoi clienti governativi. L’infrastruttura scoperta era collegata a pagine web chiamate “Paragon” che venivano restituite da indirizzi IP in Israele (dove ha sede Paragon), nonché a un certificato TLS contenente il nome dell’organizzazione Graphite. Lo stesso nome è dato allo spyware Paragon. È stato trovato anche un nome comune “installerserver”. Il prodotto spyware concorrente Pegasus usa il termine “Installation Server” per riferirsi ai server progettati per infettare i dispositivi con spyware”, scrivono gli esperti.

Secondo i rappresentanti di WhatsApp, questo vettore di attacco è stato risolto alla fine del 2024 e non ha richiesto patch lato client. L’azienda ha affermato di aver deciso di non assegnare un identificatore CVE alla vulnerabilità dopo “aver esaminato le linee guida CVE pubblicate da MITRE e a causa delle politiche interne dell’azienda”.

L'articolo Cucù, Lo 0day di Graphite non c’è più! Whatsapp risolve il bug usato per colpire gli italiani proviene da il blog della sicurezza informatica.