Desarrollar. Teniendo en cuenta la seguridad

Muralla Es ya un tema viejo debatir si la seguridad es cosa de desarrolladores o no. Yo tengo clarísimo que los desarrolladores deben saber de estos temas, deben tener directrices claras y resolver los problemas pensando -también- en la seguridad.

En Developers vs. Security: Who is Responsible for Application Security? nos hablaban de ello y por eso lo traemos aquí.

Lo primero, parece que la gente de seguridad desconfía de los desarrolladores y de su conocimiento sobre el tema, según un estudio de GitLab.

Results from a recent GitLab survey underscore the issue: most security professionals lack faith in developers’ ability to write secure code, while most developers feel they lack proper guidance. What’s worse, many companies surveyed aren’t being serious enough about their defense.

Puede haber aproximaciones diferentes, según la empresa y sus objetivos, nos dice Vikram Kunchala, responsable de Deloitte.

“It’s a mixed bag, and a lot of that is defined by how the company perceives security, and how important security is for their products and solutions,” he says.

La prioridad de los desarrolladores siempre es entregar código que funcione tan pronto como sea posible, sobre todo teniendo en cuenta la presión que sufren por la demanda.

With higher and higher demand for more software and apps, even more so in today’s business climate, the top priority for any developer is to get the code out quickly.

Pero claro, el código de calidad debe cumplir los requisitos de la organización y del negocio.

But to developers, and in most business entities, good quality code means that it meets organizational and business goals.

Esto no impide que los desarrolladores vean la seguridad como un freno para avanzar.

Making security the best it can be, from a developer’s perspective, is like a cop with a radar gun slowing them down when they only want to go faster.

Desde el punto de vista de los expertos en seguridad, se trataría de explorar de qué forma trabajar con los desarrolladores para generar productos más seguros.

But instead of talking about the mindset, it’s more important to explore how security experts can work with developers to achieve the collective goal of secure code.

Según nuestro experto, tres cosas ayudarían:

Primero, no tiene que ser perfecto, pero sí ir en la dirección correcta.

It doesn’t have to be perfect. […] to have a framework to say something like, “If I do these ten things, I’m on the right track.”

Segundo, la seguridad debería ser fácil de aplicar para ellos.

Security for developers should be frictionless and easy to consume.

Finalmente, cambiar la perspectiva. Esto es, prestar atención a qué tipo de desarrollo estamos haciendo y aplicar las medidas que sean adecuadas al proyecto, con ayuda de los especialistas.

For a developer looking to create a product or an app, they need to engage with application security teams to answer several questions that drive various risk elements

Idealmente, que sea fácil de verificar que todo está como se debe en las fases de integración y desarrollo continuo.

Those teams must provide an easy way to consume these controls as part of the development process and CICD (continuous integration/continuous delivery) pipeline.

Y los expertos deben ayudar a que la parte defensiva sea más sencilla.

Now, security experts need to make defense easier to do.

Teniendo en cuenta que cuanto más se retrase la solución de los problemas, más complicao será resolverlos.

Perhaps the most critical advice you should impart to the development team is that the longer it takes to fix the issue, the more expensive it gets.

Parece que poco a poco va calando la cultura de que las aplicaciones deben ser seguras y proteger los datos, así que eso debería ayuda.

… 78% of U.S. respondents believe it is extremely important for a company to keep their data private, building security into your product or service is putting your customer first.

En definitiva, la seguridad debería ser una fase más del diseño/desarrollo, y nho algo que se añade después.

“With any process, security should be built in, not bolted on,” Kunchala says. “Anything that organizations can do to consider shifting left and start engaging security at the conception phase is going to be beneficial.”

Supongo que no es muy nuevo para nadie que venga por aquí de vez en cuando, pero está bien tener estos recordatorios.

Se lo que escribiste en tu última videoconferencia

Teclado flexible Cuando estamos en una videoconferencia mucha gente dedica su tiempo a realizar otras actividades, además de participar más o menos activamente en la reunión. Se hace con cierta ligereza, porque estamos bastante seguros de que nadie sabrá lo que ocurría. A veces, hay accidentes, como que tenemos el sonido abierto y se escucha el teclado, nuestros comentarios, …

