Vos también? ¡Hackea windows vista! (página 2)

Partes: 1, 2

Desarrollo
("Poniéndonos a Punto")

El posterior análisis (estructural, sistemático,
metódico y conciso) "desplegará" los fundamentos y
las características esenciales de los artilugios
anteriormente descriptos.

Por ende, estudiaremos y/o examinaremos el siguiente
contenido:

Parte I – Blue Pill (Pastilla
Azul): "Creando Código Malicioso –Malware–
Indetectable"

Todos los RootKit´s y Backdoors actuales, de los
cuales estoy enterado, se basan en una concepción
(teoría). Por ejemplo: FU fue
asentado en una idea de desatar bloques de EPROCESS de
la lista de procesos
activos en
el Kernel del SO, Shadow Walker fue cimentado en un
concepto de
engañar al visitante de una Página Web (preparada
para el caso) y de marcar algunas partes del cuerpo del sitio
(Body Site) como "inválida" y así poder
ejecutar código arbitrario, Deepdoor hizo lo suyo
cambiando algunos campos en la estructura de
datos NDIS; tomando control
remoto del sistema,
Etc…

Por lo tanto, una vez que sepas "de qué
concepto" se trata, podrás, al menos
hipotéticamente, detectar el Código Malicioso que
se encuentra en tu máquina.

Ahora, imagina un Malware (desconocido,
aún, en su tipo) con capacidades de ser imperceptible.
Del cual no se pueda confiar en la oscuridad de su
concepto (teoría). Éste, no podría
detectarse (en la práctica) aún cuando su
algoritmo
(conjunto ordenado y finito de operaciones que
permiten el cálculo
de su notación) se diera a conocer en
público.

Vayamos más lejos e imaginémonos que,
incluso, su código de compilación se encuentre
In The Wild ("en la calle"), pero que todavía no
se consiguiera manera alguna para detectar que esta criatura
está funcionando en vuestras máquinas… ¡Sería un
potencial desastre libre por doquier!

Sin embargo, aunque pueda sonar un tanto absurdo, se
ha estado
trabajando en una tecnología código-nombrada
Blue Pill (Pastilla Azul), que es justamente sobre ésa
presunción (imperceptible al 100%, según las
condiciones contemporáneas) en la que uno se apoya para
verter sus postulados arriba dispuestos sin ninguna
duda.

La idea detrás de tal postura es mera: tu SO
"traga" La Píldora Azul (Blue Pill) y se
despierta dentro de una matriz
controlada por el Hypervisor Azul Ultrafino de la
Píldora, es decir, un prototipo subyacente de
ejecución que bloquea, encripta y oculta procesos y/o
procedimientos
totalmente manipulables para el control de eventos en el
SO, pero indetectables. Todo esto sucede "en marcha"
(on-the-fly), o sea, sin el reinicio del sistema, y no
hay patrones visibles de comportamientos extraños en el
funcionamiento de los recursos
(lógicos y físicos) de tu ordenador.

Empero, aunque no lo notes, ahora todos los
dispositivos son completamente accesibles al SO, que
está ejecutando una máquina virtual (VM)
interior. Esto ocurre gracias a las tecnologías de
última generación que consienten la
virtualización del hardware con
respecto al software
(sincronizados). Los paradigmas
más reconocidos que hacen posible tal obrar, en nuestros
días, son: SVM/Pacífica de AMD o
Bit VT de Intel.

Dada la infografía de arriba, podemos entender
como el SO sigue creyendo que se está ejecutando en la
PC, cuando en realidad se ejecuta dentro de una máquina
virtual (VM) controlada por el programa que lo
"infectó".

