Qu’est-ce qu’une attaque RCE (Exécution de code à distance) ?
L’exécution de code à distance est utilisée pour exposer une forme de vulnérabilité qui peut être exploitée lorsque l’entrée utilisateur est injectée dans un fichier ou une chaîne et que le paquet entier est exécuté sur l’analyseur du langage de programmation. Ce n’est pas le type de comportement exposé par le développeur de l’application Web. Une attaque d’exécution de code à distance peut entraîner une attaque à grande échelle qui compromettrait une application Web entière et le serveur Web. Vous devez également noter que pratiquement tous les langages de programmation ont des fonctions d’évaluation de code différentes.
Une évaluation de code peut également avoir lieu si vous autorisez les entrées utilisateur à accéder aux fonctions qui évaluent le code dans le même langage de programmation. Ce type de mesure peut être mis en œuvre à dessein pour accéder aux fonctions mathématiques du langage de programmation ou par accident car l’entrée contrôlée par l’utilisateur est conçue par le développeur pour se trouver à l’intérieur de l’une de ces fonctions. Il n’est pas conseillé de mener à bien cette ligne d’action. Beaucoup de gens trouvent malveillant d’utiliser même l’évaluation du code.
Exemple de code
Jetons un coup d’œil à un exemple d’attaque d’évaluation de code.
Il peut sembler préférable d’avoir des noms de variables générés dynamiquement pour chaque utilisateur et de stocker leur date d’enregistrement. Ceci est un exemple de la façon dont vous pouvez le faire en PHP
eval("$$user = '$regdate');As long as the username is controlled by the user's input, an attacker may create a name like this:x = 'y';phpinfo();//Le code PHP généré ressemblerait à ceci:
$x = 'y';phpinfo();// = 2016';Vous pouvez maintenant voir que la variable est appelée x mais a la valeur de y. Lorsque l’attaquant peut attribuer une autre valeur à la variable, il pourra créer une nouvelle commande en utilisant un point-virgule (;). Il peut maintenant remplir le reste de la chaîne. De cette façon, il n’obtiendra aucune erreur de syntaxe dans son travail. Dès qu’il exécute ce code, la sortie de phpinfo s’affiche sur la page. Vous devez toujours vous rappeler que c’est possible en PHP et dans d’autres langages avec des fonctionnalités qui peuvent évaluer les entrées.
Organisation de l’exécution de code à distance par Origine
La majorité des faiblesses RCE distinguées sont dues à certaines causes de base qui peuvent être suivies jusqu’à son point de départ. Le regroupement de l’Exécution de code à distance par début est examiné comme suit.
Exécution de code dynamique
L’exécution de code dynamique est, de tous les comptes, la raison de base la plus largement reconnue qui incite à une attaque d’exécution de code. De nombreux dialectes de programmation sont planifiés à un point tel qu’ils peuvent produire du code avec un autre code et l’exécuter immédiatement. Cette idée est étonnante et traite divers problèmes complexes. Quoi qu’il en soit, un agresseur malveillant peut contrôler cette idée pour acquérir un accès et des capacités RCE.
Habituellement, le code produit dépend rapidement de certaines entrées du client. Habituellement, le code incorpore les informations qui ont été mémorisées pour une structure spécifique. Lorsqu’un agresseur malin comprend que l’âge du code puissant utilisera certaines informations, il pourrait créer un code substantiel comme type d’accès pour séparer l’application. Si les contributions des clients ne sont pas examinées, le code sera exécuté sur son objectif.
Au moment où vous choisissez de regarder attentivement, l’exécution de code dynamique est responsable de deux types d’attaques basées sur RCE; immédiate et détournée.
Direct
Lors de la gestion d’une illustration d’exécution directe d’hommage unique, l’agresseur se rend compte que son retour serait utilisé pour produire du code.
Indirect
D’une manière aberrante, il s’inquiète de l’âge du code puissant avec les entrées client. L’entrée client est généralement soumise à au moins une couche. Une partie des couches peut être responsable de la modification de la contribution avant qu’elle ne se termine avec l’âge du code dynamique. De plus, l’âge du code dynamique peut être un impact ultérieur et non l’utilisation immédiate des informations. C’est la raison pour laquelle il peut ne pas être clair pour le client qui donne les informations qui se rempliront en tant que bloc de structure dans un scrap de code qui serait exécuté à distance.
Désérialisation
La désérialisation est un guide incroyable pour décrire la situation actuelle. Aucun âge de code puissant ne devrait se produire pendant la désérialisation. Par intermittence, c’est la situation qui se produit lorsque l’objet sérialisé contient des champs d’informations brutes ou des objets de type comparable. Les choses deviennent plus confuses lorsque les éléments de l’article sont sérialisés. La désérialisation intégrerait également un certain degré d’âge du code dynamique.
Il peut sembler que les dialectes puissants sont les seuls influencés par la sérialisation du travail. À condition que cela soit vrai, la question serait très restreinte. Quoi qu’il en soit, cette situation est également très utile dans les dialectes statiques. C’est plus difficile à accomplir avec le langage statique, mais ce n’est certainement pas faisable.
Par intermittence, l’exécution de cette idée gère les capacités intermédiaires produites par la désérialisation. Les objets d’âge à l’exécution sont tout simplement concevables avec l’âge du code dynamique. Cela implique que si l’information qui sera désérialisée est faite dans une sollicitation faite à distance, un agresseur malveillant pourrait la réquisitionner et l’ajuster. Tout autour des bits de code planifiés pourraient également être familiarisés avec stunt l’âge de code puissant pour exécuter la capacité lorsqu’elle est incorporée comme un morceau de la désérialisation.
Sécurité de la mémoire
Une autre raison fondamentale des agressions RCE s’identifie à la sécurité de la mémoire ou à la sécurité des API. Le bien-être de la mémoire fait allusion à la contre-action du code pour arriver à des morceaux de mémoire fondamentaux qu’il n’a pas instationnés. Il est ordinaire de s’attendre à ce qu’un manque de sécurité de la mémoire entraîne un accès non autorisé aux informations. Dans tous les cas, le cadre de travail et l’équipement dépendent de la mémoire pour stocker le code exécutable. Les métadonnées d’identification avec l’exécution de code sont conservées en mémoire. L’accès à cette partie de la mémoire pourrait inciter ACE et RCE. De cette façon, quelles sont une partie des raisons des problèmes de bien-être de la mémoire?
Les imperfections du plan du produit
Les imperfections dans la configuration du produit sont un type de faiblesse du bien-être de la mémoire qui se produit lorsqu’il y a une erreur de planification dans une partie cachée spécifique. Par intermittence, la partie manquante peut être un compilateur, un traducteur, une machine virtuelle ou même la partie du cadre de travail ou la bibliothèque. Il y a diverses imperfections dans cette classe. Une partie de l’incorporation;
Débordement de tampon
Le débordement de tampon, également mentionné comme dépassement de tampon, peut être utilisé pour faire allusion à une méthode de base et célèbre utilisée pour briser le bien-être de la mémoire. Cet assaut profite d’un défaut de plan spécifique ou d’un bug pour rester en contact avec les cellules de mémoire situées vers l’arrivée du coussin de mémoire. Le support serait récupéré d’un appel authentique à l’API publique. Néanmoins, cradle fait simplement allusion à une menace de lieu de départ utilisée pour enregistrer les emplacements de mémoire réels d’un compteur d’article ou de programme spécifique. Leur séparation du berceau est notable ou peut sans aucun doute être spéculée. L’enquête sur le code chaque fois qu’il est rendu accessible ou le dépannage de l’exécution complète du programme au moment de l’exécution peut être utile à un agresseur qui doit examiner les positions relatives.
Cela implique qu’une inondation du berceau permettrait de modifier la mémoire indisponible dans une certaine mesure. Le berceau peut être trouvé dans l’espace de localisation d’une autre machine et il sera modifié en appelant une API distante. Cela fera l’admission à la mémoire de la machine distante. Il existe de nombreuses approches pour utiliser ce type d’accès pour faire double emploi avec un RCE. On soupçonne généralement qu’en supposant qu’il y ait une faiblesse d’inondation de coussin, un assaut basé sur le RCE n’est pas exclu. Cela implique que les propriétaires de code sont tenus de réparer rapidement leurs inondations de support avant qu’une agression RCE ne se produise.
Défauts de conception de l’équipement
Les agressions du bien-être de la mémoire peuvent également être dues à des défauts de configuration de l’équipement. Ils ne sont pas aussi normaux que les agressions de programmation et sont beaucoup plus difficiles à reconnaître. Pourtant, ce type d’agression affecte énormément le cadre.
Impacts de la vulnérabilité d’évaluation de code à distance
Un attaquant capable d’exécuter une attaque basée sur du code à distance sur un système avec succès serait en mesure d’exécuter d’autres commandes en tirant parti du langage de programmation ou du serveur Web. Sur de nombreux langages de programmation, l’attaquant serait capable de commander au système d’écrire, de lire ou de supprimer des fichiers. Il peut même être possible de se connecter à différentes bases de données avec le système attaqué.
Pourquoi les attaquants lancent-Ils des attaques RCE ?
Bien qu’il n’y ait pas de raison particulière pour laquelle les attaquants choisissent d’utiliser l’exploitation RCE pour attaquer une application Web, il n’y a pas de raison particulière. C’est juste que certains malveillants trouvent facile de profiter de cette exécution de code pour accéder à vos systèmes.
Comment Prévenir Les Attaques D’Exécution De Code À Distance ?
POUR commencer, vous devez éviter l’utilisation de l’entrée utilisateur dans le code évalué. La meilleure option dans cette situation serait d’éviter complètement d’utiliser des fonctions telles que eval. Il est considéré comme une forme de mauvaise pratique et peut facilement être évité. Il est également recommandé de ne jamais laisser un utilisateur modifier le contenu des fichiers qui ont pu être analysés par le langage de programmation en question. Cela inclut souvent de laisser un utilisateur créer le nom et les extensions de fichier qu’il souhaite télécharger ou créer dans l’application Web.
Voici quelques-unes des choses que vous ne devriez pas faire pour éviter les attaques basées sur RCE. Ils comprennent:
- Assainir les entrées de l’utilisateur. Souvent, cela est difficile à réaliser car il existe une grande quantité de contournements et de restrictions préinstallés.
- Laissez un utilisateur décider ou créer l’extension ou le contenu des fichiers à utiliser sur le serveur Web. Il / elle doit utiliser de nombreuses pratiques sûres lors de la gestion des téléchargements de fichiers ou risquer que des informations vitales tombent entre de mauvaises mains.
- Transmettez toute entrée contrôlée par l’utilisateur dans des fonctions de rappel système ou d’évaluation
- Mettant activement sur liste noire les caractères spéciaux ou les noms de fonctions. Cela doit être évité tout comme la désinfection des entrées utilisateur. Mais c’est incroyablement difficile à mettre en œuvre.