Recherche de stage dans le domaine de la Sécurité des Systèmes d’Information

    octobre 2nd, 2009

    recherche_de_stage_en_securite_des_systemes_dinformation
    Un nouvel article pour envoyer une petite bouteille dans cet océan virtuel. Je cherche actuellement un stage de trois mois à partir d’avril 2010 afin de clore mes deux années de DUT SRC à Bordeaux et rentrer dans la vie active.

    Ce stage, je souhaite le réaliser dans le domaine de la Sécurité des Systèmes d’Information et plus spécifiquement dans le domaine des audits & tests d’intrusion (réseaux, bastions & web) ainsi que dans la veille liée à la sécurité informatique.

    Je cherche – grâce à ce stage – à approfondir mes connaissances dans les méthodes d’audit et normes (ISO 27001, OSSTMM, PCI DSS, OWASP), ainsi que dans la sécurité de certains protocoles. Aujourd’hui, je possède de bonnes connaissances en audit d’applications web & bastions, en Information Gathering ainsi que dans différents domaines liés à la sécurité des systèmes d’information.

    • Attaques sur réseaux & bastions
    • Malware analysis
    • Sécurité des clients
    • Sécurité Linux
    • Veille

    J’espère découvrir, de par ce stage, la sphère professionnelle de cette passion que je possède depuis cinq ans maintenant et partager ainsi mes connaissances tout en apprenant de nouvelles techniques dans ce domaine.

    De plus, je suis ouvert à toute proposition de stage dans d’autres domaines liées par exemple au développement web/administration de serveurs, au webdesign ou à la veille informationnelle. Vous pouvez dès aujourd’hui prendre contact avec moi par l’intermédiaire de mon site Internet et voir mon CV en cliquant sur l’icône ci-dessous :

    Voir le CV de Félix Aimé, étudiant en DUT SRC à Bordeaux.

    Tags: , , , , , , , , ,
    Posted in Projets perso & Pro, SRC Bordeaux, Sécurité des systèmes d'information | No Comments »

    Petit site bien sympa sur le SE ! :)

    septembre 19th, 2009

    Il est déjà rare que je fasse un article sur mon blog, mais lorsque c’est pour parler d’un site internet, c’est une révolution ! Aujourd’hui je voulais simplement vous présenter un tout jeune site qui traite d’un sujet très connu, mais assez mal documenté dans le domaine de la sécurité des systèmes d’informations. Ce sujet ; à la fois compliqué et simple à mettre en place mais compliqué à sécuriser (vous me suivez encore ?) étant l’ingénierie sociale (ou SE pour les intimes.)

    L’ingénierie sociale un procédé d’attaques très utilisée contre les systèmes d’information permettant de récolter des informations en vue d’une attaque ou même de saboter certaines parties des SI avec – ce que j’appelle personnellement – des bombes informationnelles (j’ferai p’être un article dessus…).

    Afin d’arriver à son objectif, l’attaquant pourra utiliser toutes sortes de méthodes plus ou moins axées sur les émotions, la naïveté de la personne, la falsification d’identité ou l’envoi de fausses informations en liaison le plus souvent avec des variables d’environnement propres à l’entité visée. (présentation minimaliste)

    Ce domaine n’a pas tellement évolué au point de vue des procédés de récolte, de tri de l’information et des stratégies d’attaques (Qui a dit stratégie militaire ?). Cependant, avec l’ébullition actuelle des réseaux sociaux tant au plan personnel que professionnel véritables fers de lances de cette société d’information où l’on veut « tout montrer » ce domaine est en pleine révolution et n’est pas prêt de disparaitre… tout comme la connerie humaine.

    Bref, c’était juste trois paragraphes pour vous mettre dans l’ambiance et vous présenter les nouvelles solutions (et non problématiques) liées à l’ingénierie sociale. En ce qui concerne le site, il s’appelle social-engineer.org.

    Ce dernier est aujourd’hui bien documenté et possède différents articles de wiki, vidéos et présentations de programmes tels que le (très connu, et très cher) Maltego ou le tookit « Social Engineer Toolkit » pour le fameux Metasploit ! Je vous invite vivement à lire le wiki car il est intéressant (même si certains sujets sont très basiques.)

    Seul petit point, en ce qui concerne les vidéos, il auraient pu mieux faire… mais bon, ce n’est qu’un détail =)

    Tags: , , , , , , , ,
    Posted in Sécurité des systèmes d'information | 1 Comment »

    Petit point sur la sécurité des applications AIR et de leurs utilisateurs

    septembre 17th, 2009

    AIR, c’est cool. La phrase est lancée et depuis que le jour s’est levé sur le SDK d’Adobe, beaucoup de personnes se sont mises à faire leurs petits widgets personnels et autres RIA liées avec différentes API web mises à disposition par des réseaux sociaux. Cependant, la sécurité des applications AIR est encore mise de côté par une partie des développeurs, ayant pour la majeure partie aucune véritable base dans le développement d’RIA sécurisées.

    Il m’arrive parfois, entre deux pages Internet de télécharger une application AIR – développée en amateur ou par une firme – afin de tester la sécurité de cette dernière se divisant en trois axes majeurs à mes yeux :

    • La sécurité client (sécurité du poste de travail)
    • La sécurité utilisateur (sécurité des données utilisateurs)
    • La sécurité serveur (sécurité du serveur auquel est rattaché l’application)

    De ces trois côtés, le constat de mes audits furtifs est lourd de conséquences, faisons donc un petit tour au pays de la sécurité des applications air et des possibilités qu’offrent ces dernières en vecteur d’intrusion.

    0×01 Sécurité Client :

    Le premier problème du côté client résulte dans la capacité pour une application AIR de manipuler des fichiers présent sur le disque dur, de les enregistrer, de les envoyer à travers le web, et ce, avec quelques lignes de code (une vingtaine tout au plus) et sans n’avoir aucune réelle expérience de la part du développeur.

    Imaginez le problème si une personne utilise des programmes présentant des fichiers de connexions contenant des logins et mots de passes en clair (tels que FireFox – n’ayant pas la fonction « mot de passe principal d’activé », FileZilla avec son fichier star filezilla.xml ou même des fichiers de Cookies) et bien, une trappe réalisée dans une application AIR légitime pourrait envoyer le contenu de ces fichiers vers une base de donnée distante permettant ainsi au développeur de réaliser au fil du temps un petit trésor de guerre.

    Évidemment, Adobe a tout prévu et avertit l’utilisateur pendant l’installation de l’application que cette dernière peut accéder à des données sur son ordinateur. Cependant, connaissant les utilisateurs et me connaissant moi-même (si-si, j’vous jure), il est assez rare pour un utilisateur de refuser l’installation d’une application venant d’être téléchargée sachant qu’elle peut accéder à des fichiers présents sur notre disque dur afin de réaliser certaines opérations. (Il est aussi assez rare de regarder l’intégralité des messages pendant une installation…)

    Voyant de plus le nombre d’applications utilisées possédant ces messages à l’installation, il est sûr que l’extrême majorité des utilisateurs ne les regardent pas avant d’installer la moindre application AIR. J’ai pu vérifier cela simplement en recherchant un « top 50 » des applications AIR et en les testant une par une afin de savoir si lors de l’installation, il y avait le fameux message (et aussi un autre message avertissant que cette application n’était pas certifiée.)

    Il ressort de cette mini-étude que pas moins de 20% des applications présentent les deux messages d’erreurs cités plus haut. Parmi lesquelles, des applications largement utilisées telles que TweetDeck, Spaz ou même Twhirl. Voici la liste complète :

    1. Doomi (doominow.com)
    2. Klok (http://klok.mcgraphix.com/klok/downloads.html)
    3. TimeLoc (www.rad3.com/timeloc/default.html)
    4. AirTube (theflashblog.com/?p=363)
    5. RandomWin
    6. twhirl (http://www.twhirl.com)
    7. Spaz (http://funkatron.com/spaz)
    8. TweetDeck (tweetdeck.com)
    9. DiggTop (http://gskinner.com/DiggTop/)
    10. Snackr (http://snackr.net)
    11. ReadAir (http://code.google.com/p/readair/)
    12. WebKut (http://toki-woki.net/p/WebKut/)

    Une autre vulnérabilité que je n’ai pas vérifié mais qui est plus que probable (n’ayant pas trouvé de dossier traitant de cela sur le site d’adobe) est la possibilité pour une application AIR de télécharger un binaire sur un serveur distant et ensuite de l’exécuter. Cependant, comme je l’ai dit plus haut, je n’ai fait aucune tentative sur le chargement du binaire.

    Pour son exécution, AIR a appliqué certaines restrictions liées à cela mais des recherches et logiciels ont abouti à la possibilité d’exécution de binaires. Vous pouvez trouver plus d’informations sur ce topic de MediaBox. Mais aussi sur ce billet parlant notamment de programme SHU.

    0×02 Sécurité Utilisateur :

    Ce qui est le plus criant côté client, c’est qu’une grande partie des développeurs stockent dans des fichiers des informations sensibles sans aucun chiffrement ou même hashage de ces dernières. Ainsi, il n’est pas rare de voir ce genre de problème pour des RIA utilisant les API de certains réseaux sociaux. Nous nous retrouvons ainsi avec des bases SQLite, des fichiers XML ou d’autres types de fichiers possédant des informations en connexion à des services tiers en clair.

    Pour ceux qui ne savent pas, petit rappel. Adobe à implémenté un « système de chiffrement » stockant des données chiffrées en AES-CBC 128-bit grâce aux différentes API de chiffrement liées aux systèmes d’exploitation (DPAPI pour windows, Keychain pour Mac). Cette solution, utilisée par différentes applications (notamment certains clients Twitters).

    Bref, vous avez une description de cette protection à mettre en place sur la documentation officielle d’AIR élaborée par Abobe [DOC_ADOBE]. De plus, un petit tutoriel simple, mettant en place un couple login/passwd et une fonction « remember this » est également présent sur le site d’Adobe [TUTO_ADOBE] afin de mettre en place cette solution (avec les sources à télécharger). Les fichiers chiffrés sont disponibles (par exemple) sur Windows dans le répertoire ELS (Encrypted Local Store) siégeant fièrement dans le dossier AppData : \Adobe\AIR\ELS\[dossier de l'application]

    (UPDATE : Un très bon diapo est dispo [ICI] =)

    0×03 Sécurité serveur :

    Ensuite, nous pouvons voir d’importantes vulnérabilités côté serveur pour certaines applications utilisant AIR. Il n’est pas rare, là aussi d’entrevoir des possibilités d’SQL injection dans le SGBD distant de l’application, car certains développeurs ne vérifient pas les données envoyées à partir du serveur mais à partir de l’application. (Des fois, ils ne les vérifient pas du tout…), je n’ai pas testé des Xpath injections mais il est fortement probable que cela puisse fonctionner là aussi (tout du moins au point de vue théorique.)

    La vulnérabilité XSS de David Naylor – même si mon petit doigt me dit que certaines personnes l’avaient déjà :) – sur le service Twitter est aussi imputable à une mauvaise vérification de chaine de caractère envoyée à l’API de Twitter pour le nom de l’application. Il ne pas oublier de filtrer les données entrantes dans les bases de données distantes contre les injections de code exécutables en client-side – et non lors de leur récupération par un frontend, car le frontend peut, lui, être mis à jour laissant ainsi exécuter certains codes contenus dans la base de donnée. C’est la célèbre phrase : « Upgrade : to take out old bugs and put in new ones ».

    Twitter n’avait pas pensé à filtrer l’intégralité des données envoyées par l’intermédiaire de l’API… ce qui se traduisit donc par un énième EPICFAIL

    0×04 Conclusion :

    L’internaute est toujours avide de nouveaux gadgets pouvant ouvrir certaines vulnérabilités sur le système sans même se préoccuper de certains messages d’alerte lors de l’installation des applications AIR. Ceci, comme nous avons pu le voir, pouvant laisser une certaine porte d’entrée à des informations contenues sur l’ordinateur. De plus, des recherches sont faites actuellement sur la possibilité d’exécution de binaires en AIR et j’ai une petite idée derrière la tête à ce propos.

    Les développeurs de leurs côtés, laissent certaines vulnérabilités en client-side (mots de passes en clair) ou en server-side (failles web connues et re-connues) pouvant ainsi ouvrir certaines brèches, tant pour l’utilisateur (piratages de comptes) que pour le backend de l’application RIA (sans parler du site internet auquel souvent cette dernière est rattachée en vue de son téléchargement).

    Les RIA sont aujourd’hui en plein développement. Beaucoup de développeurs, du fait de la facilité à mettre en œuvre ces solutions réalisent souvent sans se préoccuper de la sécurité des ces petits widgets à l’apparence inoffensifs. Il est aujourd’hui préoccupant pour les utilisateurs de prendre conscience que n’importe quelle application/widget, quelque soit sa renommée peut être un danger pour l’intégrité de ses données s’il ne fait pas attention et n’analyse pas en détails le fonctionnement de cette dernière.

    Tags: , , , , , , , , , , ,
    Posted in Développement (divers), Sécurité des systèmes d'information | No Comments »

    Petit moment de rire.

    septembre 16th, 2009

    J’interrompe ma journée pour rigoler un coup. Ce matin, j’ai envoyé un commentaire sur le blog de Korben à propos d’un article qui présentait le site – aujourd’hui très connu – Securitytube. Bref, sur ce commentaire, j’ai mis mon nom et aussi l’adresse de mon site en lien et une personne est venue est s’est amusée à essayer d’injecter des quotes dans mon formulaire de mail.

    J’en rigole encore car cette personne n’a pas compris semble-t-il que les formulaires de contact sont fait pour envoyer des mails et n’ont aucune interaction avec la base de donnée (à tel point que j’ai pensé que c’était un fuzzer…). Oui, il existe des failles liées aux headers mail mais pas de quoi faire ressortir des informations juteuses… Alors, quand elle a testée cette soit disant vulnérabilité… et bien cela m’a envoyé un mail #FAIL.

    Bref, le meilleur du meilleur, dans tout cela, c’est que cette personne est unE employéE d’une société s’occupant de réseaux informatiques et télécoms mettant notamment en place des solutions de sécurité. Bref, la prochaine fois, demandez moi, ce sera plus facile pour me « pirater ».

    Comme je disais sur Twitter : Note à I*S informatique, franchement arrêtez, c’est trop marrant… les quotes dans les champs mail ça sert à rien… par contre, les bons proxys, cela peut servir…

    De plus, si vous voulez me pirater, passez par le Mutu, je pense que cela sera plus facile (n’ayant pas d’argent pour me prendre un dédié). Car, à part un pauvre Wordpress ayant deux plugins qui se battent en duel, il n’y a rien à voir.

    Posted in Sécurité des systèmes d'information | 2 Comments »

    Requête POST en cross-domain « presque-sans » JavaScript.

    août 27th, 2009

    Il y a encore quelques mois, on me disait qu’il était impossible de réaliser une requête POST automatiquement sans passer par de l’Ajax ou un Framework javascript tiers. (notez que celles en GET nécessitaient simplement un appel vers la page demandée par l’intermédiaire d’une image mal formée, un embed, ou une feuille de style etc.)

    Cette histoire de POST pouvait poser quelques problèmes lors de lorsqu’un script appelait des variables en POST et que PHP était configuré sans les register_globals (donc à off). Ainsi, nous devions forcément passer par une requête POST afin de faire passer les variables, cela incluait alors, dans le cadre d’attaques CSRF l’utilisation d’ajax dans une page afin de perpétrer l’attaque et d’envoyer les données au script.

    Gros problème, les navigateurs empêchent les requêtes ajax POST en cross domain pour des raisons évidentes de sécurité. Et puis, j’ai eu une idée, pourquoi ne pas passer par un formulaire HTML pur et de le valider sur un évènement ? Là était la réponse ! =) Il suffit simplement de réaliser une page contenant un formulaire et une image qui ne se charge pas contenant l’évènement (non DOM) onerror , par exemple, quelque chose dans ce genre :

    <form id="form" action="[vers la page vuln aux CSRF]" method="POST">
<input name="test1" type="hidden" value="valeur test 1" />
<input name="test2" type="hidden" value="valeur test 2" />
</form>
<img src="xxxx" onerror="form.submit()" />

    Et hop, vous avez votre requête POST, cross domain sans utiliser de l’Ajax =) Vous voulez voir ce que cela donne ? Allez par ici -> [ -]

    Pour conclure, nous pouvons dire que le code est simple, très simple, voir même trop simple. Nous pourrions un peu le customiser afin que l’envoi des données soit invisible pour l’utilisateur, mais je reste dans le cadre d’un PoC, donc pas de choses très méchantes ici.

    De plus, cette technique reste assez limitée dans l’efficacité qu’aurai pu avoir une requête à dose de javascript, car cela permet de faire autre chose bien plus élaborées… et surtout de récupérer certaines informations lorsque nous sommes sur le même domaine… (arf, le cross domaine, les navigateurs n’aiment pas cela et nous pouvons les comprendre… ah si, ie6 et < aiment ça, mais c’est une autre histoire…)

    Tags: , , , , , ,
    Posted in Sécurité des systèmes d'information, Tips&tricks | No Comments »