jueves, 31 de mayo de 2018

Comprobar la seguridad de tus servidores

#DISCLAIMER
/*
Esta entrada la hago para comprobar la seguridad y algunas configurciones que pueden llevar a fallo en nuestro servidor. Este es un post con un objetivo académico y educacional. Ya he dicho que es para comprobar la seguridad de TU servidor, no del servidor del vecino, por lo que no me responsabilizo del uso que le podáis dar, panda de cabrones.

Además he estado durante unos cuantos días pensando si hablaba en esta entrada también sobre cómo fortificar el servidor, pero al final he decidido dejarlo para otro post que vendrá más adelante.

*/

Los servidores son una de las partes más críticas en una organización. Muchas veces basta con que caiga el sevidor central para generar un caos enorme a nivel de red en la organización en cuestión. Yo en este post no voy a enseñar cómo comprometer a un servidor en todos los casos, voy a hacer una especie de guía, un procedimiento que podéis seguir en las auditorías que os toque hacer o con los servidores que os montéis.




Yo para este post he utilizado un Debian 8 con un servidor Apache 2.4.10, MySQL y en la que he montado un Wordpress 4.9.6. El Wordpress tiene una configuración por defecto, está todo recién instalado para ir modificándolo todo en un post que estoy preparando sobre hardening de servidores.


¿Cuál es el problema cuando nos podemos a realizar una auditoría? Pues que muchs veces caemos en el fallo de ver que al tirar de Nmap, nos muestra por pantalla un Apache 2.4.25 y cuando nos vamos a la lista de releases de Apache y vemos que la última versión de la 2.4.x es la 2.4.33  del 17 de Marzo de 2018 ya empezamos a aplaudir porque creemos que es vulnerable.

Esto no es siempre así, ya que si nos vamos a la lista de releases estables de Debian, vemos que para Debian 9{última versión} la versión de Apache es la 2.4.25, que es stable, está actualizada y por tanto no es vulnerable.

Este ha sido solamente un ejemplo, pero que nos suele ocurrir //A mí al primero que le ocurría y muchas veces aún me sigue ocurriendo. Este fallo en el pensamiento, creo que se debe a que en muchas CONs los ponentes son confusos o no explican este matiz del todo. Muchas veces puede ser por ir apretados de tiempo, lo entiendo, no es por acusar a nadie.

Tirando de Nmap 

El primer paso a aplicar, sería tirar de Nmap contra tu servidor. Aquí, podemos usar la funcionalidad tan buena que tiene Nmap de ejecutar scripts. En este caso vamos a empezar ejecutando el script con la opción por default. {Para encontrar la lista completa de scripts que se pueden ejecutar en Nmap, deberéis escribir locat nse | grep script}



Aquí observamos varias cosas curiososas. Para empezar, tiene 3 puertos abiertos bajo tcp {recordemos que tendríamos que comprobar también los puertos bajo udp}. El primero es el servidor ssh, que lo tiene en su puerto por defecto, el 22; algo que en la entrada del hardening cambiaremos.

Como otra curiosidad, vemos que en el puerto 80, tiene montado un Worpress 4.9.6, que es la versión más actual, pues es del 17 de Mayo de 2018 tal y como apreciamos en la lista de relases de Wordpress.

También nos deja una puerta abierta a entrar por escritorio remoto, algo bastante peligroso en caso de dar con la contraseña del sistema de este servidor montado bajo un Debian.


Otro aspecto muy interesante, es ejecutar Nmap con un script con la opción auth, para tratar de encontrar, como en este caso ocurre, el usuario de Wordpress, por lo que cuando más adelante usemos la herramienta Hydra, ya es un campo que conocemos.

Además, existe el problema en que el resultado de SSH no aparece un mensaje como


============================================================
"Supported authentication methods:
publickey"

============================================================

Esto nos permitiría poder entrar obteniendo la contraseña mediante ataques de fuerza bruta o diccionario, ya que permitirá cualquier autenticación aunque no se tenga certificados de clave pública. Esto nos motiva para hacer uso de Hydra.

Nikto

Vale, ya hemos visto por qué caminos tenemos un posible acceso, en este caso tanto por SSH como por web. Vamos a tratar de explotar lo máximo posible la web. Para realizar esto, Nikto escaneará plugins e irá encontrando vulnerabilidades en el servidor.


Una vez que lo lanzamos, vemos que nos muestra respuestas como que la versión de Apache está outdated, desactualizada, que el anti-clickjacking o la protección XSS no están habiliadas,etc.


