Archive for the ‘Knowledge’ Category

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 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

Promoviendo: SANS SEC 401 en Lima, Peru

Wednesday, April 11th, 2012

SANS Books (401, 503, 504)

Dear Future SANS Alumni

Experience SANS training right here in Lima with a training course from
the SANS Mentor Program – the most affordable live, in person training
we have to offer.

Starting June 2nd, The SANS Mentor Program will be bringing Security
401: SANS Security Essentials to Lima Peru. No need to travel, no need
to be out of the office for a week. With local classes in a multi week
format, you can experience world class SANS training at home!

Meeting each week, local SANS Mentor Javier Romero will teach you the
language and underlying theory of computer security. At the same time
you will learn the essential, up-to-the-minute knowledge and skills
required for effective performance if you are given the responsibility
for securing systems and/or organizations. You’ll be able to show off
your knowledge the next day at the office!

******
For complete event details visit http://www.sans.org/info/101054

SECURITY 401: SANS Security Essentials
Start Date: Saturday June 2, 2012. Class meets every Saturday over 4 weeks.
Details and tuition visit: http://www.sans.org/info/101054

******
What is the SANS Mentor Program: Mentor is SANS’ program for learning
our courseware in multi-week classroom sessions right in your home town.
Mentor gives you time to absorb and master the same material taught at
SANS six-day conferences, with the guidance of a trained and GIAC
certified network security professional.

SANS Mentors are hand-selected from students like yourself who hold GIAC
Certifications with an 85% or better. Mentors are evaluated and trained
by the SANS Mentor team which consists of industry professionals and
SANS Certified Instructors such as John Strand and Eric Cole. Mentors
are locally based, which allows for these instructors to serve as IT
leaders in the community. Each week the local Mentor will answer
students’ questions and assist them with hands on labs and exercises
during the class. Mentor courses give you the opportunity to participate
in SANS training without the expense and inconvenience of travel or
being out of the office during the workday.

I hope you can join this class in Lima this June and earn your GSEC
Certification in 2012!

Kindest regards,

Stephen Northcutt – President
The SANS Institute

RDP, MS12-020, 3389/tcp y sistemas sin firewall

Tuesday, March 20th, 2012

En comunicado exclusivo a clientes, la semana pasada alertamos de la vuln. MS12-020 (que permite ejecución de código remoto) CVSS 9.3 (HIGH).

Luego de eso, hallamos que no todos los servicios RDP son internos, sino
-en algunos casos- fuera del alcance del firewall, por lo tanto, compartimos algunas porciones de nuestra misiva no pública, al público lector de este blog:

1. Sugerimos volver a revisar su perímetro, o sus otras redes de acceso
a Internet. Existen variados ejemplos de sistemas con RDP fuera del ámbito del firewall.
Ejemplos removidos

2. Si ha tenido o tiene sistemas públicos con RDP (Remote Desktop
Protocol), no se fíe de instalar parche de MS12-020. Es probable que su
sistema ya haya sido visitado por ataques de diccionario o fuerza bruta, antes que se conociera el MS12-020, incluso antes que su researcher lo divulgara a Microsoft. Realice una inspección minuciosa.
Detalles removidos

3. Aquí la moraleja: No por el hecho de no tener el puerto 3389, todo es
bueno. En general, un intruso puede aprovechar de múltiples formas el
tomar un sistema no protegido por firewall.
Detalles removidos

4. Finalmente, adjuntamos el update del 3389 de DSHIELD, donde la
desviación observada en Chile, también se notó en Argentina el día
sábado.
Detalles removidos



Otras estadísticas públicas (Fuente: ISC.sans.org)

JaCkSecurity
Conocimiento, Conciencia y Consultoría

http://www.jacksecurity.com

Despedida a Harold F. Tipton

Tuesday, March 20th, 2012

El privilegio de conocer a un gran arquitecto de la carrera de la seguridad

Harold F. Tipton

Tuve la oportunidad de conocer a este célebre personaje, no como mentor, sino como compañero de aula. Seguro, claro, mientras observaba que tan bien Kevin Henry nos instruía en el 3T del CISSP en el 2007, dentro del Mall of the Americas.

Durante algunos días, Harold no pasó desapercibido y pudo compartir de tiempo en tiempo los motivos detrás de la inclusión de algunos temas en el Common Body Knowledge (CBK), a la vez que se podía comprender el encaje de las piezas generales detrás de su organización.

A más de ello, también tuve el privilegio que Harold me juzgara como instructor, así que no dejo más que sentir su partida.

Con su trabajo, Harold F. Tipton ha modelado la vida de los profesionales de seguridad desde 1989, y quizás sea uno de los pioneros en aglutinarnos de la manera más ética y unificada posible, para que demos vida a un sin número de existentes líneas y especialidades en la seguridad de la información de las que gozamos hoy.

“Es nuestro deseo que Ud. recuerde a este diseñador de la profesión”

Despedida a Harold F. Tipton, ilustre personaje que trazó el camino de miles.

Javier Romero, CTO
Certified Information Systems Security Professional, CISSP 39589

JaCkSecurity
Conocimiento, Conciencia y Consultoría