Sunday, September 6, 2009

Damn Vulnerable Web App

Ryan Dewhurst desarrollador del DVWA (Damn Vulnerable Web App) ha liberado hoy una nueva versión (1.0.5), de esta excelente herramienta para testear diferentes vulnerabilidades web.

logo1q Damn Vulnerable Web App

4v4t4r ya nos había comentado sobre esta aplicación que tiene como finalidad ofrecer a los profesionales, estudiantes e investigadores en seguridad informática un conjunto de utilidades con las cuales podemos exploter y entender un amplio grupo de vulnerabilidades web.

Algunos cambios en esta nueva versión:

  • Se re escribió completamente el codigo.
  • Se rediseño completamente el aspecto de la aplicación.
  • Se agrego la vulnerabilidad CSRF.
  • Ahora las vulnerabilidades XSS se almacenan.
  • Se agrego la vulnerabilidad Full Path Disclosure.
  • Cuenta con un nuevo sistema de logueo.
  • Ahora tiene manejo de secciones.
  • Algunos bugs arreglados.
  • Se implemento el PHPIDS.
  • y muchas cosas mas…

Si te intereso la pasada versión del Damn Vulnerable Web App, no dudes en descargar esta nueva versión los dejo en compañía de este vídeo tutorial de instalación de Damn Vulnerable Web App.

Descargar Damn Vulnerable Web App

Mas Información:
Sitio Oficial de Damn Vulnerable Web App

Envíale este Articulo a Tus Amigos

Fuente: DragonJar.

Saturday, September 5, 2009

Microsoft minimiza la vulnerabilidad de SQL Server

Microsoft pone en duda la gravedad de una vulnerabilidad en su servidor SQL de base de datos que los investigadores de seguridad dicen expone contraseñas administrativas. La vulnerabilidad, descubierta por Sentrigo, puede ser explotada remotamente en SQL Server 2000 y 2005.

Microsoft minimiza el defecto de seguridad en SQL Server que podría ser explotado por alguien con privilegios administrativos para ver las contraseñas de los usuarios que están sin cifrar.

La vulnerabilidad se descubrió el año pasado por el fabricante de seguridad de base de datos Sentrigo; cuando uno de sus investigadores notó que la cadena única de su contraseña personal era visible en la memoria. Desde entonces, se contacto a Microsoft y se desencadeno una de idas y vuelta entre Sentrigo y Microsoft, que sostiene que la vulnerabilidad no es un problema porque se requiere acceso administrativo.

Mientras funcionarios de Sentrigo admiten que acceso administrativo es necesario para un explotar al trabajo, también sostienen que muchas aplicaciones están desplegadas con privilegios administrativos, lo que significa que hackers podrían utilizar una inyección de SQL y con esta vulnerabilidad para acceder a contraseñas administrativas.

"Las contraseñas utilizadas para conectarse al servidor del MS SQL se almacenan en memoria con texto claro" explicado por el CTO de Sentrigo, Slavik Markovich. "Estas no se borran hasta que se reinicia el servidor del SQL, así que puede en quedar en memoria durante semanas o meses en ambientes de producción. Es algo fácil descargar la memoria y ver su contenido en busca de nombres de usuario y contraseñas".

En el caso de SQL Server 2000 y 2005, los atacantes puede explotar la situación remotamente. Hay algunos procesos de mitigación para los usuarios de SQL Server 2008 porque Microsoft eliminó la utilidad DBCC. Sin embargo, con conexiones locales todavía se puede explotar.

Pese a ello, Microsoft sostiene que la vulnerabilidad es mucho ruido y pocas nueces.

Microsoft ha investigado a fondo reclamaciones de vulnerabilidades en SQL Server y encontraron que estos no son vulnerabilidades que requieren de Microsoft emita una actualización de seguridad. Como se ha mencionado por los investigadores de seguridad, en el escenario en cuestión, un atacante necesitaría derechos administrativos en el sistema atacado.

