Vercel Security
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Dans Vercel, une équipe est l'environnement complet qui appartient à un client et un projet est une application.
Pour un examen de durcissement de Vercel, vous devez demander un utilisateur avec la permission de rôle de visualiseur ou au moins la permission de visualiseur de projet sur les projets à vérifier (au cas où vous n'auriez besoin de vérifier que les projets et non la configuration de l'équipe également).
Objectif : Gérer les paramètres fondamentaux du projet tels que le nom du projet, le framework et les configurations de construction.
Transfert
Mauvaise configuration : Permet de transférer le projet à une autre équipe
Risque : Un attaquant pourrait voler le projet
Supprimer le projet
Mauvaise configuration : Permet de supprimer le projet
Risque : Supprimer le projet
Objectif : Gérer les domaines personnalisés, les paramètres DNS et les configurations SSL.
Erreurs de configuration DNS
Mauvaise configuration : Enregistrements DNS incorrects (A, CNAME) pointant vers des serveurs malveillants.
Risque : Détournement de domaine, interception de trafic et attaques de phishing.
Gestion des certificats SSL/TLS
Mauvaise configuration : Utilisation de certificats SSL/TLS faibles ou expirés.
Risque : Vulnérabilité aux attaques de type homme du milieu (MITM), compromettant l'intégrité et la confidentialité des données.
Mise en œuvre de DNSSEC
Mauvaise configuration : Échec de l'activation de DNSSEC ou paramètres DNSSEC incorrects.
Risque : Susceptibilité accrue aux attaques de spoofing DNS et de poisoning de cache.
Environnement utilisé par domaine
Mauvaise configuration : Changer l'environnement utilisé par le domaine en production.
Risque : Exposer des secrets ou des fonctionnalités potentielles qui ne devraient pas être disponibles en production.
Objectif : Définir différents environnements (Développement, Prévisualisation, Production) avec des paramètres et des variables spécifiques.
Isolation des environnements
Mauvaise configuration : Partage des variables d'environnement entre les environnements.
Risque : Fuite de secrets de production dans les environnements de développement ou de prévisualisation, augmentant l'exposition.
Accès aux environnements sensibles
Mauvaise configuration : Autoriser un accès large aux environnements de production.
Risque : Changements non autorisés ou accès à des applications en direct, entraînant des temps d'arrêt potentiels ou des violations de données.
Objectif : Gérer les variables et secrets spécifiques à l'environnement utilisés par l'application.
Exposition de variables sensibles
Mauvaise configuration : Préfixer les variables sensibles avec NEXT_PUBLIC_, les rendant accessibles côté client.
Risque : Exposition de clés API, d'identifiants de base de données ou d'autres données sensibles au public, entraînant des violations de données.
Sensibles désactivés
Mauvaise configuration : Si désactivé (par défaut), il est possible de lire les valeurs des secrets générés.
Risque : Augmentation de la probabilité d'exposition accidentelle ou d'accès non autorisé à des informations sensibles.
Variables d'environnement partagées
Mauvaise configuration : Ce sont des variables d'environnement définies au niveau de l'équipe et pourraient également contenir des informations sensibles.
Risque : Augmentation de la probabilité d'exposition accidentelle ou d'accès non autorisé à des informations sensibles.
Objectif : Configurer les intégrations de dépôt Git, les protections de branche et les déclencheurs de déploiement.
Étape de construction ignorée (TODO)
Mauvaise configuration : Il semble que cette option permette de configurer un script/commandes bash qui seront exécutés lorsqu'un nouveau commit est poussé sur Github, ce qui pourrait permettre RCE.
Risque : À déterminer
Objectif : Connecter des services et outils tiers pour améliorer les fonctionnalités du projet.
Intégrations tierces non sécurisées
Mauvaise configuration : Intégration avec des services tiers non fiables ou non sécurisés.
Risque : Introduction de vulnérabilités, fuites de données ou portes dérobées via des intégrations compromises.
Intégrations sur-autorisation
Mauvaise configuration : Accorder des permissions excessives aux services intégrés.
Risque : Accès non autorisé aux ressources du projet, manipulation de données ou interruptions de service.
Absence de surveillance des intégrations
Mauvaise configuration : Échec de la surveillance et de l'audit des intégrations tierces.
Risque : Détection tardive des intégrations compromises, augmentant l'impact potentiel des violations de sécurité.
Objectif : Sécuriser les déploiements grâce à divers mécanismes de protection, contrôlant qui peut accéder et déployer dans vos environnements.
Authentification Vercel
Mauvaise configuration : Désactiver l'authentification ou ne pas appliquer de vérifications des membres de l'équipe.
Risque : Des utilisateurs non autorisés peuvent accéder aux déploiements, entraînant des violations de données ou un usage abusif de l'application.
Contournement de protection pour l'automatisation
Mauvaise configuration : Exposer le secret de contournement publiquement ou utiliser des secrets faibles.
Risque : Les attaquants peuvent contourner les protections de déploiement, accédant et manipulant des déploiements protégés.
Liens partageables
Mauvaise configuration : Partager des liens sans discernement ou ne pas révoquer les liens obsolètes.
Risque : Accès non autorisé aux déploiements protégés, contournant l'authentification et les restrictions IP.
OPTIONS Liste blanche
Mauvaise configuration : Autoriser des chemins ou des points de terminaison sensibles trop larges.
Risque : Les attaquants peuvent exploiter des chemins non protégés pour effectuer des actions non autorisées ou contourner les vérifications de sécurité.
Protection par mot de passe
Mauvaise configuration : Utiliser des mots de passe faibles ou les partager de manière non sécurisée.
Risque : Accès non autorisé aux déploiements si les mots de passe sont devinés ou divulgués.
Remarque : Disponible sur le plan Pro dans le cadre de la Protection avancée des déploiements pour un coût supplémentaire de 150 $/mois.
Exceptions de protection des déploiements
Mauvaise configuration : Ajouter des domaines de production ou sensibles à la liste des exceptions par inadvertance.
Risque : Exposition de déploiements critiques au public, entraînant des fuites de données ou un accès non autorisé.
Remarque : Disponible sur le plan Pro dans le cadre de la Protection avancée des déploiements pour un coût supplémentaire de 150 $/mois.
IPs de confiance
Mauvaise configuration : Spécification incorrecte des adresses IP ou des plages CIDR.
Risque : Utilisateurs légitimes bloqués ou IP non autorisées accédant.
Remarque : Disponible sur le plan Enterprise.
Objectif : Configurer des fonctions sans serveur, y compris les paramètres d'exécution, l'allocation de mémoire et les politiques de sécurité.
Rien
Objectif : Gérer les stratégies et paramètres de mise en cache pour optimiser les performances et contrôler le stockage des données.
Purger le cache
Mauvaise configuration : Cela permet de supprimer tout le cache.
Risque : Utilisateurs non autorisés supprimant le cache, entraînant un potentiel DoS.
Objectif : Planifier des tâches et des scripts automatisés à exécuter à des intervalles spécifiés.
Désactiver la tâche Cron
Mauvaise configuration : Cela permet de désactiver les tâches cron déclarées dans le code.
Risque : Interruption potentielle du service (selon l'objectif des tâches cron)
Objectif : Configurer des services de journalisation externes pour capturer et stocker les journaux d'application pour la surveillance et l'audit.
Rien (géré depuis les paramètres d'équipe)
Objectif : Hub central pour divers paramètres liés à la sécurité affectant l'accès au projet, la protection des sources, et plus encore.
Journaux de construction et protection des sources
Mauvaise configuration : Désactiver la protection ou exposer les chemins /logs et /src publiquement.
Risque : Accès non autorisé aux journaux de construction et au code source, entraînant des fuites d'informations et une exploitation potentielle des vulnérabilités.
Protection des forks Git
Mauvaise configuration : Autoriser des demandes de tirage non autorisées sans examens appropriés.
Risque : Du code malveillant peut être fusionné dans la base de code, introduisant des vulnérabilités ou des portes dérobées.
Accès sécurisé au backend avec fédération OIDC
Mauvaise configuration : Configuration incorrecte des paramètres OIDC ou utilisation d'URL d'émetteur non sécurisées.
Risque : Accès non autorisé aux services backend via des flux d'authentification défectueux.
Politique de conservation des déploiements
Mauvaise configuration : Définir des périodes de conservation trop courtes (perte de l'historique des déploiements) ou trop longues (conservation de données inutiles).
Risque : Incapacité à effectuer des retours en arrière lorsque nécessaire ou risque accru d'exposition des données provenant d'anciens déploiements.
Déploiements récemment supprimés
Mauvaise configuration : Ne pas surveiller les déploiements supprimés ou se fier uniquement aux suppressions automatisées.
Risque : Perte de l'historique critique des déploiements, entravant les audits et les retours en arrière.
Objectif : Accéder à des paramètres de projet supplémentaires pour affiner les configurations et améliorer la sécurité.
Liste des répertoires
Mauvaise configuration : Activer la liste des répertoires permet aux utilisateurs de voir le contenu des répertoires sans fichier d'index.
Risque : Exposition de fichiers sensibles, de la structure de l'application et de points d'entrée potentiels pour des attaques.
Activer le mode défi d'attaque
Mauvaise configuration : L'activation de cela améliore les défenses de l'application web contre les DoS mais au détriment de l'utilisabilité.
Risque : Problèmes potentiels d'expérience utilisateur.
Mauvaise configuration : Permet de débloquer/bloquer le trafic.
Risque : Potentiel DoS permettant un trafic malveillant ou bloquant un trafic bénin.
Mauvaise configuration : Permet d'accéder à la lecture du code source complet de l'application.
Risque : Exposition potentielle d'informations sensibles.
Mauvaise configuration : Cette protection garantit que l'application client et serveur utilise toujours la même version afin qu'il n'y ait pas de désynchronisations où le client utilise une version différente de celle du serveur et donc ils ne se comprennent pas.
Risque : Désactiver cela (si activé) pourrait causer des problèmes de DoS dans de nouveaux déploiements à l'avenir.
Transfert
Mauvaise configuration : Permet de transférer tous les projets à une autre équipe.
Risque : Un attaquant pourrait voler les projets.
Supprimer le projet
Mauvaise configuration : Permet de supprimer l'équipe avec tous les projets.
Risque : Supprimer les projets.
Limite de coût des Speed Insights
Mauvaise configuration : Un attaquant pourrait augmenter ce nombre.
Risque : Coûts accrus.
Ajouter des membres
Mauvaise configuration : Un attaquant pourrait maintenir sa persistance en invitant un compte qu'il contrôle.
Risque : Persistance de l'attaquant.
Rôles
Mauvaise configuration : Accorder trop de permissions à des personnes qui n'en ont pas besoin augmente le risque de la configuration de Vercel. Vérifiez tous les rôles possibles sur https://vercel.com/docs/accounts/team-members-and-roles/access-roles.
Risque : Augmente l'exposition de l'équipe Vercel.
Un groupe d'accès dans Vercel est une collection de projets et de membres d'équipe avec des attributions de rôles prédéfinies, permettant une gestion d'accès centralisée et rationalisée à travers plusieurs projets.
Mauvaises configurations potentielles :
Sur-autorisation des membres : Attribuer des rôles avec plus de permissions que nécessaire, entraînant un accès ou des actions non autorisées.
Attributions de rôles incorrectes : Attribuer incorrectement des rôles qui ne correspondent pas aux responsabilités des membres de l'équipe, provoquant une élévation de privilèges.
Absence de séparation des projets : Échec de la séparation des projets sensibles, permettant un accès plus large que prévu.
Gestion de groupe insuffisante : Ne pas examiner ou mettre à jour régulièrement les groupes d'accès, entraînant des permissions d'accès obsolètes ou inappropriées.
Définitions de rôles incohérentes : Utiliser des définitions de rôles incohérentes ou peu claires à travers différents groupes d'accès, entraînant confusion et lacunes de sécurité.
Drains de journal vers des tiers :
Mauvaise configuration : Un attaquant pourrait configurer un drain de journal pour voler les journaux.
Risque : Persistance partielle.
Domaine d'email de l'équipe : Lorsqu'il est configuré, ce paramètre invite automatiquement les comptes personnels Vercel avec des adresses email se terminant par le domaine spécifié (par exemple, mydomain.com) à rejoindre votre équipe lors de l'inscription et sur le tableau de bord.
Mauvaise configuration :
Spécifier le mauvais domaine email ou un domaine mal orthographié dans le paramètre de domaine email de l'équipe.
Utiliser un domaine email commun (par exemple, gmail.com, hotmail.com) au lieu d'un domaine spécifique à l'entreprise.
Risques :
Accès non autorisé : Des utilisateurs avec des adresses email de domaines non prévus peuvent recevoir des invitations à rejoindre votre équipe.
Exposition des données : Exposition potentielle d'informations sensibles sur le projet à des individus non autorisés.
Scopes Git protégés : Vous permet d'ajouter jusqu'à 5 scopes Git à votre équipe pour empêcher d'autres équipes Vercel de déployer des dépôts à partir du scope protégé. Plusieurs équipes peuvent spécifier le même scope, permettant l'accès aux deux équipes.
Mauvaise configuration : Ne pas ajouter de scopes Git critiques à la liste protégée.
Risques :
Déploiements non autorisés : D'autres équipes peuvent déployer des dépôts à partir des scopes Git de votre organisation sans autorisation.
Exposition de la propriété intellectuelle : Du code propriétaire pourrait être déployé et accessible en dehors de votre équipe.
Politiques de variables d'environnement : Applique des politiques pour la création et l'édition des variables d'environnement de l'équipe. En particulier, vous pouvez imposer que toutes les variables d'environnement soient créées en tant que variables d'environnement sensibles, qui ne peuvent être décryptées que par le système de déploiement de Vercel.
Mauvaise configuration : Maintenir la désactivation de l'application des variables d'environnement sensibles.
Risques :
Exposition des secrets : Les variables d'environnement peuvent être consultées ou modifiées par des membres d'équipe non autorisés.
Violation de données : Des informations sensibles comme des clés API et des identifiants pourraient être divulguées.
Journal d'audit : Fournit une exportation de l'activité de l'équipe pour les 90 derniers jours. Les journaux d'audit aident à surveiller et à suivre les actions effectuées par les membres de l'équipe.
Mauvaise configuration : Accorder l'accès aux journaux d'audit à des membres d'équipe non autorisés.
Risques :
Violations de la vie privée : Exposition d'activités et de données sensibles des utilisateurs.
Altération des journaux : Des acteurs malveillants pourraient modifier ou supprimer des journaux pour dissimuler leurs traces.
SAML Single Sign-On : Permet de personnaliser l'authentification SAML et la synchronisation des annuaires pour votre équipe, permettant l'intégration avec un fournisseur d'identité (IdP) pour une authentification et une gestion des utilisateurs centralisées.
Mauvaise configuration : Un attaquant pourrait créer une porte dérobée dans les paramètres de l'équipe en configurant des paramètres SAML tels que l'ID d'entité, l'URL SSO ou les empreintes de certificat.
Risque : Maintenir la persistance.
Visibilité des adresses IP : Contrôle si les adresses IP, qui peuvent être considérées comme des informations personnelles en vertu de certaines lois sur la protection des données, sont affichées dans les requêtes de surveillance et les drains de journal.
Mauvaise configuration : Laisser la visibilité des adresses IP activée sans nécessité.
Risques :
Violations de la vie privée : Non-conformité aux réglementations sur la protection des données comme le RGPD.
Répercussions légales : Amendes et pénalités potentielles pour mauvaise gestion des données personnelles.
Blocage IP : Permet de configurer des adresses IP et des plages CIDR que Vercel doit bloquer. Les demandes bloquées ne contribuent pas à votre facturation.
Mauvaise configuration : Pourrait être abusée par un attaquant pour permettre un trafic malveillant ou bloquer un trafic légitime.
Risques :
Refus de service aux utilisateurs légitimes : Blocage d'accès pour des utilisateurs ou partenaires valides.
Perturbations opérationnelles : Perte de disponibilité de service pour certaines régions ou clients.
Vercel Secure Compute permet des connexions sécurisées et privées entre les fonctions Vercel et les environnements backend (par exemple, bases de données) en établissant des réseaux isolés avec des adresses IP dédiées. Cela élimine le besoin d'exposer les services backend publiquement, améliorant la sécurité, la conformité et la confidentialité.
Sélection incorrecte de la région AWS
Mauvaise configuration : Choisir une région AWS pour le réseau Secure Compute qui ne correspond pas à la région des services backend.
Risque : Latence accrue, problèmes potentiels de conformité en matière de résidence des données et dégradation des performances.
Blocs CIDR qui se chevauchent
Mauvaise configuration : Sélectionner des blocs CIDR qui se chevauchent avec des VPC existants ou d'autres réseaux.
Risque : Conflits de réseau entraînant des connexions échouées, un accès non autorisé ou des fuites de données entre les réseaux.
Configuration incorrecte du peering VPC
Mauvaise configuration : Configuration incorrecte du peering VPC (par exemple, mauvais IDs de VPC, mises à jour incomplètes de la table de routage).
Risque : Accès non autorisé à l'infrastructure backend, connexions sécurisées échouées et violations potentielles de données.
Attributions de projet excessives
Mauvaise configuration : Attribuer plusieurs projets à un seul réseau Secure Compute sans isolation appropriée.
Risque : L'exposition d'IP partagée augmente la surface d'attaque, permettant potentiellement à des projets compromis d'affecter d'autres.
Gestion inadéquate des adresses IP
Mauvaise configuration : Échec de la gestion ou de la rotation appropriée des adresses IP dédiées.
Risque : Spoofing IP, vulnérabilités de suivi et potentiel de mise sur liste noire si les IP sont associées à des activités malveillantes.
Inclusion inutile de conteneurs de construction
Mauvaise configuration : Ajouter des conteneurs de construction au réseau Secure Compute lorsque l'accès backend n'est pas requis pendant les constructions.
Risque : Surface d'attaque élargie, délais de provisionnement accrus et consommation inutile des ressources réseau.
Échec de la gestion sécurisée des secrets de contournement
Mauvaise configuration : Exposer ou mal gérer les secrets utilisés pour contourner les protections de déploiement.
Risque : Accès non autorisé aux déploiements protégés, permettant aux attaquants de manipuler ou de déployer du code malveillant.
Ignorer les configurations de basculement de région
Mauvaise configuration : Ne pas configurer de régions de basculement passives ou configurer incorrectement les paramètres de basculement.
Risque : Temps d'arrêt du service lors de pannes de la région principale, entraînant une disponibilité réduite et une incohérence potentielle des données.
Dépassement des limites de connexion de peering VPC
Mauvaise configuration : Tenter d'établir plus de connexions de peering VPC que la limite autorisée (par exemple, dépasser 50 connexions).
Risque : Incapacité à connecter en toute sécurité les services backend nécessaires, provoquant des échecs de déploiement et des perturbations opérationnelles.
Paramètres réseau non sécurisés
Mauvaise configuration : Règles de pare-feu faibles, absence de cryptage ou segmentation réseau inappropriée au sein du réseau Secure Compute.
Risque : Interception de données, accès non autorisé aux services backend et vulnérabilité accrue aux attaques.
Objectif : Gérer les variables et secrets spécifiques à l'environnement utilisés par tous les projets.
Exposition de variables sensibles
Mauvaise configuration : Préfixer les variables sensibles avec NEXT_PUBLIC_, les rendant accessibles côté client.
Risque : Exposition de clés API, d'identifiants de base de données ou d'autres données sensibles au public, entraînant des violations de données.
Sensibles désactivés
Mauvaise configuration : Si désactivé (par défaut), il est possible de lire les valeurs des secrets générés.
Risque : Augmentation de la probabilité d'exposition accidentelle ou d'accès non autorisé à des informations sensibles.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