Revisaremos bien la respuesta de Nikto para ver si encuentra alguna vulnerabiliad que podamos explotar o si podemos aprovecharnos de algún archivo por defecto del servidor Apache como nos reporta Nikto con el README.


El reporte no nos dice que TRACE esté activo, pero como puede dar falsos positivos, podemos comprobarlo en un momento. Como era de esperar, no estaba habilitado, por lo que no seremos susceptibles a ataques de Cross Site Tracing.

Aunque no esté activo, sí que nos da información sobre la máquina en la que está montada el Wordpress. En este caso, un Debian, que era una de las cosas que nos podía faktar por conocer.


Esta es la información que muestra OWASP sobre este posible ataque, por lo que si tenéis este método activo en vuestro servidor, será mejor que lo desactivéis para que un atacante no pueda ver lo que se está recibiendo desde el otro punto final.

Automatizando y comprobando posibles vulns con Golismero

Golismero es una herramienta muy usada por pentesters, ya que reúne varias de las herramientas de seguridad más utilizadas, además de que con su opción -o te monta un html si lo deseas para que tengas toda la información obtenida de una forma más gráfica. Podéis descargar golismero de la siguiente forma.

apt-get install python2.7 python2.7-dev python-pip python-docutils git perl nmap sslscan

git clone https://github.com/golismero/golismero.git 
cd golismero 
pip install -r requirements.txt 
pip install -r requirements_unix.txt

Una vez instalado lo podremos ejecutar para que realice un escaneo completo con la instrucción 

python golismero.py scan [IP || HOST] -o /var/www/html/reportes.html



Tardará un poco puesto que lanzará Nikto, Nmap, Ip Geolocation,etc. Pero cuando termine, podremos irnos al navegador y escribir [IP]/reportes.html y veremos todo lo que ha ido obteniendo Golismero de una forma gráfica.


Ojo, reitero que no tenemo que fiarnos de todo lo que nos muestre Golismero, y que puede dar falsos positivos. La información que nos muestra es para que sepamos por dónde tirar, pero tenemos que comprobar que efectivamente se pueden aprovechar cada vulnerabilidad encontrada.


Iremos viendo cómo nos muestra un listado de enlaces con posibles vulnerabilidades o debilidades. Esta herramienta está bastante bien porque incorpora las grandes herramientas en una y además muestra la información de una forma bastante visual.




Si vamos a uno de los enlaces en los que nos dice que sufre de fuga de información, veremos que nos muestra la versión del Worpress. Alo que ya sabíamos pero que ahora podemos confirmar con mayores evidencias.

Comprobando si existen SQL Injection en nuestro server

Las vulnerabilidades de tipo Injection es una de las tareas pendientes cuando se trata de un servidor web. Esto lo demuestra año tras año OWASP con su TOP 10 de vulnerabilidades. Si comparamos lo obtenido en 2013 y 2017, vemos que en el puesto 1, aún siguen los ataques de tipo Injection.





Por esta misma razón, será una de las cuestiones que más tengamos que revisar. Para esto, podemos utilizar la herramienta sqlmap.


Tendremos que ir viendo lo que nos muestra por pantalla esta herramienta y ver si es vulnerable o no. En mi caso me salió el siguiente mensaje mientras realizaba l prueba.


Esto lo que quiere decir es que o no ha encontrado vulnerabilidades con los parámetros enviados o que está protegido por un Firewall Web.
Obteniendo contraseñas con Hydra
Como vimos anteriormente con el caso del SSH del servidor, permitía las conexiones sin certificados digitales, por lo que será importante para nosotros obtener la contraseña que se está usando para entrar al sistema.
Nosotros lo que tendríamos que hacer sería lanzar Hydra con los diccionarios que tengamos o que hayamos generado. Yo aquí, como ya sabía el usuario y la contraseña, los he introducido directamente, aunque algo recomendable sería lanzar los diccionarios que dispone Kali Linux para ver si obtendrían o no la contraseña y el usuario y en caso de obtenerlo, cuánto tiempo tardarían. 
Comprobando la facilidad de realizar un DoS 

