Hola que tal!

estuve aprendiendo un poco de python, y para practicar estoy haciendo un programa el cual tambien me viene bien.

El programa lo que hace basicamente es reemplazar un texto por otro en uno o varios archivos. La funcion ya la programe y esta andando bien, mi problema es pasar los parametros.

Necesito que el usuario por consola pase los parametros por ejemplo python No tienes permitido ver los links. Registrarse o Entrar a mi cuenta -a archivo -t typo -cnum 0 etc.

Se que suena basico, pero no lo logro hacer por completo., intente con un for a sys.argv pero funciona solo en parte, no me llega a servir, hay parametros q no son obligatorios.


gracias!

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: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

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: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
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:

No tienes permitido ver los links. Registrarse o Entrar a mi cuenta<-- Cookies Manager+



Autor: Pablo La Rocca

Fuente: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

Fuente: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta


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):

No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

Y usando SQLMap:

python No tienes permitido ver los links. Registrarse o Entrar a mi cuenta -u "No tienes permitido ver los links. Registrarse o Entrar a mi cuenta" --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 No tienes permitido ver los links. Registrarse o Entrar a mi cuenta




Fuente: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta