El robo de cuentas de Steam

Todos habremos leído que cada día es mas común el hackeo de cuentas de Steam, por diversas razones, y, que por lo general las cuentas hackeadas suelen ser las que mas juegos tienen.

La primera pregunta sería: ¿Como saben que cuentas tienen mas juegos?

De principio, la pregunta esta mal formulada, excepto en casos excepcionales, los hackers no saben de primeras que cuenta tiene mas juegos que otra, o cual es mas atractiva de atacar. La pregunta correcta sería: ¿Por que las cuentas con mas juegos suelen ser las mas atacadas? y esta pregunta tiene una base muy solida.

Existen páginas como steamdb.info donde se actualizan a diario los precios de cada juego, en cada país, pongamos que queremos un Civilization V de Sid Meier, en el momento de escritura de este articulo, el precio de ese juego son 30 Euros en Europa, pero viendo la lista de precios en la pestaña prices, uno puede ver Rublo Ruso -80.62%, precio 5.81 Euros, que se quedarían en 6 o 7 Euros por las conversiones de la las tarjetas de crédito a monedas extranjeras.

Pero esto es un día normal, un día de las famosas Steam Offers, donde el mismo juego puede quedarse en 6.99 Euros, el precio en Rublos Rusos puede quedar al irrisorio numero de 1.7 Euros, 2 y pico Euros con las conversiones de moneda.

Si estás comprando juegos a 2 Euros y pico, igual tienes la mayor colección de juegos de la historia.

Bien pero, ¿Donde está el problema?

Está en que para comprar en Rublos, necesitas una IP rusa como es lógico, para Yuanes una China. Cada tienda de Steam esta geolocalizada. Esto en si no es el problema. El problema es, que desde foros, desde paginas web de terceros e incluso en los propios foros de Steam hay multitud de usarios diciendo, hey no veas lo que me he ahorrado comprando desde la tienda rusa y explicando como se hace.

Y realmente este es el problema, para comprar en la tienda Rusa, China, etc, necesitas una IP de la región, y la única manera es a través de un Proxy anónimo o una VPN, y claro el objetivo es coste cero, así que vas a utilizar una VPN gratuita o un Proxy anónimo gratuito con salida a Rusia o a donde prefieras.

En el momento que haces eso toda tu información esta pasando a través de un Proxy o una VPN y todo tu trafico es visible al dueño de la VPN o Proxy. Y antes de que me digas “mi tráfico esta encriptado por SSL”, el tráfico interno a través de la VPN o Proxy no lo está y la conexión con la tienda de Steam es HTTPS, pero sabiendo lo que buscas y con los conocimientos y recursos adecuados desencriptar ese tráfico puede ser hasta sencillo ya que estás siendo victima de un ataque Man-In-The-Middle.

Esa es una de las razones de que muchas de las cuentas con mas juegos sean las mas hackeadas.

Y, ¿Para que quieren mi cuenta, si solo hay juegos?

Realmente quieren tu cuenta por alguna de las siguientes razones:

Por los datos bancarios o de comercio electrónico que pueda contener y que puedan usar en un futuro.

Para revender cuentas, algo que se está poniendo de moda.

O incluso para obtener ingresos directos, ejemplo, el objetivo puede ser comprar un juego Indie de bajísima calidad que probablemente han diseñado los propios hackers y de precio bajo los cuales abundan en Steam, pero miles de ventas de un juego de 4 Euros pueden ser una cantidad muy interesante.

Así que, si de verdad estás preocupado por la seguridad de tu cuenta, no utilices Proxys anónimos ni VPNs gratuitas desconocidas ya que esto se puede volver contra ti.

Crear una lista TOR compatible con IPSet en un solo comando

Observando la creciente y en aumento cantidad de pruebas de penetración y sondeos en busca de exploits y sistemas vulnerables desde redes TOR, cada día es mas común filtrar el trafico proveniente de estas, más aún cuando es un entorno vivo donde aparecen y desaparecen puertas de acceso y IPs casi a diario.

El siguiente ejemplo es una forma rápida de crear una lista de IPs TOR compatible con IPSet y lista para usarse.

echo 'create torlist iphash maxelem 350000' > lista_tor.txt \
&& wget https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=`curl -s http://ipinfo.io/ip` -O -| egrep '^[0-9.]+$' | sed 's/^/add\ torlist\ /' >> lista_tor.txt

