domenica 16 novembre 2025

Git: Passare ad un branch esistente

Per passare a un branch esistente si utilizza il comando tradizionale:
git checkout <branch>
Ad esempio, per spostarsi sul branch Test:
git checkout Test

L’operazione sposta il puntatore HEAD affinché punti al branch Test attivo: da quel momento, eventuali commit modificheranno il branch Test.

git checkout
FIG 1 - git checkout



Effetti del cambio di branch

  • HEAD punta al branch attivo
    Dopo git checkout test, HEAD non punta direttamente a un commit ma al riferimento simbolico del branch Test (es. HEAD -> Test). Il commit successivo aggiornerà il puntatore Test al nuovo commit.
  • Modifiche alla working directory
    Al cambio di branch Git aggiorna i file nella working directory per riflettere lo snapshot dell’ultimo commit del branch di destinazione. Se le variazioni locali impediscono un passaggio netto (ad es. file modificati che verrebbero sovrascritti), Git impedisce lo switch e segnala il conflitto.
  • Creazione di nuovi commit sul branch attivo
    Dopo il checkout, un commit (ad esempio git commit -a -m 'Modifica readme
    ') avanzerà esclusivamente il puntatore del branch attivo, lasciando gli altri branch invariati. Di conseguenza, è possibile creare storie divergenti in modo isolato su differenti branch (FIG 2).

Commit su Branch Test
FIG 2 - Commit su Branch Test

Esempio di flusso operativo

Creazione branch (senza switch):
git branch Test


Switch al branch Test:
git checkout Test

Modifica e commit su Test:
vim readme.txt
git commit -a -m "Modifica readme"



Commit su nuovo branch
FIG 3 - Commit su nuovo branch

Ritorno a master:
git checkout master
Cambio Branch. HEAD su master
FIG 4 - Cambio Branch. HEAD su master

Questo riporta HEAD su master e ripristina i file alla versione indicata da master.


Divergenza della cronologia e visualizzazione

Quando si effettua lavoro parallelo su due branch differenti (ad esempio Test e master), la cronologia si diverge; successivamente le due linee potranno essere unite tramite merge o rebase. Per ispezionare la storia completa e visualizzare i punti di divergenza è utile il comando:

git log --oneline --decorate --graph --all

git log
FIG 5 - git log

Note operative e avvisi importanti

git log non mostra sempre tutti i branch: per default git log visualizza la storia a partire dal commit riferito dal branch attualmente selezionato. Per vedere la storia di un branch specifico usare git log <branch>; per mostrare tutti i branch usare --all.

Cambiare branch modifica i file sul disco: switching ripristina la working directory allo snapshot dell’ultimo commit del branch scelto. Se Git non è in grado di effettuare queste modifiche senza perdita di dati locali, il comando verrà rifiutato.

Comportamento con modifiche non committate:

  • Se si hanno modifiche locali non committate che non confliggono con i contenuti del branch di destinazione, Git generalmente permette lo switch mantenendo le modifiche.
  • Se ci sono conflitti, Git bloccherà lo switch: in tal caso è necessario committare, stashare (git stash) o ripristinare (git restore) le modifiche prima di procedere.
Operazione atomica di creare+switch: è possibile creare un nuovo branch e passare a esso con un solo comando: 
git checkout -b <newbranch>
oppure, nelle versioni moderne di Git (≥ 2.23), usando git switch:
git switch -c <newbranch>


git switch (comandi raccomandati nelle versioni moderne)

A partire da Git 2.23 è consigliato usare git switch per le operazioni di cambio branch (più leggibile e focalizzato rispetto al multitool git checkout):

  • Passare a un branch esistente:
    git switch Test
  • Creare un nuovo branch e passare a esso:
    git switch -c new-branch
    oppure
    git switch --create new-branch
  • Tornare al branch precedentemente attivo:
    git switch -

git switch separa chiaramente le semantiche di “cambio branch” da quelle di “ripristino file” che git checkout tradizionalmente confliggeva.


Best practice

  • Non lavorare su main/master direttamente — usare feature branch (feature/…), bugfix branch (bugfix/…) o hotfix branch (hotfix/…) per isolare il lavoro.
  • Eseguire commit atomici e frequenti: commit logici e piccoli rendono il merge e il debug più semplici.
  • Sincronizzare spesso con il remoto (git fetch + git merge/rebase) prima di iniziare un lavoro esteso, per ridurre la probabilità di conflitti.
  • Usare git switch quando possibile per migliorare chiarezza e sicurezza delle operazioni.
  • Usare git stash per mettere temporaneamente da parte modifiche non ancora pronte se è necessario effettuare uno switch immediato.
  • Visualizzare la storia con grafo (git log --oneline --decorate --graph --all) per avere un quadro completo delle divergenze e dei punti di merge.


Sintesi rapida dei comandi

OperazioneComando
Creare un branch senza switchgit branch Test
Creare e switchare (una riga)git checkout -b Test / git switch -c Test
Switchare su branch esistentegit checkout Test / git switch Test
Tornare all'ultimo branchgit checkout - / git switch -
Visualizzare grafo completogit log --oneline --decorate --graph --all
Mettere da parte modifiche non committategit stash push -m "work-in-progress"
Ripristinare stashgit stash pop




domenica 2 novembre 2025

Cybersecurity: HikvisionExploiter, tool open source utilizzato per attaccare telecamere IP Hikvision

I dispositivi Internet of Things (IoT), in particolare le telecamere IP di sorveglianza, rappresentano un elemento critico nelle architetture di rete moderne. La loro crescente diffusione ha parallelamente aumentato la superficie di attacco esposta, rendendo la sicurezza del firmware e la corretta configurazione imperative. Il presente articolo si concentra sull'analisi di un toolkit di penetration testing noto come "HikvisionExploiter" progettato per identificare e sfruttare in modo automatizzato le vulnerabilità note nelle telecamere IP Hikvision.

ATTENZIONE:
Danneggiare/violare un sistema informatico (anche da remoto) rappresenta un reato penale. Le informazioni contenute in questo articolo sono fornite esclusivamente a scopo didattico, informativo e di ricerca sulla sicurezza e vanno utilizzate solo per testare/verificare sistemi di cui si è titolari. Declino ogni responsabilità civile e penale derivante da un utilizzo non legale delle informazioni presentate in questo articolo a solo scopo didattico.


Architettura e Funzionalità del Toolkit di Analisi

Questo strumento di sicurezza, sviluppato in Python, è concepito per automatizzare le verifiche di sicurezza sulle telecamere di rete Hikvision, concentrandosi in particolare sugli endpoint non autenticati presenti in versioni firmware specifiche, come la Versione 3.1.3.150324, e sfruttando la ben nota vulnerabilità CVE-2021-36260.

La sua potenza risiede nella capacità di eseguire una serie di test complessi in modo sequenziale e multithreaded, offrendo ai security tester una visione rapida delle vulnerabilità dei dispositivi esposti.


Fasi di Esecuzione e Analisi

Il toolkit supporta la scansione di massa, leggendo elenchi di indirizzi IP e porte (da un file targets.txt). L'approccio multithread velocizza l'identificazione dei dispositivi potenzialmente vulnerabili.

Il processo di testing si articola in diverse fasi sequenziali e automatizzate:
  1. Verifica dell'Accesso Non Autenticato (Snapshot): In una fase iniziale, viene verificata la possibilità di accedere al feed video o alle snapshot in tempo reale senza autenticazione, indicando una potenziale violazione della privacy e un accesso improprio. Tale condizione può essere dovuta ad un grave errore di configurazione o una falla nel controllo degli accessi.
  2. Recupero e Decrittografia dei file di configurazione: Successivamente, lo strumento tenta di scaricare i file di configurazione del dispositivo. Se l'accesso ha successo, utilizza algoritmi noti come AES e XOR per decifrare questi file (utilizzando librerie come pycrypto). Dai dati decrittografati, spesso in formato XML, vengono estratti dettagli critici, quali:
    -
     Credenziali utente (nomi utente e password hashing o in chiaro).
    Livelli di autorizzazione degli account.
    - Informazioni di rete e configurazione del dispositivo.
  3. Sfruttamento della Vulnerabilità Critica RCE (Remote Command Execution): Esegue un test mirato per confermare lo sfruttamento della CVE-2021-36260, provando l'esecuzione di comandi da remoto sul sistema operativo embedded della telecamera.


Prerequisiti e Configurazione dell'Ambiente di Test

Per eseguire correttamente la suite di test, sono necessari i seguenti requisiti tecnici:
  1. Ambiente Python: È richiesto Python 3.6 o superiore.
  2. Librerie Essenziali: L'installazione delle dipendenze è fondamentale. Queste sono generalmente specificate in un file requirements.txt e includono librerie come requests e pycrypto (per la gestione della decrittografia).
  3. FFmpeg (Opzionale): Sebbene non necessario per lo scanning di base, FFmpeg è richiesto per funzionalità avanzate, come l'ipotetica conversione automatica delle snapshot in un formato video continuo.


Analisi Dettagliata della Vulnerabilità CVE-2021-36260

La falla CVE-2021-36260 è un esempio lampante di quanto sia cruciale la validazione degli input nei sistemi esposti.

Meccanismo di Sfruttamento
Questa vulnerabilità è classificata come un difetto di command injection e risiede nell'inadeguata validazione dei dati forniti dall'utente in endpoint specifici del web server integrato della telecamera, come ad esempio /SDK/webLanguage. Un attacker non autenticato può manipolare i parametri di input per iniettare comandi del sistema operativo all'interno delle chiamate di sistema eseguite dalla telecamera.
  • Impatto: L'esecuzione di codice con privilegi elevati (spesso root o admin) consente all'attaccante di assumere il controllo totale del dispositivo.
  • Rilevanza: Questa falla ha interessato numerosi modelli (in particolare delle serie DS-2CD e DS-2DF) con firmware obsoleti. La sua gravità è testimoniata dall'inclusione nel catalogo KEV (Known Exploited Vulnerabilities) della CISA, indicando che è stata attivamente sfruttata in attacchi nel mondo reale.

Shell Interattiva per Pen-Testing
Una delle funzionalità avanzate del toolkit è la possibilità di stabilire una shell interattiva sul dispositivo vulnerabile (sfruttando la RCE). Ciò permette al penetration tester di eseguire comandi in tempo reale, facilitando la post-exploitation e l'analisi dettagliata del sistema operativo embedded della telecamera.


Installazione

Per l’installazione di HikvisionExploiter , una volta installato l’ambiente Python, si procede con la clonazione  del repository e l'installazione delle dipendenze:

git clone https://github.com/HexBuddy/HikvisionExploiter.git

cd HikvisionExploiter

pip3 install -r requirements.txt

Installazione di HikvisionExploiter
FIG 1 - Installazione di HikvisionExploiter


Preparazione dell'Elenco dei Target

La prima fase richiede la creazione di un file semplice (plain text), come targets.txt, contenente l'elenco dei dispositivi da testare. Il formato standardizzato richiesto è IP:PORTA, ad esempio:

192.168.1.10:80

10.10.10.20:81

Questa preparazione garantisce che lo scanner operi solo sui sistemi per i quali è stata ottenuta una previa autorizzazione esplicita al testing.


Esecuzione dello Scanner Principale

L'esecuzione del modulo di controllo (checker.py) avvia la sequenza di test automatizzata:

python3 checker.py

checker.py
FIG 2 - checker.py

Questo processo non si limita a verificare la connettività, ma esegue attivamente i check sopra descritti: verifica l'accesso alle snapshot, tenta il download e la decrittografia della configurazione e, crucialmente, testa la presenza della vulnerabilità RCE (CVE-2021-36260). I risultati completi di ogni test sono meticolosamente archiviati in directory con timestamp (logs/IP_PORT_TIMESTAMP/) per la successiva analisi forense e di reportistica.


Come visibile in FIG 3, checker.py rileva se il dispositivo è vulnerabile e, oltre alle informazioni sul dispositivo (modello, serial number, versione firmware, ecc), viene rilevata anche la password di amministratore in chiaro.

Dispositivo vulnerabile
FIG 3 - Dispositivo vulnerabile

I risultati dei test vengono riportati all'interno della directory logs. All'interno delle directory presenti in logs, troviamo il file di configurazione del dispositivo e uno snapshot che ci mostra cosa sta inquadrando la telecamera.

Logs folder
FIG 4 - Logs folder

Conoscendo la password di amministratore è possibile tentare l'accesso tramite Web al dispositivo.
Interfaccia web
FIG 5 - Interfaccia web


Shell Interattiva e Post-Exploitation 

Nel contesto di una valutazione di sicurezza completa, la possibilità di stabilire un accesso shell interattivo sul dispositivo vulnerabile è inestimabile. Questo non è un fine, ma un mezzo per comprendere l'entità del compromesso.
L'uso di uno script di shell dedicato (shell.sh) consente di inviare comandi in tempo reale:
chmod +x shell.sh && ./shell.sh 192.168.1.10:80

Se il device è vulnerabile, il tester entra in una modalità interattiva, che simula l'ambiente operativo della telecamera (es. Linux kernel 3.0.8). Questo permette di mappare i file system, verificare l'esistenza di malware e stabilire l'impatto massimo che l'esecuzione di codice remoto comporta.

Shell, modalità interattiva
FIG 6 - Shell, modalità interattiva


Tecniche di Identificazione Passiva dei Target

Per i professionisti che devono identificare i propri asset esposti a livello globale (asset discovery), il toolkit fa riferimento a tecniche di discovery basate su motori di ricerca specializzati, come Shodan. L'uso di dork specifici (query avanzate) come: 3.1.3.150324 permette di localizzare pubblicamente le telecamere che espongono la web interface con la versione di firmware nota per essere vulnerabile. Questo è anche il metodo utilizzato dagli attacker per trovare dispositivi vulnerabili.

Shodan
FIG 7 - Shodan

Il toolkit include un template compatibile con lo scanner di vulnerabilità Nuclei (nuclei-template.yaml). Ciò consente ai team di sicurezza di integrare i check specifici per questa vulnerabilità all'interno dei loro workflow automatizzati di scansione periodica:
nuclei -t nuclei-template.yaml -list targets.txt
Questo approccio ibrido (scanner dedicato + scanner generalista) massimizza la copertura dei test rilevando: feed di snapshot aperti, download di configurazione esposti e leak di informazioni utente tramite risposte XML.



Strategie di Mitigazione e Difesa

La comprensione di questi strumenti è fondamentale per implementare una difesa robusta. Le seguenti azioni rappresentano i pilastri per mitigare il rischio di sfruttamento:
  1. Aggiornamento del Firmware: La contromisura più critica è garantire che il firmware delle telecamere sia sempre aggiornato all'ultima versione fornita dal produttore. Tali aggiornamenti contengono le patch di sicurezza per vulnerabilità come la CVE-2021-36260.
  2. Segmentazione di Rete: Le telecamere IP dovrebbero essere isolate in una VLAN dedicata (ad esempio, una rete IoT o di sorveglianza) e separate dalla rete aziendale principale. L'accesso dall'esterno dovrebbe essere limitato tramite ACL (Access Control Lists) o Firewall che permettano solo il traffico strettamente necessario.
  3. Disabilitazione di Servizi Non Necessari: Disabilitare tutti i servizi di rete e gli endpoint che non sono essenziali per il funzionamento della telecamera riduce la superficie di attacco.
  4. Monitoraggio e Hardening: Utilizzare strumenti di monitoraggio del traffico di rete (IDS/IPS) per rilevare pattern di attacco noti e tentativi di sfruttamento. Inoltre, implementare una politica di password robuste e cambiare le credenziali di default.
  5. Utilizzo di Dorking/Scanner di Sicurezza: I tester possono utilizzare strumenti come Shodan o template come quelli di Nuclei (come menzionato nello strumento analizzato) per identificare proattivamente i propri dispositivi esposti con firmware obsoleto, replicando l'approccio degli attacker.