https://www.perfil.com/noticias/reperfilar/hackeo-en-migraciones-es-una-nueva-modalidad-de-delito.phtml

Sin comentarios respecto al thumbnail que salió, asesino.

Gracias YouTube (?) !@!!

Como todo live demo tiene su errata -spoiler alert: en los comments la aclaración pertinente -. Puede fallar jaja.

Para anotarse completen este form.

¡Los esperamos!

Registrate acá

“La ofensiva hacker es similar a la que la semana pasada golpeó a otros gigantes de internet como CNN, New York Times, Twitter, Spotify y Google.”

Alguien los hackeó, es cierto, pero les cambió algo tan básico como los DNS en su proveedor de registro (comúnmente llamado registrar) y lo apuntó a un sitio de publicidad. Algo que seguramente ocurrió porque los administradores de Infobae debían tener infobae123 como contraseña en Register.com -o algo aún más trivial-….

Esto es lo que se veía durante el “ataque más grande de la historia de Infobae” en su whois:

Domain Name: INFOBAE.COM
Registrar: REGISTER.COM, INC.
Sponsoring Registrar IANA ID: 9
Whois Server: whois.register.com
Name Server: NS1641.ZTOMY.COM  –> DNS APÓCRIFOS
Name Server: NS2641.ZTOMY.COM  –> DNS APÓCRIFOS
Updated Date: 26-oct-2016
Creation Date: 05-apr-2002
Expiration Date: 05-apr-2020

Nótese la presencia de DNS extraños (asociados según domaintools a otros 500mil dominios…) y la fecha de Update, que casualmente coincide con el día de la fecha.

Ahora los ingenieros de todo el mundo de Infobae están arduamente trabajando para solucionarlo, claro. Hecho en el cual tan solo tuvieron que retomar el control de su propia cuenta y cambiar sus propios DNS.

Whois actual:

Domain Name: INFOBAE.COM
Registrar: REGISTER.COM, INC.
Whois Server: whois.register.com
Name Server: NS1.P27.DYNECT.NET  –> DNS REALES
Name Server: NS2.P27.DYNECT.NET   –> DNS REALES
Updated Date: 26-oct-2016
Creation Date: 05-apr-2002
Expiration Date: 05-apr-2020

Muy rico todo. Pero Infobae, se te fue la mano.

Esta aplicación es realmente una novedad ya que no se conocían aplicaciones Open Source que abarquen no solo los mecanismos internos de autenticación de los Sistemas Operativos, sino también aplicaciones como Firefox, Chome, Pidgin, etc.

Y una gran noticia es que no solo es OpenSource y soporta tanto Linux como Windows, sino que además resulta muy sencillo la creación de Scripts propios gracias a su estructura modular, especialmente útil a la hora de realizar auditorías específicas en algún Pentest.

Lista de programas soportados:

Windows:

• Adminsys
  • CoreFTP
  • Cyberduck
  • FileZilla
  • FTPNavigator
  • PuttyCM
  • WinSCP
• Exploradores
  • Chrome
  • Firefox
  • Opera
  • IE
• Chat
  • Jitsi
  • Pidgin
  • Skype
• Bases de datos
  • DBVisualizer
  • Squirrel
  • SQLdeveloper
• Mails
  • Outlook
  • Thunderbird
• SVN
  • Tortoise
• Wi-Fi
  • Wireless Network
• Mecanismos Internos del Sistema Operativo
  • .NET Passport
  • Generic Network
  • Windows hashes (LM/NT)
  • LSA Secrets

Linux:

• Adminsys
  • Filezilla
  • Variables de entorno
• Exploradores
  • Opera
  • Firefox
• Chat
  • Jitsi
  • Pidgin
• Bases de datos
  • DBVisualizer
  • Squirrel
  • SQLdeveloper
• Mails
  • Thunderbird
• Wi-Fi
  • Network Manager
• Mecanismos Internos del Sistema Operativo
  • GNOME Keyring*
  • KWallet*

*Usados por Chrome, Owncloud, Evolution y muchos más para guardar sus credenciales.

Link a GitHub

CHANGELOG

Slds!

En el día de hoy (hace menos de 24 horas para ser exacto) se publicó una importante vulnerabilidad en el protocolo TLS que permite a un atacante, mediante un man-in-the-middle, bajar las llaves de cifrado de una conexión con un servidor que permita el intercambio de llaves de Diffie Hellman a tan solo 512 bits. Este tipo de cifrado es por supuesto fácilmente crackeable por hackers más o menos despiertos, aunque también se rumorea que 1024 (valor al que también puede downgradearse si cliente/servidor no soportan 512 y sí 1024bits) es fácilmente accesible de crackear también.

