Validación de extensión y código en formularios de carga de archivos

La programación segura no es mas que las buenas practicas o metodologías aplicadas al desarrollo de software, las validaciones de código o en este caso de las extensiones de los archivos que los usuarios suben a través de un formulario diseñado para este propósito no se deben obviar.

Hoy en día es lamentable ver como grandes compañías, continúan omitiendo las buenas practicas, como también las de contar con personas especializadas en seguridad o RedTeam, para las pruebas de seguridad a las aplicaciones que están por salir a producción.

Escribo este articulo, ya que hace casi un año identifique un simple error en un formulario de carga de archivo en una gran compañía de telecomunicaciones en Colombia. la cual permite otorgar un acceso al servidor y posteriormente acceso completo a traves de uno de los usuarios y su llave SSH, el cual notifique en su momento. y es mas lamentable que a dia de hoy esta vulnerabilidad siga presente.

Correo de notificación:

En su momento se recibió una respuesta, pero al parecer las diferentes áreas no se comunican o su dpto de ciberseguridad esta muy verde o simplemente no existe.

A pesar de ser una vulnerabilidad de hace décadas es la falta de validación la que permite que hoy en dia se puedan seguir explotando.

¿Como evitarlo?
Existen miles de forma de realizar validaciones a las extensiones o archivos que se estén subiendo de acuerdo al tipo de archivo y del lenguaje de programación.

1. Hacer uso de .htaccess: Este simple archivo siempre sera un aliado y puede ser una capa mas de seguridad en el caso de contar con mejores opciones. de lo posible siempre ubicar el archivo en la raiz no en la misma carpeta que se desea proteger.
2. Realice validaciones del lado cliente y servidor: Las validaciones no pueden ser en un solo lado, siempre optar por validar tanto del lado cliente como en el servidor, valide el MIME Type, valide el encabezado, compruebe las expresiones regulares del archivo, compruebe las extensiones, limpie las dobles o multiples extensiones
3. Realice listas blancas, nunca lista negras: Las listas negras siempre tendrán como desventajas el tratar de conocer lo desconocido. opte por lo que conoce.
4. Realice pruebas de seguridad: Siempre es bueno contratar los servicios de un tercero para realizar pruebas de ethical hacking cuando el servicio o aplicación saldrá a producción y sera accesible por miles o millones de usuarios.

Read more

Política de SEGINFO bajo el contexto de la norma ISO / IEC 27001

En el  desarrollo de la organización de gestión de seguridad de la información, lo que puedo se puede llegar a decir de la política de seguridad de la información es que ademas de ser un documento exigido por la norma es uno de los documento mas útil e importante en la gestión de la seguridad de la información.

Pero redactar una política de seginfo no es tan facil como parece. Este documento es uno de los primeros requisitos exigidos por la norma ISO 27001, en el marco del desarrollo del SGSI (Sistema de Gestión de la Seguridad de la Información), pero el trabajo técnico y redacción de este no puede ser completamente implementado en los primeros pasos de la construcción del SGSI.

Esta debe ser redactada gradualmente en cada etapa del desarrollo, implementación, monitoreo, evaluación y mejora del SGSI.

NTC-ISO / IEC 27001

De acuerdo con los requisitos de la norma ISO / IEC 27001. La organización debería hacer lo siguiente:
Definir una política SGSI basada en las características de la organización de la empresa, su ubicación, sus activos y tecnología que:

• Incluye el concepto, los objetivos, directrices y principios para la acción en el campo de la seguridad de la información.
• Tiene en cuenta las necesidades de la empresa, los requisitos legales y reglamentarios, y las obligaciones de seguridad contractuales.
• Es coherente con el contenido estratégico de la organización, la gestión de riesgos en el marco de los cuales se ha desarrollado y mantenido el SGSI.
• Establece los criterios para la evaluación y tratamiento de riesgos.
• Es aprobado por la alta gerencia.

NTC-ISO / IEC 27002

Desde el punto de vista de la norma, el propósito de la política de seguridad de la información es:

Asegurar la gestión, apoyo de la gerencia hacia la seguridad de la información de acuerdo con los requerimientos del negocio, las leyes y reglamentos pertinentes.

La alta gerencia debe establecer una dirección clara en línea con los objetivos del negocio y demostrar su apoyo y compromiso con respecto a la seguridad de la información a través del desarrollo y el apoyo de la política de seginfo dentro de la organización.

Se deben establecer contactos con especialistas externos o grupos expertos en seguridad, tambien deben ser incluidas las autoridades competentes, para mantenerse al tanto de las tendencias de la industria, estándares y métodos de evaluación,  para proporcionar los puntos adecuados de contacto al manejar eventos e incidentes de seguridad de la información. Ademas se debe fomentar un enfoque multidisciplinario para la seguridad de la información.

La Política de Seguridad debe ser aprobada por la alta gerencia, debe ser publicada y comunicada a todos los empleados de la organización y los terceros pertinentes a través de la alta gerencia.

