Seguridad Crítica

Vulnerabilidad mundial DNS, ¿navegar a punta de IP?

2008-07-25T11:06:00.003-04:00

Varios ISPs en Chile siguen sin parchar sus servidores DNS contra una vulnerabilidad con parche disponible desde comienzos de julio 2008, exponiendo a sus respectivos clientes a visitar sitios fraudulentos, lo que puede significar desde que les roben su dinero en el banco hasta perder el acceso a muchas de sus cuentas de usuario y correo electrónico.

Por mientras, hay que revisar los certificados digitales de los sitios que visitemos para poder identificarles posteriormente.

Habeas Data - Solicitud de Cesación y Desistimiento

2008-07-22T16:39:00.003-04:00

CIUDAD, FECHA

Sres. EMPRESA,

Con Copia a: PERSONA, CARGO

Con fecha FECHA, recibí de vuestra parte en mi domicilio particular
una oferta de Crédito Preaprobado por un monto de MONTO, cuyo
remitente corresponde a PERSONA, CARGO.

Mediante la presente, dejo constancia de que yo no tengo ningún tipo
de relación comercial con uds. Sin embargo, veo cómo uds. vulneran la
privacidad de mis datos personales al hacerme llegar tal misiva
publicitaria. Considerando los datos de mi titularidad que uds.
plasman en aquél panfleto publicitario, deduzco que uds. manipulan al
menos la siguiente información con respecto de mi persona:

1.

Mi Rol Único Tributario (RUT),
2.

mi Nombre Completo y
3.

mi Dirección Postal Particular.
4.

Considerando, además, la eventual posibilidad de que uds. hayan
realizado algún tipo de análisis de mi situación financiera, supongo
que uds. han de tener acceso a mis Antecedentes Comerciales.

Según lo expuesto por la Ley Nº 19.628 sobre la protección de la vida
privada, les exijo el cumplimiento de los siguientes derechos de los
cuales soy beneficiario:

1.

Que me informen en forma precisa y fidedigna el detalle completo
de todos los datos de carácter personal que uds. almacenen actualmente
con respecto a mi persona. En esta categoría incluyo no sólo a los
datos mencionados en la presente, sino que a todos aquellos datos que
uds. estén tratando en forma automatizada sin mi conocimiento ni
consentimiento.
2.

Que me informen en forma precisa y fidedigna la procedencia a
partir de la cual uds. tuvieron acceso a tales datos personales, así
como quién fue el destinatario de tal transmisión de datos.
3.

Que eliminen y cancelen todos los registros de los datos
personales que uds. almacenen con respecto a mi persona, considerando
tanto aquellos correspondientes a la actualidad como a todos los
respaldos históricos que uds. tengan de ellos en cualquier tipo de
banco de datos.

Solicito, además, que se identifique ante mí al responsable de los
bancos de datos en donde los míos están almacenados, de modo de poder
proseguir con acciones legales ante sí en caso de considerarlo
pertinente.

Téngase en cuenta que mi solicitud de eliminación de registros es de
carácter definitivo a menos que yo indique explícitamente lo
contrario, por iniciativa propia.

Permaneceré a la espera de su respuesta dentro de los próximos dos
días hábiles, según lo estipulado legalmente, tras lo cual procederé a
comunicar mi reclamo ante el SERNAC en caso de que aquella no me sea
satisfactoria, sin descartar acciones ante algún Juzgado de NO SE.

Dejo expresa constancia de que los datos personales de mi titularidad
contenidos en esta misiva están destinados exclusivamente a permitir
la expedita comunicación entre uds. y yo, restringiéndose su
autorización de uso en forma exclusiva para las comunicaciones
derivadas del seguimiento de este caso. Además, les prevengo que me
reservo el derecho de publicación del contenido de las comunicaciones
derivadas directa o indirectamente de este caso, considerando
cualquier medio para la realización de tal comunicación y cualquier
medio para su eventual publicación.

