Threads, procesos y cómo estos afectan la seguridad de un sistema (explicado de forma que lo entiendas)

No conozco programador Python que no alucine trabajando con «threads» y «process» y a pesar de ello, muy pocos son los que realmente saben de qué se trata. Pero esto no es lo peor. Lo peor, es que desconocen los riesgos de seguridad que una mala implementación de hilos y procesos puede generar en todo un sistema informático.

Si ya trabajas con «threads» y «process» este artículo te aclarará algunas dudas con respecto a la seguridad del sistema. Pero si aún no haz llegado hasta allí, es una buena forma de comenzar, puesto que te lo explicaré de forma que lo entiendas, sin rollos ni tecnicismos inútiles.

¿Qué es un proceso?

Primero que nada, vamos a tratar de entender qué es un proceso.

Un proceso, no es más que una parte de un programa que se está ejecutando. Técnicamente es un conjunto de instrucciones haciendo uso de un conjunto de recursos del sistema.

¿Qué son los recursos del sistema?

Cuando hablamos de recursos del sistema nos referimos a uso de memoria RAM, Swap, CPU, tiempo de ejecución, entre otros recursos menos relevantes

Por este motivo, cuando se dice que un programa hace un mal uso de los recursos del sistema, por lo general es debido a la ejecución desorganizada que hace de sus propios procesos.

¿Qué es un thread (hilo)?

Un hilo (thread en inglés) es similar a un proceso en cuanto a que también representa un conjunto de instrucciones. Sin embargo, los hilos se diferencian enormemente de los procesos, paradójicamente, por la administración que hacen de los recursos del sistema. Y esta última, es la característica que diferencia a los hilos de los procesos, tal como te lo explico en el siguiente párrafo.

Threads vs. Procesos: ¿cuál es la diferencia entre hilos y procesos?

La diferencia fundamental, es que ambos administran los recursos de formas diferentes. Mientras que los diferentes procesos de un mismo programa ocupan diferentes espacios en la memoria, diferentes hilos comparten un mismo espacio. A primera vista, esto nos puede hacer suponer que los threads son una mejor alternativa que los procesos, puesto que utilizarán menor espacio de memoria. Esto es muy cierto, pero no son la panacea. Pueden acarrear múltiples problemas de seguridad tal como explicaré más adelante. No obstante, el uso de procesos en vez de threads, también solucionará problemas -a nivel seguridad de la aplicación- que estos últimos no tienen capacidad de resolver. Pero vayamos de a poco.

Problemas de seguridad generados por los threads

Todo conjunto de hilos o de procesos, probablemente necesite compartir información entre ellos. Sin lugar a dudas, será mucho más fácil compartir información si se comparte un mismo espacio de memoria, que hacerlo si hay que estar saltando de un puntero hacia otro. Por consiguiente, compartir información será mucho más fácil para los threads que para los procesos.

Sin embargo, compartiendo grandes cantidades de información y haciendo un uso significativo de tareas concurrentes a través de threads, se pueden producir dos vulnerabilidades trágicas: Una de ellas, la llamada «bloqueo mutuo» (deadblock en inglés); la otra y a la vez más peligrosa, la denominada «condición de carrera» (race condition en inglés).

Bloqueo mutuo (deadlock): Es el bloqueo irreversible de un conjunto de hilos o procesos.

Un bloqueo mutuo es lo que sucede cuando un programa se te queda “colgado” y te ves en la obligación de “matar un proceso” ya que el conjunto de hilos o procesos bloqueados, no tiene solución.

Condición (o estado) de carrera: Es aquel que se produce cuando varios hilos o procesos intentan modificar de forma simultánea a un mismo recurso.

Si más de un hilo o recurso intenta modificar el estado o valor de un mismo recurso al mismo tiempo, los datos dejan de ser confiables y por consiguiente, es correcto afirmar que los datos quedan corruptos.

