Bloquer les attaques proc/self/environ%00 via les virtualhosts de Apache2

Un truc que j’ai pu constater en regardant les logs d’accès Apache sur le site : chaque jour, j’ai une vingtaine de tentatives d’injections via l’URL, qui ressemble à ça (celle-là date d’aujourd’hui) :

220.194.62.53 – - [12/May/2010:01:23:17 +0200] « GET /323-vtigercrm-procedure-dinstallation-et-de-changement-de-langage?module=Accounts&action=../../../../../../../../../../../../../../../proc/self/environ%00 HTTP/1.0″ 200 46444 « - » « libwww-perl/5.805″

Heureusement, et d’après ce que j’ai pu comprendre, cette commande ne fais pas grand chose chez moi dans la mesure où le rewrite de l’URL mis en place sur Apache met un peu par terre la tentative. Cela dit, je suis curieux, et ce que j’ai pu voir sur le web à propos de ce genre d’attaque ne me fait pas beaucoup plaisir.

On peut voir notamment que quand on tape sur Google « ../../../../../../../../../../../../../../../proc/self/environ%00″, on tombe sur environ 1150000 résultats, ce qui montre que le phénomène n’est pas isolé.

Qu’à cela ne tienne, je continue mes recherches, et je tombe sur un thread à propos de Joomla qui dit notamment :

Effectivement, à la racine du site, j’ai trouvé les fichiers else.php et CREDIT.php.
En les téléchargeant sur mon PC, mon anti-virus à trouvé le virus Backdoor:PHP/Phricbot.A.

J’ai supprimé ces fichiers.

J’ai ensuite installé crawltrack et crawlprotect pour surveiller les attaques et les limiter.

« Oùlààà », me dis-je. Donc comme je ne sais pas si la tentative a fonctionné, je teste sur mon serveur si je trouve un else.php et un CREDIT.php (avec un locate else.php par exemple), ce qui ne me renvoie rien. Ouf.

Mais je ne m’arrête pas là. Après une ou deux recherches sur le net, j’ai trouvé un super post sur les .htaccess, ce qui m’a permit de rajouter les lignes suivantes dans mon fichier virtualhost gérant le blog. Notez que par rapport aux lignes fournies dans le billet, j’ai enlevé la ligne « RewriteCond %{QUERY_STRING} CONFIG_EXT([|%20|%5B).*= [NC,OR] » car celle-ci n’était pas reconnue par Apache2 lors du reload. Notez également que j’ai préféré mettre ces lignes dans le virtualhost gérant mon site dans la mesure où c’est mieux pour les performances d’Apache2 (en fait, si j’ai bien compris, le virtualhost est chargé au reload d’Apache2 et pour toutes les requêtes suivantes, alors que le .htaccess est chargé à chaque requête, ce qui présente une redondance inutile).

Voilà les lignes ajoutées :

RewriteCond %{REQUEST_METHOD} (GET|POST) [NC] RewriteCond %{QUERY_STRING} ^(.*)(%3C|<)/?script(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)(%3D|=)?javascript(%3A|:)(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)document\.location\.href(.*)$ [OR]
#the following rules can block some off your url, in case of problem try to suppress them one per one until you solve it
RewriteCond %{QUERY_STRING} ^(.*)(%3D|=|%3A|%09)http%3a(%3A|:)(/|%2F){2}(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)(%3D|=|%3A|%09)ftp(%3A|:)(/|%2F){2}(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)(%3D|=|%3A|%09)ht%20tp(%3A|:)(/|%2F){2}(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)(%3D|=|%3A|%09)htt%20p(%3A|:)(/|%2F){2}(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)(%3D|=|%3A|%09)http%20(%3A|:)(/|%2F){2}(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)(%3D|=|%3A|%09)h%20ttp(%3A|:)(/|%2F){2}(.*)$ [NC,OR]
#end of potential issue rules
RewriteCond %{QUERY_STRING} ^(.*)base64_encode(.*)$ [OR]
RewriteCond %{QUERY_STRING} ^(.*)GLOBALS(=|[|%[0-9A-Z]{0,2})(.*)$ [OR]
RewriteCond %{QUERY_STRING} ^(.*)_REQUEST(=|[|%[0-9A-Z]{0,2})(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)_vti(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)MSOffice(.*)$ [OR]
RewriteCond %{QUERY_STRING} ^(.*)/etc/passwd(.*)$ [OR]
RewriteCond %{QUERY_STRING} ^(.*)//(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)ShellAdresi.TXT(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)\[evil_root\]?(.*)$ [OR]
RewriteCond %{QUERY_STRING} ^(.*)\.\./\.\./\.\./(.*)$ [OR]
RewriteCond %{QUERY_STRING} ^(.*)/proc/self/environ(.*)$ [OR] RewriteCond %{QUERY_STRING} ^(.*)(SELECT|INSERT|DELETE|CHAR\(|UPDATE|REPLACE)(.*)$ [NC]
 #Block out any script trying to set a mosConfig value through the URL
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|%3D) [OR]
# Block out any script trying to base64_encode crap to send via URL
RewriteCond %{QUERY_STRING} base64_encode.*(.*) [OR]
# Block out any script that includes a < script> tag in URL
RewriteCond %{QUERY_STRING} (<|%3C).*script.*(>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL
RewriteCond %{QUERY_STRING} GLOBALS(=|[|%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL
RewriteCond %{QUERY_STRING} _REQUEST(=|[|%[0-9A-Z]{0,2}) [OR]
# Block out any script that tries to set sbp or sb_authorname via URL (simpleboard)
RewriteCond %{QUERY_STRING} sbp(=|%20|%3D) [OR]
RewriteCond %{QUERY_STRING} sb_authorname(=|%20|%3D)
# Send all blocked request to homepage with 403 Forbidden error!

Donc, au final, je ne dis pas que cela protègera le serveur de toute attaque (surtout des attaques type DoS de toute façon), mais bon c’est déjà un cran de sécurité supplémentaire.