Información Importante Sobre el Contenido
Estas accediendo al contenido antiguo del blog. Este artículo "Chile: Vulnerabilidad en software gubernamental expone a decenas de instituciones publicas" es de dominio público y no será mantenido a futuro. Cualquier error o problema acerca del contenido por favor contactate conmigo desde la sección contacto.
Con el fin de cumplir con la Ley de Transparencia, las instituciones publicas deben disponer de un sistema que permita a los ciudadanos a solicitar información publica. Algunas instituciones optaron por el desarrollo propio de un sistema que permita gestionar estas solicitudes y otros prefirieron utilizar un software gratuito publicado bajo la licencia de software público y patrocinado por el Ministerio Secretaria General de la Presidencia (minsegpres).
El software desarrollado por el minsegpres tiene una serie de vulnerabilidades de alto impacto que pone en riesgo a las instituciones que lo implementen, sin que tengan conocimiento de ello.
Dentro de las instituciones que lo implementan encontramos a Servicio Nacional de la Mujer, Prevision Social, Dipres, Subtel, Ministerio del Trabajo, FONASA, Ministerio de Salud, Ministerio de Transportes, Ministerio de Justicia e incluso el mismo Min Segpres, de una laaaaarga lista de instituciones.
Las vulnerabilidades tienen un impacto alto ya que se permiten a un atacante tomar control del servidor subiendo shells remotas gracias a un upload bypass, acceder a información confidencial como usuarios y pass de la base de datos, detalles de las solicitudes realizadas y en algunos accesos accesos a otras bases de datos que existan en el mismo servidor. En muchos casos al ser un sistema “chico” no dedican un servidor exclusivo para el Sistema de Gestión de Solicitudes (SGS) por lo que estas vulnerabilidades no solo ponen en riesgo a las otras aplicaciones y al servidor completo, sino que a la red de la institución.
Las fallas de seguridad son basicas y demuestran un bajo nivel de seguridad del software público. El sistema no usa framework, existen muchas llamadas a archivos y a consultas SQL obteniendo los valores directamente por POST o por GET, sin parametrizarlos ni escaparlos, claves en duro escrita en el código fuente, mal manejo de sesiones y privilegios, etc. Lo que demuestra que no cumplen con el minimo de seguridad que entrega el TOP 10 OWASP:
Hace un par de semanas concluí mi investigación y analisis a este sistema, a nivel funcional y a nivel de código fuente, los resultados no serán publicados aún.
Hace un par de semanas levante la alerta al CSIRT del Gobierno de Chile con el fin de informar y compartir la investigación antes de hacerla publica, en una reunion con los encargados de este sistema se mostraron sorprendidos con los hallazgos y me pidieron si podía detallarles aun mas las vulnerabilidades detectadas para que ellos trabajaran en solucionarlas. Mi impresión al respecto fue bien clara: Casi el 80% del sistema es vulnerable, no se utiliza framework, no se utiliza ORM, existen problemas de validacion, el sistema tiene archivos de “prueba” que pueden ser utilizados para acceder a información confidencial por lo que solucionarlo puede significar que se tenga que volver a hacer; pero esta bien pensando en la seguridad.
Yo cumplí con compartir mi informe y ademas darles las directrices de que deben hacer para corregir los problemas, basicamente lo que les dije fue algo bien generico
Despues me enteré que la Unidad de Modernización y Gobieron Digital tambien tenía algo que ver con este sistema, asi que me contacté y les compartí el informe. La respuesta fue rapida y eficiente, ya que se comprometieron a informar a los encargados. Demostraron interes en el asunto. Pero luego me llevé una sorpresa: conversando con un amigo me comentó que en Junio del 2014 había enviado un reporte de vulnerabilidades del mismo sistema SGS. Muchas de esas vulnerabilidades coincidian con las que yo envie… La respuesta que le dieron a el fue: Muchas gracias por el reporte, estoy informando al equipo responsable para que realicen las labores correctivas. La misma respuesta que me dieron a mi…
Como conclusión el sistema es vulnerable desde hacer varios meses (por no decir años) y las instituciones están en riesgo desde el momento que decidieron implementar este sistema. Aun cuando mi propuesta fue informar a las instituciones que esten utilizando este sistema el riesgo que estan corriendo, se prefirio trabajar en silencio y corregir las vulnerabilidades sin informar. Incluso les mencioné “algunas instituciones de gobierno han sido hackeadas o defaceadas ultimamente, perfectamente puede ser gracias al SGS” pero aun asi no hubo sensibilización.
Este es un llamado a las instituciones publicas que esten usando este sistema a que tomen medidas de precaución correspondientes, implementen medidas de seguridad complementarias o simplemente den de baja el sistema hasta una próxima actualización.
ACTUALIZADO 26/Ene/2015, 16hrs
Recientemente aparecio en twitter un hackeo a la pagina web de la Subsecretaria de Transportes (Subtrans). Este ataque fue publicado por “chilean hackers” mediante su twitter @ChileanHackers
El sitio o sistema hackeado corresponde al Sistema de Gestion de Solicitudes (SGS) version 1.
Información Importante Sobre el Contenido
Estas accediendo al contenido antiguo del blog. Este artículo "Chile: Vulnerabilidad en software gubernamental expone a decenas de instituciones publicas" es de dominio público y no será mantenido a futuro. Cualquier error o problema acerca del contenido por favor contactate conmigo desde la sección contacto.
enero 26, 2015 a las 11:33 am
Cual lenguaje de programación usan?
enero 26, 2015 a las 11:34 am
PHP
enero 26, 2015 a las 12:41 pm
No les importa la seguridad de los datos a ningún nivel. Como dices este sistema SGS es tan vulnerable que cualquiera podría hacerse con las bases de datos, donde están nuestros datos (como chilenos) y los datos de los usuarios internos, passwords y otras cosas.
Para rematar, este sistema se usa en la mayoría de los sitios del gobierno, dejándolos igual de vulnerables.
Mal por el Gobierno por no auditar el nivel de seguridad de sus aplicaciones (que es nulo) y peor aun, por dar respuestas tan mediocres sin tomar ninguna acción al respecto.
enero 26, 2015 a las 3:57 pm
Más de lo mismo, y que te apuesto que después de esto te llamaron y pidieron ayuda?? un clásico en fin muchas cosas por trabajar el tema es como priorizar. ahora pasando al tema rudo cuanto se demoraran en cuantificar el back door que proboca esto?
Saludos!
enero 26, 2015 a las 4:02 pm
Buen artículo. Ya había esuchado un comentario similar de algunos amigos informáticos. Quizás un paralelo real sobre lo alarmante de esta situación que describes, es ejemplo de las tarjetas BIP del Metro de Santiago. Por no investigar un poco se optó por adoptar un sistema muy fácil de vulnerar. Los costos de solución son gigantes. Ojalá las autoridades tomen en cuenta tu aporte. Saludos.
enero 28, 2015 a las 10:55 am
Muy bueno pero tengo un “pero”, no veo que un framework o un orm pueda siempre ser un aporte en temas de seguridad, sino mas bien el contrario por una experiencia que tuve cuando trabaje para una empresa gringa.
Habia una persona en un equipo de trabajo que conocia unas fallas se seguridad en un importante framework y en un ORM usado en PHP, las cuales hizo publicas casi un año despues. Me pregunto cuantos casos habra asi? el framework tiene un enorme equipo de colaboradores alrededor del mundo pero nadie se dio cuenta del problema de segurirdad, asi que el argumento de “codigo abierto conocido por todos implica que esta mas verificado” no es tan cierto, pues muchos se limitan solo a usar el codigo, otros pocos lo modifican, pero al final muy pocas personas en el mundo entienden/verifican realmente en totalidad el codigo fuente, pues entender el codigo escrito por otra persona no es facil y ademas es tedioso y aburrido, de hecho las persona que le mencione antes tenian muy poca vida social, no podias mantener una conversacion con el en un tema que no fuera de computacion. Por otro lado, diganme por ejemplo, cuantos de los que usan wordpress o desarollan plugings han revisado en un 100% el codigo fuente de wordpress?
Los framewok y los orm principalmente agilizan el desarrollo,pero terminan siendo cajas negras…
enero 29, 2015 a las 8:47 am
Claudio:
Si nos ponemos en el contexto de este desarrollo en particular, 3 años de desarrollo, mucha gente metiendo mano, sin una estructura base para desarrollar. Analizando el codigo encuentras distintas “tecnicas” de desarrollo y te das cuenta que mas de una persona metio mano en el codigo. Esto dificulta el mantenimiento del software a lo largo del tiempo y termina transformandose en estos problemas de seguridad que cuando se intentan resolver no tienen claridad de donde se producen ni el porque y mucho menos como solucionarlo.
El uso de framework en estos casos sirve porque te da un minimo estandar y orden, si el proximo mes otra persona toma el codigo en teoria seria mas facil modificarlo si es que maneja el framework.
Esto no quita que usando un framework programen como el * …
Cuando analizas codigo te das cuenta de estas cosas donde han pasado varias manos son mucho mas vulnerables y estan fuera de control si no usan framework.
Son conclusiones a las que llegamos cuando analizamos varios codigos…
Respecto al ORM es mucho mas facil centralizar un “escape” de caracteres al momento de consultar la BD de forma unificada que en cada consulta. Por ej es mucho mas facil hacer llamadas a $obj->query(“table_name”); y que “query()” se encargue de manera centralizada a realizar los parseos en lugar de hacer un trim, mysql scape en cada mysql_query.
Imagina un sistema que tiene 400 llamadas a la funcion mysql_query basta con que a una de ellas al programador se le olvide poner un parseo y ya deja abierto una agujero.
Se entiende?
septiembre 24, 2015 a las 9:38 am
frankencódigo