Por ejemplo, si Juan y Ana intentan modificar la contraseña del usuario admin al mismo tiempo. Juan decide colocar 123456 y Ana, 223344 ¿cuál de las dos claves será finalmente, la clave del usuario admin? La respuesta es que si el programador no contempló está posibilidad, será imprevisible conocer la clave. Incluso, podría quedar corrupta a tal punto de quedar sin clave. Esta concurrencia mal implementada es la que se denomina condición de carrera, donde los actores “compiten” por ver quien “gana” la modificación del dato.

Los estados de carrera en un sistema informático son fácilmente explotables mediante «exploits» locales. Por ese motivo, representan uno de los riesgos de seguridad más graves en un sistema.

Linux y GNU vs Sistemas Operativos privativos

En más de una oportunidad habrás escuchado decir que Linux (el kernel) y los sistemas operativos GNU que lo implementan, hacen una mejor administración de recursos que los sistemas operativos privativos comúnmente usados por el usuario promedio y que no se encuentran basados en Unix.

Esto simplemente hace referencia al costo que la creación y destrucción de procesos, implica en los distintos sistemas.

Tanto en Linux y Unix a nivel kernel como en GNU a nivel sistema operativo, el costo de creación y destrucción tanto de hilos como de procesos puede ser casi imperceptible, mientras que en sistemas operativos privativos con núcleos diferentes, el costo es muy elevado y por ese motivo, en estos sistemas, se utilizan más los threads que los procesos. De allí que comúnmente se escuche decir que estos sistemas son más vulnerables que los que implementan Linux o Unix.

Uso de procesos que evitan errores de diseño explotables

Un buen uso de procesos y de preferencia de estos frente a los hilos, se da cuando una aplicación requiere efectuar tareas simultáneas con usuarios diferentes. Puede que no te hayas planteado emplear diferentes usuarios para diferentes tareas de tu aplicación y esta es una excelente oportunidad. Apache nos da un ejemplo concreto de ello.

Apache utiliza múltiples procesos con diferentes usuarios para la ejecución de sus tareas. El enlace a los puerto de bajo número -como el puerto 80, por ejemplo- lo realiza a través el usuario root mientras que el procesamiento de las solicitudes Web, lo efectúa con el usuario www-data quien tiene permisos muy inferiores a los de root.

Casos como el de Apache, son los que evitan que frente a un error producido en el código de las tareas ejecutadas por usuarios con permisos escuetos, ejecuten acciones solo permitidas al usuario root. La única forma de que esto suceda, sería escalando privilegios para lo cual, otro error sería necesario de forma simultánea pero en el código de las tareas asignadas al usuario root.

Trabajo distribuido y portabilidad

Otra de las grandes ventajas que los procesos facilitan frente a los hilos, es la de permitir una mayor portabilidad en las aplicaciones y posibilidad de compartir el trabajo de forma simple (característica por excelencia en las arquitecturas cliente-servidor).

Esto significa que si lo que se necesita es una aplicación que permita distribuir/compartir el trabajo a través de una red local o externa, la ejecución de tareas mediante diferentes procesos, será la única alternativa. Caso contrario, la aplicación podría responder de forma impredecible facilitando así la corrupción de los datos y su consecuente explotación.

Nota final sobre threads: hilos del kernel vs hilos de usuario

Es muy importante que como programador o programadora, entiendas que diferentes hilos comparten un mismo PID (process identifier o identificación de proceso) mientras que diferentes procesos, poseen sus propios PID. De allí que frecuentemente puedas escuchar frases como “los diferentes hilos de un proceso”.

Sin embargo, esto no es así a nivel del kernel. Los hilos del kernel tienen sus propios PID. Esto es debido a la forma en la que el Kernel es ejecutado.

El kernel en sí mismo no se ejecuta como un proceso sino que sus tareas corren como parte de otros procesos. Al ser una cantidad de tareas significativas, el kernel se ve obligado a implementar acciones alternativas que operen de forma similar a los procesos, a fin de abaratar costos. Estas acciones alternativas son los famosos demonios (daemon en inglés) los cuales se ejecutan constantemente en segundo plano, asegurando de esta forma, un menor uso de los recursos ya que en caso contrario, de no estar disponibles de forma constante al usuario, éste debería invocar a dichos servicios cada vez que necesitara hacer uso de ellos. Esto implicaría nuevos procesos creándose y destruyéndose de forma permanente.

