Configurar un recurso compartido en Samba
Sin caer en intentar documentar la configuración de un recurso compartido en samba... he encontrado un par de sitios web donde claramente tienen esta información que en un momento dado nos hace falta...
https://help.ubuntu.com/ubuntu/serverguide/es/configuring-samba.html
SecGame #1: Sauron – Resolución Nivel 5
Primero, y como es habitual saludar a todos los que nos siguen, segundo enviar un saludo a todos los que desde Extrelan pasaron un buen rato resolviendo éste reto, con algunas ligeras modificaciones. Ahora, con un día de retraso nuevamente, vamos a resolver el que es ya el quinto nivel dentro de los desafíos de Sauron. Empecemos.
El nivel 5 es quizá uno de los momentos menos concretos de todos los que se pueden presentar. Ahora hemos conseguido ser usuarios locales del sistema, podemos ejecutar comandos, leer directorios, ver configuraciones, y podemos, en definitiva, explorar muchísimas posibilidades.
Sin embargo, hay que matizar algo importante, que puede servir para ahorrarnos muchas horas de trabajo inútil: si nos encontramos en un sistema actualizado, sin fallos de seguridad en el kernel y en otros servicios administrativos, es muy difícil, a menos que el administrador haya configurado algo de forma errónea, escalar privilegios directamente, hacia un usuario administrativo. ¿Qué podemos hacer entonces en estas situaciones?
Nuestro objetivo, en estos casos en los que ser "root" o "Administrador" no parece ser inmediato, será extraer la mayor cantidad de información del sistema, obtener el mayor número de cuentas de usuario posibles, etc.
¿Cómo conseguir eso?. Primeramente, en los sistemas que tengan servicios web, nos centraremos en estos, ¿por qué?. Básicamente porque el aislamiento entre usuarios web, es quizá no complicado, pero sí tedioso. Es fácil encontrar escenarios en los que directamente podamos acceder a los directorios de otros usuarios en la web, y leer sus ficheros, porque todas estas carpetas pueden ser leídas por el usuario que ejecuta el servidor web ( apache, httpd, etc ). En otros escenarios los usuarios web estarán aislados usando cgi-wrappers. Y únicamente, en los entornos más avanzados y seguros, cada usuario web poseerá una máquina virtual o un vps, en la que sólo existirá él. En caso de no existir escenario web, otros escenarios posibles son por este orden: ficheros de configuración, ficheros temporales, ficheros de logs y permisos inseguros.
En este escenario que nos ocupa, relativamente común en un entorno de seguridad medio con árbol web (incluso muy común en granjas de servidores web), vamos a ver cómo se puede proceder. Lo primero, saber quiénes son los usuarios.
blindware:x:500:500::/var/www/blindware:/bin/bash intranet:x:501:501::/var/www/intranet:/bin/bash developer:x:502:502::/home/developer:/bin/bash
El sistema parece tener 3 usuarios. 2 de ellos, usuarios web, uno de los cuales es el usuario con el que podemos ejecutar comandos, y otro es el usuario “intranet”.
Podemos probar a acceder al directorio del usuario intranet (/var/www/intranet), pero rápidamente nos daremos cuenta, que poco podemos hacer, pues nos deniega el acceso. Incluso si intentamos leer /var/www, obtendremos resultado parecido, puesto que sus permisos son los siguientes:
d--x--x--x 8 root root 4096 May 12 13:52 www
Ésta situación es bastante común, sin embargo, hay un fichero en el sistema que nos será siempre de gran utilidad, y es la configuración del propio Apache, la cual habitualmente se encuentra desprotegida (en este caso dentro de /etc/httpd/httpd.conf).
ServerAdmin blindware@blindware.inc
DocumentRoot /var/www/blindware/htdocs
ServerName www.blindware.inc
SuexecUserGroup blindware blindware
<Directory />
Options Indexes SymLinksIfOwnerMatch ExecCGI
AllowOverride All
</Directory>
</VirtualHost>
<VirtualHost *:80>
ServerAdmin intranet@blindware.inc
DocumentRoot /var/www/intranet/htdocs
ServerName intranet.blindware.inc
SuexecUserGroup intranet intranet
<Directory />
Options Indexes SymLinksIfOwnerMatch ExecCGI
AllowOverride All
</Directory>
</VirtualHost>
De esta configuración, lo primero que extraemos, es que los hosts están aislados mediante Apache suEXEC, lo cual hace que PHP esté configurado para ejecución en modo CGI, en vez de cómo módulo de Apache, y por ello antes necesitábamos permisos de ejecución en los ficheros PHP. Tal y como comentamos con anterioridad, no es recomendable ir reinventando la rueda a cada paso, por ello, la pregunta que nos tenemos que hacer en este punto es: ¿existe algún procedimiento público y documentado que permita sobrepasar los mecanismos de aislamiento de hosts basados en Apache suEXEC?.
Existe, únicamente tenemos que buscar en Google: "apache suexec", "apache suexec bypass", o similares y encontraremos un documento denominado "Apache suEXEC Bypass" en el cual se nos detalla de forma bastante extensa los problemas de configuración asociados a éste sistema.
A grandes rasgos, nosotros vamos a sacar lo más interesante del documento, para hacernos una idea de cómo podemos proceder para leer ficheros dentro del directorio web del usuario intranet.
1. Los diferentes hosts virtuales de Apache, mediante suEXEC, lo que consiguen es que cada host ejecute comandos CGI, bajo un usuario diferente. De esta forma, por ejemplo, nosotros ejecutamos comandos con “blindware”, mientras que el vhost intranet, ejecuta comandos con el usuario “intranet”.
2. Esto permite un esquema de aislamiento “relativamente” sencillo.
drwxr-x--- 3 blindware apache 4096 nov 25 17:00 blindware
drwxr-x--- 3 intranet apache 4096 nov 25 17:00 intranet
Si nos damos cuenta, cada usuario es propietario de su directorio, y ningún otro usuario puede acceder a ellos, a excepción del usuario apache, con el que se ejecuta el servicio web. Esto "garantiza", que aunque el usuario ejecute comandos en el sistema, ningún usuario podrá acceder al directorio de otro usuario.
3. Esta idea, cuenta con un fallo: el enlace simbólico. Los enlaces simbólicos se pueden establecer sobre ficheros en los que no tenemos permisos. Dicho de otra forma, nosotros como usuario “blindware”, podemos enlazar cualquier fichero del usuario “intranet”, del que conozcamos su existencia.
4. Una vez enlazado el fichero, podremos usar Apache, para leer el enlace simbólico, de esta forma, el enlace simbólico será leido con los permisos de Apache, usuario Apache, y podremos acceder a aquellos directorios a los que Apache tenga acceso, que comúnmente son todos los del árbol web, puesto que debe poder leerlos.
5. Para que el ataque tenga éxito Apache, es así por defecto, debe estar activa la opción FollowSymLinks en Apache. Por el contrario, si la opción que se encuentra activa es SymLinksIfOwnerMatch, el ataque no se podrá realizar, puesto que Apache, únicamente seguirá enlaces que apunten a ficheros propiedad del dueño del enlace.
6. En caso de estar activa la directiva SymLinksIfOwnerMatch, podrá ser modificada por un usuario mediante un fichero .htaccess, siempre que las opciones AllowOverride Options, o AllowOverride All, estén habilitadas.
A priori, parece que nos encontramos en un escenario vulnerable: se usa suEXEC, y aunque se encuentra habilitada la opción SymLinksIfOwnerMatch, también está habilitada la cláusula AllowOverride All. Por tanto, es cuestión de proceder, a través de nuestra shell en PHP según lo que vamos a describir a continuación. Un detalle importante, cuando queramos ejecutar contenido en nuestra shell PHP, cualquier instrucción que incluya caracteres mínimamente extraños, debemos hace uso de URLEncode.
1. Lo primero que queremos hacer es escribir un fichero .htaccess que nos permita aprovecharnos de esta vulnerabilidad. La orden bien pudiera ser esta.
echo "Options -SymLinksIfOwnerMatch +FollowSymLinks" > .htaccess
Pero como sabemos, debe ser URLEncodeada, quedando una cadena, para su ejecución en nuestra shell, como la siguiente:
echo+%22Options+-SymLinksIfOwnerMatch+%2BFollowSymLinks%22+%3E+.htaccess
2. Ahora es cuestión de crear un enlace simbólico, sobre algún contenido que nos interese leer del directorio “intranet”. En este caso, lo más interesante es leer el fichero .htaccess de ese directorio, del que nos garantizamos su existencia, y que además nos impide el acceso al contenido web de http://intranet.blindware.inc. Creamos pues el enlace simbólico: ln –s /var/www/intranet/htdocs/.htaccess htaccess
De esta forma, tenemos un enlace directo, en nuestro directorio http://www.blindware.inc/_controlp/htacccess, que una vez visitado nos dará el contenido del fichero:
Options +Indexes
AuthName "Blindware - Intranet Protected"
AuthType Basic
AuthUserFile /var/www/intranet/htdocs/.htpasswd
require valid-user
4. Repetimos el proceso, una vez que conocemos la localización del fichero .htpasswd. Para ello creamos otro enlace simbólico: ln –s /var/www/intranet/htdocs/.htpasswd htpasswd
De esta forma, creamos un enlace directo, en nuestro directorio http://www.blindware.inc/_controlp/htpasswd, que una vez visitado nos dará el contenido del fichero.
admin:tCPJIYCZjtqF6
5. Tenemos el usuario, y el hash del acceso a intranet.blindware.inc, podemos bien intentar crackearlo, bien seguir intentando la lectura de ficheros contenidos en ese directorio. A priori es un hash DES tradicional, con lo cual podemos intentar romperlo, a ver qué sucede.
Para romper el hash, hacemos uso de la herramienta “john the ripper”, que es con diferencia el crackeador de passwords más conocido de Unix.
$ john htpasswd
guesses: 1 time: 0:00:00:10 (3) c/s: 335628 trying: 132449 - 132498
Loaded 1 password hash (Traditional DES [64/64 BS MMX])
132456 (admin)
Pues ya conocemos el password: 132456 con usuario admin. Lo que nos permite acceder a intranet.blindware.inc y seguir avanzando en la resolución de Sauron. Dentro de 15 días, continuaremos con el siguiente nivel. Suerte a todos los que intentáis superarlo.
Analizando como poner en marcha un sitio Web de alto rendimiento I
La puesta en marcha de un servicio web de alto rendimiento no nace de la noche a la mañana. Es un trabajo constante en el que tienen que ir de la mano la cordinación de más de un departamento. El departamento de desarrollo tiene que preveer el crecimiento haciendo escalable el desarrollo de la aplicación coordinando con las necesidades y/o requisitos del departamento de sistemas.
Un papel fundamental para su crecimiento es la disponibilidad y velocidad del servicio. Aquí es donde se tiene que analizar como vamos a hospedar la web.
En cuanto al desarrollo hay que preveer la escabilidad técnica por parte del equipo de sistemas para el correcto funcionamiento con tráfico elevado.
El análisis de la base de datos es un papel muy muy pero muy importante en todo esto. Una vez completado el esquema de la BD es importante el definir que tablas tendrán más escritura para poder, en un mañana próspero y posible la separación de BD's con tablas diferentes en caso de que así lo requiera el proyecto. No obstante, MySQL puede dar mucho juego. Desde el montar un cluster de BD a crear BD's con replicación o separar las tablas de la BD en diferentes BD con la desventaja que ello podría acarrear en un futuro.
Ahora es cuando nos sentamos a pensar con que tecnología vamos a trabajar. Exceptuando los servicios de Microsoft no conozco ningún sitio web de alto rendimiento que esté funcionando con ISS por lo que por el momento vamos a comenzar con tecnologías libres.
Sistema Operativo: Debian Estable
Servidor Web: Apache 2
Base de datos: MySQL 5.0
Código: PHP 5.1
Instalación de Lighttpd (Pronunciado Lighty)
Descargamos y descomprimimos Lighttpd:
wget http://www.lighttpd.net/download/lighttpd-1.5.0-r1992.tar.gz
tar xvzf lighttpd-1.5.0-r1992.tar.gz
cd lighttpd-1.5.0/
Configuramos:
./configure
make
make install
// Copiamos el directorio de los sources de lighttpd en /usr/src por seguridad, por si necesitamos
desinstalarlo y demás algún día.
cp lighttpd-1.5.0 /usr/src/ -R
Ahora vamos a crear el directorio de configuración si no existe (/etc/lighttpd) y copiar en el el fichero principal de configuración, que se encuentra entre los directorios del código fuente
mkdir /etc/lighttpd
cp doc/lighttpd.conf /etc/lighttpd/
Vamos a editar el fichero lighttpd.conf y ver las partes más importantes.
nano /etc/lighttpd/lighttpd.conf
Módulos del servidor:
Se estrablecen los módulos activos dentro de la directiva server.modules(), de esta forma:
server.modules = ("mod_rewrite","mod_alias","mod_accesslog")
De momento utilizaremos solo estos modulos. mod_rewrite para las normas de rewrite, mod_alias para los alias del servidor, mod_access para denegar el acceso a ciertos archivos y mod_accesslog para los log de acceso y error.
Configuración básica del servidor:
server.document-root = "/home/web/htdocs" # Directorio raiz del servidor
server.errorlog = "/var/log/lighttpd/error.log" # Archivo de log de errores
index-file.names = ( "index.phtml", "index.php" ) # Archivos de índice y su orden.
accesslog.filename = "/var/log/lighttpd/access.log" # Log de acceso del servidor.
url.access-deny = ( "~", ".inc" ) # Deniega la descarga de los archivos con las extensiones indicadas.
static-file.exclude-extensions = ( ".php", ".phtml") # Extensiones que el servidor tratará como dinámicas.
#server.port = 81 # Puerto por defecto. Si está comentado usa el 80
#server.bind = "grisu.home.kneschke.de" # Host del que escuchará peticiones por defecto. Si está comentado acepta todos.
server.error-handler-404 = "/missing.phtml" # Archivo que mostrará cuando se produzca un error 404 (No se encuentra la página)
Para empezar, con estas opciones nos vale.
Importante: Si queremos incluir algun fichero;
include "lighttpd-inc.conf"
El fichero debe estar situado en /etc/lighttpd/
Por último, vamos a configurar nuestro servidor para que funcionen las páginas en php 5. Para ello necesitamos instalar el paquete php5-cgi y activar el módulo "mod_proxy_backend_fastcgi".
apt-get install php5-cgi
Para que todo funcione aún mejor, añadimos al fichero php.ini de /etc/php5/cgi la siguiente linea:
server.modules = ("mod_rewrite","mod_alias","mod_accesslog","mod_proxy_backend_fastcgi","mod_proxy_core",)
Y ahora configuramos el módulo:
$PHYSICAL["existing-path"] =~ ".php$" {
proxy-core.allow-x-sendfile = "enable"
proxy-core.protocol = "fastcgi"
proxy-core.backends = ( "unix:/tmp/php-fastcgi.sock" )
proxy-core.max-pool-size = 16
}
En nuestro caso, como tambien utilizamos archivos phtml haremos una copia:
$PHYSICAL["existing-path"] =~ ".phtml$" {
proxy-core.allow-x-sendfile = "enable"
proxy-core.protocol = "fastcgi"
proxy-core.backends = ( "unix:/tmp/php-fastcgi.sock" )
proxy-core.max-pool-size = 16
}
*Importante: por último para que se lanzen los procesos php ejecutar desde un script: spawn-fcgi -s /tmp/php-fastcgi.sock -f /usr/bin/php-cgi -u www-data -g www-data -C 5 -P /var/run/spawn-fcgi.pid
Otros detalles "sin importancia":
modulo rewrite: Son totalmente convertibles las máscaras del rewrite de apache a lighttpd sin demasiado esfuerzo, solo cambia la sintaxis dentro de lighttpd.conf (mejor hacer un include)
más info acerca del rewrite en: http://trac.lighttpd.net/trac/wiki/Docs%3AModRewrite
modulo alias: Creas alias virtuales para poder acceder a directorios que estan fuera del docroot (por ejemplo) o acortar rutas (por ejemplo tambien)
Ejemplo: alias.url = ( "/cgi-bin/" => ""/home/web/htdocs/rg/cgi-bin/" )
Ya tenemos un servidor lighttpd sencillo que soporta procesa php.
Manual gracias a: MiJack
Apache Benchmark – Prueba de carga a sitios web
La utilidad "ab" (Apache Benchmark) sirve para hacer pruebas de carga a un servidor apache.
Por ejemplo 100 consultas, con una concurrencia de 5 usuarios a la vez.
ab -n100 -c5 http://www.dominio.com/
No olvidar el "/" final en el URL
Probar con diferentes niveles de concurrencia. Y no olvidar ver las opciones con ab --info pues es batante flexible.
Usage: ab [options] [http://]hostname[:port]/path
Options are:
-n requests Number of requests to perform
-c concurrency Number of multiple requests to make
-t timelimit Seconds to max. wait for responses
-p postfile File containing data to POST
-T content-type Content-type header for POSTing
-v verbosity How much troubleshooting info to print
-w Print out results in HTML tables
-i Use HEAD instead of GET
-x attributes String to insert as table attributes
-y attributes String to insert as tr attributes
-z attributes String to insert as td or th attributes
-C attribute Add cookie, eg. 'Apache=1234. (repeatable)
-H attribute Add Arbitrary header line, eg. 'Accept-Encoding: gzip'
Inserted after all normal header lines. (repeatable)
-A attribute Add Basic WWW Authentication, the attributes
are a colon separated username and password.
-P attribute Add Basic Proxy Authentication, the attributes
are a colon separated username and password.
-X proxy:port Proxyserver and port number to use
-V Print version number and exit
-k Use HTTP KeepAlive feature
-d Do not show percentiles served table.
-S Do not show confidence estimators and warnings.
-g filename Output collected data to gnuplot format file.
-e filename Output CSV file with percentages served
-h Display usage information (this message)
Problema con el audio en VMware en Linux
Hoy recordando viejos tiempos me ha entrado la necesidad de jugar a uno de mis pasa tiempos preferidos en años anteriores, StarCraft!! 
si ese maravilloso juego de estrategia. Pero me he encontrado con la curiosidad de que por primera vez necesitaba de sonido en mi Windows virtualizado con vmware. Así que para poder solucionarlo he tenido que indagar un poco por internet.
1. sudo -i
2. aptitude install alsa-oss
3. chmod +s /usr/lib/libaoss.so.*
4. mv /usr/bin/vmware /usr/bin/vmware.orig
5. echo ‘#!/bin/bash’ > /usr/bin/vmware
6. echo ‘LD_PRELOAD=libaoss.so exec /usr/bin/vmware.orig “$@”‘ >> /usr/bin/vmware
7. chmod +x /usr/bin/vmware
8. exit
Una vez abierto el vmware, vas a la opción de configuración de sonido. Podrás comprobar que todavía sigue con el "Auto detect" y en el desplegable no aparece nada más. Si arrancas así la máquina virtual no funcionará el sonido. Para solucionar esto tienes que escribir en ese campo: /dev/dsp y listo, a usar sonido en las máquinas virtuales.
Visto en: Libertad Digital
Windows XP cuando actualiza te da opciones
Sn comentarios, imaginaros la gracia cuando tienes unas cuantas ventanas abiertas, donde tienes sesiones contra servidores etc....
OpenOffice habla con Festival
Directo desde el foro de OOoForum Marilenc Cosiovei de Bucharest, Rumania ha podido conectar dos proyectos, OpenOffice.org y Festival para poder hacer que OpenOffice.org hable el contenido de los documentos. Los pasos son sencillos, primero necesita comenzar OpenOffice.org como cliente en el puerto 2002. Seleccionar el texto dentro del documento y correr el script de python.El script de python tendra el siguiente codigo:
import uno, unohelper # obten el componente uno del motor de PyUNO localContext = uno.getComponentContext() # crea el UnoUrlResolver resolver = localContext.ServiceManager.createInstanceWithContext( "com.sun.star.bridge.UnoUrlResolver", localContext ) # conectate al office corriente ctx = resolver.resolve( "uno:socket,host=localhost,port=2002;urp; StarOffice.ComponentContext" ) smgr = ctx.ServiceManager # obten el objeto central del desktop desktop = smgr.createInstanceWithContext( "com.sun.star.frame.Desktop",ctx) # accesa el documento actual de writer model = desktop.getCurrentComponent() selection = model.getCurrentSelection().getByIndex(0) selection = selection.getString() print selection ctx.ServiceManager
./python.sh ~/free/pys/oopy.py | festival --tts
El script de python.sh que esta provista por ooowriter. Para un buen repositorio de voz puedes usar las voces de este sitio.
Escrito por: JZA lider del proyecto OpenOffice Hispano.
Instalar Adobe Flash Player 9 para Firefox en Ubuntu 7.10
Primero tenemos que descargar los fuentes del plugin de flash que vamos a instalar: Adobe Flash Player
Una vez tengamos el paquete en nuestro escritorio, tenemos que descomprimir el arcvivo para poder hacer la instalación. En vez de descomprimir el paquete aprovechando la comodidad de usar el entorno gráfico.
Una vez que tenemos la carpeta descomprimida abriremos un terminal para seguir con el proceso de instalación, donde nos dirigiremos al path donde están las fuentes. Es importante que no tengamos en ejecución el navegador Firefox.
| usuario@maquina:~/Escritorio/install_flash_player_9_linux$ sudo ./flashplayer-installer[sudo] password for usuario: Copyright(C) 2002-2006 Adobe Macromedia Software LLC. All rights reserved. Adobe Flash Player 9 for LinuxAdobe Flash Player 9 will be installed on this machine. You are running the Adobe Flash Player installer as the "root" user. Support is available at http://www.adobe.com/support/flashplayer/ To install Adobe Flash Player 9 now, press ENTER. To cancel the installation at any time, press Control-C. Please enter the installation path of the Mozilla, Netscape, Adobe Flash Player 9 will be installed in the following directory: Browser installation directory = /usr/lib/firefox Proceed with the installation? (y/n/q): y Adobe Flash Player 9 will be installed in the following directory: Browser installation directory = /usr/lib/firefox Proceed with the installation? (y/n/q): n Please log out of this session and log in for the changes to take effect. usuario@maquina:~/Escritorio/install_flash_player_9_linux$ |
Ahora ya podemos abrir nuestor navegador favorito y utilizar el Flash player 9 en nuestro firefox.