Le Backdoors

Introduzione

Cosa c’entrano le backdoors con il Visual Basic? C’entrano eccome, perché vi spiegherò non solo come funzionano, ma anche come se ne potrebbe fare una “rudimentale” (a solo scopo informativo e teorico). È solo uno spunto, perché si dovrebbe lavorare con il C++, poich´ con Visual Basic l’utente vittima dovrebbe avere installate le relative runtimes e la RAM richiesta sarebbe eccessiva. Tuttavia per i nostri scopi, il Basic funziona benissimo. Quest’articolo serve solo per farvi capire cosa siano questi giochini che ora vanno tanto di moda e, di conseguenza, come difendersi. Prima di procedere à meglio che leggiate (o rileggiate, spero) il precedente articolo (Il controllo Winsock.ocx, ndr), visto che il nostro compagno di viaggio sarà ancora Winsock.ocx :-)

Prima di tutto, cos’à una backdoor? Tradotto alla lettera significa porta posteriore. In effetti è come una porta che permette ad un utente di “far visita” al vostro pc senza che ve ne accorgiate. Si divide in due parti: un client e un server (ovvio che il client è nelle mani dell’intruso e il server in quelle della nostra immaginaria vittima!). Il server è installato sul computer della vittima e si avvia automaticamente ad ogni boot e aspetta che vi colleghiate. Se il pirata vi trova in rete, manda delle stringhe al server (che è sempre in ascolto su una porta UDP) e quest’ultimo fa qualcosa. Un esempio?

Pirata invia ciao

Il server interpreta ciao come cancella file c:\windows\b.txt

In pratica il server sa che la stringa x corrisponde evento y. Ingegnoso, no? Una volta stabilita la connessione il client ha nelle mani l’altro PC. Il passaggio di tutti questi dati è facilmente intercettabile da un utente medio con un netstat dal prompt di MS-DOS, ma non posso dilungarmi su quest’aspetto perché con il Visual Basic c’entra poco :) Vediamo ora come costruirne un semplice prototipo. Faremo in modo che il client possa inviare due stringhe (a cui sono associati due eventi). Ovviamente dovreste costringere un vostro amico ad installare un server, pertanto vi consiglio di provare solo sul vostro pc locale. Il 75% del lavoro viene compiuto dal server che, oltre ad “interpretare” i dati ricevuti deve poi fare qualcosa. Ecco come potrebbe essere il codice del client:

Private Sub cmdConnetti_Click()

Winsock.RemoteHost = txtVittima.Text ‘raccoglie i dati

Winsock.RemotePort = txtPorta.Text

Winsock.Connect ‘si connette

End Sub

Private Sub cmdMandaMessaggio_Click() ‘questa parte mette un MsgBox sullo schermo ;)

Winsock.SendData “mess” ‘invia una stringa che verrà interpretata dal server

End Sub

Private Sub cmdEsgui_Click() ‘questo invece esegue Telnet.exe

Winsock.SendData “esegui”

End Sub

Sembra senza senso, vengono inviate solo delle semplicissime stringhe. In effetti è così. Il compito più arduo è affidato al server. Ovvio che il codice riportato sopra non è molto corretto: innanzitutto prima di inviare qualcosa bisognerebbe accertarsi di essere connessi ed ` buona norma inserire sempre, all’inizio della procedura, un “On Error GoTo x” per evitare che il programma si chiuda bruscamente. Eccovi il codice di un rudimentale server:

Private Sub Winsock_DataArrival(ByVal bytesTotal As Long)

Dim strData As String

Winsock.GetData strData, vbString

Select Case strData

Case Is = “mess”

MsgBox “Ho distrutto il tuo pc!”

Case Is = “esegui”

Shell “telnet.exe”, 1

End Select

End Sub

Finito! È davvero facile, poi però la cosa si complica perché il server deve essere invisibile agli occhi della vittima, si deve caricare all’avvio e non basta che esegua Telnet o che visualizzi un messaggio, si può fare qualsiasi cosa. Questo è solo un esempio, come vi ho già detto, ma basta usare la fantasia. Ora che sapete come funzionano, sarà più facile difendervi. Se ci pensate bene, anche i normali programmi funzionano in questo modo, solo che alla recezione di una stringa non creano danno, ma magari vi riferiscono cosa ha da dirvi il vostro amico (sto parlando di chat). Qual è il punto cruciale? Lo scambio di messaggi tra le due parti, che sono ben visibili. La volta scorsa vi ho detto come costruire una utility che avrebbe dovuto monitorare la porte e che vi avrebbe avvertito in caso di attacco. Bene, è venuto il momento di provare! Le backdoors non inviano stringhe a casaccio, ma spesso adottano un loro protocollo. Che significa? Se per esempio dovessero spedire abcd, magari (per semplice ipotesi) scriverebbero */-+, ma a noi non cambia assolutamente nulla. Tutto questo semplicemente per non inviare testo in chiaro. Come accennato in precedenza, anche se quello citato è solo un esempio, un programma del genere (che può essere anche usato per scopi benefici) dovrebbe caricarsi ad ogni avvio, poiché il server deve rimanere in ascolto sempre su una porta per aspettare ordini. Basta inserire una stringa in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run che richiami il nome del vostro programma (p.e. c:\windows\system\ciao.exe”).

Conclusioni

Anche per questa volta ho finito, se non vi è chiaro qualcosa, potete contattarmi, come sempre. Sopra avete trovato solo delle informazioni vaghe su ciò che potreste realizzare e su come farlo. Questo perchè avevo solo intenzione di darvi delle linee guida da seguire, al resto dovete pensare voi. Ci sono altre faccende da sbrigare: il server deve essere chiamato ad ogni avvio e perciò dovete sapere dove esso si troverà. L’esecuzione deve essere invisibile: il task non deve risultare da nessuna parte, i dati inviati devono essere criptati, etc. Ad ognuno di questi problemi c’è un rimedio. Come detto, il mio voleva solo essere una spiegazione di cosa sono questi programmi che tanto spaventano gli utenti e come è facile difendersi, non un invito a peggiorare la situazione

Both comments and pings are currently closed.

Comments are closed.