Account lockout attack o Ataque para bloqueo de cuenta, un ataque simple pero efectivo, donde se aprovecha la funcionalidad de bloqueo automática a la cuenta del usuario tras numerosos intentos de acceso fallidos. El abuso de esta funcionalidad en manos de un atacante podría provocar serios problemas.


Como se hace?


Sencillo... intentamos acceder con el nombre de usuario de la víctima al sistema muchas veces, hasta activar el sistema de bloqueo de cuenta. ¿Cuántos de ustedes han ingresado mal su propia contraseña intentando recordar cómo era?, hasta que les aparece que su cuenta ha sido bloqueada por seguridad y necesita verificaciones.

Bien, pero esto no queda acá, vamos a echar un poco la imaginación a volar... imaginemos este mismo ataque pero a millones de víctimas en el mismo sistema de logeo, un bloqueo de cuenta masiva. No sólo que van a bloquear todas esas cuentas, sino que también posiblemente estén realizando un ataque DoS (Denial of Service) logrando colapsar el sistema en el máximo de los casos. Ya no solo afectaría a los usuarios sino que estarías logrando un ataque hacia el servidor/web.



Ejemplo real.



Un ejemplo real sucedió en eBay, página de transacciones online reconocida mundialmente, dónde había una subasta y el atacante la queria ganar, pero también había otro usuario legítimo intentando ganarla. Entonces el atacante no oferto más, hasta que faltaban pocos minutos de terminar la subasta, en ese instante el atacante lanza un ataque contra la cuenta de la víctima (ya que en la subasta oculto en el código se veía el user_id del usuario víctima), intentando entrar varias veces logrando bloquear la cuenta de la víctima. El atacante vuelve a entrar a su cuenta y antes de que termine la subasta hace una oferta, como la víctima no podía entrar a su propia cuenta perdió la subasta.



Pablo E. La Rocca.

Fuente: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login

Si navegamos un poco por los foros de hacking "underground" de la red y nos metemos en sus subforos de malware, vamos a encontrar numerosos crypters y modificaciones de los mismos para -supuestamente- indetectar cualquier código malicioso. Por si algún colgado en el tema no sabe lo que es un crypter, le comento: son herramientas que utilizan algoritmos simétricos para cifrar malware de forma que las firmas de los antivirus sobre ese código se rompan.

Es cierto que los crypters funcionaron muy bien hasta hace unos años atrás, luego los antivirus evolucionaron implementando otro tipo de detección, para no depender únicamente de las firmas... sobre eso les quiero compartir una investigación:

Antes los antivirus contaban con una sola proteccion, basada en firmas, conocida como reactiva. Que en muy resumidas cuentas funciona de la siguiente manera: una muestra de cada malware llega a los laboratorios de los antivirus, los analistas buscan una pequeña parte de ese malware que sea sencible dentro de su código, es decir, que si se llegara a modificar el malware deje de funcionar (al menos debería ser asi aunque a veces no pasa :p) y entonces marcan esa parte como firma para ese malware. A partir de ahí, cuando la base de datos de firmas de los usuarios se actualiza, el AV comienza a detectar ese código malicioso.

Entonces, existen numerosos métodos para acorralar esa firma, modificarla, evitar que el .exe se rompa, etc etc. Uno de los métodos mas sencillos de todos (si no es el mas sencillo) es cifrar el malware utilizando un crypter. ¿Que pasa cuando se cifra? todo el código cambia incluyendo la firma, entonces el antivirus deja de detectar ese malware.

Estas técnicas siguen funcionando para evadir la protección reactiva, ya que la misma no cambió su funcionamiento, peeero, las compañías de AV  implementaron otra protección para complementar a la reactiva, que se llama: Proactiva.

Esta "nueva" protección hace que indetectar un malware ya no sea tan fácil como simplemente utilizar un crypter fud. ¿Porqué? veamos cómo funciona...

Se basa en heurística, tiene algoritmos heurísticos que son en resumidas cuentas aquellos comportamientos que convierten a un ejecutable en potencial sospechoso de malware. Así es, la proactiva no tiene firmas, sino que analiza el comportamiento del .exe.