Para colmo (aunque ya no se por qué me sorprende), las mayores sospechas son que la NSA estaba haciendo uso de esta vulnerabilidad desde hace tiempo de acuerdo a NSA leaks que se conocieron hace poco y que son consistentes con el tipo de ataque que se describe… (oootra vez arroz)

Desde el punto de vista del cliente, hasta el momento salieron patch’s para Internet Explorer (inserte cara de asombrado aquí), aunque están anunciando que saldrán en Chrome, Firefox y Safari en breve. Inclusive Mathew Green (parte del equipo de investigadores), twiteó el Martes por la noche que estuvo realizando disclosure a varias empresas previo a publicarlo. Ahora, ¿por qué publicarlo antes de que una buena parte de los browsers tenga ya fix disponible? Esa parte es realmente cuestionable.

Por el lado de los servidores, de acuerdo al sitio de la vulnerabilidad, las recomendaciones para evitar Logjam son las siguientes -atentos SysAdmins, me incluyo-:

1. Deshabilitar las Export Cipher Suites.
2. Habilitar ECDHE (Eliptic Curve Diffie Hellman).
3. Generar un grupo de Diffie Hellman seguro y único de 2048bits.

En el siguiente link de los researchers encontrarán instrucciones para aplicar correciones en:

• apache (mod_ssl).
• nginx.
• lighttpd.
• apache Tomcat.
• postfix SMTP.
• sendmail.
• dovecot.
• haproxy.

Todo da a entender que, como se está haciendo de moda últimamente, los investigadores creen necesario dar a conocer la vulnerabilidad aunque aún siga siendo una gran amenaza para la mayoría de los usuarios. Quizás así puedan llegar a una mayor concientización. Una discusión recurrente e inconclusa en el ambiente, aunque yo preferiría la paciencia antes que salir corriendo a patchear.

No se olviden de probar si su servidor es vulnerable desde el siguiente link: 

https://weakdh.org/sysadmin.html

O bien su SSL (análisis completo de SSL) en Qualys:

https://www.ssllabs.com/ssltest

Saludos!

Después de mucho pensarlo y tras recibir varias comentarios de gente amiga y colegas decidí pasar a escribir el Blog en Español. Por lo tanto, de ahora en más ISWT tendrá de inglés tan solo su nombre (es marketinero, imposible de negar!), sin embargo las notas, noticias y distintas publicaciones serán escritas enteramente en la querida lengua castellana.

Saludos!

Bash, the most-used shell interpreter for Linux and most Unix systems like OS X, suffers from a vulnerability that gives an attacker the ability to execute arbitrary commands because of Bash not correctly processing environment variables. And it’s worst: under specific situations, it is possible to remotely exploit this vulnerability.

How can this be possible ?

Incredibly, Bash is not correctly processing function definitions when they are stored in a variable. You can use the following Proof of Concept to check if your system is still vulnerable and as a demonstration of this behavior:

$ env var='() { ignore this;}; echo Vulnerableeee' bash -c ''

If vulnerable, you will see printed “Vulnerableeee” on your screen.

If patched, the follow output will appear:

bash: warning: var: ignoring function definition attempt
bash: error importing function definition for 'var'

How can an attacker exploit this ?

There are two ways in order to exploit this vulnerability: an authenticated user is needed in order to exploit this on SSH, but there are variables like HTTP/CGI which make remote code execution over the network possible, making multiple areas of exploitation.

A quick Google Dork will reveal that using HTTP/CGI for shell scripts is widely used -more than million results for this search-:

filetype:sh inurl:cgi-bin

This inmediatelly reminded me of a text by Leon Juranic from DefenseCode which talked about how Unix wildcards can gone really wild! A must-read, I must say.

Updates for all major distributions have been release, so go ahead and update Bash ASAP!

C ya l8r!

Today I wanted to talk about how thin is the line between security and (IN)security, and why we can’t just rely on an IPS/IDS. And here it goes today’s subject: how could an attacker hack any eBay account in just a few minutes (or less than just that). An Egipcian security researcher,Yasser H. Ali, reported the following vulnerability followed by this PoC:

As you can see on the video, eBay guys mistakenly used the same value for what it were supposed to be two different variables -or at least, two different values-, probably because they used the very same name for them: “reqinput”. So, the value used on the password restore link should have been a secret one that should never had to be exposed on server responses. Not to say extra data like IP Address/Client Agent/Session/etc. could have also been good for helping to detect an unwanted password reset POST.

Anyway, of course not only an Intrusion Detection System could have never notice this kind of attack, but also an Intrusion Detection System would have never stopped anyone from abusing this bug. This reminds us how important is to focus on our most critical value of our applications: developers. Never stop instructing them, security is always a continuous process.

Welcome to In Security We Trust!
See you!