Etiquetaweb

Los cuatro errores más comunes al momento de subir archivos a producción

Es más común de lo que piensan que los usuarios suban archivos “basura” a servidores en producción/explotación. Muchas veces son distintos usuarios los que tienen acceso al directorio público de un sitio web, ya sea todos accediendo desde el mismo usuario o cada uno con su usuario.
El problema es cuando no tenemos control sobre las cosas que se suben a producción, por ejemplo como administrador de sistemas a muchos nos ha tocado que debemos crear cuentas de usuario ftp con acceso a subdirectorios de un sitio web, uno intenta aplicar todas las medidas de seguridad posible y hacer cumplir todos los procedimientos necesarios, como por ejemplo que un “usuario normal” no puede subir archivos a produccion vía FTP sin que sean correctamente validados ni filtrados, sin embargo, a ellos no le sirve. Otro ejemplo es cuando los desarrolladores tienen que subir desarrollos nuevos o actualizaciones, ya sea mediante un control de versiones o suciamente directamente desde ftp o ssh, nunca se controla qué tipo de archivos están subiendo, exponiendo nuestros servicios y servidores.

Seguir leyendo

Está preparado el gobierno chileno para recibir un ataque de robo de información ?

Ultimamente se han puesto de moda los ataques de “Anonymous”, ataques como tirar un sitio abajo o saturación de servidores, algo bastante simple que no requiere mucho conocimiento y es por esto que mucha gente se ha sumado. Algunos medios los han llamado ‘hackers‘ otros ‘simples aficionados que se descargan un programa, introducen una URL, se coordinan y presionan enter‘. Por suerte del gobierno no se comparan con los ataques originales de Anonymous o LulzSec. Cuando digo “originales” me refiero a esos ataques que han salido a la luz donde divulgan información sobre las cuentas de usuario e información sensible y privada de las empresas, no a unos wannabe.

Según mi opinión, un ataque de denegación de servicio a sitios del gobierno no tiene ningun sentido y no hacen daño ni provocan preocupación, creo que los ataques deberian realizarse hacia “servicios” y no a “sitios”, donde se vean afectados los servicios que los ciudadanos usan y que el gobierno se sienta incapaz de brindarselos. Esto sucede porque no se hace un estudio sobre la víctima, para darle donde más le duele, se puede llamar “ataque organizado” porque se acuerdan una hora y todos presionan el botón ese dia a esa hora, pero no hay una real coordinación donde se investigue un objetivo donde realmente llame la atención, y mientras siga siendo así, seguiran siendo ataques simbólicos.

El gobierno chileno tiene muchas brechas de seguridad informática y de la información, es por esto que me hago la pregunta, ¿Está preparado el gobierno de Chile para recibir un ataque de robo de información?, la respuesta clara es: NO. No está preparado el gobierno, ni las personas, ni los encargados, no existen políticas (y si existen no se cumplen), encargan su seguridad a un simple firewall que solo les sirve para que sus empleados no puedan ingresar a ver youtube. Obviamente no puedo decir que “todas las entidades del gobierno tienen fallos de seguridad”, pero me refiero al gobierno en general.

Desde hace un tiempo que he estado investigando las distintas vulnerabilidades web en sitios del gobierno, intentando reportar la mayoría. En algunos casos no responden, en otros casos no hay forma de contactarlos pero en el mejor de los casos, recibo respuestas y unas satisfactorias gracias.

Seguir leyendo

Testing de calidad a las empresas de hosting y desarrollo web en Chile

Binary Code AbstractHace un tiempo comencé con la idea de exponer públicamente una lista, semanal, de sitios vulnerables.
Ahora, mi propósito será realizar un análisis de seguridad a las empresas de desarrollo web y hosting en Chile, exponiendo todas sus debilidades y fortalezas para generar un poco de conciencia respecto a la seguridad tanto como en las empresas como en los clientes o usuarios, quienes hacen uso de estos servicios.

Analizaré tanto los servidores de las empresas como sus sitios web, al igual que los sitios web de sus clientes.

GoldenData: Una empresa en la que NO se puede confiar

Bien. Hace tiempo vengo hablando sobre las vulnerabilidades web, escribí un artículo sobre los fallos que tenia tiene la web Caffarena y la verdad es que me he encontrado con varias sorpresas en otros sitios web.