En Experts Find a Way to Learn What You’re Typing During Video Calls nos cuentan cómo se puede extraer cierta información de los movimientos corporales mientras tecleamos.

A new attack framework aims to infer keystrokes typed by a target user at the opposite end of a video conference call by simply leveraging the video feed to correlate observable body movements to the text being typed.

Nada impide que esto se haga con vídeo en directo, sino que alguien podría procesar vídeos disponibles por ahí y tratar de averiguar lo que sucedía.

… who say the attack can be extended beyond live video feeds to those streamed on YouTube and Twitch as long as a webcam’s field-of-view captures the target user’s visible upper body movements.

Casi nada que hacemos está aislado completamente, así que se puede tratar de decucir palabras teniendo en cuenta lo que ha sucedido anteriormente y posteriormente.

Word prediction, where the keystroke frame segments are used to detect motion features before and after each detected keystroke, using them to infer specific words by utilizing a dictionary-based prediction algorithm

Si escribimos mirando al teclado y buscando las teclas, y además llevamos ropa sin mangas, será más fácil ver lo que estamos haciendo, nos dicen.

The findings showed that hunt-and-peck typers and those wearing sleeveless clothes were more susceptible to word inference attacks

Si tenemos información adicional sobre la actividad del usuario, todavía es más fácil tener éxito. Por ejemplo, nombres de usuarios, correos electrónicos…

The tests were repeated again with 10 more participants (3 females and 7 males), this time in an experimental home setup, successfully inferring 91.1% of the usernames, 95.6% of the email addresses, and 66.7% of the websites typed by participants, but only 18.9% of the passwords and 21.1% of the English words typed by them.

Curioso.

Los fallos de seguridad en curl por culpa del lenguaje C

Another bug's life Hace unos días hablábamos de la seguridad de Java (en ¿Java es un lenguaje seguro? . En cualquier caso, el récord como lenguaje problemático (aunque seguramente lo sea todavía más la programación en shell) lo tiene el lenguaje C.

En half of curl’s vulnerabilities are C mistakes nos hablaban justamente de eso, para el caso de curl, la conocida herramienta que nos permite una amplia gama de posibilidades de transferencia de datos mediante URLs (que es una forma complicada de decir que puede hacer muchas de las cosas que hace un navegador; y algunas más, porque al poder integrarse en scripts tiene algunas ventajas interesantes). Viene de Would Rust secure cURL? donde se muestran los errores que provienen de las dificultades de C.

Daniel Stenberg, el responsable de curl se toma el trabajo de confirmar o desmentir estas ideas y llega a la conclusión de que la entrada proporciona datos ciertos (con pequeños matices de conteo).

51 out of 98 security vulnerabilities are due to C mistakes

That’s still 52%.

Pero claro, dice, el análisis se ha hecho sobre 98 fallos de los 6682 que ha tenido curl en su historia (un 1,46%).

The curl changelog counts a total of 6,682 bug-fixes at the time of this writing. It makes the share of all vulnerabilities to be 1.46% of all known curl bugs fixed through curl’s entire life-time, starting in March 1998

Luego nos cuenta cuáles son los tipos de fallos detectados: hay lectura fuera del espacio de memoria reservada (buffer overread), y escritura, desbordamientos de memoria, (buffer overflow). También hay usos de la memoria después de liberarla (user after free) y liberaciones innecesarias (porque ya estaban hechas, double free). Finalmente, fallos relacionados con el NULL (NULL mistakes).

Sin embargo, nos dice, también es verdad que parece que las vulnerabilidades relacionadas con el lenguaje se encuentran antes que otros tipos de fallos.

C mistake vulnerabilities are found on average at 80% of the time other mistakes need to get found. Or put the other way around: mistakes that were not C mistakes took 25% longer to get reported – on average. I’m not convinced the difference is very significant.