Se debe de establecer la responsabilidad de gestión, así como para presentar el enfoque de la organización para la gestión de seguridad de la información. El documento, que establece una política debe incluir disposiciones relativas a:

• Definición de seguridad de la información, sus objetivos generales y ámbito de aplicación, así como los valores de referencia de seguridad como una herramienta que ofrece la posibilidad de compartir la información.
• El apoyo a los objetivos y principios de la seguridad de la información en línea con la estrategia y los objetivos de negocio.
• Un Enfoque para el establecimiento de medidas y herramientas para el monitoreo y control de los efectos, y su aplicación, incluyendo la estructura de la evaluación de riesgos y gestión de riesgos.
• Una breve explicación de los más esencial para la organización en cuanto a las políticas de seguridad, los principios, las normas y los requisitos de cumplimiento, tales como:

• Cumplimiento de los requisitos legales y las obligaciones contractuales
• Concienciar, la educación y la formación en materia de seguridad.
• Gestión de la continuidad del negocio.
• Responsable de las violaciones de la política de SegInfo
• La determinación de las obligaciones generales y específicas de los empleados bajo la gestión de seguridad de la información, incluyendo los incidentes de seguridad de la información.
• Enlaces a documentos que complementan la política de seguridad de la información, como las políticas más detalladas y procedimientos de seguridad para los sistemas de información específicos, así como las normas de seguridad que deben seguir los usuarios.

Esta política de la seguridad de la información debe darse a conocerse a todo personal de la organización de forma relevante, accesible y compresible . de aquí la construcción de ideas y mecanismos para llegar a concienciar a empleados en sus diferentes areas.

Si esta es distribuida a terceros debe existir un apartado a la no divulgación del contenido y protegida toda información bajo acuerdos de confidencialidad.

NTC-ISO / IEC 27003

Este estándar recomienda lo siguiente:

Los datos iniciales a tomar:

• Prioridades para el desarrollo de SGSI de la organización - Objetivos generalizados y Listado de Requisitos.
• Elaboración de descripciones de casos de SGSI para el negocio y el plan del proyecto para su aprobación por la alta gerencia y la aprobación original del proyecto SGSI.
• Alcance y limite del SGSI
• Definición de requisitos de seguridad de la información para el proceso del SGSI.
• Determinación de los activos dentro del alcance del SGSI
• Evaluación de la seguridad de la información.
• Los resultados de la evaluación de riesgos y la selección de objetivos y controles.
• Desarrollar una estructura final de la organización para la seguridad de la información
• Desarrollar un marco para la documentación del SGSI.

Es necesario documentar la posición estratégica de la gestión y administración en relación con los objetivos de seguridad de la información en relación con su uso del SGSI. 

Los ejemplos de la política de seguridad de la información pueden extraerse de libros de referencia, Internet, comunidades de interés y asociaciones sectoriales de la industria. Las declaraciones y consejos se pueden encontrar en los informes anuales, otros documentos de política o documentos  de orientación.

En cuanto a la cantidad real de la documentación en la política puede haber diferentes interpretaciones y requisitos. Esta documentación debe ser resumida para que los empleados comprendan la importancia de la política de la organización. Además, debe mostrar claramente cuáles son los objetivos a alcanzar.

El tamaño y la estructura de la política de seguridad de la información deben fortalecer algunos documentos utilizados en la siguiente etapa del proceso, para la introducción del SGSI.

Para las grandes organizaciones con estructura compleja (por ejemplo, con una amplia gama de diferentes áreas de actividad) puede ser necesaria la creación de una política común y una variedad de políticas de niveles inferiores que se adaptan a las áreas específicas de la actividad.

La política propuesta (Con control de versiones) debe ser sometida a verificación cruzada ,establecida y aprobada por la gerencia. Después del establecimiento de grupos o líder de la operación o entidades similares que aprueba la política de seguridad de la información. Para que luego pueda ser comunicada a cada empleado de la organización de una manera adecuada.

La salida debe ser un documento que describe politicas y objetivos y los documentos aprobados por la dirección de la política del SGSI. Este documento debe ser aprobado nuevamente en la próxima fase del proyecto, ya que depende de los resultados de la evaluación de riesgos.

Politica de ejemplo

El siguiente es un ejemplo de una política de seguridad de la información, mostrando su estructura y un ejemplo del contenido.

Política de seguridad de la información

Resumen de la política

La información siempre debe protegerse con independencia de su forma y el método de su distribución, transmisión y almacenamiento.

Introducción

La información puede existir en muchas formas diferentes. Puede ser impresa o escrita en papel, almacenada electrónicamente, transmitida por correo o por el uso de dispositivos electrónicos, o transmitida de forma oral en el curso del diálogo.

La redacción de este documento es para concienciar  la protección de la información de una variedad de amenazas, diseñado para asegurar la continuidad del negocio, reducir al mínimo el riesgo del negocio y maximizar el retorno de las inversiones y ofrecer oportunidades de negocio.

