/*codigo slider*\

lunes, 28 de mayo de 2012

CRYPTEX - Seguridad de la Información: ¿Qué es ISO 22301?

CRYPTEX - Seguridad de la Información: ¿Qué es ISO 22301?:  El nombre completo de esta norma es ISO 22301:2012 Seguridad de la sociedad – Sistemas de gestión de la continuidad del negocio – Requisitos. Esta norma fue redactada por los principales especialistas en el tema y proporciona el mejor marco de referencia para gestionar la continuidad del negocio en una organización.
Relación con BS 25999-2
La ISO 22301 ha reemplazado a la 25999-2. Estas dos normas son bastante similares, pero la ISO 22301 puede ser considerada como una actualización de la BS 25999-2. Para conocer las diferencias entre ambas, por favor, consulte la infografía ISO 22301 vs. BS 25999-2.
¿Cuáles son los beneficios de la continuidad del negocio?
Si se implementa correctamente, la gestión de la continuidad del negocio disminuirá la posibilidad de ocurrencia de un incidente disruptivo y, en caso de producirse, la organización estará preparada para responder en forma adecuada y, de esa forma, reducir drásticamente el daño potencial de ese incidente.

¿Quién puede implementar esta norma?
Cualquier organización, grande o pequeña, con o sin fines de lucro, privada o pública. La norma está concebida de tal forma que es aplicable a cualquier tamaño o tipo de organización.

¿Cómo encaja la continuidad del negocio en la gestión general?
La continuidad del negocio es parte de la gestión general del riesgo en una compañía y tiene áreas superpuestas con la gestión de seguridad y tecnología de la información.

¿Qué es ISO 22301? Fuente: iso27001standard.com

miércoles, 23 de mayo de 2012

What Is the Difference: Viruses, Worms, Trojans, and Bots?



Contents
Introduction
Viruses, worms, Trojans, and bots are all part of a class of software called malware. Malware or malicious code (malcode) is short for malicious software. It is code or software that is specifically designed to damage, disrupt, steal, or in general inflict some other “bad” or illegitimate action on data, hosts, or networks.
There are many different classes of malware that have varying ways of infecting systems and propagating themselves. Malware can infect systems by being bundled with other programs or attached as macros to files. Others are installed by exploiting a known vulnerability in an operating system (OS), network device, or other software, such as a hole in a browser that only requires users to visit a website to infect their computers. The vast majority, however, are installed by some action from a user, such as clicking an e-mail attachment or downloading a file from the Internet.
Some of the more commonly known types of malware are viruses, worms, Trojans, bots, back doors, spyware, and adware. Damage from malware varies from causing minor irritation (such as browser popup ads), to stealing confidential information or money, destroying data, and compromising and/or entirely disabling systems and networks.
Malware cannot damage the physical hardware of systems and network equipment, but it can damage the data and software residing on the equipment. Malware should also not be confused with defective software, which is intended for legitimate purposes but has errors or bugs.
Classes of Malicious Software
Two of the most common types of malware are viruses and worms. These types of programs are able to self-replicate and can spread copies of themselves, which might even be modified copies. To be classified as a virus or worm, malware must have the ability to propagate. The difference is that a worm operates more or less independently of other files, whereas a virus depends on a host program to spread itself. These and other classes of malicious software are described below.
Viruses
A computer virus is a type of malware that propagates by inserting a copy of itself into and becoming part of another program. It spreads from one computer to another, leaving infections as it travels. Viruses can range in severity from causing mildly annoying effects to damaging data or software and causing denial-of-service (DoS) conditions. Almost all viruses are attached to an executable file, which means the virus may exist on a system but will not be active or able to spread until a user runs or opens the malicious host file or program. When the host code is executed, the viral code is executed as well. Normally, the host program keeps functioning after it is infected by the virus. However, some viruses overwrite other programs with copies of themselves, which destroys the host program altogether. Viruses spread when the software or document they are attached to is transferred from one computer to another using the network, a disk, file sharing, or infected e-mail attachments.
Worms
Computer worms are similar to viruses in that they replicate functional copies of themselves and can cause the same type of damage. In contrast to viruses, which require the spreading of an infected host file, worms are standalone software and do not require a host program or human help to propagate. To spread, worms either exploit a vulnerability on the target system or use some kind of social engineering to trick users into executing them. A worm enters a computer through a vulnerability in the system and takes advantage of file-transport or information-transport features on the system, allowing it to travel unaided.
Trojans
A Trojan is another type of malware named after the wooden horse the Greeks used to infiltrate Troy. It is a harmful piece of software that looks legitimate. Users are typically tricked into loading and executing it on their systems. After it is activated, it can achieve any number of attacks on the host, from irritating the user (popping up windows or changing desktops) to damaging the host (deleting files, stealing data, or activating and spreading other malware, such as viruses). Trojans are also known to create back doors to give malicious users access to the system.
Unlike viruses and worms, Trojans do not reproduce by infecting other files nor do they self-replicate. Trojans must spread through user interaction such as opening an e-mail attachment or downloading and running a file from the Internet.
Bots
"Bot" is derived from the word "robot" and is an automated process that interacts with other network services. Bots often automate tasks and provide information or services that would otherwise be conducted by a human being. A typical use of bots is to gather information (such as web crawlers), or interact automatically with instant messaging (IM), Internet Relay Chat (IRC), or other web interfaces. They may also be used to interact dynamically with websites.
Bots can be used for either good or malicious intent. A malicious bot is self-propagating malware designed to infect a host and connect back to a central server or servers that act as a command and control (C&C) center for an entire network of compromised devices, or "botnet." With a botnet, attackers can launch broad-based, "remote-control," flood-type attacks against their target(s). In addition to the worm-like ability to self-propagate, bots can include the ability to log keystrokes, gather passwords, capture and analyze packets, gather financial information, launch DoS attacks, relay spam, and open back doors on the infected host. Bots have all the advantages of worms, but are generally much more versatile in their infection vector, and are often modified within hours of publication of a new exploit. They have been known to exploit back doors opened by worms and viruses, which allows them to access networks that have good perimeter control. Bots rarely announce their presence with high scan rates, which damage network infrastructure; instead they infect networks in a way that escapes immediate notice.
Best Practices for Combating Viruses, Worms, Trojans, and Bots
The first steps to protecting your computer are to ensure that your OS is up to date. This means regularly applying the most recent patches and fixes recommended by the OS vendor. Secondly, you should have antivirus software installed on your system and download updates frequently to ensure that your software has the latest fixes for new viruses, worms, Trojans, and bots. Additionally, you want to make sure that your antivirus program can scan e-mail and files as they are downloaded from the Internet. This will help prevent malicious programs from reaching your computer. You may also want to consider installing a firewall.
Additional Definitions and References
Exploit
An exploit is a piece of software, a command, or a methodology that attacks a particular security vulnerability. Exploits are not always malicious in intent—they are sometimes used only as a way of demonstrating that a vulnerability exists. However, they are a common component of malware.
Back Door
A back door is an undocumented way of accessing a system, bypassing the normal authentication mechanisms. Some back doors are placed in the software by the original programmer and others are placed on systems through a system compromise, such as a virus or worm. Usually, attackers use back doors for easier and continued access to a system after it has been compromised.
Technical Definition Sites


This document is part of the Cisco Security Intelligence Operations.
This document is provided on an "as is" basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information on the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document at any time.

CRYPTEX - Seguridad de la Información: Robo de información corporativa: delito informátic...

CRYPTEX - Seguridad de la Información: Robo de información corporativa: delito informátic...:


Un 25% de organizaciones a nivel mundial ha tenido que retrasar o detener una fusión o adquisición, o el lanzamiento de un nuevo producto o solución, por filtración de datos.


De acuerdo con el más reciente Informe Global sobre Fraude de Kroll, la mitad de las compañías se siente muy vulnerable al robo de información, y en aquellas que tienen más pérdidas por fraude, los autores más probables fueron ejecutivos de alto nivel (29%) o ejecutivos menores (8%).

“El robo de información sensible y secretos corporativos es uno de los delitos con mayor incidencia en las empresas no solo a nivel mundial, sino también en México. Muchas veces, el robo de secretos industriales está vinculado a un fraude, pero en otros casos, se trata de empleados que se llevan la información que generaron o con la cual trabajaron en la compañía al momento de cambiarse de trabajo, o al tener algún problema con su jefe inmediato”, comenta Andrés Velázquez, Presidente y Fundador de MaTTica.

Según cifras del estudio de McAfee Inc. y Science Applications International Corporation, 25% de las organizaciones han sufrido la paralización o atraso de una fusión o adquisición, o bien de la implementación de un nuevo producto o solución, a causa de una filtración de datos o por una amenaza creíble de filtración de datos.

Andrés Velázquez aconseja tener cuidado con empleados que se quedan después de horas de trabajo, que vienen a trabajar solos en fines de semana muy seguido, que se tratan de ocultar al hablar por teléfono o que tratan de obtener de manera incisiva detalles de proyectos confidenciales, pues esto podría indicar que se está compartiendo información privilegiada que puede beneficiar a otros.

“En muchos casos, las computadoras y los teléfonos celulares son los medios que se usan para cometerlos. Hemos tenido casos en los cuales se han coordinado reuniones de entrega de información a través de mensajes de texto, o en los que usan correos corporativos o personales desde la computadora de la empresa, y en ella quedan remanentes a los que podemos acceder e identificar qué sucedió”, dice el Presidente de MaTTica.
El ejecutivo aconseja que las empresas establezcan claramente políticas de uso de tecnología para los empleados dentro de la corporación, ya que en el caso de un proceso legal se puede obtener la evidencia digital de los dispositivos corporativos, pero cuando se usan cuentas personales desde equipos particulares –lo que sucede cuando los empleados llevan y usan sus propios dispositivos al trabajo– se requiere de una orden judicial o el consentimiento del usuario para analizarlos.

También hay que considerar si se permite usar programas de mensajería instantánea, memorias USB o reenvío de correos corporativos a cuentas de correo webmail.

“Creo que es un tema de educación entender cómo se puede proteger la información dentro de las empresas, así como que se puede llegar a investigar en el caso de que esto suceda, y que deben haber ciertos lineamientos para que la investigación no solo dé resultados, sino que se pueda llegar a vincular una responsabilidad legal sobre la persona que cometió el delito”, explica Andrés Velázquez.

En cuanto a los empleados que se van a trabajar a la competencia, el ejecutivo señala que las empresas deberían contar con un protocolo para recoger el equipo de los empleados que se van y documentar la salida del personal, entre otros procesos.
Actualmente, MaTTica está ofreciendo un servicio para generar imágenes forenses de las computadoras de ejecutivos gerenciales antes de que se retiren de la empresa. “Así, aunque los ejecutivos ya no estén o reasignen su máquina, podremos tener evidencia digital resguardada por si la persona se va a la competencia en unos tres meses, y se llega a sospechar que hubo alguna filtración de datos corporativos”, afirma Velázquez.

La mayor incidencia en el robo de información y datos electrónicos, según el Informe Global sobre Fraude de Kroll 2011, ocurre en las empresas financieras (29%); de tecnología, medios y telecomunicaciones (29%); salud, farmacéuticas y biotecnología (26%); y servicios profesionales (23%). Asimismo, en 28% de las compañías afectadas por fraude, los autores más probables de estos fueron ejecutivos menores, en tanto que en otro 21% fueron empleados de nivel gerencial. Las pérdidas por este tipo de delitos en las empresas mexicanas, según el estudio, llegaron al 2.2% de sus ingresos.

martes, 8 de mayo de 2012

Ninety Percent of HTTPS Websites Insecure

Ninety Percent of HTTPS Websites Insecure

Recently the most popular websites using secure online transactions (Online stores, banks, communication sites, etc.) were tested for security and most did not fare very well.
Of the approximately 200,000 HTTPS SSL encrypted websites tested, only about 10% are properly secured according to the Trustworthy Internet Movement (TIM).
Also, about 75% of the sites are still vulnerable to a BEAST attack:

The test used checks for several key factors used in SSL encryption including:
  • Cipher Strength
  • Key Exchange
  • Protocol Support
  • Certificate Information
The woes of SSL communication have been known for several years now. Years ago, security expert Moxie Marlinspike has shown that SSL communications can be intercepted using a man-in-the-middle attack and the encryption can be stripped away so the unencrypted information read using a program called SSLstrip.
Also, one of the tests used by the TIM checked SSL sites for a vulnerability to the Browser Exploit Against SSL/TLS (BEAST) attack. The BEAST attack exposes a vulnerability that was discovered in SSL in 2004.
The attack is a combination of Javascript and network sniffer that decrypts session cookies which can then be used to hijack and take over the user’s logged in session.
A video of BEAST in operation along with additional information on the attack tool can be found on one of the developer’s websites.
TIM has created a taskforce of world renown security experts to try to tackle the SSL issue:
“The Trustworthy Internet Movement (TIM) is convening a task force that includes Taher Elgamal, one of the creators of the SSL protocol; Moxie Marlinspike, creator of Convergence; Ivan Ristic, director of engineering at Qualys; and other experts from Google, PayPal and GlobalSign. Ristic founded SSL Labs, a research project to measure and track the effective security of SSL on the internet.”
Changes definitely need to be made to the secure online transaction system. Even so, several of the SSL issues have already been addressed, and sadly it seems that the appropriate measures to properly secure SSL have just not been taken.
 
Cross-posted from Cyber Arms


CRYPTEX - Seguridad de la Información: Concientes de riesgos pero incongruentes con plane...

CRYPTEX - Seguridad de la Información: Concientes de riesgos pero incongruentes con plane...:




Escrito por Martha E.Gómez Cruz   
Las principales prioridades en las empresas son la implementación de controles más estrictos para proteger los datos sensibles y asegurar la continuidad del negocio.

mcafee logoLa seguridad de la información efectiva es posible solo al crear un Plan de seguridad estratégico (SSP) que incorpore un análisis completo de amenazas y un exhaustivo método de migración de riesgo de seguridad por niveles, destacó el informe Estado de seguridad, de McAfee.
De acuerdo con el estudio, las organizaciones están seguras de identificar la mayoría de las amenazas fundamentales a sus entornos y de saber dónde residen sus datos fundamentales. No obstante, la mayoría no están seguras de cuantificar el posible impacto financiero de un potencial peligro, en caso de que ocurriera. 
Los encuestados consideraron que la conciencia y la protección de la organización contra riesgos de seguridad de información son muy importantes; aunque, 1/3 de las empresas “optimizadas” no están seguras de su postura de seguridad de TI en términos de conciencia y protección. 34% de las empresas cree que no están protegidas adecuadamente contra riesgos de seguridad de información. 
Algunos datos relevantes del informe son:
  • Cuando desarrollan Planes de seguridad estratégicos, las empresas incluyen consideración de posibles amenazas y el riesgo asociado al negocio, y un análisis financiero. Sin embargo, 4 de 5 experimentaron un incidente de seguridad importante en los últimos 12 meses.
  •  Casi 1/3 de las empresas no han adquirido o no han implementado muchas de las tecnologías de seguridad de próxima generación diseñadas para resolver las amenazas actuales. 
  • 2 de cada 5 empresas tiene un plan informal o un plan ad hoc o no cuentan con un plan estratégico de seguridad en funcionamiento. El tamaño de la compañía sí importa cuando se trata de tener un plan de seguridad estratégico formal. 6 de cada 10 empresas poseen SSP formales, 2 de cada 3 compañías de tamaño mediano cuentan con un SSP formal, mientras que esta relación cae a solo 1 de cada 2 empresas pequeñas.
  • Existe mayor probabilidad de que las organizaciones de América del Norte y Alemania tengan Planes de seguridad estratégicos formales, en comparación con otras regiones del mundo, probablemente a causa de los entornos regulatorios de estos países. 
Para este 2012, una de las principales prioridades es la implementación de controles más estrictos para proteger los datos sensibles y asegurar la continuidad del negocio. 
La menor prioridad es reducir el capital y los gastos operacionales para infraestructura de seguridad, lo que indica que las empresas tienen como objetivo invertir en el tipo de soluciones de seguridad que requieren. 
En este informe, los encuestados se clasificaron en diversos estados de madurez de seguridad, que ayudaron a comprender la mentalidad de las empresas cuando ven la seguridad de la información de la empresa. 
Se utilizaron diversos términos para describir el nivel de madurez en cuanto a la seguridad de las empresas:
  • Reactivo: usa un método ad hoc para definir procesos de seguridad y es impulsado por los eventos. 9% de las empresas dice estar en esta etapa.
  • Cumplimiento: tiene algunas políticas vigentes, pero no cuenta con estandarización real entre las políticas de seguridad. La organización se adhiere a ciertos estándares de seguridad o al mínimo requerido. 32% de las empresas asegura estar en esta etapa.
  • Proactivo: sigue políticas estandarizadas, se rige de manera centralizada y tiene un nivel de integración entre algunas soluciones de seguridad. 43% considera estar en esta etapa.
  • Optimizado: sigue las mejores prácticas de la industria de seguridad y se adhiere estrictamente a la política corporativa. La organización utiliza soluciones de seguridad automatizadas, las cuales están muy bien integradas en toda la empresa. 16% de las empresas encuestadas dicen estar en esta etapa.
Jill Kyte, vicepresidente de McAfee, precisó que las empresas necesitan adoptar un método por niveles en cuanto a seguridad y usar procesos y soluciones diseñados para evitar ser afectados. “Las empresas dan acceso a su red a socios de negocios y empleados y, en algunos casos, incluso a clientes. Los trabajadores acceden remotamente a la red de la empresa a través de dispositivos móviles, muchos de los cuales son de propiedad personal y no son controlados por la empresa a cuya red ellos acceden. Los datos y aplicaciones se mueven a entornos de nube pública e híbrida, donde los propietarios de los datos poseen poco control directo sobre la seguridad, y todo esto requiere que una empresa cuente con un Plan de seguridad estratégico”, comentó el vicepresidente.
Si bien las empresas trabajan en sus planes de seguridad estratégicos y están colocando sus mejores esfuerzos para proteger los sistemas comerciales y los datos fundamentales, aún hay mucho por mejorar como es:
  • Subir al nivel más alto de madurez en cuanto a seguridad.
  • La participación de los ejecutivos es fundamental. Es importante tener los conocimientos de quienes comprenden mejor los sistemas comerciales y los datos que utilizan.
  • Probar tempranamente, probar a menudo y realizar los ajustes necesarios. ¿Qué tiene de bueno un plan que se desarrolla y se deja en un estante? ¿Si nunca se prueba?
  • Utilizar sabiamente las asignaciones de presupuesto.
  • Usar las herramientas adecuadas para las amenazas actuales.
  • Centrarse en proteger el alma de la empresa: los datos corporativos sensibles. 

lunes, 7 de mayo de 2012

Codigo Unix: Performance analysis: Understanding the vmstat com...

Codigo Unix: Performance analysis: Understanding the vmstat com...: Todo sysadmin que se digne de tal, tiene la capacidad de optimizar sus equipos para soportar las distintas situaciones de carga a las que se se puede ver sometido o resolver bottlenecks que puedan llegar a producirse. Existen varias situaciones que pueden sobrecargar un equipo, y siempre es útil comprender cuando se producen y los procedimientos para remediarlas.
La performance es un área difícil de comprender, pero fundamental a la hora de administrar sistemas.
Durante este post vamos a intentar comprender la salida de vmstat(8), un comando disponible en la mayoría de los sistemas Unix, en nuestro caso vamos a enfocarnos en Linux, y analizaremos algunas situaciones las cuales pueden llevar a una sobrecarga de performance.
Existen numerosas herramientas para analizar esto, pero muchas de ellas dan su punto de partida en vmstat(8), para luego enfocar en herramientas más específicas como iostat(8), mpstat(1), o sar(1). Para un mayor entendimiento de performance y las herramientas utilizadas les recomiendo el blog de Brendan Gregg, o también leer el libro "Solaris™ Performance and Tools: DTrace and MDB Techniques for Solaris 10 and OpenSolaris" por Richard McDougall, Jim Mauro y Brendan Gregg

Según su propia manpage vmstat(8): reports information about processes, memory, paging, block IO, traps, disks and cpu activity.

Nosotros enfocaremos este post en entender la información proporcionada por los procesos, la memoría, el I/O y la utilización de la CPU. Pero antes de entrar de lleno en esto, hay algunas cosas que tenemos que comprender primero.

Los sistemas operativos modernos, trabajan en distintos modos a fin de garantizar una mayor seguridad y proteger las aplicaciones unas de otras. Actualmente en PC x86/x86_64 podemos definir algunos modos de operación como es el modo real (utilizado durante el booteo), modo protegido (proteger la memoría virtual), long mode (modo de operación 64 bits), modo virtual 8086 (retrocompatibilidad binaria con antiguos procesadores). El modo protegido, planea una interfaz de llamadas al sistema (syscall) para poder acceder al hardware, evitando de esta manera que un usuario tenga acceso directo al I/O y sea el kernel, el responsable de realizar estas actividades, es por ello que fueron diseñados básicamente un sistema de privilegios basados en rings, el ring0 también conocido como kernel mode, y el ring 3, denominado userspace.



Kernel mode: En este modo es el kernel, y sus drivers (módulos) quienes pueden ejecutarse, se reserva un espacio de memoria virtual donde solo puede estar mapeado el kernel, sus extensiones y como dije anteriormente sus drivers.

Userspace: Solo se ejecutan las aplicaciones de usuario, para acceder al kernel mode se necesitan efectuar llamadas al sistema, reserva un rango de direcciones de memoria donde las aplicaciones y librerías (o bibliotecas, para los puristas) del userspace (denominadas userland) pueden ejecutarse.

Veamos un ejemplo sencillo en ANSI C y luego en ensamblador para INTEL x86 sobre como el sistema operativo hace uso de esta interfaz para poder realizar un sencillo exit.

  1. int main() {
  2.   _exit(0);
  3. }

Las llamadas al sistema en Linux, se realizan de una manera bastante sencilla, cada una de ellas es mapeada a un código hexadecimal, por ejemplo la syscall 0x1h (1 en decimal), representa exit, la syscall 0x4h (4 en decimal), representa a write y 0x37h (55 en decimal) es kill.
Este código hexadecimal es posicionado en un registro de propósito general en la CPU, en el caso de un procesador 32 bits este registro es %EAX o %RAX si contamos con 64 bits.
Luego los siguientes argumentos que lleva la syscall son posicionados en otros registros de propósito general como es el caso de %EBX, %ECX y %EDX (en 32 bits). Si miramos dentro de la manpage de _exit(2) podemos ver:

NAME
       _exit, _Exit - terminate the calling process

SYNOPSIS         top
       #include 
       void _exit(int status);

       #include 
       void _Exit(int status);

   Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
       _Exit():
           _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE || _POSIX_C_SOURCE >= 200112L;
           or cc -std=c99

DESCRIPTION
       The function _exit() terminates the calling process "immediately".  Any open
       file descriptors belonging to the process are closed; any children of the
       process are inherited by process 1, init, and the process's parent is sent a
       SIGCHLD signal.
       The value status is returned to the parent process as the process's exit
       status, and can be collected using one of the wait(2) family of calls.
       The function _Exit() is equivalent to _exit().

CONFORMING TO
       SVr4, POSIX.1-2001, 4.3BSD.  The function _Exit() was introduced by C99.

NOTES
       For a discussion on the effects of an exit, the transmission of exit status,
       zombie processes, signals sent, etc., see exit(3).

       The function _exit() is like exit(3), but does not call any functions
       registered with atexit(3) or on_exit(3).  Whether it flushes standard I/O
       buffers and removes temporary files created with tmpfile(3) is implementation-
       dependent.  On the other hand, _exit() does close open file descriptors, and
       this may cause an unknown delay, waiting for pending output to finish.  If the
       delay is undesired, it may be useful to call functions like tcflush(3) before
       calling _exit().  Whether any pending I/O is canceled, and which pending I/O
       may be canceled upon _exit(), is implementation-dependent.

       In glibc up to version 2.3, the _exit() wrapper function invoked the kernel
       system call of the same name.  Since glibc 2.3, the wrapper function invokes
       exit_group(2), in order to terminate all of the threads in a process.

SEE ALSO
       execve(2), exit_group(2), fork(2), kill(2), wait(2), wait4(2), waitpid(2),
       atexit(3), exit(3), on_exit(3), termios(3)
Por lo cual, podemos apreciar que _exit, cumple la función de terminar un proceso de manera inmediata, y además cualquier file descriptor (fd) abierto es cerrado de manera inmediata. Esto es logrado mediante un wrapper que invoca a exit_group(2) en la glibc (mayor a 2.3), haciendo la systemcall exit(2). exit_group(2) es utilizada para que todos los threads de un proceso sean terminados. En nuestro ejemplo a exit debemos pasarle un argumento, del tipo entero (int de ahora en más), para retornar un exit status, que posteriormente podemos comprobarlo en el shell instanciando a la variable $?.

Esto, en ensamblador INTEL x86 quedaría así:

  1. Section .text
  2.   global  _start
  3.  
  4. _start:
  5.   mov eax, 1  ; Syscall 1 - _exit
  6.   mov ebx, 0  ; Exit status
  7.   int 0x80    ; Switch to kernel mode

Si miramos este código con algo de atención podemos notar que lo primero que se efectua es posicionar el valor 0x1h, dentro del registro %EAX, que se está refiriendo a la syscall exit(2), en el segundo paso, posiciona el exit status (0), dentro del registro %EBX, y paso final llama a la interrupción 0x80h (int 0x80). Esta interrupción es muy importante en Linux, y es la que efectúa el switcheo de un código ejecutándose binariamente en el userspace, a pasar a ejecutarse en el kernel mode. Esto, se lo conoce como Context switching.


Por lo cual, podemos concluir que una aplicación de usuario (userland) se ejecuta en el Userspace, y para poder ejecutarse en kernel mode, necesita hacer uso de llamadas al sistema (syscall), que es provista por el kernel, quién el, junto a los drivers será capaz de interactuar directamente con el hardware. Entonces, podemos plantearnos el siguiente interrogante, ¿que pasaría si notamos un consumo elevado de la CPU, y podemos apreciar una enorme cantidad de context switchs (CS)?. Bien, podemos deducir que una aplicación del userland, es quien esta generando un importante número de llamadas al sistema y debemos revisar nuestros procesos que se estén ejecutando a ver quién es el responsable.

Procesos y threads:
Podemos definir a un proceso como una instancia de un programa en ejecución que a reservado memoria para su uso, todo proceso al momento de su creación lleva asignado un número de PID (Process ID), y un número de PPID (Process Parent ID), esto es debido a que en Linux, y muchos otros Unix, los procesos nacen por medio de una familia de syscalls denominada fork (fork, vfork). Estos procesos, crean en la memoria virtual (VM) ciertos segmentos, que luego mediante el sistema de IPC (Inter Process Comunication), se establecen permisos de acceso. Entre estas secciones podemos encontrar la sección .TEXT donde se encuentra mapeado la porción de código en ejecución a nivel binario, .STACK, una estructura bastante dinamica en forma de pila que hace uso del método LIFO (Last In, First Out) sobre los datos que puede almacenar, el .HEAP, .BSS, entre otras. Los procesos, tienen la particularidad de que su segmento reservado de memoria puede ser accedido únicamente por ellos (a menos que el mismo mapee una porción como SHM). Por su parte los threads, los cuales son procesos livianos, comparten entre ellos la misma "imagen" de memoría, de forma que pueden acceder indistintamente a ellos, dando lugar en los peores casos a race conditions y deadlocks. Para evitar esto, existen algoritmos que emplean por ejemplo la exclusión mutua y se hace uso de los semáforos. Veamos un pequeño ejemplo a continuación, en el cual varios trheads intentan acceder a un mismo recurso, en el mismo instante de tiempo:


Estos trheads, de los cuales hablamos, en un sistema monoprocesador (1 CPU), no tienen demasiado sentido, ya que solamente puede ejecutarse uno por vez, y es el scheduler del sistema operativo quien se encarga de asignarles un tiempo de CPU para que los mismos se ejecuten, en caso de que un proceso haga uso de mayor cantidad de tiempo a la que le fue asignada el mismo será penalizado (mediante semáforos), teniendo que esperar N cantidad de tiempo antes de poder volver a ingresar nuevamente a la CPU. Esto se logra mediante la utilización de el algoritmo Round Robin, el cual asigna tiempos iguales de CPU a todos los procesos, pero en caso de que uno se exceda aplica penalizaciones. En caso de equipos con múltiples cores, esta limitación se ve superada, pero siempre que tengamos una sola CPU física, solo un proceso por vez podrá correr. Para que varios procesos puedan correr concurrentemente necesitamos tener un equipo con múltiples unidades de procesamiento. Pero también suele pasar que muchos procesos o threads esten esperando para entrar a la CPU, y a esto lo realizan generando una cola o también denominada run queue, estaremos tienen una cola de ejecución normal, cuando esta no supere en número a la cantidad de procesadores que tenga el equipo instalado, caso contrario, estaremos ante un bottleneck.
Una métrica que suele ser tomada en cuenta por muchos administradores para medir la carga de un equipo, es mediante la carga promedio (Load average), la misma puede ser consultada mediante el comando top o también mediante uptime, y nos informa la carga del equipo ahora, hace cinco minutos y hace quince minutos. Veamos un ejemplo:
02:20:23 up  3:06,  2 users,  load average: 3.03, 2.13, 0.19
En este ejemplo, podemos notar que la carga actual esta en 3.03, siendo que el equipo cuenta con un procesador con 2 cores podemos decir que es alta, la carga promedio hace 5 minutos también se encuentra mínímamente excedida, y hace 15 minutos se encontraba bien. Por lo cual, es probable que algún proceso esté encolado, esperando para entrar a ejecución en la CPU. Pero está métrica no es del todo confiable, ya que en Linux además, promedia el tiempo en el que el proceso se encuentra "Waiting for I/O", por lo cual, la salida de vmstat sería mas confiable, y esta la podemos encontrar en la columna "r" de dicho comando.

Para reportar las estadísticas, vmstat hace uso del procfs, especificamente de /proc/stats, /proc/mem/info y /proc/*/stat, que como muchos de ustedes sabrán, cada proceso en ejecución, crea una entrada (mediante un directorio) en el directorio /proc, cuyo nombre es el PID del proceso y dentro del mismo existe un archivo denominado stat.

