Pour ma part j'ai commencé par lire : "The Art of Exploitation" (ou Techniques de Hacking en français) dont vous parliez qui pose les bases et convient très bien au débutants.

Ensuite pour approfondir les failles applicatives il y a "Shellcoder's Handbook", qui est très bien mais commence à se faire un peu vieux étant données les nouvelles techniques. Pour le Web et les BDD il y a dans la meme série "Web Application Hacker's Handbook" et "Database Hacker's Handbook" qui sont eux aussi plutot complets.

Pour plonger un peu plus du coté Windows tu as "Rootkits, subverting the Windows Kernel" dont t'as parlé Geo, et si l'analyse forensique te tente tu peux aussi trouver "Windows Forensic Analysis" (que je n'ai pas encore lu).

Un autre que je n'ai pas encore lu est "A guide to kernel exploitation", qui semble avoir de bonnes critiques

Bonne recherche !

Sérieux, je veux bien essayer de résoudre l'épreuve.
Mais un minimum de code sensé et respectueux des normes devrait quand même être présent.

Ouf, merci, j'ai eu peur que tu ne veuilles pas essayer de la résoudre...Je n'en dormais plus !  

Bon, maintenant, lisons la doc :

Variable names follow the same rules as other labels in PHP. A valid variable name starts with a letter or underscore, followed by any number of letters, numbers, or underscores. As a regular expression, it would be expressed thus: '[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*'

Tiens ?! Une regex pour tester si un nom de variable est valide...

Code:

var_dump( preg_match('#^[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*$#', 'caractères') );

Et on obtient le très surprenant résultat :

int(1)

Bref, le caractère accentué "è" est tout à fait autorisé dans un nom de variable en PHP...
De plus, que crois-tu ? Que chaque auteur d'une épreuve va se plier aux conventions de code de chaque challenger ?

Si l'épreuve ne te plais pas alors ne la fais pas. Point. Mais inutile de venir pleurer sur le forum pour une broutille (qui manifestement n'a pas gêné la 40^aine de challengers qui a validé cette épreuve ces dernières années) parce que tout le monde s'en tape.

Bon après si on pouvait en revenir au sujet principal, je suis aussi intéressé pour savoir qui il y aura là-bas

J'y serais aussi

Vu les questions que je reçois en MP qui ressemblent souvent à la tienne, il semble que beaucoup bloquent au même endroit que toi tarzanlefumeur.
Ce n'est pas le but de l'épreuve, donc si jamais vous êtes dans une situation dans laquelle tous vos actes sont vains, et pour laquelle vous avez épuisé tous vos arguments, sachez que vous faites fausse route

++
Niklos

sauf qu'il n'y a pas le fichier config.php dans ./requires...
Ca serait quand même 'achement plus simple si vous pouviez me l'envoyer 

Ahem... La lecture de l'énoncé est fortement conseillée avant de commencer une épreuve :

Note : Le fichier install.php crée les 2 tables nécessaires à l'épreuve et le fichier config.php

Je pense que c'est à ce niveau qu'il existe un problème à résoudre sans déplacer ces épreuves en dev/null

Selon moi c'est plus un problème de nom.
Je pense qu'il ne serait pas dérangeant du tout de déplacer les épreuves à validation manuelle dans une catégorie à part, mais je crois que ça pose problème à certains (moi compris) de les déplacer en /dev/null particulièrement.

Parce que ce qu'on trouve en /dev/null, ce sont des épreuves sans intérêt et en général assez chiantes à "résoudre", et il plane donc autour de cette catégorie une sorte d'aura néfaste (d'ailleurs ceci est confirmé par le fait qu'on puisse masquer les /dev/null...)

