Category: System administration, Databases, Messaging and Security

Lectura de archivos a través de páginas ASP

Reading time: 2 – 3 minutes

Bucle a Servidors.

Las páginas ASP programadas para la versión 5.0 del servidor
web de Microsoft (IIS) que hacen uso del método “Execute” pueden
permitir una escalada de directorios y dar acceso a la mayor parte de los
archivos del servidor.

El lenguaje ASP surge como una extensión al código HTML para
permitir un mayor dinamismo en la presentación de contenidos y obtener
una mayor potencia del servidor web. Pero si la programación de estas
páginas no se realiza de forma correcta puede producir graves problemas
que pueden permitir a un atacante la posibilidad de acceder a datos, robar
información e incluso llegar a tomar el control de la maquina.

Desde la aparición de la versión 5.0 de IIS muchos programadores
hacen uso del método “Execute” para desarrollar los sitios web sin
necesidad de usar “frames” o usar la directiva “#include”. De este modo es
más sencillo implementar plantillas HTML para facilitar el trabajo de
los desarrolladores.

EL problema se produce cuando se indica la página que debe de ser
cargada desde la propia URL, por ejemplo:

http://servidor/inicio.asp?file=/asp/home.asp

Mediante la modificación de la URL puede ser posible escalar directorios
mediante el uso de URL’s modificadas:

http://servidor/inicio.asp?file=../../WINNT/win.ini

Esto permitirá a un atacante acceder con permisos de lectura a muchos de
los archivos del servidor, o todos si no está usando el formato de
archivos NTFS.

Un segundo problema es una posible denegación de servicio si se solicita
el mismo archivo que hace la llamada al Server.Execute:

http://servidor/inicio.asp?file=inicio.asp

Esto provocaría que el script ASP entrara en un bucle infinito que le
llevaría a usar el 100% de la CPU y grandes cantidades de memoria
mientras el script no hiciera “time out”, generalmente a los 90 segundos de
haberse iniciado la petición.

Las posibles soluciones pasan por verificar que el archivo que se pasa al
método Execute no contienen cadenas como “../” o desactivar las “rutas
padre” en la configuración del propio servidor IIS.

Vulnerabilitat al PGP

Reading time: 2 – 3 minutes

Ja fa un parell o tres de dies q no paren de correr missatges a la BUGTRAQ
parlant de la vulnerabilitat q han trobat uns “checs” al PGP, però trobo
q pel calibre d la notícia no acaba de saltar la bomba o la gent no s’ho
acaba de creure.

Pel q sembla però amb els missatges m’han anat arribant les
últimes hores cada cop hi ha més gent confirmant la
notícia i malgrat encara no tinc coneixement q entitats com
securityfocus ho hagin publicat confirmant-ho. Hi ha múltiples documents
tècnics dels “analistes” q ho han aconseguit.Documents q de moments tots
els experts donen com a correctes.

Alguns d’aquests interessants documents estan a les següents URLs:

http://www.i.cz/en/pdf/openPGP_attack_ENGvktr.pdf

“The attack to private signature keys in OpenPGP format, PGPTM program and
other OpenPGP based applications” here.
http://www.i.cz/pdf/pgp/OpenPGP_Attack_ENGfinal.ppt

Jo sincerament em perdo amb les definicions tècniques dels documents
anteriors pq no domino lo suficient el RSA i el DSA, q és on s’han
trobat els errors. Però a la llista del openPGP hi ha un missatge q
és el q millor entenc sobre l’error:
http://www.imc.org/ietf-openpgp/mail-archive/msg04767.html

En aquest missatge es deixa clar q l’impacte real de l’error és petit pq
s’ha de tenir accés a la clau privada per poder modificar-la i
això a l’hora de la veritat és poc factible, però a nivell
teoric si q és una gran troballa. Per tant, potser no s’ha trencat
l’algorisme, però si q s’ha fet un gran abans en entendre les seves
potencials vulnerabilitats.

Parlnat de PGP i ja per tancar l’article només afegir q ja fa una
setmana o dues l’inventor del PGP Phil Zimmermann va deixar la NAI pq estava en
desacort en la seva política respecta al codi de les noves versions del
PGP, així doncs va decidir separar-se d’aquesta prestigiosa empresa d
seguretat.

El primer nombre ilegal

Reading time: < 1 minute

Aquesta si que es bona, ja s’ha trobat una espècie de clau
obre-tot.

Ara resulta que existeixen els nombres prohibits, com en el cas de:

485650789657397829309841894694286137707442087351357924019652073668698513401047237446968797439926117510973777701027447528049058831384037549709987909653955227011712157025974666993240226834596619606034851742497735846851885567457025712547499964821941846557100841190862597169479707991520048667099759235960613207259737979936188606316914473588300245336972781813914797955513399949394882899846917836100182597890103160196183503434489568705384520853804584241565482488933380474758711283395989685223254460840897111977127694120795862440547161321005006459820176961771809478113622002723448272249323259547234688002927776497906148129840428345720146348968547169082354737835661972186224969431622716663939055430241564732924855248991225739466548627140482117138124388217717602984125524464744505583462814488335631902725319590439283873764073916891257924055015620889787163375999107887084908159097548019285768451988596305323823490558092032999603234471140776019847163531161713078576084862236370283570104961259568184678596533310077017991614674472549272833486916000647585917462781212690073518309241530106302893295665843662000800476778967984382090797619859493646309380586336721469695975027968771205724996666980561453382074120315933770309949152746918356593762102220068126798273445760938020304479122774980917955938387121000588766689258448700470772552497060444652127130404321182610103591186476662963858495087448497373476861420880529443

