Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Auditoría de software.

No description
by

Pilar Retana

on 15 November 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Auditoría de software.

Auditoría de software.
Tema 4: Principios guías del software seguro.
Reducir las líneas débiles
Reporte del análisis
Tema 3: Código abierto o cerrado.
Seguridad por oscuridad.
Tema 2: Administración de los riesgos en la seguridad del software.
¿De que manera se pueden conocer las contraseñas del cliente y el servidor?

Diseño e implementación de su Arquitectura de Seguridad
Validación en el inicio de sesión (login) del servidor y en los clientes
Esta validación "asegura" que sólo los usuarios o administradores correspondientes sean los que tengan acceso a la aplicación.
Tema 1: Introducción a la seguridad del software.
Un software que cumplas con las epecificaciones de esteta deberá tener/ser:
Auditable y trazable
Monitoreo
Privacidad y Confidencialidad
Seguridad Multiniveles
Anonimato
Autenticación
Integridad
Árboles de Ataque
Se reservaron la información de en qué lenguaje estaba escrito su software. Al hacerlo ejecutable y no tener una extensión determinada se oculta información del software.

No cumple pues no hay una revelación total o parcial de alguna vulnerabilidad del software auditado.
Full Disclosure
Ingeniería Inversa
Nos mostró las llamadas a bibliotecas como lo son las de entrada y salida.
Tan sólo con este simple comando pudimos saber la contraseña del servidor y la del cliente.
Trazable
No cumple pues no hay un registro de accesos y modificaciones
Monitoreo
El software no supervisa la interacción que tiene con el usuario
Ingeniería Inversa.
Otro dato que pudimos ver fue el puerto, 8000, que abre la conexión del chat y que la dirección que utiliza el servidor para atender es el localhost.
Ingeniería Inversa
Muestra los caracteres mostrables de un fichero(no ascii).
Con él pudimos ver todas las cadenas contenidas en el programa.
Reingeniería.
Contando solo con el ensamblador del software, no se puede aplicar este punto funcionalmente
Código Fuente.
Abierto
Los compañeros no proporcionaron en ninguna forma código de su software, es por ello que este punto no aplica.
Cerrado
El código de los compañeros cabe en este rubro debido a que no se nos proporcionó ningún segmento de código del software.
Software Libre
En ningún lugar se especifica ningún tipo de Licencia de software libre. Debido que es un software para auditar, consideramos que aún no aplica.
Falacias del código abierto
En este caso no aplica, pues aún se encuentra el software en auditoría.
Puntos de vulnerabilidad técnica
Ataque de fuerza bruta: al principio se intentó acceder al programa por medio de contraseñas pero no se logró acceder al programa.
Recolección de información
Al usar el comando ltrace obtuvimos:
Contraseña servidor y cliente
La dirección ip y el puerto que ocupa.

También poniendo un Sniffer pudimos ver que cualquier atacante que esté intersectando tramas puede ver la conversación; ya que viaja en claro.
Defensa por pasos o capas
Seguridad a nivel de sistema
Seguridad a nivel de sistema: Al principio no se podía ejecutar los programas ya que el SO asigno permisos, lo único que se tuvo que hacer fue cambiar los permisos en el sistema y se pudo correr el código.

Seguridad a nivel de red
La aplicación abre un puerto para establecer la comunicación y deja a la vista la dirección ip, pero no se dispone a proteger las medidas de seguridad.
Seguridad a nivel de transmisión
Los datos se mandan directos sin ningún tipo de cifrado
Seguridad a nivel de transmisión
Seguramente fallará
Menos privilegios
Este punto fue más tomado como línea de defensa del SO al cambiar los permisos que del propio programa.
Segmentación
No hay una prueba completa de qué tan modulado está el software, pues no se obtuvo el código completo para poder determinarlo
Mantenerlo simple
Al no cumplir con el punto de, seguramente fallará nos da a notar que n est tan simple como podría ser pues se les escapó validar cuestiones indispensables
Promover la privacía
Al menos, no mostrarla:
punto que no es cumplido ya que al ejecutar el comando ltrace nos muestra la comparación de las contraseñas.


Almacenarla cifrada:
punto que no se cumple ya que la contraseña va directa.