De este modo, la aplicación se vuelve
"virtualmente invisible", dado que Windows Vista
sólo puede ver la máquina virtual ("el mundo que
ha sido puesto ante sus ojos para ocultarle la
verdad").

Asimismo, un programa de esta magnitud "corriendo"
dentro de una máquina virtual (VM) puede ser sospechoso,
pero un SO dentro de una máquina virtual (VM) que a su
vez está dentro de otra máquina virtual (VM)
ejecutando la misma aplicación, muestra
desconcierto de razonamiento lógico.

Sin embargo, su punto en contra (defecto) es la
degradación en su rendimiento y performance (debido al
consumo
extremo de requisitos para mantenerse estable en un sistema con
tantas peticiones de este tipo), lo que puede ser "el
talón de Aquiles" para producir una vacuna que lo evite
y prevenga su intrusión desautorizada a posteriori de
haberse entregado a la intervención dañina.
Incluso, contamos con las opciones para desactivar estas VMs
por Hardware desde la BIOS y el SO
(indicadas por leyendas que
hacen referencia a sus nombres y funciones), las
cuales no resultan convenientes recomendar, salvo para una
"salida de emergencia" al apuro oportuno.

Otro mecanismo para divisarlo podría ser
llenando toda la memoria RAM
del equipo, de esta manera, el programa sólo
podría ir a la memoria
de intercambio virtual del SO (Swap), donde ya no
tendría la capacidad de seguir ejecutándose y,
por lo tanto, tampoco podrá mutar ni moverse
allí.

En definitiva, el esquema radical de su
interoperabilidad sería el que a continuación
se muestra:

Parte II – Red Pill (Pastilla
Roja): "Sometiendo a engaños el Núcleo del
Sistema –Kernel-"

¿Quién no conoce la importancia y
relevancia del Kernel? ¿Quién no se ha
visto "know out" (KO) por "la caída" del mismo?
¿Por qué los mayores (y mejores) ataques a nivel
de Seguridad
Informática se suceden sobre este?
¿A qué se debe tan renombrada autoridad y
dogma? ¿Y…?

Para sintetizarlo en unas pocas líneas, el
Kernel es el Núcleo de todo Sistema
Operativo (SO); el sostén del mismo, la "columna
vertebral" que permite la sincronización entre los
Recursos Físicos (Hardware) con los Recursos
Lógicos (Software) de una máquina
(llámese PC). El encargado de "mantener en pie"
(armazón) a cualquier plataforma de Software Base en
posesión de un equipo…

Pero, tanto mérito no le concede "ser perfecto"
y, lejos de estar de ello, tiene sus falencias.

En tal caso particular, MS Windows
Vista sufre en su célebre incursión por las
VMs de una patología un tanto grave
(clasificación crítica) que permite
insertar código arbitrario en la médula del
Kernel (núcleo del SO) sin percatase de conocer si
éste se encuentra firmado digitalmente o no. Lo que
sería capaz de eludir el sistema de certificados
genuinos requeridos para la instalación de drivers
(precisos para el funcionamiento idóneo de dispositivos
en el SO).

Se trata de una instrucción que no es
privilegiada en los rangos del Microprocesador, la SIDT. Es decir, no causa una
excepción cuando se la aplica. Pero, si es sensitiva. O
sea, da un resultado distinto en la VM (Level 1) que en
la RM (Level 0). Lo cual, no debería ser
anunciado de ninguna manera. Tal artimaña es conocida
con el nombre de Exclusion Trap ("Trampa de
Exclusión").

En conclusión, ejecutar una instrucción
SIDT da un resultado distinto dependiendo de donde se encuentro
operando el Kernel del SO con respecto al
Microprocesador.

Algo que no tendría que ser así, por el
simple hecho de que puede delatar su ubicación real a
otras aplicaciones en memoria que
pueden intentar "persuadirlo" para aprovecharse de tal
vulnerabilidad y, por ende, esgrimir con sus actividades
perjudiciales.

Ahora bien… Visto y considerando tales detalles
teóricos, es momento de llevarlos a la
práctica.

El siguiente Código de Programación efectuado en C++ descubre
(fehacientemente) lo que intento confesarles:

Como antes lo dijimos, lo volvemos a reiterar…
El corazón
de este código, ciertamente, es la instrucción
SIDT (aquí como 0F010D[addr]) que tiende a los
volúmenes de interrupción del descriptor de la
tabla del registro (IDTR) en el destino local de
memoria que se esté operando.

Debido a que hay sólo un IDTR registrante como
verdadero (True), pero (por lo menos) dos SO que
"corren" concurrentemente (el anfitrión –host– y
el invitado –guest-), VMM necesita relocalizar el IDTR
del invitado en un lugar seguro, para
que no cause conflictos
con el anfitrión y termine desbordando al sistema.
Desgraciadamente, VMM no puede saber si (y "cuando") el
proceso que
se ejecutó en el invitado desencadenó la
instrucción SIDT en el anfitrión, porque no es
una orden privilegiada (y, como inicialmente describimos, no
genera una excepción). Así, el proceso consigue
la dirección IDT sin mayores inconvenientes
y, por supuesto, sin el consentimiento del usuario a
cargo.

Por ejemplo, fue observado que en VMWare la
dirección relocalizada IDT estaba en el sector
0xffXXXXXX, mientras que, en Virtual PC, la
sección era 0xe8XXXXXX;
respectivamente.

¿Extraño, no…? Sabiendo que una
misma máquina (PC) comparte un cabal recurso de
privilegios en instancias del Microprocesador que el SO
(más específicamente el Kernel del mismo)
impone.

La captura de pantalla que veremos seguidamente,
mostrará su representación substancial de
interoperabilidad:

Igualmente, se pretende que en un futuro, el SO
(comandado por su Kernel) sólo pueda instalar
drivers de dispositivos autorizados por firmas digitales con
Certificación WHQL (Laboratorio de Control de
Calidad de
Hardware de Windows). Por lo que, tal contingencia
sería resuelta sin mayores peligros e inconvenientes en
su devenir.

Pues, entonces, como veredicto final… Reforzar
la prevención, preferentemente, con lo "malo conocido",
sin arriesgarse en ir en búsqueda de lo "bueno por
conocer".

Esa sería mi principal recomendación;
hasta que, por lo menos, las empresas en
convenio, nos den una solución pertinente a la
complicación existente. ¿Hacemos
trato…?

Conclusión
("Al Fin Llegamos a la Meta:
¿¡Lo Logramos!?")

Podríamos decir, en un "juego
inteligente de palabras", que el apasionante y sorpresivo
Mundo de la (IN)seguridad Informática nos sobrepasa
y colapsa cualquier seguridad vigente en tiempos inconcebibles,
pero reales. ¿Qué lo corrobora y/o
cerciora?

Sin ir más allá, lo aquí dispuesto
(mecanismos -cariñosamente llamados: Blue Pill /
Red Pill– ideados y desarrollados por Joanna Rutkowska en
técnicas y/o estrategias de
"Hackeo a Windows Vista") dan una "pequeña gran
pauta" de lo lejos que estamos de una forma bastante efectista y
eficiente de poseer un SO (promocionado por Microsoft
Corp.) que sea robusto, confiable, versátil y flexible
a las exigencias de los usuarios alrededor de todo el mundo y de
"los tiempos que corren".

Pero… Sin olvidarse de hacerlos
¡SEGUROS!

Por otra parte, muchos le encontraran y/o consideraran a
esta nota un halo de fantasía y superstición. Sin
embargo, las denominaciones y tendencias aquí
desempeñadas y aprendidas se apoyan en el pedestal
hegemónico (por analogía) a la tan admirada
Película Matrix; donde la gente cree vivir en un
mundo real cuando en realidad viven en úteros artificiales
controlados por máquinas.

Del mismo modo, Windows Vista cree ejecutarse en
una máquina real cuando en realidad se ejecuta en una
máquina virtual y… Allí es dónde
"comienzan los dolores de cabezas".

Esperemos que… Estos principios de
colaboración sirvan para mejorar y progresar en el
análisis, el diseño,
la implementación y la actualización de un pilar
tan reclamado como es La Información y El
Conocimiento; los cuales deben ser: "universales, libres y
gratuitos".

Y, saber que… "Quién tropieza pero no se
cae, dos pasos adelanta". ¡Salgamos a luchar por el 2º
Round!

Y… Recuerden Siempre para Nunca Jamás
Olvidar:

"LA SEGURIDAD INFORMÁTICA NO ES UN PRODUCTO SINO
UN PROCESO".-