Ataques a los datos de entrenamiento de inteligencias artificiales

Calentando Solemos decir que tomamos decisiones basadas en los datos. El problema que surje con esto es cuando nuestros datos no reflejan adecuadamente la realidad. En el mundo de la inteligencia artificial esto podría ser un problema, tal y como nos cuentan en Data poisoning in action.

Si podemos introducir errores en los modelos que se utilizan para entrenar las inteligencias artificiales, podremos causar problemas:

Data poisoning attacks compromise the integrity of machine learning models by injecting incorrect data in their training set.

Se trata de modificar un conjunto de datos de los que se emplean en el entrenamiento, para lograr que el resultado sean predicciones incorrectas.

A data poisoning attack aims to modify a training set such that the model trained using this dataset will make incorrect prediction

El objetivo es degradar el modelo obtenido (en el entrenamiento o cuando se le alimentan nuevos datos para volver a entrenarlo). Estos ataques podrían tener un efecto duradero, porque comprometen la integridad del modelo y le hacen cometer errores de manera consistente. Una vez comprometido, recuperar el sistema es un problema de solución no trivial.

Poisoning attacks have a long-lasting effect because they compromise the integrity of the model and cause it to make consistent errors at runtime when making predictions. Once a model has been poisoned, recovering from the attack at a later date is a non-trivial procedure.

Como ejemplo, nos habla de lo que sucedería si en un modelo orientado a detectar pedidos fraudulentos (y que, lógicamente, se entrenará con pedidos reales anteriores). Podría contaminarlo realizando una serie de pedidos y luego pagando algunos y otros no, con lo que podría conseguir degradar la capacidad de predicción.

The model should be able to predict whether a placed order will be paid for ( legitimate ) or not ( fraudulent ) based on information about the given order. The training set for this model consists of details contained in historical orders placed on the website. In order to poison this training set, an attacker would pose as a user or users of the site and place orders. The attacker pays for some orders and doesn’t pay for others such that the predictive accuracy of the model is degraded when it is next trained.

Hay dos formas de contaminar estos datos:

  • Inyección de datos, tal y como decíamos arriba.

Data injection: by injecting new data in the training set, as illustrated above with the attacker creating new orders. This new data can be synthetic in nature.

  • Cambio de etiquetas. Esto es, se trata de cambiar los valores que asigna el modelo a algunos datos.

Label flipping: by changing labels of existing real data in the training set.

Si conocemos el modelo utilizado y los datos que se utilizan para entrenarlo, se podría ir más allá, sintentizando (generando) datos que podrían optimizar el proceso de contaminación.

Given some knowledge about the model and its training data, an attacker can generate synthetic training data points that will optimally degrade the accuracy of the model.

Como defensa, se pueden utilizar modelos lo más complejos posibles, que serán más resistentes y robustos frente a los ataques.

In general, this means that complex models (models having a high capacity) are more resilient than simple models to DoS poisoning attacks, they require more poisoning data points to be compromised, and it is difficult to decrease their accuracy as a whole.

Muy interesante. Cada vez que hagamos un sistema automático, alguien intentará hacer que se comporte de manera diferente a la prevista.

Sobre la verificación en tiempo de ejecución del kernel de Linux

Vigilantes En [RFC PATCH 00/16] The Runtime Verification (RV) interface un texto sobre la interfaz de verificación en tiempo de ejecución del Kernel de Linux.

Se trata de un método ligero que complementa las técnicas tradicionales de verificación exhaustiva mediante el análisis de la traza de la ejecución del sistema.

Runtime Verification (RV) is a lightweight (yet rigorous) method that complements classical exhaustive verification techniques (such as model checking and theorem proving) with a more practical approach for complex systems.

Instead of relying on a fine-grained model of a system (e.g., a re-implementation a instruction level), RV works by analyzing the trace of the system’s actual execution, comparing it against a formal specification of the system behavior.

Existe un documento de referencia, que es:

DE OLIVEIRA, Daniel Bristot; CUCINOTTA, Tommaso; DE OLIVEIRA, Rômulo Silva. Efficient formal verification for the Linux kernel. In: International Conference on Software Engineering and Formal Methods. Springer, Cham, 2019. p. 315-332.

En el RFC se presenta un sistema basado en monitores que ayudan a observar el uso y cómo se genera código automáticamente. Esto ha venido motivado por el uso de Linux en sistemas críticos.

In this RFC I am still not proposing any complex model. Instead, I am presenting only simple monitors that help to illustrate the usage of the automatic code generation and the RV interface. This is important to enable other researchers and developers to start using/extending this method.

It is also worth mentioning that this work has been heavily motivated by the usage of Linux on safety critical systems, mainly by the people involved in the Elisa Project.

Algunos (pocos) datos sobre generadores de números aleatorios

La suerte (?) De vez en cuando volvemos a hablar de los generadores de números aleatorios. Aunque sólo sea porque alguien la próxima vez lo haga un poco mejor. Siempre decimos que los sistemas informáticos son muy malos generando aleatoriedad y que utilizan algunos trucos para ello. En este caso John D. Cook entra en detalle en diversas implementaciones y propuestas en Evolution of random number generators.

Habla de los generadores basados en congruencias

x(n+1) = a.x(n) mod m

Y luego hace algunos análisis estadísticos con algunos valores para los parámetros del generador (los valores de a, n y m). No se asusten, es cortito y muy visual.

El FBI limpiando sistemas infectados, al menos parcialmente.

Semana Santa. Moto de la policía. Imaginemos que pasas por delante de una puerta que está abierta y dentro ves la puerta de una habitación y dentro un montón de billetes. Sabemos que no lo robarrías pero…. ¿Volverías la puerta de la habitación o la cerrarías para que alguien que pase no tenga malas tentaciones? Tiene su peligro, porque si alguie te ve entrar y luego faltara dinero, podrían pensar que has sido tú. Podrías llamar a la policía y que se ocupen ellos, que seguramente nadie les acusaría con la misma facilidad de robar. Algo así ha estado pasando con el FBI (aunque sin que nadie les avise). En FBI cleans web shells from hacked Exchange servers in rare active defense move nos cuentan como el FBI obtuvo permiso del juez para eliminar puertas traseras de sistemas infectados.

Es un movimiento interesante porque esto supone que detectan un sistema infectado, son capaces de entrar en el mismo (la puerta no está exactamente abierta, hace falta ciertas herramientas y conocimiento para poder acceder), eliminan el problema y se van.

In a move that has been described as unprecedented, the FBI obtained a court order that allowed it to remove a backdoor program from hundreds of private Microsoft Exchange servers that were hacked through zero-day vulnerabilities earlier this year.

La cosa tiene su miga, porque muchas veces esos servidores están medio abandonados o mal gestionados y pueden ser utilizados para atacar y provocar problemas en otros sistemas. En este caso, una web shell es un programa que instalan los malos para poder acceder al sistema y ‘gestionarlo’ desde su navegador.

A web shell is a type of program that hackers install on hacked web servers to grant them backdoor access and remote command execution capabilities on those servers through a web-based interface.

En la solicitud del FBI explicaban que, a pesar de haber avisado tanto el fabricante, como otras organizaciones y ellos mismos, muchos servidores seguían infectados. Existiendo una solución para remediarlo.

In its warrant application, dated April 13, the FBI argues that despite the public awareness campaigns by Microsoft, CISA and the FBI itself, many servers remained infected with the web shell …

No sólo recibieron permiso para entrar en los sistemas con las credenciales que consiguieron para ello, sino que también recibieron autorización para conservar estos programas maliciosos, como evidencias para posibles acciones posteriores.

The FBI was also allowed to make a copy of the web shells first because they could constitute evidence.

Sin embargo, no recibieron autorización para parchear (esto es, aplicar las soluciones necesarias para proteger los sistemas de ataques posteriores) o para eliminar otros programas maliciosos que pudieran encontrar.

This means the FBI was not granted permission to patch the vulnerabilities to protect the servers from future exploitation or to remove any additional malware or tools that hackers might have already deployed.

Tiene sentido porque modificar el sistema puede tener consecuencias que serían difíciles de evaluar para un visitante casual, que no conoce toda la configuración y las actividades del sitio en cuestión.

Según la nota, no sería la primera vez que habían obtenido permiso (ellos u otras fuerzas del orden) para enviar instrucciones a programas maliciosos en sistemas infectados.

This is not the first time when the FBI or law enforcement authorities from other countries have sent commands to malware running on infected computers.

