Archive for the ‘Knowledge’ Category

El costo de NO INVESTIGAR incidentes

Thursday, July 10th, 2014

El costo de NO INVESTIGAR incidentes

En enero del 2005, la compañía Vodafone Grecia no pudo procesar los mensajes de texto (SMS) de sus clientes de telefonía celular. Luego de un mes de revisar la extraña falla, su proveedor concluyó que una actualización del firmware había provocado el desperfecto. La actualización contenía 6,500 nuevas líneas de un sofisticado y esotérico código totalmente ajeno a Ericsson. Al ahondar un poco más, el proveedor determinó -también- la presencia de módulos activos de interceptación de llamadas.

Al día siguiente de recibido el reporte, George Koronias, el CEO, solicitó al fabricante Ericsson remover el código y desactivar los módulos hallados.

Como resultado de esta acción, toda oportunidad de rastreo directo se estropeó. La fuerza del orden y el servicio de inteligencia de Grecia quedaron imposibilitados de dar con los criminales que provocaron esta interceptación, la misma que afectó a más de 100 líderes civiles y de gobierno por 8 meses continuos. La orden de des-instalación y des-activación actuó en contra de Vodafone, al convertirse en una señal de aviso indirecto para los intrusos y hacerles notar que Vodafone había identificado la anomalía, lo que no dejó de ser aprovechado como una ventaja para limpiar otros rastros, con suficiente antelación.

En el desenlace de esta historia, entre los años 2006-2008, Vodafone Grecia sufrió finalmente de diversas multas judiciales y regulatorias, además del reemplazo de George Koronias, su CEO, uno de los más exitosos en Grecia. Las multas de Vodafone Grecia ascendieron a €110,000,000 (1) por obstruir la investigación policial, y (2) por violar diversas reglas de protección de datos personales de hasta dos reguladores en ese país.

Antes, durante, y luego de la brecha, las organizaciones necesitan de un aliado!

JACKSECURITY – JACK YOUR INCIDENTS NOW!

La capitalización de un hacking

Friday, July 4th, 2014

8 años

En cierta ocasión, el centro de datos donde trabajaba era señalado como la fuente de una catástrofe en toda la red de la compañía. Por supuesto, mi firewall no iba a ser la excepción, especialmente porque su predecesor administrativo había renunciado a no más de 30 días atrás.

Llegado mi turno, el que era mi jefe me dijo:

¿por qué no revisas el firewall? ¿no lo estarán atacando?

Por supuesto, quedé frío. Imaginé seriamente la probabilidad que eso era cierto, en especial por que el análisis de riesgo que había hecho a toda la infraestructura había demostrado que eso era viable.

A pesar de que los dumps & logs no mostraron indicios que un ataque operativo estuviera en curso de acción contra el firewall, la revisión arrojó una ingrata sorpresa: Una regla de acceso TELNET había sido configurada para una dirección IP de la Federación Rusa. Para bien de mi salud cardíaca, mi conocimiento me decía que tal regla estaba inconclusa porque el firewall requería de una configuración VPN para los accesos remotos como ese. Uffff…!!! casi…!

Con todo ello, una cosa era cierta “me habían hackeado”, quizás no literalmente al firewall, pero cuando menos -sí- a algún sistema de mi red, y sabemos que un sistema en la red es potencialmente toda la red.

Desde entonces, afirmo una sóla posición respecto a la seguridad: “todos podemos ser hackeados”.

Es por eso que, en el presente, JaCkSecurity te insta a estar preparado.

Javier Romero, CTO
JaCkSecurity

4/7/14: Cumplimos 8 años.

Security! el chico nerd se hizo grande

Tuesday, May 13th, 2014

Hace años, para varias personas desear ser un hacker (experto en seguridad), era un sueño de nerds. Hablando de qué quería hacer al graduar mis estudios, un compañero tuvo el infortunado comentario de decir, que en el país donde residía no existían hackers (en el término malo), y que por ende dedicarse a arreglar problemas de seguridad, era absurdo, era de nerds, era para morirse de hambre. Era entonces el verano de 1998, en el trópico de cáncer. A la fecha, sucede al revés, por no dedicarse a la seguridad, te mueres de hambre.

Estoy convencido que quien escribe esta entrada, no fue el único que tuvo una experiencia similar, y no se rindió, y batalló su visión en su respectiva región.