Me gustaria hacer una observación a todas las empresas que se dedican al desarrollo de aplicaciones web: Existen frameworks muy buenos, libres y gratuitos y aveces conviene mucho más entender ese framework y no hacer uno propio.

El error que cometen muchas empresas como ésta es que, al usar un mismo framework (desarrollado por ellos mismos), para todos sus clientes, cuando se encuentra una vunlerabilidad en almenos 1 sitio, este mismo fallo se aplica automaticamente a todos sus clientes y de esta forma ponen en riesgo ademas de sus clientes, a los clientes de otras empresas (cuando comparten un mismo servidor de hosting).

Les voy a hablar sobre la empresa GoldenData Ltda., quienes se dedican al desarrollo web. Antes de publicar y decir cualquier cosa, quiero aclarar que yo me comuniqué con estas personas para darles a conocer sus fallos de seguridad en todos y cada uno de sus sitios web obteniendo un cierto interes por parte de ellos para solucionar el problema. En un principio les comenté sobre la falla en su sitio web lo que me respondieron:

Actualmente estamos rediseñando todo el sitio web, así que el sitio actual será desechado en el corto plazo.

Días despues, les envié otro correo electrónico para comentarles que esa falla que tenian en su sitio web se replicaba a todos y cada uno de los sitios de sus clientes, obteniendo la siguiente respuesta:

De verdad me interesa el tema, pero actualmente estoy realmente
colapsado, ya que se juntaron muchos proyectos y temas internos. Voy a
aumentarle la prioridad a ese tema. Estamos en contacto. Saludos!

Ya ha pasado casi un mes desde el primero correo electrónico que les envié y no han solucionado el problema, por lo que no me sentiré mal al publicar sus falencias.

Seguir leyendo

Vulnerabilidades más comunes en los sitios web

Estamos en el año 2009 y es increible que existiendo tantas herramientas de auditoría y el peligro/riesgo que existe por el mal tratamiento de la información, los desarrolladores esten cayendo en errores tan básicos.

Voy a listar las vulnerabilidades que, según mi experiencia, son las más comunes en los sitios web.

  • File/Path Disclosure: Esta vulnerabilidad es más comun de lo que uno pueda imaginar, aunque generalmente para poder llegar a explotarla es necesario pasar algun sistema de autentificacion ya que es muy comun en sistemas donde los usuarios tienen acceso a descargar o subir información como un sitio de una Universidad, biblioteca, intranet, etc.
  • XSS (Cross-Site Scripting): Esta vulnerabilidad tambien es muy comun, aunque es un poco mas compleja de explotar, requiere conocimiento en javascript, manejos de cookies y un poco de experiencia en el tema. Con esta vulnerabilidad es posible robar cookies para ingresar a algun sistema autentificado con un usuario ajeno.
  • SQL Injection: Hace un tiempo fue el boom de esta vulnerabilidad, muchos sitios tenian fallos de este tipo. Estuvo de moda explotar vulnerabilidades de phpnuke o phpbb basadas en SQL Injection que nos permitian escalacion de privilegios. Esta tecnica consiste basicamente en manipular una consulta sql para lograr nuestro proposito como saber nombre de tablas, version de la base de datos y tambien manipular ingresos de datos a la base de datos para modificar campos de tablas, crear archivos, cambiar privilegios, etc.
  • Authentication bypass:  Desde mi punto de vista, esta vulnerabilidad, bug o fallo es uno de los mas estupidos que un programador/desarrollador puede cometer. Para hacer un login es necesario manejarse con el tema de cookies o sesiones, segun el lenguaje o las necesidades y cuando una persona sin estos conocimientos intenta hacer un codigo de autentificacion sucede lo peor. El caso mas comun y sencillo de este tipo de fallo es saltarse el login haciendo un cambio en la URL. Por ejemplo, tenemos https://example.com/login.php y nos damos cuenta que ese login.php hace un POST con nuestros datos a https://example.com/admin/valida.php, luego, sin ingresar ningun usuario ni password escribimos manualmente la url https://example.com/admin y sorpresa! estamos en el sitio de admin sin usuario pass ni nada, habiendonos saltado el login. Aunque no lo crean, es bastante comun.