Atte.

MI NOMBRE

RUT: MI RUT

Dirección: MI DIRECCIÓN

E-mail: MI E-MAIL

Autor: Luis León Cárdenas Graide
http://www.dcc.uchile.cl/~lcardena

Documento protegido por una Licencia Creative Commons
Atribución Autor - Modificacar y Derivar - No Comercial - Licenciar Igual
http://creativecommons.org/licenses/by-nc-sa/2.0/cl/

Cómo navegar bajo fuego sin quemarnos en el intento

2007-12-22T15:39:00.000-03:00

Hoy en día, el navegar tranquilamente por Internet es una fuente directa de exposición a ataques e infección por malware.

Objetivos típicos

Ciertos objetivos típicos de los ataques dirigidos a los usuarios son:

(1) Inyección remota y ejecución arbitraria de código.

Aprovechándose de algún desbordamiento de buffer intermedio en la aplicación cliente, tras contactar a una contraparte maliciosa, el atacante toma control de la aplicación vulnerable. Con esto, el atacante consigue que la aplicación afectada ejecute lo que él quiera ejecutar, con las restricciones de seguridad del usuario que estaba corriendo la aplicación. Además, en el caso específico de Windows, dado que suele trabajarse con privilegios de Administrador, esto da paso directo a convertir nuestra máquina en un robot zombie de una botnet bajo las órdenes de algún delincuente informático.

Aplicaciones Cliente típicamente expuestas: navegador web, lector de correo electrónico, cliente de mensajería instantánea, visualizador/editor de documentos/imágenes, etc.

Vectores típicos de infección de las aplicaciones: Páginas web maliciosas o infectadas, correos electrónicos con adjuntos infectados (peor si son ejecutables), etc.

(2) Robo de credenciales.

Aprovechándose de alguna vulnerabilidad de tipo XSS en algún sitio web de interés para el usuario, se nos expone a ejecutar código script (típicamente JavaScript) arbitrario creado por el atacante, bajo el contexto de seguridad del nombre de dominio del sitio que estamos visitando. Mediante esta técnica, el uso típico es robar las cookies del sitio en cuestión almacenadas en el navegador, cosa que puede ser grave si aquellas almacenan información de identificación ante el mismo. Peor aún es el escenario si en el sitio explotado usan técnicas de CSRF, pues nos pueden robar las credenciales mientras navegamos por otros sitios. Dependiendo del caso, esto puede ocurrir tanto si navegamos simultáneamente por ambos, como si estuviésemos navegando solamente por el sitio de infectado.

Las credenciales (cookies de identificación) típicamente apetecidas por los atacantes son aquellas correspondientes a sitios relacionados con: cuentas bancarias, cuentas en sitios de comercio electrónico (e-commerce) "famosos" (Amazon, PayPal, eBay, etc.), cuentas de correo electrónico, cuentas en sitios de redes sociales (LinkedIn, FaceBook, MySpace, Blogger, etc.), etc.

Si además en Windows navegamos como Administrador, un ataque del tipo (1) permite capturar todo lo escrito "mediante el teclado" (KeyLoggers) y todo lo visto "mediante la pantalla" (Screen Grabbers). Valga la obviedad, pero así de extremo es.

Cómo protegernos

Es iluso esperar que las aplicaciones (tanto clientes como servidoras) nunca tengan vulnerabilidades. Entonces, dado que no podemos controlar qué tan bien nos protegen las aplicaciones y los servidores, trataremos de cortar la veta desde donde obtienen el beneficio los atacantes una vez que logran realizar el ataque con "éxito".

Estas medidas no pretenden ser "a prueba de balas", pero al menos permitirán protegernos contra las vulnerabilidades más típicas y los ataques más típicos, conservando la mayor funcionalidad, dentro de lo posible.

Comenzaremos por lo más simple:

Robo de credenciales