Cuando hablamos de caro o barato refiriéndonos al uso de recursos del sistema, estamos diciendo que “a mayor uso de RAM y mayor tiempo de ejecución, más cara es la implementación”.

Si programas en Python, desde ahora en más, antes de decidir utilizar threads, piensa en lo que acabas de leer 😉

 

Modelos de seguridad permisivos, GNU/Bash Hacks, Python y más en The Original Hacker Nº5

La edición Nº5 de The Original Hacker acaba de salir a las cyber-calles de esta maravillosa red, con:

  • Un especial sobre Modelos de Seguridad Permisivos: permitir y no prohibir es lo más seguro
  • GNU/Bash Hacks: ideas para menús que no te encuentras a la vuelta de la esquina
  • Decorador para formularios Web en Python capaz de soportar hasta la carga de archivos al servidor
  • Dict Object, un nuevo concepto en objetos para PHP

Este mes, además, se suma a “TOH” un nuevo desafío mensual: el acertijo en el que todas y todos podrán participar a través de Twitter e Identi.ca utilizando el hashtag #AcertijoTOH5. Los ganadores serán publicados en la próxima edición.

Descarga gratuita desde www.originalhacker.org

Desde Cuba: http://humanos.uci.cu/2014/04/revista-the-original-hacker-5/

 

Prevenir ataques XSS e inyecciones de código y SQL con EuropioCode

Riesgos y problemas actuales, aún no resueltos

Actualmente, los ataques XSS, las inyecciones de código y las inyecciones SQL, se suelen prevenir, mayormente, de dos formas:

1) Filtrando las entradas del usuario a nivel de la aplicación: utilizando funciones propias del lenguaje y funciones definidas por el usuario, en los algoritmos de la aplicación.

2) Aplicando herramientas como ModSecurity en forma conjunta con las reglas de OWASP, a nivel servidor, para prevenir el envío de datos que puedan resultar sospechosos.

En el primer caso, los programadores se ven forzados a efectuar trabajos de diseño realmente extenuantes. Muchas veces, se efectúa un filtrado sencillo a nivel de la aplicación, mediante el uso de funciones como strip_tags() o htmlentities() en PHP, pero cuando comienzan a aparecer requerimientos fuera de lo común en la aplicación, todo se complica. Y así nos encontramos con necesidades puntuales como por ejemplo:

  • Necesidad de facilitar y permitir el ingreso de texto con preformato (tags HTML permitidos)
  • Necesidad de permitir al usuario, el ingreso literal de código fuente en diversos lenguajes;

Y aquí, el trabajo a nivel aplicación, comienza a complicarse. No todo diseño suele ser suficiente ni todo diseño deja confiados a sus programadores. Siempre se estará alerta.

En el segundo caso y sin siquiera mediar alguna de las necesidades puntuales mencionadas anteriormente, ModSecurity termina convirtiéndose en un problema tanto para los programadores como para los administradores de sistemas. La mayoría de las veces, el servidor comienza a arrojar errores 403 al usuario y los logs de Apache, se llenan de lo que a simple vista, parecen ser falsos positivos de ModSecurity haciendo referencia a supuestos intentos de ataques por diversos tipos de inyecciones.

Pero, como siempre digo a mis alumnos:

Los falsos positivos de ModSecurity por intentos de inyección de código o SQL, son en realidad, errores de diseño a nivel de la aplicación.

La realidad, es que la mayoría de los programadores, aún en épocas donde arquitecturas como MVC son el auge de la moda en la ingeniería de Software y sobra documentación al respecto, continúa confundiendo los requerimientos visuales de la aplicación con la lógica algorítmica de la misma.

