Mes: marzo 2012

Publicado el

Update Item to Revision vs Revert to Revision

desde:

http://stackoverflow.com/questions/1214939/update-item-to-revision-vs-revert-to-revision

Update to revision will only update files of your workingcopy to your choosen revision. But you cannot continue to work on this revision, as SVN will complain that your workingcopy is out of date.

revert to this revision will undo all changes in your working copy which were made after the selected revision (in your example rev. 96,97,98,99,100) Your working copy is now in modified state.

The file content of both scenarions is same, however in first case you have an unmodified working copy and you cannot commit your changes(as your workingcopy is not pointing to HEAD rev 100) in second case you have a modified working copy pointing to head and you can continue to work and commit

Publicado el

Usando Horde con safe_mode para enviar por smtp y no usar sendmail

Seguramente esté muy documentado ya por ahí pero es muy recomendable dejar de usar horde bajo sendmail con el fin de securizar la máquina. Con el cambio que comentamos a continuación, evitamos tener que ejecutar comandos en la máquina local, ya que el correo lo enviamos vía smtp al servidor local o a cualquier otro servidor que configuremos.

Resumen rápido:

Deshabilitamos la mayor parte de funciones potencialmente peligrosas para el sistema.
Esto implica que fallen algunas aplicaciones, como Horde

 
# /etc/php5/apache2/php.ini) 
disable_functions = system,passthru,readfile,escapeshellarg,proc_close,proc_open,ini_alter,dl,show_source,curl_exec

La alternativa elegante sería activar safe_mode y dejar de usar sendmail, como vemos en el fragmento de la configuración de Horde:

# fragmento de la configuracion de horde 
# /etc/psa-webmail/horde/horde/conf.p
if (ini_get("safe_mode") == "1") { // Safe mode in action
$conf['mailer']['params']['host'] = '127.0.0.1';
$conf['mailer']['params']['port'] = 25;
$conf['mailer']['params']['auth'] = false;
$conf['mailer']['type'] = 'smtp';
} else {
$conf['mailer']['params']['sendmail_path'] = '/usr/sbin/sendmail';
$conf['mailer']['params']['sendmail_args'] = '-oi';
$conf['mailer']['type'] = 'sendmail';
}

En Plesk10 se han definido plantillas para los servicios de forma que aunque cambiasemos los ficheros de configuarción de apache estos cambios se terminarían machacando y volveríamos al estado por defecto.

Para ello, Plesk ha provisto un repositorio de plantillas para configurar los servicios en /usr/local/psa/admin/conf/templates/

Para reconfigurar la plantilla tenemos aqui un copy&paste muy cómodo, como siempre nos gusta:

# reemplazar safe_mode en la plantilla
sed -i 's/safe_mode off/safe_mode on/g' /usr/local/psa/admin/conf/templates/default/horde.php
# reconfigurar las plantillas
/usr/local/psa/admin/bin/httpdmng --reconfigure-server
# recargar el servicio
apache2ctl graceful

Para probarlo es necesario cerrar la sesión de Horde y volver a autenticarse.

Publicado el

[SQLite] SQL error: near «EXISTS»: syntax error

llevo un rato dándo vueltas a este error para una secuencia de comandos sql para sqlite:

[shell]
sqlite> DROP TABLE IF EXISTS geolocation;
SQL error: near «EXISTS»: syntax error
[/shell]

Revisando la documentación la sintaxis es correcta :
http://sqlite.org/lang_droptable.html

SQL Drop table

… le he dado vueltas y más vueltas

… más vueltas

y he encontrado esto : http://www.sqlite.org/releaselog/3_3_0.html
[shell]
SQLite Release 3.3.0 On 2006 January 10 (3.3.0 alpha)

….
IF EXISTS and IF NOT EXISTS clauses on CREATE/DROP TABLE/INDEX.
….
[/shell]

Así que va a ser que mi base de datos no es version 3, vamos a ver… :

[shell]
sqlite> select sqlite_version();
2.8.17
[/shell]

… shit…

Ala para los que os haga falta

Publicado el

Vulnerabilidad CRÍTICA en la API de Plesk