Consideraciones para este script:

  • Usa ipinfo.io para resolver tu propia IP.
  • Puede ser automatizado sin problema, aunque se debería permitir el acceso a check.torproject.org.
  • El script es funcional a día de hoy, pero eso no significa que en algún momento en el futuro el método cambie.

Que hace tu Smart TV sin tu saberlo. Consideraciones de seguridad y rendimiento.

Cada día es mas común encontrar SmartTVs en oficinas y hogares por la cantidad de ventajas que proporcionan. Pero pocas veces se tiene en cuenta los problemas o peligros que pueden acarrear.

¿Cuales son estos problemas?

Problemas de privacidad, de rendimiento de red y de seguridad.

Empecemos por los de privacidad:

Cualquiera que haya leído las EULAs (Licencias de Software) de los fabricantes, puede ver claramente que prácticamente cualquier acción que haga dentro de la SmartTV puede quedar registrada y a disposición del fabricante, ninguna sorpresa aquí.

Lo que es más preocupante es que muchas SmartTV actuales llevan adaptadores Bluetooth y servicios de control remoto a través de el y se anuncian abiertamente como FABRICANTE MODELO PULGADAS (o un patrón similar), lo cual permite a cualquier persona con un móvil y sin ningún tipo de software especifico ni acceso a una red, descubrir cuantas SmartTV hay en un recinto, cuantas pueden ser vulnerables de algún tipo de ataque y demás, lo mas preocupante es que casi ninguna SmartTV del mercado permite desactivar esos servicios.

De rendimiento de red:

Las SmartTVs son muy agresivas en cuanto al uso de la red y lo son hasta cuando solo están simplemente conectadas. Un ejemplo real de uso es el siguiente:

  • Sincronización horaria: 123 UDP a servidores NTP
  • Session Traversal Utilities for NAT: 3478 UDP a servidores STUN
  • Simple Service Discovery Protocol: 1900 UDP a Host Multicast
  • Boot Service Discovery Protocol: 15600 UDP a Broadcast
  • Aparentemente algún tipo servicio de streaming: 8001 UDP a Multicast
    • (Este es curioso por utilizar una dirección experimental y poco adoptada Multicast 224.0.0.7)
  • Trafico WEB y HTTPS: 80 TCP y 443 TCP a distintos servidores
    • Que incluyen:
    • Trafico a sitios web
    • Actualizaciones
    • Recolección de datos
    • Telemetría y estadísticas
    • Netflix
    • Hulu
    • Etc.

Y la mayoría de este trafico sucede continuamente, incluso cuando no se está usando la SmartTV, lo cual puede llegar a degradar seriamente el rendimiento de una red.

Y de seguridad:

Hasta hace poco y utilizando cualquiera de los métodos anteriormente comentados, cualquiera podía instalar software de terceros en prácticamente cualquier SmartTV del mercado. Solo había que saber cual era el blanco e instalarlo podía ser tan simple como conectar un pendrive con el software o en casos mas elaborados a través de algún servicio web.

Los objetivos pueden ser tan dispares como, ser la puerta de acceso para otro tipo de ataque, activar una webcam conectada a la SmartTV, monitorizar parte del trafico de la red, o lo que se os ocurra.

Por suerte muchos fabricantes se han dado cuenta y impiden instalar software de terceros, si bien esto no elimina la amenaza, si la disminuye.

¿Cual es mi recomendación entonces?

Si tienes una o varias Smart TV y estás preocupado por cualquiera de estas cosas, lo ideal sería crear una VLAN para las SmartTVs donde permitas solo el trafico que te interese y el acceso a los recursos que tu decidas.

DNSCHECK v1.0

Con la creciente cantidad de servidores DNS conteniendo bloqueos regionales, redirecciones a páginas del ISP, diferentes sets de DNS y los tristemente famosos poisoned DNS, es muy útil tener a mano una herramienta que de un vistazo permita aligerar la carga del administrador de sistemas.

Verificar su estado es tan simple como correr el siguiente código:

#!/usr/bin/python
# dnscheck v1.00 by Eduardo Garcia <eduardo.garcia@gmx.com>
# Checks every dns in a file called dns.lst and returns
# its result. Tries to be "somewhat" smart by polling every
# server and discovering the most likely correct IP address.
# It also warns of misbehaving, poisoned, geo-locked and 
# dns servers with a different set of addresses.
#
# TODO: In following versions will likely scrap nslookup and
# use dig or even resolve directly from python.
#
# usage: dnscheck somesite.com

