Lee aquí tus blogs preferidos...

Security By Default

El extraño caso del SSH y el ataque de fuerza bruta

Hace poco me pasó una anécdota curiosa que me gustaría compartir con vosotros. Intentaré narrarla de la forma mas fidedigna posible.

Suena el teléfono, es un cliente con el que tengo una de esas relaciones que van mas allá de lo profesional y 'hay confianza':

Cliente> Yago ! Me están atacando !

Yago> ¿? A ti o algún equipo tuyo ?

Cliente> Perdona, estoy un poco acelerado, he encontrado unos logs de lo mas extraños relacionados con intentos de acceso vía SSH

Yago> Si es un servidor de cara a internet, es lo más normal del mundo, deberías cambiar el puerto e instalar fail2ban

Cliente> No, no, es a un equipo con un Linux que uso para administrar máquinas que está tras un router ADSL

#Interesante

Yago> Bueno, mantén la calma, seguro que todo tiene una explicación, ¿podrías enviarme alguna traza del log?

Cliente> Claro, ya mismo

Me llega a mi correo lo siguiente:

Feb 1 22:25:34 localhost sshd[11740]: Failed password for root from 173.83.251.184 port 52597 ssh2
Feb 1 22:25:36 localhost sshd[11742]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=173.83.251.184 user=root
Feb 1 22:25:38 localhost sshd[11742]: Failed password for root from 173.83.251.184 port 53937 ssh2
Feb 1 22:25:41 localhost sshd[11744]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=173.83.251.184 user=root
Feb 1 22:25:43 localhost sshd[11744]: Failed password for root from 173.83.251.184 port 55240 ssh2

Y así, un buen número de líneas con diferentes IPs cuya procedencia geográfica variaba y era de lo más variopinta (turkia, china ...)

Claramente se trata de un ataque de fuerza bruta pero ¿Como podía estar ejecutándose?

Lo primero que me vino a la cabeza son dos hipótesis: O bien era alguien en la misma red (wifi, presumiblemente) o había un 'nat' que hacía visible el puerto.

Descarto el tema de la Wifi por las IPs, si hubiera sido por ahí serian 192.168.x.x

Vamos con el tema nat:

Yago> No tendrás mapeado el puerto 22 de tu router hacia dentro ¿no?

Cliente> No ! claro que no, ya había pensado en eso

Como dicen en Aragón: 'Aragonesico que no toca, no ve'

Yago> Bueno, ve a www.whatismyip.com y la IP que te dé me la envías que quiero hacer una prueba.

Ejecuto un nmap y nada, 0 puertos a la escucha.

El cliente me asegura que su máquina es un pc de sobremesa y por ende, 'no se ha movido', también me asegura solo se conecta vía cable y no tiene interface Wifi (eso descarta que se haya podido conectar a una red insegura de forma inadvertida ...)

Le tranquilizo y le pregunto si tiene activado el acceso vía ssh para el usuario root. Me confirma que no, no está. Le pregunto por la longitud y la complejidad de la contraseña y por lo que cuenta, parece difícil de romper.

No obstante, le envío una serie de comandos grep para buscar si otros usuarios han sido atacados y si hubo un login positivo. No parece que haya habido compromiso en el sistema.

Dos días después vuelve a sonar el teléfono:

Cliente> Yago ! otra vez ! más intentos de acceso

Como esta persona no está excesivamente lejos decido desplazarme. Ya veré de que forma le hago entender el 'pedazo favor' que le estoy haciendo cuando toque hablar 'de otros proyectos'

Una vez in situ, reviso el router, efectivamente no tiene ningún puerto mapeado, vuelvo a leer los logs y veo que los patrones de acceso suelen ser por la noche.

Le cambio la IP a ese equipo por otra de la red interna y pongo otro PC con la IP anterior, en el que ejecuto un netcat a la escucha en el puerto 22

nc -l -p 22

Y me marcho.

A la mañana siguiente llamo y pregunto

Yago> ¿Que tal? hay alguna conexión en el netcat que dejé ayer ?

Cliente> No, está como lo dejaste, voy a ver en el otro PC

tras un rato ...