Un poco de numerología y también un recordatorio que los fallos de seguridad no siempre tienen que ver con los fallos del lenguaje, hay más posibilidades de equivocarse y son más difíciles de encontrar.

Repaso de un viejo fallo de seguridad: contaminación de parámetros de HTTP

Lanchas La contaminación de parámetros de HTTP es un fallo que ya tiene un tiempo (descubierto en 1999). Se trata de aprovechar que algunos entornos ponen a disposición del entorno esos parámetros para atacar una aplicación.

En A Look at HTTP Parameter Pollution and How To Prevent It repsan las ideas principales y nos ofrecen consejos para evitarlos.

With HTTP Parameter Pollution (HPP) attacks, threat actors can hide scripts and processes in URLs. First discovered in 1999, this technique can also allow threat actors to pollute the parameters in the URL and the request body. This could lead to behavior changes in the app, such as cross-site scripting, privilege changes or granting unwanted access.

Nos dicen que se pueden clasificar en los del lado del cliente y los del servidor. Esto se debe a que diferentes entornos procesan los valores de formas diferentes.

HPP can be classified into two types: client side or server side. Different web servers behave in different ways when they receive multiple parameters with the same name since ways to parse parameters vary. Client-side or server-side HPP attacks are possible depending on the way requests are handled.

En el lado del cliente, afectarán a las acciones del usuario y podrían forzar la realización de acciones sin su conocimiento.

A client-side HTTP Parameter Pollution attack is related to the client or user environment, meaning the user’s actions are affected and will trigger a malicious or unintended action without their knowledge.

Por otro lado, las del lado del servidor afectarán a terceros: acceso a datos, realización de acciones…

So, the goal of the attacker in a client-side attack is to attack other users. In the server-side variant the attacker could use an at-risk web app in several ways. They could access protected data or perform actions that either are not permitted or not supposed to be run on the server side.

La protección pasa por la validación de la entrada (validación, no saneamiento) y observación clara de lo que recibimos.

There are several ways to protect against HPP. Make sure to perform an extensive and proper input validation. All user-supplied data, which is reflected in the HTML source code of the HTTP response, should be encoded according to the context in which they are reflected.

Buena lectura, para recordar un viejo problema.

¿Java es un lenguaje seguro?

The pila seguridad Cuando se habla de programación segura, suele decirse aquello de: ‘utiliza un lenguaje que sea seguro’ y, a veces, se pone como ejemplo Java (fundamentalmente por su gestión automática de la memoria, en contraposición con C; en este último la memoria se gestiona de manera manual por parte del programador).

En No, Java is not a Secure Programming Language el autor argumenta que Java no es tan seguro como suele decirse.

En particular, nos cuenta, tiene muchos problemas debidos a los valores por defecto.

Many Java security bugs are due to insecure defaults. As a consequence, developers need to have advanced development knowledge just to write simple code that cannot be easily exploited.

Y también porque la documentación no es muy buena.

Java has really poor documentation: it is not hard to make things work, but it is often very unclear how to do things the ‘right way.’

Luego detalla el tratamiento de los diferentes problemas que aparecen en el OWASP Top 10, y con cuatro de ellos en particular: las entidades XML externas (XML External Entity), las vulnerabilidades de deserialización, los problemas de ‘cross site scripting’ y la exposición de datos delicados.

Posteriormente detalla otros problemas.

Lectura interesante.

Recuperar información sobre un binario en ejecución (bash)

Conchas En What am I running inside my bash? una entrada bastante técnica (con código y todo) sobre la accidentada recuperación de una línea que el autor escribió en su línea de órdenes hace unos meses.

I desperately needed to extract the complete (and very lengthy) command line I had written 6 months ago in a bash shell - which was still running under screen. Read on to see how I eventually made it…

Se trata, ni más ni menos de recuperar una línea de código ejecutada en una instancia que sigue en ejecución:

You download the bash source code, untar, and hoping you can somehow recover the history information kept inside the running instance of bash, …

Lanzamos el gdb para que se asocie al proceso en cuestión y podemos empezar a buscar.

Spawn GDB - and activate God mode! That is, attach to the running bash, and call write_history on our own - it conveniently takes the filename to save in as an argument!

