I. Présentation

Nous avons vu précédemment comment installer et utiliser Windows Terminal sous Windows 10. Je vous propose d'ailleurs plusieurs tutoriels à ce sujet, si vous voulez un peu de lecture :

• Windows Terminal : trucs et astuces
• Windows Terminal : personnaliser l'image de fond
• Windows Terminal : modifier la console par défaut
• Windows Terminal : ajouter une session PowerShell distante

Dans ce tutoriel, je vous propose de voir tout simplement comment installer Windows Terminal avec Chocolatey ou Winget, deux gestionnaires de paquets pour Windows 10.

II. Windows Terminal et Chocolatey

Si vous n'avez pas Chocolatey sur votre machine, il faut commencer par l'installer sinon ça va être difficile de l'utiliser pour installer Windows Terminal... Voici la commande pour l'installer à l'aide d'un script d'installation PowerShell à disposition sur le site officiel :

Set-ExecutionPolicy Bypass -Scope Process -Force; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

Cette commande doit être exécutée dans une console en tant qu'administrateur. Il suffit de patienter pendant l'opération.

Lorsque l'installation est terminée, vous pouvez appeler Chocolatey avec la commande "choco" :

choco

Si ça fonctionne, c'est tout bon ! Il va falloir installer Windows Terminal, tout simplement en précisant la commande "choco install" suivie du nom du paquet correspondant à cet outil. Ce qui donne :

choco install microsoft-windows-terminal

Lorsque le téléchargement est terminé, vous devrez indiquer "A" pour valider l'installation des différents éléments, à savoir Windows Terminal et ses dépendances.

Installed:
- kb2919355 v1.0.20160915
- kb3033929 v1.0.5
- chocolatey-core.extension v1.3.5.1
- kb2999226 v1.0.20181019
- kb2919442 v1.0.20160915
- vcredist140 v14.26.28720.3
- kb3035131 v1.0.3
- chocolatey-windowsupdate.extension v1.0.4

Packages requiring reboot:
- vcredist140 (exit code 3010)

Par la suite, pour mettre à jour Windows Terminal avec Chocolatey, voici la commande à exécuter :

choco upgrade microsoft-windows-terminal

Passons maintenant à l'installation via winget.

III. Windows Terminal et Winget

Pour installer Windows Package Manager (winget), vous devez utiliser le Microsoft Store ou Powershell, je vous oriente vers mon tutoriel si vous avez besoin d'aide : Installer Winget sur Windows 10

Ensuite, pour installer Windows Terminal à partir de l'outil winget en ligne de commande, il faut installer le paquet "Microsoft.WindowsTerminal". On peut d'ailleurs le vérifier d'une simple recherche :

winget search terminal

Nous devons utiliser "winget install" pour l'installer et l'on précisera l'option "-e" pour que le nom soit exactement celui que l'on précise. Sinon, winget indique qu'il existe deux paquets correspondants : effectivement, il y a "Microsoft.WindowsTerminal" et "Microsoft.WindowsTerminalPreview".

Voici la commande d'installation :

winget install Microsoft.WindowsTerminal -e

A vous de jouer et de profiter de Windows Terminal, que personellement, j'adore !

La plateforme de réservation en ligne de rendez-vous médicaux annonce avoir été victime d'un piratage. Suite à cet incident, ce sont les données administratives de 6 218 rendez-vous qui sont concernées.

Les équipes de sécurité de Doctolib ont détecté cette attaque le mardi 21 juillet 2020, qu'ils ont pu stopper dans la foulée et combler la faille de sécurité.

De son côté, Doctolib assure que les données n'ont pas fuité, mais l'attaquant a eu accès à ces informations pendant un court laps de temps. Néanmoins, Doctolib ne précise pas ce que représente "ce court laps de temps".

1. Mardi 21 juillet, notre équipe de sécurité a détecté et stoppé un acte malveillant contre Doctolib visant des informations administratives de rendez-vous. Aucun rendez-vous pris sur https://t.co/83E0LFU1vz ni aucune donnée médicale n'est concerné. https://t.co/6qK6Gi8R04 pic.twitter.com/S6R0jihnrT

— Doctolib (@doctolib) July 23, 2020

<script async src="https://platform.twitter.com/widgets.js" charset="utf-8">

Au niveau des informations administratives, nous retrouvons les éléments suivants concernant le patient : nom, prénom, sexe, numéro de téléphone et adresse e-mail. En complément, il y a la date du rendez-vous ainsi que le nom du professionnel de santé associé. Ce qui est rassurant, c'est que les mots de passe des comptes utilisateurs n'ont pas fuité, et Doctolib précise : « qu'aucun motif de rendez-vous, aucun document médical, aucune information relative au dossier médical des patients n'a été concerné ».