Cliente> Joder ! tengo más intentos de acceso !!

Yago> ¿Cooooooooomo? en el equipo donde cambié la IP ?

Cliente> Si ! ahí están

En este punto y ya con los esquemas totalmente por los suelos decido empezar a generar conversación intrascendente mientras intento que se me ocurra algo. Lo bueno de la informática es que siempre, SIEMPRE, las cosas tienen un motivo. No es como por ejemplo la medicina donde lo mismo un día te levantas con un misterioso dolor en la cadera y puedes pasar años escuchando 'no sabemos el motivo'

Después de haber hablado del tiempo, fútbol, política, etc ...

Yago> Se están poniendo feas las cosas con tanta SOPA/Sinde y demás ¿Eh?

Cliente> Si ! empieza a dar miedo navegar, yo estoy probando uno de esos servicios de VPN 'anonimizadores' cuando me pongo a bajar algo

¡Ding! Se me enciende la bombilla

Yago> Ehm, déjame hacer una prueba, conéctate a ese servicio de VPN

Cliente> ¿Ahora?

Yago> Si, dale

Cliente> Ok, ya está

Yago> Ve a www.whatismyip.com y me pegas la IP

Cliente> Toma xx.xx.xx.xx

telnet xx.xx.xx.xx 22

Connected to xx.xx.xx.xx.
Escape character is '^]'.
SSH-2.0-OpenSSH_5.6

Misterio resuelto !

Resulta que esa persona, 'además de usar el equipo para administrar' también lo usaba para descargar cosas, accedía mediante la VPN y esta le daba una IP pública totalmente accesible sin las restricciones de su router ADSL

Lecciones aprendidas:

1- Desconfía de lo obvio, pese a que un escenario parezca claramente una cosa (pc de sobremesa, tras un router adsl, sin wifi) has de intentar despejar la mente y no caer en pensamientos del tipo ¡ Es imposible !, si hay un log que dice X, es X y es ahí donde hay que hacer 'foco'.

2- Fuera los remilgos. Probablemente si hubiera auditado el PC a fondo, revisado todos los logs y configuraciones, habría visto tanto las trazas de la conexión VPN, como los ficheros de configuración. En primera instancia me pareció demasiado intrusivo pedirle 'el root' y lanzarme a investigar y opté por no invadir su privacidad. Craso error
RootedLab: Iniciación al hacking

Como ya ocurrió otros años, el taller que imparto en la conferencia Rooted se ha llenado y la organización ha decidido repetirlo otro día.

El curso será similar a otros años, aunque he actualizado los ejercicios prácticos y habrá que desarrollar algún exploit y "pivotar" en un sistema para simular una intrusión.

Estoy pensando en hacer algo tipo "wargame" pero aplicado a casos reales que sirvan como ejemplo del día a día en un tests de intrusión.

El temario esta publicado con el resto de información en la página web de los rootedlabs y el lugar donde inscribirse.

Contenidos
- Fases de un test de intrusión
Entrevista al equipo de Backend de Tuenti

Mucho se ha hablado en Security by Default sobre redes sociales (en mi caso, centrándome siempre en Tuenti) y siempre hemos tenido solamente una visión, la nuestra. Se me ocurrió hace unos meses que podía ser interesante organizar una entrevista con el equipo de Backend de Tuenti (evitando a departamentos de comunicación) y que nos contaran, desde la perspectiva de la seguridad, el funcionamiento interno de la red social. En un primer momento iba a ser una entrevista en video pero voy a estar unos meses ‘fuera de combate’ asi que hemos optado por la opción clásica.

Antes de empezar, agradecer a Guillermo Pérez (@bisho), responsable de Backend y Seguridad, todas las facilidades que ha puesto para poder llevar a buen puerto la entrevista. Todos los que hayáis reportado alguna vez una vulnerabilidad habréis tratado con él, y a los que no, deciros que el trato recibido siempre ha sido ejemplar (y eso que no siempre hemos coincidido y hemos tenido algún que otro roce… :D). Agradezco también a Chema Alonso (@chemaalonso) por las preguntas que me propuso.

¡Comencemos!