La invocación de vmstat es sencilla, si lo invocamos sin parámetros, nos imprimirá por la salida estándar, una sola muestra, podemos especificarle al mismo mediante un entero, la cantidad de tiempo que debe pasar entre muestra y muestra, y además la cantidad de muestras que queremos que nos brinde. Es un factor a tener en cuenta el periodo que debe pasar entre cada una de las muestras, ya que puede afectar notablemente a nuestro entendimiento de la salida. Con el argumento -a, nos brindara estadísticas mas avanzadas (imprimiendo la memoria activa e inactiva) y con -t además nos imprimirá un timestamp sobre cuando se produjo dicha muestra. vmstat Además imprime información sobre el estado de la swap y del IO (discos), utilizando como medida bloques de datos, cada bloque actualmente para kernels 2.6 y 3.x tiene un tamaño total de 1024 bytes, antiguamente estos podían ser reportados por vmstat en bloques de 512 bytes, 2048 bytes o 4096 bytes.

Veamos nuestro primer ejemplo:
$ vmstat 1 10
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 3  0  71096 200036  12252 277544    0    3    64    45  662 1212 11  4 82  3  0 
 3  0  71096 199788  12252 277928    0    0     0     0  470  811  2  1 98  0  0 
 0  0  71096 201276  12260 277980    0    0     0    40  686  839 10  1 88  2  0 
 1  0  71096 201276  12260 277604    0    0     0     0  479  743  2  1 98  0  0 
 0  0  71096 201084  12260 277604    0    0     0   232  561  811  2  2 96  0  0 
 1  0  71096 201180  12260 277604    0    0     0    28  466  804  2  1 98  0  0 
 0  0  71096 201180  12260 277604    0    0     0     0  702  871 11  1 89  0  0 
 0  0  71096 201644  12260 277604    0    0     0     0  465  756  2  0 98  0  0 
 0  0  71096 201668  12260 277604    0    0     0     0  577  750  2  1 97  0  0 
 0  0  71096 201700  12276 277588    0    0     0    36  641  750  1  0 92  7  0 