Security! el chico nerd se hizo grande

Security!, el chico nerd se hizo grande. Hoy, sin embargo, se hace más notorio que los tiempos de cambio que vive la humanidad, los datos y la tecnología empiezan a gravitar con fuerza hacia “la seguridad de la información”. En plena segunda mitad del segundo decenio del siglo XXI, desde las personas de a pie, las instituciones con y sin fines de lucro, y hasta los intocables ejecutivos corporativos, todos hablan de seguridad, la seguridad les preocupa, la seguridad les importa.

Tan sólo en enero del 2007, mientras viajaba en un taxi en la ciudad de Hollywood en Florida, USA, me deleitaba el ver en retrospectiva que el jargon nerd se había hecho materia de conversación natural, cuando el taxista que me transportaba me preguntaba qué herramienta de protección de passwords usaba yo, mientras me hacía referencia a la que él usaba, porque estaba de “moda” en la web.

La seguridad ahora tiene tal mano dura, que usada como fuente de justicia, puede sancionar por miles y hasta millones de dólares a instituciones solamente. Así, es el caso de dos hospitales en Nueva York (New York Presbyterian Hospital and Columbia University Medical Center) que tuvieron que desembolsar $4.8 millones por violar la ley HIPAA. ¿El hecho? Expusieron -de manera accidental- datos personales de pacientes cuando un médico desconectó su computadora personal, de la red que poseía más de 6,800 datos sensibles (con resultados de laboratorio, datos de medicación y más información de pacientes).

Llevado a moneda peruana, la sanción tuvo el equivalente a S/.13 millones, que se puede expresar mejor como el salario de todo 1 año de una compañía peruana de 400 a 500 trabajadores en promedio. Sí, leyó bien, el salario de 400 a 500 trabajadores de una compañía exitosa, que podrían producir según su rubro de 10 a más millones de dólares americanos en 1 año, sólo en Perú.

Si tal sanción pudiera trasladarse al empleo, hablaríamos entonces de despojar de empleo a 500 familias, por al menos 365 días.

¿No le interesa la seguridad?, Security, ya no es más un asunto de suntuosidad, o de nerds. No invertir en ella, es como revertir voluntariamente lo logrado, y producir un forado crítico, en la vida de personas, negocios, y hasta de economías enteras, no sólo de su compañía, o de su cargo como gerente.

Preocúpese por su seguridad!

JACKSECURITYJACK YOUR INCIDENTS NOW!

Escribe: Javier Romero, CISSP CISM ISO27001LA GLEG GCSC GXPN GWEB GCIH CGIA C|EHv8 GWAS SSP-GHD, actual Chief Technology Officer de JaCkSecurity.

Hackear una compañía antes de adquirirla

Tuesday, February 11th, 2014

¿Deberían añadirse labores de Ethical Hacking y de Incident Detection al Due-Diligence, durante el proceso de adquisición de una compañía?

Sí.

Un asesor de negocios, sí debería sugerir un “ethical hacking & incident detection”, como parte del due-diligence.

¿Pero es acaso eso ético?
Siendo que no hay nada de antiético en un due-diligence, y desde que los frameworks de due-diligence contemplan el identificar el riesgo del negocio desde la perspectiva de la seguridad de la información, por el contrario a lo que podamos concebir en primera instancia, un ejercicio de ethical hacking & incident detection es más que razonable, pues nos permitirá identificar los riesgos reales, así como los incidentes (riesgos más reales aún) que ya vienen produciéndose en esa compañía. Sin duda eso, ayudará a tener una mejor decisión a la hora de comprarla, y saber qué riesgos para los bolsillos del inversionista eso significa.

Como empresa en soluciones de análisis y detección de brechas e incidentes, JACKSECURITY ha visto importantes casos, donde la incómoda situación futura de la adquisición podría haberse mitigado, si la diligencia debida hubiera sido dirigida con igual atención sobre la seguridad de la información de la compañía adquirida, desde el enfoque real “hacking & incidentes”.

Citando un caso público, en el años 2011, la compañía VASCO tuvo que perder los €10 millones que había empleado para adquirir la compañía DIGINOTAR, además de otras tantos a sólo un par de meses de su operación de compra, luego que se descubriese que su adquirida había sido víctima de una brecha de seguridad informática importante, hecho que además sacó a la subsidiaria del negocio de los certificados digitales. Aún, los mismos oficiales de VASCO fueron los primeros en hacer saber a todos los medios de la puesta en bancarota en la que se hallaba DigiNotar.

