Qu'est-ce qu'un shell restreint et pourquoi les attaques de shell sautantes sont importantes
Les shells restreints sont utilisés pour contrôler les commandes que les utilisateurs peuvent exécuter, empêchant souvent des actions telles que cd, lancer de nouveaux shells ou exporter des variables d'environnement. Ils sont généralement déployés dans CI/CD agents ou environnements de construction pour limiter le comportement des utilisateurs. Cependant, les attaquants recherchent des moyens d'exécuter un shell de saut, une méthode utilisée pour échapper aux environnements de shell restreints et accéder à des shells non restreints comme poubelle/bash. Une fois à l'intérieur it, l'attaquant dispose d'un contrôle total de la ligne de commande, contournant toutes les limitations de l'environnement restreint.
Fonctionnement du Jumping Shell : de restreint à bin/bash
Le but d'un shell sauteur est d'exploiter les faiblesses dans des environnements restreints et de déclencher une évasion de shell qui mène à poubelle/bashLes techniques courantes pour les attaques de shell restreintes incluent :
$ ls
/bin/bash
$ /bin/bashIf poubelle/bash est accessible, cette simple invocation le complète.
Une autre méthode courante :
$ echo "/bin/bash" > run.sh
$ sh run.sh
Les attaquants peuvent également exploiter des éditeurs tels que vi or moins:
vi
:set shell=/bin/bash
:shell
Ces méthodes illustrent à quel point une coquille sauteuse peut facilement conduire à poubelle/bash exécution, contournant efficacement les protections de shell restreintes.
Les risques réels de ces attaques dans DevOps
En partage CI/CD environnements, des shells restreints sont utilisés pour isoler les builds et réduire les risques. Mais lorsqu'un attaquant réussit avec un shell de saut et atteint poubelle/bash, le modèle de sécurité s’effondre.
Les risques comprennent:
- Accès non autorisé aux secrets de l'environnement
- Élévation des privilèges sans restriction poubelle/bash
- Altération de la construction pipelines ou artefacts
- Déploiement d'outils persistants au sein du pipeline
La coquille d'échappement restreinte à poubelle/bash ouvre la porte à un compromis complet du système, souvent la première étape d'un processus plus large Attaque DevSecOps.
Surveillance et détection des sauts de shell et des échappements bin/bash
Pour détecter le comportement du shell sauteur et bloquer les tentatives de shell restreintes par échappement, les équipes de sécurité doivent :
- Enregistrez toutes les activités du shell, en particulier / bin / bash efficace
- Surveiller les abus de l'éditeur et l'utilisation des scripts comme vecteurs de génération de shell
- Suivre l'accès aux fichiers de configuration du shell comme .bashrc or .bash_profile
Modèles comportementaux tels que le lancement poubelle/bash Les alertes provenant d'un environnement restreint doivent être considérées comme prioritaires. Une détection précoce peut prévenir tout mouvement latéral plus important.
Prévention des attaques et des exploits de shell restreints Escape
Pour atténuer les risques de saut de shell et empêcher les attaquants de se lancer poubelle/bash:
- Durcir les coquilles restreintes : Retirer ou bloquer les accès
- Utilisez AppArmor ou SELinux pour restreindre l'exécution des commandes
- Appliquer le principe du moindre privilège à tous CI/CD rôles et coureurs
- Conteneuriser les builds avec des images sans distribution sans shells comme poubelle/bash
- Valider les environnements avant et après les builds pour détecter les anomalies
La prévention des scénarios d'échappement à shell restreint nécessite des contrôles multicouches, et non pas seulement le recours à des shells limités. Ne présumez pas que les shells restreints sont sécurisés si poubelle/bash est même potentiellement accessible.
Conclusion : les échappements de coquille sont des points d'entrée
Les shells restreints constituent une couche de défense, et non une garantie. Les attaques par shell sauteur ciblent une isolation faible et une validation insuffisante. Une fois à l'intérieur / bin / bash, les attaquants peuvent pivoter, persister et compromettre l'infrastructure DevSecOps.
La détection et l'isolement sont essentiels. Combiner la journalisation des commandes, les environnements restreints et un nettoyage approprié des gestionnaires de paquets réduit l'exposition.
Enfin, des outils comme Xygéni offrent une visibilité sur ces risques. Ils contribuent à garantir l'intégrité du code, à détecter les comportements inhabituels du shell et sécurisez votre pipelinecontre les menaces internes et externes, y compris ceux qui commencent par un simple shell de saut pour / bin / bash ou tente d'échapper aux environnements shell restreints.
