Github fa fatica a tenere il passo una campagna malware che rappresenta una nuova svolta nel typosquatting. Il gioco è semplice: clonare repository popolari, aggiungere malware e pubblicizzare i fork come originali. Alcuni sviluppatori confondono i fork con progetti reali ed eseguono involontariamente il malware. La scelta ovvia del nome è forksquatting, ma il file i ricercatori di apiiro hanno scelto il nome più sicuro di “Repo Confusion”.

La campagna è automatizzata e GitHub ne è consapevole, poiché la stragrande maggioranza di questi repository dannosi viene rimossa immediatamente. Per qualche motivo, l'algoritmo GitHub non riesce a rilevare tutti i nuovi repository. Sembra che l'attuale campagna pubblichi milioni di fork, utilizzando il codice di oltre 100,000 progetti legittimi. Comincia a sembrare che la famiglia degli attacchi abusivi sia qui per restare.

RustDesk e certificati dispari

Il software di accesso remoto RustDesk è interessante, poiché è open source, consente l'hosting autonomo ed è scritto in Rust. Ho esplorato RustDesk come elemento da fare per molto tempo, ma un po' di drammaticità preoccupante è appena finita. Un utente lo ha sottolineato a novembre come parte dell'installazione di RustDesk è stato installato un certificato root di prova. Quel certificato root è autofirmato con SHA1. C'è anche la preoccupazione che i file binari di RustDesk siano firmati con un certificato diverso.

Da allora ci sono stati nuovi eventi. Innanzitutto c'era un thread di Hacker News sulla questione all'inizio di questo mese. Il giorno successivo, CVE-2024-25140 è stato registrato presso il NIST, classificandosi con un CVE folle di 9.8 CVSS. Tagliamo un po' di FUD e parliamo di cosa sta realmente succedendo.

Innanzitutto, i certificati root dovrebbero essere firmati con una funzione di hashing più sicura rispetto a SHA1. Ma non per il motivo che pensi tu, e in questo caso non ha importanza. I certificati radice sono autofirmati per definizione e l'unico motivo per cui sono firmati è perché questi certificati devono essere firmati per essere validi. I certificati secondari non sono protetti dalla firma del root. La funzione importante che dipende da quella firma root è la capacità di emettere una richiesta di revoca. Sarebbe davvero negativo per uno dei certificati radice ampiamente attendibili e non sarebbe affatto un problema per un certificato non attendibile come questo.

Successivamente, RustDesk dispone di un certificato valido e firmato per gli eseguibili. Il certificato root autofirmato serve esclusivamente per firmare un driver del kernel, che richiede un certificato EV (Extended Validation). È un po' sconcertante che questo requisito possa essere eluso così facilmente installando un certificato root durante l'installazione dell'applicazione, ma questo è su Microsoft, non su RustDesk.

L'ultima preoccupazione qui è che questo certificato viene installato come un'autorità di certificazione (CA) a livello di sistema. Questo è l'elemento più preoccupante di questa saga, ma i certificati hanno un campo che specifica il loro utilizzo della chiave (KU) e l'utilizzo della chiave estesa (EKU). La CA RustDesk è esclusivamente per la firma del codice. Ciò non consente a RustDesk o a chiunque sia in possesso di questa chiave di violare TLS o falsificare siti Web. Consente la firma del codice, il che potrebbe essere una preoccupazione valida, ma non è la situazione in fiamme che sembra a prima vista.

RustDesk ha estratto questa chiave dalla loro installazione, che disabilita il driver del display virtuale. Questa era la funzionalità che richiedeva un driver del kernel firmato. L'ultima notizia è che gli sviluppatori di RustDesk stanno ricevendo assistenza e stanno ottenendo un certificato di firma del codice EV e si aspettano di completare il processo in circa un mese. E quel CVE, con un punteggio di gravità 9.8? Sembra completamente falso.

Iniezione SQL del membro ultimo

Il plugin Ultimate Member WordPress è stato aggiornato alla versione 2.8.3, correggere un difetto di SQL injection che era accessibile come utente non autenticato. In base alla differenza di aggiornamento, la questione chiave è probabilmente una mancata risposta prepare() on line 704. Oh, e a quanto pare è stato sondato e potenzialmente sfruttato in natura, quindi vai alla patch.

Questo è probabilmente un buon momento per parlare del perché ci sono così tanti attacchi SQL injection in WordPress. Innanzitutto, l'iniezione SQL avviene quando i dati forniti dall'utente vengono interpretati come parte del comando SQL da eseguire. Questo viene fatto includendo un personaggio inaspettato. Ad esempio, un punto e virgola indica la fine di un'istruzione e può essere utilizzato per iniziare quella successiva. Quindi, dove un programma ingenuo si aspetta un numero, un input di 15; DROP TABLE Students soddisferà un'istruzione SQL e inietterà una seconda istruzione da eseguire sul database.

In generale, esistono due approcci per prevenire l’SQL injection: la sanificazione dell’input e le dichiarazioni preparate. Ed entrambi sono buoni! Innanzitutto, disinfetta l'input dell'utente. Assicurati che il numero intero sia effettivamente un numero intero e solo un numero intero. Eliminare virgolette, punti e virgola e altri caratteri potenzialmente pericolosi.