Como la entrevista es algo extensa, podéis acceder aquí a la versión en PDF.
La entrevista la he estructurado en cinco partes, seguridad del lado del equipo de desarrollo, del de la empresa, acerca del reporte de vulnerabilidades, seguridad/privacidad y finalmente un par de ‘offtopic’.
1. Del lado del servidor
- ¿Qué metodología de desarrollo de código utilizáis?
Cada equipo tiene libertad para elegir su propio modelo de desarrollo, según las necesidades de cada área de producto. Casi todos los equipos de producto utilizan alguna metodología ágil, fomentándose mucho el test-driven development (TDD).
- ¿En qué partes del desarrollo entra en juego la auditoría de seguridad?
Desde el principio, por supuesto. Desde el mismo momento en que se está diseñando un servicio nuevo, se tiene en cuenta la seguridad y las reglas de privacidad. No sólo el código es revisado por otros miembros del equipo u otros equipos, sino que las especificaciones de producto y técnicas también pasan revisiones de otros equipos.

Por ejemplo para diseñar la plataforma de juegos, hicimos mucho hincapié en la privacidad, generando identificadores de usuario diferentes de los de la plataforma, distintos para cada proveedor de juegos, no proporcionamos la lista de amigos completa, sino sólo los amigos que hayan aceptado también las condiciones de privacidad del mismo juego, y un sin fín de medidas adicionales. Todo para proteger a los usuarios y limitar la información que se cede a terceros. Es un gran esfuerzo, requiere más computación y sube la barrera de entrada de nuevos proveedores de juegos, pero es un buen ejemplo del esfuerzo y el compromiso con la seguridad y la privacidad en Tuenti desde la misma fase de diseño de los productos.
- ¿Tenéis algún equipo de testing de código con tests unitarios, de regresión, fuzzing y demás técnicas?
Por supuesto. Tenemos un equipo de QA, release y testing frameworks (amplios y dedicados).
Tuenti tiene una amplísima batería de tests, desde unitarios hasta de aceptación con navegadores automatizados. Usamos Jenkins con múltiples instancias donde se prueban las ramas de desarrollo, que necesitan pasar todos los tests antes de ver la luz verde para ‘mergear’ el código al repositorio de integración. Este, a su vez, vuelve a pasar todos los tests en cada ‘merge’ antes de que salga a producción.

Aún siendo muy exhaustivos con los tests, el proceso está muy automatizado y resulta ágil. Somos capaces de hacer dos releases a la semana, con más de quince ramas de desarrollo en cada una, y nuestra intención es agilizarlo aún más.
- ¿Qué herramientas de tracking de bugs utilizáis internamente?
Actualmente estamos en una fase de transición de Trac a Jira, ya que Trac se nos quedaba pequeño para el tamaño del equipo y el volumen de los datos. En otras áreas de la empresa como sistemas o soporte al usuario utilizan otras herramientas mejor adaptadas a sus necesidades.
- Segun me comentasteis dais charlas internas los viernes… ¿Son realmente suficiente? ¿os habéis planteado que las imparta una empresa externa?
La formación es clave para una empresa como Tuenti. Las charlas técnicas de los viernes suelen ser de formación para nuevos empleados y las grabamos en vídeo para que estén siembre disponibles para cualquier recién llegado.

Normalmente las charlas son de miembros del equipo para explicar la filosofía de las herramientas, recomendaciones, etc., aunque no sustituyen al 100% a la documentación.
También se anuncian entre los empleados charlas que puedan resultar interesantes (sobre todo en Madrid y Barcelona que es donde tenemos oficinas), se fomenta la asistencia y se anima a participar como ponentes. Estamos abiertos a hospedar charlas técnicas externas en nuestras oficinas como las de Madrid DevOps, MadridJS o Python-Madrid, y patrocinamos numerosas conferencias.

Por último cada ingeniero tiene asignado un presupuesto que puede emplear para atender a conferencias técnicas. Hemos estado en el Velocity y muchas otras conferencias tanto nacionales como internacionales.

