Powershell: obtener la temperatura de la placa base en grados celsius.

¿Se puede obtener la temperatura de la placa base en Windows sin necesidad de apps externas y sin tener que entrar al a BIOS? Se puede con PowerShell.

Lo primero que tenemos que hacer es ejecutar PowerShell con permisos de administrador. Luego si ejecutamos este comando podríamos obtener un array con un par de lecturas de la temperatura de nuestra placa base en ese momento:

$(Get-WmiObject MSAcpi_ThermalZoneTemperature -Namespace "root/wmi").CurrentTemperature

Pero claro, esto no nos da la temperatura en grados celsius, ni siquiera en kelvin realmente. Si queremos ver esos datos tenemos que operar: si dividimos ese valor entre 10 obtendremos la temperatura en grados kelvin, después para convertir de kelvin a celsius habría que restar 273.15 grados. Estas operaciones podemos meterlas directamente en el comando que ejecutamos para no tener que andar haciendo cálculos manuales. Ojo, porque el objeto al que llamamos nos devuelve un array, para poder operar yo voy a acceder al primer elemento de la respuesta y forzar la conversión a entero para poder trabajar sin problema. Nos quedaría tal que así:

[int]($(Get-WmiObject MSAcpi_ThermalZoneTemperature -Namespace "root/wmi").CurrentTemperature[0])/10-273.15

Voy a recalcar que esta temperatura es la de la placa base y no la del procesador, que generalmente suele ser más alta.

¿Cómo leer un fichero de Excel en ASP clásico?

Pues me encontraba estos días trabajando con una aplicación web antigua en ASP clásico que requería una nueva funcionalidad: importar datos que el cliente recibiría en una hoja de Excel, una hoja que en principio siempre tendrá el mismo formato. La duda era ¿cómo hago para leer el fichero de Excel con el viejo VBScript? Pues en este caso he usado el motor de Access 2010 (puede descargarse desde la web de Microsoft) y su conector OLEDB para tratar la hoja de Excel como si fuera una tabla SQL. Aquí os dejo un ejemplo del código:

Declare ExcelFile, Consulta, ExcelConnection, RSDatos
ExcelFile = "C:\Users\MiUsuario\MiCarpeta\MiExcel.xls"

Consulta= "SELECT [Campo1], [Campo2],[Campo3] FROM [Hoja1$]"
Set ExcelConnection = Server.createobject("ADODB.Connection")
ExcelConnection.Open "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & ExcelFile & ";Extended Properties=""Excel 12.0 Xml;HDR=YES;IMEX=1"";"
SET RSDatos= Server.CreateObject("ADODB.Recordset")
RSDatos.Open Consulta, ExcelConnection

En resumen: creo una consulta para sacar los datos como si fuera un SQL, creo un objeto de conexión ADODB, me sirvo del motor de Access para pasarle como fuente de datos la ruta del fichero excel, creo un recordset y guardo los datos de la consulta en el mismo. Ahora ya puedo usar a mi gusto los datos almacenados en el recordset.

Activar cuenta atrás para envío de correos en el webmail de GMX, para poder corregirlo.

Hace unos días hablábamos de cómo se puede deshacer el envío de un correo en GMAIL, que nos permite cancelarlo hasta 30 segundos depués. Tras eso me pregunté si el webmail de GMX permitiría hacer también eso y me puse a trastear. La respuesta corta podría ser «sí puedes, pero…» o «no puedes, pero…» según seas optimista o pesimista, en cualquier caso lo que quiero decir es que aunque no funciona de la misma forma que en GMAIL sí tienes la opción en GMX de hacer algo parecido: activar una cuenta atrás para el envío, que te dará la opción de poder pararlo si te arrepientes o si ves que hay que corregir algún error ortotipográfico.

Ejempó de cual es el menú "Nuevo Mensaje"
Menú izquierda, sección «Nuevo Mensaje».

Para configurar esto hay que ir al menú Configuración, al cual se puede acceder o desde el enlace que hay en la parte inferior de la columna izquierda en la bandeja de entrada o pulsando el botón Más que está en la parte superior a la derecha de la botonera, representado con un icono que son 9 puntos. Una vez entremos en Configuración por defecto deberíamos estar en la sección Nuevo Mensaje, si no fuese así busca dicha sección en el menú de la columna izquierda.

Para activar la cuenta atrás deberíamos irnos al final de esta sección, el último elemento pone «Establezca Conteo Regresivo de Envío» y por defecto estará en 0, pero nos dará la opción de elegir entre 5, 10 o 15 segundos. Elegimos el tiempo que queramos, pulsamos «Guardar» y ya podemos cancelar en envío de mensajes mientras se realiza la cuenta atrás para su envío.

Ejemplo del selector donde debemos escoger el tiempo de envío.