Alcance

Esta política se aplica a todos los empleados de la organización.

Objetivos

1. Proteger,   preservar   y   administrar   objetivamente   la   información   de   la  organización.
2. Protección de la información confidencial de los clientes, desarrollo de productos y planes de marketing.
3. Preservar la integridad de los registros contable, Backup, etc...
4. El cumplimiento de los controles de acceso a los recursos de red internos de la organización.

Responsabilidades

• Cada ejecutivo es responsable de asegurar que el personal que trabaja bajo su dirección, la protección de la información  de acuerdo con las normas de la organización.
• Los propietarios de activos de información, son responsables de su clasificación, mantenimiento y actualización.
• Es responsabilidad de la alta gerencia la aprobación de este documento.

Políticas relacionadas

Las siguientes políticas detalladas contienen principios y recomendaciones sobre aspectos específicos de seguridad de la información:

1. Sistema de Gestión de Políticas de Seguridad de la Información (SGSI)
2. Política de control de acceso
3. Politica de escritorios y pantallas limpias
4. Politica de software no autorizados.
5. Politica de copias de seguridad o backup.
6. Politicas de seguridad de teletrabajo.
7. Politicas de intercambio de informacion.
8. Gestion y clasificacion de documentacion.
9. Protecion de la privacidad y la privacidad de los datos.

Todas estas políticas son compatibles con:

• Identificación del riesgo, proporcionando los fundamentos de las herramientas de gestión que pueden utilizarse para detectar defectos en el diseño e implementación del sistema.
• Tratamiento de riesgos, ayudando en la definición de los métodos de procesamiento para las vulnerabilidades y amenazas específicas.

Read more

Virusdie - Un AV+FW para sitios web

Este es un nuevo sistema de alerta de malware en sitios web en su momento se encuentra en su fase beta, pero el sistema se ve prometedor para usuarios comunes y no tan comun.

¿Que es Virusdie?

Es un AV y FW en la nube diseñado para tratar automáticamente el malware alohado en los sitios web. Segun los desarrolladores protege contra ataques de re-infección, XSS / SQL Injection y actividades sospechosas, el servicio está dirigido a webmasters, y cualquier propietario de sitios web, que prefieren pasar el menor tiempo preocupandose por la seguridad de su sitio y hechar a un lado el esfuerzo para analizar, encontrar y eliminar las fuentes y consecuencias de la infección. Virusdie encuentra y realiza correcciones de código malicioso automáticamente  en PHP, HTML, JS, archivos del sistema y archivos disfrazado como una imagen (Troyano), y después del tratamiento el rendimiento por el recurso se almacena. El servicio puede trabajar directamente con una variedad de sitios de usuario y no requiere instalación o configuración. Tan solo de una verificacion de la propiedad del sitio con el típico archivo de verificación que debe ser alohado en la raiz del sitio.

EL programa es de origen ruso asi que la web de administracion esta por el momento en ese idioma a dia de hoy la app ha entrado a una fase de suscripción, realmente no me gusta hacerle publicidad a un software de pago. pero la app tiene un buen rendimiento y su uso es relativamente faciil para cualquier usario con pocos conocimientos de seguridad. 

En la app se va agregando los sitios y su respectiva verificación, en sus herramientas de protección incluye un Antivirus y el Firewall, ademas de poder excluir ciertos archivos,

ANTIVIRUS

El antivirus nos muestra información detallada sobre los archivos infectados y desinfectados, su número, tiempo de comprobaciones detalladas y ultima operación del malware, el estado del sitio web se identifica a travez de los populares colores. Rojo - amenazas detectadas. Amarillo - error de sincronización. Se puede activar el tratamiento automático de malware, Si este se encuentra activo cualquier amenaza o malware encontrado serán eliminados automáticamente cuando se analiza el sitio. Virusdie no puede eliminar todas las amenazas que detectan automáticamente. algunas deberan ser sanadas o eliminadas manualmente pero igual sera notificado de un posible malware o inyección de código malicioso.

FIREWALL

Aun en su etapa de pruebas por el momento está disponible  para los sistemas de administración de Joomla, WordPress, Drupal, DLE, Bitrix, MODX, marco Yii, OpenCart, netcat, CS.Cart, AmiroCMS, HOSTCms y Magento y puede reducir la probabilidad de éxito de los ataques DoS, XSS / SQL Injection y descarga archivos sospechosos.

LISTA DE EXCLUSIÓN

Simple, la app hace caso omiso de ciertos archivos durante el analisis del sitio.

ADMINISTRADOR DE ARCHIVOS

Simplemente eso un administrador de archivos.

Fuente

Read more

Autenticacion web basada en certificados SSL (CentOS)

Todos creo que conocemos OpenSSL la navaja suiza del cifrado y el uso que se les da a los certificados SSL al dia de hoy para proporcionar una conexión segura HTTPS.