Nos cuenta el caso de la Gendarmería francesa, que habría sido autorizada para inhabilitar un servidor de ‘comando y control’ que se utilizaba para desplegar un programa malicioso de minado de criptomonedas, reemplazándolo con un servidor de desinfección.

In 2019, the French National Gendarmerie, working with antivirus vendor Avast, disabled the command-and-control server used by the Retadup worm that deployed cryptocurrency mining malware and replaced it with a “disinfection server.”

Pero se trataba más bien, nos dicen, de aproximaciones pasivas. Desactivaban el sistema de control de una red de programas amliciosos que contactaban con este sistema para recibir instrucciones.

Placing a specific command on a seized server knowing that malware programs are programmed to contact that server and execute that command is a somewhat passive approach.

Elogian también la transparencia del FBI y el Departamento de Justicia, así como la limitación en el ámbito de actividades desarrolladas.

It seems that the FBI and the DOJ tried to be transparent and were careful to limit the scope of their actions in this case.

Muy interesante.

Desbordamientos de enteros en aplicaciones del mundo real

El sorteo del Stock Travel Day. Números mágicos Parece que no aprendemos nada: la gestión de memoria es uno de los problemas bien conocidos en los programas desarrollados en el lenguaje C. Seguimos encontrándolo casi donde miremos: en muchos casos porque hacemos desrrollos rápidos para avanzar, y en otros porque ni siquiera miramos.

En BadAlloc: Microsoft looked at memory allocation code in tons of devices and found this one common security flaw lo cuentan desde una perspectiva informativa, y en “BadAlloc” – Memory allocation vulnerabilities could affect wide range of IoT and OT devices in industrial, medical, and enterprise networks desde una perspectiva más ténica. Nos hablan del tema, relacionado con un montón de dispositivos de IoT, industriales, médicos… donde además el problema se agrava porque la cultura de actualización está mucho menos extendida.

Cuando se habla de gestión de memoria, lo primero que nos viene a la cabeza es un desbordamiento de la zona reservada, pero hay más casos. Por ejemplo, desbordamientos de enteros. En este caso fuerzan la reserva de cantidades de memoria muy grandes. Esto es, en este caso no nos pasamos del tamaño reservado, pero reservar un espacio demasiado grande es también un problema. A veces.

The team found a programming blunder common among much of the software: integer overflows during heap memory allocation. This occurs when an attacker is able to, usually via malicious data inputs, trick application code into making a very large memory allocation for a buffer to hold further incoming information.

Tiene que ver con que se trata de dispositivos de 32 bits y la aritmética relacionada con ello.

The trouble is that a vulnerable memory allocator could take that large size – eg, 0xffffffff on a 32-bit embedded system – and add something like 8 to it because the requested memory block needs eight bytes of metadata to describe it. The size then overflows to 7 and the allocator finds space in memory that’s seven bytes in size for the requested buffer.

Esto supone que, en las condiciones adecuadas, estaríamos asignando memoria más allá de lo que es posible y permitiendo sobreescribir valores importantes.

This causes the application to overwrite the memory allocation metadata, structures, and contents. Now the attacker who sent over the data can take full control of the system by overwriting function pointers or altering other values.

Del desbordamiento de enteros se habla todavía menos que del desbordamiento de memoria y este será, a partir de ahora, uno de mis ejemplos favoritos sobre el tema.

No guardar secretos en repositorios de código

Centro de Exposiciones del Centro de Conocimiento sobre servicios públicos electrónicos. Almacenamiento. Esto es de primero de seguridad y desarrollo, pero parece que hace falta recordarlo (bueno, vale, ¿quién no ha hecho por error un commit con datos delicados?). En Why We Shouldn’t Commit Secrets into Source Code Repositories hablan del tema.

Nos dice que enviar secretos a un repositorio es uno de los fallos más frecuentes:

Committing secrets into source code repositories is one of the most frequent problems I see in application security code review, and has been so for at least 5 years. I’m speaking as one who has reviewed numerous code repositories for a variety of different companies. It is a problem that never seems to go away.

Luego da algunos ejemplos de empresas que se han visto afectadas por este tipo de problemas, como Uber (credenciales de AWS S3), Stackoverflow (que consiguieron acceso al código y, a partir de allí, a más cosas por la información obtenida).O el caso de AShley Madison (un sitio de citas, que también teńia contrasweñas en el código). Y algunos ejemplos más.