Los falsos positivos de ModSecurity se producen por errores de diseño cuando los programadores confunden un requerimiento visual con la lógica de negocios de la aplicación.

Necesitar poder permitir al usuario el ingreso de código fuente, es una necesidad visual. Es el usuario quien DEBE CREER que está ingresando código fuente. Es, a los ojos del usuario, que se debe mostrar una cadena de texto que luzca de forma idéntica (o similar) a un código fuente. Sin embargo, una aplicación JAMÁS debe permitir que se le inyecte código fuente. Y lo mismo, aplica al texto con preformato.

Entonces aquí es donde radica el problema. Los programadores no encuentran una alternativa lateral a lo que conocen y todo concluye en la ERRÓNEA anulación de las reglas de ModSecurity.

Anular las reglas de ModSecurity, es el peor error que un SysAdmin puede cometer

La idea de este post, justamente, es brindar esa solución lateral que “le de el gusto” a todos, sin comprometer la seguridad del sistema.

Una solución que conforma a todo el mundo

La solución consiste entonces, en encontrar una manera de permitir al usuario ingresar código fuente en la aplicación, sin que lo que se envíe sea código fuente.

Y para ello, la única alternativa es:

Convertir las entradas del usuario en cadenas alfanuméricas.

Solo las cadenas de texto puro, son las que nos darán la seguridad y tranquilidad que necesitamos. Si lográsemos convertir luego, esa cadena de texto alfanumérico en algo que VISUALMENTE, se asemeje a lo que originalmente ingresó el usuario, estaríamos hallando una forma 100% segura de prevenir las inyecciones de todo tipo.

Y a tal fin, es que creé a  EuropioCode, un nuevo algoritmo de codificación alfanumérica, que puede ser aplicado a cualquier cadena de texto.

EuropioCode -actualmente en fase beta-, cuenta con dos librerías:

  1. Una librería JavaScript para codificar los campos de un formulario del lado del cliente (es decir, codificar el/los campo/s antes del envío del formulario al servidor);
  2. Una librería PHP que por un lado, refuerza la codificación del lado del servidor (en caso que la librería JS sea ignorada y ModSecurity no se encuentre operativo) y por otro, decodifica la cadena como entidades HTML hexadecimales, de forma tal que dicha entrada solo se interprete visualmente pero sea incapaz de ejecutarse.

En el repositorio oficial en Launchpad, se pueden obtener tanto las librerías JS y PHP como códigos con ejemplos de uso.

Actualmente, está en constante desarrollo por lo que recomiendo a los programadores, hacerse un branch del repositorio:
bzr branch lp:~eugeniabahit/europiocode/trunk
El repositorio está manejado con Bazaar, el sistema de control de versiones desarrollado por Canonical (fabricantes de Ubuntu), que forma parte oficial del proyecto GNU.

Si utilizas Git, otro sistema de control de versiones o simplemente, nunca has utilizado un sistema similar, aprender a usar Bazaar te llevará solo 5 minutos con este tutorial.

Para implementar EuropioCode, solo necesitas unas pocas líneas de código. Te recomiendo mirar (y probar) los ejemplos de uso incluidos en el repositorio.

Por favor, ten en cuenta que EuropioCode:

  • No es un encriptador de texto y por lo tanto, no cifra la información. Solo convierte caracteres NO alfanuméricos en código que sí es alfanumérico.
  • No es una librería pensada para proveer privacidad al usuario ni salvaguardar datos. Es un pseudo-código alfanumérico para reinterpretación de caracteres NO alfanuméricos.

Esta vez sí, Happy Hacking!

 

The Original Hacker Nº3, una edizione da non perdere

Ni los inimaginables cortes de luz argentinos ni las alertas rojas por olas de calor bonaerenses, impidieron que la edición Número 3 de mi niña mimada The Original Hacker, saliera como es debido, el primer martes de mes.

No les voy a mentir, es una edición que me dio dolores de cabeza, pues la terminé en el último minuto (estar sin luz no solo afecta la tarea de los ordenadores; te caga las tareas diarias de la casa y tu propia existencia!). Sin embargo, a pesar de todos los dolores de cabeza que me dio, les aseguro que el contenido me ha dejado más que contenta.