En el navegador web, el robo de credenciales y posterior suplantación de identidad, se reduce técnicamente a la lectura no consentida y posterior retransmisión de nuestras cookies.

Ante esto, aparecen las primeras recomendaciones más básicas:

Recomendación #1: No navegar simultáneamente por sitios de seguridad crítica y "el resto" de Internet.

Recomendación #2: Cerrar sesiones abiertas en sitios de seguridad crítica una vez que dejemos de usar el sitio.

El no hacerlo, deja las sesiones "abiertas", pues el servidor nunca recibió nuestro requerimiento de olvidarse de nosotros, dejándonos expuestos mientras no se cumpla el período de expiración de la sesión en el servidor. Ante un ataque CSRF, nuestra exposición sería directa. NO BASTA SIMPLEMENTE CON CERRAR LAS PÁGINAS/TABS/LENGÛETAS, pues las cookies validadas seguirán almacenadas en el repositorio de cookies del navegador y serán enviadas ante "forged queries".

Asumiendo que el atacante ya consiguió ejecutar código script arbitrario en nuestro navegador para robar nuestras cookies, no le demos lo que quiere. ¿Cómo? Simple: no teniéndolo. Naturalmente, no estoy proponiendo desistir del uso de cookies, pues hoy en día poco se puede hacer sin ellas y perderíamos mucha funcionalidad. Simplemente almacenémoslas en perfiles distintos, de modo que el compromiso de un repositorio de cookies no implique el compromiso del otro, y así trabajamos con un repositorio para transacciones de seguridad crítica y con otro para "el resto" de Internet. Esto da pie a la siguiente recomendación:

Recomendación #3: Usar perfiles (y, por ende, repositorios de cookies) distintos para navegación de seguridad crítica que para navegación "normal" (o, derechamente, "suicida", lo que requeriría un 3er perfil ;P ).

En Firefox, las opciones -P profile y -ProfileManager pueden ser de utilidad.

Sin embargo, ante un ataque de tipo (1), esta prevención también puede ser vulnerada, pues se muda de perfil, pero no de aplicación ni permisos. Ante ello, una posible mejora contra ataques "a ciegas" (en contraposición con los "dirigidos") es utilizar un navegador para "todo lo demás" y otro para navegación de seguridad crítica.

Por cierto que no todo es blanco/negro, así que es perfectamente posible tener más de 2 perfiles. No es lo mismo navegar por el sitio del banco que por un webmail o por sitios de redes sociales.

Recomendación #4: Usar programas distintos para navegación simultánea de seguridad crítica y para navegación normal (y no mezclarlos).

En mi caso, uso Mozilla Prism para navegación de seguridad crítica y dejo mi Firefox híper-enchulado para navegación normal. La gracia es que funcionan como programas separados, cada uno con su propio repositorio de cookies.

Esto ya requeriría ser vulnerado con un ataque del tipo (1), situación que analizamos a continuación:

Inyección remota y ejecución arbitraria de código.

Puesto que tampoco podemos esperar que los agentes de usuario (o sus plugins y extensiones) no tengan desbordamientos de buffer, tampoco podemos evitar que tomen control del proceso de la aplicación con la que navegamos. Como tal proceso corre bajo nuestros permisos de usuario, queda virtualmente libre para acceder/realizar todo lo que nuestro perfil de usuario del sistema nos permite. ¿Cómo lo enfrentamos? Pues nuevamente, con separación de privilegios.

La primera recomendación básica es NO trabajar cotidianamente con privilegios globales sobre el sistema.

Recomendación #5: Utilizar permisos restringidos para aplicacio'nes de riesgo.