2. Del lado de la empresa
- ¿Habéis superado la ISO 27001?
En Tuenti estamos absolutamente concienciados sobre la seguridad y seguimos buenas prácticas alineadas con esta ISO, pero implantarla supondría una carga operativa importante en todos los procesos y por el momento no lo hemos hecho.
- Empresas como Microsoft, Google, o Facebook, contratan auditorías whitebox/blackbox a empresas externas. ¿Ha auditado el código completo de la red social alguna empresa externa?
Grupos de Telefónica dedicados a la auditoría se encargan de las de tipo blackbox y estamos explotando sinergias para que se realicen auditorías de código pero, como el código de Tuenti es de una elevada complejidad y muy especializado, es difícil que herramientas automáticas den resultados aceptables (encargándose el equipo de QA de las pruebas manuales).
- Uno de los principales problemas reportados por la Cloud Security Alliance es el del insider... ¿Hacéis auditorías de seguridad para saber quién ha accedido a qué perfiles de forma regular? ¿Tiene que reportarse todo acceso de un desarrollador o administrador a la base de datos de información en producción o backup?
Hemos pasado una auditoría de la AEPD muy recientemente. El equipo de ingeniería con acceso a datos es reducido y el acceso no es fácil. Los backups se encuentran aislados. Registramos la actividad de los equipos de soporte, que son más amplios, para controlar el mal uso de los permisos de administración, pero por el momento dichos registros son privados.

3. Reporte de vulnerabilidades
- ¿Cuantos reportes recibís y cual es su criticidad media? ¿Cuáles son los tiempos de actuación?
En el último trimestre tan sólo recibimos cuatro notificaciones de siete vulnerabilidades, y el anterior fue aún mejor. Nuestro compromiso es solucionar las incidencias de seguridad en menos de 24h, aunque normalmente tardamos entre 1 y 2 horas.

La tendencia es claramente positiva, con cada vez menos incidencias (sobre todo en productos nuevos que antes eran un problema), siendo la criticidad de las mismas cada vez menor.
El fallo más habitual suele ser algún tipo de inyección XSS, que tienen una criticidad limitada ya que requieren que el atacante desarrolle una plataforma para el ataque.

Aunque no es una vulnerabilidad en sí misma, con diferencia, el mayor problema de seguridad es el phising. Normalmente cada semana aparece alguna página nueva dedicada a engañar a los usuarios y robar credenciales. Bloqueamos la URL de inmediato y contactamos con los hostings y proveedores de DNS para cerrar la página lo antes posible. Tenemos contratada una empresa externa para el proceso, y actuamos por vía judicial si se averiguan datos de los implicados.
Ser rápidos es imprescindible para limitar la posible exposición de los usuarios y el beneficio obtenido por los atacantes. Cuanto menos sea el beneficio, menos interesante será Tuenti como plataforma a atacar, y por ello nos lo tomamos muy en serio.

También tratamos de concienciar al usuario, colaboramos con entidades públicas y privadas que trabajan en éste área explicando a los jóvenes cómo controlar su privacidad en Internet y disponemos de páginas de ayuda, pero el factor humano es siempre el eslabón más débil.
- En el caso de que alguien encuentre una vulnerabilidad… ¿Como os la notifica? ¿Cómo gestionáis todos los reportes?
Atendemos todos los buzones de correo publicados en DNS además del estándar security@tuenti.com. No queremos publicarlo en la web para evitar que el volumen de correos no relacionados (realmente) con problemas de seguridad sea tal que los ingenieros tengan que dejar de atender la cuenta, y tener que ser filtrada por soporte al usuario. Actualmente tenemos un representante de cada equipo, y eso garantiza unos tiempos de respuesta bajísimos en comparación con muchas otras empresas del sector.