Y la Nona preguntó… “¿Ma perché bambina? ¿Che cosa porta la rivista di questo mese?” y yo, le respondí… “deja que te cuente, Nona”…

Ingeniería Inversa de Código para la detección de Vulnerabilidades

En primer lugar, el artículo que más feliz me ha dejado es el de Ingeniería Inversa y Seguridad Informática. Sí, esta vez, los dos temas están presentes en el mismo artículo. Este artículo, es una transcripción hiper-mega completa de la charla que di el 13 de diciembre en la A&D Security Conference que se llevó a cabo en Buenos Aires. Si la organización del evento hubiese puesto el mismo esfuerzo que puso en justificar la misoginia y discriminación de la empresa ESET Latinoamérica, en dejar un legado cultural libre que perdurara en el tiempo, hubiésemos tenido TODOS, el video de esta (y las demás) charlas.

Pero como eso no sucedió, me tomé el trabajo de repasar mentalmente cada uno de los momentos, palabras y líneas de código de mi charla, para que quienes no pudieron estar allí, tengan derecho a instruirse sobre el tema y, para que quiénes si pudieron presenciarla, tuviesen la oportunidad de repasar los temas en cualquier momento. Como adelanto para quien quiera leer el artículo, les cuento que se trata de los cómo, por qué y para qué de la lectura de código, enseñando cómo leer el código fuente de un programa y cómo detectar vulnerabilidades imposibles de ser detectadas mediante pentesting. De verdad, les recomiendo a todos leer este artículo. Lo van a entender, se los prometo! No importa si recién comienzan o ya son tremendos [email protected] Sinceramente, es un tema muy poco documentado y que no tiene desperdicio.

Bash Scripting Avanzado

El otro artículo que me tiene como niña con juguete nuevo, es el dedicado al Scripting. Se trata de una nueva serie de artículos sobre scripting avanzado con GNU Bash, donde iré publicando pequeños tips que brindan grandes soluciones.

Lambdas y closures en Python

No una, sino decenas de veces te habrás enfrentado, ya sea en código o en concepto, a los lambdas y closures en Python. Y no una sino decenas de veces te habrás preguntado qué carajo son realmente o si verdaderamente los estabas utilizando como correspondía hacerlo. Y si me dices que no, permíteme dudar de tu afirmación. Pues preguntarse en más de una oportunidad “qué carajo es eso de los lambdas o de los closures en Python” es algo que todos hemos vivido alguna vez. Lo se!! xD En fin… lee esta explicación y no te lo volverás a preguntar jamás en tu vida. Créeme! Como adelanto, te dejo unas líneas de código:

Es exactamente lo mismo que:

Y se que solo con eso, ya comienzas a entenderlo mejor 😉

¿Es posible desarrollar un sitio Web estándar (front-end básico) sobre Europio Engine?

La respuesta a una de las FAQ que más he recibido por e-mail, junto con los cómo, los encuentras en esta edición de The Original Hacker. Como adelanto: puedes hacer el backend sobre Europio Engine y para tu Web, consumir la API de Europio. Pocos y sencillos pasos. Todo explicado y ejemplificado con código.

Después de leer todos estos adelantos ¿de verdad piensas seguir postergando la descarga? Pero!!! ¡Descargala ahora, bambino/a!! www.originalhacker.org (y pulsa F5 si en vez de la edición 3 ves el link de descarga hacia la edición 2… no es que a un tal Víctor le haya pasado… no no, para nada).

Per la persona che si questione perché io ho usato il colore fuchsia per tutti l’articolo, e perché scrivo in italiano, a la prima questione io rispondo: perché me canta il mio culo e a la seconda, perché si tu parla inglese, io parlo italiano e punto, capisce?

 

Problemas al reproducir Ogg bajo Apache con ModSecurity desde Chrome y Chromium

HTML 5 y sus nuevos tags de <audio> y <video> terminaron desencadenando anoche, una batalla campal con mis neuronas.

A raíz de querer incorporar audio OGG en una de mis Webs, descubrí que si el audio estaba alojado en mi servidor, no se reproducía. En cambio, si modificaba la ruta del archivo de audio colocando una URI externa, el audio se reproducía sin problemas.

De allí en más, comencé a investigar si era necesario que el servidor tuviese algún requisito/configuración/cuidado/whatever para permitir la reproducción de audio. Hasta incluso, pedí ayuda por Twitter con la esperanza de que a alguien se le prendiese la lamparita y muchísimas personas colaboraron. Sin embargo, cuando hallé la respuesta final, me di cuenta que era mucho más compleja de lo que me esperaba.

El problema

  • Intentando acceder a la URL del archivo de audio, éste era loclizado y sin embargo no se podía acceder a él.
  • Con wget el archivo bajaba sin inconvenientes;
  • Con los navegadores Firefox, Chrome y Chromium (desde Ubuntu GNU/Linux) podía reproducir audio en el mismo formato sin inconvenientes, siempre y cuando estos archivos NO se encontrasen en mi servidor.

Contexto

Se trataba de un servidor Ubuntu 12.04, con Apache 2.2 y… ModSecurity instalado con el paquete de reglas de OWASP. Mi mayor sospecha estaba sobre estas últimas. Ya habíamos hablado la noche anterior con Dabo, sobre los falsos positivos de ModSecurity.

El camino hacia la solución

A través de Twitter, @mjimeneznet me explicaba que con solo los tags debería funcionar y que el server no necesitaba nada más. Lo mismo sobre los tags, mencionaba todo el mundo! Pero esto iba más allá de HTML 5. Había algo en el servidor, eso era seguro.

Y así fue que a @elrevo, @daviddfr, @hernanJ y @f_rojas se les ocurrió que podría ser necesario indicar los tipos MIME en Apache, ya sea a través de Virtual Host, en apache2.conf directamente o en .htaccess.

Tras agregar al VirtualHost un AddType con el formato ogg, probé y solo en Firefox, parecía haberse resuelto el problema. Sin embargo, en Chrome y Chromium aún seguía el fallo.

En eso apareció @MatiasKatz con quien desde Google Talk, estuvimos haciendo varias pruebas. Hasta que se me ocurrió mirar los logs de error de Apache. Hice un tail -f a los logs, y allí estaban “esperándome” esos “malditos”:

Este error se replicaba decenas de veces. Resaltado en negritas vemos:

  1. ModSecurity negaba el acceso con un error 403;
  2. La causa era el archivo de reglas crs_20 sobre violaciones de protocolo;
  3. La regla específica era la indicada en la línea 248 (vale aclarar que muchas veces, se edita la regla en cuestión y es otra la que prohíbe el acceso así que esto era para ser tomado con pinzas)
  4. La severidad del supuesto ataque evitado, era a penas un aviso (notice)
  5. Finalmente, la URI, era la de mi famoso archivo de audio Fenster.ogg

La parte más desagradable era que ninguna de las URL logueadas, era accesible, así que en principio, no tenía explicación ni justificación para esa regla.

Lo primero que hice para verificar si era o no ModSecurity quien me estaba jodiendo, fue mover el archivo a un directorio de pruebas a fin de eliminarlo de su origen pero mantenerlo en copia de resguardo. Reinicié Apache y el problema desapareció. Finalmente, solo comenté la regla en cuestión y volví a reiniciar Apache.

La solución

En el archivo de reglas modsecurity_crs_20_protocol_violations.conf comentar la regla de línea 248:

Reiniciar Apache y ¡problema resuelto!

La explicación a todo

Erradicar un error pero no encontrarle la explicación lógica es como estar co….

(por si no se entendió mi metáfora: lo anterior fue un ejemplo de algo que te deja con una sensación de discontinuidad y por consiguiente, de algo inconcluso xD)

Así que para no quedarme con esa asquerosa sensación, a pesar de haber resuelto el problema, seguí analizando lo sucedido hasta hallar respuestas y el tema es así:

  • En el archivo de reglas de OWASP, las líneas previas a la regla que se comentó, explicaban de manera abreviada, que la misma era en cumplimiento con lo establecido en las definiciones RFC 2616 (correspondiente a la definición de estándares del protocolo HTTP 1.1);
  • Los estándares HTTP están publicados nada más ni nada menos que por la W3C;
  • En dicha RFC, la sección 14.35.1 se refiere a los rangos de bytes que el cliente (navegador en este caso) envía en los campos de cabecera al servidor (a.k.a “headers” para los amigos). Es decir que la sección 14.35.1 de las RFC 2616 son las que definen los estándares para los rangos de bytes enviados por el cliente al servidor a través de las cabeceras HTTP;
  • Estas especificaciones, dicen claramente que: “si un rango de bytes sintácticamente válido, cuyo primer byte del rango sea menor a la longitud total del elemento a ser servido, o por lo menos, el sufijo del intervalo es distinto que cero, entonces la solicitud puede ser satisfecha por el servidor, pero de lo contrario, el servidor debe rechazar la petición;

Si volvemos a darle un vistazo al error que ModSecurity grabó en los logs, veremos esto:

El valor recibido indicaba un rango inválido en el cual, faltaba el sufijo del rango:

bytes=0-???

Recordemos que ese error, se producía al intentar acceder desde Google Chrome o desde su fork libre Chromium, al archivo de audio ogg. Es decir, que tanto Google Chrome como Chromium, envían como valor de rango de bytes en los encabezados HTTP, un rango inválido (sin sufijo). Dicha solicitud VIOLA LOS ESTÁNDARES DE LAS RFC 2616.

Vale aclarar que:

  1. A raíz de esto, revisando los logs, me di cuenta que el reclamo realizado por muchos usuarios que eran rechazados al intentar descargar un PDF desde dispositivos con Android, también era a causa de este problema. Vale decir que Android tampoco cumple con dichos estándares.
  2. A pesar de haberme enojado con MpdSecurity, no se puede responsabilizar del bloqueo a las reglas de OWASP ni mucho menos a ModSecurity, puesto que es el Software de Google quien al incumplir con dichos estándares provoca que sus aplicaciones actúen de forma similar a como lo haría una herramienta pensada para el ataque.

Lamentablemente, por la irresponsabilidad de Google, la única solución (que en realidad sería utilizar Mozilla Firefox), fue comentar la regla mencionada.

Happy Hacking, Fuckin’ Google!

Dedicado con todo googlelove a mi compañero Debish 😛

 

2ª entrega del Magazine «The Original Hacker»

9902 descargas desde IPs únicas marcaba mi script contabilizador de logs de Apache, el viernes 29 de noviembre a las 17:30 hs, momento en el que redactaba el e-mail de la «Avant Première» para la 2ª edición de The Original Hacker. Casi diez mil descargas únicas tuvo la primera edición cuando los principales responsables de los sitios Webs de difusión, recibían en exclusiva, el adelanto de lo que sería esta segunda entrega que ya se encuentra disponible al público general.

TOH-webfinal

… 

 

Ya salió The Original Hacker Nº1 ¡No te la pierdas!

El día de ayer, martes 5 de noviembre de 2013, publiqué el primer número de mi nueva revista The Original Hacker, inaugurando esta edición mensual que prometo tener en pie cada primer martes de mes. En poco más de 24 horas, la revista ha superado las 4000 descargas y por si aún no estás entre esos downloads, aquí te cuento mejor de qué se trata =)

… 

 

Presentando The Original Hacker, un juego con la inteligencia

El pasado domingo 20 de octubre, me di cuenta que dejar de invertir tiempo y esfuerzo en reparar los errores de terceras personas y dejar de sentirme obligada a cumplir con las responsabilidades de otros, me iba a permitir poder poner mayor dedicación en generar material que verdaderamente sirviese a programadores en vías de convertirse en Hackers y a los Hackers más avezados.

