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.

Vulnerabilidad crítica en Servicio RDP de Windows

Microsoft acaba de publicar una vulnerabilidad 0-Day de carácter crítico, junto con el parche de aplicación.

Esta vulnerabilidad permite a un atacante no autenticado en el sistema realizar una peticion especial de servicio RDP que permitiría la ejecución de código arbitrario en el equipo, y por tanto, podria desde instalar programas, a crear nuevas cuenta de usuario con permisos de administrador.

Además, esta vulnerabilidad es preautenticación (como decía anteriormente basta con realizar una petición especial de servicio), y no requiere interacción por parte de los usuarios.

El boletín de seguridad de Microsoft con los parches a aplicar para distintos sistemas operativos puede encontrarse aquí:

Windows 7, Windows Server 2008, and Windows Server 2008 R2

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0708


Windows XP, Windows Server 2003
https://support.microsoft.com/en-us/help/4500705/customer-guidance-for-cve-2019-0708


El parche es tan grave que, igual que pasó con el ransomware Wannacry, han publicado parches incluso para Windows Server 2003 y Windows XP

La buena noticia es que solo afecta a los sistemas operativos indicados, Windows XP, Windows 7, Windows Server 2003, Windows Server 2008 y 2008 R2, todos ellos obsoletos, con lo que aunque el riesgo para estos sistemas es alto, no deberían estar funcionando ni en tu casa ni en tu empresa.

No se ven afectados por esta vulnerabilidad Windows 10, Windows 8.1, Windows 8, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, ni Windows Server 2012.

Los parches específicos para equipos Windows 7 son el kb4499175-x64.msu y el kb4499175-x86.msu, asi como el kb4500331 para Windows XP, pero si dispones de la posibilidad de implementar el de los links superiores, donde se agregan a una monthly update, mejor que mejor.


Microsoft no ha liberado las PoC (Pruebas de concepto) para esta vulnerabilidad, con el objetivo de dar algo más de margen a los fabricantes de antivirus y antimalware a poner a punto sus soluciones.


Puedes obtener más informacion en el blog de Microsoft, AQUI,

La VM no arranca con "This virtual machine appears to be in use"

Recientemente me he encontrado con el problema de VM´s funcionando en los equipos locales de algunos usuarios, que reportaban un fallo a la hora de encender la VM. Concretamente, el fallo era "This virtual machine appears to be in use"

Las opciones son, cancelar, para evitar daños, o tomar la propiedad del objeto, el archivo .vmx.
Si seleccionar "tomar la propiedad del objeto", inmediatamente saldrá otro mensaje indicando que la acción ha fallado, imposibilitando la ejecución de la VM. Incluso si revisas los permisos del archivo, verás que probablemente el objeto tenga los permisos adecuados. Entonces, ¿cómo se solventa esto?

La solución es fácil: Si tomases el archivo .vmdk y montases una nueva VM, el problema se solventaría, pero hay una solución más elegante. En los archivos de la VM con el fallo, debemos buscar los archivos .lck o .lock, y eliminarlos. Para eliminarlos, debemos tener cerrado VMware Workstation, o bien hacer retirado la VM de VMware Workstation, aunque luego tendremos que volver a agregarla. Lo que prefieras.
Puedes ser que .lck sea una carpeta, en cuyo caso, la eliminamos igualmente, con todos sus archivos.
Tras esto, ya podrás abrir VMware, o bien agregar de nuevo la VM e iniciarla.

Tras investigar la causa por la que este archivo se queda bloqueado, resultó que el usuario que suele tener este error, en vez de apagar la VM con el "shut down guest file system", solía apagarla con el botón de power off, en algunos casos, seguido del apagado del equipo que ejecuta VMware, sin esperar al cierre de procesos.