A ver, aquí siempre hay mucha confusión, incluso por gente que se dedica a Seguridad que se empeña en llamar DoS a lo que no es, ya que muchas veces un servidor cae por tener malas configuraciones.
Tened en mente que un servidor no es solamente el sistema operativo sobre el que está montado un recurso como un FTP, una página web, un DHCP, un DNS,etc. No. Un servidor es el sistema operativo, el servidor Apache con sus configuraciones, la Base de datos con su configuraciones, el código de la web ¿Es redundante el código de la web? ¿Hay mucho entorno gráfico que con menos transmites lo mismo y encima el rendimiento sea mayor?  Todas estas son preguntas que deberemos  responder en función de lo que vayamos encontrando en los archivos de configuración o en el código de la web o configuraciones del sistema operativo.


En esta entrada no voy a entrar en temas de explicar cada parte  de cada archivo de configuración. En este caso vemos el MaxKeepAliveRequest. En el mismo archivo de configuración explica lo que es, y no es otra cosa que el número máximo de consultas que va a permitir el servidor Apache.


Si entramos en el archivo de configuración de MySQL, tendremos que tener cuidado de que no ponga 0.0.0.0 en el bind-address para que no pueda entrar cualquiera a la Base de datos.




Si seguimos bajando por el archivo, veremos que en la opción de max-connections, tenemos por defecto como comentario, por lo que no tendríamos límite de conexiones a la vez en la base de datos.
Esto es una mala configuración, ya que Apache permite 100 consultas, pero la Base de datos no tendría límite, por lo que se crea un cuello de botella de libro.
A ver, esto nosotros lo podemos controlar porque es nuestro server, aunque sino lo fuese, recordemos que tenemos la contraseña y el usuario para acceder por SSH.
Este problema puede desencadenar en una "DoS", aunque no es fallo del servidor ni de la web, es una mala configuración, el Apache no cae. Es el que crea el cuello de botella con respecto a la Base de datos, pero el servidor no cae. Reiniciamos y sigue funcionando todo.

Tener clara esta idea es vital. Un servidor no cae, es muy difícil que caiga, y si la web se cae, puede er por mil cuestiones, ya que una web no es solamente la web, es Apache o Nginx, es la Base de datos, es el Kernel. Es una combinación de cosas, no es un problema único.


Por si queremos buscar los demás límites máximos de la base de datos, es tan sencillo como hacer un cat my.cnf | grep "max".


Para las pruebas de DoS que queráis hacer sobre vuestro servidor, podéis usar la herramienta de Apache2-utils ab, que es de fácil uso. con -c indica el nivel de concurrencia y -n el número de peticiones. Aquí todas las opciones.

Como vemos en el servidor con el comando netstat -plan|grep :80 | awk {'print $5'} | cut -d: -f1 |sort| uniq -c| sort -n veremos las peticiones que llegan, en este caso de 50 en 50 hasta 100, por lo que, en teoría, no debería caer ¿no?


Pues lo cierto es que si te vas a la web, no carga, y si tratas de ejecutar cualquier comando en el terminal del Debian, te va a ser difícil porque empieza a pillarse. Tened en cuenta que estamos realizando pruebas de estrés.

Esto ocurre, entre otras cosas, porque los archivos de configuración de Apache y MySQL están por defecto y sn contradictorios, además de que no se disponen de sistemas de caching y que encima estamos con un Wordpress, que sin caching, al final cae.


Otra herramienta muy útil para realizar estas pruebas de DoS es UfoNet. Aquí podéis ver mejor cómo funciona UfoNet, aunque para casos básicos es muy sencillo de usar, con -a indicamos el sitio a atacar y -r indica el número de veces que cada host atacará a la víctima.


Y tendremos que esperar y ver cómo reacciona nuestro servidor. Con netstat lo podemos ver aunque también sería aconsejable el uso de Mod-Status para ver desde dónde y qué IPs nos están atacando.

Creo que si se siguen los pasos enunciados en este post, podremos tener una visión general de los problemas de seguridad y configuración que puede tener nuestro servidor. Conocer los fallos que puede tener nuestro server es importante para no perdernos mucho al aplicar las soluciones, unas soluciones que os dejaré más adelante en otro post. Me llevará un tiempo preparar esa entrada, así que a lo mejor para mediados de junio está lista, aunque no prometo nada.

¿Hackeamos el Mundo?

miércoles, 30 de mayo de 2018

Smart Fridge, una frigorífico/despensa inteligente

Con la informática podemos automatizar casi cualquier proceso de nuestra vida cotidiana para hacernos la vida más sencilla o más cómoda. Esto ya lo dijo Turing, que cualquier parámetro que fuese parametrizable de nuestra vida por nosotros, un ordenador podría cuantificarlo también.


