Trasferire un file con Netcat

In questo periodo, in cui in tanti non possono più lavorare, non avrei proprio la faccia di lamentarmi di non avere lavori interessanti ed invece mi è capitato un piccolo lavoretto su un sistema LoRaWAN che stiamo mettendo in piedi, di cui magari parlerò in un futuro articolo.

E così mi ritrovo davanti ad aggeggi che ancora non conosco cercando ti tirare le fila. Il principio è questo: c’è il LoRaWAN gateway, che sarebbe il coso con le antenne che riceve i segnali radio e li processa, nello specifico li demodula e li rende leggibili per il TCP. Poi c’è un firewall e poi c’è un router che mette in contatto questo sistema con il resto della rete.

Ad un certo punto della catena, c’è un software chiamato Chirpstack che si occupa di censire i messaggi arrivati dai vari apparati radio, e come lo fa? Tramite le code MQTT. E quindi visto che i messaggi sono TCP è tutto apposto no? Eh no, perché come far fare la subscription sulla coda del Chirpstack al LoRaWAN gateway è una cosa che sa solo Dio, Padre Pio e pochi altri nelle sfere celesti.

Dopo mille milioni di prove infruttuose, trovo scritto nella documentazione di Chirpstack che va installato un componente chiamato Chirpstack Gateway Bridge (che poi scoprirò non servire data la nostra implementazione) che però va installato direttamente sul LoRaWAN gateway.

Perciò mi dico, beh, gioco da ragazzi, visto che è abilitato SSH, ti pare che non c’è SCP? E infatti non c’è. Vabbè ftp? Nada. Vabbè, visto che ha accesso alla rete, vai di wget: come no, command not found. CURL??? Aricommand not found.

P.S.: Il LoRaWAN gateway è roba Cisco e loro sono famosi per rispettare gli standard…loro. Come usare roba proprietaria senza farsi sputare in faccia? Si rilasciano le specifiche rendendole di fatto uno standard.

Lungi dall’arrendermi, decido di usare il vecchio metodo dei forensi: trasferimento via netcat, che grazie a dio è disponibile sul LoRaWAN gateway.

Tu non puoi passare!!

La macchina su cui sto operando era un portatile Windows 10, per via di tutta una storia di subnet e VLAN che non sto qui a spiegare.

Ovviamente non è che posso raggiungere il Gateway così, direttamente, perché il figlio di buona donna era nattato dietro un firewall, perciò l’opzione era una sola: Tunnel SSH.

Apro putty, inserisco l’IP del firewall e, nella voce SSH->Tunneling inserisco

L4444 <IP del LoRaWAN Gateway>:4444

La 4444 è la porta su cui metterò in ascolto il netcat sul LoRa e su cui metterò in ascolto la mia macchina. La 4444 ormai è la porta ufficiale di quando faccio queste porcate tipo reverse shell e affini.

Via all’operazione

Ora mi serve il client netcat su Windows. Fortunatamente scopro che Nmap ha una versione rinomata, forse un fork, di netcat chiamato ncat. Ok è tutto pronto, faccio login SSH sul LoRaWAN Gateway, mi metto nella cartella /root e metto in ascolto netcat sulla porta 4444

nc -l -p 4444 > arm64.tar.gz

“-l” indica di mettersi in listening mode, “-p” indica la porta e il maggiore fa si che ogni cosa che arrivi su quella porta vada nel file arm64.tar.gz, per questo è importante mettere una porta che si sa non venire mai usata altrimenti il file verrebbe fuori corrotto.

E’ tempo di sparare il file di rinterzo verso il gateway

nc <IP del firewall> 4444 < arm67.tar.gz

Questa è semplice, apro una connessione netcat verso il firewall, che è l’IP dove mi connettevo in SSH, sulla porta 4444 e gli dò come input il file da trasferire.

Una volta connesso sul LoRaWAN Gateway non mi rimane che decomprimere il pacchetto e installare il software.

TL;DR

Putty:
    <ip macchina ponte>
    SSH->Tunnel: L4444 <ip macchina destinatario>:4444

Macchina destinatario:
    nc -l -p 4444 > file

Macchina sorgente:
    nc <ip macchina ponte> 4444 < file