Ciberseguridad: ¿Qué es el QRishing y cómo nos defendemos de este fraude?

Por aquí hemos hablado del phishing a través de correos fraudulentos, del envío de facturas falsas, del smishing o del vishing, así que por seguir con los «ings» toca hablar del QRishing, palabro que no tengo ni idea de cómo se pronunciaría y que viene a ser una combinación de QR y phishing.

Los códigos QR (abreviatura del inglés Quick Response, que vendría a ser Respuesta Rápida en castellano) fueron creados por Toyota a mediados de los 90 para gestionar sus inventarios de repuestos y se popularizaron rápidamente en Japón, expandiéndose por Europa durante la primera década de los 2000 y alcanzando su mayor aceptación durante la pandemia de 2020, cuando los locales de hostelería comenzaron a usarlos para enlazar urls con sus cartas al no poder utilizar una carta en papel. Cada vez más en los últimos años se están convirtiendo en una alternativa a los tradicionales códigos de barras, pues permiten almacenar información más compleja.

Ejemplo de código QR
Código QR (Ejemplo tomado de Wikipedia)

Su popularización en los últimos tiempos, cuando se han vuelto un recurso casi omnipresente y todos los teléfonos traen ya un lector de QR incorporado, ha llevado a que también se utilicen para el cibercrimen. El QRishing consiste en engañar a la víctima para que lea un código QR creyendo que le llevará a un sitio legítimo y conducirle realmente a uno fraudulento, para allí intentar robar sus credenciales de acceso a algún servicio o incluso colarle un falso pago (fue muy sonado un caso en Texas en el que se usaron códigos QR falsos para engañar a la gente que quería pagar los tickets del parking). Os podría contar un gracioso troleo que realicé sirviéndome de estos códigos el verano pasado (una acción entre activismo, pedagogía y un poco de cabronería también), pero prometí contárselo a un amigo y si lo lee aquí luego perderá su gracia cuando lo hablemos entre birras.

¿Cómo nos protegemos?

Bueno, primero vamos con las medidas técnicas: yo diría que es importante que la aplicación que usemos no abra directamente la URL escaneada en el código sino que, en lugar de eso, nos muestre la dirección a la que va a llevarnos y nos pregunte antes si queremos ir. Un simple gesto que nos hará perder un par de segundos a cambio de ganar mucho en seguridad.

Más allá de tener una app un poco más segura el resto dependerá de nuestro proceder, como en todo lo que podamos considerar fraude o estafa: habría que comprobar que el código viene de una fuente fiable, si nos piden credenciales de acceso ver que la página sea legítima y si tiene sentido que nos lo pidan, si es para realizar un pago habrá que andarse con mi ojos y ver tanto que la plataforma sea legítima como que el receptor del pago sea el correcto y comprobar finalmente en la página de nuestro banco que la transacción haya sido correcta. Si tomamos como ejemplo la estafa de los aparcamientos en Texas, añadiría que también hay que fijarse que el código que vamos a escanear no haya sido manipulado, si hay una pegatina con un código colocada encima de otro es mejor desconfiar y alertar a la entidad o negocio que debería gestionarlo por si fuera un intento de estafa.

Ciberseguridad: consejos a la hora de usar conexiones con el protocolo RDP

El protocolo de acceso a escritorio remoto (en adelante RDP) ha formado parte de Windows desde hace años, apareciendo originalmente para Windows XP. Cuando nos conectamos por RDP tenemos un equipo que hace de servidor, al que nos conectaremos, y el resto de equipos serán clientes. Aunque es una forma muy cómoda de trabajar también hay que señalar que con el paso de los años se ha quedado bastante obsoleto en términos de seguridad: carece de encriptación y es muy sensible a los ataques por fuerza bruta. Cuando durante el confinamiento de marzo-mayo de 2020 muchas empresas se lanzaron a teletrabajar sin un plan claro, dada la urgencia, se abusó de estas conexiones y muchas sufrieron problemas de seguridad (recuerdo haber leído un artículo en Twitter allá sobre el 18 de marzo donde ya se remarcaba la cantidad de escritorios remotos vulnerables que se podían localizar en España). Los delincuentes intentar servirse de conexións RDP vulnerables para instalar ransomware, spyware o practicar el cryptojacking.

Fotografía genérica de un app de seguridad.
Photo by Pixabay on Pexels.com

¿Cómo podemos usar RDP de forma segura?

Vamos a plantear varios puntos. El primero ¿necesitamos conexión vía RDP para trabajar? En muchos casos es más seguro implementar soluciones de trabajo a través de portales en la nube, claro que también requiere de una inversión en desarrollo (que se verá compensada en el largo plazo por la mejora en productividad y en seguridad).