La invocación en este caso se hizo imprimiendo muestras cada un segundo, y un total de diez muestras. Lo primero que nos llama la atención es que por un instante (2 segundos), la columna "r" tiene un valor de 3, en mi caso tengo solo dos cores y una CPU, por lo cual este valor se encuentra minimamente alto, pero dura muy poco como para preocuparnos. Seguido a nuestra columna "r", nos encontramos con la columna "b", esto según la manpage de vmstat, significa: The number of processes in uninterruptible sleep., como seguramente sabrán un proceso puede encontrarse en diversos estados, y utilizan un mecanismo de señales para comunicarse entre ellos (para listarlas: kill -l), Estos procesos, pueden encontrarse entre otros estados: Running (en ejecución), Sleeping (Durmiendo, esperando alguna señal o evento que los despierte), Stopped (parados), Zombie (Murio el padre, pero no el hijo), etc. Dentro de Sleeping, existen dos estados principales en los que puede estar durmiendo el proceso:

Interruptible sleep: Aquellos procesos que están esperando alguna señal para despertar y volver a ejecutarse (por ejemplo que se les notifique que X tarea fue completada).

Uninterruptible sleep: Aquellos procesos los cuales se encuentran aguardando algún tipo de evento externo para poder continuar, por ejemplo esperando I/O.

