BASIC PENTESTING

Membre du groupe : Aida Diagne KOMBO, Mohamed DIOUF, Sembala TRAORE

1. Déployer la machine et se connecter à notre réseau

2. Trouver les services exposés par la machine
On a les ports 22, 88, 139, 445, 8009, 8080 qui sont ouverts et nous avons des applications qui tournent dessus.

3. Quel est le nom du répertoire caché sur le serveur Web (entrez le nom sans /) ?
Le nom du répertoire cache est development.

4. Utiliser le forçage brutal pour trouver le nom d’utilisateur et le mot de passe
Nous avons trouvé l'utilisateur mais nous n'avons de mot de passe associé. Nous allons alors chercher le mot de passe en utilisant un outil qui s'appelle hydra qui va chercher le mot de passe associé à cet utilisateur dans son dictionnaire de mot de passe
Le mot de passe est armando

5. Quel service utilisez-vous pour accéder au serveur (réponse en abréviation dans toutes les majuscules) ?
Nous avons utilisé SSH.

RAPPORT D’AUDIT

E4 CCSN 2021 2022
Controle document

Historique de révision
Version: 1.0
Date: 06/07/2022
Auteur: ESTIAM

SOMMAIRE

Introduction

Périmètre

Vulnérabilité

Recommandation

Introduction

Le 15 Juin 2022, l’équipe d’ESTIAM E4 CCSN à effectuer des test d’intrusion sur l’application ag.ums.sn.

Ce document relate les informations recueillies ainsi que les vulnérabilité trouvées et les solutions apportées.

Ce qui a été fait : Nous avons effectuer le pentest sur l’applications ag.ums.sn qui sert de réservation

Ce qui a été trouvé : Voir la partie vulnérabilité

Ce qui va étre fait ensuite : Voir la partie recommandation

I. Périmètre

Le périmètre du pentest a été choisi selon la disponibilité des actifs (application)

- Application

Nous avons effectué un pentest sur l’application disponible via le lien ag.ums.sn.

II. Vulnérailités

- Application

Le pentest a été realisé par l’outil OWASP-ZAP et les vulnérabilité suivantes ont été trouvées.

Vous avez l’ensemble des informations sur le tableau ci-dessous avec les niveaux criticités:

Nous allons voir en détails les caractéritique de chaque vulnérabilté et leurs impacts.

- Cross Site Scripting (basé DOM) – XSS
Description

Le cross-site Scripting (XSS) est une technique d'attaque consistant à retourner du code fourni par l'attaquant à une instance de navigateur d'un utilisateur. Une instance de navigateur peut être un navigateur standard, un objet navigateur incorporé dans un produit logiciel (p.ex. le navigateur dans WinAmp), un lecteur RSS ou un client de messagerie. Le code lui-même est généralement écrit en HTML/JavaScript, mais peut être aussi en VBScript, ActiveX, Java, Flash ou toute autre technologie supportée par les navigateurs.

Lorsqu'un pirate parvient à faire exécuter son code par le navigateur d'un utilisateur, le code s'exécute dans le contexte de sécurité (ou zone) du site web hébergeur. Avec ce niveau de privilège, le code a la capacité de lire, modifier et transmettre toutes les données sensibles accessibles par le navigateur. Un utilisateur sujet au Cross-site Scripting pourrait voir son compte piraté (vol de cookie), son navigateur redirigé vers un autre site, ou éventuellement voir apparaître du contenu frauduleux envoyé par le site internet qu'ils visitent. Les attaques par Cross-site Scripting compromettent fondamentalement la relation de confiance entre un utilisateur et le site web. Les applications utilisant des instances d'objet de navigateur, et qui chargent du contenu depuis le système de fichiers, peuvent exécuter du code dans le périmètre de confiance de l'ordinateur, mettant ainsi en danger le système.

Il existe trois types d'attaques par Cross-site Scripting : non persistant, persistant et basé sur les DOM.

