Hace no mucho cayó en mis manos el artículo: I Don’t Need an Expert! Making URL Phishing Features Human Comprehensible donde se pueden leer algunas ideas sobre el phishing y las URLs y lo difícil que puede llegar a ser darse cuenta de que estamos siendo engañados.

Judging the safety of a URL is something that even security experts struggle to do accurately without additional information. \changed{In this work, we aim to make experts’ tools accessible to non-experts and assist general users in judging the safety of URLs by providing them with a usable report based on the information professionals use.} We designed the report by iterating with 8 focus groups made up of end users, HCI experts, and security experts to ensure that the report was usable as well as accurately interpreted the information. We also conducted an online evaluation with 153 participants to compare different report-length options. We find that the longer comprehensive report allows users to accurately judge URL safety (93% accurate) and that summaries still provide benefit (83% accurate) compared to domain highlighting (65\% accurate).

Creo que merece la pena su lectura (se puede descargar de [PDF] I Don’t Need an Expert! Making URL Phishing Features Human Comprehensible) para repasar conceptos básicos sobre las URLs, pero también para ver cómo los expertos se enfrentan al problema y echarle un vistazo a los datos que aparecen. En particular, yo tuve la oportunidad de hacer la prueba que indica en la Tabla 3 con un grupo y fue bastante ilustrativo (incluso para mi mismo, que no era perfectamente capaz de identificar todos los casos). Arriba también se puede ver el vídeo de la presentación en el congreso del ACM Special Interest Group on Computer-Human Interaction (SIGCHI). Arriba hay un vídeo de la presentación del artículo.

Hace años comentaba informes que iba leyendo de vez en cuando, pero ahora lo había dejado un poco abandonado. No es que pretendar comentarlos ahora, pero estuve echando un vistazo a un par de ellos y creo que vale la pena echarles un ojo y,por lo tanto, enlazarlos.

• [PDF] CCN-CERT IA-35/23 Ciberamenazas y Tendencias. Edición 2023

Me parece interesante porque nos habla del contexto local.

• CrowdStrike 2023 Cloud Risk Report.

Para mi tiene el interés de hablar de la nube, es más cortito que el otro.

Se habla poco de los problemas que puede traernos la codificación de un mensaje, texto lo que sea… Algunos sistemas intentarán interpretarla como si estuviera escrita en la codificación que esperan, otros la mostrarán sin más, en algún caso puede haber algún tipo de interpretación.

De esto nos habla Brian Krebs en Teach a Man to Phish and He’s Set for Life y un caso de este estilo en el nombre de un fichero: el recpetor trataba de cambiar el nombre, pero se encontraba con que las flechas de movimiento dentro del texto se movía en sentido contrario al que debían:

For example, when he downloaded and tried to rename the file, the right arrow key on the keyboard moved his cursor to the left, and vice versa.

La cosa tiene hasta un nombre y es lo que se llama anulación de derecha a izquierda (right-to-left override) y tiene todo el sentido para idiomas como árabe, hebreo … Se lleva a cabo mediante un caracter especial, que se abrevia como RLO.

The file included in this phishing scam uses what’s known as a “right-to-left override” or RLO character. RLO is a special character within unicode — an encoding system that allows computers to exchange information regardless of the language used — that supports languages written from right to left, such as Arabic and Hebrew.

Esto puede dar lugar a situaciones donde vemos un fichero que se llama “lme.pdf” (un PDF, potencialmente poco peligroso) pero que en realida es “fdp.eml” (un mensaje de correo, más peligroso).

Look carefully at the screenshot below and you’ll notice that while Microsoft Windows says the file attached to the phishing message is named “lme.pdf,” the full filename is “fdp.eml” spelled backwards. In essence, this is a .eml file — an electronic mail format or email saved in plain text — masquerading as a .PDF file.

Cuando abrimos el mensaje como si fuera un PDF, se abre como un mensaje de correo, muestra una página en HTML y nos redirige, a través de algún sistema de redirecciones que oculta el destino final, a algún sitio donde no querríamos ir.

Opening the .eml file generates a rendering of a webpage that mimics an alert from Microsoft about wayward messages awaiting restoration to your inbox. Clicking on the “Restore Messages” link there bounces you through an open redirect on LinkedIn before forwarding to the phishing webpage.

El resto, ya lo podemos imaginar, puede ser cualquier petición de datos ilegítimos que nos produzcan algún problema más adelante.

No me llevo bien del todo con la electrónica y el hardware. Eso no me impide comprender lo importante que es y admirar entradas como Understanding Battery Performance of IoT Devices donde un experto nos desgrana los detalles importantes de la baterías.

Casi al principio ya dice que el tema de las baterías es complicado:

But batteries are hard

Después habla de la temperatura, el uso, y muchas otras consideraciones.

Para guardar.

Cuando introduces un nuevo sistema añades toda una panorámica de posibilidades donde un atacante puede intentar hacer algo. Cuantas más son las posibilidades, mayor es lo que llamamos la superficie de ataque.

En The AI Attack Surface Map v1.0 Daniel Miessler nos da pistas sobre todos los sitios donde un atacante podría intentar obtener alguna ventaja cuando hablamos de la inteligencia artificial.

This resource is a first thrust at a framework for thinking about how to attack AI systems.

Habla de los componentes (modelos, preguntas, índices, memoria, cadenas, agentes, …) y luego habla de algunos ejemplos de ataques posibles (inyección de preguntas, prompts, ataques al entrenamiento, …).

Interesante.