Además de
hacer la comparación de la contraseña dentro de los propios programas
, es decir el programa contenía la contraseña de acceso.

Fue un principio no considerado por los compañeros ya que se olvidaron de contemplar las salidas inesperadas de los clientes o la caída del servidor; estos originan que el software se comporte de forma no segura.
Ocultar secretos es difícil
En este punto no se pudo esconder la verdadera naturaleza de su aplicación ya que pudimos ver que el código estaba en c, además de ver cómo transmitía los datos y verlos tal cual por medio de un sniffer
Transparentar el código
Al ser software propietario es un poco más difícil que sea transparente. Usando técnicas de ingeniería inversa pudimos sus características
Usar recursos comunes
El programa cumple con este punto ya que cuenta con librerías y programación estándar en gran parte del código.
Pruebas de Caja Negra
El sistema funciona correctamente, pero... nada es perfecto :S
No se conserva el formato
Hay un ligero error de despliegue de la información cuando enviamos textos muy largos :/
Auditoría de Código Fuente
El código fuente no se pudo obtener al 100% debido a falta de recursos financieros, pero fuimos capaces de obtener el código en ensamblador para poder analizar el comportamiento del software por medio de las llamadas a las funciones que realizaba y así poder ir encontrando vulnerabilidades críticas que dejan expuesto al programa en ciertos estados.
Herramientas de Auditoría de Seguridad de Código empleadas
Decompilador HopperApp
Comandos Linux como ltrace y strings
Editores Hexadecimales como HexCorp y OllyDGB

Técnicas de Código Seguro empleadas
No encontramos ninguna técnica de código seguro durante toda la auditoría sólo las validaciones que hace la aplicación del servidor y del cliente para iniciar la conversación.
Diferentes tipos de pruebas que se realizaron
Consistieron en verificar que el software cumpliera con el funcionamiento para el cual fue hecho, el cual es establecer una comunicación uno a uno mediante un cliente-servidor.

En general logramos realizar las pruebas más importantes en la auditoría como son las pruebas de caja blanca y caja gris, asegurar la mayor cantidad de los niveles de confianza, pruebas de identidad, de validación, pruebas de sistema, seguridad por oscuridad, análisis de vulnerabilidades, entre otras

La comunicación se pierde! :O
Después de llevar a cabo una conversación larga se pierde la comunicación
ya no hay chat :'(
Privacidad y conencialidad
Los mensajes entre los clientes no se cifran y se envíanen forma clara en la red.
Existe un archivo "vitacora.txt" donde se guarda el registro de las conversaciones.
Este archivo se encuentra en la misma carpeta de ejecución del programa y no tiene ningún tipo de seguridad por lo que cualquier persona podría tener acceso a conversaciones pasadas entre los clientes de mensajería.
Niveles de confianza
No se tiene control para la finalizar la sesión
Seguridad multinivel
No está presente, al obtener la contraseña se logran visualizar los comandos.
Funcionalidad probada
Anonimato
Se cumple, de acuerdo a lo visto con los decompiladores y comandos de rastreo no existe ningún tipo de información personal dentro del código del software
Estructuralmente probado
No se comprobó totalmente ya que se necesita la cooperación del desarrollador para conocer la información del diseño y la implementación, se realizaron las pruebas de caja negra pertinentes que deberá de verificar el desarrollador para mejorar y garantizar la seguridad del sistema
Autenticación
Los programas tanto de servidor como de cliente piden una contraseña para acceder a ellos, sin embargo es una contraseña única y no se manejan identidades o usuarios.
Integridad
Probado y verificado metódicamente
No se verificado totalmente ya que no se obtuvo el código completo para revisar su estructura
El programa no hace uso de una base de datos o almacenamiento de ellos por lo que no hay implementación de métodos que aseguren la integridad de los datos.
No hay métodos que aseguren que el mensaje emitido por el cliente llegue al servidor de manera correcta.
Diseñado, probado y revisado metódicamente; Diseñado y probado semiformalmente; Diseño verificado y probado semiformalmente
No es posible verificarlos ya que estos puntos requieren que el desarrollador este presente y se revisen las pruebas ya realizadas con el.
Diseño verificado y probado formalmente
Full transcript