"Un atacante que tiene derechos administrativos ya tiene completo control del sistema y puede instalar programas; ver, cambiar o borrar datos; o crear nuevas cuentas con plenos derechos de usuario", agregaron desde Microsoft.

Si bien los administradores pueden normalmente restablecer una contraseña de usuario si es necesario, mejores prácticas de seguridad no permiten incluso a los administradores ver la verdadera contraseñas de otros usuarios, oficiales de Sentrigo dicen: este es un problema aún mayor ya que muchas empresas necesitan cumplir con diversas normas y reglamentos que exigen estricta separación de funciones, algo que es claramente violado por compartir todos las contraseñas de los usuarios con los administradores.

En respuesta a la situación, el fabricante de seguridad ha publicado un utilitario gratuito para borrar estas contraseñas. La utilidad puede ser descargada a partir de hoy de la pagina Web de Sentrigo.

Fuente: SeguInfo.

Friday, September 4, 2009

Auditar SAP – Introducción

A lo largo de varios post en este blog vimos desde artículos introductorios, hasta algunas pequeñas herramientas que SAP nos brinda para ayudarnos a configurar su seguridad.

En este post, y los subsiguientes sobre “Auditar SAP“, trataremos de abarcar paso a paso, las tareas a realizar para evaluar la seguridad de un sistema. En algunos casos repitiéndo conceptos ya definidos en anteriores artículos del blog, e incorporando otros nuevos.

Lo principal a fines de empezar, es entender el alcance de la auditoría que vamos a realizar. Metodológicamente, una auditoría del sistema se concentra en revisar la configuración del mismo, con el fin de exponer las falencias que puedan poner en jaque la seguridad de la información que en el reside.

Tenemos que comenzar entendiendo que el sistema SAP como ERP, es un sistema que puede aportar un alto grado de seguridad en las operaciones, y posee un buen número de controles embebidos en el mismo, tanto configurables como inherentes. Pero esta seguridad tiene que ser configurada, para que sea efectiva.

Y también es importante destacar una característica particular de SAP a la hora de auditarlo, y es que en el mismo no solo se configuran y por consiguiente, se revisan, los controles de aplicación (controles internos del negocio, validaciones de datos, etc) si no que también un gran número de controles de base o generales deben efectuarse en el mismo, ya que desde dentro de un sistema SAP es posible acceder directamente a las tablas de base de datos, ejecutar programas, ver código fuente, ejecutar comandos de sistema operativo, apagar el servicio, realizar debugging, y un largo etc de actividades que en otros sistemas deben controlarse “por fuera de la aplicación” y en el caso de SAP deben controlarse en “ambos lugares”. Y resaltamos “ambos lugares” porque incluso en muchas revisiones de seguridad se pierde el foco y se controlan los permisos dentro del sistema con el fin de verificar controles generales y de aplicación, abandonando un poco el control sobre los servidores de base de datos, de aplicación, etc.

Igualmente como corresponde a este blog, nos ocuparemos, al menos en principio, a la revisión de la seguridad específica en la plataforma SAP y posteriormente incorporaremos tips a verificar en las plataformas subyacentes (pero es tan variado este control, como plataformas y bases de datos sobre las que puede instalarse SAP).

Antes de empezar efectivamente con la auditoría sobre el sistema, hay cierta información que uno debería recopilar, y vamos a explicar porque:

- Versión, o versiones de SAP sobre la que se va a trabajar - Distintos parámetros y configuraciones son posibles dependiendo de la versión del sistema, como así también nuestras recomendaciones varí an según la versión de SAP, salvo que nuestra recomendación se actualizar la versión ;-)

- Cualquier informa de auditoría previo – Nos puede dar una idea general del sistema, aunque la revisión deba hacerse de cero.

- Landscape, número y nombre de instancias - Por motivos obvios es necesario conocer el landscape sobre el que se trabaja, servidores involucrados, application servers lógicos, físicos, ambientes de desarrollo, pruebas, producción etc. Es importante que los ambientes se encuentren correctamente aislados el uno del otro.