Por lo cual, nuestra columna "b" representa a la cantidad de procesos que se encuentran esperando alguna actividad externa para poder continuar como se dijo, por ejemplo I/O. Por lo cual, hacia el final de la salidad de vmstat encontramos la columna "wa" la cual nos dice que es la cantidad de tiempo gastado por la CPU esperando I/O. Generalmente ambas columnas están relacionadas, y tener altos valores aquí, puede ser sinónimo de algún desperfecto en el filesystem (posiblemente optimizable), baja velocidad en el bus de datos utilizado por las controladoras de disco, o algún tipo de desperfecto en el dispositivo de almacenamiento o sus controladoras. Para tener un detalle superior y resolver problemas de performance de I/O puede ser consultado iostat(1).
Veamos un ejemplo de esto:

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  1  71096  83596  18112 356208    0    3    61    44  644 1182 11  4 83  3  0 
 2  1  71420  72564   9772 379456    0  324 69760   412 2310 3041  4 45 20 31  0 
 1  1  71420  70584   4292 391272    0    0 84224     0 2589 3295  3 55 21 21  0 
 2  0  71420  72744   4292 393968    0    0 79104     0 2489 3131  3 51 23 23  0 
 3  1  71420  71796   4292 397928    0    0 81280     0 2472 3147  3 52 24 21  0 
 2  1  71420  69932   4292 402356    0    0 83968     0 2634 3308  3 55 21 21  0 
 1  1  71420  73220   4284 401044    0    0 84864    40 2673 3282  3 56 20 22  0 
 1  2  71420  67416   4292 408544    0    0 83208     0 2699 3202  3 54 16 26  0 
 0  2  71420  71728   4292 408500    0    0 83328     0 2602 3230  3 55 11 32  0 
 2  0  71420  74236   4300 408988    0    0 60456    32 2069 2752  4 39 12 45  0 