En los sistemas basados en Unix/Linux, esto es práctica normal y está todo diseñado para que se pueda realizar sin inconvenientes. En los sistemas basados en Windows, la experiencia puede ser más frustrante pues se suele obtener ejecuciones entorpecidas de las aplicaciones de aplicarse estas restricciones. Si bien en la actualidad esto ha ido mejorando (aunque todavía falta bastante para equiparar a Unix al respecto), aún persiste la costumbre (y la configuración por omisión del sistema) de hacer todo bajo privilegios de superusuario. Considerando que al menos al 90% de los usuarios no les interesa preocuparse por la seguridad de sus sistemas y que el 90% de los usuarios de Internet usa Windows, no es de extrañar el descomunal tamaño que están alcanzando las botnets hoy en día, situación que ha contribuido enormemente a poner en grave riesgo la seguridad en Internet durante los últimos años.

La implementación siguiente es específica para Linux (en mi caso, KUbuntu), pero sus ideas pueden ser extrapoladas para otros sistemas. Quienes no puedan evitar tener que usar Windows, pueden pedirle asesoría técnica de cómo hacerlo al vendor a quien le compraron la licencia }:-] (broma).

Algo de esto ya ha incorporado Windows Vista al implementar el modo de permisos reducidos expecíficamente en Explorer 7, pero acá vamos a ver cómo hacerlo en forma más general. La gracia es que no sólo protegeremos nuestros datos de usuario de inyecciones al navegador web, sino que ante inyecciones a cualquier visualizador de documentos potencialmente malignos: e-mails, PDFs, macros de Office, fotografías, música, video, etc.

Esta solución está pensada para usuarios hogareños incluso en sistemas multiusuario (por ejemplo, con cuentas para familiares, amigos y visitas). Para servidores, si bien también puede aplicarse, puede ser poco práctico y es más recomendable SELinux.

Usuario trinchera

La idea es que dejemos nuestra cuenta de usuario normal solamente para navegaciones/visualizaciones de seguridad crítica (banco, quizás webmail) y creemos otra cuenta de usuario todavía más restringida, bajo nuestro control, que dejaremos para mandar a la guerra a la aplicaciones bajo sus permisos.

Supongamos que mi usuario:grupo es lux(1000):lux(1000). Procedemos entonces a crear otro usuario:grupo que usaremos como trinchera para navegación insegura:


% sudo addgroup --gid 1001 xul
% sudo adduser --home /home/xul --uid 1001 xul
% sudo addgroup xul xul

No debemos obviar la calidad de la contraseña que le definiremos, la cual, muy preferentemente, debe ser distinta a la nuestra.

La idea es que hagamos todo lo inseguro usando al usuario xul, el cual no deberá poder mirar nada de nuestro usuario oficial lux, pero cuyos archivos deben poder ser accesibles por lux. Para esto, agregamos a nuestro usuario oficial (¡y sólo a él!) al grupo del usuario trinchera:

% sudo addgroup lux xul

Con esto, nuestro usuario oficial tendrá acceso a todos los archivos que el usuario trinchera permita dentro de su grupo. Para que por omisión queden todos sus archivos disponibles para nuestro usuario oficial, necesitamos modificar su UMASK en el archivo de configuración de su login shell:


lux % su xul
xul % vim ~/.bash_profile

Y donde dice umask 077 debe decir umask 007.

Y no olvidemos proteger el acceso a su $HOME así como protegemos el nuestro. De paso, damos los permisos al usuario oficial vía los permisos de grupo:

xul % chmod -R u=rwX,g=rwX,o-rwx $HOME

Listo. Ya tenemos configurada la cuenta del usuario trinchera. Ahora trabajaremos en la cuenta del usuario oficial para acceder fácilmente a las aplicaciones inseguras vía el usuario trinchera desde el usuario oficial.

En nuestra cuenta podemos crear un subdirectorio ~/bin/ y, dentro de él, dejar el siguiente archivo (que llamaremos cage.sh, pues es algo más básico que un jail :P).

Archivo cage.sh:


#!/bin/bash

if [ -z "$CAGE_USER" ]; then
echo Environment variable CAGE_USER not defined.
exit 1
fi

CMD=$(basename $0)

