15 de abril de 2012

Evolución de Android en Seguridad


El objetivo de este post es realizar un listado sobre como ha ido evolucionando en seguridad Android; permitiendo a un usuario conocer las vulnerabilidades y características de su sistema Android en cuanto a seguridad se refiere.

Este listado solo se listarán fallos y mejoras a nivel de sistema y que afectan a el mismo, es decir:

Quedan descartados los fallos en las aplicaciones de terceros o externas al sistema, como pueden ser Skype (CVE-2011-1717), el SDK de Android (CVE-2011-1001, CVE-2008-0985, ...), Flash (CVE-2011-2460, CVE-2011-2459, …), entre otras.

Otro ejemplo que excluiré son los fallos CVE-2008-7298 y/o CVE-2011-2344 que afecta a la seguridad de las cookies en una conexión, y no están incluida ya que no tienen un impacto directo contra el sistema.

Tampoco tendremos en cuenta fallos que afecten a fabricantes en exclusiva, como por ejemplo, la vulnerabilidad CVE-2011-3975 que afecta a algunos modelos de HTC. O las versiones de la 2.3.5 a la 2.3.7 que solo de están disponibles para algunos dispositivos.

He intentado mostrar las fuentes originales y no perder ninguna vulnerabilidad o fallo importante. Si conocéis alguno que me olvide encantado de añadirlos, solo tenéis que comentar. xD

Voy ha distinguir tres apartados:
Soluciona: Indica que ha sido publicada de forma clara, que este fallo ha sido solucionado en esa versión.
Nuevo: Nueva mejora implementada.
Vulnerable: Indica que esa versión en vulnerable, pero no se especifica cuando ha sido solucionada.

Febrero 2009 v1.1

  • Soluciona:
    CVE-2009-0475 (Ejecución de código a través de Mp3)
    CVE-2009-0606 (Elevación de privilegios)
    CVE-2009-0607 (Múltiples desbordamientos de enteros)
    CVE-2009-0608 (Desbordamiento de entero)

Abril 2009 v1.5 r1

Mayo 2009 v1.5 r2

Julio 2009 v1.5 r3

Septiembre 2009 v1.6 r1

Octubre 2009 v2.0

  • Nuevo:
    Kernel 2.6.29
  • Vulnerable:
    CVE-2009-1442 (Posible ejecución de código a través de “Skia”)
    CVE-2010-EASY (Elevación de privilegios, exploit RageAgainsttheCage)

Diciembre 2009 v1.6 r2

Diciembre 2009 v2.0.1

Mayo 2010 v2.2 r1

Julio 2010 v2.2 r2

Diciembre 2010 v2.3

Julio 2011 v2.2 r3

Febrero 2011 v2.3.3, v3.0

Mayo 2011 v2.3.4, v3.1 r1 y r2

Julio 2011 v3.0 r2

  • Nuevo:
    Kernel 2.6.36
    DRM
    Cifrado de disco
    Mejora de Políticas de seguridad

Julio 2011 v3.1 r3, 2011 v3.2

Octubre 2011 v4.0


[UPDATE]



OTRAS NOTAS:
Busqueda sistemática de fallos de fuga de información
http://www.csc.ncsu.edu/faculty/jiang/pubs/NDSS12_WOODPECKER.pdf
http://www.youtube.com/watch?v=xGwTviVRcrg
http://www.xda-developers.com/android/discover-undisclosed-apis-with-androids-secret/
Escucha este post Publicado por ehooo 0 comentarios
Etiquetas: ,

13 de febrero de 2012

La Comisión Europea propone cambiar las leyes de Protección de datos

Tras un estudio realizado por la Comisión europea sobre la preocupación de sus ciudadanos en temas de protección de datos y observar que:
 - 2/3 de los europeos nos preocupa que las empresas compartan nuestros datos personales sin autorización.
 - 9/10 queremos tener los mismos derechos de protección en toda Europa.

La comisión ha propuesto un cambio de legislación que unifique los la protección de los internautas europeos.

Entre las novedades destancan:
- Se establece un "Derecho al olvido", de tal modo que las empresas estén obligadas a eliminar los datos personales a petición del usuario, salvo razones legítimas (como el cumplimiento de alguna norma).
- La protección de datos también debe aplicarse en los países que no pertenezcan a esta y traten con datos de europeos.
- Las empresas estarán obligadas a comunicar los incidentes de fugas de información que puedan afectar a los datos personales de sus usuarios.

Por el momento es una propuesta de reforma, y queda un largo camino burocrático para que pueda ser aplicable.


