Avui només he dormit 7h i es nota, tinc soneta tan pc s’acusa el
cansament a la vista.
El pof, el benja i jo ens hem passat el dia configurant serveis a la
màquina pel concurs de seguretat la veritat es q encara en voldriem
posar uns quants més però tic petat i no en tinc ganes hauria de
posar el servidor de realaudio i suport wml al apache. Pero fa mandra.
Basicament ens em passat el dia fent això per tant molt divertit no ha
estat, això si entretingut. Ara d’aquí 1h o així anirem de
festa a la discoteca no sé q. Q tenim entrada gratix o això diuen
tot i q no sé si ens deixaran entrar amb la pinta q portem.
Bé això ha estat tot ara me’n vaig a mirar el squid q el pof m’ha
dit q es llarg de configurar i tb seria lo seu posar-lo.
#===================================== -s –> Especificar el tipo de escaneo
-sF : Escaneo por FIN (windows no responde por culpa de una mala implementacion
del protocolo tcp) -sS : Escaneo por SYN
Estos dos no se logean en el SYSLOG porque no envias un ACK y el demonio no se
activa.
-sT : Escaneo por ACK
-sU : Escaneo puertos UDP, este es muy lento. -O –> Identificacion de host por fingerprint. Para
averiguar el SO del Host. -P0 –> Para que no compruebe mediante un ping si la
maquina esta online. O sea no envia un ping para comprobar que la maquina este
online. -v –> verbose -d–> debug -F –> Solo escanea “servicios estandars” en lugar de
escanearse todos los 65523 puertos. -f –> Envia el escaneo en paquetes fragmentados, con lo
cual es mas dificil detectarlo. Cuidado los windows se pueden quedar
colgados. -Dhost1,host2,host3,… –> DECOYS. Utilizamos ips de otros
servers para ocultarnos. Lo que estamos haciendo es modificar la SOURCE ADRESS
de la cabecera TCP de los paquetes.
Conferències:
– Seguretat en les TI
– Sistema de fitxers Hersier http://devlinux.com/projects/reiserfs/
Forums:
– Forum de seguretat
Les conferencies de seguretat ha estat molt interessant, he aconseguit unes
transparencies molt guapes les hauria de pujar al directori de
documentació.
Això planteja un error d’organització de documentació al
portal. Tema a estudiar.
Sobre el tema de seguretat hi ha uns conceptes a retenir:
– Autenticidad de certificación: fa els certificats.
– Autenticidad de registro: solicita els certificats, es dediquen a demanar les
dades per fer els registres i a entregar els certificats un cops fets.
– Repositorio de certificados: on hi ha les bases de dades de
certificats.
– Certificados revocados: gestió q es fa quan es perd un
certificat.
– Certificación cruzada: quan varies agencies de certificació
firmen un acord per acceptar els certificats l’una de l’altre.
– Recuperación de claves: problemàtica de quan es perd una clau.
Per evitar això s’usen tècniques com la de CLAU DOBLE,
així s’aconsegueix recuperar la clau. Per mitjà del q se’n diu la
clau mestre.
La conferencia del sistema de fitxers no m’he empanat de res ja q el tio no
s’explicava organitzadament i la traducció era patetica. Així
doncs queda pendent mirar la web http://devlinux.com/projects/reiserfs/ ja q el
projecte malgrat estar en fase inicial té pinta de ser
interessant.
Al forum de seguretat encara no hi he anat ja q es celebra d’aquí dues
hores aprox.
Tb m’he inscrit al concurs de seguretat q s’ha proposat per part del banc
UNO-E, participarem amb 4 maquines el pof, inqui i jo.
Primera marxada de llum, tot continua guay, a destacar una conferencia de 2
a 4 de la matinada sobre seguretat.
La gent del banc Uno-e ens van donar una conferència sobre seguretat
molt interessant, varem tractar conceptes com el paradigme del ACIDAN:
Autenticidad
Confidencialidad
Integridad
Disponibilidad (DOS attack)
Auditoria
No repudio: no poder negar algo q s’ha fet pq tingui validesa judicial.
Pos res com sempre, molta calor, molt estres, configurant la xarxa a tot deu
pq això del DHCP ningú sabiem el q era. Així doncs he
hagut d’investigar com rular. Però és una tonteria el tema
està en no posar res pq configuri la xarxa i tenir el eth0 down i
després executar el dhclient i ell s’ho fa tot està molt
bé no cal pensar massa pq ruli. Està bé, tp es tan guarro
com em pensava, això no vol dir pas q sigui millor q el modo IP fixa,
però per xarxes grans reconeixo q va molt millor.
Bé això és tot, q no tinc més ganes d’escriure
més q aquí tothom demana coses i no em concentro per
escriure.
Només dir q com sempre em divertiré més q no pas
aprendre.
És un shell script q he trobat a freshmeat q està curradissim
un nipon q tenia poca feina, s’ha dedicat a pillar les noticies de fotimer de
sites a internet. Ja podia jo currar-me un puto script en PHP pq ho fes :'(
Sort q l’script q jo he fet fa cosetes q l’altre no fa. Però el puto
nipon està currat.
CASL és un llenguatge de programació d’xploits i altres proves
de seguretat similiars…
Roses Labs En exclusiva para Canal #Networking IRC by Conde Vampiro
————————– ||Lenguajes de Seguridad||
————————– CASL —- CASL (Common Attack Script Language) fue
diseñado con el proposito de proporcionar una poderosa herramienta al
ejercito de los EE.UU. Logicamente este era un proyecto secreto, por lo que
practicamente no ahi ninguna informacion sobre CASL en Internet. Quiero dejar
claro que ni yo ni nadie de los Roses Labs a sido el creador de CASL, nosotros
simplemente hemos realizado una libreria para mejorar el lenguage en si,
aportando mas funciones y hemos realizado numerosos ejemplos en CASL. CASL
salio a la luz a principios de 1998, cuando los propios creadores de CASL,
sacaron su obra maestra, un documento de obligada lectura titulado: “Insertion,
Evasion, and Denial of Service: Eluding Network Intrusion Detection” por Thomas
H. Ptacek y Timothy N. Newsham. En este documento se uso CASL para realizar las
pruebas a los distintos NIDS (Network Intrusion Detection System) evaluados. EL
cual esta disponible en
http://www.nai.com/services/support/whitepapers/security/IDSpaper.pdf CASL es
un producto que pertenece a NAI (Network Associates, Inc. http://www.nai.com)
que forma parte de su scanner de vulnerabilidades CyberCop. Posiblemente la
mejor herramienta comercial que he conocido. Y sobre mediados de 1999 NAI
decidio crear un interprete CASL independiente para Linux sin necesidad de
tener que utilizar CyberCop. Lo bueno de usar este potente lenguaje, es que nos
permite crear programas en poco minutos para comprobar la (in)seguridad de una
red o sistema. Ya que CASL es un lenguaje de bajo nivel, en el sentido que solo
nos enfocamos en lo que nos interesa sin tener que preocuparnos por
abrir/cerrar socket, etc.. todo ello se encarga el interprete CASL. Nosotros
solo vamos a por lo que nos interesa 🙂 Esto es una enorme ventaja ya que
podemos escribir potentes programas en muy pocas lineas de codigo, ademas es un
lenguaje muy facil de aprender si contamos con ciertas nociones de C y TCP/IP.
CASL utiliza TCP/IP, UDP e ICMP. Podemos escribir programas para: – Testear un
NIDS. – Firewall virtual – Scanners – DoS (Denegacion de Servicio) – sniffers
NASL —- NASL (Nessus Attack Scripting Language) es un lenguaje que forma
parte del scanner de vulnerabilidades Nessus (http://www.nessus.org). Nessus es
un scanner en modo cliente/servidor. Es La herramienta por excelencia en el
mundo del software libre 🙂 Aunque tecnicamente no es un herramienta bien
diseñada aunque sirve bien sus propositos. Mediante el uso de NASL
podemos crear Tests de Seguridad (“Security Test codes”) en poco tiempo.
Podriamos decir que cuando aparece un nuevo fallo podemos en menos de una hora
crear un Test de Seguridad para detectar el fallo. Ahi que tener en cuenta que
solo podemos utilizar NASL mediante el uso de Nessus, y el servidor solo corre
actualmente en sistemas *nix, pero existen clientes tanto para Linux como
Windows. Entre todos los lenguajes que voy a comentar, NASL es el unico que
utiliza una plantilla que estamos obligados a cumplir si queremos escribir un
Test de Seguridad para Nessus. Este plantilla esta divida en dos partes: 1-
“(description)” Aqui pondriamos todo la informacion referente al fallo (Autor,
Problema, Solucion, Plataforma, tipo de fallo, , familia, Idioma, etc..) 2- En
esta parte ya seria el codigo para detectar el fallo en si. Nessus divide su
deteccion de fallos en familias, las cuales serian las siguientes: – Gain a
shell remotely – CGI abuses – Backdoors – Remote file access – Denial of
Service – Useless services – NIS – Finger abuses – Firewalls – Misc. – FTP –
Gain root remotely – SMTP problems – Port scanners – RPC Podemos ver que Nessus
tiene muchas familias. Si solamemnte utilizamos los Test de Seguridad que
incorpora Nessus, podemos detectar unos 280 fallos aproximadamente para
sistemas *nix o Windows. ELZA —- Elza es un lenguaje de script
diseñado para analizar servidores web, el cual nos puede ser de gran
ayuda. Esta escrito en Perl y su lenguaje por tanto es parecido al Perl.
Podemos utilizar Elza tanto en *nix o Windows. Podemos encontrar el interprete
Elza en http://phiphi.hypermart.net Mediante el uso de Elza podemos: – Examinar
el contenido de un website (Su codigo HTML). – Robar formularios (Hijacking). –
Utilizar Elza bajo SSL. – Lanzar Ataques de Fuerza bruta – Automatizar el
relleno de formularios. – Detectar CGIs. – Evaluar ataques NIDS bajo HTTP. –
Utilizar proxys – Rotar proxys o webs. Elza nos permite usar sus script
remotamente como si fueran CGI y/o desde una pagima web. Esto es una gran
ventaja ya que podemos poner nuestros scripts en una maquina y utilizarlos
desde otra 🙂 SuperCACLS ———- SuperCACLS es una interesante herramienta
para sistemas Windows NT, este lenguaje basado en script “.bat” (de toda la
vida 🙂 puede sernos muy util para comprobar la seguridad de un sistema NT o
una red NT. Este conjunto de utilidades es un producto comercial de Trusted
Systems Services, Inc. (http://www.trustedsystems.com). Tendremos control total
sobre las ACL (Access Control List). Esta diseñado para integrarse sin
problemas en NT y requiere poco aprendizaje por parte del experto en seguridad
🙂 Mediante el uso de SuperCACLS podemos: – Buscar/Borrar/Cambiar permisos en
ficheros o usuarios. – Buscar/Borrar registros – Tanto local como remotamente.
Como he dicho antes, SuperCACLS esta formado por un conjunto de programas, que
son los siguientes: – PRACL = Nos muestra el ACL en el mismo formato que el NT
ACL Manager. – REACL = Para modificar las ACL. (directorios, usuarios, grupos.)
– MODACL = Modifica, remueve o añade ACL individuales. – TAKEOWN = Para
tomar el control de un objeto, o a nosotros el control total 🙂 – RENAMEACL =
Cambia todas las ocurencias de un usuario o grupo de una ACL a otra. Como
podemos apreciar es una herramienta interesante si trabajamos en sistemas NT,
ya que podemos analizar todo el registro en busca de registros
“extraños”, usuarios sospechosos, etc. AdvancedChecker —————
AdvancedChecker es otro producto comercial de Trusted Systems Services, Inc.
(http://www.trustedsystems.com). Es un poderoso lenguaje de script que nos
permite comprobar la seguridad de nuestra red NT o de nuestros IDS inclusos. Es
una formidable herramienta tanto para expertos en seguridad o administradores
en entornos NT. Este herramienta ya requiere un cierto aprendizaje pero es
facil 🙂 Mediante AdvancedChecker podemos: – Comprobar/establecer las
politicas. – Revisar las ACL. – Revisar los Logs. – Modificar el Registro. –
Firmar los ficheros. – Enviar mail si detectamos anomalias. – Comprobrar los
passwords. Utilizando AdvancedChecker podremos comprobar la seguridad de
nuestro sistema NT, de forma rapida y eficaz. ——————— ||Discusion
General|| ——————— Cuando vamos a escribir codigo para probar una
teoria o simplemente para detectar un fallo, debemos tener cuidado con lo que
hacemos. Por ejemplo, hace unos meses salio un adv por parte de ADM sobre
varios fallos en el Bind, posiblemente uno de los fallos mas importante para
pasar al 2000. Si escribimos codigo para detectar este fallo, no podemos
escribir un programa que lo explote, ya que si lo hicieramos nuestro scanner no
podria continuar con el analisis, por ello los scanners de vulnerabilidades
simplemente detectan la version. No siempre nos interesa explotar el fallo 🙂
Si utilizamos CASL debemos tener precaucion, ya que podemos inflinjir
daños en la red que queremos analizar y no creo que a los
administradores les vaya a gustar, sobre todo si es un sistema de produccion.
Al escribir Tests de Seguridad para Nessus, debemos hacerlo en NASL
logicamente. Pero debemos prestar mucha atencion con lo que hacemos ya que el
interprete NASL no detecta si nos hemos equivocado al escribir el Test de
Seguridad. Esto puede ser frustante a la hora de buscar nuestro fallo y ademas
puede causar que el servidor Nessus pete!!! Existen mas lenguajes enfocados en
la seguridad, que pueden sernos de gran interes, los cuales son parte de
conocidas herramientas de seguridad. – Packet Shell, es un lenguaje parecido a
CASL para entornos solaris, disponible en http://playground.sun.com/ – N-Code
es un potente lenguaje del conocido NIDS NFR (http://www.nfr.net). NFR es uno
de los NIDS comerciales por excelencia, para entornos Linux. NFR es un potente
sniffer programable mediante el uso de N-Code. – POST Platform for Open
Security Testing (POST) es un lenguaje parecido a Perl para escribir Test de
Seguridad para el scanner de vulnerabilidades de la casa WebTrends, conocido
como WebTrends Security Analyzer, disponible en
http://www.webtrends.com/default.htm ———————— Conde Vampiro
Roses Labs / w00w00 http://www.roses-labs.com Advanced Security Research.
Ahir vaig estar llegint a fons el funcionament d’aquest filtre de correu per procmail i esta molt bé, avui ha sortit una nova versió a cotinuació enganxo la pàgina on indica el funcionament generic del programa.
La url és ftp://ftp.rubyriver.com/pub/jhardin/antispam/procmail-security.html
There are four types of attacks on system security that can be carried out via electronic mail:
Active Content attacks, which take advantage of various active HTML and scripting features and bugs.
Buffer Overflow attacks, where the attacker sends something that is too large to fit into a fixed-size memory buffer in the email client, in the hopes that the part that doesn’t fit will overwrite critical information rather than being safely discarded.
Trojan Horse attacks, where an executable program or macro-language script that grants access, causes damage, or does other unwelcome things is mailed to the victim as a file attachment labeled as something innocuous, such as a greeting card or screen saver, or hidden in something the victim is expecting, such as a spreadsheet or important document.
Shell Script attacks, where a fragment of a Unix shell script is included in the message headers in the hopes that an improperly-configured Unix mail client will execute the commands.
Active Content Attacks, a.k.a. Browser Attacks, Active HTML Attacks or Scripting Attacks
These attacks are aimed at people who use a web browser or HTML-enabled email client to read their email, which these days is a very large portion of the computing community. Typically these attacks attempt to use the scripting features of HTML or of the email client to retrieve private information from the victim’s computer or to execute code on the victim’s computer without the victim’s consent (and possibly without the victim’s knowledge).
Less dangerous forms of these attacks can automatically cause the recipient’s computer to display some content the attacker wishes, such as automatically opening an advertising or pornography web page when the message is opened, or perform a Denial-of-Service attack on the recipient’s computer through code that freezes or crashes the browser or the entire computer.
The simplest way to completely avoid such attacks is to not use a web browser or HTML-enabled email client to read your email. Since many of these attacks do not depend on bugs in the email client software, they cannot be prevented through patches to the email client. If you use a web browser or HTML-aware email client, you will be vulnerable to these kinds of attacks.
Also, as some of these attack depend on the email client being able to execute scripted HTML rather than depending on the weaknesses of any particular operating system, these attacks can be cross-platform. An HTML-enabled email client on a Macintosh is just as vulnerable to active-HTML email attacks as an HTML-enabled email client on Windows or Unix. The vulnerabilty will vary from system to system based on the email client rather than the operating system.
Switching to a non-HTML-aware email client is not a realistic option for many people. An alternative is to filter out or alter the offending HTML or script code before the email client gets a chance to execute it. It may also be possible to configure your email client to turn off the interpretation of script code. See your program documentation for details. Turning off scripting in your email client is strongly recommended. There is very little reason to support scripted email messages.
These attacks can be used as Denial-of-Service attacks, because when a program’s memory gets randomly overwritten the program will generally crash. However, by carefully crafting the exact contents of what overflows the buffer, it is in some cases possible to supply program instructions for the victim’s computer to execute. The attacker is mailing a program to the victim, and it will be executed by the victim’s computer.
Note that this is the result of a bug in the program under attack. A properly written email client will not allow random strangers to run programs on your computer without your consent. Programs subject to buffer overflows are incorrectly written and must be patched to permanently correct the problem.
Buffer overflows in mail programs occur in handling the message headers and attachment headers, which is information the email client needs to process in order to know details about the message and what to do with it. The text in the body of the message, which is simply displayed on the screen and which is expected to be a large amount of text, is not used as the vehicle for buffer overflow attacks.
The recently-announced overflow bugs in Outlook, Outlook Express and Netscape Mail are examples of this. Patches for Outlook are available via the Microsoft security site.
The message headers and attachment headers can be preprocessed by the mail server to limit their lengths to safe values. Doing this will prevent them being used to attack the email client.
Trojan Horse Attacks
These attacks are usually used to breach security by getting a trusted user to run a program that grants access to an untrusted user, or to cause damage such as attempting to erase all of the files on the victim’s hard disk. Trojan Horses can also act to steal information or resources or implement a distributed attack, such as by distributing a program that attempts to steal passwords or other security information, or a program that mails itself around (a “worm”) and also mailbombs a target (a worm with an attitude :).
For this attack to succeed the victim must take action to run the program that they’ve received. The attacker can use various “social engineering” methods to convince the victim to run the program; for example, the program may be disguised as a love letter or joke list, with the filename specially constructed to take advantage of Windows’ propensity for hiding important information from the user.
This attack can be avoided simply by not running programs that have been received in email until they have been checked over, even if the program seems to be harmless and especially if it comes from someone you don’t know well and trust.
Except…
Bugs in the email client or poor design may allow the attack message to automatically execute the Trojan Horse attachment without user intervention, through either the use of active HTML, scripting or buffer overflow exploits. This is an extremely dangerous scenario and HAS BEEN DEMONSTRATED in a public computer security forum.
In an attempt to prevent this, the names of executable file attachments can be changed in such a way that the operating system no longer thinks they are executable (for example, by changing “EXPLOIT.EXE” to “EXPLOIT.DEFANGED-EXE“). This will force the user to save and rename the file before it can be executed (giving them a chance to think about whether it should be executed), and it reduces the possibility that other exploits in the same message will be able to find and execute the Trojan Horse program automatically (since the name has changed).
In addition, for known Trojan Horse programs the attachment format itself can be mangled in such a way that the email client no longer sees the attachment as an attachment. This will force the user to contact technical support to retrieve the attachment, and gives the system administrator a chance to examine it.
Unmangling a mangled attachment is fairly straightforward for the administrator. In mangling the attachment the original MIME attachment header is shifted down and an attack warning attachment header is inserted. No information is deleted or altered. To reattach the attachment simply edit the mailbox file with a text editor and delete the attack warning header, returning the original attachment header to its original location.
Here is a list of recent Trojan Horse executables and documents, gleaned from bugtraq and Usenet newsgroup warnings and antivirus vendor advisories:
Another channel for Trojan Horse attacks is via a data file for a program that provides a macro (programming) language, for example, modern high-powered word processors, spreadsheets, and user database tools.
If you cannot simply discard attachments that may put you at risk, it is recommended that you install anti-virus software (which detects and disables macro-language Trojan Horses) and that you always open data file attachments in the program’s “do not automatically execute macros” mode (for example, by holding down the [SHIFT] key when double-clicking the attachment).
Also: if your system administrator (or someone claiming to be your system administrator) emails you a program and asks you to run it, immediately become very suspicious and verify the origin of the email by contacting your administrator directly.
Shell Script Attacks
Many programs running under Unix and similar operating systems support the ability to embed short shell scripts (sequences of commands similar to batch files under DOS) in their configuration files. This is a common way to allow the flexible extension of their capabilities.
Some mail-processing programs improperly extend this support for embedded shell commands to the messages they are processing. Generally this capability is included by mistake, by calling a shell script taken from the configuration file to process the text of some headers. If the header is specially-formatted and contains shell commands, it is possible that those shell commands will get executed as well. This can be prevented by the program scanning the header text for the special formatting and changing that formatting before it gets passed to the shell for further processing.
Since the formatting needed to embed a shell script in an email header is fairly special, it’s fairly easy to detect and alter.
Filtering Email for Security
(Finally! The meat!)
Procmail is a program that processes email messages looking for particular information in the headers or body of each message, and takes actions based on what it finds. If you’re familiar with the concept of “rules” as provided in many major user mail clients (such as the cc:Mail client), then you are already familiar with the concept of automatically processing email messages based on their content.
This page provides you with a procmail ruleset specifically designed to “sanitize” your email against these attacks.
Personal safety
Please see my Procmail Kit page for details about how to use procmail, and a kit of rules that includes the sanitizing ruleset as well as anti-spam filters. If you just want to sanitize your email and don’t care about spam, then you can download and install just the sanitizing ruleset. Note that the full kit has an older version of the sanitizing filter, and is not currently being maintained.
If you are downloading this on a Windows system for use on a Unix or Linux system, make sure that you take care of text-file conversion – the script will not run properly with DOS end-of-line characters in it. One way to do this is to open the sanitizer script in vi and type:
:textmode on :textmode off :wq
Site Safety
If you’re an administrator and you wish to sanitize all of your users’ email automatically, here’s how to do it:
Requirements
Your email must be received by a system that runs or can run procmail. See the procmail link above for information about obtaining and installing procmail for your platform.
If you are running sendmail then it must be set up to use procmail as the local delivery agent. Look for the following line in your /etc/sendmail.cf file:
If you wish to scan attachments, you must have mimencode (which is a part of the metamail package) and mktemp installed. I have decided that Mime::Base64 from CPAN is better for this, so sometime soon the sanitizer will use that instead of mimencode.
Installation under *nix and workalikes (Linux, *BSD, etc.)
Create a directory /etc/procmail owner and group root, permissions rwxr-xr-x.
Download the sanitizing ruleset and save it in that directory, owner and group root, permissions rw-r--r--. If you are using Lynx, highlight the above link and press “D” to download the file – don’t view it and save it, it’ll be corrupted.
Create /etc/procmailrc owner and group root, permissions rw-r--r-- and put the following into it:
Of course, if you’ve already got an /etc/procmailrc file you’ll have to incorporate the INCLUDERC=/etc/procmail/html-trap.procmail call into what’s already there.
Notes about local policy:
This will create a file named procmail.log in the home directory of any user who receives mail. Your users should be instructed to periodically review and delete this file, or an administrative daemon (e.g. logrotate) should be set up to periodically collect statistics and delete the files or warn the user to do so. If you don’t care to log the sanitizing messages and possible exploit warnings, then change the logfile line to:
LOGFILE=/dev/null
Note that the DROPPRIVS at the beginning means the log file must be writable by the recipient.
You may override the default list of executable extensions by setting MANGLE_EXTENSIONS. The default list is:
Note that what you specify completely replaces the default list, so, for example, if you don’t want to mangle .EXE files for some reason, you’d specify:
This can also be used to customize the sanitizer on a by-sender or by-recipient basis. For example, if has a legitimate reason to send you .EXE attachments, you might do something like this before calling the sanitizer:
They will still be scanned for poisonous macros and quarantined if appropriate, but they will not be checked against the poisoned executables list (see below).
Note that the MANGLE_EXTENSIONS settings you enter must all be on one line.
If you wish to block specific executable and document attachments, create a text file containing one filename or filespec per line, with no comments or leading spaces, permissions rw-r--r--, and set the variable POISONED_EXECUTABLES to point at that file before calling html-trap.procmail. See above for a recommended list of filenames of known trojans. The names in this list are not case-sensitive and wildcards may be used. For example:
*.hta *.vbs *.chm happy??.exe happy[0-9]+.exe
Note that only extensions in the MANGLE_EXTENSIONS list are compared against the poisoned executables file. Omitting .EXE from MANGLE_EXTENSIONS means you will not be able to poison any .EXE attachments. This is a design weakness in the current sanitizer.
If you wish to be notified when the filter traps poisoned attachments, set SECURITY_NOTIFY and/or SECURITY_NOTIFY_VERBOSE to a comma-delimited list of email addresses to notify. The SECURITY_NOTIFY_VERBOSE recipients will receive a full copy of the message, the SECURITY_NOTIFY recipents will only receive the headers.
If SECURITY_NOTIFY or SECURITY_NOTIFY_VERBOSE are set, then the message sender may also be notified of the message being trapped. To do this, set SECURITY_NOTIFY_SENDER to any value. If you wish to override the simple default message, set SECURITY_NOTIFY_SENDER to point at a text file and that text file will be included as the body of the message – I recommend you explain site policy there if you are blocking attachments by wildcard. If SECURITY_NOTIFY_SENDER is set but not pointing at a file, a simple default message will be sent. NOTE: Be careful that you set it to something that is NOT a file if you don’t want to override the default message. “SECURITY_NOTIFY_SENDER=/etc/passwd“, for example, would be bad. “SECURITY_NOTIFY_SENDER=YES” is probably safe. If you do not want to send a notification reply, you may want to set it explicitly to empty (“”) to avoid any inherited value.
If you wish to quarantine poisoned messages, set SECURITY_QUARANTINE to the file you wish to save the message in. This will prevent delivery to the original addressees. It is suggested that you set SECURITY_NOTIFY if you set SECURITY_QUARANTINE as this will remind you to check the quarantine file. If for any reason the message cannot be quarantined it will be bounced and the SECURITY_NOTIFY list will be notified. If you want the (mangled) message to be delivered instead of bounced, set SECURITY_QUARANTINE_OPTIONAL to any value. The SECURITY_QUARANTINE file must already exist – the sanitizer cannot reliably create it on-the-fly.
Note that the DROPPRIVS at the beginning means that the security quarantine file must be writable by users: access permissions on the quarantine file must be -rw--w--w-. If this is a problem, you may want to try setting the quarantine filename to /dev/null and rely on SECURITY_NOTIFY_VERBOSE to keep a copy of the original message.
The sanitizer implements a scanner which checks Microsoft document and worksheet attachments for macros that appear to be trying to do dangerous things. Depending on what the macros in a document or worksheet try to do, you may see false positives (safe documents being marked as dangerous). The score at which an attachment is considered “poisoned” may be set via POISONED_SCORE. If not given, it defaults to 25. The minimum POISONED_SCORE is 5.
It appears that many virus scanners do not actually delete evil macros; instead, they are mangled enough to disable them and are left in place. The sanitizer will very likely detect enough of these fragments to consider the document as still infected. If this happens, suggest to the sender of the document that they save the document in a format that does not support macros at all, such as Rich Text (RTF).
If you wish to completely disable macro scanning, set DISABLE_MACRO_CHECK to any value. If you wish to scan and save the scores to do profiling but not mark any attachments as “poisoned”, you can either set SCORE_ONLY to any value (not recommended), or set POISONED_SCORE to a very high value (100-200 is recommended – this will trap currently known exploits while giving you a chance to profile). Set SCORE_HISTORY to the name of the file to save scores in (with the same DROPPRIVS caveats as the other log files).
All of these site policy customizations must be made in the procmail script that calls the sanitizer, before the sanitizer is called, or they will have no effect on the sanitizer’s behavior.
Suggestions for what to consider dangerous in a macro are welcome, as are samples of infected documents.
An announce list for email security issues has been set up. It will primarily carry information on new exploits and updates of the sanitizer. To subscribe, send a message with the subject “subscribe” to esa-l-request@spconnect.com.
08/04/00 Okay, don’t trigger the Excessively Long Header trap until the header exceeds 250 characters. Added asd to the default MANGLE_EXTENSIONS. If you are overriding the default list you should add it to your custom list. Fixed a problem where it was possible for the sanitizer to overlook every other attachment in a series of document attachments. Added clearing of the MIME content type if the attachment filename gets mangled, to prevent the mail program from figuring out what program to run even though the filename is mangled. For the same reason, drop x-mac-* clauses that Eudora uses to indicate the file type and restore the filename extension.
07/26/00 Bugfix in NOTIFY SENDER.
07/23/00 Added checks for certain excessively long standard headers, to address the MS Outlook header buffer-overflow bug; previously only MIME-related headers were length-limited, and only in MIME messages. Disabled sanitizing of encrypted/signed messages; changing the body of such a message breaks the signature, so there’s no good way to sanitize it. Moved DROPPRIVS=YES into the sanitizer itself to avoid configuration errors – this may break gateway use, watch it closely. Enabled scanning of PowerPoint files, which weren’t being scanned due to an oversight (D’oh!). Improved handling of RFC822 comments embedded in unquoted attachment filenames. Improved handling of filenames containing international characters. Added a debugging mode – if you want to see the poisoned filespecs it is comparing attachment names to, define $DEBUG to be anything. Improved loop-prevention in notification messages; if you want to secure your system against someone forging the X-Loop: headers in an attempt to suppress attack notification messages, define $SECRET to be a short string of random text. Given the severity of the Outlook BO bug, you probably want to install the updated sanitizer right away.
05/18/00 (Announcement here delayed, sorry) Okay, it’s happened. A working demonstration attack that uses a combination of active-scripted HTML and a scriptable attachment (in the form of a Microsoft Compiled Help file) to automatically save and execute an arbitrary program remotely via email without the user having to double-click on an attachment has been posted to Bugtraq. This means that, for example, someone could email you a copy of Back Orifice that would install itself on your computer the moment you simply previewed the message in your mail client. Make sure that chm appears in your MANGLE_EXTENSIONS list and that *.chm is in your poisoned executables list. You should also visit this page that describes tightening down Outlook’s security settings.
05/22/00 Added some new executable extensions to MANGLE_EXTENSIONS. See above for the new default. Fixed a bug that prevented macro scanning if document attachments were in MANGLE_EXTENSIONS. Dynamically set LINEBUF so that we’re no longer vulnerable to extremely long To: headers.
05/14/00 Fixed a bug in notification. Added error logging on failure to open poisoned spec file.
05/13/00 Made sender notification optional. Added ability to specify executable extensions list in configuration file. No more script updates for new executables! Site-customized executable mangling!
05/10/00 Added “.vbe” to the executable extensions list. You should add “*.vbe” to your poisoned executables list. Fixed a problem where a message that was *only* a poisoned executable (e.g. no text body at all) wouldn’t be quarantined.
05/06/00 Added “.wsf” and “.wsh” to the executable extensions list. Fixed another DoS bug in header fixups. Fixed a missing executable extension in the UUE checker. Added notification of the message sender on hits.
03/26/00 Added “.eml” to the executable extensions list. Dynamic configuration of this soon…
02/01/00 Improved handling of quotes in tag arguments.
01/22/00 Sanitizer now deals with attempted obscuration of tag options with and % escapes.
01/14/00 Fixed another DoS bug in certain quoted strings, and generally improved quoted string and wrapped-header handling.
Do not put html-trap.procmail into /etc/procmailrcs/ as implied by the procmail man page. You’ll get security errors from Perl about -e and setuid scripts if you do this. You may also have problems with filtering mail sent to root for this reason.
It looks like this perl script can be a bit of a memory hog on some systems. If you start getting “Out of memory” errors in your procmail log file, try adding
ulimit -d 15000;
just before the perl -p -e in the MIME-sanitizing rule:
:0 fw | ulimit -d 15000; perl -p -e ' #
You might also have to increase the hard memory limit originally set for sendmail.