En este post abarcaremos el uso de estos certificados para autenticarnos en un sitio web. Crearemos un sitio web que solo sea accedido o sea visible para ciertos clientes o personas que posean el certificado llave(Publica).

Este post se ha generado para aquellos que han tenido problemas de realizar esta tarea en servidores CentOS. ;)

Escenario:

OpenSSL
Mod-SSL

Apache
CentOS 6.3

Instalación de OpenSSL

Pasaremos a instalar OpenSSL y el respectivo modulo SSL para el servidor web (APACHE) en nuestro servidor y crearemos los certificados necesario. el modulo es necesario para que apache interactué con Openssl y este viene los repositorios de Centos 6.3 y también en EPEL.

[root@localhost ~]# yum install openssl

[root@localhost ~]# yum install mod_ssl

Una vez tengamos instalado OpenSSL y el modulo SSL para apache pasaremos a crear los certificados (Privada y publica). si sera un cifrado asimetrico, ya que es conveniente para el sistema plantado.

[root@localhost ~]# openssl genrsa -des3 -out server.key 2048
Generating RSA private key, 2048 bit long modulus
............+++
...............................................+++
e is 65537 (0x10001)
Enter pass phrase for server.key:
Verifying - Enter pass phrase for server.key:

Como ven en el comando estamos solicitando que nuestra clave sea de 2048 bits, una vez ejecutado el comando antes de generar la clave privada nos solicitara ingresar una contraseña, esta es para proteger el archivo de posibles descifrado.

Ya que tenemos nuestra llave privada pasaremos a crear el certificado a firmar y llenarlo con los datos necesarios del servidor, dominio o empresa. este certificado sera el identificador de nuestro servidor, dominio o empresa.

[root@localhost ~]# openssl req -new -key server.key -out server.csr
Enter pass phrase for server.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:CO
State or Province Name (full name) []:COLOMBIA
Locality Name (eg, city) [Default City]:BOGOTA
Organization Name (eg, company) [Default Company Ltd]:ANTONIOJORZ
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

El comando nos solicitara la contraseña quemada en la llave privada para acceder a el. durante el proceso de creacion se nos solicitaran los datos con los cuales se va identificar nuestro sitio web y/o servidor. como mi servidor es local y obviamente lo voy autofirmar posteriormente, lo llenare con cualquier dato. en caso que se genere en producción el campo "Common Name" debe estar quemado el dominio o subdominio del servidor.

Autofirmamos el certificado
una vez creado nuestro certificado indentificador llega el momento de firmarlo en nuestro caso como mencione anteriormente no sera un ente quien lo firme, sera autofirmado por el server esto debido que es para fines educativos en un ambiente local..

Primero creamos nuestro propio CA (Certification Authority)