Si bien la carga no es excesivamente alta, podemos ver que nuestra columna "r" se encuentra entre 1 y 3 la mayor parte del tiempo. Nuestra columna "b" la encontramos variando entre 1 y 2 y la columna "wa" en un valor estimado entre 21 y 45. Lo cual en este caso es indicio de que o el disco conectado a la máquina es lento, o la controladora lo es. También encontramos otras columnas sumamente interesantes y muy importantes para nuestro análisis, esta es "us" dicha columna nos informa la cantidad de tiempo gastado en el userspace, por ejemplo alguna aplicación o aplicaciones que esten consumiendo un alto porcentaje de la CPU. Por su parte la columna "sy", nos dice la cantidad de tiempo que el kernel mode se encuentra consumiendo. "id", del término inglés idle, nos dice que tan libre se encuentra el sistema, cuando este valor es cercano a 100, mas libre se encuentra el mismo. Estás métricas son interesantes para conocer que la carga de la CPU y a esto se le denomina utilización, cuando la utilización supera el 100%, cambia su denominación a saturación, y esta saturación puede ser responsable de procesos encolados en la "run queue" (la columna "r"). Posiblemente, obviamente dependiendo el caso, la saturación pueda estar dada por una poca cantidad de RAM, o un bajo poder de procesamiento en el equipo.

