Solventar los problemas de la Security Update de Julio de 2019

Es posible que tras la actualización de Julio de 2019 (Monthly rollup) sobre equipos Windows 7 o Server 2008 R2 sp1 arrancando con UEFI, nos encontremos con que los equipos no arrancan mostrando un fallo del tipo "Info: An error has occurred while attempting to read the boot configuration data.", o bien "Windows cannot verify the digital signature for this file" provocando que el equipo no arranque y solo permita llegar a la pantalla de reparación.

Esto es debido a un error en los parches desplegados por Microsoft. Lo gracioso es que la actualización KB4512506 que causa el problema se lanzó el 13 de Agosto de 2019, y la solución está en la KB4512514, preview para la siguiente actualización, lanzada el 17 de Agosto. De manera que en vez de modificarse la monthly rollup, te puedes encontrar con que tus maquinas actualizadas a partir de las actualizaciones de seguridad mensuales, no arranquen, así que cuidadito con las updates del verano.

Si el problema que se muestra es que efectivamente tu equipo, con arranque UEFI arranca automáticamente a la ventana de recuperación del equipo, la solución consiste en reemplazar los ficheros winload.efi, winload.exe, winresume.efi y winresume.exe. Vamos a ello:

• Desde la consola de recuperacion, vamos a la ruta donde tengas tu instalacion de Windows. Si es C:\, la ruta es c:\windows\winsxs\C:\windows\winsxs\
• Entramos en la carpeta "amd64_microsoft-windows-b..vironment-os-loader_31bf3856ad364e35_6.1.7601.24499_none_b984965a9ca0bb23" sin comillas, todo seguido, sin espacios. Dentro de esta carpeta, veremos 4 archivos.
• Escribimos "md c:\w" Cambiar la C por la unidad en la que se encuentre tu instalacion. Este comando creará un directorio con el nombre "w" en la raiz de c.
• Escribimos copy . c:\w . Deberia mostrar "4 archivos copiados"
• Seguidamente vamos a system32 con cd \windows\system32
• Escribimos copy c:\w\*.* . Esto reemplazará los anteriores archivos. Puedes hacer previamente una copia de ellos
• Salimos de la consola, y reiniciamos. 

Solo hay que seguir los pasos de la imagen superior. El equipo debería arrancar sin problemas.

Ah, un pequeño detalle: La carpeta donde se encuentran los 4 archivos corresponde a la copia de los mismos de Junio. Por tanto, se crearan en esa ruta distintos "backups" con lso que podemos afinar la restauracion a lo largo del tiempo, o en caso de no encontrar exactamente la ruta indicada más arriba.

Tipo de disco no admitido o no válido para 'scsi0:0'. Asegúrese de que se haya importado el disco.

Para ponernos en situacion sobre la causa y resolucion del aviso "Tipo de disco no admitido o no válido para 'scsi0:0'. Asegúrese de que se haya importado el disco", os comento este ejemplo desde el inicio.

Vamos a instalar un Appliance cualquiera, en este caso, Zabbix, donde indican la descarga en un formato aparentemente válido, VMDK.

Me salto los pasos de descargar el archivo, descomprimir, crear la carpeta de la VM, subir los archivos al datastore y registrar la VM. Hasta aqui, todo perfecto. Es cuando arrancas la Vm cuando te encuentras con el error antes mencionado.

Basicamente, este error viene provocado por una incompatibilidad del archivo VMDK, no tanto por el formato, si es thin, thick, lazy zero, o cualquier otro formato, sino por la compatibilidad del VMDK con el producto de VMware que lo soporta. Me explico: muchas veces, estos archivos se generan pensando en las versiones más simples del producto, y por ello su formato es VMware Fusion, Player o Workstation. El producto ESXi es otra historia, y en este caso, es donde lo hemos subido, y donde la máquina falla a la hora de inicializarse.

Siempre que tratemos con appliances en este formato, la forma más simple de solventar este problema es realizar una conversion de formato a la vez que subimos el appliance a nuestro datastore. Para ello, utilizaremos VMware Converter.