Referencia:
http://ec.europa.eu/news/business/120125_es.htm
Escucha este post Publicado por ehooo 0 comentarios

15 de enero de 2012

Filtrado por lista negra en WebPy


WebPy es un framework para aplicaciones web escrito en python. Se trata de un framework de código libre y está "licenciado" como dominio público.

En este caso queremos mejorar la seguridad de nuestra aplicación web creando una clase que implemente mecanismos de filtrado por lista negra. Existen múltiples listas negras en internet sobre IPs potencialmente dañinas.

En mi caso he decido para implementar esta funcionalidad con la lista negra suministrada por el proyecto honeypot.

En primer lugar vamos a crear una clase que nos permita hacer consultas sobre esta base de conocimiento.

class HttpBL():
 def __init__(self, key):
  self.key = key
  self._DOMAIN = "dnsbl.httpbl.org"

 def get_info(self, ip, timeout=None):
  partes = ip.split(".")
  #Don't ask private networks
  if partes[0] == "10" or partes[0] == "127":
   return (-1,-1,-1)
  elif partes[0] == "192" and partes[1] == "168":
   return (-1,-1,-1)
  elif partes[0] == "172" and int(partes[1]) >= 16 and int(partes[1]) <= 31:
   return (-1,-1,-1)

  domain_ask = ""
  for parte in partes:
   domain_ask = parte+"."+domain_ask

  domain_ask = self.key+"."+domain_ask+self._DOMAIN
  try:
   if timeout:
    socket.timeout = timeout
   result = socket.gethostbyname(domain_ask)
   result = result.split(".")
   return (int(result[1]), int(result[2]), int(result[3]))
  except socket.gaierror as (error, string):
   if error == 11001 or error == -5:
    return (-1,-1,-1)
   else:
    raise socket.gaierror(error, string)
Como podeis observar, las IPs privadas no se consultan.
Podeis obtener más información sobre el tipo de información que nos provee esta lista desde: http://www.projecthoneypot.org/httpbl_api.php

Por otro lado he implementado una clase que, además de comprobar que quien acceda al servicio no sea potencialmente peligroso, define: unas reglas de acceso directamente en la declaración, la creación de una respuesta OPTIONS con los datos anteriores y una comprovación del dominio desde el que se está acediendo a la aplicación.
class SecureWeb():
 def __init__(self, blkey="", host_name=None, allow_methods=["HEAD","GET","POST","OPTIONS"]):
  self.allow_methods = allow_methods
  self.host_name = host_name
  self.blacklist = HttpBL(blkey)
 def not_allowed(self):
  raise web.Forbidden()
 def wrong_hostname(self):
  self.not_allowed()
 def bad_method(self):
  self.not_allowed()
 def to_honeypot(self, data):
  self.not_allowed()
 def to_search_engine(self):
  pass
 def check_allow(self):
  (last_activity, threat_score, type) = self.backlist.get_info(web.ctx.env["REMOTE_ADDR"])
  if type == 0:
   self.to_search_engine()
  elif type > 0:
   self.to_honeypot((last_activity, threat_score, type)) 
  if self.host_name:
   hostname_ok = False
   for hostname in self.host_name:
    if hostname.lower() == web.ctx.env["SERVER_NAME"].lower():
     hostname_ok = True
     break
   if not hostname_ok:
    self.wrong_hostname()
  if not web.ctx.env["REQUEST_METHOD"].upper() in self.allow_methods:
   self.bad_method()

 def HEAD(self, *extras):
  self.check_allow()
 def GET(self, *extras):
  self.check_allow()
 def POST(self, *extras):
  self.check_allow()
 def PUT(self, *extras):
  self.check_allow()
 def DELETE(self, *extras):
  self.check_allow()
 def TRACE(self, *extras):
  self.check_allow()
 def CONNECT(self, *extras):
  self.check_allow()
 def OPTIONS(self, *extras):
  self.check_allow()
  allow = ""
  for method in self.allow_methods:
   allow += method+","
  allow = allow[:1]
  web.header('Allow', allow)

Como se puede observar en cada tipo de petición HTTP se realiza un chequeo de acceso, y en caso de no validarlo se envia la información a la función correspondiente para poder procesarla de forma adecuada. En el ejemplo todas las funciones acaban llamando a 'not_allowed' que muestra un Forbidden. Pero cada uno de vosotros podeis modificar las funciones 'wrong_hostname' 'bad_method' 'to_honeypot' 'to_search_engine' para que realicen las acciones que estimeis oportunas.
Escucha este post Publicado por ehooo 0 comentarios
Suscribirse a: Comentarios (Atom)