Las comunicaciones vía los canales de soporte al usuario también son filtrados y nos acaban llegando. Aunque el equipo de soporte es amplísimo y está muy formado, el proceso suele demorarse más tiempo hasta que llega a manos de los ingenieros.
- En el caso de que se publiquen vulnerabilidades sin haber sido notificadas previamente, ¿cómo gestiona Tuenti la situación?
Lo primero nos centramos siempre en lo importante: tratar de solucionar el problema. Luego procuramos contactar con la persona que lo publicó para pedirle que la próxima vez nos lo notifique previamente, a fin de que ningún usuario se pueda ver afectado por un fallo de seguridad. Les transmitimos nuestro objetivo de solucionar las incidencias en menos de 24 horas, y casi siempre la gente responde genial, se muestra muy dispuesta a colaborar y agradece nuestra actitud responsable y comprometida por la seguridad.
- Recientemente enviastéis un C&D a un usuario por publicar una aplicación que monitorizaba el tráfico XMPP del chat de Tuenti (tema comentado aquí hace más de un año), ¿puedes comentarnos por qué llegastéis a tomar esa decisión si no era ninguna novedad?
Somos totalmente flexibles y tolerantes con la publicación de artículos, investigaciones e incluso segmentos de código, pero dar una herramienta ya lista es algo diferente, puede perjudicar a muchos usuarios. Actuamos igual que hacemos para casos de phising y spam, una vez detectado, nuestro departamento legal envía un C&D estándar para tratar de mitigar el riesgo lo antes posible.

No obstante, a posteriori nos hemos puesto en contacto desde el área técnica con el autor para agradecerle su rápida colaboración y aclarar los motivos. Las relaciones han sido cordiales y estupendas, como entre todos los profesionales de este sector.
- Hemos podido comprobar la buena acogida que ha tenido el ‘Bounty Program’ de Facebook… ¿Habéis pensado en algún tipo de reconocimiento para los que, desinteresadamente, os notifican vulnerabilidades?
Siempre he creído que una respuesta rápida y profesional es la mejor respuesta, y siempre procuramos agradecer las comunicaciones y mantener informado del estado a los investigadores. También tenemos previsto reconocer la labor en un “Hall of Fame” de seguridad. Por supuesto sólo aquellos que nos notifiquen las vulnerabilidades y nos permitan solucionar el fallo antes de la publicación serán susceptibles de ser incluidos en él. Por el momento no tenemos pensados bounty programs, aunque si que solemos mandar algún detalle, camisetas, el famoso bote de Conguitos...

4. Seguridad y privacidad
- ¿Tenéis implementado algún motor antimalware para validar los enlaces que publican los usuarios en la red social contra bases de datos de, por ejemplo, Driven by URL malware?
Tenemos validadores de muchos acortadores, más de 125 actualmente, aunque obviamente no es posible estar siempre 100% al día. También tenemos sistemas anti spam y anti malware automáticos y podemos bloquear URLs concretas dentro de la plataforma.
- Control de privacidad, ¿es suficiente?
Creemos que lo simple es al final lo más conveniente. Sistemas más complicados acaban haciendo complejas las implicaciones y causando más fallos que beneficios.
Tuenti es cerrada, intenta que los usuarios sólo acepten a sus verdaderas amistades y que la información sea siempre relevante.

Además, en el caso particular de juegos y aplicaciones de terceros, como he comentado antes, hemos puesto mucho énfasis en la privacidad y protección de nuestros usuarios. No sólo redujimos la información enviada de cada usuario (por ejemplo, nunca se facilita el correo electrónico del usuario, al contrario que otras redes sociales) sino que los contratos que firman los proveedores de juegos están muy blindados a favor de la privacidad del usuario son muy estrictos con el manejo y almacenamiento de su información.
- ¿Qué ocurre con los datos cuando los borramos?
La ley nos obliga a guardar algunos datos de acceso durante un tiempo. Aparte de eso, los datos se borran físicamente de todos los soportes de almacenamiento. Las fotos también se borran, aunque este proceso, dado el elevadísimo volumen de datos que manejamos, tarda más.