from __future__ import with_statement
import subprocess
import sys
import getopt

try:
    address = sys.argv[1]
    if not address:
        raise ValueError()
except IndexError:
    print"Usage: %s domain.com" % (sys.argv[0])
    sys.exit(2)

filename = "dns.lst"
dnss = None
hits = []
best_ip_match = None
good_servers = []

def populate_hits(address, dns):
    if "No Answer" not in address:
        addr = address.split(": ", 1)[1]
        addr = addr.rstrip()
    else:
        addr = address

    hits.append([addr, dns])

def best_match():
    ip_match = []
    ip_count = []
    for i in range(len(hits)):
        if hits[i][0] in ip_match:
            ip_count[ip_match.index(hits[i][0])] += 1
        else:
            ip_match.append(hits[i][0])
            ip_count.append(1)
    return ip_match[ip_count.index(max(ip_count))]

def match_good_servers():
    matched_servers = []
    for i in range(len(hits)):
        if best_ip_match in hits[i][0]:
            if hits[i][1] not in matched_servers:
                matched_servers.append(hits[i][1])
    return matched_servers

def print_good_servers(number_of):
    print "[ %s ] appears to be the correct IP address for [ %s ]" % (best_ip_match, address)
    print "Within:",
    for i in range(number_of):
        if i < (number_of - 1):
           delimiter = ","
        else:
           delimiter = "..."
        print good_servers[i] + delimiter,
    print "(and other %s servers)\n" % (len(good_servers) - number_of)

def print_alternate_ips():
    matched_ips = []
    for i in range(len(hits)):
        if hits[i][1] in good_servers:
            if best_ip_match not in hits[i][0]:
                if hits[i][0] not in matched_ips:
                    if "No Answer" not in hits[i][0]:
                        matched_ips.append(hits[i][0])
    if len(matched_ips) > 0:
        print "The following IPs were also returned by apparently good servers:"
        for x in range(len(matched_ips)):
            if x < (len(matched_ips) - 1):
                delimiter = ","
            else:
                delimiter = "\n"
            print matched_ips[x] + delimiter,
        print

def print_unanswering_servers():
    printed = False 
    for i, field in enumerate(hits):
        if "No Answer" in field:
            if printed is False:
                print "The following servers failed to answer:"
                printed = True
            print hits[i][1],
    if printed is True:
        print "\n"

def print_misbehaving_servers():
    printed = False 
    for i in range(len(hits)):
        if hits[i][1] not in good_servers:
            if "No Answer" not in hits[i][0]:
                if printed is False:
                    print "The following servers are likely stale, misconfigured, geo-locked, poisoned, do redirections or have a different dns set."
                    print "It is worth to take a look at them."
                    printed = True
                print "Server: %s\tAnswered IP:\t%s" % (hits[i][1], hits[i][0])
    if printed is True:
        print 


try:
    with open(filename, 'r') as f:
        dnss = [f.rstrip('\n') for f in open(filename, 'r')]
except EnvironmentError:
    print "This program requires a file called %s with servers in the following format:" % (filename)
    print "8.8.8.8"
    print "8.8.4.4"
    print "208.67.222.222"
    sys.exit(2)

for dns_ip in dnss:
    proc = subprocess.Popen(['nslookup', address, dns_ip ],stdout=subprocess.PIPE)
    been_answered = False
    for line in iter(proc.stdout.readline,''):
        if "Address" in line:
            if dns_ip not in line:
                populate_hits(line, dns_ip)
                been_answered = True
    if been_answered is not True:
                populate_hits("No Answer", dns_ip)

best_ip_match = best_match()
good_servers = match_good_servers()
print_good_servers(3) 
print_alternate_ips()
print_unanswering_servers()
print_misbehaving_servers()

Es necesario crear un archivo llamado dns.lst que contenga las IP de los servidores DNS a probar, una IP por línea, que este en el mismo directorio que dnscheck. El programa funciona mejor con una lista grande de DNSs. Un ejemplo del contenido de dns.lst sería este:

8.8.4.4
8.8.8.8
208.67.222.222
208.67.220.220

Y ejecutarlo con un:

./dnscheck dominioaprobar.com