SU=`which sux`
if [ _$SU == _ ] ; then # SU
SU=`which su`
exec "$SU" "$CAGE_USER" --command="$CMD $@"
else # SUX
exec "$SU" "$CAGE_USER" "$CMD" $@
fi

Este programa se encarga de ejecutar en forma genérica los programas que queramos como usuario trinchera, dependiendo del nombre con el que lo llamemos al invocarlo con el usuario oficial.

Como pueden ver, el nombre del usuario trinchera lo obtiene a partir de la variable de ambiente CAGE_USER. Para el ejemplo, en algún lugar de nuestro profile deberemos configurarlo así: (por ejemplo, para Bash, en ~/.bash_profile)

export CAGE_USER=xul

Y por comodidad, el nombre cage es conveniente ante cage.sh:

% ln -s cage.sh ~/bin/cage

Este archivo debe tener permisos de ejecución:

% chmod u=rwx,og=rx ~/bin/cage

También deben notar que intenta usar primero al comando sux y, si no lo encuentra, intenta después con el comando su.

Atrincherando aplicaciones

Ahora estamos casi listos. Para cada programa que queramos ejecutar con los privilegios del usuario trinchera, creamos un link simbólico a cage. Por ejemplo, para correr un Firefox "atrincherado", haríamos:

% ln -s cage ~/bin/firefox

Luego, si ejecutamos ~/bin/firefox, tendremos a nuestro querido navegador full-featured andando con cadenas, mientras que si ejecutamos directamente firefox, lo ejecutaremos como usuario oficial.

Esto puede ir más allá y podemos atrincherar todas las aplicaciones que encontremos peligrosas. Por ejemplo, si encontramos riesgoso abrir archivos PDF recién descargados, podemos atrincherar nuestro visualizador de PDF, como lo es el caso de KPDF:

% ln -s cage ~/bin/kpdf

Así, para ver un PDF potencialmente maligno, ejecutamos:

% ~/bin/kpdf archivo.pdf

O si queremos ver planillas con macros virulentas (salvando incompatibilidades de formato):


% ln -s cage ~/bin/oocalc
% ~/bin/oocalc planilla.xls

Y así con cada aplicación que queramos "black-listear". Ciertamente que una lista negra no es la mejor solución de seguridad, pero si lo limitamos al universo (generalmente reducido) de aplicaciones que utilizamos regularmente, puede ser de mucha utilidad, sin perder funcionalidad.

Algunas simplificaciones

Para evitar tener que escribir la ruta completa de la aplicación atrincherada cada vez que necesitemos ejecutarla, surge la tentación de anteponer el directorio de cage a nuestro PATH, configurándolo en alguno de nuestros archivos de inicialización:

export PATH=$HOME/bin:$PATH

El problema de esto es que cage entraría en un ciclo infinito de auto-invocaciones, pues invocaría una y otra vez a la aplicación atrincherada y nunca pasaría a ejecutar a la aplicación deseada (gracias al uso de exec, esto se limita a un sólo proceso y no botará el sistema, bastando interrumpir su ejecución con Control+C).

Una alternativa es crear un mini script que invoque a las aplicaciones atrincheradas por nosotros:

Archivo ~/bin/trinchera.sh:


#!/bin/bash

APP=$1
shift

if [ _ == _$APP ] ; then
echo Uso: `basename $0` 'programa [ argumentos ]' ;
exit 1 ;
fi

exec "~/bin/$APP" $@

Le damos permisos de ejecución con:

% chmod u=rwx,go=rx ~/bin/trinchera.sh

Acortamos su uso con:

% ln -s trinchera.sh ~/bin/trinchera

Y así ejecutamos simplemente (con ~/bin en nuestro PATH):

% trinchera firefox

Lo cual podría ser más cómodo si la ruta es engorrosa.

Ahora, a crear íconos en vuestros menúes y Desktops y ¡a la guerra! :)

De vuelta a lo oficial