Existen tres tipos de heurísticas: genérica, pasiva y activa. La primera busca similitudes entre un malware que ya ha pasado por el laboratorio de la compañía y el ejecutable a analizar, si hay demasiadas coincidencias saltará el alerta. La pasiva explora el código del .exe tratando de determinar que acciones realizará y con ello darse cuenta si se trata de un malware o no. La activa, es el sandbox, una caja de arena que viene a ser un entorno virtualizado donde se ejecuta el malware y el AV puede realmente saber todo lo que el mismo va a hacer.

Obviamente esa última heurística es la mas difícil de evadir, y la tienen implementada todos los AV mas populares.

Entonces, a lo que vamos con todo esto, es que hoy en día por mas que cifremos un malware y logremos evadir la protección reactiva, el mismo ejecutará igualmente las acciones tipicas de un malware y será detectado por la segunda protección del AV: la proactiva.

Para respaldar un poco tanta teoría, me arme un mini laboratorio y utilicé el último crypter fud posteado en un popular foro underground. Allí podemos ver el resultado del scan online y efectivamente es un crypter que evade la reactiva de los antivirus. Los escaners online muestran el resultado de la protección reactiva y es lógico que sea así ya que para mostrar el resultado de la protección en tiempo real se deberia contar con una máquina para cada AV con todas sus funciones activas y ejecutar ahí mismo el malware, pero eso no pasa por una cuestión de consumo de recursos.

Bien, en mi lab instale AVG Free con la configuración por default (que cualquier usuario dejaría) donde vemos activa la protección en tiempo real (proactiva). Aquí dejo una captura:



Tome mi carpeta de malware  y cree servers funcionales con la configuracion MINIMA (para reducir comportamientos sospechosos) utilizando los siguientes troyanos: DarkComet, SpyNet 2.6 y uno mas que no me acuerdo indecision

Por supuesto el server así nomas es super detectado hasta por aquellos AVs que no los conoce ni el que lo hizo. Pero bueno, lo fuddie con el crypter y le hice un escaneo manual al .exe que es el mismo que hacen los AV onlines, el resultado fue este:



pero, al ejecutar el malware con el antivirus instalado y con sus funcionalidades a pleno, el resultado cambia:



con otro troyano:



Finalmente no se logró infectar con ninguno de los troyanos. Resultado esperado, al menos para mi. ¿Qué podemos concluir? Al menos a mi me gustaría concluir que hay que innovar en nuevos códigos, en nuevas técnicas de evasión teniendo en cuenta cómo funciona esta nueva protección. Los crypter es algo que se utiliza hace mucho y los AV ya los tienen muy cocinados, de hecho, el que el exe este todo cifrado hace que el AV ya lo mire con sospechas


Fuente: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
Autor:Sheila A. Berta

#Explicación:

Insecure Cookie Handling (inseguridad en el manejo de cookies) es una vulnerabilidad que encontraremos en sitios que utilizan mal sus cookies y es muy sencilla de explotar. Los programadores pueden utilizar cookies, por ejemplo, para restringir la sección de los usuarios no autorizados, vamos a explicar qué significa cada cosa...


Cookie: Las cookies forman parte del protocolo HTTP, este protocolo se usa para intercambiar mensajes entre el servidor y el cliente utilizando solicitudes y respuestas HTTP. El encabezado HTTP reservado para el uso de las cookies se denomina Set-Cookie y está compuesto por estos valores:

Set-Cookie: nombre=valor; domain=nombre de dominio; expires=vencimiento de la cookie; path=ruta donde la cookie será validada; secure

Ejemplo:

Set-Cookie: admin=1; domain=www.web.com; expires=Friday, 2-Feb-2016 00:00:00 GMT; path=/admin; secure

Secure: Solo se usa si la cookie es enviada por conexion segura (SSL) y es opcional.


#Explotación:

Pondremos algunos ejemplos en PHP. Mostramos un código que lo puede utilizar un programador para autorizar la entrada a la administración.

<?
// verificamos que existe la cookie admin y que tenga el valor 1.

if(isset($_COOKIE['admin']) && $_COOKIE['admin'] == 1)
{
echo "Bienvenido a la administración...";

}else{

echo "No estas autorizado";

}
?>