Con esto en mente, podemos analizar cualquier aspecto de nuestra vida y tratar de mejorarlo de la mejor manera posible. Muchas veces las soluciones se te ocurren por arte de magia cuando estas haciendo tareas cotidianas como si de una película se tratase.

Esta idea se me ocurrió mientras mi pareja y yo estábamos viendo una serie en Netfilx. Todo genial, hasta que me dijo lo siguiente:

"Manu, cielo, mira si hay cervezas en la nevera, que no sé si hay y a mi me gustan muy frías"

Aquí aclaro dos cosas:
  1. Mi pareja siempre me dice "Manu, cielo," cuando quiere que haga algo. Es un inicio que me mantiene alerta a lo siguiente que va a decir, es un mensaje SYN para mí.
  2. Yo no bebo alcohol, pero mi pareja sí.
 A mí, particularmente, cuando estoy viendo una serie después de un día entero de trabajo e investigación, no me suele agradar mucho la idea de levantarme por cosas como esta, pero como esto es una pareja, voy sin problema. Y fue mientras me levantaba del sofá que se me ocurrió la idea y salí corriendo a apuntarla.

Se me ocurrió que podría consultar el estado del frigorífico y la temperatura de las latas desde el móvil mientras estaba en el sofá. Esta idea la apunté rápidamente y la empecé a desarrollar en papel.

Después de tenerlo toda la base en papel, siempre, para proyectos de este tipo, empiezo a hacerlos en Arduino para tener una ligera idea de cómo quedaría. Así que fue a una de las tiendas de electrónica que tengo relativamente cerca de casa, pillé una placa Arduino y unos conectores macho-hembra y me puse a enrredar hasta que lo saqué.

Para desarrollar la idea, lo primero que necesitaba eran botellas y latas, asíq ue las que íbamos gastando en casa mi pareja y yo, las guardaba por mi habitación hasta que saqué algo bastante avanzado del proyecto.


Cuando comecé con el proyecto, quité cosas de nuestro armario para meter ahí las latas y botellas, además de alguna caja de Oreo como se ve en la imagen.

Nota: Os podéis imaginar el rostro de felicidad en la cara de mi pareja, la cual estaba muy "contenta" porque hubiese quitado ropa de nuestro armario para guardar ahí el proyecto. Ya no duermo en el sofá ni nada.


Aunque este esquemático con las conexiones sea muy cutre {soy partidario del Keep It Cutre} podéis apreciar que reutilicé una idea que ya desarrollé para GAURUINO, más concretamente, para la idea del parking. Ahí utilicé un sensor de ultrasonidos para que, si había un coche a menos de una distancia determinada, eso era un indicador de que esa plaza no estaba libre y si no había coche a menos de esa distancia, la plaza estaba libre. Pues aquí hice lo mismo, pero con la sutileza de que si hay "algo" a menos de una distancia, es que SÍ hay ese producto y al revés. Una idea simple, que es verdad que requiere de tener toda la nevera siempre con el mismo orden, pero una idea que funciona.


Para conocer la temperatura de una botella o una lata, tendría que meter un sensor de temperatura tipo DHT11 dentro de la boteela. Yo lo que he hecho con una botella ya usada es abrirla por arriba, meter el sensor con los cables y esa parte de arriba volví a pegar tal y como se ve en la foto. Espero que también veáis el sensor dentro de la botella.



Para el sensor de ultrasonidos me hice una plataforma con un mecano de cuando era pequeño. Esta plataforma me iba a servir para sujetar bien el sensor ultrasónico.


Ya tenía sujeto el sensor de ultrasonidos y el sensor de temperatura y humedad  dentro de una de las botellas, por lo que era hora de probar el código.


Tal y como se observa en esta imagen, cuando detecta que la botella de Pepsicola {pepsi, pagadme por esta publi} obtiene la temperatura de la botella, cuando no, simplemente muestra que no hay pepsicola. También he grabado un vídeo con la PoC que subí a mi cuenta de Instagram.



 Ya tenía controlada este despensa/frigorífico, pero claro, para saber si quedan pepsicolas y su temperatura para saber si hay o no, tendría que abrir igualmente la puerta de la nevera, ya que el ordenador con el Arduino lo tendría que dejar dentro, y eso es una mierda. Bien es cierto que puedo utilizar una pantalla LCD o una pantalla de una tablet que ya no uso, pero el problema sería ir hasta la cocina, aunque el problema del gasto energético por abrir y cerrar la nevera se quita, eso sí.