Además, hay que comprender que el volumen de ficheros que se sirven en un sitio como Tuenti es tal que se suelen utilizar sistemas especializados, CDNs y servidores de estáticos. Éstos disponen de cachés que pueden tardar en actualizarse. Aún con todo, la diferencia es importante con respecto a otras redes sociales por nuestro marcado compromiso con la seguridad y la privacidad de los usuarios.
- ¿Se almacenan las conversaciones del chat?
No, nos las almacenamos. Sin embargo los usuarios nos lo están pidiendo y estamos trabajando en poder atender esta demanda cumpliendo con todos nuestros protocolos de privacidad.
- Con respecto al manejo de sesiones… ¿tenéis pensado evitar que los indentificadores de sesión sean comunes entre API y Web? ¿qué pasó con el firmado de peticiones?
Estamos trabajando para quitar la compartición de sesiones entre plataformas, pero surgen muchos efectos colaterales. Creo que pronto lograremos que al menos el session id de la web normal no sirva para la API, aunque tiene el inconveniente de que extensiones de navegador puede acabar pidiendo el login y contraseña a los usuarios, lo cual es una mala práctica.

El firmado de peticiones causaba muchos problemas con algunos navegadores, y actualmente estamos apostando por SSL en vez de soluciones complejas.
- Pregunta obligada, ¿váis a implementar SSL tanto en la página como en el chat y la API?
Nuestra infraestructura ha avanzado bastante en estos meses con conexiones persistentes, persistencia de sesiones SSL y un nuevo sistema de balanceado, así que tenemos planificado ofrecer SSL pronto.

En cualquier caso, me gustaría reiterar que el principal problema de seguridad de las grandes plataformas en Internet es el phising, muy por encima del robo de sesiones por interceptación de comunicaciones. Interceptar tráfico es más complicado, el target de usuarios es más reducido y el atacante queda más expuesto (tiene que estar en la misma red) que en un phising donde se puede aprovechar el anonimato de Internet. Por no hablar de que las sanciones por violar la privacidad de las comunicaciones son muchísimo más severas.

Respecto a la implantación de SSL, no puedo dar fechas al respecto todavía, ya que en una plataforma tan grande como Tuenti siempre hay mucha casuística que resolver. Pero será más pronto que tarde.

5. Otras preguntas
- Comentanos un poco el tema de las becas en Tuenti
Colaboramos activamente con las universidades y ofrecemos cursar proyectos de fin de carrera. Tenemos un catálogo de temas e ideas pero también estamos abiertos a sugerencias. Recomiendo contactar con hr@tuenti.com a todo aquél interesado.

Además, hace poco organizamos el primer Hack/Programming Contest de Tuenti con muy buenos resultados, tanto por el feedback que nos dieron los participantes como por haber acabado haciendo ofertas a casi todos los finalistas. Aprendimos mucho de esta experiencia y esperamos mejorar los sucesivos contests que hagamos.
- ¿No crees que dar acceso a las betas privadas a las personas que os notifican vulnerabilidades sería una buena forma de fidelizar su colaboración?
Tenemos un sistema de lanzamiento de productos muy flexible que nos permite seleccionar a gente por diversos criterios, incluso selección manual de usuarios específicos.

Actualmente estamos incluyendo a algunos colaboradores en los programas de beta, aunque depende mucho del producto, del secretismo necesario, de si se desea hacer pruebas de A/B testing sin polucionar, etc. Si algún investigador de seguridad desea ser incluido puede contactar con nosotros y lo evaluaremos.

Bueno, si habéis llegado hasta aquí... ¡enhorabuena!
Espero que haya resultado interesante :)

----------------------------------
Contribución por Luis Delgado
¿Por qué falla la seguridad?

Cada día, cuando abrimos Twitter, las RSS, o nuestras fuentes de información de seguridad favoritas, nos echamos las manos a la cabeza por diversos motivos.

Cuando no es por las cifras del paro, es por el aumento de la prima de riesgo, o las leyes censuradoras de los gobiernos a favor de los "autores".

Al llegar a la sección "Seguridad", siempre hay algo que nos sorprende. Lo normal es encontrar entradas relacionadas con vulnerabilidades parcheadas de diverso software, aunque de vez en cuando leamos que es noticia la publicación de datos personales de miles de clientes, defacements y robos a compañías enormes como Sony, Nintendo, Google,… hechos más graves como el compromiso de bancos o datos internos del gobierno de un país, y ya lo que es el colmo, los hackeos memorables de compañías que se supone, están dedicadas a seguridad como pilar central de negocio: RSA, diversas entidades de certificación como Diginotar o Comodo, Symantec, HBGary o el último de los escándalos: Verisign!!