En este caso tendríamos que crear una cookie llamada "admin" con el valor 1. Lo haremos en JavaScript pero se puede hacer con un plugin de Firefox ( Cookies Manager+ ). Entonces, ingresaremos en el sitio vulnerable y ponemos en la barra del navegador:

javascript:document.cookie="admin=1; path=/";

Ahora entramos nuevamente al login y, en este caso, tendremos acceso a la administración.


Otro ejemplo:

<?
// Verificamos que este creada una cookie user con valor 1, y pass con valor 1

if($_COOKIE['user'] == 1 && $_COOKIE['pass'] == 1)
{
echo "Autorizado";
}else{
echo "No autorizado";
}
?>

Como en el caso anterior entramos a la web e insertamos en el navegador:

javascript:document.cookie="user=1; path=/"; document.cookie="pass=1; path=/";

Ahí creamos 2 cookies las cuales sirven para pasar la verificación. Entramos nuevamente a la web estando ya autorizados.


Vamos con un último ejemplo:

<?

// codificamos en base64 el usuario admin para luego encriptarlo en md5.
$user = md5(base64_encode("admin"));

//verificamos que la cookie usuario tenga el valor de la variable $user, y que pass sea 1.
if($_COOKIE['usuario'] == $user && $_COOKIE['pass'] == 1)
{
echo "Administración";
}else{
echo "Acceso Incorrecto";
}
?>

Bueno hay que explicar unas cositas de este ejemplo, primero: lo que codifica y después cifra es el nombre de usuario en este caso "admin". Tenemos que saber cómo sacar este nombre de usuario ya que por ejemplo, puede contener el nombre y apellido del administrador, una vez que tenemos el usuario tendríamos que codificar primero en base64 y después cifrar en md5. Como no somos magos para adivinar el usuario tenemos que ver la forma de poder sacarlo, puede ser un nombre de usuario por default (como admin, administrador etc..) o sino nos podemos fijar quién postea en la web, por ejemplo... en la mayoría de los Blogs que son pre-fabricados dice el usuario que posteó.

Supongamos que tiene como usuario "admin" (como el script de arriba) entonces codificamos y ciframos el usuario, una vez hecho creamos la cookie:

javascript:document.cookie="usuario=db69fc039dcbd2962cb4d28f5891aae1; path=/"; document.cookie="pass=1; path=/";


#Solución:

Ya no es recomendable usar cookies para el acceso de un login, yo recomiendo que utilicen sesiones, y en lo posible también un token.



Links recomendados:

You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login<-- Cookies Manager+



Autor: Pablo La Rocca

Fuente: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login

Fuente: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login


Fue descubierta una vulnerabilidad en el plugin WordPress SEO by Yoast que cuenta con mas de 14 millones de descargas. Según el sitio oficial del plugin, existe una vulnerabilidad de Blind SQL Injection - descubierta por  Ryan Dewhurst - el mismo que desarrolló el scanner de vulnerabilidades de WordPress (WPScan).

La vulnerabilidad afecta a la versión 1.7.3.3 y a todas las anteriores, pero no cualquiera puede explotar esta vulnerabilidad; ya que es necesario tener permisos de administrador, editor o algún tipo de permiso que nos deje acceder al administrador, mas precisamente al archivo "admin/class-bulk-editor-list-table.php" que mediante la url se accede desde "admin.php?page=wpseo_bulk-editor".


Líneas afectadas:

Line 529:

$orderby = ! empty( $_GET['orderby'] ) ? esc_sql( sanitize_text_field( $_GET['orderby'] ) ) : 'post_title';

Line 533:

order = esc_sql( strtoupper( sanitize_text_field( $_GET['order'] ) ) );

Los parámetros GET llamados "orderby" y "order" no estan filtrados correctamente por la función "esc_sql" la cual se usa para justamente filtrar SQL Injection. Por lo tanto se puede explotar, por ejemplo de esta manera (PoC):

You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login

Y usando SQLMap:

python You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login -u "You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login" --batch --technique=B --dbms=MySQL --cookie="wordpress_9d...; wordpress_logged_in_9dee67...;"