Hace unas semanas se notificó por parte de Parallels un fallo crítico en el su software de panel de control de hosting: Plesk. Hicimos referencia a la nota en nuestro blog http://hostingaldescubierto.com/wordpress/2012/02/10/plesk-fallo-critico-de-seguridad-sql-injection/

Reciemiente hemos tenido accesos a una máquina usando este fallo de seguridad y vamos a compartir con vosotros algunas observaciones de estos accesos:

En el sistema se observan procesos perl no habituales, con lo que procedemos a buscar el origen del mismo con lsof y el resultado es que el origen del proceso pertenece a «/tmp/…» y se se ha eliminado. Ya esto nos da una idea de que el proceso no es para nada un proceso autorizado.

Verificamos /tmp y /var/tmp donde encontramos algunos ficheros ajenos al sistema pero sin contenido.

Si nos enganchamos al proceso , podemos ver que constantemente se está descargando ficheros de diversas urls con wget:

https://eycgkhkxfs.tmdnzapomk.info:1905//b/index.php?id=...
https://94.23.208.20:1905//b/index.php?id
https://rqckfdgumv.sxobnmbjzb.info:1905//b/index.php?...

Después de consultar algunas fuentes ( gracias Logan ) vemos que en los ficheros de logs de panel de control de plesk en /usr/local/psa/admin/logs/httpsd_access_log tenemos llamadas al fichero agent.php de la api de Plesk y posteriormente accesos al panel de control donde se suben ficheros a diversos dominios.

httpsd_access_log.processed.1.gz:78.139.244.50 dd.com:8443 - [13/Feb/2012:00:33:05 +0100] "POST /enterprise/control/agent.php HTTP/1.1" 200 74360 "-" "-"
httpsd_access_log.processed.1.gz:78.139.244.50 dd.com:8443 - [13/Feb/2012:03:04:52 +0100] "POST /enterprise/control/agent.php HTTP/1.1" 200 74360 "-" "-"
httpsd_access_log.processed.1.gz:78.139.244.50 dd.com:8443 - [13/Feb/2012:03:37:21 +0100] "POST /enterprise/control/agent.php HTTP/1.1" 200 74360 "-" "-"
110.136.186.229 x.x.x.x:8443 - [19/Feb/2012:05:12:37 +0100] "POST /login_up.php3 HTTP/1.1" 200 966 "https://x.x.x.x:8443/" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; 3301; MyIE2)"
110.136.186.229 x.x.x.x:8443 - [19/Feb/2012:05:12:42 +0100] "GET /plesk/client@3/domain@/?context=domains HTTP/1.1" 200 29327 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; 3301; MyIE2)"
110.136.186.229 x.x.x.x:8443 - [19/Feb/2012:05:12:50 +0100] "GET /plesk/client@3/domain@222/hosting/file-manager/?cmd=chdir&file=%2Fcgi-bin%2F HTTP/1.1" 200 39293 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; 3301; MyIE2)"
110.136.186.229 x.x.x.x:8443 - [19/Feb/2012:05:13:06 +0100] "POST /plesk/client@3/domain@222/hosting/file-manager/create-file/ HTTP/1.1" 303 0 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; 3301; MyIE2)"

y dentro del dominio en la carpeta /cgi-bin/ vemos ficheros .cgi con el contenido de los scripts que el atacante ha subido.

Un fragmento de uno de los scripts nos indica que los procesos ejecutados en el sistema provienen de esos ficheros

open(OLD_UNIX, ">", "/tmp/.X11-unix");
print OLD_UNIX decode_base64("....L....");
close(OLD_UNIX);
system("echo '* * * * * perl /tmp/.X11-unix >/dev/null 2>&1' >
/tmp/cron.d ; crontab /tmp/cron.d ; rm /tmp/cron.d");
system("perl /tmp/.X11-unix");
print "exdonen";

Como medidas para prevenir este fallo de seguridad hay que actualizar Plesk aplicando los microupdates.
Reviar /var/spool/cron aunque en nuestro caso no se han encontrado crontabs ajenos.
Es recomendable también ajustar los permisos para wget, curl y get

http://kb.parallels.com/en/113321

En breve daremos más detalles de las evidencias obtenidas.