Vea en la gráfica siguiente la importante caída estacionaria en las acciones del ejemplo descrito, luego que VASCO hiciera público los hechos, y a pesar de que los negocios de VASCO poco o nada tuvieran que ver con la tecnología de su recién subsidiada DIGINOTAR (2011)



Recomendación JaCkSecurity:
Si Ud. es un ejecutivo en esta misión escríbanos para presentarles una solución de análisis y detección de brechas e incidentes de seguridad real y en producción de su prospectada actual.

JACKSECURITY
JACK YOUR INCIDENTS NOW!

Armas para un CISO: El caso Heckenkamp (1999)

Wednesday, November 27th, 2013

runner

En diciembre 1999, Scott Kennedy, administrador de sistemas de Qualcomm Corp. San Diego, California, descubrió que alguien había hackeado la red de su compañía, por lo que contactó a Terry Rankhorn del FBI.

Su rastreo de la intrusión apuntaba a una computadora en la red de la Universidad de Wisconsin en Madison. Jeffrey Savoy, investigador de la red informática, respondió al contacto de Kennedy, al examinar inmediatamente los sistemas de su universidad.

Savoy determinó que en efecto alguien había empleado una computadora en la red de la universidad para hackear los sistemas de Qualcomm, y que la misma computadora había sido usada para hackear uno de los sistemas más importantes de la universidad, el servidor de correos (Mail2) con 60,000 cuentas de correo y con una carga diaria de 250,000 correos, lo que lo convertía de valor crítico, sobre todo porque era temporada de exámenes finales.

La computadora empleada pertenecía al área de hospedaje estudiantil, y su dirección IP terminaba en .117 (en adelante “x.x.x.117″). El acceso ganado contaba con los privilegios de un administrador (root), y ninguno de los administradores había estado trabajando desde los dormitorios del campus.

Fijando la dirección IP como referencia inicial, y comparándolo con los tiempos del acceso del hacking y los ingresos normales al servicio de correos, Savoy determinó que el estudiante de ciencias informáticas Jerome Heckenkamp podría estar relacionado, además de su resquemor por los antecedentes laborales de Heckenkamp en el departamento de TI, donde fuere despedido por actos similares.

Sin embargo, debido a que los registros (escritos) de asignación de direcciones IP del hospedaje estudiantil no eran precisos y hasta eran incongruentes con la persona de Jerome Heckenkamp, Savoy sólo procedió a bloquear en su firewall la computadora registrada con la dirección IP x.x.x.117.

Rankhorn (FBI) enterado de los hallazgos de Savoy, le pidió a Savoy esperar a tener la orden judicial para hacer el cateo de la computadora en cuestión.

A pesar de ello, Savoy -preocupado- decidió más tarde -en la noche- verificar si el intruso había vuelto a conectarse a Mail2, quizás al alterar su dirección IP, lo cual en efecto así comprobó. Esta vez conectado con la dirección IP x.x.x.120, Savoy elevó su nivel de preocupación, toda vez que el intruso ya sabía que estaba siendo investigado (producto del bloqueo del firewall) y que en cualquier momento podría tomar represalias contra el sistema y echarlo abajo.

El sysadmin concluyó que debía tomarse acción esa noche y no esperar al labor del FBI de la mañana siguiente, porque temía sería demasiado tarde.

Al emplear las mismas credenciales que previamente había conseguido para acceder al computador con x.x.x.117, Savoy ingreso al computador con la nueva dirección IP x.x.x.120, para verificar si se trataba del mismo. A pesar, de ello, y sin tomar borrar o alterar o destruir algún archivo en el computador, Savoy decidió ejecutar una serie de comandos que le permitiesen verificar si el computador x.x.x.120 y el x.x.x.117 eran el mismo.

Savoy concluyó que la máquina x.x.x.120 debía ser sacada de línea inmediatamente para proteger los intereses y seguridad de la universidad, a pesar de que el FBI no tenía aún su orden judicial. Para ello contactó nuevamente al detective Scheller, miembro de la policía universitaria, con quienes desconectaron la computadora en cuestión desde el mismo cuarto de habitación de Heckenkamp, el cuál -además- estaba entreabierto, y sin Heckenkamp dentro.