Ahora venía lo gracioso, el mostrar los datos obtenidos por la web. Esto con Arduino, ya sabéis que no es fácil, o al menos no tanto como en Raspberry.


Si queremos seguir con Arduino, vamos a tener que sudar un poco, ya que tendremos que realizar la conexión al Arduino para sacar sus datos mediante un programa en Java que, una vez obtenga los datos, los base a un CSV o a una Base de datos. Os dejo un vídeo donde se explica cómo hacer esto.

La otra opción-que es por la que opté yo- es por cambiar todo el proyecto hacia Raspberry, ya que te ahorras mucho tiempo, y todos los problemas vendrán más en pelearte con Python-que no es muy complicado- y poco más.


Ya os digo, si os vais a pasar a Raspberry, tenéis 2 opciones. La primera es controlar cada componente con Python tal y como se ve en la imagen anterior, que son 2 códigos que se usó para GAURUINO para la parte que iba con Raspberry. Como veis, es más elegante este código, ya que en pocas líneas termina, aunque también es verdad que es encender y apagar un led.


Aquí ya vemos algo más elaborado, aunque en muchos aspectos es casi lo mismo que arduino. El pin lo declaras igual, y posteriormente dependiendo de la humedad, lo metes en el if y hará una cosa u otra.


Con shellscript es más o menos lo mismo, ya que en Linux todo es tratado como un archivo, por lo que todo queda en un echo 0 || 1 >/aya/class/gpio y el valor del gpio correspondiente si quieres encender o apagar algo. Para los demás casos, serían cosas muy parecidas, declaras los variables para los pines y todas las operaciones que tengas que hacer, tendrás que hacerlas con let. Al fin y al cabo es lo mismo, aunque hay mucha gente haciéndolo en Python en lugar de ShellScript.

Yo apuesto siempre que puedo por ShellScript, aunque vosotros como os veais más cómodos.

Pues para este proyecto de frigorífico sería lo mismo, pero ahora en Raspberry, y cuando se obtengan los datos, pasarlos a un archivo CSV o de Base de datos.

Posteriormente, con un bucle while infinito, en otro script leeríamos cada 5 minutos por ejemplo, las nuevas actualizaciones en el archivo de la base de datos y lo subiríamos a mysql con source ARCHIVO.

Finalmente, tendríamos que crear un archivo PHP con la web y un archivo PHP con la consulta a la base de datos que se relacione con el primer PHP o HTML, en el que el usuario, mediante un formulario sencillito, escriba el nombre de un producto, y al pulsar Enviar, le muestre la salida del SELECT product_name FROM productos.frigo WHERE product_name like '[String enviada por el usuario]'.

 

Con esto creo la conexión, la base de datos, tablas e inserto datos. En nuestro caso, esto ya estaría creado.

Como tendremos nuestro Apache montado e iniciado, tan sólo tendríamos que ir a otro equipo y buscar con el formulario que se haya creado para esto.


Que se enviaría a un PHP donde recibe la consulta y la mete en el SELECT.


Aquí estaría mostrando toda la tabla, que es algo que a nosotros nos puede interesar, ya que nuestra base de datos tendrá el nombre del producto y la temperatura.


Esta sería otra forma de mostrar los datos de la base de datos con, además, las cabeceras.

Con nuestro Apache, y conociendo la IP de nuestra web que hemos creado, podríamos acceder desde cualquier equipo. Por ejemplo, si estoy en mi casa, abro un navegador, escribo la IP y el archivo en cuestión y realizo la consulta.

Es verdad que si lo hago en PHP y abro la web desde el móvil, a lo mejor los datos que almacene en la tabla puede que no se vean del todo bien. Esto se puede solucionar con Wordpress y un tema que sea responsive, aunque yo lo he hecho en PHP directamente y no se me ve mal, ya que solamente son 2 campos los que muestra.

Dependiendo el móvil, a lo mejor hay que girarlo para verlo mejor, pero vamos, que desde ordenador se ve bien y desde móvil depende del dispositivo, desde el mío tengo que girarlo y desde el de mi novia, se ve bien sin girarlo.

Así ya sí que puedo consultar si hay o no hay refrescos o cervezas y además puedo comprobar su temperatura. Yo esto lo he probado sin meterlo en el frigorífico, solamente en una especie de despensa que tenemos, y la verdad es que funciona bastante bien.

¿Hackeamos el Mundo?

martes, 29 de mayo de 2018

Dalas y su lío con el hacking

Voy a tratar de elaborar esta entrada de forma objetiva. Prometer ser larga, ya que tengo mucho que comentar. También dejaré al final una reflexión que yo tengo sobre esta persona en base a acontecimientos como este, el que hoy voy a comentar en este post. Hace casi 2 años ya comenté de forma muy breve los fallos que el señor Dalas Review cometió cuando habló sobre Hacking. Pues han pasado 2 años y parece que nada a cambiado. Ni un sólo vídeo rectificando y aclarando sus fallos ni nada, así que voy a tratar de comentar, ahora en detalle, sus fallos cuando ha hablado sobre hacking en su canal de Youtube.


Dalas hace poco subió un vídeo en el que previamente pidió la contraseña de sus redes sociales a sus fans, pero antes de eso, ya tenía-al menos 2- vídeos donde hablaba sobre hacking, más concretamente sobre cómo se puede hackear una cuenta de una red social como Instagram.

Los vídeos en sí, a primera vista, parecen interesantes, ya que este señor mueve mucha audiencia y eran buenas oportunidades para distribuir información relativamente buena sobre el tema, ya que es algo importante. Pero claro, Dalas tenía 2 opciones, informarse debiadamente, o tirar de tópicos y de 4 chorradas que se leyó en los primeros blogs en los que hablaban sobre el tema. Eso, pasa factura.

Os voy a ir dejando algunas de sus afirmaciones que realiza en estos 2 vídeos e iré comentando cuál es o son los errores que ha cometido.


Afirmación 1:“Os voy a dar los trucos para que nadie os pueda hackear nunca más”
La seguridad Informática a día de hoy es imposible al 100%, sobre todo cuando metemos al tiempo en la ecuación, ya que puede que estés seguro hoy al 100%, pero mañana, por no actualizar un software de tu sistema operativo, verte afectado. Por ejemplo. Pero bueno, a lo mejor tras varios años de investigación, él ha dado con una solución o, al menos, un modelo matemático que pueda servir.

Afirmación 2:"Cada vez salen más grupos de ‘hackers’ entre muchas comillas que en realidad no tienen ni puta idea de hackear nada y que son unos críos…"

Cuando habla de "hackers", utiliza la palabra en un contexto ambiguo, donde lo mismo significa crío que cree que sabe hackear -script kiddie es su nombre correcto- que un cibercriminal, pero en ningún momento utiliza la palabra con su significado real, el de investigador y pasionado por la informática que trata de mejorar la seguridad de la misma.


El IETF en el RFC1392 ya definió lo que es un hacker, y esta es una definición que yo suscribo, es más, cada vez que me refiero a la palabra "hacker", la utilizo en este contexto. Si alguien utiliza esta palabra de otra forma, estamos hablando de cosas distintas y no perderé mi tiempo en especificar que un hacker no es un cibercriminal.

Afirmación 3:"A veces esta gente sí que consigue hackear a gente, hackear entre comillas"

Con esto no sé a lo que se refiere, ya que si consigues tu objetivo, has hackeado, sea cual sea el camino seguido. Aquí no hay una sola solución, aquí importa el camino seguido, aunque es cierto que no es lo mismo currarte un ataque que buscar por Pastebin.

Afirmación 4: “El método más usado se llama EXPLOIT. Consiste en que te envían un enlace y lo que te salta es la página como la de inicio de gmail,twitter,facebook,etc...Así que tú confiado escribes tu correo creyendo que la envías a gmail,twitter, facebook cuando en realidad es la página creada por este ‘hacker’, entre comillas hacker”.

Aquí confunde por completo y se ve que no sabe muy bien que lo que ha explicado, se denomina Phishing y no exploit. Un exploit es un trozo de código que se usa para, por ejemplo, ponernos a la escucha como es el caso del multi handle. Pero al César lo que es del César, lo que es el Phishing lo ha explicado muy bien, sólo que ha confundido Exploit con Phishing. El fallo es garrafal, pero es lo que pasa cuando te lees las 4 chorradas que lees en el primer blog que pillas.

Pero lo que más me llama la atención, es que dice que este es el método más utilizado, pero en ningún momento aporta ninguna fuente que respalde lo que dice. Es cierto que el phishing se realiza mucho, ya que es uno de los caminos más fáciles para obtener una password, y posiblemente sea la forma más utilizada, pero no tenemos fuentes que respalden eso, o al menos Dalas no las ha mostrado.

Los que nos dedicamos a Seguridad lo sabemos nada más que por experiencia, pero tampoco he visto que en su vídeo haga una PoC de cómo se realiza un Phishing, algo que es relativamente sencillo de mostrar.