La faille de sécurité ne réside pas sur le site Doctolib directement, mais au niveau des interconnexions avec des logiciels tiers. Il y a fort à parier pour que cette vulnérabilité se trouve au sein de l'API utilisée par les logiciels tiers et mise à disposition par Doctolib. Cette interaction avec d'autres logiciels permet de faciliter la prise en rendez-vous pour les professionnels du médical.

Les patients concernés par ce piratage seront contactés par des établissements de santé afin de les informer de l'incident. La CNIL est également informée de ce piratage.

I. Présentation

L'objectif de cet article n'est pas de vous montrer comment remplir votre disque en un temps record. Mais j'avoue que dans certains cas, il peut s'avérer utile de pouvoir créer un fichier "vide" d'une taille définie afin de réaliser des tests sur quelque chose... Plutôt que d'aller chercher le dernier film dans votre collection, autant partir sur un fichier avec une taille que vous définirez.

Sans plus attendre découvrons cette astuce qui fonctionne sur toutes les versions de Windows, y compris Windows 10.

Tutoriel disponible au format vidéo :

II. Créer un fichier vide

Pour créer un fichier vide, c'est-à-dire remplis intégralement de caractères null, nous allons utiliser l'outil fsutil. Exclusivement disponible en ligne de commande, il sert à manipuler le système de fichiers de Windows, et notamment de créer des fichiers.

Il regorge de paramètres et les options sont nombreuses, mais concentrons nous sur le sujet de cet article : la création d'un fichier vide d'une taille définie.

Voici la syntaxe de la commande :

fsutil file createnew <chemin-vers-le-fichier> <taille-fichier>

Prenons un exemple. Nous allons créer un fichier de 50 Mo appelé 50-Mo.txt et que l'on va stocker dans le dossier "C:\Temp". Cela donne :

fsutil file createnew c:\Temp\50-Mo.txt 52428800

Après avoir exécuté la commande, on retrouve bien notre fichier et si l'on regarde ses propriétés, il fait bien exactement 50 Mo. Plutôt cool... et simple à la fois.

Puisque la commande fsutil nécessite une valeur exprimée en octet, voici quelques correspondances :

50 Mo = 52428800 octets
100 Mo = 104857600 octets
500 Mo = 524288000 octets
1 Go = 1073741824 octets

Amusez-vous bien... Mais attention à votre espace disque ! On aurait pu s'embarquer dans du code PowerShell pour créer un fichier vide, mais concrètement c'est plus simple avec fsutil (et surtout ça se fait en une seule ligne).

BadPower : des chercheurs chinois ont découvert un nouveau type d'attaque qui cible directement les chargeurs rapides dans le but d'endommager l'appareil connecté au chargeur.

Depuis plusieurs années maintenant, nos smartphones sont la plupart du temps livré avec un chargeur rapide, et ce dernier intègre un firmware contrairement à un chargeur classique. Pourquoi ? Simplement, car le chargeur rapide dispose d'un microcontrôleur qui doit échanger avec l'appareil qui se connecte, un smartphone par exemple, pour négocier une vitesse de charge et adapter la puissance. Cette intelligence repose sur un firmware.

L'attaque BadPower va venir modifier les paramètres de charge par défaut pour perturber le chargeur et faire en sorte qu'il délivre trop d'énergie à l'appareil connecté. Conséquences : les composants de l'appareil connecté vont être endommagés, car ils vont chauffer, voire même fondre ou brûler.

Pour injecter le firmware malveillant sur un chargeur, il suffit de s'y connecter. Les chercheurs chinois précisent alors qu'un smartphone ou un PC infecté sont des vecteurs possibles pour diffuser ce firmware malveillant. Il est à noter qu'une fois le firmware injecté dans le chargeur rapide, l'attaque fonctionnera sur tous les appareils qui vont se connecter au chargeur.

La gravité de l'attaque va dépendre des capacités du chargeur ciblé mais aussi du type d'appareil que l'on connecte. Certains chargeurs peuvent délivrer jusqu'à 60 Watts et peuvent recharger un PC alors que d'autres sont limités à 18 Watts.

L'équipe de chercheurs de chez Tencent Security Xuanwu Lab a testé 35 chargeurs différents. Au total sur cet échantillon, il y a 18 chargeurs vulnérables, en provenance de 8 fabricants différents. Ils estiment qu'il y a 234 modèles de chargeurs rapides sur le marché. En revanche, la liste des chargeurs qui sont impactés par ce problème n'est pas disponible. Dommage.

Pour les fabricants, il ne reste plus qu'à publier une mise à jour du firmware. Ensuite, à l'utilisateur de prendre le temps de l'installer, si ce n'est qu'il faut déjà être au courant du problème. Enfin, ce n'est pas si simple, car sur 34 puces analysées il y en a seulement 18 qui intègrent une fonction de mise à jour du firmware. Cela signifie que certains chargeurs ne pourront même pas être patchés.