Abrimos la aplicacion y pulsamos sobre Convert Machine.

Tenemos solo los archivos del appliance, no necesitamos poner la maquina en funcionamiento. Solo indicamos en las opciones, "Powered off", y marcamos el archivo de nuestro appliance.

Este paso es importante: indicamos que el destination type es VMware Infrastructure virtual Machine, no un vmware workstation o similar. Ponemos los datos para la conexión con nuestro vCenter (importante, el vCenter, no el ESXi).

Indicamos el nombre de la VM, y la ubicacion que debe tener, y next. Iniciará el despliegue de la VM. Tras esto, podreis arrancarla sin los problemas anteriores.

Después de todo esto, que en el fondo es un "workaround" en caso de encontrarte con este fallo, la moraleja es: si puedes, descarga el appliance en formato OVF (Open Virtualization Format), que no te dará tanta guerra y es fácilmente importable desde la consola de vCenter.

Habilitar copy-paste para la consola de VMware

Usualmente me conecto a las VM´s via Escritorio Remoto de Windows, pero hay que reconocer que la consola de VMware es cómoda para trabajar, sobre todo en primeras configuraciones, cuando todavia no está bien habilitada la red, por poner un ejemplo. Aunque se echa en falta la simple posibilidad de utilizar el portapapeles. El poder, en tu equipo, copiar por ejemplo un password complicado que debes introducir en la nueva maquina para lo que sea, o peor aún, debes ejecutar un script de cientos de lineas, y no tienes forma de pasarlo, con lo facil que sería con un coypaste.

Copypaste es una opción que originalmente existia en VMware, pero en la version 4.1 se deshabilitó, por problemas de seguridad. Por suerte, es facil habilitarlo, sólo tenemos que seguir los siguientes pasos:

• Verificar que tenemos las VMware Tools instaladas. Si no es asi, ¡tienes un problema serio! ¡Son vitales! Instalalas sin falta.
• Apagamos la VM, y vamos a la pestaña "summary". Ahí pulsamos sobre Edit settings.

• Seguidamente, vamos a la pestaña "VM Options", en las opciones de la izquierda expandimos "Advanced", y pulsamos sobre "Edit Configuration"

• Nos aparecerán los parámetros de configuración de la VM.Abajo, veremos la opción "add row". Tenemos que añadir los siguientes parámetros:

"isolation.tools.copy.disable", sin las comillas, y en valor, "FALSE", y otra linea mas con "isolation.tools.paste.disable" con valor "FALSE" igualmente, tal y como se ve en la imagen superior.

• Pulsamos Ok, vamos cerrando los cuadros de dialogo, y ya está. SOlo queda arrancar de nuevo la VM.

Esta opción sólo modifica la VM sobre la que lo has hecho, pero puede ser que quieras activar estas opciones para toda tu granja de servidores. En ese caso, tendrás que modificar las opciones en el host ESX. Para ello, nos conectamos al ESXi como root, hacemos backup del fichero /etc/vmware/config antes de modificarlo, y seguidamente, lo editamos, añadiendo estas entradas al archivo:

vmx.fullpath = "/bin/vmx"
isolation.tools.copy.disable="FALSE"
isolation.tools.paste.disable="FALSE"

Tras esto, guardamos y cerramos el archivo.
Por cierto, la activación no es inmediata, se habilitarán cuando las VM´s se reinicien (o apagando y encendiendo, claro). Ten en cuenta también que si actualizas el host, habrá que volver a realizar los cambios.

Convertir una version de evaluacion de Windows en una Full Version

Como sabréis, podéis descargaros de la web de Microsoft la versión de evaluación de sus distintos productos, con un periodo de evaluación de 180 días (aunque luego explicaré como prolongar este estado de vida útil, y de manera totalmente legal). La versión de evaluación de Windows Server 2012, por ejemplo, la podeis descargar desde AQUI, así como los nuevos productos que están de camino, como la versión Server 2016.

Lo primero de todo: tu versión de Windows tendrá un aviso como este:

Siendo este el caso, lo primero que haremos será determinar con exactitud la versión de Windows que estamos utilizando. Para ello, abrimos una ventana de comando con privilegios de administrador, y ejecutamos el siguiente comando: DISM /Online /Get-CurrentEdition

Esto nos dirá la edicion que tenemos. Lo siguiente, será saber a qué ediciones podemos optar. Para ello, ponemos el comando DISM /online /Get-TargetEditions:

En este caso, y al ser un Datacenter Evaluation, solo nos da la opcion de actualizar a Datacenter. Pero si la version hubiera sido una Standar Evaluation, nos habria dado opcion de actualizar a una version Standar y a una Datacenter.

Bueno, ya tenemos nuestra version, y el nombre de la version a la que podemos actualizar. Ahora viene el paso en el que cambiamos la version, y el serial number que tengamos para la nueva version. El comando es DISM /online /Set-Edition: <el ID de la edicion, por ejemploServerDatacenter, sin los corchetes> /ProductKey:xxxxx-xxxxx-xxxxx-xxxxx-xxxxx /AcceptEula
Obviamente, ¡no pongas las X, sino tu serial number!

Este proceso requerirá dos reinicios. Aunque a veces, la máquina se queda frita por la tarjeta de red, y aunque cambia bien la versión del producto y el serial, no activa. Verifica que tienes conectividad, y dale otro reinicio, en caso de que no. A partir de ahí, es paciencia, o ir a activación, y decirle que active en el momento.

¡No tiene mas! Simple, rápido, y sin andar reinstalando Windows, como pide la versión de Evaluación cuando intentas ponerle una licencia Full Version

Flipboard ha sido hackeada

Según un comunicado que están recibiendo los usuarios de Flipboard, éstos han tenido accesos no autorizados a sus BBDD, aunque por los sistemas de seguridad que implementan, el riesgo de exposición de las contraseñas es nulo. Aun así, han reseteado todos los pass de acceso, de manera que en nuevos dispotitivos, cuando accedas a tu cuenta de Flipboard, te encontraras con un aviso para el cambio de contraseña. En cambio, en dispositivos donde ya estuvieras logueado, podras seguir accediendo sin problemas.

Adjunto el comunicado al completo:

Querida comunidad de Flipboard:

Nos comunicamos con ustedes para notificarles un incidente de seguridad que hemos identificado y abordado recientemente en relación con un subconjunto de datos de usuarios. Sabemos que la transparencia es importante para nuestra comunidad y queremos compartir con ustedes lo que hemos aprendido de nuestra investigación, las medidas que hemos tomado, y los pasos que pueden adoptar de ahora en adelante.

Lo que ha sucedido

Recientemente identificamos accesos no autorizados a algunas de nuestras bases de datos que contienen información de cuenta de ciertos usuarios de Flipboard, incluidas las credenciales de sus cuentas. En respuesta a este descubrimiento, lanzamos inmediatamente una investigación y contratamos una firma especializada en materia de seguridad para recibir asistencia. Los resultados de la investigación indican que una persona no autorizada accedió y probablemente obtuvo copias de ciertas bases de datos que contienen información de usuarios de Flipboard entre el 2 de junio de 2018 y el 23 de marzo de 2019 y entre el 21 y el 22 de abril de 2019.

De qué información se trataba

Es posible que las bases de datos afectadas tuvieran su nombre, su nombre de usuario de Flipboard, la contraseña protegida criptográficamente y la dirección de correo electrónico.

Flipboard siempre ha protegido las contraseñas criptográficamente utilizando una técnica conocida por los expertos en seguridad como "salted hashing". La ventaja de proteger contraseñas con código hash es que nunca necesitamos almacenarlas en texto sin formato. Asimismo, el uso de una sal única para cada contraseña en combinación con los algoritmos de hash hace que sea muy difícil y requiere importantes recursos informáticos para descifrar estas contraseñas de hash. Si usted creó o cambió su contraseña después del 14 de marzo de 2012, estará protegida por un algoritmo hash con una función denominada bcrypt. Si no ha cambiado su contraseña desde entonces, tendrá la protección exclusiva de sal y hash con SHA-1.