Tal como mencionamos anteriormente, para poder hacer esto necesitamos privilegios pero.. ¿Qué pasaría si intentamos hacer un CSRF (Cross Site Request Forgery) en conjunto con Blind SQL? Por ejemplo, mandarle un link al administrador el cual el contenido del link sea el fallo de Blind SQL y que la consulta ejecute la sentencia para agregar un usuario administrador a la base de datos. De esta manera si logramos engañar al administrador y, si el sistema WordPress no posee un buen filtrado de CSRF, posiblemente tengamos exito y se agregue un usuario a la base de datos que nos permitiría tomar el control del WordPress.


Veamos cuantos sitios hay con este plugin en este momento en google: inurl:"page=wpseo_bulk-editor"




Solución:

Actualizar el plugin You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login




Fuente: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login

a simple vista con lo q comentas, creo q no puedo saber de que se trata hasta no intentar, sin embargo eso es un error SQL,  habria que ver porque se produce, capas que en la consulta utiliza la cookie para comparar o anda a saber para que la usa.

lo que si estoy seguro que a ese codigo le falta un if isset jaja. para comprobar si la cookie existe.

saludos

en form pone method='POST' ....

no se entiende la pregunta. No decis si es una web o una aplicacion de escritorio, en que lenguaje esta, y que es eso de "por cambio de ip". y despues haces otra pregunta que tampoco se entiende..., si formulas bien las preguntas, te podremos ayudar.

No vi el codigo del script, pero...  sirve solo si queres scanear url x url??, sin embargo es bastante dificil encontrar un RCE en esta epoca...

buen post, pero me estuve fijando y habre puesto 30 webs para ver si habia alguna vulnerable, y no salio ni 1. Testeado con la web publicada para testear...

Ya no habran mas webs vulnerables??, o el testing no funciona bien?, solamente queria probar con 1 aver que onda...

ami me dice que el correo gmail es incorrecto...., el cual en realidad no es incorrecto, por lo cual no me deja registrarme

y me da paja registrar una cuenta hotmail xD, una lastima xD

si lo llegas a subir seria mejor   

Exelente!!!

Lo que deberias cambiar es la 4er imagen, es la misma que la 3da, deduzco que te habras confundido.

Saludos!

la primero variable llamada cantidad, no esta tan errada. La segunda variable si esta errada.

De cualquier forma, te aconsejo que para probar las consultas utilizes directamente mysql, por ejemplo en un phpmyadmin, o si tenes acceso por consola a mysql tambien lo podes probar, se te va a ser mas facil y rapido....

En este momento no tengo acceso a nada para probar y darte la consulta correcta.

Sin embargo fijate si pones solamente esto:

SELECT COUNT(*) FROM libros WHERE libro  LIKE '%".$search."%'

Primero...Fijate si ahi funciona bien, Si lo pongas en algun sistema de los que te dije remplaza la variable $search por lo que quieras buscar.

Si llega a funcionar.. prueba.. asi...

SELECT COUNT(*) FROM libros WHERE (libro  LIKE '%".$search."%') AND (type = 'infantil') AND (id = '".$libroseccion['libro_id']."')

Aver..., un snifer no vas a poder poner en la maquina del atacante, como crees q lo lograras?, ademas la pregunta principal esta orientada a que queres protejer tus CLIENTES de este tipo de ataques..., que colocaras un snifer a cada atacante?? xDD...

Por eso dije lo del sniffer en el servidor web. Que puede ser mas logico. ya que podrias controlar mejor las entradas y salidas.

Igualmente nose porque se esta haciendo extenso este tema. Fleshed dice que tiene acceso al CPANEL, es tan simple como entrar a los archivos php y buscar el de configuracion del scam, ahi vas a tener la respuesta.

You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login

You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
Si logras tener acceso directo puedes montar un sniffer de por medio y ver a donde envia los datos

Regards,
Snifer

Este sniffer lo colocaría en la supuesta "maquina victima"?

Gracias por comentar.
Saludos

No, creo q a lo que se refiere es un sniffer en el servidor que esta el scam, me parece.

De cualquier forma, la mayoria estan programados en PHP, por lo cual si sabes php y lees el codigo (ya que dijiste q tenias acceso al panel), vas a entender adonde lo envia. No todos los scam son iguales, y seguramente vas a encontrar muchos q son diferentes, si queres encontrar un patron en comun, olvidate, no es una solucion buena.

generalmente existe un archivo con extencion X, supongamos .php, el cual tiene el mail del atacante....


