"De nombreux programmes malicieux". Haha je bataille contre ce faux-ami qui signifie en français "avec malice". Le programme est malvaillant, ce n'est pas un petit polisson !
C'est pas mal comme vidéo, c'est accessible, mais ça ne fait pas l'impasse sur la partie technique. Dommage sur les vidéos IA à 4:51 de montrer du JavaScript en parlant de programmation Bash.
0:38 - Ca commence mal... Edimbourg c'est pas DU TOUT en Angleterre, mais c'est la capitale de l'écosse... Tu tiens pas a ta vie avec ce genre d'erreur !
in summary, do not let a web service pass query parameters inside the value of an environment variable, that is freely "expandable" in other subprocesses to create command lines that are executed as is. The problem is the simple presence of a single ';' inside such query paramer: the expanded command line becomes two command lines (for the shell syntax: it does not matter if it's bash, or ksh, or cmd.exe or powershell.exe, they behave the same), the expected command may fail to run, but the second command line will run unconditionnaly jut after the first commend (independantly if it fails or not) and with the same local privileges as the 1st command, so you can place arbitrary command just after the 1st semi-colon (and to make sure that this one will not fail (due to the presence of other parameters in the unexpanded command, just after the name of the environment variable) jsut place an extra semicolon to your desired command (the rest will also run unconditionnaly). The only solution is, before placing any value into an environment variable and coming directly from incoming web requests, to make sure that this value is "safe". If that value is to be used by a shell and must not break a command line, it MUST NOT contain any unsafe characters that causes the shell to have specific behavior: braces, semicolons, backquotes, pipes, lower-than/greater-than, quotation marks, wildcards that are expansible into file names or paths in the shell execution context, dollar signs or percent signs that expand an internally exposed shell variable whose value is not known and present in the client query (etc., there are many possibility with command syntaxes), so the parsed value MUST be reencoded ("URL-encoding" is insufficient, only "Base64" is safe and also sufficiently compact compared to hexadecimal). But passed values must ALSO have a limited length that has been tested to be sufficient and safe (to avoid various possible buffer overflows later in the exploited commands launched by the shell). But the problem is in fact more generic than with shells: CGI allows launching any child program (not just a shell or a shell script), passing it arbitrary environment variables with arbitrary values: CGI is unsafe if it is used by the webserver directly without validating ALL field names and values that will be passed to such environment variables via the CGI interface. But CGI is in fact not required: the webserver may as well compute the whole command line itself, without passing directly any variable and needing any shell executor to interpret it. It could pass values only as command parameters. Why CGI is used? Just because it allows "forking" child processes to "isolate" requests between each other. But it is intrinsicly unsafe as web requests will allow the webserver to execute an arbitrarily large number of child processes, causing a DOS attack on the server (not enough memory for all children, or not enough available ports, or file handles or other resources to communicate). CGI is deprecated and must no longer be used (preferably replaced by FastCGI), instead you need a controlled number of "worker processes", which will run web requests isolately within theuir own quota limits (ordered in a queue, possibly with priorities, depending on credentials/privileges of remote clients that want to execute web requests). But here also it is unsafe if the way to pass values from the client's query to the child workers goes via environment variables, memory blocks, temporay file handles, which are still not guarded by length limitations and safe reencoding. This is in fact the same problem as common "SQL injections" that are caused by the of common SQL interprets, that also accept scripts with multiple requests to run in a batch. Here also you need validation of length values (truncating those from the request if needed, to just what is needed to be valid), and of their encoding (beware of values containing any metacharacter, such as '?' or "*' for the SQL "LIKE" operator in "WHERE" or "HAVING" clauses, or as well the effect of quotation marks and other separators specific to the SQL dialect parsed by the processes launched either by CGI, or by worker processes waiting commands with FastCGI and communicating via internal pipes or shared memory or other IPC mechanisms with the main parent process of the webserver, or by constructing requests directly in string buffers, even if they are immunized from buffer overflows). In all these cases, the problem is to depend on a too generic parser for a complex scriptable language (any shell or SQL engine) and the complex syntax they need to isolate arbitrary valid values. Delegating everything from the webserver to a child process that will be the only one to make parameter validation is wrong. Such basic safety validation must be made directly inside the main webserver before it attempts any communication with child processes, or worker threads. The problem is that validation at this level i nthe the main webserver is extremely generic (the webserver does not really know itself the variety of requests needed by any web app using it): it can only use strong isolation of values, with safe reencodings but without knowing the datatype of these values and the exact useful range for these values (it will be up to child processes or worker threads to decode it and validate again locally according to the webapp logic and expected types, and maximum lengths/ranges, or enumerated values). Other things to consider is the case of query parameters passed via POST and not via the query string: it is a priory safer, because you can easily parse the command block and check its validity directly inside the main webserver, without needing to understand the logic of the hosted webapp. The encoding of the command block coming with POST-like requests is well-documented. But you can pass arbitrarily large blocks, containing an arbitrary number of variables with arbitrary values (some values will be very tiny, some will be very large, e.g. for file content uploads): the webserver needs to allocate space for the command block on a well isolated temporary folder, and perform its cleanup very rapidly after the webrequest has been handled by child processes or threads (even if these are crashing): the webserver must never expect that this storage space will be cleaned/freed by children handling the request. The same is true if the webserver uses shared memory blocks to communicate with IPC mechanism with child processes or threads, or allocates a specific temporary port to communicate with another local server (abandon FTP for that reason!), or adds database entries for pending requests to be executed, all those resources should never be freed by the workers but directly by the parent server (or its associated scheduler).
Bon. Il est pro en informatique... et un peu moins calé en géopolitique... D'accord. Comme il fait des vidéos d'informatique, je peux vivre avec ça. 😅 Mais si vraiment je réfléchis à l'erreur, ici, je dirais que les Français (sauf en Bretagne, Alsace ou Corse (?), je sais pas...) ne conçoivent pas trop la notion d'avoir un NIVEAU d'Union entre les pays-nations et le niveau international (mondial:~200 pays). La "bévue" étonnerait peut-être un tout petit peu moins un États-Unien, un Québécois ou même un Suisse, tiens... Pour preuve, l'histoire de Mitterand reçu à Neuchâtel (Suisse) par le président de l'État de Neuchâtel, plutôt que par le président de la Confédération suisse dans son ensemble. Neuchâtel est certes un "canton" de la Suisse, mais c'est bien la "République et canton de Neuchâtel". Bref, revenons au bash, cgi, et autres joyeusetés linuxiennes... Bravo pour cette vidéo !
@@jeanheonofficial Oui mais il a dit "Angleterre", pas Royaume-Uni. C'est comme si quelqu'un disait "Paris dans Les Landes" et que tu avais dit "Paris est en France"
Wow, je me suis posé la question de ce que ça voulait dire cette syntaxe quand j'ai vu cet exemple il y a deux jours dans une liste de Payload Mdr merci, il y a un site ou une source qui référence le pourquoi du comment une commande existe ?
Je trouve le format un peu sensationnel mais ne colle pas tant à la réalité, c'est dommage parce que je trouve que ça nuit à la crédibilité, je m'attendais au problème qui a surgit sur le protocole BGP du côté de l'Inde, et non en fait, donc clairement pas une "faille qui embrase Internet", de plus 1 million c'est très faible comparé aux nombres de machines en service. Ensuite quand je regarde la documentation pour test la CVE-2014-6271 je m'aperçois que bash ne serait vulnérable mais pourtant dans la vidéo ce serait le seul concerné, si je teste sur zsh et que j'en crois les tests alors zsh est vulnérable, un non sens. cgi-bin est effectivement obsolète, le fait que le code affiche shellshock ou shellshock minifié n'a rien d'une faille, c'est un abus de langage de considérer que c'est un problème de bash cela ne suffit pas à faire en sorte que l'on puisse accéder à une machine distante, de plus admettons qu'on affiche /etc/passwd ou /etc/hostname ce n'est pas un problème en soi et normalement quand on gère un serveur web on créer un client dédié qui a certains droits et pas d'autres justement pour limiter la casse. Dans le cas de /etc/shadow en principe un simple utilisateur n'y a pas accès donc là encore le réel problème c'est si l'utilisateur distant prends le contrôle de root, le shellshock ne sert à rien car il a déjà un contrôle absolu sur la machine. Si il y a une vielle faille côté web qui existe toujours et qui n'est quasiment jamais patché uniformément c'est le "bon vieux" remote shell exploit. Enfin concernant la série Mr Robot, elle n'est pas critique concernant l'informatique en général, j'ai lâché à la première saison, je recommande plutôt Person of Interest qui est bien plus réaliste et intéressante.
"De nombreux programmes malicieux". Haha je bataille contre ce faux-ami qui signifie en français "avec malice". Le programme est malvaillant, ce n'est pas un petit polisson !
C’est pas plutôt comme une maladie maligne qui signifie « mauvais, méchant »
@@aviron2830 😂😂😂😂😂😂... Vérifie stp.
@@newlysama2846 ouvre un dictionnaire 😉
malicieux est aussi un synonyme de malfaisant
Syn. *Malintentionné
C'est pas mal comme vidéo, c'est accessible, mais ça ne fait pas l'impasse sur la partie technique.
Dommage sur les vidéos IA à 4:51 de montrer du JavaScript en parlant de programmation Bash.
Haha tu as l'oeil ! Je vais taper sur les doigts du monteur 😋
0:38 - Ca commence mal... Edimbourg c'est pas DU TOUT en Angleterre, mais c'est la capitale de l'écosse... Tu tiens pas a ta vie avec ce genre d'erreur !
Et le fix, il a constitué en quoi ? Ne pas executer ce qui se trouve apres le corps de la fonction ?
in summary, do not let a web service pass query parameters inside the value of an environment variable, that is freely "expandable" in other subprocesses to create command lines that are executed as is. The problem is the simple presence of a single ';' inside such query paramer: the expanded command line becomes two command lines (for the shell syntax: it does not matter if it's bash, or ksh, or cmd.exe or powershell.exe, they behave the same), the expected command may fail to run, but the second command line will run unconditionnaly jut after the first commend (independantly if it fails or not) and with the same local privileges as the 1st command, so you can place arbitrary command just after the 1st semi-colon (and to make sure that this one will not fail (due to the presence of other parameters in the unexpanded command, just after the name of the environment variable) jsut place an extra semicolon to your desired command (the rest will also run unconditionnaly).
The only solution is, before placing any value into an environment variable and coming directly from incoming web requests, to make sure that this value is "safe". If that value is to be used by a shell and must not break a command line, it MUST NOT contain any unsafe characters that causes the shell to have specific behavior: braces, semicolons, backquotes, pipes, lower-than/greater-than, quotation marks, wildcards that are expansible into file names or paths in the shell execution context, dollar signs or percent signs that expand an internally exposed shell variable whose value is not known and present in the client query (etc., there are many possibility with command syntaxes), so the parsed value MUST be reencoded ("URL-encoding" is insufficient, only "Base64" is safe and also sufficiently compact compared to hexadecimal). But passed values must ALSO have a limited length that has been tested to be sufficient and safe (to avoid various possible buffer overflows later in the exploited commands launched by the shell).
But the problem is in fact more generic than with shells: CGI allows launching any child program (not just a shell or a shell script), passing it arbitrary environment variables with arbitrary values: CGI is unsafe if it is used by the webserver directly without validating ALL field names and values that will be passed to such environment variables via the CGI interface. But CGI is in fact not required: the webserver may as well compute the whole command line itself, without passing directly any variable and needing any shell executor to interpret it. It could pass values only as command parameters. Why CGI is used? Just because it allows "forking" child processes to "isolate" requests between each other. But it is intrinsicly unsafe as web requests will allow the webserver to execute an arbitrarily large number of child processes, causing a DOS attack on the server (not enough memory for all children, or not enough available ports, or file handles or other resources to communicate). CGI is deprecated and must no longer be used (preferably replaced by FastCGI), instead you need a controlled number of "worker processes", which will run web requests isolately within theuir own quota limits (ordered in a queue, possibly with priorities, depending on credentials/privileges of remote clients that want to execute web requests). But here also it is unsafe if the way to pass values from the client's query to the child workers goes via environment variables, memory blocks, temporay file handles, which are still not guarded by length limitations and safe reencoding.
This is in fact the same problem as common "SQL injections" that are caused by the of common SQL interprets, that also accept scripts with multiple requests to run in a batch. Here also you need validation of length values (truncating those from the request if needed, to just what is needed to be valid), and of their encoding (beware of values containing any metacharacter, such as '?' or "*' for the SQL "LIKE" operator in "WHERE" or "HAVING" clauses, or as well the effect of quotation marks and other separators specific to the SQL dialect parsed by the processes launched either by CGI, or by worker processes waiting commands with FastCGI and communicating via internal pipes or shared memory or other IPC mechanisms with the main parent process of the webserver, or by constructing requests directly in string buffers, even if they are immunized from buffer overflows).
In all these cases, the problem is to depend on a too generic parser for a complex scriptable language (any shell or SQL engine) and the complex syntax they need to isolate arbitrary valid values. Delegating everything from the webserver to a child process that will be the only one to make parameter validation is wrong. Such basic safety validation must be made directly inside the main webserver before it attempts any communication with child processes, or worker threads. The problem is that validation at this level i nthe the main webserver is extremely generic (the webserver does not really know itself the variety of requests needed by any web app using it): it can only use strong isolation of values, with safe reencodings but without knowing the datatype of these values and the exact useful range for these values (it will be up to child processes or worker threads to decode it and validate again locally according to the webapp logic and expected types, and maximum lengths/ranges, or enumerated values).
Other things to consider is the case of query parameters passed via POST and not via the query string: it is a priory safer, because you can easily parse the command block and check its validity directly inside the main webserver, without needing to understand the logic of the hosted webapp. The encoding of the command block coming with POST-like requests is well-documented. But you can pass arbitrarily large blocks, containing an arbitrary number of variables with arbitrary values (some values will be very tiny, some will be very large, e.g. for file content uploads): the webserver needs to allocate space for the command block on a well isolated temporary folder, and perform its cleanup very rapidly after the webrequest has been handled by child processes or threads (even if these are crashing): the webserver must never expect that this storage space will be cleaned/freed by children handling the request. The same is true if the webserver uses shared memory blocks to communicate with IPC mechanism with child processes or threads, or allocates a specific temporary port to communicate with another local server (abandon FTP for that reason!), or adds database entries for pending requests to be executed, all those resources should never be freed by the workers but directly by the parent server (or its associated scheduler).
Pretty good and deep analysis. I like it 😉👌
J'aime bien tes vidéos ainsi que tes explications plus facile à comprendre 🔥🔥
Merci 🙌
Bon. Il est pro en informatique... et un peu moins calé en géopolitique... D'accord.
Comme il fait des vidéos d'informatique, je peux vivre avec ça. 😅
Mais si vraiment je réfléchis à l'erreur, ici, je dirais que les Français (sauf en Bretagne, Alsace ou Corse (?), je sais pas...) ne conçoivent pas trop la notion d'avoir un NIVEAU d'Union entre les pays-nations et le niveau international (mondial:~200 pays).
La "bévue" étonnerait peut-être un tout petit peu moins un États-Unien, un Québécois ou même un Suisse, tiens...
Pour preuve, l'histoire de Mitterand reçu à Neuchâtel (Suisse) par le président de l'État de Neuchâtel, plutôt que par le président de la Confédération suisse dans son ensemble. Neuchâtel est certes un "canton" de la Suisse, mais c'est bien la "République et canton de Neuchâtel".
Bref, revenons au bash, cgi, et autres joyeusetés linuxiennes...
Bravo pour cette vidéo !
Édimbourg est en Écosse, pas en Angleterre...
Pas faux
Édimbourg est au Royaume-Uni 💂
@@jeanheonofficial Oui mais il a dit "Angleterre", pas Royaume-Uni. C'est comme si quelqu'un disait "Paris dans Les Landes" et que tu avais dit "Paris est en France"
@@oportbis Je le sais :)
sh a t’il été impacté?
Super intéressant, Mr robot est ma meilleur ma série aussi. Je cherche une série qui serait pratique comme elle , mais j'en trouve pas pour le moment
Tu peux aussi regarder sillicon valley mais bon ça se penche plus sur la programmation.
Trés bonne vidéo!
Merci 😁
Merci moi je suis un script kidi technicien réseaux inf0👤
Je viens de root-me en voyant ton profile et j'adore tes vidéos
Merci et bienvenue. Profite de RootMe c'est grâce à cette plateforme que j'en suis la maintenant 😉
nickel bonne vidéo
Très bonne vidéo💯
Merci 💯
🔥🔥
Merci Thibaud
De rien 😉
4:32 : Logo CGI (boîte de service informatique canadienne très connue) pour illustrer « cgi-bin », ça pique. 😂
en.m.wikipedia.org/wiki/CGI_Inc.
J'attends mon chèque de leur part 👀#pubdéguisé #honteux
@@trackflaw ou leur procès 😅
Pour les futures OPs, utilise leur logo actuel 😋
Passionnant^^
Merci 👌
J'aime trop tes videos. pouvez nous parler des vulnabilité web bref les top 10 de l'owasp
Oui pourquoi pas
Ok merci
Wow, je me suis posé la question de ce que ça voulait dire cette syntaxe quand j'ai vu cet exemple il y a deux jours dans une liste de Payload Mdr merci, il y a un site ou une source qui référence le pourquoi du comment une commande existe ?
De rien. Il n'existe pas de site universel. Fouine un peu sur internet tu finiras pas trouver des explications
Je trouve le format un peu sensationnel mais ne colle pas tant à la réalité, c'est dommage parce que je trouve que ça nuit à la crédibilité, je m'attendais au problème qui a surgit sur le protocole BGP du côté de l'Inde, et non en fait, donc clairement pas une "faille qui embrase Internet", de plus 1 million c'est très faible comparé aux nombres de machines en service.
Ensuite quand je regarde la documentation pour test la CVE-2014-6271 je m'aperçois que bash ne serait vulnérable mais pourtant dans la vidéo ce serait le seul concerné, si je teste sur zsh et que j'en crois les tests alors zsh est vulnérable, un non sens.
cgi-bin est effectivement obsolète, le fait que le code affiche shellshock ou shellshock minifié n'a rien d'une faille, c'est un abus de langage de considérer que c'est un problème de bash cela ne suffit pas à faire en sorte que l'on puisse accéder à une machine distante, de plus admettons qu'on affiche /etc/passwd ou /etc/hostname ce n'est pas un problème en soi et normalement quand on gère un serveur web on créer un client dédié qui a certains droits et pas d'autres justement pour limiter la casse. Dans le cas de /etc/shadow en principe un simple utilisateur n'y a pas accès donc là encore le réel problème c'est si l'utilisateur distant prends le contrôle de root, le shellshock ne sert à rien car il a déjà un contrôle absolu sur la machine.
Si il y a une vielle faille côté web qui existe toujours et qui n'est quasiment jamais patché uniformément c'est le "bon vieux" remote shell exploit.
Enfin concernant la série Mr Robot, elle n'est pas critique concernant l'informatique en général, j'ai lâché à la première saison, je recommande plutôt Person of Interest qui est bien plus réaliste et intéressante.
L'apport de votre commentaire me permet de prendre connaissance de trucs auxquels je devrai jeter un coup d'oeil afin d'apprendre... Merci!
Edinbourg en Angleterre ?
Non au Vénézuéla