Al siguiente día, el FBI consiguió su orden de allanamiento, por lo que confiscaron la computadora e inspeccionaron la habitación. Heckenkamp fue acusado de múltiples delitos por acceso intencional a computadoras protegidas sin autorización (18 U.S.C. §,1030(a)(5)(B).

En amparo a la 4ta Enmienda, Keckenkamp solicitó suprimir la evidencia -que él consideraba ilegal- obtenida por:
1) la inspección remota de su computadora,
2) la imagen del disco duro tomada de su computadora la noche del hallazgo (la que había sido de su consentimiento original),
3) la confiscación realizada en consecuencia a la orden de allanamiento del FBI,

Aunque los jueces no negaron su derecho a la expectativa de privacidad razonable de la 4ta. Enmienda, el tribunal de apelaciones finalmente desestimó su pedido, por dos razones esenciales:

1) Porque Savoy no hackeó la computadora de Heckenkamp para sostener evidencias a favor de la investigación federal (FBI) de Qualcoom Corp., Savoy hackeó la computadora de Heckenkamp únicamente para proteger el servidor de correos de su universidad en un momento del negocio que él consideró de alto riesgo el no tomar acciones inmediatas para determinar el equipo real, bloquearlo y entregarlo a las autoridades.

2) Los términos de servicio (TOS/TOU) de la universidad autorizaban el hacking de Savoy. Al respecto, la corte señaló: “Bajo las políticas de la universidad, las cuales consintió Heckenkamp cuando conectó su computadora a la red de la universidad, Savoy estaba autorizado a rectificar situaciones de emergencias que amenacen la integridad de los sistemas informáticos y de comunicaciones del campus… además señaló que… Savoy descubrió a través de su inspección de los registros de la red, sobre los que Heckenkamp no tenía por qué tener alguna expectativa de privacidad razonable, que la computadora que él había bloqueado previamente de la red estaba ahora operando desde un dirección IP diferente, lo cuál en sí mismo era ya una violación a otra política de la red de la universidad”

Resumido de http://cdn.ca9.uscourts.gov/datastore/opinions/2007/04/04/0510322.pdf

J A C K S E C U R I T Y
- JaCk Incidents Now! -

Ética

Friday, November 15th, 2013

Recientemente estuvimos hablando de ética en un repaso interno del CBK. Y nos quedó claro que este tema casi hasta parece tierra virgen en la actualidad en las conferencias de seguridad, especialmente en las que se habla de hacking.

Con la finalidad de demostrar quién es mejor, o cuán grande es su kung fu, muchos hackers deben hacer uso de la irreverencia para venderse bien.

Sin embargo, ese (halo o transpiración real de) arrogancia que le distingue a la mayoría de los que se hacen llamar hackers, a veces les lleva a salirse del libreto de lo que le llamamos “hacking o hacker ético”.

¿Por qué deberíamos salirnos del libreto? ¿Cuándo deberíamos salirnos del libreto?

En JaCkSecurity empresa, tenemos un “código de ética”, y guardamos un capítulo con muchas reglas para dicho fin, pues puede ser extremadamente “bajo de ética” el no controlar el espíritu hacker.

Aunque, la habilidad parece darte el poder para hacer o gozar de algo que el resto no puede o no tiene (acceso), eso no significa que tienes licencia para hacerlo, sobre todo si ostentas una certificación de hackeo ético. Eso sería contradictorio.

Un individuo contradictorio o con doble libreto, no puede ser un individuo de fiar. Y con las disculpas del resto de colegas, no debe ser aceptado en una comunidad (seguridad) donde nos queremos hacer notar por la “confianza”.

En JaCkSecurity creemos que sin confianza en la gente de seguridad, no hay mercado de seguridad legítimo, sino mas bien un mercado sobre el que no podemos construir “buenos” negocios. Por eso, es importante para nosotros la ética.

Escribimos este post, para aquellos colegas y competidores que aún se mantienen en la brecha, luchando contra la falsa ética hacker, contra los irreverentes que patean el tablero, contra los que hackean a sus propias instituciones “éticas” y/o superiores.

A todos aquellos que procuran guardar la ética, los felicitamos.