Otro campo interesante es "cs", que contabiliza la cantidad de context switchs durante la muestra, si vemos un número elevado de context switchs puede ser indicio de que alguna aplicación en el userspace se encuentra ejecutando una gran cantidad de syscalls que pueden ser o no un problema.

El campo "in", nos muestra la cantidad de interrupciones producidas en el tiempo de muestra por el equipo. Hace un tiempo, tuve una experiencia personal con un firewall ejecutando la tecnología de filtrado IP Filter (IPF), el cual estaba produciendo un número enorme de interrupciones (entre 70000 y 100000) en muestras de 1 segundo, en este caso era debido a un daño físico (aunque podía deberse al driver también) en una interfaz de red. A esto se lo conoce como interrupt storm, y como un dato curioso, la primera de ellas se produjo durante el alunisaje del Apollo XI en 1969. Una tormenta de interrpuciones puede consumir el mayor tiempo (o todo el tiempo) en kernel mode ("sy"), y dejar el sistema sin respuesta, en un estado denominado live lock. Existen algunas formas de mitigar las tormentas de interrupciones, por ejemplo en el siguiente planteamiento: Una NIC ethernet, la cual debe efectuar una interrupción por cada paquete que ingresa o sale de la misma, para que esto no genere una interrupt storm, se hace uso de un mecanismo de polling el cual genera una interrupción cuando X cantidad de paquetes deben ser enviados o recibidos. Caso contrario, mientras mayor througput de red exista, mayor será la cantidad de interrupciones generadas, pudiendo producirse una interrput storm.

El campo "st", hace referencia a la cantidad de tiempo de procesamiento en caso de utilizarse virtualización robado al hypervisor por las máquinas virtuales.

Un grupo de campos bastante relacionados son los de la sección "Memory", en los cuales podemos encontrar "swpd" como la cantidad total de swap en el sistema (mas información: swapon -s), "free" la cantidad de memoria libre y que puede ser ser utilizada. "buff", Es la cantidad de memoria utilizada como buffers. "cache", La cantidad de memoria utilizada como cache por los distintos procesos.

Por su parte dentro de el grupo de campos "Swap", encontramos dos columnas, "si" o swap-in y "so" o swap-on. Esto es la cantidad de bloques que son escritos a swap, y son leídos de swap respectivamente. El sistema operativo hace uso de la memoría swap, cuando se queda sin memoria física a la que direccionar las páginas de memoría, bajando las menos utilizadas a dicha memoría de intercambio. La memoría swap, mas los buffers y la memoria física conforman un grupo al que se denomina virtual memory (VM). Por lo cual, notar actividad en estas columnas, puede ser síntoma de que la memoria física instalada en el equipo esta siendo insuficiente.