Además, si conectó su cuenta de Flipboard a una cuenta de terceros, incluidas las cuentas de redes sociales, es posible que las bases de datos contengan tokens digitales utilizados para conectar su cuenta de Flipboard a esa cuenta de terceros. No hemos encontrado prueba alguna de que la persona no autorizada accediera cuenta(s) de terceros conectada(s) a sus cuentas de Flipboard. Como medida de precaución, hemos reemplazado o eliminado todos los tokens digitales.

Es importante aclarar que no recogemos de los usuarios, y este incidente no involucra números de Seguridad Social u otros documentos de identidad emitidos por el gobierno, cuentas bancarias, tarjetas de crédito u otra información financiera.

Qué estamos haciendo

Como medida de precaución, hemos restablecido todas las contraseñas de los usuarios, aun cuando estaban protegidas criptográficamente y no toda la información de la cuenta de los usuarios estaba involucrada. Puede seguir utilizando el Flipboard en los dispositivos desde los que ya ha iniciado sesión. Cuando acceda a su cuenta de Flipboard desde un dispositivo nuevo, o la próxima vez que inicie sesión en Flipboard después de salir de su cuenta, se le pedirá que cree una contraseña nueva.

Otra medida de precaución es que desconectamos los tokens que servían para conectar a cuentas de terceros, y en colaboración con nuestros asociados, reemplazamos o eliminamos todos los tokens digitales donde resultaba pertinente.

Asimismo, para contribuir a evitar que se repita un incidente como este en el futuro, hemos implementado medidas de seguridad mejoradas y seguimos buscando formas adicionales de reforzar la seguridad de nuestros sistemas. También hemos notificado a las fuerzas del orden.

Lo que usted puede hacer

Puede seguir usando Flipboard sin más. Sin embargo, la próxima vez que inicie sesión en su cuenta, observará que la contraseña de su cuenta de Flipboard necesita ser actualizada. Encontrará las instrucciones en nuestra página de apoyo (enlace abajo) que explican cómo crear una nueva contraseña. Además, si usa el mismo nombre de usuario y contraseña que creó para Flipboard o cualquier otro servicio en línea, le recomendamos que también cambie su contraseña allí.

Si ha conectado su cuenta de Flipboard a una cuenta de terceros para ver su contenido, en algunos casos observará que necesita reconectarla. En nuestra página de apoyo también encontrará instrucciones para la manera de hacer esto.

Adónde acudir para obtener más información

Lamentamos mucho que haya sucedido este incidente. Para obtener más información y respuestas a las preguntas frecuentes, hemos creado una página de apoyo con más detalles sobre el incidente.

Con todo esto, aun así, recomiendo el uso de esta herramienta para estar informado en todos los ámbitos que quieras, y perfectamente integrada para su uso en móviles y tablets.

Forzar vaciado de carpeta "Deleted Items" en Office365

Un pequeño problema observado con el trabajo en cuentas de Office365 consiste en el límite que éstas tienen en las carpetas creadas por defecto, como por ejemplo, deleted items. En este caso, el problema es causado por una limpieza del buzón de correo enviando más de 30 Gb a la papelera, y tras eso, forzar el borrado.

Aunque la carpeta nos da el mensaje de que no hay items contenidos en ella, se podían ver miles de mails contenidos. Esto es debido a la política de retención por defecto en la cuenta, que realiza el borrado definitivo e irrecuperable en un periodo de tiempo de 14 días.

Para solventar este problemilla, lo que podemos hacer es forzar la eliminación de los elementos. Aun así, la solución puede llevar 24 horas en aplicarse correctamente. Veamos los pasos a dar:

Abrimos Powershell como administrador local

Ejecutamos esto:

Set-ExecutionPolicy RemoteSigned

Seguidamente,

$UserCredential = Get-Credential

Las credenciales que ponemos son las de usuario administrador en office365, el login de acceso, que será un mail