Debemos redoblar esfuerzos en alzar nuestra ética aún más, para que aquellos que ostentan el título de ética y aún no comprenden su verdadero significado puedan madurar pronto.

Sigamos siendo éticos, y en el largo plazo cocecharemos resultados beneficiosos para todos en esta fascinante industria.

Javier Romero
Chief Technology Officer
JaCkSecurity

Ingeniero social, ¡ya te ví!

Thursday, September 12th, 2013

2012-12-14 19.31.02-400

Fueron las palabras que nuestro falso mensajero leyó de los ojos de una de las ejecutivas que lo vió descender del ascensor común de la torre que minutos antes había burlado satisfactoriamente.

Hoy en día es común las solicitudes de pruebas de ingeniería social física y lógica, para probar la propensibilidad de todos los usuarios y agentes de la seguridad de una compañía. Sin embargo, de qué sirve encrespar la suspicia de un usuario, si previamente no se le ha “entrenado” para responder a incidentes de este tipo. (¿No es mas bien hasta cierto punto injusto? Si su política no lo detalla así)

La ejecutiva que vio a nuestro falso mensajero, de haber sido entrenada, hubiera tomado acciones, y no sólo nos habría observado con ojos de:

“¡ya te ví! si algo sucede no me olvidaré tu rostro, mensajero con ese pingüino navideño”

Eso es sin duda, una buena medida del usuario aislado (se llama juicio y criterio: muchas mujeres lo tienen más desarrollado que los hombres), pero no es una componenda eficaz en un paquete de respuesta a incidentes “entrenado” de los usuarios de una compañía a la que se le prueba con este tipo de ataques de ingeniería social. Es decir, de qué sirve que haya un usuario alerta, si no sabe a quién reportar la misma.

Si Ud. piensa contratarnos para ataques de ingeniería social, primero verifique si su SGSI, y/o su personal entienden y sabe cómo reaccionar a ellos, de otro modo, es como llamábamos a nuestra antigua versión de nuestra familia de pentest (penetration testing):

“un deja vu“. Sí, un deja vu, es decir, un servicio que demostrará algo que prácticamente “ya lo he visto”, o que al menos tenía certero que “podía suceder”.

¿Para qué contratar una empresa que te demuestre lo que ya sabías que iba a suceder? Alguna ideas para no dejar de lado esta pruebas sólo porque si SGSI no lo contemplen, podrían ser:
1) Usar la explotación como un ejemplo para entrenamiento futuro
2) Filmarlo, documentarlo
3) Usar el material videográfico para desarrollar con todos su staff de colaboradores (en su charlas mensuales de concientización) un plan consenzuado para “responder a incidentes” por ataques de ingeniería social.

JaCkSecurity
+51-651-0222

Su SGSI (sistema de gestión de seguridad de la información) debería contar con un plan para esos eventos de interés. Sólo en Perú, la SBS (Superintendencia de Banca y Seguros) exige en su circular desarrollar procedimientos específicos para incidentes específicos, si la ingeniería social le preocupa, y su sector es regulado por SBS, entonces “debe desarrollarlo“. Asi, el próximo “ya te ví” activará la alarma, y el show se acabará antes que nuestro falso mensajero salga de su edificio.

Sembrado de evidencia, una estrategia de detección

Wednesday, July 17th, 2013

 

 

Sembrar evidencia puede ser muy mal visto, y de hecho si lo pretendemos usar en un litigio, hasta podríamos terminar siendo incriminados. Pero, en la práctica muchas empresas lo usan, para detectar agentes del mal, ante incidentes no controlables.

 

En la calle, hay unos dispositivos que no sobrevivirían financieramente si no fueran protegidos por esa técnica de detección efectiva. Aquí un ejemplo menos virtual.

Cuando la privacidad protegió a la música compartida (Verizon, 2003)

Friday, July 12th, 2013

 

En enero del 2003, una corte de distrito de los EE.UU. en District of Columbia ordenó que Verizon (un proveedor de servicio de Internet o ISP) debía sujetarse a las disposiciones del citatorio de RIAA, Recording Industry Association of America, una organización que representa los intereses de la industria de la grabación.

 