En caso de que realmente necesitemos esta conexión vamos con el siguiente punto ¿Está nuestro software actualizado? Este es un punto recurrente en todas las entradas sobre ciberseguridad, pero es importante recordar que un equipo desactualizado suele ser más vulnerable ante cualquier tipo de ataque. No olvides descargar siempre las actualizaciones de seguridad del sistema operativo.

Los ataques más comunes contra los escritorios remotos son ataques de fuerza bruta y en muchos casos se sirven de un diccionario de usuarios y contraseñas, por lo que es recomendable no utilizar nombres genéricos para los usuarios (tipo Admin, Administrador, Administrator, etc.) dificultando así el trabajo del atacante, además de complementarlo con una política de contraseñas robustas. A día de hoy depender solo de la contraseña puede no ser suficiente, por lo que sería recomendable utilizar alguna solución para realizar una autenticación de dos factores, ya sea a través de datos biométricos, de una clave generada al momento que se envíe al usuario o del uso de un dispositivo externo para la validación. Otra buena política es bloquear el acceso de un usuario a través de este protocolo tras un número determinado de intentos fallidos de conexión. También es importante definir bien los permisos de los usuarios para limitar qué pueden y qué no pueden hacer según el trabajo que vayan a desempeñar. Un último consejo es no dejar «usuarios zombies«, cuántos más usuarios tenga el servidor más posibilidades tendrá el atacante de intentar entrar, por lo que si un usuario deja de utilizarse lo mejor será eliminarlo del sistema.

Una de las mejores soluciones que tenemos para hacer más robusta nuestra seguridad en los accesos a un servidor por RDP es utilizar una VPN: por un lado nos dará un cifrado para nuestras comunicaciones, cosa de la que carece el protocolo RDP, y por otro podremos limitar el acceso al servidor y permitirlo solo a través de dicha VPN, lo que reduce enormemente las posibilidades de un ataque. Lo ideal es conectarse a través de una VPN, pero si por lo que sea no disponéis de una entonces al menos no utilicéis el puerto por defecto, el 3389, para la conexión. Cambiando este puerto se logra reducir un poco el número de ataques automatizados, aunque no es una solución ideal pues el atacante podría simplemente buscar los puertos a la escucha. También se puede implementar un filtrado por IP en el cortafuegos, pero es algo que solo recomendaría para empresas que cuenten con una IP fija, para el teletrabajo no acaba de ser una solución práctica pues la mayoría de conexiones domésticas utilizan direcciones IP dinámicas.

Seguridad informática ¿Qué es un wiper y cómo nos podemos proteger?

En los últimos meses otro término relativo a la ciberseguridad del que se está hablando mucho, por la situación bélica en el este de Europa, es wiper. ¿De qué hablamos? Pues de un tipo de malware diseñado para destruir la información almacenada en discos duros. Al contrario que el ransomware, que secuestra nuestros datos, el wiper lo que hace es destruirlos. Esto no es algo nuevo, allá por los 90 virus como Casino, CIH o alguna de las últimas versiones del virus de los Barrotes también estaban diseñados para destruir los datos, aunque en los últimos años este tipo de amenazas se habían vuelto menos habituales ya que es complicado para un ciberdelincuente conseguir un retorno económico si ha destruído de forma irremisible la información, siendo sustituídos por herramientas que roban datos, meten publicidad o los cifran para cobrarnos el rescate. En efecto, un wiper no es especialmente útil para extorsionar o robar, pero sí es muy útil en contextos de ciberguerra o ciberterrorismo. En los últimos meses además de grandes campañas de ransomware también se ha visto un crecimiento del uso de este tipo de herramientas, pensadas para destruir información confidencial o inutilizar sistemas informáticos enteros.

Cada wiper puede funcionar de una forma distinta, los más efectivos que se han analizado durante esta guerra, se cree que usados por los servicios de inteligencia militar rusos, principalmente sobreescriben los primeros bytes de cada fichero con una serie de datos aleatorios para dejarlos inservibles, además de rellenar también el espacio vacío y destruir las particiones y el sector de arranque del sistema, dejándolo inutilizado. La idea es destruir la información, inutilizar el sistema y dificultar además el trabajo forense.

¿Cómo nos protegemos?

Aunque en el párrafo anterior nos centremos en el uso de esta tecnología como arma en el contexto de la guerra entre Rusia y Ucrania, esto no quiere decir en absoluto que empresas o entidades públicas de otros países estén libres de recibir este tipo de ataques. Como siempre que hablamos de posibles pérdidas de datos, lo primero y más básico es tener una política de copias de seguridad que nos garantice que la pérdida si no es nula al menos que sea mínima, con copias diarias de los datos críticos y guardados en varias ubicaciones distintas. Es importante mantener los sistemas operativos actualizados, al igual que el antivirus y el cortafuegos, en caso de disponer de uno. Finalmente el comportamiento del usuario será la última clave: cuidado con lo que se descarga de correos, unidades de almacenamiento externas, sistemas de mensajería, etc. Como siempre la recomenación será tener cuidado con lo que recibimos, descargamos y ejecutamos.

