pruebas-de-seguridad

App terminada: ¿la subo a producción o hago pruebas de seguridad?

/en , , /por

Hace dos días me tocó ir a la ventanilla de Alsa para cerrar un billete de vuelta. Sí, a la ventanilla. Mis argumentos sobre que puedo comprar hamburguesas del mercado con Amazon Prime, la comida del mes en Carrefour, pantalones vaqueros con Vibbo, pedir «taxi» con Uber o «conocer amigas» con Tinder… todo desde mi móvil, no fueron suficientes para convencer a la simpática persona que me atendía de que no tenía sentido que no pudiera hacerlo por internet a estas alturas de siglo.

Hoy en día todas las empresas que quieren estar «a mano» de sus usuarios invierten en apps móviles o web (responsive). Es imprescindible que sean sencillas,  rápidas y con un diseño fabuloso.

Seguro que alguno ya lo ve venir… ¿reconocéis lo que falta?

Seguridad. Cerca del 70% de las vulnerabilidades se encuentran en la capa de aplicación y apenas el 10% de los desarrolladores reconocen haber realizado pruebas de seguridad antes, durante y tras el lanzamiento de las apps [1].

Tampoco es para tanto…?

Quizás parezca que no, pero un error en una aplicación puede derivar en graves violaciones de seguridad. Lo que para un desarrollador puede ser un pequeño fallo, puede ser la entrada a la red interna de la organización y convertirse en el principio de una serie de escalados en horizontal y vertical que terminen con un magnífico acceso de administrador.

Una aplicación que no ha pasado las necesarias pruebas de seguridad puede terminar costando millones al negocio. Todavía me acuerdo de aquella charla de Antonio Ramos (www.leetsecurity.com) en la RootedCON titulada ¿Y si la seguridad afectara al valor contable de la empresa?. Que le pregunten a Yahoo si afecta a las cuentas o no un fallo de seguridad…

Si no te preocupas por la seguridad, quizás deberías preocuparte por la tesorería… ¿Qué tal unas recomendaciones mínimas?

Versiones cerradas, no metas parches de última hora

A veces, con las prisas, metemos características que no están del todo maduras. Tienen que estar aunque no estén demasiado finas, que «ya lo iremos arreglando». La realidad es que se suele dejar como está, ya que tras la release, una lista de nuevas features está en tu nuevo sprint y no tienes tiempo para arreglar cosas.

Si algo no está pulido, probado y validado, no debería ponerse en producción, a la larga lo agradecerás.

Pruebas de todo tipo (sí, de seguridad también)

Una batería de pruebas es esencial en el desarrollo, pero no hablo de las pruebas funcionales mínimas que realiza el desarrollador conforme escribe código. Haz todo tipo de pruebas, automatiza, audita tu código, incluso busca expertos en QA testing que te enseñen cómo hacerlo.

Nunca dejes de revisar

Las pruebas no deben terminar una vez se publica una versión. Si tienes algo en producción durante mucho tiempo, ponlo a prueba, «putéalo» para que seas tú el primero en encontrar una vulnerabilidad y no el primero en sufrirla.

 

No es tan complicado, no te olvides las pruebas y tus usuarios, tu negocio y tu tesorería te lo agradecerán.

[1] https://www.sans.org/reading-room/whitepapers/analyst/2015-state-application-security-closing-gap-35942

primer_ataque_dos

¿El primer ataque DoS de la historia?

/en , , , /por

Estamos en 2017, lo que implica que el ataque DoS (Denegación de Servicio – Denial of Service) cumple 43 años. Lo que nació como la obra de un geek (o friki como decimos por aquí) se ha ido convirtiendo en algo muy elaborado que afecta a multitud de sistemas. Además, gracias a Internet, su variante DDoS (Distributed DoS) es sin duda uno de los quebraderos de cabeza de los que trabajamos en esto.

Un poco de historia

Cuenta la leyenda que el primer ataque DoS ocurrió en 1974 gracias a la curiosidad de David Dennis, un estudiante de 13 años de la Universidad de Illinois. David se percató de la existencia de un comando en los terminales PLATO (uno de los primeros sistemas computerizdos de aprendizaje compartido, antecesor de los sistemas multiusuario) llamado «ext».