[root@localhost ~]# openssl req -x509 -newkey rsa:2048 -keyout ca.key -days 730 -out ca.crt
Generating a 2048 bit RSA private key
.......................+++
.............................+++
writing new private key to 'ca.key'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:CO
State or Province Name (full name) []:COLOMBIA
Locality Name (eg, city) [Default City]:BOGOTA
Organization Name (eg, company) [Default Company Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:
Email Address []:

Creamos nuestro propio certificado de autoridad de confianza con validez de dos años. Este certifica do ca.crt sera quien firme el certificado de nuestro servidor web.

Firmamos el certificado con el CA

[root@localhost ~]# openssl x509 -req -days 365 -CA ca.crt -CAkey ca.key -CAcreateserial -in server.csr -out server.crt
Signature ok
subject=/C=CO/ST=COLOMBIA/L=BOGOTA/O=ANTONIOJORZ/emailAddress=frenyman@gmail.com
Getting CA Private Key
Enter pass phrase for ca.key:

Con el comando anterior estamos firmando el certificado del servidor web con nuestro CA con una validez de 1 año, este comando nos generara un certificado CRT.

Generación de certificado Cliente

Como decía al comenzar este post, lo buscado es que solo ciertas personas puedan ver nuestro sitio web y para eso crearemos este certificado cliente, como llave de acceso
El proceso es exactamente el mismo que los anteriores.

[root@localhost ~]#openssl genrsa -des3 -out client.key 2048
[root@localhost ~]#openssl req -new -key client.key -out client.csr
[root@localhost ~]#openssl x509 -req -days 365 -CA ca.crt -CAkey ca.key -CAcreateserial -in client.csr -out client.crt

Ya con esto tenemos nuestro certificado cliente.crt y sus respectiva llaves ahora debemos pasar a unir estos archivos y convertirlos en único fichero con formato PKCS#12.

[root@localhost ~]# openssl pkcs12 -export -in client.crt -inkey client.key -out client.p12
Enter pass phrase for client.key:
Enter Export Password:
Verifying - Enter Export Password:

El comando al ejecutar solicita la contraseña para acceder a la llave cliente. y luego una contraseña para el certificado, yo la dejare nula.


Preparando Apache y ModSSL

Primero editamos el archivo de configuracion de SSL para agregar los nombres y/o path de los certificados creados.
Abrimos el archivo /etc/httpd/conf.d/ssl.conf
Buscamos
SSLCertificateFile 
SSLCertificateKeyFile 
Y editamos con los nombres de los certificados generados en nuestro caso "server"

SSLCertificateFile /etc/pki/tls/certs/server.crt
SSLCertificateKeyFile /etc/pki/tls/private/server.key

Ahora debemos indicarle ha Apache que debe solicitar dichos certificados.
Estando en el mismo fichero buscamos SSLVerifyClient y SSLVerifyDepth
descomentamos y editamos de la siguiente manera

SSLVerifyClient require
SSLVerifyDepth  1

Donde indicaremos con la primera variable que se requiere de un certificado SSL para poder ver el sitio web y con la segunda variable estamos pasando el parametro del numero de certificadoras autorizadas que firmaron nuestro certificado, en nuestro caso 1 ya que fue autofirmado y no hay mas de 1 ente intermediando.

Ahora buscamos lo siguiente SSLCACertificateFile.
descomentamos y editamos el nombre de nuestro certificado de confianza, en nuestro caso CA.crt

SSLCACertificateFile /etc/pki/tls/certs/ca.crt

Guardamos y reiniciamos Apache.

[root@localhost ~]# service httpd restart
Stopping httpd:                                            [FAILED]
Starting httpd: httpd: Could not reliably determine the server's fully qualified domain name, using localhost.localdomain for ServerName
Apache/2.2.15 mod_ssl/2.2.15 (Pass Phrase Dialog)
Some of your private key files are encrypted for security reasons.
In order to read them you have to provide the pass phrases.

Server localhost.localdomain:443 (RSA)
Enter pass phrase:

OK: Pass Phrase Dialog successful.
                                                           [  OK  ]

Apache nos solicitara la contraseña quemada en la llave privada del servidor.

Si requieren que no se las solicite cada vez que reinicien deben decifrar con openssl la llave con la misma contraseña quemada. claro esta que esto se considera un riesgo de seguridad.

Una vez reiniciado el servicio de Apache. ingresamos al navegador y digitamos la ip del servidor bajo el protocolo HTTPS.

al intentar ver la web veremos que no es visible y requeriremos del certificado de autenticacion cliente "cliente.p12" el que fue anteriormente empaquetado.

Si nos encontramos en sistemas windows simplemente hacemos doble clic en el archivo cliente.p12 y siga los pasos de importación. este importara y aplicara (Funcional para navegadores chrome e IE)

para navegadores basados en firefox se debe agregar independientemente. Para importarlo simplemente nos vamos a:
Menu-->Opciones-->Avanzado-->Certificados-->Ver Certificados -->Sus Certificados

una vez importado el certificado actualizamos navegador este nos solicitara selecionar un certificado como autenticacion.

Una vez selecionado el Certificado de autenticacion este nos permitira ver nuestra web.

Saludos.

Post basado en la fuente y reformado para CentOS.
Fuente

Read more

Prueba de carga y estrés con Jmeter

Performance Testing o prueba de rendimiento tiene como objetivo eliminar “cuellos de botella” en la ejecución de una aplicación y poder determinar una medida aceptable para su funcionamiento,

Con esa simple definición podemos conocer profundamente la intención  de realizar este tipo de pruebas a nuestros servicios o aplicaciones y tener una perspectiva de su funcionamiento,

Load Testing o prueba de carga es un proceso progresivo en el cual se va aumentando la carga (usuarios, transacciones, peticiones) en el sistema.

Stress Testing o prueba de estrés en esta se busca forzar a una falla en el sistema excediendo los recursos y verificar su comportamiento ante esta situación.


¿Por qué utilizar este tipo de pruebas?

Por que nos ayuda a encontrar fallas en los servicios y tener una perspectiva de su solidez antes de entrar a producción, las pruebas de estrés aumentan la posibilidad de encontrar errores de concurrencia o problemas de memoria (Buffer Overflow)

¿Cual es la diferencia entre los test load y stress?

Normalmente se ven como sinónimos, sin embargo el concepto de pruebas de estrés abarca mas allá que un test de carga, y nos ayuda a determinar el comportamiento de un sistema bajo un nivel de exigencia (Stress) mayor al que es capaz de manejar, de ahí el origen de su nombre.

En estos Test el sistema se satura y los escenarios más comunes suelen ser:

• El sistema apila y desecha peticiones
• El sistema responde con una latencia a las peticiones.
• El sistema colapsa y queda fuera de línea. (DOS)

En términos simples:
Load Testing = Gran cantidad de usuarios
Stress Testing = Demasiados usuarios, demasiados datos, demasiadas peticiones, poca memoria, poco espacio

Los ataques DOS o DDOS están basados en este principio inundan de peticiones el objetivo llevando a un nivel de estrés y si no se encuentra bien protegido el objetivo colapsa.

Test

Normalmente este tipo de pruebas suelen ser usados en servidores web's llámese Apache, Nginx, lighthttpd, Cherokee o incluso IIS. pero tambien puede usar el mismo principio para pruebas de software (Desktop) o cualquier sistema de información.

Todos estos servidores web en su configuración por defecto trabajan excelente pero los sitios web albergados pueden convertirse en una fuente de carga estresante para el servidor y forzando a colapsar los servicios.

Existen diversas formas tanto manuales, y herramientas automatizadas para realizar este tipo de pruebas. algunos automatizados son Jmeter, siege, ab (ApacheBench),

Nuestro ambiente de simulación es el siguiente:

• Servidor CentOS 6.3
• Apache 2.2.15 (Configuración por defecto) lo invito a ver el hardening de esta app
• PHP 5.3.3

Simulare un esfuerzo con la herramienta Jmeter de Apache con el se pueden realizar pruebas de carga y stress sobre servidores, esta herramienta requiere una version java >= 1.6:

• Web - HTTP, HTTPS
• SOAP
• BD via JDBC
• LDAP
• JMS
• Mail - SMTP(S), POP3(S) y IMAP(S)

JMeter puede hacer peticiones distribuidas puede encontrar mas info aqui
Una vez tenga instalado el Jmeter ejecutamos el script Jmeter ubicado /bin dentro de la carpeta de Jmeter  esto si quiere usar el modo GUI.

Al ejecutarlo nos encontraremos con la GUI  en el cual nos solicita crear un plan de Pruebas :

Un plan de prueba se compone de una secuencia de componentes que determinaran cómo se simulará la prueba de carga. Ahora podemos añadir elementos a este plan de pruebas. jMeter permite muchos tipos diferentes de peticiones a practicar como mencione anteriormente, nosotros nos limitaremos al HTTP


1. Agregamos un Thread Group

• Clic derecho en Test Plan >Add>Threads (Users) >Thread Group 

Thread Group tiene tres propiedades particularmente importantes que influyen en la prueba.

• Number of Threads (users): Numero de usuarios a simular
• Ramp-Up Period (in seconds): Tiempo que Jmeter distribuira los Threads
• Loop Count: El numero de veces que se ejecutara la prueba.

2. Agregamos un HTTP Request Defaults

• Clic derecho en Test Plan >Add>Config Element >HTTP Request Default 

Este elemento es utilizado para establecer los valores predeterminados para las peticiones HTTP en nuestro plan de pruebas.

En este elementos llenamos los datos del servidor solicitados para la prueba. 

3. Agregamos el elemento HTTP Request Sampler

• Clic derecho en Thread Group >Add>Sampler >HTTP Request

Debemos tener en cuenta que no es necesario especificar los datos del servidor en este elemento debido a que ya se ha especificado en el elemento de HTTP Request Defaults.

Nota: Si desea agregar más solicitudes HTTP como parte de la prueba, se debe repetir este paso. Cada Thread llevará a cabo todas las peticiones en este plan de pruebas.

3. Agregamos el elemento View Results in Table Listener

• Clic derecho en Thread Group >Add>Listener>View Results in Table

Con este elemento podemos visualizar la interacción de Jmeter hacia nuestro aplicativo ejerciendo la prueba una vez ejecutada la prueba.

la tabla refleja la iteracion del HTTP Request.

de esta manera podemos realizar simulaciones de estres y podemos ir forzando y ejerciendo mas iteraciones a medida que veamos el comportamiento del sistema de información.

Proceso de optimización

Como cualquier tema en auditoria despues de realizar estas pruebas, el sysadmin debe pasar a un proceso de optimizacion para solucionar los fallos encontrados en el sistema. el proceso difiere de acuerdo al sistema de informacion por ejemplo si el sistema se trata de un servidor de base de datos se debe ejercer una optimizacion a su configuración por ejemplo, caché de consultas, contemplar mayor recursos, analizar velocidad de escritura en disco, caché de objetos para evitar lecturas desde base de datos (memcached, APC, etc). Utilización de sistemas de caché estático (nginx como proxy inverso, Varnish, etc).
Si se trata de un servidor web: realizar un hardening al servidor web, denegar las multiples peticiones, Mantener una bitacora firewall (Para muchos algo de poca relevancia - pero es de lo mas importante para un sysadmin), ejercer el uso IPS e IDS,

Read more

Pentesting Aplicaciones Web (Burp suite)

Burp Suite es una herramienta mas que conocida por los pentester, en estos dias estaba haciendo uso de ellas en auditoria de aplicaciones web y recordé que no había realizado un post de esta increíble herramienta. la cual para mi gusto es mas que buena y me ahorra tiempo a la hora de realizar Script. claro esta en la versión Pro. ya que la versión free es limitada sobre todo en la velocidad de procesar los ataques.

Burp Suite es una aplicación desarrollada en java la cual podemos encontrar en versiones gratis y de paga. es una herramienta desarrollada explicitamente para pruebas de seguridad en aplicaciones web.

Los componentes de Burp Suite mas destacados son:

• Proxy: Actua como un proxy haciendo como un man in the middle, lo que le permite interceptar las peticiones al navegador, y asi inspeccionar y modificar el tráfico entre el navegador y la aplicación de destino.
• Spider: con reconocimiento de aplicaciones, para el rastreo de contenido y funcionalidad.
• Scáner: Disponible en la versión de paga, escanea el sitio en busca de vulnerabilidades.
• Intuder Tool: Con este componente podemos realizar ataques personalizados y automatizados para explotar vulnerabilidades. 
• Repeater: El repetidor es una herramienta sencilla la cual se puede utilizar para modificar las solicitudes al servidor y volver a enviar.

Vamos a poner a prueba esta herramienta con los 4 desafíos gratuitos de pentesting-academy

Challenge 1: Form Bruteforcing Solutions

En el primer reto del Web-Lab nos encontramos con un login, en el cual nos dan pista para el ataque nos dicen que:

1. El dominio es: PentesterAcademy.com
2. Los usuarios posibles son: jack, admin
3. Y de que la posible contraseña es de 5 caracteres y solo contiene las letras x,y,z en minúscula

Bueno ya teniendo esta información nos vamos a Burp Suite, en mi caso estoy realizando las pruebas en Kali Linux, El cual ya trae integrada la herramienta en su versión gratuita.

En la pestaña Proxy de Burp Suite podemos observar que trabaja en localhost (127.0.0.1) a través del puerto 8080. estos datos los configuramos en nuestro navegador.

Una vez ya configurado podemos captar la comunicación de nuestro navegador. Burp suite intercepta antes de enviar los datos entre el navegador y la aplicación web. ya interceptada puedes validar datos, modificar o simplemente hacer clic en Forward. para que Burp Suite permita seguir la comunicación.

Para el primer laboratorio digitare en el login un nombre de usuario de los que nos dan que seria admin@PentesterAcademy.com y contraseña cualquier cosa solo como prueba.

Una vez interceptada la comunicación esta la podemos observar en la pestaña intercept de burp suite.

Como ven en la imagen la petición se hace a través del método GET y muestra en texto plano lo enviado. esta información la envió al componente intruder.

En este componente nos encontraremos las siguientes pestañas:

Target: Nos muestra información del objetivo y nos permite modificar dominio y puerto

Positions: Nos permite configurar las variables ha tener en cuenta en el Payloads.

Payloads: Nos permite configurar la transmisión de los datos a proporcionar a la aplicación.

Option: Permite realizar ajustes que controlan si intruder actualiza los encabezados de solicitud configurados durante los ataques.

Nos vamos a la pestaña Positions. selecciono el valor del campo password y hago clic en el botón add$ esto con el propósito que solo cambien los valores de la contraseña ya que conocemos el usuario. y el tipo de ataque seleccionamos sniper.

Ahora en Payload. configuremos nuestros datos a enviar.

En Payload Type seleccionamos Bruter Forcer ya que lo que vamos a realizar para este caso es un ataque de fuerza bruta. introducimos nuestros tres caracteres a permutar (x,y,z) con un mínimo y máximo de 5 caracteres. una vez configurado nos vamos al menú intruder --> Start Attack.

Una vez comienza el ataque probara las 243 permutaciones posibles de nuestros caracteres. en este caso todas los estados seran de 200 asi que nos guiaremos por la longitud (length).

como ven el length de esta varia hacemos doble clic y en response-->render nos muestra que hemos entrado con exito con las credenciales:

username: admin@PentesterAcademy.com

password: zzzxy

Challenge 2: HTTP Form Attacks Reloaded  

En el segundo desafió tenemos que pasar por alto dos tipos de autenticacion uno va por GET y el otro es HTTP Basic Authentication.

Al igual que el anterior nos dan pista, el mismo domino que el anterior, los usarios son admin y nick, la complejidad de la contraseña es de 5 caracteres en los cuales solo incluye a,s,d.

Usernames: nick, admin

Si caemos en el error y empezamos el ataque con fuerza bruta configurando todo los parámetros como lo hicimos anteriormente notaremos, que el metodo GET no funcionara por la recarga y validación del formulario HTTP Basic Authentication. y no podemos usar el metodo POST el cual usa el segundo método de autenticación. ya que el primero no lo permitira. asi que optamos por usar el metodo de cabecera HEAD. y asi realizar un Bypass al reload login.

Y podemos ver la contraseña fluir con la URL de éxito.

Challenge 3: HTTP Basic Authentication Attack (Easy)

En esta ocasión la autenticacion del reto esta basada por el método POST. A traves de HTTP Basic Authentication.

lo primero que podemos notar es que las credenciales viajan codificadas, (No Cifradas) en Base64, .

Enviamos lo captado a intruder, y dentro seleccionamos el texto y haciendo clic derecho  Convert Selection --> Base64 --> Base64 decode. podemos decodificar el texto y podemos observar lo digitado anteriormente.

Aun teniendo el texto seleccionado hacemos clic al boton Add$ dado que en esta ocacion tanto la clave como el usuario viajan como un solo texto Observando : que son divididos por ":" para su identificación.

Nos dirigimos a Payloads y configuramos nuestros parámetros de la siguiente manera:

Seleccionamos Bruter force como tipo de ataque nuestra permutaciones que nos dan como pista. Y añadimos como reglas un prefijo "admin:" que seria el usuario con los dos puntos de division de campos. igualmente como vimos que esto viajaba codificado en Base64. debemos igualmente enviarlo codificado de la misma manera, para eso lo añadiremos como regla de Encode.

Y en Payload Encoding. quitaremos el símbolo = ya que no es usado por Base64. Y por ultimo lanzamos nuestro ataque con Burp Suite. dándonos como resultado lo siguiente:

Donde nos arroja un Status 200 El cual en HTTP es un estado de OK. seleccionamos todo el texto en Authorization Basic, hacemos clic derecho y lo enviamos a decoder para decodificarlo en Base64 y obtener el texto plano.

Success, nuestras credenciales de acceso serian admin, aaddd

Challenge 4: Basic Authentication and Form Bruteforcing (Intermediate)

En este reto existen dos tipos de autenticacion y tenemos como pista los usuarios nick y admin.
Para la autenticacion html form nos encontramos con 5 caracteres y hacen solo uso de los caracteres m,n,o en cuanto a la otra autenticacion contiene los caracteres v,i,e de igual tamaño. ambos en minúscula.

Comenzamos a capturar y lo primero que notamos en la cabecera es que primero se valida el HTTP Basic y luego HTML Form. así que el orden a atacar seria primero el HTTP Basic en Base64 guardar/recordar las credenciales y luego ir por el HTML Form.

Ya teniendo esta analogía apliquemosla en Burp Suite. Nos vamos a Payloads y configuramos nuestro primer ataque para el HTTP Basic. asi que debemos configurar como en el Challenge 3. una vez ya configurado efectuamos el ataque.

aplicando el decoder Base64 podemos observar que nuestras primeras credenciales son: nick:vivvv

Una vez ya tengamos nuestras primeras credenciales, las quemamos en la cabecera y proseguimos  a por la segunda donde todas nos arrojaran Status 200, debido al OK de la primera.

Efectuamos el ataque y Eureka!

Nuestras segundas credenciales son:
email: admin@pentesteracademy.com
password: nnomm
como ven nuevamente las identifique por la longitud (length) debido al estatus OK de todas. ya con esto hemos pasado todos nuestros Challenge gratis de pentesteracademy con tan solo una herramienta.

Espero que les haya gustado hasta otra ocasión.

Read more

Bypass Safe Exam Browser

Hace unos días me encontraba por realizar un examen en una plataforma moodle cuando entro para realizar el examen me encuentro con un mensaje en moodle donde me da el aviso que el examen solo podía realizarse en un navegador seguro.. realmente me pareció algo gracioso para un examen para personas con un grado de conocimiento en seguridad de la información.

Inmediatamente me pico el bicho de seguridad de conocer sobre ese supuesto navegador seguro y como saltármelo.

el navegador seguro era un modulo de moodle llamado Safe Exam Browser es un entorno supuestamente seguro donde los estudiantes pueden realizar los examenes con solo una instancia de un navegador al parecer basado en firefox  de forma segura. El software cambia cualquier ordenador en un puesto de trabajo seguro. Regula el acceso a los servicios públicos, como funciones del sistema, otros sitios web y las aplicaciones y evita recursos no autorizadas que se utilizan durante un examen y la denegación de pulsaciones de teclas de función y combinaciones.

Lo primero que se me vino a la mente fue descargarlo y abrirlo para ver que era.. ps realmente tomaba "posesion" del sistema y solo daba la impresión de generar un escritorio con la instancia de su navegar y nada mas que un boton de salir.

Al ser un navegador fácilmente recordamos que todos usan un User-Agent. el cual ubico rápidamente en la misma web.

May 23, 2013
New Bugfix Version of SEB Windows 1.9.1 Final Release fixes a bug in the XULRunner browser component. The User Agent String in the "config.json" file has been changed from "SEB" to "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0 SEB" because some web pages checked it and complained.

Simplemente con cambiar el User-Agent. de tu navegador favorito llámese firefox o chrome podemos ingresar simulando estar en SEB.

El complemente USer-Agent-Switcher el cual se encuentra tanto para firefox como para chrome nos permite cambiar rapidamente el User-Agent por uno de los ya establecidos o generado como es el caso.

Una vez ingresado el nuevo User-Agent regreso a la web y así de fácil fue saltar este supuesto modulo de seguridad.

El cual me parece que es una buena idea plantar la honestidad en los alumnos al presentar exámenes pero el desarrollo aun me parece muy crudo para implementarlo en exámenes en alumnos con niveles básicos de informática.

Read more