Correr infinitamente un programa en un entorno mínimo

Antes o después uno necesita que un programa se ejecute constantemente. Esto no suele ser un problema en un servidor o workstation, pero cuando nos enfrentamos a sistemas embebidos todo cambia.

En un servidor o workstation utilizaríamos un trabajo Cron o el comando nohup, pero… ¿Y cuando no tenemos acceso a ninguno de esos, o simplemente no existen en el dispositivo?

Pues bien, podemos utilizar el comando trap como se va a ver en el siguiente ejemplo.

#!/bin/ash
# watchdog program by Eduardo Garcia <eduardo.garcia@gmx.com>
# This program runs endlessly on a minimal environment (Ash)
# usually found in routers and other embedded devices.
# In this case, it's purpose is getting the stats from a router
# and uploading it to a FTP server every 5 minutes, avoiding
# being killed or terminated.

# To avoid being killed we invoke trap
trap "echo FTPput crashed. Respawning..." SIGINT SIGTERM
echo "pid is $$"

# We are getting the server IP from a file at /tmp
ip=`cat /tmp/servip`

while true
do
    sleep 295
    adslcmd info --show 1> /tmp/dslstats
    sleep 5
    /usr/bin/ftpput -u dsluser -P 2121 $ip -l /tmp/dslstats -r /dslstats 1> /dev/null
done

Haciendo esto las posibilidades son infinitas, por ejemplo, resetear la línea cada vez que baje de una velocidad definida, o cuando acumule una cantidad definida de errores…

O lo que se os ocurra.

Descubiertas varias vulnerabilidades en OpenSSL

OpenSSL.org ha lanzado un parche arreglando varias vulnerabilidades de gravedad media y baja.

La más importante podría colgar las rutinas de verificación de firma con una excepción de puntero invalido, lo cual podría utilizarse para preparar un ataque DDoS.

Como es natural se recomienda actualizar todos los servicios afectados.

Para mas información sobre este problema pulse aquí

Descubierta una vulnerabilidad critica en las librerías LibPNG

Este bug causa un desbordamiento de buffer que permite realizar un vector de ataque DDoS

Afecta a múltiples versiones, programas y dispositivos, como servidores, teléfonos móviles, reproductores mp3, navegadores web, tiendas de aplicaciones y un largo etcétera.

Este bug afecta a todas las versiones de libpng, por lo que se recomienda actualizar a las siguientes:  libpng 1.6.19, 1.5.24, 1.4.17, 1.2.54 y 1.0.64

Para mas información pulse aquí

Mitigando el ataque Bittorrent DDoS

Hace no demasiado tiempo ha surgido un nuevo tipo de ataque usando la infraestructura de clientes de bittorrent.

El ataque se basa en pasar una dirección web valida como si fuese un tracker de bittorrent, una vez hecho esto, se propaga a través de la red de clientes bittorrent y comienza un DDoS.

Si bien, la mayoría de los ataques provienen de IPs chinas, no solo es exclusivo de estas, se han visto replicas en Estados Unidos, Italia, etc…

La solución sería decirle al cliente que aquí ahí no hay un tracker valido, esto se consigue añadiendo el siguiente código en Apache:

<IfModule mod_rewrite.c>
    <Location ~ "^/announc">
        ErrorDocument 410 "d14:failure reason13:not a tracker8:retry in5:nevere"
     </Location>
     RewriteEngine On
     RewriteRule ^/announc - [G]
</IfModule>

Y en el caso de ngnix:

server {
    location /announc {
        access_log off;
        error_log off;
        default_type text/plain;
        return 410 "d14:failure reason13:not a tracker8:retry in5:nevere";
    }
}

Entendiendo y seleccionando el Clocksource adecuado en Linux

Aunque hay mucha información sobre los Clocksource (fuente de reloj) en internet también hay aspectos muy oscuros y poco tratados sobre este tema.

Y se plantean las siguientes preguntas:

¿Cuantas llamadas por segundo se hacen al Clocksource?

Depende del sistema. Una buena forma de verlo sería con RDDTools, Munin o Cacti, como se ve en el ejemplo siguiente.

irq-munin

No tengo RDDTools, Munin, Cacti… ¿Como sé cuantas llamadas se están realizando?

Un método sencillo sin recurrir a un script sería ejecutar los dos siguientes comandos:

# cat /proc/interrupts