La seguridad en una empresa pequeña

Me puedo creer que la empresa de tipo "Maderas Pepe" no disponga, para proteger su día a día, de mecanismos de seguridad que blinden la información importante de su contabilidad y clientes en su único servidor.

Lo habitual, en este tipo de empresas, es que ni haya servidor. Todo lo relacionado con contabilidad suele estar en el portátil de la administrativa, compartiendo sitio con el emule, los juegos online, y la edición online de la revista Hola! abierta. Los "secretos industriales" del cómo cortar la madera, en la cabeza del dueño y de los operarios.

Este escenario, llevado a empresas un pelín mayores, se cuenta con un sencillo firewall, los PCs de los usuarios tienen el antivirus crackeado que instaló el vecino (con suerte no está bajado de Taringa), y con muy mala suerte, a lo mejor incluso se aprovecha la infraestructura del PC que compraron de oferta en el Mediamarkt que hace las funciones de servidor web, para almacenar ficheros importantes, contratos, información de clientes, datos de negocio, que si los coge la Agencia de Protección de Datos, les "cruje" una multa que provocaría el fin de la empresa, etc,…

La seguridad en empresas medianas

Si seguimos creciendo, observamos compañías de mayor envergadura, que no desean preocuparse ellos de la seguridad, por lo que contratan a una empresa externa, en el que un señor con corbata y maletín, que antes vendía lavadoras, y anteriormente enciclopedias puerta a puerta (no os lo toméis a risa, que me he conocido estos casos), les explica que su empresa tiene el "know-how" de seguridad desde muchos años atrás, porque tienen una experiencia que ni te imaginas, y un montón más de humo, con el objetivo de vender.

La realidad, en muchos de estos casos, es que los técnicos que la empresa con "know-how" lleva como responsables de proteger y securizar los problemas del cliente, han entrado en la compañía hace una semana, gracias a que el comercial vendió este proyecto, y hubo que contratar a la carrera al primero que pasó por la puerta para cubrir la necesidad. El cliente, que lo que quiere es lavarse las manos en el tema de la seguridad, si realmente no tiene ni idea, ni sentido común, deja hacer al chaval que viene con una camiseta que dice "No, no voy a arreglar tu ordenador", y vive feliz confiando en que el contrato que ha firmado, si hay algún incidente de seguridad, la empresa responderá. La conclusión a este escenario es que efectivamente, la empresa pagará por lo que dice su contrato, pero el daño ya estará hecho, la base de datos de la empresa en Pastebin (o aún peor, en manos de la competencia).

La seguridad en grandes empresas

En empresas de tamaño XXL, desde el punto de vista de infraestructura, disponen de servidores dedicados para cada cosa, una correcta segmentación de redes, dispositivos de seguridad que monitorizan eventos, detección de ataques, políticas de seguridad de red definidas de forma correcta, aplicaciones configuradas con permisos mínimos para acceder con lectura (y/o escritura) de lo estrictamente necesario, etc,…

Aquí ya la cosa cambia…. ¿o no? Veamos.

Efectivamente, la seguridad se aplica, en una mayor medida. Sin embargo, no se considera nunca la securización de la mayor de las amenazas: las personas. No estoy descubriendo la pólvora al decir esto, pero cierto es que una de los mayores peligros en las empresas, es el desconocimiento o la inconsciencia a la hora de trabajar de la gente, y sobre todo: las excepciones. En todas las empresas que he estado, con mayor o menor conciencia de seguridad, las necesidades puntuales que tiene un empleado ante un caso determinado, es la ventana de entrada a que todo el blindaje previo se vaya abajo.

¿Queréis ejemplos? el empleado Paquito, que tiene que ser el único que necesita tener habilitado el USB del PC porque hace una tarea todas las semanas que así lo requiere; la existencia de otro gateway que nos lleva a Internet, con una política de seguridad más ligera que el cortafuegos corporativo; que el CEO de la compañía pueda tener una contraseña sencilla tipo "1234" o que esta sea el nombre de la empresa para el acceso remoto.