Les attaques non persistantes et celles basées sur les DOM nécessitent qu'un utilisateur visite un lien incorporant un code malveillant, ou visite une page web malveillante contenant un formulaire internet, qui, une fois publié sur le site vulnérable, permettra l'attaque proprement dite. Un formulaire malveillant sera souvent utilisé lorsque la ressource vulnérable n'accepte que les requêtes HTTP POST. Dans un tel cas, le formulaire peut être envoyé automatiquement, sans que la victime n'en ait conscience (p. ex. à l'aide de JavaScript). En cliquant sur le lien malveillant ou en soumettant le formulaire malveillant, le code XSS s'affichera en retour et sera interprété et exécuté par le navigateur de l'utilisateur. Une autre technique pour envoyer des requêtes presque arbitraires (GET et POST) consiste à utiliser un client intégré, tel que Adobe Flash.

Les attaques persistantes se produisent lorsque le code malveillant est envoyé à un site internet où il est stocké pendant un certain temps. Des exemples de cibles favorites des pirates sont les publications sur les tableaux de messages, les messages de courrier électronique et les logiciels de tchat internet. Aucune interaction avec un quelconque site/lien supplémentaire (par exemple, un site de pirate ou un lien malveillant envoyé par e-mail) n'est requis de la part de l'utilisateur sans méfiance, il suffit de visualiser la page internet contenant le code.

- Application Error Disclosure
Cette page contient un message d’erreur qui peut divulguer des renseignements sensibles comme l’emplacement du fichier qui a produit l’exception non gérée. Ces informations peuvent être utilisées pour lancer d’autres attaques contre l’application web. L’alerte peut être un faux positif si le message d’erreur se trouve à l’intérieur d’une page de documentation.

- Directory Browsing
Il est possible de visualiser la liste des répertoires. Cette dernière peut révéler des scripts cachés, des fichiers inclus, des fichiers sources de sauvegarde auxquels on peut accéder pour lire des informations sensibles.

- X-Frame-Options Header
X-Frame-Options header n’est pas inclus dans la réponse HTTP pour protéger contre les 'ClickJacking'.

- Absence of Anti-CSRF Tokens
No Anti-CSRF tokens n’a été trouvé dans un formulaire de soumission HTML La contrefaçon de requête inter-sites (Cross Site Request Forgery - CSRF) est une attaque qui consiste à forcer une victime à envoyer une requête HTTP vers une destination cible, sans qu'elle n'en aie ni connaissance ni intention, afin d'effectuer une action en se faisant passer pour la victime. La cause originelle est que les fonctionnalités de l'application sont appelées à l'aide d'URL ou d'actions de formulaires prévisibles et reproductibles. La nature de l'attaque est que le CSRF exploite la confiance qu'un site internet accorde à un utilisateur. En revanche, le cross-site scripting (XSS) exploite la confiance que l'utilisateur porte à un site internet. Comme XSS, les attaques CSRF ne sont pas nécessairement multi-sites, mais elles peuvent l'être. La contrefaçon de requête inter-site est également connue sous les noms CSRF, XSRF, attaque en un clic (one-click attack), session riding, confused deputy et sea surf.

Les attaques CSRF sont efficaces dans de nombreuses situations, notamment:

* quand la victime a une session active sur le site cible.

* quand la victime est authentifiée via HTTP auth sur le site cible.

* quand la victime est sur le même réseau local que le site cible.

CSRF a d'abord été utilisée pour effectuer une action contre un site cible en utilisant les privilèges de la victime, mais des techniques récentes permettent d'avoir accès à des renseignements en

accédant à la réponse. Le risque de divulgation d'informations est considérablement augmenté lorsque le site cible est vulnérable aux XSS, parce que XSS peut être utilisé comme une plateforme pour CSRF, permettant à l'attaque d'opérer dans les limites de la politique de même origine.

- Cross-Domain JavaScript Source File Inclusion
La page comprend un ou plusieurs fichiers de script d’un domaine tiers.

- X-Content-Type-Options Header Missing
The Anti-MIME-Sniffing header X-Content-Type-Options n’était pas défini sur 'nosniff'. Cela permet aux anciennes versions d’Internet Explorer et de Chrome d’effectuer un MIME-sniffing sur le corps de réponse, ce qui peut entraîner l’interprétation et l’affichage du corps de réponse en tant que type de contenu autre que le type de contenu déclaré. Les versions actuelles (début 2014) et anciennes de Firefox utiliseront le type de contenu déclaré (si on est défini), plutôt que d’effectuer MIME-sniffing.

III. Recommendation