Ciao a tutti, oggi vi scrivo perchè stavo usando la libreria Python fbchat. Il repository è stato dismesso il 23 settembre 2020, però è ancora utilizzabile e funziona.

Durante l'utilizzo mi sono accorto di un errore presente all'interno della libreria, nella funzione get_files_from_paths chiamata dalla funzione sendLocalFiles. La funzione esegue queste righe:

def sendLocalFiles(
        self, file_paths, message=None, thread_id=None, thread_type=ThreadType.USER
    ):
        """Send local files to a thread.

        Args:
            file_paths: Paths of files to upload and send
            message: Additional message
            thread_id: User/Group ID to send to. See :ref:`intro_threads`
            thread_type (ThreadType): See :ref:`intro_threads`

        Returns:
            :ref:`Message ID <intro_message_ids>` of the sent files

        Raises:
            FBchatException: If request failed
        """
        file_paths = require_list(file_paths)
        with get_files_from_paths(file_paths) as x:
            files = self._upload(x)
        return self._sendFiles(
            files=files, message=message, thread_id=thread_id, thread_type=thread_type
        )

Il problema risiede nella funzione get_files_from_paths che è così formata:

@contextmanager
def get_files_from_paths(filenames):
    files = []
    try:
        for filename in filenames:
            file_obj = open(filename, "rb")
            file_info = (basename(filename), file_obj, guess_type(filename)[0])
            files.append(file_info)
        yield files
    finally:
        for _, fp, _ in files:
            fp.close()

La funzione get_files_from_paths sembra essere implementata correttamente come un generatore usando il decoratore @contextmanager. Tuttavia, c'è un potenziale problema nella chiusura dei file aperti.

Nella riga che inizia con for fn, fp, ft in files:, la chiamata fp.close() viene effettuata per ogni file aperto. Tuttavia, se si verifica un'eccezione durante l'iterazione dei file, ad esempio durante la lettura o l'elaborazione dei dati, il codice salterà alla riga successiva dopo l'istruzione yield files. In questo caso, i file aperti non verranno chiusi correttamente.

Analizziamo il codice riga per riga:

1. @contextmanager è un decoratore fornito dal modulo contextlib che ci permette di definire un generatore come un gestore di contesto. In questo caso, il decoratore abilita la funzione get_files_from_paths per essere utilizzata in un blocco with.

2. get_files_from_paths prende un argomento filenames, che dovrebbe essere una lista di nomi di file.

3. La variabile files viene inizializzata come una lista vuota. Questa lista conterrà le informazioni sui file aperti.

4. Viene eseguito un ciclo for che itera su ciascun filename presente nella lista filenames.

5. Per ogni filename, viene eseguita la seguente operazione:

   • basename(filename) restituisce il nome base del file senza il percorso completo.
   • open(filename, "rb") apre il file in modalità di lettura binaria e restituisce un oggetto file.
   • guess_type(filename)[0] restituisce il tipo MIME del file, prendendo solo la prima parte del risultato restituito. La funzione guess_type viene importata da fbchat.

6. Il risultato dell'operazione precedente viene aggiunto come una tupla alla lista files, che conterrà le informazioni sui file aperti.

7. Viene eseguito l'istruzione yield files, che restituisce files come valore di ritorno del generatore. Questo è il punto in cui viene "parcheggiato" il generatore e viene fornito al blocco with che lo sta utilizzando.

8. Dopo che il blocco with ha completato la sua esecuzione, il controllo ritorna al generatore. Viene eseguito un altro ciclo for che itera su ciascuna tupla (fn, fp, ft) presente in files.

9. Per ogni tupla, viene eseguita l'operazione fp.close() per chiudere il file aperto.

Per garantire che i file vengano chiusi anche in caso di eccezioni, si può utilizzare il costrutto try-finally per assicurarci che la chiusura dei file avvenga correttamente. Ecco una versione modificata della funzione che gestisce la chiusura dei file in modo sicuro:

@contextmanager
def get_files_from_paths(filenames):
    files = []
    try:
        for filename in filenames:
            file_obj = open(filename, "rb")
            file_info = (basename(filename), file_obj, guess_type(filename)[0])
            files.append(file_info)
        yield files
    finally:
        for _, fp, _ in files:
            fp.close()
            
def sendLocalFiles(
    self, file_paths, message=None, thread_id=None, thread_type=ThreadType.USER
):
    """Send local files to a thread.

    Args:
        file_paths: Paths of files to upload and send
        message: Additional message
        thread_id: User/Group ID to send to. See :ref:`intro_threads`
        thread_type (ThreadType): See :ref:`intro_threads`

    Returns:
        :ref:`Message ID ` of the sent files

    Raises:
        FBchatException: If request failed
    """
    file_paths = require_list(file_paths)
    with get_files_from_paths(file_paths) as x:
        try:
            files = self._upload(x)
        except Exception as e:
            for fn, fp, ft in x:
                fp.close()
            raise e

    return self._sendFiles(
        files=files, message=message, thread_id=thread_id, thread_type=thread_type
    )

Il Fast Flux è una tecnica utilizzata dai criminali informatici per nascondere i loro siti di phishing e consegnare malware attraverso una rete di host compromessi in continua evoluzione. Questa tecnica combina diverse strategie, come il networking peer-to-peer, il distributed command and control, il bilanciamento web-based del carico e la proxy redirection, al fine di rendere le reti di malware più resistenti al rilevamento e alle contromisure.

Come funziona?

Il concetto fondamentale del Fast Flux consiste nell'associare numerosi indirizzi IP a un singolo nome di dominio completamente qualificato (FQDN) e nel sostituire frequentemente questi indirizzi IP tramite la modifica dei record DNS. Questo processo avviene ad alta frequenza, spesso ogni pochi minuti, utilizzando una rotazione di indirizzi IP e un breve Time-To-Live (TTL) per i record delle risorse DNS. Ciò significa che quando un utente si connette a un sito web utilizzando il FQDN, in realtà si sta connettendo ogni volta a un host compromesso diverso.

Il vasto pool di indirizzi IP che ruotano non fornisce direttamente i contenuti richiesti. Infatti, i sistemi front-end compromessi agiscono come redirector, chiamati agenti di flusso (flux agents), che instradano le richieste e i dati verso i server backend. Questi server backend sono quelli che effettivamente servono i contenuti. Fondamentalmente, i nomi di dominio e gli URL dei contenuti pubblicizzati non puntano direttamente all'indirizzo IP di un server specifico, ma oscillano tra molti redirector o proxy front-end, che a loro volta inoltrano il contenuto a un altro gruppo di server backend.

Inoltre, gli attaccanti si assicurano che i sistemi compromessi utilizzati per ospitare le loro frodi abbiano la migliore banda larga e disponibilità di servizio possibile. Spesso utilizzano uno schema di distribuzione del carico che tiene conto dei risultati dei controlli di stato dei nodi, in modo che i nodi non rispondenti siano rimossi dal flusso e l'accessibilità dei contenuti sia sempre garantita.

I tipi di rete Fast Flux

Esistono due tipi principali di reti Fast Flux:

1. Reti a flusso singolo (Single Flux Networks): In queste reti, un insieme di nodi compromessi registra e deregistra i propri indirizzi come parte della lista di record di indirizzi DNS per un singolo nome DNS. Ad esempio, in una comunicazione normale tra client e server, un browser web esegue una richiesta a un server e il server soddisfa la richiesta del client. Tuttavia, in una rete a flusso singolo, la comunicazione tra il browser del client e il server viene intercettata e instradata da un redirector chiamato flux-bot e la richiesta viene reindirizzata al sito di backend. Le reti a flusso singolo modificano i record DNS per l'indirizzo IP dei loro nodi front-end di flusso con una frequenza elevata, ad esempio ogni 3-10 minuti.
2. Reti a doppio flusso (Double Flux Networks): Queste reti si caratterizzano per la registrazione e la deregistrazione di più nodi come parte dei record NS DNS. Sia i set di record A DNS che i record NS autoritativi per un dominio malevolo vengono continuamente modificati in modo circolare e pubblicizzati nella rete di servizi Fast Flux. Questo tipo di rete funziona in modo diverso rispetto alle reti a flusso singolo. Supponiamo che l'utente stia richiedendo una risorsa denominata http://abc.example.com. Quando il client effettua una richiesta DNS per abc.example.com, l'ultimo passo è diverso rispetto alla rete a flusso singolo. Nel caso delle reti a doppio flusso, l'indirizzo IP del nameserver autoritativo stesso cambia con frequenza elevata. Quando una richiesta DNS per abc.example.com viene ricevuta dal client, il nameserver autoritativo corrente inoltra le query al nodo "mothership" per ottenere le informazioni richieste. Il client può quindi tentare di stabilire una comunicazione diretta con il sistema di destinazione, anche se il sistema di destinazione è a sua volta un nodo redirector di flusso front-end in costante cambiamento. Ciò fornisce un ulteriore livello di ridondanza e sopravvivenza all'interno della rete di malware.

Prima di tutto procediamo con l'installazione dei pacchetti

sudo apt update
sudo apt install compiz compizconfig-settings-manager compiz-plugins-extra

Una volta installati i pacchetti necessari bisogna dare il comando

ccsm

A questo punto abilitiamo "SVG", "Finestre tremolanti" e "GNOME". Dopodiché procediamo:

compiz --replace

Se ricevi come codice di errore

#Window manager warning: Failed to load theme "Ambiance": Failed to find a valid file for theme Ambiance

Dovrai copiare e incollare questi comandi

sudo apt install light-themes
sudo apt install humanity-icon-theme & compiz --replace

Se le finestre hanno solo il pulsante che indica la chiusura (cioè non ci sono i pulsanti minimizza e massimizza) dovrai dare i seguenti comandi

sudo apt install gnome-tweak-tool gnome-shell
gnome-shell --replace & gnome-tweak-tool

Andare su Finestre e abilitare "minimizza" e "massimizza". Poi possiamo tornare a compiz:

compiz --replace

Ho creato un nuovo sito qui, su Eklablog, ma prima di iniziare a scrivere vorrei almeno sapere per quanto può ancora rimanere attivo il servizio. L'interfaccia è vecchia e dà l'impressione di un servizio che in meno di un mese potrebbe chiudere i battenti. Quindi mi devo informare prima di perdere tempo... Se l'azienda proprietaria ha un capitale alto o è quotata in borsa, perfetto, ma se così non fosse, cioè se fosse tipo di proprietà di una piccola attività, mi converrebbe guardare altrove. Quindi ho iniziato le mie ricerche.

Ho iniziato proprio da Eklablog e ho trovato questa pagina. È scritto chiaro e tondo, l'azienda proprietaria è "Webedia" e ha un capitale di 1.254.703,00€. Potrei fermarmi qui, ma ovviamente non lo farò. Andando avanti con le ricerche scopro che sul sito di Webedia Group Eklablog non risulta tra i servizi offerti. Strano. Su Linkedin appaiono solo 2 dipendenti presso Eklablog, ma l'indirizzo della sede è "2 rue Paul Vaillant Couturier, LEVALLOIS-PERRET, France 92300, FR", lo stesso di Webedia Group, quindi relazione confermata.

Anche EasyCounter, Informer, SiteIndices e MyIP.ms confermano l'appartenenza di Eklablog a Webedia (tramite records DNS e NS) e in più indicano che la piattaforma riceve circa 20.000~50.000 views al giorno solo sul dominio principale eklablog.com. Il problema? Il dominio eklablog.com scadrebbe in data 24 giugno 2023, mentre non ci sono informazioni relative al dominio "lo.gs". Per verificare sono andato sul sito della IANA e il WHOIS del dominio è disponibile all'indirizzo "whois.nic.gs".

Perfetto, "lo.gs" scade il 28 agosto 2023. Quindi, in teoria, il dominio exto.lo.gs esisterà almeno fino al 28 agosto dell'anno prossimo. Speriamo bene e che rimanga tutto online