La cosa se complica un poco más porque en la máquina remota había algunas actualizaciones posteriores (el binario ya no era el mismo).

Curioso.

Desarrollo seguro: algunas piezas sobre las que construir

Teruel. Torre mudéjar. En Applying Software Security to Security Software utiliza la excusa de la seguridad del software de seguridad (mucha seguridad, pero ya hemos dicho varias veces como sorprende muchas veces que los programas informáticos de las empresas de seguridad fallan muchas veces, igual que los otros, en estos aspectos). Todo a raíz del descubrimiento de un fallo en sudo.

When it comes to software security, the devil is in the details. When it comes to security software, those details are even more important. Just recently a significant bug was found in sudo, demonstrating that even the most highly scrutinized software can still contain mistakes.

En este paso parece que es evidente que no habría que justificar mucho un mayor coste, en aras de tener una mejor seguridad.

Arguably, security software is one of the easier places to justify spending more time on software security.

Y luego pasa a enumerar una lista de recomendaciones, que empieza con las dependencias: tenemos que estar seguros de que nuestros programas no dependen de otros que tienen vulnerabilidades.

Getting Familiar With Dependencies

The first thing to do is check up on our dependencies to make sure there aren’t any issues.

Y el camino a seguir es actualizar siempre que sea posible. La razón es que si no estamos actualizados podríamos tener problemas de compatibilidad cuando aparezca alguna actualización de seguridad.

Keeping up with dependencies should be a first class concept in your SDLC. In reality, you should update your dependencies as often as possible. If you only wait for security issues to update dependencies, you could be left with expensive upgrade paths that touch code that has long since fallen out of context with your team.

Igualmente, deberíamos utilizar una versión actualizada del lenguaje.

An Updated Language Version

También deberíamos tener pruebas (tests), no se si vale la pena explicarlo mucho.

Adding Tests

Baste decir que asegurar el funcionamiento correcto de nuestro programa forma parte de la seguridad.

It turns out functioning correctly is also a part of Software Security.

Finalmente, habla de medir los resultados y procedimentar lo que hacemos.

I do think it’s worth mentioning that part of Software Security is grounding your work and making sure you’re applying methods that map to measurable outcomes.

Sin olvidar que hay que pensar bien lo que se hace, para poder refactorizar y obtener productos robustos y sólidos.

Part of applying software security is arriving at a model that allows the full expression of the domain, including invariants, and nothing more. This is much more difficult than it sounds. It takes thought, several rounds of refactoring, and good old fashioned discipline. Before we crack into our code it is important to expose a better model that we can refactor into.

Más de 20 años de la inyección SQL y todavía sigue allí

Brazo ortopédico Una de las facetas más curiosas de la seguridad informática es que se siguen cometiendo los mismos errores desde hace un montón de años. En SQL injection: The bug that seemingly can’t be squashed nos recuerdan que los fallos de inyección de SQL acaban de cumplir 22 años pero siguen siendo un problema frecuente de seguridad.

December 2020 marked SQL injection’s 22nd birthday (of sorts). Despite this vulnerability being old enough to drink, we’re still letting it get the better of us instead of squashing it for good. In August this year, Freepik Company disclosed that they had fallen victim to an SQL injection blunder that compromised the accounts of 8.3 million users.

La inyección de SQL se produce cuando alguien que utiliza un programa es capaz de hacer que se lancen sus preguntas directamente a la base de datos. De allí puede salir cualquier problema: divulgación de información, modificación o incluso eliminación. El problema tiene que ver casi siempre con desarrolladores que no han tomado las precauciones necesarias para que esto no pueda suceder (esencialmente validar que los datos proporcionados por el usuario corresponden a lo que deben y que no incluyen ‘sorpresas’).

Es un problema especialmente grave porque no tiene que ver con los usuarios: son los desarrolladores los que pueden evitarlo con unas prevenciones mínimas y, aún así, no se remedia.

We keep saying that SQL injection is simple to fix and that code should be written so as to not introduce it at all. Like most things, it’s only easy when you’ve been taught how to do it right.