Pourquoi alors vouloir déplacer en /dev/null des épreuves qui ne collent pas à la définition rattachée à cette catégorie ?
Déplacer une épreuve en /dev/null n'est pas une mise à jour, c'est une condamnation (qui va me dire qu'il va de temps en temps faire un tour en /dev/null ?)

Je ne les ai pas validées, mais je me permet de m'avancer en disant, comme l'ont dit chaise et mathgl24, que les épreuves à validation manuelle sont intéressantes, assez pour mériter leur propre catégorie, autre que /dev/null et son coté péjoratif, comme /dev/manual ou n'importe quoi d'autre qui signalerai à l'utilisateur que l'épreuve est présente mais qu'elle n'est pas "classique". Après reste à savoir s'il faut les garder ou les exclure du système de points, le risque ici étant de désintéresser les challengers motivés...

A discuter
++
Niklos

Sinon "Pourquoi avoir choisi l'Optima" ne semble pas faire l'unanimité d'après sa note...

Effectivement, elle n'apporte aucune connaissance et c'est extrêmement tiré par les cheveux si on a la bonne méthode. Je la mettrais dans /dev/null elle aussi.

Je ne trouve pas. C'est vrai que "la bonne méthode" comme tu dis est vraiment tirée par les cheveux, mais la manière dont je l'ai résolue (qui est la méthode utilisée par la majorité selon l'afterward) me semble être la base de la cryptographie, et de ce fait je classerai cette épreuve dans la catégorie des épreuves "intermédiaires" tant réclamées. Ce n'est pas parce que le chiffrage est un peu biscornu qu'il n'est pas possible d'utiliser les métodes rigoureuses de la cryptographie (pour rester vague). A discuter

++
Niklos

Code:

<?php

	if($argc>=2)
		exec(urldecode($argv[1]));
		
?>

Sapristi ! Avec un script comme ça ce serait peut être une bonne idée de faire une whitelist des exécutables autorisés...parce que là on peut faire une nouvelle épreuve dans la catégorie hacking (et même si ce n'est qu'une idée de départ, autant poser de bonnes bases dès le début )

on m'apprend que le password est caché dans un certain fichier JPG...

Non, ce n'est pas exactement ce qui est dit, nuance

Après avoir fini la première étape (d'ailleurs au passage je me tape le front sur le clavier de ne pas avoir compris le titre de l'épreuve plus tôt), et la seconde (pour ceux que ça pourrait aider, elle n'est pas nulle du tout cette étape),  je bloque sur ce qu'il me reste à faire car j'ai l'impression d'avoir déjà exploité ce qui était à ma disposition...

Est il possible de savoir si il faut se concentrer de nouveau sur le média obtenu en fin de première étape (sur un objet précis par exemple...), ou s'il faut exploiter "le reste" de ce qu'on obtient de la deuxième étape (car il y a bien un reste inintelligible) ? Je suppose que c'est à ce moment qu'intervient la crypto dont nms parle au début de ce fil

Merci d'avance à l'âme charitable qui se proposera de m'aiguiller 
++
Niklos

Bonifas risque de tourner en rond avec une démonstration comme la sienne.

Si vous continuez ainsi vous allez le laisser sur le carreau, carrément

Oui mais si c'est un carré, c'est bien un rectangle et un losange

[echo 0x27;]

Salut FiRe_StoRM,

0x27 est juste la notation hexadécimale du nombre 39. Le préfixe 0x servant à préciser qu'il s'agit d'un chiffre en hexadécimal.
Tu peux le vérifier en PHP en faisant echo 0x27; , ce qui t'affichera 39.
(Si cela te fait penser à une adresse mémoire c'est parce qu'elles emploient la même notation.)
Il ne faut pas confondre avec MySQL, qui interprète les chiffres en notation hexadécimale comme des chaines de caractères, ainsi (SELECT 0x616263 renverra abc)
Et on peut aussi remarquer que 39 est le code ASCII d'une simple quote. Toujours vérifiable en faisant echo chr(0x27); qui t'affiche '.

Maintenant parlons des caractères multibytes.
Le jeu de caractères habituels que nous employons utilise des caractères qui sont codés sur 1 octet (donc de 0 à 255).
En effet vu le peu de caractères cela suffit. Mais certains alphabets en contiennent un si grand nombre, qu'il devient impossible de les coder tous en utilisant seulement les valeurs possibles avec un seul octet : dans ce cas le charset utilise alors plusieurs octets pour coder un caractère, c'est un charset multi-octet (ou multi-byte en anglais). On peut citer en exemple les charsets chinois comme GBK ou BIG5.

Maintenant, le seul problème de sécurité en php que je connais qui fait intervenir cela, c'est celui de l'échappement des caractères par une fonction qui ne tient pas compte du charset utilisé par MySQL (addslashes, mysql_escape_string ou les magic_quotes). Voici un lien intéressant à ce sujet : http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string

Voilà un exemple de ce problème (qui paraphrase ce que dit l'auteur) : imaginons que MySQL utilise le charset BIG5. Addslashes ne tient pas compte du fait que big5 utilise des caractères multi-octets comme par exemple ce caractère 兝 dont le code hexadécimal est 0xa25c. Et avec addslashes, les quotes (entre autres) dont le code hexadécimal est 0x27 seront précédés d'un anti-slash 0x5c. Donc si j'envoie la chaine « ¢' », 0xa227 en hexadécimal, elle sera remplacée par la chaine 0xa25c27, et lorsque cette chaine sera utilisée dans la requête SQL, étant donné que 0xa25c est un caractère valide dans le charset BIG5, MySQL l'interprétera comme une chaine formée de deux caractères : notre caractère multi-octet et une quote ! On pourra donc utiliser des quotes dans une requête censée être sécurisée, ce qui nous mène au problème des injections SQL ...


Voilà voilà,
j'espère que c'est plus clair.
++
Niklos

Salut mOuchOu,

je vais me renseigner sur ces deux failles.

Si je peux me permettre, je pense que le problème ne vient pas du manque d'informations sur les failles en question, mais plutôt du manque des "bases à avoir" pour les comprendre.

Je m'explique, tu commet ici une erreur flagrante en confondant XSS et Include, alors qu'elles sont nettement différentes : rapidement, une faille XSS se situe coté client alors qu'une faille include se situe coté serveur. Et tu auras beau lire et relire toutes les docs sur ces deux failles, cela ne servira à rien si tu n'as pas compris ce point. Il est donc clair qu'il faut se documenter ici sur "comment fonctionne le php", "qu'est ce qu'une relation client-serveur", ... avant de passer aux différentes failles !

Je pense que d'une manière générale il faut se contruire un "mur des connaissances" : tu commence par apprendre les informations générales, qui seront les fondations de ton mur, pour ensuite empiler différents sujets plus précis, plus complexes, qui viendront s'appuyer sur ces premières compétences. Inutile donc d'attaquer la construction par le haut

Pour revenir à la question de départ, plus concrète : pour faire les épreuves de hacking il faut d'abord regarder ce qu'elles mettent en jeu et comment elles sont faites. Par exemple beaucoup utilisent une interface Web et PHP (pas toutes), un bon moyen de commencer est alors de voir comment tout cela fonctionne, pourquoi pas apprendre à manipuler PHP... Et une fois que tu en sauras assez, tu pourras alors seulement te documenter sur les détournements, les problèmes de sécurité que l'on rencontre avec ce type d'application.

Et une fois que tu auras fini tout ça, il ne te resteras plus qu'à faire de même pour la catégorie de challenge suivante ^^
Bon challenge
++
Niklos

j'ai reusit à trouver le contenu du fichier secret.php mais je galère un peu pour passer l'auth...

Surprenant ! Ou pas tant que ça finalement, tu es déjà le troisième qui me dit la même chose...
Pourtant je suis sur que tout le monde à au moins une lointaine connaissance à appeler à la rescousse