Pero casi todo el tiempo hemos estado hablando de secretos (y no de contraseñas) porque, nos dicen, las claves SSH, las conexiones a bases de datos y otras informaciones también deberían ser secretas. Y en caso de duda, casi cualquier información. Cuidado.

Educate engineers that “secrets aren’t just passwords.” Protect SSH keys and database connection strings too. When in doubt, protect it. If you must store secrets in a Git repo, protect them with git-crypt or Blackbox.”

Las contraseñas. Más complicado de lo que solemos pensar.

Detalle parte superior puerta de la Lonja Me encanta el tema de las contraseñas. Es un modelo sencillo, pero muy difícil de hacerlo todo bien. En mis clases dedico un buen rato al tema y cuando me invitan a dar una charla también me gusta prestarle atención.

En Evolving beyond password complexity as an identity strategy una entrevista a Troy Hunt, que mantiene el sitio HaveIBeePwned, entre otras cosas. Este sitio se dedica a recopilar información sobre diversos conjuntos de datos obtenidos en ataques informáticos que terminan siendo publicados de una forma u otra. Esto le da mucha perspectiva acerca de las contraseñas que utiliza la gente y cómo la protegen los sitios.

Empieza hablando de una tendencia que se está observando en los últimos meses, relacionada con ataques de robo de información mediante la obtención de una copia de la SIM del propietario por diversos métodos. Cuando se utiliza como un segundo factor de autentificación (2FA) tendremos unproblema si alguien puede conseguir una copia de la nuestra con cierta facilidad. Tiene que ver con lo desagradable que es quedarse sin ella y no poder comunicarte, pero hay que balancear la facilidad de resolver los problemas con lo que puede pasar si eso ayuda a los malos.

… SIM card hijacking. It concerns me greatly that it seems to be so prevalent and that it’s so easy, almost by design, to port a SIM from one location to another. As an industry, we need to say, “Where is the level of identity assurance for a phone number?”

Y, claro, esto tiene que ver con la industria y cómo los profesionales manejan las necesidades de sus usuarios. A veces se toman decisiones sin tener en cuenta a las personas afectadas.

I would really like IT professionals to better understand the way humans interact with systems. Everyone says, “Just force people to use two-factor authentication.” Do you still want customers? I think every IT professional should have to go through two-factor authentication enrollment with my parents. Everyone should have to learn what it’s like to take non-technical people and try and get some of these things working for them. We can’t just look at these things in a vacuum.

Y las contraseñas tradicionales son un método de interacción bien conocido.

The thing that passwords do better than just about everything else is that everyone knows how to use them.

Un consejo que solemos dar es utilizar un gestor de contraseñas, que nos permiten almacenarlas adecuadamente protegidas. Pero, dice Hunt, no sólo las contraseñas, podemos utilizarlos para otro tipo de información, como puede ser nuestra tareta de crédito u otros datos secretos que podamos necesitar.

Password managers are a way of storing one-time passcodes (OTPs), but it’s important to recognize that password managers are not just for passwords. I have my credit card details in there, and every time I go to pay at a store, I do the control backslash and automatically fill in the credit card details.

Otros casos pueden ser las cuentas compartidas (aunque yo aquí diría que los proveedores de servicios deberían hacerlo mejor y permitirnos tener cuentas individuales en servicios compartidos; pero no estamos allí, en la mayoría de los casos, aún).

Another use case is a family account. If my partner wants to log into our Netflix account, she has her own identity, but there’s one set of credentials. […] But if you have a password manager where you have shared vaults, you can just drop it in the shared vault.

Se dice de vez en cuando que las contraseñas llegan a su fin (de hecho, algunosservicios ya usan sistemas alternativos como el envío de un código cuando intentamos entrar). Pero es un sistema que ya tiene más de 60 años.

Ultimately, this password is the key to your identity. We’ve had passwords on computer systems for about 60 years and the era in which they were born was so simple.

Luego habla de las normas de complejidad: en muchos sitios nos obligan a cumplir determinadas normas consiguiendo, paradójicamente, contraseñas peores. Si nos dicen que tenemos que poner alguna letra mayúscula, ponemos la primera en mayúscula; si nos piden que tenga un número o un símbolo, lo añaddimos al final:

“[…] and a website says you have to have at least one uppercase character. What do you do? You capitalize the first letter.” […] “You have to have a number. What do you do? You put a one at the end.” And there’s the same nervous laughter.

Las contraseñas representan algo fácil de comprender pero que tiene más dificultades a la hora de hacer las cosas bien de las que solemos tener en cuenta.

GitHub y sus cambios en los nuevos formatos de los tokens de autentificación

Más bolas A veces, cuando diseñamos un sistema, no somos conscientes de todas las consecuencias de nuestras decisiones. Tarde o temprano nos tocará cambiar algunas partes para remediar estos problemas. En GitHub se han encontrado con este problema a la hora de identificar los tokens de autentificación y descubrir que no podían diferenciar unos tipos de otros. En Behind GitHub’s new authentication token formats nos lo cuentan.

El formato de algunos tokens antiguos están codificados en formato hexadecimal de 40 caracteres y esto los hace indistinguibles de otros que están codificados de la misma forma, pero que son de otros tipos. Y esto es un problema.

Many of our old authentication token formats are hex-encoded 40 character strings that are indistinguishable from other encoded data like SHA hashes.

Consideran, igual que otros, que la mejor forma de diferenciar estos elementos es mediante un prefijo, y por eso los están sustituyendo.

As we see across the industry from companies like Slack and Stripe, token prefixes are a clear way to make tokens identifiable. We are including specific 3 letter prefixes to represent each token, starting with a company signifier, gh, and the first letter of the token type.

Pero aún querían ir más allá, añadiendo sumas de comprobación (checksums).

Identifiable prefixes are great, but let’s go one step further. A checksum virtually eliminates false positives for secret scanning offline. We can check the token input matches the checksum and eliminate fake tokens without having to hit our database.

Y para hacerlo, han seleccionado el algoritmo C·C32

We start the implementation with a CRC32 algorithm, a standard checksum algorithm. We then encode the result with a Base62 implementation, using leading zeros for padding as needed.

Una guía sobre OAuth

Ipomonea OAuth es un conjunto de especificaciones para delegar la autentificación y autorización en un tercero. Tiene algunas ventajas notables, como la de permitir que alguien pueda actuar en nuestro nombre sin cederle nuestras credenciales. O que ese ‘alguien’ sea ‘algo’ que utilizamos y donde no queremos (o alguien no quiere) que se almacenen las credenciales, sino un sistema alternativo que permite realizar determinadas operaciones.

En The Modern Guide to OAuth una buena guía que nos puede ayudar a comprender mejor la cosa, sus posiblidades y qué podemos hacer con ello.

Es bastante larga, así que no vamos a extaer apartados ni contenido y simpelmente haremos una invitación a la lectura.

¿Corre riesgo Python de quedar como un lenguaje marginal?

Libro. Practical Programming. An introduction to CS using Python Python es uno de mis lenguajes favoritos, y lo uso con frecuencia para algunas tareas. Sin embargo, hay en otras en las que no es lo más adecuado y de este tema hablan en el artículo que traemos hoy.

En Programming language Python is a big hit for machine learning. But now it needs to change hay algunas ideas interesantes sobre lo que Python debería ser en el futuro.

Desde luego, está claro que es un gran éxito en los temas relacionados con la inteligencia artificial y aprendizaje autómatico y se ha convertido en un lenguaje muy popular.

Sin embargo, nos dicen, no se puede ejecutar en el navegador, y tampoco en el teléfono móvil. Y tampoco hacen juegos con él.

Python is the top language according to IEEE Spectrum’s electrical engineering audience, yet you can’t run Python in a browser and you can’t easily run it on a smartphone. Plus no one builds games in Python these days.

Otra limitación, es la de la dificultad para construir y distribuir aplicaciones de escritorio, sobre todo si tienen interfaces gráficas.

“It’s an embarrassing admission, but it’s incredibly awkward to use Python to build and distribute any applications that have actual graphical user interfaces,” he tells ZDNet.

Mucho del problema tiene que ver con la dificultad de cambiar el lenguaje sin causar problemas en algunos de los módulos más populares como numPy. Y por lo tanto, enfadar a mucha gente.

Ronacher says Python has been “stuck like this for many years”. Time and again, efforts to “kill the global interpreter lock” fail because it would cause troubles for extensions like NumPy.

Interesante.