Deshacer el envío de un correo en GMAIL

El popular webmail de Google desde hace tiempo nos da la opción de deshacer el envío de un correo. «Muchas garcias«, «Un sauldo«, «Nos bemos» ¿quién no ha enviado un correo electrónico con una errata? Errar es de humanos y herrar es de herreros, por suerte deshacer el envío de un correo electrónico ya no es algo divino sino una función integrada en muchos gestores de correo o plataformas de webmail. En caso de GMAIL cuando enviamos un correo en la parte inferior izquierda de la pantalla nos saldrán dos opciones: Ver Mensaje y Deshacer Envío. Si pulsamos en la segunda podremos parar el envío del correo, que se quedará en nuestra carpeta de borradores para que lo editemos o lo borremos si nos arrepentimos mucho de haberlo enviado.

Por defecto tenemos 5 segundos para realizar esta opción, pero podemos configurarlo para disponer de más tiempo. Para ello, desde la versión web de GMAIL, entramos en Configuración pulsando el icono de la rueda dentada en la parte superior derecha de la pantalla. Allí pulsamos en Ver Todos los Ajustes y bajamos un poco hasta encontrar la opción Deshacer el envío, que está situada entre Tamaño máximo de la página y Forma predeterminada de respuesta.

Por defecto estará marcado en 5 segundos, pero podéis ampliarlo a 10, 20 o 30.

Ciberseguridad: reconocer facturas on-line fraudulentas

Una de las estafas que más ha crecido en los últimos años en el mundo de internet es el envío de facturas fraudulentas mediante correo electrónico o sistemas de mensajería instantánea. Fue especialmente grave durante el confinamiento de la primavera de 2020, momento en el que en España se registraron varios intentos de fraude suplantando a Hacienda o a la Oficina de Patentes para intentar engañar a empresas y organismos públicos. Lógicamente los atacantes suelen hacer un trabajo previo de investigación antes de ataque, sirviéndose de fuentes abiertas (por ejemplo buscar licencias de obra en registros públicos municipales o autonómicos) o de subterfugios (fishing, vishing) para recabar información tanto de la víctima a la que pretenden estafar como del proveedor al que pretenden suplantar.

¿Cómo nos protegemos?

  • Lo primero es comprobar la legitimidad de la factura: el número de cuenta, el CIF, el concepto, incluso el diseño comparando con facturas anteriores, la dirección de correo desde la que se nos ha enviado la factura… Si vemos algo extraño, algo distinto, si es una factura que no esperábamos o si es algo que ya habíamos pagado antes y nos vuelven a enviar lo mejor es contactar con el emisor, no a través del propio correo desde el que hemos recibido la factura sino por el contacto que ya tuviésemos con esa entidad/proveedor de antemano (teléfono, otro mail, etc) para comprobar que no hayan sido suplantados.
  • Dos red flags: si nos apremian al pago con mucha urgencia e incluso con amenazas legales (ya comentamos en la entrada sobre el vishing que esa estrategia de asustar se usa para que la víctima se ponga nerviosa y no piense) o si el proveedor nos informa de un cambio en su cuenta bancaria, esto debería ponernos sobre aviso y en esos casos es mejor contactar y confirmar esa información por otros medios.
  • Como ya hemos comentado hablando del smishing o de los correos fraudulentos, intentar no pinchar en enlaces ni descargar ficheros que recibamos en esos correos.
  • Además de intentar no ser estafados también es importante intentar no ayudar involuntariamente a los estafadores: en ocasiones estos atacantes intentarán hacerse con una factura real para poder falsificarla con mayor detalle, por lo que desconfía cuando te pidan una factura con alguna excusa tipo «es para revisarla«.

Javascript: sobreescribir el comportamiento del botón derecho del ratón en una web.

A veces, por lo que sea, en una aplicación web necesitamos sobreescribir el comportamiento standar del click derecho del ratón, que en lugar de abrirnos el menú contextual abra algo personalizado. Veamos lo básico ¿Cómo hacemos que en lugar del comportamiento por defecto ejecute el código que queramos? Pues recogiendo el evento y escribiendo nuestro propio código:

if (document.addEventListener) {
    document.addEventListener('contextmenu', function(e) {
        alert("NANAY DE ABRIR!!!!!"); //Aquí iría el código que quieres ejecutar en lugar del comportamiento por defecto
        e.preventDefault(); //esta línea evita el comportamiento por defecto
     }, false);
 } else {
    document.attachEvent('oncontextmenu', function() {
        alert("NANAY DE ABRIR"); ///aquí una alternativa
        window.event.returnValue = false;
    });
}