Dans le rapport officiel, une vidéo de démonstration est disponible : BadPower

I. Présentation

Lorsque l'on rédige un script, on essaie généralement d'y aller petit à petit, et de le tester au fur et à mesure, puis arrive le moment fatidique : il faut exécuter le script. Le problème c'est qu'il n'est pas possible de le tester avant... Heureusement, Microsoft a prévu le coup et à intégré le paramètre -WhatIf à la majorité des commandes PowerShell qui effectue des modifications, sous réserve d'implémentation par les développeurs.

Si une commande est exécutée avec le paramètre -WhatIf, elle ne fera aucune modification sur votre système. Ce qui est intéressant, c'est que grâce à -WhatIf, des informations vont s'afficher dans la console pour indiquer qu'elles sont les actions réalisées pour chaque commande, ainsi que l'objet affecté. Un bon moyen d'anticiper un éventuel bug en complément des tests que l'on peut réaliser progressivement pendant la construction du script.

Tutoriel disponible en version vidéo ⬇

En consultant l'aide d'un cmdlet, on peut rapidement voir si le paramètre -WhatIf est supporté. Par exemple :

Get-Help New-Item

Une autre méthode serait de s'appuyer directement sur l'auto-complétion, tout simplement.

II. WhatIf dans la pratique

A. Premiers pas avec -WhatIf

Nous allons reprendre la commande New-Item citée précédemment et qui va altérer notre système puisqu'elle sert à créer un fichier ou un dossier. Par exemple, nous pouvons créer un fichier nommé "it-connect.txt" dans le répertoire courant, comme ceci :

New-Item -ItemType File -Name "it-connect.txt"

A première vue, rien de dramatique, mais imaginons que l'on ne sait pas trop ce que va faire la commande... Il est alors intéressant d'utiliser le paramètre -WhatIf pour regarder ce qu'elle va faire. Ce qui donne :

New-Item -ItemType File -Name "it-connect.txt" -WhatIf
What if: Performing the operation "Create File" on target "Destination: C:\TEMP\it-connect.txt".

On peut comprendre facilement que cette commande va créer un fichier à l'emplacement suivant : C:\TEMP\. Intéressant, non ?

Dans le même esprit, on peut prendre cette commande :

Get-Process *explorer* | Stop-Process

Si l'on se demande ce qu'elle va faire, on va simplement ajouter WhatIf à la fin :

Get-Process *explorer* | Stop-Process -WhatIf

A la lecture du retour obtenu dans la console, on comprends que la commande va exécuter l'action "Stop-Process" (tuer le processus) sur deux processus ayant les PID 3144 et 7692.

What if: Performing the operation "Stop-Process" on target "explorer (3144)".
What if: Performing the operation "Stop-Process" on target "explorer (7692)".

Sur le même principe, on pourrait utiliser WhatIf sur d'autres commandes notamment Stop-Service.

B. La variable $WhatIfPreference

Avec ce que l'on a vu précédemment, c'est pratique mais contraignant : il faut définir -WhatIf sur chaque commande, alors si l'on veut tester un script complet, ça peut vite devenir pénible. En effet, s'il faut s'amuser à ajouter le paramètre sur les différents cmdlets pour le retirer ensuite.... c'est chronophage !

C'est là qu'intervient la variable booléenne $WhatIfPreference, c'est-à-dire qu'elle peut avoir seulement deux valeurs : $true ou $false. Par défaut, la valeur est $false cela signifie que le paramètre WhatIf est désactivé pour l'ensemble des commandes, à moins de le spécifier au niveau d'une commande (comme vu précédemment). A l'inverse, si l'on définit sa valeur sur $true, WhatIf sera actif automatiquement sur toutes les commandes supportées : pratique car on peut basculer d'un mode à l'autre d'une seule commande.

Pour basculer sur le mode $true, il suffit d'exécuter cette commande :

$WhatIfPreference = $true

Si je ré-exécute la commande précédente, on peut voir que le WhatIf s'active sans que je le précise à la fin de la commande 😉 - Lorsque les tests seront concluants, il suffira de faire machine arrière :

$WhatIfPreference = $false

Pour les développeurs qui souhaitent créer leurs propres commandes, vous pouvez implémenter -WhatIf dans vos fonctions par l'intermédiaire du paramètre "[CmdletBinding(SupportsShouldProcess)]" qui va permettre d'ajouter le support de WhatIf et Confirm à votre fonction. Ce sera à vous ensuite d'alimenter le message qui s'affiche lorsque le WhatIf est appelé 👍

A vos tests !