Logic time bomb Piergiorgio Venuti

Logic Bomb: what they are and how to prevent them

Estimated reading time: 6 minutes

Una logic bomb, chiamata anche slug code, è un pezzo di codice inserito in un’applicazione, virus o malware che implementa una funzione dannosa dopo un certo limite di tempo o in condizioni specifiche.

Queste “bombe” sono spesso usate tramite virus, worm e Trojan per gestire al meglio il tempo a disposizione e fare il massimo danno prima di essere notati. Eseguono azioni come corrompere o alterare i dati, riformattare un disco rigido e cancellare file importanti.

In questo articolo voglio spiegare cosa sia un bomba logica e offrire qualche suggerimento per prevenirne i danni.

Logic bomb virus

Cos’è un logic bomb virus?

Una bomba logica è spesso inserita in un virus o comunque in un file eseguibile. È composta da un codice malevolo che innesca un attacco quando vengono soddisfatte condizioni specifiche. Le condizioni possono essere positive (qualcosa che accade) oppure negative (qualcosa che non accade). Nel primo caso un esempio è quello dell’apertura di un programma, invece, un esempio di condizione negativa è un utente che non compie il login.

Le bombe logiche sono spesso installate da qualcuno con un accesso di alto livello, come un amministratore di sistema. Tale persona può causare il caos impostando questi codici su più sistemi e programmandoli per “esplodere” simultaneamente quando si verifica un certo evento. Per esempio, potrebbero azionarsi quando un certo dipendente viene rimosso dal database degli stipendiati, cioè quando viene licenziato.

Con il termine slag code ci si riferisce al codice manipolato che rende dannoso un programma altrimenti sicuro. Le versioni a tempo di bomba logica sono quelle più diffuse e utilizzano come condizione positiva il trascorrere di un certo lasso di tempo.

Qualunque sia il nome usato, il metodo di attacco è sempre chiaramente lo stesso: il codice rimane dormiente nel software infetto fino a quando non viene innescato. Gli attacchi comuni coinvolgono la corruzione dei dati, la cancellazione dei file e la cancellazione dei dischi rigidi.

Come funziona

Il modo in cui una logic bomb funziona dipende da chi l’ha ideata. Ogni bomba logica è unica, ed è per questo che sono difficili da tracciare. Di solito sono personalizzate per essere il meno rilevabili possibile. Spesso sono travestite per sembrare un tipico virus informatico o inserite in altri tipi di malware come i worm. Worm e virus sono diversi, ma le bombe logiche non si preoccupano della distinzione: possono causare danni attraverso entrambi.

Una bomba logica è effettivamente un malware? Poiché fanno parte di altri programmi, no, ma di solito hanno un intento maligno. Ecco perché gli slag code sono così difficili da rilevare. Inoltre, essendo “solo” codice, potenzialmente inseribile ovunque, mitigare il rischio è più complicato.

La cosa migliore da fare, come utente finale che potrebbe essere coinvolto in un attacco con una logic bomb, è quello di tenere gli occhi aperti e chiedere agli esperti IT della tua azienda di fare i controlli necessari in caso di dubbio. Il rischio è quello di far scattare la bomba involontariamente cercando di trovarla.

Esempi di attacchi

Le bombe logiche possono cambiare in modo impercettibile un frammento di codice in modo che appaia tecnicamente normale ad un sistema automatico di ricerca delle minacce, mentre sembrerebbe molto sospetto per un occhio umano. Nel 2016, un programmatore freelance ha volontariamente causato un malfunzionamento ricorrente dei fogli di calcolo in una filiale della società Siemens. La filiale lo ha continuato ad assumere per risolvere il problema che lui stesso aveva causato (Fonte). In questo caso, i dipendenti non sospettavano nulla fino a quando una fortunata coincidenza ha costretto il codice maligno a uscire allo scoperto.

Anche le aziende possono usare bombe logiche per violare i propri clienti. Nel 2005, Sony fu coinvolta in uno scandalo per aver rilasciato dei CD che scatenavano una bomba logica quando venivano inseriti in un computer. Lo slag code contenuti nei CD installava un rootkit che bloccava la capacità del PC di copiare i CD. (Fonte)