otro factor tambien puede ser q guarde los datos en el mismo servidor en un TXT, escondido por algun directorio...

Como lo pensas evitar eso?? (pregunta que te hago.)


Yo mi opinion personal es darle seguridad al servidor/web para que no tengan acceso. Porque si vos evitas el pishing de otra forma, corres el riesgo de que rooteen el servidor y cometerian su objetivo igual

te hago una consulta...


set USERNAME informix <- nombre de la máquina OS GNU/LINUX

ahi pusiste ya el nombre de usuario, vos ya lo sabias no?, osea para el q no lo sabe, le deberia hacer brute force o como lo sacas??.

Otra mas..

Vos sacaste X cantidad de hosts con el puerto 22 abierto, en caso de lanzar el exploit a todos ellos, hay que ponerlo de forma manual, ip por ip? o hay una forma automatizada que envie el exploits a todos los hosts q allan detectado el puerto 22???

No le veo sentido, si sabes que te estan por robar la contraseña o sospechas, lo menos q vas a poner es un espacio, directamente pones una contraseña erronea y listo.

Sin embargo, siendo yo el atacante, y si la victima me pone un espacio, me daria cuenta al instante de copiarlo, cuando se copia se selecciona todo en color azul, por lo cual el espacio se ve claramente, el atacante tiene que ser muy despistado para no verlo, en el caso de que no lo vea, cuando tira error de password, lo puede poner tranquilamente con el teclado a mano, suponiendo que tiene 20 passwords, y 1 o 2 tienen espacio o son incorrectas, al atacante no le va a molestar escribir esas 2 contraseñas a mano.

Por lo cual no lo veo efectivo el metodo que comentastes.

Es mi punto de vista..., ademas estas subestimando al atacante...

Antrax, me genero dudas, se supone que la nanostation m2 alcanza una vista directa de 5km, como hiciste para que alcanze 10km mas de lo que supuestamente alcanza por defecto.??.

Por otro lado, vos tenes una antena aparte?, osea la conexion la tenes asi: antena->nano->router. ?? o tenes asi: nano->router??

y de paso preguntarte que router tenes??, yo tengo un adaptador alfa de 1000mw (el original)

gracias!

No existe hasta ahora, o no se a dado a conocer.

Lo que si te puedo recomendar, es aplicaciones que bloquean si te llaman numeros desconocidos o privados. Si tenes android la vas a encontrar facil ya que no recuerdo el nombre.

Entonces van a tener q dar a conocer el numero, sino nunca se van a comunicar con vos.

Otra cosa que podes hacer es joderlos a ellos. Todos los celus tienen redireccionamiento de telefono..., Si tu sabes que en X momento llama  o va a llamar alguien para joderte, lo que haces antes es redireccionar tu numero a otro, entonces cuando llama esa persona, atendera la persona a la cual redireccionaste tu numero.

You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
Navegando me tope con esto, quizas te sirva:

Tenes que sacar la batería y vas a ver un código de IMEI, en mi caso es : 352417058969627, solo sirve para un cel, y cada uno tiene un código propio..tenes que prender el cel SIN CHIP. y poner para marcar una llamada, pones al principio "#pw+" y luego el código..y quedaría algo así: #pw+352417058969627, le agregas un "+" y el numero 1 y pones "#"..va a quedar así: #pw+352417058969627+1# ..cuando llegues a apretar por ultimo el "#" automáticamente se desbloquea.

Para introducir la # (almohadilla) debe pulsar la tecla con ese símbolo (abajo a la derecha).
Para introducir la letra p debe pulsar 3 veces la tecla * (asterisco).
Para introducir la letra w debe pulsar 4 veces la tecla * (asterisco).
Para introducir el signo + debe pulsar 2 veces la tecla * (asterisco).

antrax eso no es universal, cada imei tiene su codigo de desbloqueo. Fijate en la parte que dice "solo sirve para un cel, y cada uno tiene un código propio..". Ese codigo se genera depende el imei.

Lo que dice el texto o lo que explica es como colocar el codigo, que seria asi: #pw+CODIGO+NUM#  el NUM puede ser remplazable del 1 al 7, eso es tambien depende de lo generado. No siempre es un numero 1 como muestra en tu ejemplo.