Este comando permitía conectar dispositivos externos y suponía que cuando se lanzaba, el dispositivo estaría presente, avisando de que únicamente era útil usarlo en ese caso.

Sin embargo, no avisaba de lo que ocurriría si no había dispositivos conectados. Cuando el comando se ejecutaba en un terminal así, se bloqueaba requiriendo un reinicio para volver a funcionar.

En este escenario, David tuvo la curiosidad de comprobar si era capaz de bloquear a todos los usuarios a la vez, de forma que el laboratorio quedase colapsado. Con esto en mente, desarrolló un programa que enviaba el comando «ext» a todos los terminales PLATO al mismo tiempo.

Como podéis imaginar, la ejecución fue un éxito rotundo, ya que bloqueó los terminales de más de 30 usuarios ante el asombro general. Este movimiento terminó con el bloqueo de la ejecución del comando «ext» de forma remota.

Os dejo la historia contada por David Dennis:

As far as I know, I’m the first person to have created a DoS of a room full of PLATO terminals deliberately. Systems people could of course kick anyone out they wanted, and «operator wars» had existed for years, but those tended to be consensual attacks on each other. What I did was I heard about a new command called the «external» command in TUTOR, or ‘ext’. Specifically, one of the music kids was saying how if you didn’t have a device attached, an ext command would cause your terminal to lock up and have to be powered off. Remember that powering off was discouraged, due to always-concern over flaky power to the plasma panels.

The other piece of this was they had rolled out the external command for everyone in the fall of 1974, after it having been only in use by the Music project. This meant that every user account on PLATO was set to defalt «can accept ext commands.» Default on.

If you recognize default enabled from any firewall work you’ll immediately recognize the trouble…

Anyway, I heard this and immediately thought of how a room full of annoying users could be locked up at once. My little 13 year old brain wanted to see a room full of users all be locked up at once.

So, I wrote a little program that sent exts to everyone within a range of site numbers, waited til I was over at CERL one morning, and let er rip.

It worked as advertised, 31 users all had to power off at once, great mayhem in the classroom, site monitors notified. No logging of course, I was never detected. Quietly left the room, went back over to uni.

Accessed the site displays I knew of from author mode, and looked up other sites around town or the country, and tried sending them some ext’s too. Was delighted to see mass posting on notesfiles about a locking out they were experiencing.

Soon some systems guys figured it out, probably a combination of common sense and maybe looking in some sort of logs, though I was never prosecuted or even approached, so I have to think to this day it was undetected. A few weeks later the ext command was withdrawn from ‘open all’ and a while after that was redeployed, this time with the default set to OFF. As it should have been all along. 🙂

So was there ever a DoS on a networked system prior to 1974 ? Im sure there had to be, but at least for the moment I’m claiming it !

Y la moraleja es…

Al final, es la historia de siempre. Si hacemos algo pensando en que la situación perfecta es la única, lo más probable es que alguien se de cuenta de que, si esa situación no se da, ocurre algo indeterminado. A partir de ahí, encontrada la vulnerabilidad, lo demás es jugar y eso es precisamente lo que hizo David.

Como dijo Chema en alguno de sus posts:

Entendemos como Software Fiable aquel que hace lo que tiene que hacer y como Software Seguro aquel que hace lo que tiene que hacer y nada más. Ese algo más entre el software fiable y el software seguro son los bugs.

En este blog puedes encontrar algunas entradas que te pueden ayudar a desarrollar software seguro como las de las contraseñas (esta o esta) o las de auditoría de código (esta, esta o esta). Con estos consejos podrás lidiar en la medida de lo posible contra ataques DoS como el que hizo David. En cuanto a los DDoS, eso es otra historia…

SecurityInside Live: Mundo Hacker Day 2017

/en , , , , , , , , , , , , , , , , , , /por

Al igual que el año pasado, me voy al evento «Mundo Hacker Day 2017» para asistir en primera persona a las interesantes charlas que grandes expertos en seguridad van a ofrecer.