Il secondo approccio consiste nell'utilizzare dichiarazioni preparate. Ciò separa il comando SQL dai dati in modo fondamentale. È qualcosa del genere $database->prepare("INSERT INTO Students (name, age) VALUES (?, ?)"); per inviare i comandi SQL. Poi è seguito da $database->bind_param("si", $name, $age); per impostare i valori da utilizzare. E infine a $database->execute(); esegue effettivamente la query. Non è possibile alcuna iniezione a causa della rigida separazione tra codice e valori.

Veniamo ora a WordPress, che ha il suo wpdb classe per le chiamate al database. Ciò include una funzione utile, wpdb::prepare() sembra quasi una dichiarazione preparata come mostrato sopra.

$wpdb->prepare( "u.user_registered BETWEEN %s AND %s", $from_date, $to_date );

Solo che non lo è affatto. IL prepare() la funzione esegue rigorosamente un passaggio di sanificazione e un sprintf() sostituzione di valore. IL prepare() la funzione non produce effettivamente un'istruzione di database preparata. WordPress non fornisce un modo per utilizzare effettivamente le istruzioni preparate. Manca uno dei paradigmi di base per tenere gli sviluppatori fuori dai guai con le SQL injection.

Gli M&Ms stanno guardando

Ho una specie di hobby. Trovo divertente individuare le macchine che si comportano in modo anomalo e provare a capire quale sistema operativo è in esecuzione sotto la brillante GUI. Il dispositivo incorporato più strano che ho trovato è uno scanner di pagine che eseguiva una copia completa di Windows. Gli scanner dei prezzi nel tuo grande magazzino locale potrebbero eseguire semplicemente Windows CE. I centri di infotainment sugli schienali degli aerei utilizzano un Linux davvero vecchio. E a quanto pare i distributori automatici di M&M dell'Università di Waterloo funzionano Windows con l'applicazione Invenda.Vending.FacialRecognition.App.exe.

Lo sappiamo perché [SquidKid47] ha rilevato un'eccezione software sconosciuta sullo schermo del distributore automatico e l'ha condivisa su Reddit. UN il giornale scolastico raccolse la storia (pdf) e ha stabilito che il distributore automatico utilizza una fotocamera e il rilevamento facciale come una combinazione di sensore di movimento intelligente e rilevatore demografico per la pubblicità mirata. Sì, questi distributori automatici pubblicano annunci mirati. Almeno lo hanno fatto. Questi distributori automatici hanno incontrato la loro Waterloo presso l'Università di Waterloo, e la scuola ora ne richiede formalmente la rimozione.

Bit e byte

Suona il campanello al Pwn: si scopre che alcuni campanelli intelligenti non sono poi così intelligenti. Non sorprende che esista un processo per reimpostare un campanello intelligente e associarlo a un altro account. È piuttosto sorprendente che questo processo sia così semplice come tenere premuto il grande pulsante del campanello per 8 secondi. Come minimo, il legittimo proprietario riceverà un'e-mail sulla modifica.

L’insicurezza delle stampanti non è una novità, ma la sicurezza delle stampanti 3D è ancora un’idea di nicchia. Le cose potrebbero cambiare, adesso l'equivalente di un file "greetings.txt" è stato eliminato su un gruppo di stampanti Anycubic. Apparentemente Anycubic utilizza un server MQTT che in realtà non dispone di controlli di accesso sufficienti.

È di nuovo quel momento, quando è stata rilasciata una correzione della vulnerabilità per GitLabed è ora di aggiornare. La novità questa volta è un difetto di Cross Site Scripting (XSS) che si verifica quando si visita la pagina del profilo di un utente. Lascio come esercizio per il lettore, produrre un codice di esempio che copi “samy è il mio eroe” nella pagina del profilo di ciascun visitatore.

E infine, nel reparto dell'ironia, Avast è stata multata per l'utilizzo di un plug-in per la privacy del browser come piattaforma per raccogliere e vendere i dati degli utenti. Ciò è avvenuto dal 2014 al 2020, utilizzando la piattaforma Jumpshot per la vendita vera e propria dei dati. I dati sono stati nominalmente resi anonimi, ma la quantità e il dettaglio delle informazioni disponibili sono un po’ sconcertanti. Vale la pena sottolineare che Jumpshot non esiste più e Avast è ora di proprietà di un'altra società. Si spera senza raccogliere informazioni sugli utenti.

• Distribuzione di contenuti basati su SEO e PR. Ricevi amplificazione oggi.
• PlatoData.Network Generativo verticale Ai. Potenzia te stesso. Accedi qui.
• PlatoAiStream. Intelligenza Web3. Conoscenza amplificata. Accedi qui.
• PlatoneESG. Carbonio, Tecnologia pulita, Energia, Ambiente, Solare, Gestione dei rifiuti. Accedi qui.
• Platone Salute. Intelligence sulle biotecnologie e sulle sperimentazioni cliniche. Accedi qui.
• Fonte: https://hackaday.com/2024/03/01/this-week-in-security-forksquatting-rustdesk-and-mms/