- Sistema operativo y Base de Datos (Nombre, versiones, etc) – Averiguar el sistema operativo sobre el que está instalado el application server y la base de datos sobre la que corre es importante tanto para la revisión de software de base, como para algunas transacciones específicas del sistema según donde se instale.

- Mandantes - Conocer los mandantes existentes y el objetivo de los mismos es necesario por las mismas razones que las instancias, y para conocer las necesidades de auditoría.

- Cantidad de usuarios - Complejidad y extensión de la revisión.

- Módulos utilizados/implementados - Para conocer el alcance de la revisión, una aproximación del número de roles involucrados y complejidad, la cual puede depender de los módulos (sobre todo si son incluidos módulos de industria específicos que si bien pueden no agregar muchos controles de seguridad, pueden ser desconocidos para nosotros)

- Esquema general de Sociedades, Centros, Sociedades CO, y otros datos funcionales - Resultan útiles a la hora de evaluar un esquema de roles acorde a las necesidades de la organización.

- Número de desarrollos ABAP o Z - Nos servirá como dato sobre la complejidad del sistema y de su diferencia con el sistema estándar. Este dato es de suma importancia a la hora de saber lo complejo del análisis de roles y en un posible caso de reingeniería de los mismos.

- Toda la documentación del área de sistema definiendo procedimientos, misiones y funciones, organigrama, nómina de empleados del área de sistemas con funciones, monitoreo, etc - Es útil con el fin de confirmar que estos procedimientos y puestos se vean reflejados en la estructura del sistema, y que los permisos de usuarios en el sistema no excedan o limiten sus responsabilidades. Es importante conocer el procedo de gestión de usuarios y accesos, para ver que el mismo se refleje de manera adecuada en el sistema.

- Procedimiento de cambios, y cambios de emergencia Es importante contar con este procedimiento escrito y de no ser así relevar el proceso que debería ser, para comprobar que el sistema de transporte y los permisos estén configurados de manera acorde.

- Usuarios de Interfaz o no nomenclados - Es importante conocer de antemano cuales son estos usuarios para verificar su correcta parametrización o recomendar su eliminación.

- Esquema de Nomenclatura de roles - Como son nomenclados los roles es vital para entender la estructura de los mismos.

- Nomenclatura de usuarios - Para verificar que se cumpla y comprender la misma.

- Metodología de Acceso al sistema - A través del SAP GUI, Web, interfaz desde otras aplicaciones, usuarios de internet, externos, SAP Router, Citrix. Es importante determinarlo con el fin de verificar el alcance y saber con que estamos tratando.

- Implementación de Seguridad a través de la estructura organizativa, o la utilización de perfiles estructurales - Cambio nuestro punto de vista sobre como revisar la seguridad del sistema.

- Topología de Red del sistema SAP - Realizar un análisis preliminar de la instalación y su seguridad

- Planes de continuidad del sistema - Además de lo obvio, para conocer la redundancia, el riesgo y otros sistema que debamos verificar.

- Existencia de permisos de visualización para auditar el sistema - Lo dejamos para el final, pero es de suma importancia poseer permisos a todo lo que necesitemos, pero sin modificación, para poder trabajar con tranquilidad sobre el sistema. Ya que de ser negado el acceso interactivo al sistema tendremos que encarar una auditoría COMPLETAMENTE DISTINTA.

Evidentemente todavía no abordamos nada técnico, pero es un paso esencial el de recopilar toda la información que sea posible. Si a ustedes se les ocurre alguna otra información específica a recopilar no duden en hacer comentarios en este artículo.

En el próximo abordaremos ya más en detalle los temas técnicos y cómo proseguimos con una auditoría del sistema.

Fuente: SeguridadSap.

Securing Application Infrastructure: The analysis of Application Security Methodologies