Yo para la prueba he usado un Apache Web Server en mi Linux Mint en el que he creado una web de login sencilla.


Si escribimos un usuario y una contraseña cualesquiera, se enviarán a una Base de Datos en MariaDB que me he montado.


En este caso, la seguridad a la hora del almacenamiento de datos confidenciales como puede ser la contraseña por parte de la web es una basura, ya que se está almacenando en texto claro.


Una capa extra sería almacenar esa contraseña con un hash. Para esto, se utilizan funciones sencillas, pero claro, utilizar MD5 no es seguro, ya que existen webs online que sacan el texto asociado a dicho hash en cuestión de segundos. Sobre esto ya hablé en este post, y la solución-que también la di en esta entrada- sería almacenar la password utilizando un hash con un salt para que así resulte mucho más difícil descifrar la contraseña.

Claro, que para el caso del Phishing, lo que vamos a hacer será una web con la apariencia de Twitter, Instagram, Facebook,etc. algo que con SET se hace en un momento. En este post donde mostraba cómo hacer un ARP  y DNS SPOOFING lo demostré. Enviabas el archivo con los hosts cambiados y ya está, la víctima solamente tenía que entrar a su red social favorita-en este caso lo hice con Twitter- y recibiríamos su contraseña.

Aunque si lo queremos hacer a mano, nos bastaría con dejar la web de tal forma que al pulsar en "Iniciar Sesión", la password se almacene en una Base de datos que controlemos nosotros y, por supuesto, sin hashear la contraseña para no pararnos mucho. Ya tendríamos la password.



Afirmación 5: “La forma de evitar esto es que no entréis en vuestras cuentas en páginas que no sean escribiendo la url arriba, es decir, gmail.com. No busquéis en Google y después hagáis clicks por si una de estas webs se ha conseguido posicionar bien y estáis regalando vuestra contraseña”.

Esta es una solución parcial, ya que tampoco te quita de problemas. Es cierto que te quita del problema de caer en ataques de Phishing que te puedan enviar por correo electrónico, pero si seguís este blog ya sabéis que le podemos buscar las cosquillas a esto. Algunas de las formas son:

-Ataque ARP y DNS SPOOFING
-Cambiar DNS del router de la víctima
      -HiitA
-Cambiar DNS del router de la víctima + certificado SSL

Afirmación 6:
“Cuando entréis, comprobad arriba que efectivamente es la página de Facebook, Instagram,etc entonces os podéis fiar, y si no pone https que indica que es segura y habéis accedido desde un enlace que os han pasado o algo parecido, jamás pongáis vuestra contraseña”.
Esta afirmación se niega por completo con la afirmación 5 y con la entrada Cambiar DNS del router de la víctima + certificado SSL. También recordar que la web sea HTTPs solamente es que los datos van cifrados en tránsito, es decir, desde el cliente hasta el servidor[sobre esto ya hablé en este blog]. Pero si consigo acceso a tu equipo por un software desactualizado y te instalo un keylogger{programa que detecta lo que escribes con el teclado} o utilizas un Windows y con el acceso a tu sistema utilizo unas sentencias básicas de Powershell que ni te tienes que saber, con tenerlas apuntadas basta para copiar y pegar; te podría robar la password aunque vaya en HTTPS.

Y de todas formas, este consejo si es en ordenador, puede pasar, pero ¿desde el móvil? ¿Quién ve la URL a la que te estás conectando? Nadie, y esto es culpa de las webviews, algo de lo que también he hablado en este blog.


Afirmación 7: “Esta no es la única forma, también usan unas webs que ‘prometen’ que te van a hackear el Instagram de la cuenta que escribas”
Vale, esto que dice es cierto. Esas webs que prometen que te van a sacar la contraseña del usuario que le pases son una estafa. Aquí estamos de acuerdo. No obstante, yo eché en falta que lo demostrase de alguna forma, ya que en teoría él se había informado debidamente{o eso dice}.
 Claro, que diga algo pero no lo demuestre, reduciendo algo al absurdo, no es que sea muy fiable{y esto él lo hace con varios temas, tomad nota}. O no demuestra lo que dice, o se queda a medias con una media verdad {caso de alguna afirmación anterior}. La demostración hubiese sido muy sencilla.