Leer más

auditar-api

Revisando nuestros servicios: auditar API (parte 1)

/en , , /por

Poder ofrecer la información de valor que genera tu empresa de una forma eficiente y segura es tan importante que puede ser el punto de inflexión entre convertirla en un Unicornio o llevarla directamente a la ruina.

En el mundo de hoy, contar con una buena API que permita a terceros consumir tu información te va a permitir extender tu negocio más allá de lo que puedes ofrecer de forma individual. Es habitual conceder acceso a una parte pública de la información, pero otra parte sensible suele estar vinculada a algún contrato, cuota o condiciones particulares.

Una API abierta a terceros te permitirá abrir tu información y servicios a todo tipo de clientes, gestionando hasta dónde quieres que puedan llegar. Sólo tienes que ponerte a desarrollar en tu proceso de integración continua, darle caña a las pruebas unitarias, los test de integración, la documentación y todo lo que tu metodología dicte. Por fin tienes una API de calidad dispuesta a echar humo con miles de clientes y…

…entonces llego yo y te pregunto… ¿has tenido en cuenta la seguridad en el ciclo de vida de tu API?

Tu respuesta tiene una alta probabilidad de ser «ehhh…. no!». Lo normal es que sea así y que se hayan cometido errores de desarrollo que impliquen vulnerabilidades en nuestra API que puedan impactar en nuestro producto.

¿Como incorporo la seguridad a mi API?

api_security

Si no has empezado a desarrollarla, entonces te recomiendo que tengas en cuenta algún modelo como «Microsoft Security Development Lifecycle» (echando un vistazo aquí, aquí o aquí, aunque hablaremos de esto en breve) y lo hagas bien desde el principio.

Si ya tienes tu API funcionando, en la próxima entrada realizaremos una pequeña prueba que te puede ayudar a evaluar su seguridad.

En cualquier caso, deberías tener en cuenta siempre estos checks básicos:

1) Fase de Autenticación:

  • Habilita tu API únicamente con SSL, todos los accesos debería ser https. Prohibe http o dale un uso meramente informativo.
  • Nunca envíes usuarios, contraseñas, tokens… en la url.

2) Fase de Autorización:

  • Pon especial atención en el escalado de privilegios tanto en horizontal como en vertical.
  • Acentúa los controles en las peticiones que actualicen o eliminen información.
  • Utiliza roles para administrar permisos de tus usuarios.
  • Protege al máximo las funcionalidades destinadas a usuarios administrativos.

3) Gestión de sesión:

  • Habilita un tiempo máximo de sesión (timeout).
  • Asegúrate de tener medidas para invalidar tokens si es necesario.

4) Validación de entradas:

  • Los ataques web habituales pueden afectar a tu API, así que pon atención en los conocidos ataques de injección, xss…

5) Codificación de salidas:

  • Revisa bien la estructura de tu salida json, xml,…
  • Inserta cabeceras de seguridad acordes al uso que se le va a dar a tu API.

Empieza por echar un vistazo a estas recomendaciones. En la próxima entrada seguiremos viendo detalles para tener tu API lo más segura posible. ¿Te lo vas a perder?

de-charleta

De Charleta: “Mobile App Pentesting en Primera Persona” (Gustavo Sorondo)

/en , , , , /por

Hace poco se celebró la DragonJar Security Conference 2.016, así que hoy recomendamos esta interesante charla en la que Gustavo Sorondo (Puky) nos cuenta un proceso de pentesting sobre una app móvil.

Gustavo Sorondo es CTO de «Cinta Infinita – Information Security». En su carrera profesional ha trabajado en más de 100 proyectos relacionados a la seguridad de la información en 6 paises, y ha dictado cursos de Penetration Testing, Seguridad en Aplicaciones Web, Seguridad Wireless y Testing de Mobile Apps. También ha dado charlas y workshops en conferencias de seguridad como ekoparty, OWASP Latam Tours, Segurinfo, RISECON y PampaSeg.

DragonJar Security Conference 2.016.

Español.

https://twitter.com/iampuky
https://www.linkedin.com/in/gustavosorondo