The trend of security threats has recently gained a prominent attention in media and industry reports. This article will briefly examine the methodologies and approaches that most organizations follow to address security issues by giving examples, test cases, strengths and weaknesses. Today's widely known solutions involve vulnerability scanning, static code analysis, penetration testing, binary analysis, fuzzing etc. Which of them are more or less reliable and which of them can address specific type of application problems, is mainly discussed here.

As many software vendors think that 'security issues' may never laid them out of business but in reality it does affect the sales as well as market reputation. Deploying proper application security not only rest assure the clients but also lead to increase the productivity. Let us take an example of interesting equation:

X=Applications developed
Y=Vulnerabilities exist in those applications
Z=Cost of repair (patch and fixes)
Now; X.Y.Z=A (answer)

If 'A' is less than the cost of third-party QA auditor, cost of training the developers and conducting additional security audits then it make more sense to write an insecure code.

Application vulnerabilities (in broad sense) can be divided into following sections but not limited to:

Operation/Platform Vulnerabilities
-Asset information disclosure
-Buffer Overflows
-Misconfigurations
-Error Handling
-Resource specific threats

Design Vulnerabilities
-Logic Flaws
-Access Control (Authentication/Authorization

Implementation Vulnerabilities
-Code Injection
-Information Disclosure
-Command Execution
-Functionality Abuse
-Input Validation
-Time and State

Now to test the security of the application, one may apply either of these methodologies:

Automated
-Automated Dynamic Tests (Fuzz Testing, Vulnerability Scanning)
-Automated Static Tests (Source or Binary Code Scanning)

Manual
-Manual Dynamic Tests (Parameter Tampering and Social Engineering)
-Manual Static Tests (Source or Binary Code Auditing)

Although each of these methods have their own strengths and weaknesses. Thus, we assume not the best, but atleast more efficient and reliable method can be judged by looking into their specific testing process.


Automated Dynamic Testing
While approaching to disclose application vulnerabilities under this method, the complexity ratio increases when moving from vulnerability scanning to the fuzz testing.

Strengths
-Less false positives (inherent benefits of run-time analysis)
-Programmatic approach to ensure reliable and consistent tests output

Weaknesses
-Threat assurance, No Fault != No Flaw
-Only the part of code audit may provide baseline for measurement.
-Unexpected conditions cannot be tested without additional programming.

Use Cases
-Fuzz Testing (complex input, informal SDLC, observable indicators)
-Application Scanning (strongly typed flaw classes, deterministic and observable behavior, known inputs only)
-Vulnerability Scanning (known transaction sequences, one to one mapping of triggers to specific conditions)


Automated Static Testing
This method can disclose the set of vulnerabilities present in the application by examining the code (source/binary) without user interaction. Several commercial and open source tools are available to perform automated static analysis. The complexity of such tools increases from normal flaw identification to the formal verification process.

Strengths
-Assessment of low-context flaws (parameters, DB query statements, etc)
-Automated scans required little or no human interaction
-Can get good placement during development lifecycle

Weaknesses
-Applications without presence of their source code.
-High ratio in false postives or negatives, tuning is harder.
-Critical issues with formal verification
  1. Developing and correctly expressing a set of security invariants.
  2. Developing an interpretation of the application that lends itself to proving/disproving invariants.
Use Cases
-Timely and resource-specific detection of simple flaws
-Detection of regression as a part of development lifecycle
-False assumption on strong assurance of the critical application
-In the hands of a developer who cannot interpret or filter the results correctly


Manual Dynamic Testing
The manual dynamic assessment apporach can be achieved by human-navigated application usage followed by assurance validation process and fuzz testing. A critical background information on application design can be provided by the developers. The complexity of manual dynamic testing process increases with its level of common criteria, assurance validation to parameter tampering.

Strengths
-Parallel capacity in execution of tests
-Pattern recognition
-Testing the live implementation may reduce false positives
-Capable of emulating the malicious attack process

Weaknesses
-Time consuming for large and complex applications
-May require the tester to hold a steep learning curve
-Test envrionment may not mirror production

Use Cases
-High risk applications require highly experienced security auditor to understand and scope the attack surface
-Wrong application type or the wrong tester background
-A case where the requirements of assessment does not match the expected risk profile of an application


Manual Static Testing
This process involves the interaction of human reviews, understanding application design and architecture documentation, use of offline toolset (such as, disassemblers, code browsers, etc).

Strengths
-Known data and code points
-Without any resource specific considerations
-Adaptability with skills and toolset

Weaknesses
-Accuracy issues (falst positives, human mistakes)
-High resource requirements
-Inconsistency in interpretation of same flaw in different ways

Use Cases
-Manual code audit (skilled resources, minor findings before automated tests, custom-coded scripts)
-Configuration review (low risk in changing values at runtime, known data sources and formatings)


Thus, from the application security assessment methods mentioned above and the statistics from "WASC Statistics Project" prove that the probability in detection of high risk vulnerabilities can be higher if combined set of methodologies are used. And this combined approach is almost 12.5% higher than automated scanning (specific to web applications).

Source: EthicalHacker.

Exploiting SAP Business Platforms: The Pen-Testing Analysis

SAP simply stands for "Systems, Applications and Products in data processing". SAP as a unique business solution developer integrates range of solutions including ERP, CRM, GRC, PLM, SCM and many more. The ease of usage, implementation and market reputation has put forward a strong basis for the company (german based) worldwide. Deploying SAP solution is a bit lengthy and complex process and that's why a core security settings left default or unattended. This could results in serious exposure of the SAP platforms and flag a high risk to the organization.


SAP Basic Components

ClientID - Business unit or Corporation with unique identifier.
Transaction - A conversation between client interface and backend database.
Authorization - Users assigned roles/profiles.
ABAP - SAP high-level programming language.
Reports - A component to generate report on user requests.
Functional Modules - A set of remote or local procedures.
RFC Interface - Remote funtion call library.


SAP Security

Talking in the specific context of SAP platform, many auditors would like to harden the SAP authorization subsystem (roles and profiles). While hardening the authorization process and segregation of duties is considered vital but there is also another aspect of security which involves technical assessment of all the networked components within SAP environment. Conducting "Penetration Testing" using industry-proven methodology gives more clear outlook for security vulnerabilities and threats in the existing infrastructure. Such as, weakness in configuration may result in business frauds. The typical number of steps followed under SAP Pen-Testing are:

-Discovery (Find the target)
-Enumeration (Services running on the platform)
-Vulnerability Assessment (Check for the presence of known/unknown vulnerabilities)
-Exploitation (Try to gain administrator privileges on the defined system)

The main goal is to achieve the highest possible privileges in the production environment which can be accomplished by:

-Getting SAP Administration access
-DBA privileges
-SAP_ALL access privileges

Though obtaining any of the above access may give complete control over SAP systems.


SAP Penetration Toolkit

Following are some of the key tools necessary to assess the SAP infrastructure.

-NMap
-rsh,rlogin,rexec
-BurbSuite
-W3af
-Nessus
-JTR (John The Ripper)
-THC Hydra
-SQL Client Tools
-NFS Client Tools
-Sapyto
-Metasploit

It worth to mention that "Sapyto" is specially designed as SAP Penetration Testing Framework to cover all aspects of Pen-Testing methodology. And because it is developed in python and C, it is easier port plugins.

Countermeasures

1.Restrict connections to the SAP gateway.
2.Restrict access to shared resources. Such that, allow only internal connections.
3.Harden the configuration settings.
4.Remove/Change the default user accounts.
5.Enable "SNC" to protect against evasdropping.
6.Good password security should be enforced.
7.Access to transactions should be restricted.
8.Use SAP authorization object "S_Program" to protect report confidentiality.

Source: EthicalHacker.

Cloud Computing: A Security Outlook

A 'cloud' in computing environment is the combination of Infrastructure as a service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS) components. Well, most of us may confuse it with ASP (Application Service Provisioning) strategy, which is completely wrong. In simple terms, cloud is a virtualized, dynamically scalable, shared fabric and shared hardware solution to the users. It avoids capital expenditure (CapEx) on purchasing expensive hardware, software and other services by renting the usage from a third-party provider under SLA (Service-level Agreement). For more information, a cloud taxonomy is attached below.

