{"id":2013,"date":"2026-05-17T10:37:18","date_gmt":"2026-05-17T08:37:18","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/supply-chain-attack-android-2026-rilevamento-hardening-apk\/"},"modified":"2026-05-17T10:37:18","modified_gmt":"2026-05-17T08:37:18","slug":"supply-chain-attack-android-2026-rilevamento-hardening-apk","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/supply-chain-attack-android-2026-rilevamento-hardening-apk\/","title":{"rendered":"Supply Chain Attack Android 2026: Come Rilevare e Proteggere Play Services dai Moduli Compromessi"},"content":{"rendered":"

Nel corso del 2026, ho assistito a un’escalation preoccupante di attacchi alla catena di approvvigionamento Android. Non si tratta pi\u00f9 solo di malware generici<\/strong>: gli attaccanti stanno compromettendo le fondamenta stesse dell’ecosistema, inserendo malware direttamente nella firmware dei dispositivi e nei moduli di sistema come Play Services. In questa guida, condivido le tecniche di rilevamento che applico quotidianamente e le strategie di hardening che hanno dimostrato di funzionare in ambienti enterprise.<\/p>\n

Il Panorama dei Supply Chain Attack Android nel 2026<\/h2>\n

Nel febbraio 2026, Kaspersky ha scoperto Keenadu, un malware integrato nella firmware Android come risultato di un supply chain attack<\/cite>. Quello che mi ha colpito di pi\u00f9 \u00e8 la sofisticatezza: una fase della catena di approvvigionamento della firmware \u00e8 stata compromessa, introducendo una dipendenza malevola che utilizza il processo Zygote di Android, il che significa che il malware viene automaticamente copiato in ogni applicazione in esecuzione<\/cite>.<\/p>\n

Secondo Kaspersky, circa 13.000 dispositivi Android sono stati infettati da Keenadu, con il numero pi\u00f9 alto di utenti colpiti in Russia, seguito da Giappone, Germania, Brasile e Paesi Bassi<\/cite>. Ma c’\u00e8 di pi\u00f9: le applicazioni si affidano sempre pi\u00f9 a SDK di terze parti, creando dipendenze di supply chain grandi e spesso opache. Man mano che diventano pi\u00f9 comuni portafogli mobili e altre app di alto valore, anche piccoli difetti nelle librerie upstream possono impattare milioni di dispositivi<\/cite>.<\/p>\n

Come Funzionano gli Attacchi: La Compromissione a Livello di Modulo<\/h2>\n

Nella mia esperienza, gli attacchi pi\u00f9 sofisticati sfruttano tre vettori:<\/p>\n

    \n
  1. Firmware compromessa durante il build<\/strong>: Kaspersky ha concluso che Keenadu \u00e8 stato “integrato nella firmware durante la fase di build” in una compromissione della supply chain, piuttosto che essere successivamente installato attraverso un server OTA compromesso<\/cite>.<\/li>\n
  2. Moduli Play Services modificati<\/strong>: Il malware pu\u00f2 essere distribuito non solo via firmware armata, ma anche nascosto in app di sistema, inclusi servizi di riconoscimento facciale e app launcher, oltre a versioni modificate di applicazioni popolari su store ufficiali come Google Play<\/cite>.<\/li>\n
  3. Vulnerabilit\u00e0 negli SDK di terze parti<\/strong>: Nel 2026, Microsoft ha identificato una grave vulnerabilit\u00e0 di reindirizzamento intent in un SDK Android ampiamente utilizzato (EngageSDK), che consente alle app sullo stesso dispositivo di bypassare la sandbox Android e accedere senza autorizzazione ai dati privati. Con oltre 30 milioni di installazioni di applicazioni di wallet di terze parti da sole, l’esposizione di PII, credenziali utente e dati finanziari era a rischio<\/cite>.<\/li>\n<\/ol>\n

    Nel mio lavoro di System Administrator, ho notato che questo file infetto viene utilizzato dal processo master Zygote di Android, il che significa che il malware viene automaticamente copiato in ogni applicazione che gira su un dispositivo compromesso<\/cite>, rendendo estremamente difficile il rilevamento per l’utente finale.<\/p>\n

    Rilevamento dei Moduli Compromessi: La Mia Procedura Pratica<\/h2>\n

    1. Verificare l’Autenticit\u00e0 dei Moduli Play Services<\/h3>\n

    A partire dal 1\u00b0 maggio 2026, le applicazioni Android di produzione di Google avranno una voce crittografica corrispondente che ne conferma l’autenticit\u00e0. L’iniziativa include sia Google Play Services che app Google standalone, nonch\u00e9 i moduli Mainline che fanno parte del sistema operativo e possono essere aggiornati dinamicamente al di fuori del normale ciclo di rilascio<\/cite>.<\/p>\n

    Come implementarlo nella tua infrastruttura:<\/strong><\/p>\n

    #!\/bin\/bash\n# Script per verificare l'integrit\u00e0 di Play Services su dispositivi Android\n# Utilizzo: .\/verify_play_services.sh <device_serial>\n\nDEVICE=$1\nGMS_PACKAGE=\"com.google.android.gms\"\nGMS_VERSION=$(adb -s $DEVICE shell dumpsys package $GMS_PACKAGE | grep versionName)\n\necho \"[*] Play Services Version: $GMS_VERSION\"\n\n# Verificare il certificato di firma\nadb -s $DEVICE shell pm dump $GMS_PACKAGE | grep -A 5 \"signingCertificates\"\n\n# Confrontare con la lista ufficiale di Google\necho \"[!] Verificare il certificato contro il registro pubblico di Binary Transparency\"\necho \"[!] URL: https:\/\/transparency.googlesource.com\/android\/+\/refs\/heads\/main\"\n<\/code><\/pre>\n
    2. Analizzare le Dipendenze degli SDK di Terze Parti<\/h3>\n
    Le applicazioni si affidano sempre pi\u00f9 a SDK di terze parti, creando grandi e spesso opache dipendenze della supply chain. Man mano che i portafogli mobili e altre app di alto valore diventano pi\u00f9 comuni, anche piccoli difetti nelle librerie upstream possono impattare milioni di dispositivi. Questi rischi aumentano quando le integrazioni espongono componenti esportati o si affidano a ipotesi di fiducia che non vengono validate oltre i confini dell’app<\/cite>.<\/p>\n
    La procedura che uso quotidianamente:<\/p>\n
      \n
    1. Generare un SBOM (Software Bill of Materials)<\/strong> per ogni APK\/AAB distribuito<\/li>\n
    2. Verificare le versioni degli SDK<\/strong> contro i bollettini di sicurezza ufficiali<\/li>\n
    3. Analizzare le attivit\u00e0 esportate<\/strong> in AndroidManifest.xml<\/li>\n
    4. Testare le intent redirection vulnerabilities<\/strong> usando strumenti come Frida<\/li>\n<\/ol>\n
      3. Scansionare le Attivit\u00e0 Esportate e Componenti Nascosti<\/h3>\n
      Nella mia esperienza, le vulnerabilit\u00e0 pi\u00f9 pericolose si nascondono nei componenti esportati impliciti:<\/p>\n
      # Estrai AndroidManifest.xml dal file APK\napktool d app.apk\n\n# Cerca attivit\u00e0 esportate senza protective permissions\ngrep -n \"exported=\"true\"\" AndroidManifest.xml\n\n# Identifica servizi, content provider e broadcast receiver senza protezioni\ngrep -E \"<(service|provider|receiver)\" AndroidManifest.xml | grep -v \"android:permission\"\n<\/code><\/pre>\n
      Hardening della Catena di Approvvigionamento APK: La Mia Strategia Enterprise<\/h2>\n
      Implementazione di Binary Transparency per Google Apps<\/h3>\n
      Questo fornisce un “Source of Truth” trasparente che consente a chiunque di verificare che il software Google sul proprio dispositivo Android \u00e8 una versione di produzione autorizzata da Google e non \u00e8 stato modificato da un attaccante. Se il software non \u00e8 nel registro, Google non lo ha rilasciato come software di produzione. Qualsiasi tentativo di distribuire una versione “one-off” sar\u00e0 rilevabile. Come parte di questo sforzo, il gigante tecnologico sta anche mettendo a disposizione strumenti di verifica che utenti e ricercatori possono sfruttare<\/cite>.<\/p>\n
      Come integro questo nella mia infrastruttura Plesk:<\/strong><\/p>\n
        \n
      1. Utilizzo Google Binary Transparency API<\/strong> per fare il log di tutte le app Google rilasciate dopo il 1\u00b0 maggio 2026<\/li>\n
      2. Mantengo una copia locale dei registri di trasparenza<\/strong> per audit offline<\/li>\n
      3. Implemento verifiche automatizzate che bloccano app non presenti nel registro<\/li>\n<\/ol>\n
        Blocco dei Componenti Non Autorizzati<\/h3>\n
        In un ambiente enterprise, implemento un whitelist di componenti conosciuti<\/strong>:<\/p>\n
        # Script di verifica per environment enterprise\nadb shell pm list packages -3 > \/tmp\/third_party_apps.txt\n\n# Per ogni app, verificare che non contenga componenti non autorizzati\nfor app in $(cat \/tmp\/third_party_apps.txt); do\n  adb shell dumpsys package \"${app#package:}\" | grep -E \"Service|Activity|Provider\" | \n  while read -r component; do\n    # Confrontare contro whitelist autorizzato\n    if ! grep -q \"$component\" \/etc\/android_whitelist.conf; then\n      echo \"[ALERT] Componente non autorizzato: $component in $app\"\n    fi\n  done\ndone\n<\/code><\/pre>\n
        Implementazione di SafetyNet\/Play Integrity API<\/h3>\n
        Live Threat Detection, il sistema AI on-device di Android per contrassegnare il comportamento sospetto delle app, guadagna nuovi avvisi per l’inoltro SMS e l’abuso di overlay di accessibilit\u00e0. Una capacit\u00e0 chiamata dynamic signal monitoring osserver\u00e0 le interazioni applicazione-sistema in tempo reale e distribuir\u00e0 regole di rilevamento aggiornate per affrontare nuove minacce. Arriva sui dispositivi Android 17, con protezioni spedite nella seconda met\u00e0 del 2026<\/cite>.<\/p>\n
        Integro questa verifica nel mio workflow di deployment:<\/p>\n
        \/\/ Verificare l'integrit\u00e0 del dispositivo prima dell'installazione di app sensibili\nfinal SafetyNetClient client = SafetyNet.getClient(context);\nclient.attest(nonce, apiKey).addOnSuccessListener(result -> {\n    SafetyNetData data = result.getResult();\n    if (data != null && data.isValidSignature()) {\n        \/\/ Dispositivo autorizzato, procedere con l'installazione\n        installSecureApp();\n    } else {\n        \/\/ Dispositivo compromesso o modificato\n        blockInstallation(\"Dispositivo non supera il controllo di integrit\u00e0\");\n    }\n});\n<\/code><\/pre>\n
        Protezione Contro le Compromissioni di Firmware: Zero-Trust su Android<\/h2>\n
        Nel corso del 2026, la ricerca di Kaspersky e Sophos ha evidenziato un fatto spaventoso: Keenadu \u00e8 un’infezione firmware incorporata in libandroid_runtime.so che si inietta nel processo Zygote. Poich\u00e9 Zygote \u00e8 il processo padre di tutte le app Android, un attaccante guadagna effettivamente il controllo totale di un dispositivo infetto. Keenadu funge da downloader per moduli malware di secondo stadio<\/cite>.<\/p>\n
        Implementazione di Verified Boot Hardening<\/h3>\n
        Prima che qualsiasi app si esegua, prima che qualsiasi utente acceda, prima che accada qualcosa di visibile sullo schermo, il secure boot su Android \u00e8 gi\u00e0 in funzione. Verified Boot \u00e8 l’implementazione di secure boot di Android, ed \u00e8 uno dei meccanismi di sicurezza pi\u00f9 importanti dell’intero sistema. Il processo funziona in una catena di fiducia: il bootloader verifica l’integrit\u00e0 del recovery, che verifica la partizione di sistema, che verifica il resto del sistema operativo. Se qualsiasi collegamento in quella catena \u00e8 stato manomesso, il dispositivo lo rileva e rifiuta di avviarsi o avverte chiaramente l’utente<\/cite>.<\/p>\n
        Auditing Continuo della Firmware<\/h3>\n
        Implemento uno script di auditing mensile nei miei ambienti:<\/p>\n
        #!\/bin\/bash\n# Verifica mensile dell'integrit\u00e0 della firmware\n\nfor device in $(adb devices | grep -v devices); do\n  if [ -z \"$device\" ]; then continue; fi\n  \n  # Estrarre info della build\n  adb -s $device shell getprop ro.build.fingerprint > \/tmp\/fingerprint_$device.txt\n  adb -s $device shell getprop ro.build.version.security_patch > \/tmp\/patch_level_$device.txt\n  \n  # Verificare contro database storico\n  if ! grep -q \"$(cat \/tmp\/fingerprint_$device.txt)\" \/var\/lib\/android_firmware_whitelist.db; then\n    echo \"[CRITICAL] Nuova fingerprint rilevata su $device - Verificare manualmente\"\n    # Inviare alert ai security team\n    mail -s \"Anomalia firmware su $device\" security@company.com\n  fi\ndone\n<\/code><\/pre>\n
        Protezione degli SDK e Validazione delle Dipendenze<\/h2>\n
        La maggior parte delle app mobile integra dipendenze esterne, incluse open-source e proprietarie, a volte come SDK solo binari o moduli offuscati. I problemi di sicurezza, come vulnerabilit\u00e0, errori di configurazione o logica malevola, sono difficili da rilevare tramite sole scansioni a livello di codice sorgente o fuzzing superficiale. In poche parole, ogni app ha una catena di approvvigionamento, e i dispositivi mobili ereditano dozzine, se non centinaia, di queste catene<\/cite>.<\/p>\n
        Verifica dell’Integrit\u00e0 degli SDK Integrate<\/h3>\n
        \/\/ Verificare il certificato di firma dell'SDK all'avvio dell'app\npublic class SDKIntegrityChecker {\n    \n    public static boolean verifySDKSignature(Context context, String sdkPackageName) {\n        try {\n            PackageInfo pkgInfo = context.getPackageManager()\n                .getPackageInfo(sdkPackageName, PackageManager.GET_SIGNATURES);\n            \n            Signature[] signatures = pkgInfo.signatures;\n            for (Signature signature : signatures) {\n                byte[] signatureBytes = signature.toByteArray();\n                MessageDigest md = MessageDigest.getInstance(\"SHA-256\");\n                byte[] hash = md.digest(signatureBytes);\n                \n                \/\/ Confrontare con hash conosciuto\n                String hashHex = bytesToHex(hash);\n                if (!isKnownSignature(hashHex)) {\n                    Log.e(\"SDKCheck\", \"Firma SDK non autorizzata: \" + sdkPackageName);\n                    return false;\n                }\n            }\n            return true;\n        } catch (Exception e) {\n            Log.e(\"SDKCheck\", \"Errore nella verifica SDK\", e);\n            return false;\n        }\n    }\n}\n<\/code><\/pre>\n
        Developer Verification e Accountability<\/h2>\n
        Nel 2026, a partire da settembre, Google richieder\u00e0 che tutte le app Android installate su dispositivi certificati in Brasile, Indonesia, Singapore e Tailandia siano registrate da sviluppatori verificati. Per altre regioni, questo requisito verr\u00e0 implementato gradualmente dal 2027 in poi<\/cite>.<\/p>\n
        Il mandato di Google richiede che ogni sviluppatore che vuole che la sua app sia installabile su un dispositivo Android certificato provi la propria identit\u00e0. Google sta confermando chi \u00e8 lo sviluppatore, il che introduce un nuovo livello di responsabilit\u00e0 nell’ecosistema. Se uno sviluppatore verificato distribuisce malware, Google pu\u00f2 rimuoverli pi\u00f9 efficacemente e impedire loro di semplicemente creare un nuovo account anonimo per continuare le loro attivit\u00e0<\/cite>.<\/p>\n
        Link Interni Pertinenti<\/h2>\n
        Se sei interessato ad approfondire le strategie di sicurezza multi-layer, consiglio di leggere i miei articoli correlati:<\/p>\n