es tracta de un nombre primer de 1401 dígits molt peculiar: si es passa
a notació hexadecimal resulta que és el codi font del DeCSS
(descompresor de DVD proscrit en EEUU) en C, comprimit amb gzip. Aixñi
que desde el punto de vista legal està prohibit distribuír aquest
nombre dins del territori dels EEUU.

Si voleu més informació sobre aixo:
http://www.utm.edu/research/primes//curios/48565…29443.html

Algorisme DES

Reading time: < 1 minute

A l’assignatura de Criptologia i Seguretat de Xarxes, estem tractant el tema
dels algorismes simètrics i assimètrics, sobre tot estem donant
una visió filosofia del funcionament dels algorismes…

Ahir a la nit l’Ernest em va passar una URL en castellà on s’explica
de forma senzilla i entenedora el funcionament d’un algorisme simètric
molt usat, millor dit el més usat: el DES. A la URL
http://paginas.deagrapa.com/computadoras_e_internet/aorellana/des.htm hi ha la
informació necessaria per implementar-lo i tb fan una pinzellada sobre
el Triple DES.

Descobert un important error en el protocol TCP

Reading time: < 1 minute

Investigacions de la empresa Guardent han descobert un important error en el
protocol TCP. Noticia confirmada, alatrament per Steven Bellovin (AT&T)

Bàsicament l’error es resumeix en: té a veure amb la forma en
que els sistemes qeu treballen amb TCP sleccionen el ISN. Aquest com pren un
valor aleatori, fet servir per a ajudar a la identificació de paquets de
informació legítims i per a preveure que les dades extranyes no
interfereixin en la transmissió.Fins ara es pensava que, al
seleccionar-se aquets numeros ISN al atzar, s’aconseguia protegir les
connexions. De totes maneres, existeixen maneres de esbrinar quins son aquests
numeros, quelcom que permetria realitzar una sèrie de sofisticats atacs
informàtics.La noticia la he extret de ibrujula a:
http://ibrujula.com/news/noticia.php3?id=14822

BIND Vulnerabilities

Reading time: < 1 minute

Aquests dies has sortit un mega-bug a totes les versions del Bind per sota
de la 9.1, es veu que la cosa és molt xunga i convé
“updetajar-se” ràpid.

No he trobat enlloc l’explicació tècnica de com es fa explotar
el tema, malgrat es veu q ja hi ha explotis una bona url per informacion del
BIND és:
http://www.isc.org/products/BIND/bind-security.html
Però no s’explica massa profundament. L’únic q diu sobre aquesta
vulnerabilitat és:
“It is possible to overflow a buffer handling TSIG signed queries, thereby
obtaining access to the system. “
Quan trobi més info sobre el tema ja la posaré en forma de
comentari.

Netscape Communicator JPEG-Comment Heap Overwrite Vulnerability

Reading time: 2 – 2 minutes

Antiga vulnerabilitat dels netscape’s, no m’hi havia fixat però tot
llegint la BUGTRAQ m’he trobat aquesta url de securityfocus:
http://www.securityfocus.com/bid/1503 on es descriu el bug i és molt
interessant, més del q sembla a primera vista 😉

Netscape Browsers use the Independent JPEG Group’s decoder library to
process JPEG encoded images. The library functions skip JPEG comments; however,
the browser uses a custom function to process these comments and store them in
memory. The comment includes a 2-byte “length” field which indicates how long
the comment is – this value includes the 2-bytes of the “length” field. To
determine the length of the comment string alone (for memory allocation), the
function reads the value in the “length” field and subtracts two. The function
then allocates the length of the comment + one byte for NULL termination. There
is no error checking to ensure the “length” value is valid. This makes it
possible to cause an overflow by creating an image with a comment “length”
field containing the value 1. The memory allocation call of 0 bytes (1 minus 2
(length field) + 1 (null termination)) will succeed. The calculated comment
size variable is declared unsigned, resulting in a large positive value (from 1
minus 2). The comment handling function goes into a loop to read the comment
into memory, but since the calculated comment size is enormous this causes the
function to read the entire JPEG stream, overwriting the heap. It is
theoretically possible to exploit this to execute arbitrary code. The browser,
mail and news readers are all vulnerable to this.

Defensar-se dels atacks DOS

Reading time: 1 – 2 minutes

http://grc.com/r&d/NoMoreDoS2.htm
Estava llegint el resum anual de securityfocus i he trobat una URL molt
interessant…

En la URL a d’alt esmentada hi ha una explicació a nivell TCP de com
evitar els atacs DOS, la idea és molt bona, bàsicament consisteix
en no guardar informació del SYN q t’envia el client per establir la
conexio i només guardar la clau CSN q envies tu quan envies un packet
SYN/ACK així després quan el client envii el ACK amb la teva clau
CSN sabràs q és el mateix tio q t’ha fet un SYN al principi, cosa
amb la q verifiques q no s’ha espofejat la IP i a més al no haver
guardat la informació del SYN podem evitar el desvordament de recursos
al q és sotmes la màquina en un atac DOS.
Per informar-se més detalladament de tot això la URL q he
esmentat abans ho explica molt bé.