When taking insights of security within Cloud Computing domain give a clear view of risks involved from consistency, interoperability, confidentiality, availability and integrity point of view, such as:

-Host visibility within cloud
-Trust Exploitation
-Data Privacy issues
-Immature logging process
-Data center tripwire
-Application security vulnerabilities
-Backdoored filesystem/virtualized operating systems/applications
-Virtualization security issues
-Content ownership/Intellectual property rights
-Cleartext data storage and transfer vs SSL/EV-SSL
-Use of weak encryption technology
-Centralized approach

Hence, before approaching any cloud computing vendor its better to investigate their policies and procedures regarding security of your company's data transactions. This can be analyzed on the following basis:

-Data segregation and use of strong encryption technology
-Data hosting location
-Recognized under industry standards and regulatory compliance.
-Disaster recovery and business continuity assurance
-Privileged access control
-Availability of resources and data
-Viability of data in case if the vendor goes out of business

A good set of cloud service can be differentiated under agility, sustainability, cost, multi-tenancy, reliability, scalability and security. Additionally, from security perspective, a 'focused penetration testing' may rest assure a vendor from any false sense of security and thus save the cost of any data loss or liability issues.

For more information on current security initiatives, visit:
[1]Cloud Security Alliance - http://www.cloudsecurityalliance.org
[2]ENISA Cloud Security Working Group - http://www.enisa.europa.eu