Si tenemos un proxy, ejecutamos esto:

$ProxyOptions = New-PSSessionOption -ProxyAccessType <Value>

Donde Value será la configuración que necesites, en este caso,

$ProxyOptions = New-PSSessionOption -ProxyAccessType IEConfig

Las opciones posibles son IEConfig, WinHttpConfig o AutoDetect

A continuación, escribimos el siguiente comando:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri 

https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic –AllowRedirection

Si has utilizado proxy, agregas al final -SessionOption $ProxyOptions. O sea, quedaría asi:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic –AllowRedirection -SessionOption $ProxyOptions

Si da error del este tipo,

Ejecutar el siguiente comando: Import-PSSession $Session –DisableNameChecking

Cargará el cmdlet, y probamos si funciona, con un get-mailbox “tubuzondecorreo”, asi, entrecomillado

Si aparecen los datos del buzon, introducimos el siguiente comando:

Set-mailbox “tubuzondecorreo” -RetainDeletedItemsFor 0

Seguidamente,

Start-ManagedFolderAssistant “tubuzondecorreo”

El proceso de vaciado de los deleted items puede llevar horas. Una vez finalizado, recordar cambiarlo de nuevo a 14 días, con:

Set-Mailbox “tubuzondecorreo” –retainDeletedItemsFor 14

En caso de querer examinar el progreso, puedes utilizar el siguiente comando:

Get-MailboxFolderStatistics usuario@dominio.com  | FT name,foldersize,ItemsInFolderAndSubfolders

para comprobar si el tamaño de "purges" va disminuyendo. Ademas, obtienes el listado detallado de ocupacion de las distintas carpetas. Si lo quieres en un documento de texto, al final del comando, agregamos un pipe (|) con el siguiente contenido:
Out-File -FilePath C:\larutaquequieras\nombredeldoc.txt

Si diera un problema de conexión, utilizar previamente este comando:

Start-ManagedFolderAssistant usuario@dominio.com

Si no, repetir todo el proceso para reconectar.

¡Y esto es todo!

Obtener un listado de números de serie y modelos de tus equipos

He aquí un pequeño script de Powershell para obtener, a partir de un listado previo de equipos en formato .txt, otro listado igual pero agregando a la lista el número de serie y modelo del equipo.

Ni que decir tiene que las máquinas, ya sean servidores o equipos, deben estar encendidas y accesibles desde tu red. Aquí va el script:

$file= "C:\listado.txt"
$inf = get-content $file
Out-File -FilePath C:\listadocompleto.txt -Append -InputObject "servidor;serial;modelo"
Foreach($server in $inf)

 {
$serial = gwmi win32_bios -computername $server |Select-Object -ExpandProperty SerialNumber
$model = Get-CimInstance -ClassName Win32_ComputerSystem -computername $server | Select-Object -ExpandProperty model


Out-File -FilePath C:\listadocompleto.txt -Append -InputObject "$server;$serial;$model"
}

Como ves, realmente el script ejecuta sobre cada una de las lineas del documento "listado.txt" los comandos gwmi win32_bios -computername, que te va los valores de versión de BIOS, fabricante, nombre de versión, Numero de Serie, y versión (que no es exactamente el modelo).

luego, al comando gwmi win32_bios -computername se le hace un "|" para indicarle que el único dato que queremos extraer es el SerialNumber. En la imagen superior puede ver los dos ejemplos, el comando ejecutado al completo, o sin la selección de SerialNumber.

Con la siguiente linea sucede lo mismo: tenemos Get-CimInstance -ClassName Win32_ComputerSystem -computername, que nos da una serie de valores como el nombre del equipo, propietario, dominio, memoria fisica, modelo (que es lo que nos interesa), y fabricante.

Igual que con el anterior comando, la primera parte nos da bastantes datos, y con el "|" agregamos el "Select-Object -ExpandProperty model" para obtener únicamente el modelo del equipo.

Finalmente, la ultima parte del script mete en un nuevo documento los equipos del listado inicial, y agrega el resto de campos solicitados.