Una vez que hayamos terminado de trabajar con la aplicación atrincherada y queramos, por ejemplo, rescatar los documentos que hayamos descargado dentro de la cuenta del usuario trinchera, procedemos a:

(1) Escanear con antivirus lo descargado:


% ln -s cage ~/bin/clamscan
% trinchera clamscan -r ~xul/descagas/

(2) Recuperar los documentos:

% mv ~xul/archivo_descargado ~/mis_descargas

Esto último se puede hacer así de simple porque nuestro usuario oficial pertenece al mismo grupo que el usuario trinchera y éste último nos dio permisos de escritura al grupo.

(3) Enviar documentos:


% ln -s $PWD/mi_documento ~xul/uploads
% trinchera firefox
# ... enviarlo
% rm ~xul/uploads/mi_documento

Limitaciones

El uso de este usuario trinchera no protege ante ataques de elevación de privilegios, pues aquellas vulnerabilidades radican o bien en el kernel o bien en otros procesos que ya están corriendo como superusuario. Al menos, la gracia es que se reduce la probabilidad de ataque, pues se requiere tanto una vulnerabilidad de inyección de código como una vulnerabilidad de elevación de privilegios.

Espero que les guste y les sirva. Cualquier comentario o mejora es bienvenido.

Have a nice bit.

Autor: Luis León Cárdenas Graide
Licenciado bajo Creative Commons. Algunos derechos reservados.

xtrlock - Bloqueo minimalista de X

2007-09-30T00:26:00.000-04:00

Una medida básica de seguridad es monitorear la actividad de los sistemas que se pretende proteger, analizando alzas de carga, tiempos de respuesta, alcanzabilidad de los nodos, tráfico de red, pérdidas, tasa de despacho y un sinfín de otras estadísticas. Naturalmente surge la necesidad de contar con una estación de monitoreo dedicada a tales efectos, de modo que el monitoreo pueda ser realizado en tiempo real y revisado por el operador del mismo modo, ante la búsqueda de anomalías y a la espera de alertas automáticas.

Por otra parte, es deseable que la estación de monitoreo no pueda ser manipulada por personal no autorizado en ausencia del operador, la cual puede ser provocada por cualquier urgencia o eventualidad.

Hay un programa llamado xtrlock que permite bloquear al servidor X en forma minimalista, pero manteniendo el despliegue gráfico de las aplicaciones en ejecución. Durante el período de bloqueo, reemplaza el puntero del mouse por un candado. El control del teclado y del mouse serán recuperados una vez que se tipée correctamente la contraseña del usuario que realizó el bloqueo.

Operador, puedes partir corriendo al sanitario si lo deseas. Nadie tocará tu estación ;)

Seguridad por Bajo Perfil

2007-08-31T22:41:00.000-04:00

Prevenir vale más que curar. Para evitar incidentes de seguridad en nuestros sistemas es imprescindible defenderlos bien, pero toda defensa tiene su costo y debe evaluarse a conciencia la relación costo/beneficio de las medidas implementadas.

Dado que la batalla por la seguridad es una carrera armamentista entre el presupuesto que el atacante está dispuesto a invertir para conseguir su objetivo y el de quien debe implementar las contramedidas para defenderse y prevenir nuevos ataques, mala inversión es para quien se defiende el entrar en una carrera de inyección de recursos contra el atacante.

En la evaluación de costo/beneficio del atacante influye el costo que le significa realizar el ataque versus el beneficio que puede obtener como resultado del éxito del mismo (típicamente económico, aunque no exclusivamente). Mientras más sustanciosos puedan ser los beneficios obtenidos por el atacante tras un ataque exitoso, más precauciones y recursos deberá invertir el defensor para resistir tales embistes.

En este artículo quiero discriminar entre la Seguridad por Oscuridad y la Seguridad por Bajo Perfil.