Source: EthicalHacker.

Escalating from PHP Hardend Environment

There are number of PHP threats and vulnerabilities which have been reported during the past few years. These include, file inclusion attacks, remote file upload vulnerability, insecure function injection (eval,create_function,preg_replace), etc. Executing malicious shellcode over vulnerable web servers is still easier but it is quiet challenging when "post exploitation" topic is highlighted.

Today many of PHP-based web servers are hardened by default and running with low privileges. Thus, it is extremely challenging for the attacker to gain full control over the server. Let's take a brief overview on common type of protection schemes used to hardened PHP environment:

1. Limit the PHP code (i.e. control each input/output)
2. Limit the PHP interpreter
3. Harden the code against buffer overflow + memory corruption
4. Limit the possibility of arbitrary code execution
5. Non-writable filesystem
6. safe_mode (disable access to configuration settings, limit access to files/directories, limit environmental variables)
7. disable_function/disable_classes (remove un-necessary functions and classes)
8. Use memory manager (malloc/mmap) to apply safe_unlink feature and three canaries (metadata,buffer(before/after)
9. Kernel-level protection with ASLR (address space layout randomization), mprotect(), Apparmor, SELinux, GRSecurity

Now take some highlights on PHP vulnerabilities and exploitable condition:

1. Caller of the PHP application can force parameter to be passed by reference

function increase($a)
{
$a++;
}
$z = 7;
// pass $z as a reference
increase(&$z);
echo $z,"\n";
?>

This happens because we are unable to disabled the internal "allow_call_time_pass_by_reference" function.

2. executor_globals() to find the interesting target, it contains list of functions/ini entries/jmp_buf but the memory position is unknown and
it changes the structure with every single PHP version.

3. To execute the user choice of code, function dl() comes in handy but it requires:
-platform independent library
-a writable directory
-enable_dl should be activated
-setting extension_dir to the shared library directory

4. Attacking under x86 linux platform:
-PHP array leaks the pDestructor pointer which points to PHP code segment
-scan until we find ELF header in memory
-once ELF header discovered, we can also find imported functions
-select the function which have been imported from libc (memcpy)
-from there we can look any function within libc and access their addresses
-address to shellcode can be written and executed
-copying shellcode into the writable text-segment and execute it

Source: EthicalHacker.