Aunque siempre pensamos que los ataques son muy sofisticados, lo cierto es que no parece que esto sea siempre así.

En la nota dicen, y debe de ser verdad, que muchas personas que estudian informática nunca han llegado a recibir formación sobre estos temas:

This shouldn’t come as a surprise: most engineers complete their degree without having learned much about secure coding (if anything at all). Most on-the-job training is inadequate, especially in an environment where security is not seen as a business priority in their role.

Algunos lenguajes nuevos, más robustos, ayudan con algunos fallos que sigue habiendo. Pero sigue habiendo sistemas legados, código viejo y bibliotecas que no manejan bien estas cosas (y también, esto lo digo yo, desarrolladores que siguen haciendo las cosas ‘a mano’ sin tener en cuenta las amenazas que existen).

Newer, more security-robust languages like Rust are helping to eradicate some of the bugs we’ve dealt with for a long time by utilizing safer functions, but there is an enormous number of legacy software, older systems, and libraries that will continue to stay in use and be potentially vulnerable.

Como siempre decimos, los desarrolladores deben embarcarse en este viaje desde el principio y recibir el apoyo adecuado para desarrollar mejor.

Developers must be brought on the journey from the beginning, and supported to take responsibility for their part in creating safer, better code.

Más ataques a la privacidad: los 'faviconos'

Juan oculto Internet no se diseñó pensando en la privacidad. Esto hace que casi cualquier iniciativa en la red pueda ser usada para ‘conocernos mejor’. En este caso, unos investigadores de la Universidad de Illinois (Chicago) nos hablaban de los ‘faviconos’: Favicons may be used to track users. Los ‘faviconos’ son esos dibujitos asociados a los sitios web que aparecen en la barra del navegador y también en los favoritos, en la barra del navegador…. Como siempre, y por motivos de eficiencia, se almacenan. El problema parece ser que no se almacenan con el resto de objetos temporales del navegador (caches).

Favicons are used by site to display a small site icon, e.g. in the address bar of browsers that support it but also elsewhere, e.g. in the bookmarks or tabs. Favicons are cached by the browser, but are stored independently from other cached items such as HTML files or site images.

Los investigadores prepararon un sistemas para generar el almacenamiento de diferentes ‘faviconos’ según la navegación del usuario y, por lo tanto, mejorar las poosibilidades de identificar a un usuarios conforme se tienen más datos almacenados en su navegador.

A single favicon is not enough to identify users based on it, but the researchers discovered a way to plant multiple favicons in the favicon cache. The site does a series of redirects through several subdomains to save multiple different favicons in the cache. Each saved favicon creates its own entry in the cache, and all of them together can be used to identify users provided that enough favicons are saved using the methodology.

Curioso.

Optimización con llamadas recursivas al final

Letras Algunas funciones recursivas se pueden convertir fácilmente en bucles (composiciones iterativas). En general se trata de una buena medida, porque evita las llamadas recursivas a la función y eso, por si solo, ya asegura una mayor velocidad de ejecución (todos sabemos que la llamada a la función provoca una serie de movmientos de información en la pila que tienen un coste, por pequeño que sea).

De eso hablan en How Tail Call Optimization Works. Nos explican cómo funcionan las llamadas a funciones, en particular la necesidad de copiar el contador de programa (program counter) en la pila, hacer un salto y luego otro…

The PC is pushed onto the stack so the called function can return back to the right spot. To return from a function, a function executes ret which pops the top value on the stack and then jumps back to that location.

Nos muestra el código en ensamblador y lo hace con bastante detalle. También cómo los compiladores son capaces de detectar los casos de este tipo de recursión ‘al final’ (tail call optimization) sustituyendo la llamada a la función por un salto (esto es evitando la copia de datos y todo eso).

This is tail call optimization. Tail call optimization happens when the compiler transforms a call immediately followed by a ret into a single jmp. This transformation saves one instruction, and more importantly it eliminates the implicit push/pop from the stack done by call and ret.

Una buena descripción del problema y la solución.