Un altro caso di alto profilo si è verificato nei primi anni 2000, quando un dipendente di UBS Global, arrabbiato per una disputa salariale, ha piazzato una bomba logica a tempo che ha causato più di tre milioni di dollari di danni. Un segno evidente che uno snippet di codice molto piccolo può causare una grande quantità di danni. (Fonte)

Nel 2013, un attacco con una bomba a tempo in Corea del Sud ha cancellato i dischi rigidi di diverse banche e società di trasmissione. Il gruppo responsabile dell’attacco ha messo la bomba a tempo all’interno di un malware che ha finito per infettare oltre 32.000 sistemi. Le bombe sono esplose tutte insieme, causando il caos in tutto il paese. (Fonte)

Logic bomb cover

Da dove vengono e come prevenire le logic bomb

Come abbiamo visto anche negli esempi, le bombe logiche sono tipicamente distribuite all’interno di una rete chiusa, come quella di un’azienda o di una filiale. Una delle probabili fonti è un dipendente scontento con accessi di amministratore, quindi un attento monitoraggio delle attività in uscita del personale dovrebbe rivelare qualsiasi attività sospetta. Ma non è tutto, le bombe logiche possono anche essere piazzate in allegati di email e download di file sospetti, quindi gli utenti dovrebbero essere vigili quando scelgono i file da scaricare.

Come abbiamo visto quando abbiamo parlato di phishing e di ingegneria sociale, la parte più hackerabile di un sistema, sono spesso gli user. Per questo una campagna preventiva è sempre un’ottima scelta. Prendersi cura del personale significa anche proporre dei training specifici tramite servizi di phishing etico.

Oltre alla prevenzione, è bene limitare i privilegi amministrativi a un gruppo selezionato di dipendenti in modo che sia meno probabile che qualcuno possa causare gravi danni alla rete con una bomba logica. Questo metodo preventivo, inoltre, riduce il numero dei sospetti in caso di attacco, rendendo l’appartenenza a quello specifico gruppo di dipendenti di per sé un deterrente contro gli attacchi interni.

La soluzione proposta da Cyberfero

Dove la prevenzione fallisce e vincono invece gli hacker, è il campo ideale per implementare sistemi avanzati di monitoring e analisi.

Cyberfero offre, per esempio, un sistema SIEM nella soluzione SOC as a Service. Tramite il SIEM vengono costantemente raccolte informazioni su quello che succede nella rete. Queste informazioni vengono poi arricchite con metadati contestuali per uniformarle e gestirle al meglio. Già questo è in grado di far scattare allarmi se alcuni eventi sospetti si verificassero. Ma se questo non bastasse, il SOC dispone anche di uno strumento di “User and Entity Behavior Analysis” (UEBA) che analizza il comportamento degli utenti e grazie all’interazione di una IA riesce a individuare comportamenti sospetti.

Se vuoi saperne di più riguardo al servizio SOC offerto, o se hai delle domande su come Cyberfero può aiutarti a mantenere la tua azienda al sicuro, non esitare a contattarci. Saremo lieti di rispondere a ogni dubbio.

Useful links:

Mobile App Penetration Test & Code Review

Cos’è la Cyber Security? Definizione e proposte

Share


RSS

More Articles…

Categories …

Tags

RSS feed: Unknown Feed Unknown Feed