Con tan sólo analizar el código fuente de la web, se hubiese dado cuenta que, escriba lo que escriba el usuario, la web ya tiene siempre las mismas respuestas, algo que no es lógico, ya que si introduce un usuario que no existe, no tendría sentido que diga, por ejemplo, que el usuario está conectado. Un usuario que no existe no puede estar conectado. Tan sólo con esto, ya lo hubiese demostrado, y esto es algo que no es muy complicado de hacer, de ahí que me extraña mucho que diga lo que diga, ya que, o no se ha informado debidamente, o ha leído 4 tonterías en 2 blogs cualesquiera y sin fundamento y ya está.
Afirmación 8: “Existen los hackers de mierda y los de verdad que sí que dan mucho miedo”
Esto es lo mismo que una de las afirmaciones anteriores. Sin definir debidamente lo que es un hacker, parece absurdo que diga esto. Además, Charlie Miller, un hacker muy conocido, estuvo trabajando para mejorar la seguridad de Twitter, y no creo que mejorar la seguridad de Twitter, de miedo.
Afirmación 9: “La forma más eficiente es la que hacen estos hackers de verdad que hackean bases de datos de sitios como Linkedin, Instagram,etc.” 
Esta es una de mis afirmaciones favoritas y de las más fáciles de demostrar que realmente no se ha informado como debe.
Para esto, os debéis ir a la afirmación 4 de nuevo, ya que es ahí donde realizo una web con un formulario de login que envía los datos a una base de datos que tengo creada. Claro, los datos los envía por POST y en claro, por lo que la contraseña se almacena en la base de datos tal cual. Solamente ahí-y en un escenario más- sería posible que ocurra lo que dice Dalas, ya que si hackean la base de datos de la web de, por ejemplo Twitter, y almacenasen así las credenciales, sí que un atacante podría acceder y conocer las contraseñas sin problema.
¿Cuál es entonces el problema de su afirmación? Pues que esta no es la única manera de almacenar una contraseña en una Base de datos.
En el post fucking your bullshit code ya lo demostré, y como dije, una opción es-tal y como se ve también en la afirmación 4- almacenar la contraseña tras pasarle una función hash, como puede ser MD5.


Esto es un ejemplo de código y se ve como en $pass estoy utilizando la función MD5 para hashear la contraseña que se pasa por POST y posterormente almacenarla en la Base de datos.


El problema reside en que funciones de este tipo, son conocidos, por lo que se obtiene el texto claro en un momento con servicios online como MD5Hashing 
En este escenario también sería posible conocer la contraseña de los usuarios por esto mismo que estoy contando. Estos 2 escenarios son los que cometa Dalas en su vídeo, aunque hay un escenario más que se le "olvidó" comentar o, al menos, tener en cuenta.


 
Utilizar un hash + salt tal y como se ve en la imagen anterior. Es aplicar una función solamente, y esto dota a las Bases de datos de una mayor seguridad a la hora de almacenar información relativa a credenciales de usuarios.
Y este escenario es el que invalida la afirmación de Dalas, pues este escenario es que el utilizan la mayoría de sitios webs como Twitter, Instagram, Facebook,etc. Esto lo sabemos porque hasta en webs con CMS Wordpress, se utilizan estas funciones hash con salt. Podemos demostrar este punto si nos vamos a la base de datos de nuestro sitio en Wordpress y en la base de datos entramos en wp_users.

No mostrar todos estos escenarios posibles es meter miedo por meter, algo que no está bien. Ojo, no digo que avisar de determinada cuestiones sea malo, al contrario, es más, avisar -sobre todo a los desarrolladores- que gestionen correctamente su web y que las credenciales de sus usuarios la almacenen utilizando hashes con salt, me parece correcto, y prevenir de los 2 primers escenarios también puede ser interesante, pero también se debe avisar de este tercer escenario, que es el que usan casi todos los servicios webs.

Y hasta aquí lo dejo. He comentado solamente los fallos de uno de sus vídeos, pero la verdad es que llevo 2 días preperando este post y seguir sacando más me está cansando mucho, ya que es hablar sin informarse de absolutamente nada, siendo en muchos casos falaz y con medias verdades. Además, tengo que preparar otros posts que me van a llevar su tiempo también y no quiero perder más tiempo con este, porque la de tonterías que se dice por minuto, es bestial.

¿Hackeamos el Mundo?
Related Posts Plugin for WordPress, Blogger...

Entrada destacada

El server me sabe a poco.

Soy un fanático del Rock y de Debian . (Creo que voy a inventar Rockbian, que suena bien y todo xD) Llevaba tiempo queriendo unir estos 2 c...