Y con un:

# mpstat -I SUM -P ALL 1
Linux 2.6.32-5-686	16/09/15 	_i686_	(1 CPU)

17:30:37     CPU    intr/s
17:30:38     all   2146,00
17:30:38       0   2146,00

17:30:38     CPU    intr/s
17:30:39     all   3216,00
17:30:39       0   3217,00

17:30:43     CPU    intr/s
17:30:44     all   11640,00
17:30:44       0   11641,00

En el anterior ejemplo aparecen casi 12000 intr/s. ¿Son todas llamadas a Clocksource?

No.

Solo una parte de los intr/s corresponden al Clocksource, por lo general entre un 20% y 45% y dependiendo del número de dispositivos, carga del servidor, etc…

Presuponiendo que fuesen 12000 intr/s. ¿Cuanto tiempo de procesador ocuparían?

Para dar respuesta a eso necesitamos un pequeño código que nos ofrece RedHat.

#include <time.h>
main()
{
    int rc;
    long i;
    struct timespec ts;

    for(i=0; i<10000000; i++) {
        rc = clock_gettime(CLOCK_MONOTONIC, &ts);
    }
}

Pero adaptando la línea adecuada a nuestras necesidades:

    for(i=0; i<12000; i++) {

Para compilarlo ejecutaríamos un:

# cc clock_timing_12k.c -o clock_timing_12k -lrt

Y tras eso podríamos ejecutar la prueba con cada uno de los Clocksource:

# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
# time ./clock_timing_12k

real	0m0.058s
user	0m0.008s
sys	0m0.024s
# echo pit > /sys/devices/system/clocksource/clocksource0/current_clocksource
# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
pit
root@epsilon:~# time ./clock_timing_12k

real	0m0.253s
user	0m0.020s
sys	0m0.100s

 

Conclusión:

De los resultados se puede extraer que todos los Clocksource disponibles en Linux están altamente optimizados.

De los resultados también se desprende que TSC sería el Clocksource adecuado para el sistema probado (siempre que este no de problemas de clock drift o unstable clocksource). Más revelador es que un Clocksource considerado lento como PIT, desempeña perfectamente en esta prueba con valores del mundo real.

Como reducir la frecuencia de un i3, i5, i7 en verano reduciendo la emisión de calor.

Este es un post un poco atípico, pero trabajar con PCs durante una ola de calor puede ser una tarea insufrible, mas que nada por el hecho de que el propio PC es una fuente constante de calor.

Desde luego estas recomendaciones son para una estación de trabajo (workstation) y uso normal, no para un servidor.

Para los i7 de primera generación bastaría pasarle como root un:

# echo powersave | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Pero en el caso de un Sandy Bridge o Ivy Bridge con kernel 3.9 o superior habría que dar los siguentes pasos:

# ls -l /sys/devices/system/cpu/intel_pstate/

-rw-r--r-- 1 root root 4096 Jul  8 14:41 max_perf_pct
-rw-r--r-- 1 root root 4096 Jul  8 14:40 min_perf_pct
-rw-r--r-- 1 root root 4096 Jul  8 14:40 no_turbo

Los tres archivos mostrados corresponden al nuevo modelo de P-States de Intel donde el propio procesador gestiona la cantidad de carga y la velocidad, para estos procesadores habría que hacer un:

# echo powersave | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Pero este solo ha sido el primer paso, veremos el resultado con un:

# egrep --with-filename * /sys/devices/system/cpu/intel_pstate/*
/sys/devices/system/cpu/intel_pstate/max_perf_pct:100
/sys/devices/system/cpu/intel_pstate/min_perf_pct:23
/sys/devices/system/cpu/intel_pstate/no_turbo:0

En mi caso, el uso máximo permitido del procesador es 100%, el mínimo 23% y el Turbo Boost está activado.

Podemos mejorarlo con diciéndole que solo queremos usar un 38% del potencial del procesador:

# echo 38 > /sys/devices/system/cpu/intel_pstate/max_perf_pct

La temperatura del procesador cayo de 68 grados a 57 grados en uso, sin ninguna perdida de usabilidad. Otra opción puede ser pasarle un echo 1 a no_turbo para deshabilitar el Turbo Boost.

Si hacéis esto vuestros cuerpos os lo agradecerán (y de paso reducís la probabilidad de fallo de hardware en un gran porcentaje).