En todos estos casos, las excepciones son las que nos tiran por tierra el resto del trabajo: Todo aquel que quiera copiar las fotos del fin de semana, o ese powerpoint tan chulo de colores que trae en un USB, irá donde Paquito que tiene el USB accesible y le pedirá por favor que lo copie por red a su PC…. ¿Total, que puede pasar? Si esto de no poder usar los USB, lo hacen los empresarios por fastidiarnos y que no podamos traer MP3 a la oficina; ¿que el gateway normal no me deja ir a buscar el crack ese que me pidió un amigo que le buscara? Menos mal que está el otro aceso a Internet, para "emergencias como esta" y, como una vez ví al de sistemas meter la clave de administrador (o me la dio directamente por no bajar desde su planta a la mía), pues me cambio el gateway un momento y salgo por el otro cortafuegos; ¿que todos los empleados tienen una política de complejidad en las contraseñas y el CEO no? pues ¿es lo lógico no?, que la persona que mayor visibilidad tiene sobre la empresa, y que maneja información más sensible, tenga una contraseña fácilmente adivinable porque se niega a cumplir con la política de complejidad o a acceder con algún mecanismo de autenticación fuerte por ser más "coñazo".

Conclusiones

Evidentemente, en algunos de los casos que he expuesto, he exagerado para denotar el por qué de la falta de seguridad. Generalizar es siempre un error, y por eso digo abiertamente que, afortunadamente, en el mercado, hay muchas empresas de seguridad que disponen de personal muy bien cualificado y, por supuesto que son capaces de ofrecer al cliente un servicio profesional y con buenas prácticas de seguridad. Sin embargo, estoy completamente convencido que nuestros lectores conocerán casos en los que incluso, me he quedado corto.

No me quiero extender más con las reflexiones. Simplemente he querido expresar que la seguridad falla por múltiples factores, pero que, partiendo de algo bien configurado y optimizado, todas las causas tienen como denominador común, o el desconocimiento, o la inconsciencia, irresponsabilidad o negligencia.
Interceptar con un proxy peticiones SSL de un iPhone

Como hemos repetido incansables veces, una de las partes más importantes de auditar aplicaciones móviles es auditar los servicios web con los que interactuan. Si la comunicación se hace utilizando HTTPS, no basta con configurar el proxy en el móvil, ya que las aplicaciones nativas hacen llamadas a la API exigiendo que el certificado sea válido.

La forma más sencilla de interceptar estas comunicaciones es añadiendo un certificado de confianza siguiendo los pasos que se describen a continuación:

1.- Se arranca el servidor proxy, en este caso "burp" y configurado para que genere certificados SSL:

Opciones del proxy Burp

2.- Usando Firefox se visita cualquier página en https para que muestre error de certificado y se pueda exportar mediante la opción de añadir una excepción, ver, pestaña detalles, y pulsando sobre PortSwigger CA , darle a Exportar. El fichero generado ha de tener extensión ".cer" para luego ser importado en el móvil.

Exportar certificado de PortSwigger CA con Firefox

3a.- Una vez exportado se puede importar de tres formas distintas. La primera y más sencilla es mandar un correo adjuntando el archivo a nuestra propia dirección y cuando se reciba, abrir el adjunto para instalarlo tal y como se muestra en las tres capturas siguientes.

Correo electrónico con certificado adjunto

Propiedades del certificado previa instalación

Certificado finalmente instalado

3b.- Otra opción alternativa para añadir el certificado es utilizar la utilidad de Apple "Iphone Configuration Utility", añadiendo un nuevo perfil.

3c.- La última opción es colgar el certificado en un servidor web y acceder mediante Safari para descargarlo, lo que proporcionará el menú de instalación igual a la primera opción.

4.- Una vez instalado el certificado, se configura el proxy en los ajustes de la Wifi:

Una vez terminado el trabajo, se elimina desde Ajustes->General->Perfil->Eliminar.

Ajustes generales

Lee aquí tus blogs preferidos...

Security By Default

Suscribirte a nuevas noticias

Novedades Ultimas noticias

Popular Las más vistas