El paradigma de Seguridad por Oscuridad ha sido ampliamente debatido y rebatido: simplemente no funciona en el largo plazo (y, lamentablemente, es ampliamente utilizada en implementaciones de software hechas bajo la modalidad de código propietario). El atacante siempre tiene suficiente tiempo e indefectiblemente termina descubriendo las vulnerabilidades de seguridad escondidas, pero no resueltas.

Al evaluar el riesgo de seguridad que significa una amenaza de seguridad sobre una vulnerabilidad de seguridad, los factores que intervienen son: la probabilidad de ser atacado, la probabilidad de que el ataque tenga éxito y el impacto en costo asociado a la pérdida económica producto de un ataque exitoso. El producto de estos tres factores permite cuantificar el riesgo. Como producto que es, el aumento o disminución (céteris páribus) de cualquiera de ellos, aumenta o disminuye, respectivamente, el riesgo total. Y como de economía se trata, el disminuir alguno de los factores de riesgo resulta en un costo que requiere inversión económica. Dado que los recursos económicos son escasos, una estrategia prudente en pos de no aumentar los costos es, al menos, evitar incrementar la cuantía de los factores de riesgo.

Al referirme a Seguridad por Bajo Perfil, quiero decir justamente esto último: ya que sale caro disminuir el riesgo, al menos evitemos aumentarlo. Una forma barata de conseguirlo es manteniendo un perfil bajo, así llamamos menos la atención de los atacantes y disminuímos la probabilidad de que se fijen en nosotros. Esto disminuye el riesgo, pues disminuye la probabilidad de ser atacados.

¿Cómo mantener un perfil bajo en lo que a seguridad se refiere? Lo típico es no ir por el mundo haciendo anuncios acerca de la calidad de nuestra seguridad, con lo que evitamos tentar a los más peligrosos. Pregonar que "nuestro sistema es seguro" o que "nos comprometemos con la seguridad de nuestros clientes" es una forma de llamar la atención sobre la infraestructura de seguridad que decimos (o creemos) tener. Si la oferta de seguridad informática no está en interés directo con nuestro modelo de negocios, puede ser mejor omitir hacer comentarios acerca de nuestra seguridad y simplemente dedicarnos a fortalecerla en forma silenciosa.

Lamentablemente, siempre existe la posibilidad de que atentemos contra nosotros mismos en los dos aspectos discutidos: implementando nuestra seguridad deficientemente y llamando la atención más de la cuenta.

Esto parece ser lo que le ocurrió a www.maomava.com. El día 30/08/2007 salió un artículo en el diario Las Últimas Noticias con respecto a un servicio de reparto de snacks y bebidas alcohólicas a domicilio, cuyo nicho de mercado son los grupos de amigos enfiestados para quienes puede ser contraproducente o incómodo tener que salir a comprar en avanzadas horas de la noche para continuar disfrutando. ¿Y cuál es el problema? Pues el nombre del a empresa, que hace referencia al dicho "Si la montaña no va a Mahoma, entonces Mahoma va a la montaña". Ante el interdicho del periodista con respecto a la falta de una letra "H", el entrevistado respondió que lo sabía, nada más que "no quería herir susceptibilidades".

Pues tal precaución no fue suficiente ya que el mismo día, al entrar al sitio web de la empresa, se apreciaba un defacement que decía "0wnz by blueenet // İslamic HackerS !!!". Por cierto que el nombre de la empresa puede haber sido llamativo y de fácil recuerdo para el público, pero tengo mis dudas con respecto hasta qué punto se evaluó verdaderamente el impacto que tal nombre tendría sobre la probabilidad de ser atacado. Ignoro cuántas ventas habrán perdido a causa de esto, pero si el negocio era fructífero, no creo que hayan sido pocas. Hasta el momento de escritura de este post, todavía no logran volver a levantar el servicio.

En ese sentido, el haber elegido tal nombre para la empresa atentó contra su propia Seguridad por Bajo Perfil.