Veamos el siguiente ejemplo:
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs  us sy id wa st
 3  3  71420  93312  14888 373588    1    2    97    41  623 1140  84  3 10  3  0   
 8  2  72280 104204  28608 321432    2  860  1864  2704 2689 9901  61 22  1 17  0
 7  2  72784  75128  28040 350996  100    2   100    41  623 1143  93  3  0  3  0   
11  5  72812  75128  28116 351024  132   28 11392   668 1962 8491  32 16 11 41  0   
 8  3  72840  70540  28092 355984    1   28  9184   780 1766 11739 27 16  1 47  0   
 9  4  72972  74964  28068 351312    7  132 15860   644 2138 6639  34 20  5 40  0   
 8  2  73104  75264  21200 358408    0  132 11208   628 1775 5542  18 16  8 58  0
 3  2  73388  72768  13444 368200  345  284  2724   524 2032 25138 29 20  5 46  0   
 5  4  73848  74540  31100 347204  123  208  8120   208 3566 59935 41 35  0 24  0   
 4  3  74092  73084  36244 342524   98  244  5436  1392 3434 43193 33 27  0 40  0   
 7  4  74196  66204  43588 341380   15  104  6084   148 4437 64503 34 37  8 21  0   
 5  2  75344  70212  45964 335144    2 1148  4432  1368 3115 56056 30 32  7 31  0
La swap, es memoria lenta, ya que reside en el disco, por lo tanto pasa a ser un problema para nuestro analisis, por su parte la memoría física mantiene comunicación directa con la o las CPU's del equipo, mediante el bus de memoria, el cual trabaja a una frecuencia mucho mayor brindando una velocidad que jamaz los discos que conocemos podrán alcanzar, incluido aquellos de estados solido, los cuales suelen utilizarse entre otras cosas para hacer web cache (con Varnish). La tendencia a swappear por parte del kernel, puede ser optimizada mediante una sysctl, esta es vm.swappines.

En las muestras proporcionadas por el último ejemplo vemos una clara situación de saturación: La columna "r" en este caso es mayor a nuestra cantidad de cores (2, según /proc/cpuinfo), la columna "b", muestra un número constante y bastante alto de procesos con uninterruptible sleep, lo cual se apoya en el tiempo empleado en Waiting for I/O, según la columna "w", además podemos notar que el equipo esta swappeando ("si" y "so"), por lo cual aquí el problema puede deberse a una combinación de factores como baja velocidad de las controladoras, o daño en ellas o en los discos (para ello buscar por errores en los logs del sistema), además de una baja cantidad de memoria, o la existencia de un proceso o varios que se esten cosumiendo todos los recursos. Además podemos ver que el userspace es bastante alto en proporción a nuestro tiempo idle, por lo cual podría ser una aplicación o varias aplicaciones pequeñas del userland quien este produciendo esto. Para determinar esto, podemos ejecutar en una termianl lo siguiente:
# ps -eo user,pid,pcpu --no-headers | awk '{ if ( $3 > 80 ) print $1,$2,$3}'
zimbra 28442 88.5

# ps aux | grep 28442 
zimbra   28442  88.5 60.3 1213164 924904 ?      Sl   Apr11 306:57 /opt/zimbra/java/bin/java -Dfile.encoding=UTF-8 -server -Djava.awt.headless=true -Dsun.net.inetaddr.ttl=60 -XX:+UseConcMarkSweepGC -XX:PermSize=128m -XX:MaxPermSize=128m -XX:SoftRefLRUPolicyMSPerMB=1 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationStoppedTime -XX:-OmitStackTraceInFastThrow -Xss256k -Xms256m -Xmx256m -Xmn64m -Djava.io.tmpdir=/opt/zimbra/mailboxd/work -Djava.library.path=/opt/zimbra/lib -Djava.endorsed.dirs=/opt/zimbra/mailboxd/common/endorsed -Dzimbra.config=/opt/zimbra/conf/localconfig.xml -Djetty.home=/opt/zimbra/mailboxd -DSTART=/opt/zimbra/mailboxd/etc/start.config -jar /opt/zimbra/mailboxd/start.jar /opt/zimbra/mailboxd/etc/jetty.properties /opt/zimbra/mailboxd/etc/jetty-setuid.xml /opt/zimbra/mailboxd/etc/jetty.xml
¡Bingo! encontramos al responsable de quien se esta comiendo nuestra CPU y en gran parte a la memoria. Con esto, estamos imprimiendo mediante ps(1), aquellos procesos cuyo consumo de CPU sea superior al 80%. Si en vez de querer consultar la CPU, quisiéramos hacer lo mismo con la memoria ejecutaríamos:
# ps -eo user,pid,pmem --no-headers | awk '{ if ( $3 > 80 ) print $1,$2,$3}'
Pero también pueden existir situaciones en la que no sea un gran proceso quien este consumiendo los recursos, sino que pueden ser múltiples procesos chiquitos, que comen un poco cada uno y en conjunto si estén sobrecargando el sistema. Veamos un ejemplo de esto:
zimbra   28468  4.2  3.9  21540   840 ?        S    Apr11   0:05 /opt/zimbra/httpd-2.2.19/bin/httpd
zimbra   28471  1.2  1.1 109432  6196 ?        S    Apr11   0:00 /opt/zimbra/httpd-2.2.19/bin/httpd
zimbra   28488  6.0  4.7 109432  6196 ?        S    Apr11   0:04 /opt/zimbra/httpd-2.2.19/bin/httpd
zimbra   28489  1.3  3.2  54028  3476 ?        S    Apr11   0:05 /opt/zimbra/httpd-2.2.19/bin/httpd
zimbra   28490  1.8  1.6  54028  3476 ?        S    Apr11   0:00 /opt/zimbra/httpd-2.2.19/bin/httpd
zimbra   28491  6.2  9.1  54028  3476 ?        S    Apr11   0:01 /opt/zimbra/httpd-2.2.19/bin/httpd
zimbra   28492  0.4  1.0  54028  3476 ?        S    Apr11   0:02 /opt/zimbra/httpd-2.2.19/bin/httpd
zimbra   28493  0.1  1.0  54028  3476 ?        S    Apr11   0:02 /opt/zimbra/httpd-2.2.19/bin/httpd
zimbra   28494  0.7  1.0  54028  3476 ?        S    Apr11   0:02 /opt/zimbra/httpd-2.2.19/bin/httpd
zimbra   28495  0.4  1.0  54028  3476 ?        S    Apr11   0:02 /opt/zimbra/httpd-2.2.19/bin/httpd
--- OUTPUT OMMITED ---
Si bien omití algunos procesos por comodidad al momento de leer este, esta situación también podría darse, logrando saturar la CPU/Memoria, o bien producir una alta utilización. A veces estos procesos suelen ser difíciles de tracear debido a que pueden durar muy poco, muchas veces para conocer que esta haciendo un proceso solemos utilizar strace(1),(o truss en Solaris), si bien nos permite conocer con exactitud que se encuentra ejecutando el proceso, impacta en el mismo produciendo una baja perfomance. Pero cuando no podemos realizar esto, una forma bastante sencilla de conocer la cantidad de procesos o threads nuevos que se están creando en nuestro sistema es mediante el parámetro -f de vmstat, la cual contabiliza la cantidad de forks y vforks, producidas desde el último booteo del equipo.
La diferencia mas sustancial entre fork(2), y vfork(2), es que este último crea un nuevo child process suspendiendo a su padre (bloqueándolo) hasta que el mismo termine o envíe alguna señal que lo haga finalizar (por ejemplo llamando a _exit(2)). vfork(2) además, no copia su tabla de páginas de su padre, como si lo haría un proceso creado con fork(2), pero este si comparte su propia memoria con el padre, incluido el stack. Veamos un ejemplo, en el cual un webserver (Apache), esta produciendo forks continuamente, consumiendo de manera excesiva la CPU del equipo:
# while true; do sleep 1 && vmstat -f ; done
283986702 forks
283986734 forks
283986769 forks
283986812 forks
283986855 forks
283986938 forks
283986963 forks
283987083 forks
283988034 forks
283988918 forks
A esto debemos restarle los aproximadamente 2 forks que realiza vmstat y while para producir esta salida para tener un resultado aún más exacto. Lo que nos da un promedio de aproximadamente 50 forks por segundo.