Así fue, que con la premisa de conservar la esencia de lo que venía haciendo, me propuse crear The Original Hacker, un nuevo magazine cuyo espíritu se basa en la libertad y el verdadero Hacking.

… 

 

Ubuntu, Apache, VirtualHost, 403 Forbiden y la putaqueloparió

Hace unos meses ya, desde que a un alumno se le ocurrió instalar Ubuntu 13.04, que vengo padeciendo del Síndrome del “pero qué mierda le pasa a esto, carajo!”.

Los pongo en contexto:

Ubuntu 13.04. Se crea un nuevo Virtual Host y al intentar acceder, Apache retorna el error 403 Forbiden.

Si uno ve un error 403 Forbiden, lo primero que piensa es lo obvio: problema de permisos. Pero los permisos pueden tener a la vez, “cientocincuentamillonesdeorígenes“.

En resumidas cuentas, para solventar el problema en su momento, se probaron no una, tampoco 2 ni 10 formas diferentes sino decenas de soluciones posibles y ninguna de ellas lo solucionaba.

Y ¿qué cambió ahora? El martes pasado, estábamos en clase de PHP con mi alumno Marcelo Lobato, quien harto de no poder solucionar el error en Ubuntu 13.04 decidió pasar al más querido estable 12.04 LTS. Estábamos creando nuevamente un Virtual Host, cuando para mi sorpresa, Apache volvió a arrojar un 403 Forbiden y mi grito de “Oh, pero qué mierda le pasa a esto, carajo!” se hizo evidente.

Puteada va, prueba viene, a Marcelo se le ocurrió la brillante idea de decir: – “¿No tendrá algo que ver que al momento de instalar Ubuntu yo haya elegido cifrar mi carpeta personal?”

¡Me cago en la puta! ¿Cómo pude no tener en cuenta que las carpetas personales podrían estar cifradas?!?! Si la carpeta está cifrada, el usuario de Apache, es decir, www-data, no tendría acceso a ella. Y, hablando con uno y otro, ¿podría ser que Ubuntu 13.04 más allá de la elección del usuario estuviese cifrando la carpeta personal por defecto? Sí, podría ser, pero aún falta laboratorio para dar una respuesta certera.

Por lo pronto, aquí les dejo la solución al problema.

Lo primero que hay que hacer, es cerciorarse de que el problema, realmente se debe al impedimento del usuario de Apache, de acceder a la carpeta raíz del dominio. Para comprobar esto, la forma fácil y rápida es editar el archivo de configuración de Apache, indicando como usuario y grupo al usuario y grupo propietarios de la carpeta en cuestión.

Supongamos que el DocumentRoot de tu Virtual Host es /home/pepe/miweb y que el propietario del directorio miweb es pepe:pepe. Como súper usuario, editas el archivo /etc/apache2/apache2.conf y buscas las siguientes líneas:

Y las reemplazas por el usuario y grupo propietarios de la carpeta en cuestión, respectivamente:

Reinicias Apache:

sudo service apache2 restart

Y pruebas nuevamente ingresar en tu host virtual. Si logras acceder SIN un 403 Forbiden, el problema, efectivamente, se debe al impedimento del usuario de Apache, de acceder a la carpeta raíz del dominio.

¿Cuál sería la solución entonces? Obviamente, volver las variables User y Group del apache2.conf a su estado original y luego, crear una carpeta FUERA de la carpeta cifrada, pero con el mismo propietario para no estar trabajando allí dentro ni como root ni cosas locas. Una buena alternativa es esta:

Y no olvidar de asignar como ruta del DocumentRoot del VirtualHost, el nuevo path /srv/miweb.

Ahora sí, Happy Hacking!

 

Humor geek: ¿me quiere? ¿no me quiere?

Me pregunto que niña no habrá torturado alguna vez en su infancia, a una pobre margarita deshojándola para saber si un fulano la correspondía o no…