RSS feed: Full Disclosure Full Disclosure

  • SEC Consult SA-20261104-0 :: Improper device certificate validation enables AiTM attacks in Siemens SICAM Toolbox II device communication November 5, 2026
    Posted by SEC Consult Vulnerability Lab via Fulldisclosure on Nov 04SEC Consult Vulnerability Lab Security Advisory < 20261104-0 > ======================================================================= title: Improper device certificate validation enables AiTM attacks product: Siemens SICAM Toolbox II device communication vulnerable version:
  • Apache Struts2 Tiles Plugin <=7.4.0 and >=6.3.0 Preparer Cache Vulnerabilities November 5, 2026
    Posted by Daniel Owens via Fulldisclosure on Nov 04The Apache Struts2 Tiles plugin version =6.3.0) codebase includes a `ViewPreparer` construct, replete with multiple ViewPreparer factories, that contains several important vulnerabilities including unsynchronised, unbounded caches. The lack of proper synchronisation means that certain factories will create caches that race, risking lost cache entries, corrupted internal bucket […]
  • unixODBC <=2.3.14 Rude Truncation via Narrowing Conversion Causes Out-of-Bounds `memcpy` November 5, 2026
    Posted by Daniel Owens via Fulldisclosure on Nov 04unixODBC versions
  • unixODBC <=2.3.14 Multiple Races November 5, 2026
    Posted by Daniel Owens via Fulldisclosure on Nov 04The unixODBC driver manager library contains multiple races of importance / interest, including a set of data races in the connection-pooling configuration state data that can cause one thread to read a half-written pool-size or timeout value, which can lead to a variety of harmful effects, as […]
  • unixODBC <=2.3.14 Multiple Heap Buffer Overflows, Underflows, and Over-Reads November 5, 2026
    Posted by Daniel Owens via Fulldisclosure on Nov 04unixODBC versions 2.3.14 and below contain multiple heap buffer overflows, underflows, and over-reads. Attackers who can influence various arguments passed thereto can trigger the heap-based buffer overflows inside of the unixODBC driver manager itself, potentially corrupting the shared heap state across connections, crash the driver manager (thereby […]
  • Apache Struts2 Core Arbitrary Code Execution via OGNL Sandbox Escape November 2, 2026
    Posted by Daniel Owens via Fulldisclosure on Nov 01Description Apache Struts2 Core version 7.4.0 and below attempt to prevent arbitrary code execution via Object-Graph Navigation Language (OGNL) through several different mechanisms but only in a cursory fashion -- the libraries only guard against immediate calls evaluated by the OGNL engine via `SecurityMemberAccess`, but an allowed […]
  • Apache Struts2 Core TokenHelper Token Cryptographic Timing Side-Channel November 2, 2026
    Posted by Daniel Owens via Fulldisclosure on Nov 01Description The Apache Struts2 Core 7.4.0 and below performs session token comparisons cryptographically insecure early-exit comparison functions (e.g., `!=`, `memcmp`, byte-by-byte loops with `break`) that return as soon as the first mismatched byte is encountered. The execution time of the comparison is therefore proportional to the number […]
  • Apache Struts2 Spring Plugin Uses a Previously Closed Resource November 2, 2026
    Posted by Daniel Owens via Fulldisclosure on Nov 01Description The Apache Struts2 Spring Plugin opens a Spring `ApplicationContex` via a try-with-resources block and, outside of said block, then continues to use the closed resource, resulting in an uncaught `IllegalStateException`. This particular issue prevents proper functionality and indicates poor code quality and code review standards and […]
  • Apache Struts2 Core Integer Overflow November 2, 2026
    Posted by Daniel Owens via Fulldisclosure on Nov 01Description Apache Struts2 Core version 7.4.0 and below fails to properly prevent integer overflows, causing wrap-arounds and other issues on a downstream forced casting into types smaller than `BigInteger`. Importantly, this finding underscores why all applications using Struts and other such platforms should perform their own input […]
  • Apache Struts2 Core Cross-Origin Protection Exemption Miskeyed to a Deployment-Wide Path November 2, 2026
    Posted by Daniel Owens via Fulldisclosure on Nov 01Description Apache Struts2 Core version 7.4.0 and below&apos;s `FetchMetadataInterceptor`, `CoepInterceptor`, and `CoopInterceptor` each compare their `exemptedPaths` configuration -- a per-interceptor-reference, administrator-supplied set of paths intended to exempt specific actions from the corresponding cross-origin protection -- against `HttpServletRequest.getContextPath()`. `getContextPath()` is fixed for the entire deployed web...

Customers