Toda esta salida que hemos analizado a lo largo del post puede ser graficada con numerosas herramientas tales como gnuplot, en la cual podemos obtener resultados como este:

Grave vulnerabilidad en PHP-CGI (Parchea!)

Grave vulnerabilidad en PHP-CGI (Parchea!)

Eindbazen, un equipo de competiciones CTF, ha descubierto una vulnerabilidad en PHP-CGI que permite pasar parámetros al intérprete de PHP, como -s o -r, a través de la URL. Por ejemplo añadiendo la cadena '?-s'.

Como resultado de la inyección de estos parámetros en la URL, se puede mostrar el contenido de archivos de código fuente (que puede incluir información confidencial como, por ejemplo, contraseñas de BBDD) o ejecutar código PHP arbitrario.
Aunque el parámetro '-r', para ejecutar código PHP, es filtrado en php5-cgi, dependiendo de las variables de entorno, esta medida de seguridad puede evitarse.

PHP eliminó por error el código que protegía ante este problema en 2004 y se posibilita el paso de parámetros al intérprete, lo que permite la ejecución de código arbitrario y la revelación de información confidencial. FastCGI no es vulnerable.

Solución

Ya existen módulos de la herramienta de pentesting y hacking metasploit que permiten explotar esta vulnerabilidad por lo que se recomienda actualizar cuanto antes. Se puede hacer a través del código fuente, aunque se recomienda instalarlo a través de los mecanismos de actualización de paquetes de Linux. Para sistemas Windows, se puede descargar de la web http://windows.php.net/download/.

Como alternativa, si no se puede actualizar, el fabricante propone las siguientes reglas del módulo mod_rewrite de Apache para bloquear las URLs maliciosas:

RewriteCond %{QUERY_STRING} ^(%2d|-)[^=]+$ [NC]
RewriteRule ^(.*) $1? [L]


Actualización: PHP ha confirmado que las nuevas versione 5.3.12 y PHP 5.4.2 no corrige definitivamente el error.

Actualización: nuevas versiones de PHP que incorporan esta revisión revisada se dará a conocer pronto. El error que inicialmente no fue bien corregido, es identificado como CVE-2012-2311.

Actualización: ya se han publicado varios exploits que permite RCE.

Actualización: Metasploit ya dispone del módulo para probar esta vulnerabilidad.

Actualización: Pentester ha publicado un paso a paso sobre la explotación de la vulnerabilidad.

Fuente: INTECO-CERT

BEiNi: ManuaL de Usuario

BEiNi: ManuaL de Usuario: Una Vez adquirido el disco te mostraremos paso paso y de forma sencilla como Instalarlo Fácilmente !  Página de inicio al programa Beini...


  • Barra de herramientas del programa.


Estructura interna del PE (Portable Executable)

Estructura interna del PE (Portable Executable)

En la gran web de corkami han creado un esquema muy bueno sobre el formato de los archivos PE (Portable Executable) de Windows. Resaltan las secciones más interesantes del mismo, mostrando el volcado ASCII, el nombre del campo correspondiente, su valor hexadecimal y una pequeña explicación de dicho campo.

También muestran las tablas se secciones más importantes, pero no sólo han recogido información interna del PE, sino que además muestran de forma simple los pasos del proceso de carga de estos ficheros en memoria (clic para agrandar):

 Puedes descargar el esquema en varios formatos: PDF, JPG o SVG. Esquema digno de todo un póster. Este es el complemento perfecto de este otro esquema (PDF) que crearon los chicos del OpenRCE.

Fuente: Cyberhades

viernes, 4 de mayo de 2012

http://blog.segu-info.com.ar/2012/05/blackhole-exploit-kit-el-mas-propagado.html

http://blog.segu-info.com.ar/2012/05/blackhole-exploit-kit-el-mas-propagado.html

AVG ha publicado su Informe de Amenazas para el primer trimestre de este año [PDF], y menciona que el paquete de exploits BlackHole Exploit Kit sigue siendo la amenaza Web más propagada con un 43% del total de sitios web maliciosos detectados.

Blackhole es constantemente actualizado, se trata de un kit polimórfico y usa técnicas de ofuscación para engañar y eludir las herramientas de seguridad. De acuerdo al estudio los sitios con antivirus falsos antivirus (FakeAV) están en segundo lugar con el 27,3% y permite vender software real para engañar a las víctimas.

Los sitios con spam de farmacias aparecen en el tercer lugar con el 7,71%. En este caso se trata de páginas web falsas que dicen vender productos médicos y muchas víctimas compran estos productos en línea.

A continuación, el documento se traslada a las amenazas móviles y AVG alerta sobre malware para Android, donde los atacantes están usando Facebook y Twitter para la promoción y difusión de nuevos virus para los usuarios móviles.

Los autores de malware ya no están utilizando métodos estándares para atacar a sus víctimas, sino que están utilizando activamente los recursos de las redes sociales, sitios web vulnerables y los mensajes de spam.

Fuente: SecTechno

Related Posts Plugin for WordPress, Blogger...