La RIAA, en un esfuerzo por detener la música compartida no autorizada en-línea, solicitó a Verizon los nombres de 2 de sus suscriptores quienes supuestamente hicieron disponible en el Internet más de 600 archivos de música protegidos por copyright. Aunque muchos ISPs, como Comcast, y otras universidades cumplían con similares citatorios solicitados por RIAA, Verizon rehusó a liberar los nombres de cualquier de sus suscriptores.

 

 

Verizon argumentó que al hacer eso violaría los derechos de privacidad de sus suscriptores y violarían artículos específicos de la Constitución de los EE.UU. Así, Verizon apeló la decisión de la corte de distrito. El 19 de diciembre del 2003, la Corte de Apelaciones del District of Columbia anuló la decisión de corte inferior, al fallar a favor de Verizon. [Extraído de Ethics & Technology de Herman T. Tavani]

¿Quiénes son más propensos a recibir un DDoS?

Tuesday, June 11th, 2013

[Anonimizado] Era una compañía de e-commerce que a juzgar de algunos andaba al margen de la bahía (Ud. entiende). Cierto día su sitio web fue agredido por un DDoS. Hasta varios días después de sufrir por pérdidas de ventas en línea, el agresor se dio a revelar. El atacante indicó ser del otro latitud, y le solicitó a la empresa de e-commerce $9K por detener los ataques. Estos ataques eran esporádicos y astutamente breves, y se repitieron luego de recibir esta oferta de salvataje. El empresario fue reacio a seder esa suma. Al ver que nadie lo ayudaba, decidió salir del país donde alojaba su sitio de e-commerce. Esta decisión no duró ni 4 semanas desde el inicio de los hechos. ¿Sabría el atacante al tipo de negocio que atacaba?

Era un sitio de venta de medios digitales ilegal. Otros sitios propensos a DDoS:
- Sitios de pedófilos o pedofilia
- Sitios de ideas políticas no aceptadas
- Sitios ilegales o prohibidos
- Sitios que hacen dinero ilegal
- Sitios de e-commerce en general (con algún transfondo de revanchismo)
- Sitios de streaming
- En incluso sitios legales, pero vulnerables a race-conditions o de propensos a venganzas (¿sitios de gaming?)

YES!, la realidad supera al cine

Thursday, June 6th, 2013

Este era un “insider” que trabajaba para una agencia de reporte de créditos de consumo (si ve el enlace, no son muchas de las cuáles conjeturar http://www.fdic.gov/consumers/consumer/ccc/reporting.html). Su responsabilidad era mantener la información almacenada en la base de datos de crédito de consumo. A cambio de dinero que recibía de “outsiders”, ella inflaba la calificación de crédito de los consumidores para permitirles hacerse de préstamos de instituciones financieras de crédito y préstamo. Ella, también, asimiló a otros “insiders” a su conspiración quienes le ayudaron a modificar o borrar datos de historiales de créditos de 178 consumidores a cambio de recibir una parte de su paga. El propósito era fortalecer la confianza crediticia de los consumidores; el impacto de este fraude provocaría que las compañías de préstamos expidieran USD 4.2 millones en nuevos créditos a estos consumidores de mala tacha. (Historia de la base de datos del CERT/CC del libro The CERT Guide To Insider Threats). Quizás le recuerde a la película YES!

En cierto país de Sur América, a fines de la primera década del XXI, una entidad financiera corrompido por error los registros colectados de todo el sistema financiero, al reportar datos del backup del periodo anterior. La medida fue superada por las mismas entidades usuarias, al no poder usar los datos sincretizados del sistema, por lo menos durante el periodo afectado.

Una vez más, comunicar el incidente oportunamente y transparentemente es y seguirá siendo una estrategia importante del plan de crisis (BS25599, ISO 22301).

¿Día Protección Datos Personales?

Tuesday, January 29th, 2013

Violencia (RAE) = Acción violenta o contra el natural modo de proceder.

SB1386

28 Enero

FanPage InPage

6to. Aniversario

Wednesday, July 25th, 2012

Es una bonita idea, pero poco práctica

Wednesday, April 25th, 2012

Es una bonita idea, pero poco práctica
Frase célebre de, Pepito Grillo en Pinocho

Se puede aplicar para metodologías cada vez más bellas.

JaCkSecurity, CTO
Conocimiento, Conciencia y Consultoría

Ud. qué opina

Tuesday, April 24th, 2012