Vulnerabilidad Adobe Reader

11/02/2008 Una vulnerabilidad en Adobe Reader está siendo aprovechada para instalar malware

El día 6 de febrero Adobe publicaba una nueva versión del popular Adobe Reader que solucionaba varios problemas de seguridad. Sin dar apenas detalles, se recomendaba la actualización a la versión 8.1.2 que solucionaba «múltiples vulnerabilidades de impacto desconocido». Durante el fin de semana se ha sabido que uno de estos fallos está siendo aprovechado de forma masiva para instalar malware… desde hace semanas.La versión 8.1.2 apareció el día 6 de febrero, pero no ha sido hasta el día 9 que Idefense hizo público varios boletines que en los que, sin dar detalles técnicos, se adjudicaba el descubrimiento. Según el boletín, Adobe fue notificado de las vulnerabilidades a principios de octubre de 2007. El fallo en concreto que está siendo explotado está relacionado con desbordamientos de memoria intermedia a través de JavaScript. Inmunity, empresa desarrolladora de CANVAS, publicó por su parte en cuanto estuvo disponible la actualización de Adobe, un exploit para sus suscriptores.

Durante el fin de semana se ha sabido que desde al menos el día 20 de enero, uno de estos fallos está siendo aprovechado para instalar malware, en concreto Zonebac. El usuario quedaría infectado con sólo abrir un archivo PDF con Adobe Acrobat anterior a la versión 8.1.2 y el malware se ejecutaría con los permisos del usuario ejecutando la aplicación vulnerable. Zonebac es un malware especializado en adware y el payload del ataque se descarga, como viene siendo habitual, de un servidor remoto (no va incluido en el PDF que está siendo distribuido).

Al parecer Zonebac fue también el malware que instalaba la famosa vulnerabilidad descubierta en octubre y que afectaba a RealPlayer. En aquella ocasión, el fallo se dio a conocer cuando ya estaba siendo aprovechado por malware. Incluso fue descubierto por esa misma razón. También en octubre se detectaron PDFs que aprovechaban una vulnerabilidad compartida entre Microsoft Windows y Adobe Reader, y que también descargaba de forma automática malware en el sistema.

Durante este último fin de semana, ningún antivirus era capaz de detectar un PDF que intentase aprovechar el fallo. Una de las muestras que ha llegado a través de VirusTotal, es hoy detectada por:

AVG Generic_c.GGU
Fortinet W32/AdobeReader!exploit
F-Secure Exploit.Win32.Pidief.a
Kaspersky Exploit.Win32.Pidief.a
Microsoft Exploit:Win32/Pdfjsc.A
Symantec Trojan.Pidief.C
Webwasher-Gateway Exploit.PDF.ZoneBac.gen (suspicious)

Aunque hay que advertir que pronto será detectada por más motores (dado el impacto mediático del asunto). También es necesario tener en cuenta la capacidad de detección del payload en sí, que es descargado por separado, puesto que el archivo PDF es solo el vehículo para la ejecución inadvertida. Este puede ser reemplazado en el servidor en cualquier momento.

Como curiosidad, la muestra que hemos estudiado está creada con iText 2.0.7, una librería Java de código abierto usada para generar y manipular archivos PDF. Y su fecha de creación según el código (que posiblemente no tenga nada que ver con la realidad) es del 28 de enero.

Adobe ha decidido no actualizar la rama 7.x de su producto, con lo que la solución pasa por actualizar a la 8.1.2 desde su web oficial, o utilizar (si es posible) alternativas como Foxit Reader.

13/02/2008 Elevación de privilegios en el kernel vs. ejecución de código en Adobe Reader: Reacción de los Antivirus

Durante el fin de semana se ha dado a conocer una nueva vulnerabilidad en el kernel de Linux que permite a los usuarios conseguir privilegios de root. El problema es que también se ha hecho público, al mismo tiempo, un exploit que permite aprovechar la vulnerabilidad de forma sencilla. Lo mismo ha ocurrido con un fallo en Adobe Reader, pues durante el fin de semana se ha detectado que una vulnerabilidad estaba siendo aprovechada de forma masiva. Como simple experimento curioso, hemos comparado la reacción de los AV ante estas dos nuevas amenazas.¿Cómo han reaccionado las casas antivirus ante este par de vulnerabilidades? Pertenecen a mundos distintos, una permite elevación de privilegios en el kernel (a través de una llamada a vmsplice) y otra ejecución de código en Windows con los privilegios del usuario que ejecute Adobe Reader. Una la sufren los kernel de Linux y otra los usuarios de Adobe en Windows, y los antivirus han reflejado esta disparidad en su capacidad y velocidad de reacción.

Durante el fin de semana, nada más ser descubierta, ningún antivirus detectaba los archivos PDF que intentasen aprovechar la vulnerabilidad en Adobe para ejecutar código. No fue hasta el lunes a primera hora que apenas seis casas antivirus comenzaron a detectar la muestra analizada. Hoy son ya 14 los antivirus que reconocen el archivo PDF como una amenaza. Y es cuestión de tiempo que todos lo reconozcan por igual, pues el impacto mediático del problema está siendo importante.

http://www.virustotal.com/analisis/85630b830a06246ba16d19d342c4bb0c

El impacto mediático de la elevación de privilegios en el kernel también está siendo notable. Son decenas de distribuciones afectadas y al existir exploit disponible público, conseguir privilegios de root en un kernel vulnerable se convierte en un juego de niños. Hemos compilado el exploit y enviado el ejecutable ELF a VirusTotal para comprobar que (como esperábamos) ni un solo motor lo detecta. Ni durante el fin de semana ni días después de que la noticia saltara en todos los medios.

http://www.virustotal.com/es/analisis/a258aaa05e20f8c0bd27c28cd3a9a115

Se puede considerar normal que los antivirus tomen una amenaza para Linux como un «mal menor» teniendo en cuenta que no todos poseen soluciones adaptadas a escritorio para a este sistema operativo. Pero dadas ciertas circunstancias, sí que tendría sentido que los motores detectaran una amenaza así, incluyendo la firma en su base de datos. Por ejemplo en soluciones perimetrales, o para análisis en frío de discos duros con alguna distribución instalada… son situaciones donde podría resultar útil la detección (aparte de las puramente marketoides).

Por otro lado, para conocer comportamientos anteriores ante amenazas específicas para Linux, hemos enviado a VirusTotal una muestra compilada de un exploit que igualmente permitía elevar privilegios, pero en este caso mucho más antiguo. En concreto, conocido y público desde julio de 2006. El resultado es que nada menos que 12 casas antivirus lo detectan, que no es poco (incluso es un ratio mayor que algunas muestras actuales de malware para Windows).

http://www.virustotal.com/analisis/0802cf8b3e30d7ea7efc69cf44752b2c

Cabe pensar que tarde o temprano, al igual que ha ocurrido con este exploit de hace casi dos años, detectarán el nuevo exploit para el kernel, pero desde luego la reacción es mucho mas pausada comparada con la de cualquier amenaza para Windows. Quizás dentro de meses sea reconocida, pero ni de lejos es prioridad. Por supuesto, y dadas las circunstancias de saturación de muestras, la prioridad para las casas antivirus es proteger a los usuarios Windows… y no es poco trabajo.

¿Qué se está vendiendo como antivirus para Linux?

Los antivirus para Linux comparten en general la misma base de datos de firmas que sus versiones Windows. Es decir, detectan el mismo tipo de malware. Y los laboratorios antivirus están especializados en la detección de malware para Windows, que es donde se libra la gran batalla y donde, lógicamente, está el negocio.

La utilidad de un antivirus para Linux es muy cuestionable bajo esas premisas, a no ser que la máquina forme parte de un esquema de red o proporcione servicios a sistemas Windows. Por ejemplo, un servidor de correo, de archivos, etc. En estos casos el antivirus para Linux se convierte en una especie de filtro perimetral de las máquinas Windows que se conectan a él, al poder evitar que el código malicioso pase a través del servidor, pero no en una solución para esta plataforma en sí.

La realidad es que como antivirus para la propia plataforma Linux, las versiones actuales no están optimizadas. No tanto por el motor, sino porque las empresas antivirus no invierten en recursos especializados en identificar las amenazas para esta plataforma. Si bien no tienen nada que ver con la acaparadora e inmensa problemática del malware en Windows, también existen sus códigos maliciosos como cualquier otra.

Fuente: Hispasec

Tips Java

Siempre surgen dudas cuando empiezas a adentrarte en java y por eso he hecho este

Ejemplo práctico de serialización, de ficheros y de uso de GregorianCalendar:

El centro de salud de Valdecasas de Arriba desea llevar una gestión informatizada de
las citas programadas:

De cada cita se almacena el día, la hora y el no de sala.
Si la cita es para una consulta, se almacena el nombre del doctor y la especialidad.
Si la cita es para una prueba, se almacena el tiempo estimado de duración.

Para mejorar el seguimiento, todas las pruebas llevan asignada una referencia única.
Por supuesto, cada cita se refiere a un paciente, del que se conoce el nombre, sexo y número de afiliación a la Seguridad Social.
La única funcionalidad requerida es poder crear citas y consultarlas.
Se pide:
a) Implementar las clases
b) Escribir un programa que:

a. Cree una colección de objetos Cita que contenga pruebas y consultas.

b. Almacene la información de todas las citas (incluido el paciente al que se refieren en un archivo en disco.

c) Escribir un programa que:

a. Abra el archivo creado, copie a una colección los objetos y muestre su información

b. Téngase en cuenta que después de haber leído de disco se deben poder seguir dando citas, y las pruebas deben tener una referencia única.

Práctica optativa propuesta por Elisa García en 3º de ITIG en la UPSAM en enero de 2008

**************************************************************************

Primero: elaboración de un diagrama de clases…

Segundo, implementación:

CITA.JAVA

package optativa3;
import java.util.GregorianCalendar;
import java.io.*;

public class Cita implements Serializable{

private GregorianCalendar fecha;
private int hora; //TO DO: aprender a manaejar horas con GregorianCalendar…
private int sala;
private Paciente paciente;

public Cita(GregorianCalendar f, int h, int s, Paciente p) {
fecha =f;
hora = h;
sala=s;
paciente = p;
}
public GregorianCalendar getFecha(){
return fecha;
}
public int getHora(){
return hora;
}
public int getSala(){
return hora;
}
public Paciente getPaciente(){
return paciente;
}
}

CITACONSULTA.JAVA

package optativa3;
import java.util.GregorianCalendar;
import java.io.*;

public class CitaConsulta extends Cita implements Serializable{

private String doctor;
private String especialidad;
public CitaConsulta(GregorianCalendar f, int h, int s, Paciente p, String d, String e) {
super (f,h,s,p);
doctor = d;
especialidad=e;
}
public String getDoctor(){
return doctor;
}
public String getEspecialidad(){
return especialidad;
}
}

CITAINPUT.JAVA

package optativa3;
import java.io.*;

public class CitaInput {

private FileInputStream file;
private ObjectInputStream input;

public CitaInput() {
}
public void Abrir() throws IOException{
file = new FileInputStream(«C:/Citas.data»);
input = new ObjectInputStream (file);
}

public void cerrar()throws IOException{
if(input!=null)
input.close();

}
public Cita leer() throws IOException, ClassNotFoundException{
Cita cit= null;
if (input !=null){
try{
cit = (Cita) input.readObject();
}catch(Exception ex){

}
}
return cit;
}

}

CITAOUTPUT.JAVA

package optativa3;
import java.io.*;

public class CitaOutput {
private FileOutputStream file;
private ObjectOutputStream output;

public CitaOutput() {
}
public void Abrir() throws IOException{
file = new FileOutputStream(«C:/Citas.data»);
output = new ObjectOutputStream (file);
}
public void cerrar()throws IOException{
if(output!=null)
output.close();
}
public void escribir(Cita cit) throws IOException{
if(output!=null)
output.writeObject(cit);
}
}

CITAPRUEBA.JAVA

package optativa3;
import java.util.GregorianCalendar;
import java.io.*;

public class CitaPrueba extends Cita implements Serializable{

private double tiempoEstimado;
private Prueba referencia;
public CitaPrueba(GregorianCalendar f, int h, int s, Paciente p, double t , Prueba r) {
super (f,h,s,p);
tiempoEstimado = t;
referencia = r;
}

}

PACIENTE.JAVA

package optativa3;
import java.io.*;

public class Paciente implements Serializable{

private String nombre;
private String sexo;
private long numSS;
public Paciente(String nom, String s,long num) {
nombre = nom;
sexo = s;
numSS=num;
}
public String getNumbre() {
return nombre;
}
public String getSexo() {
return sexo;
}
public long getNumSS() {
return numSS;
}
}

PRUEBA.JAVA

package optativa3;
import java.io.*;

public class Prueba implements Serializable{

private int referencia;
private String resultados;
public Prueba(int ref, String res) {
referencia=ref;
resultados = res;
}
public int getReferencia(){
return referencia;
}
public String resultados(){
return resultados;
}

}

MAIN.JAVA

package optativa3;
import java.util.*;
import java.io.*;
import java.util.Random; //para generar aleatoriamente el numero de sala

public class Main {

public Main() {
}
public static void main(String[] args) {
Random rnd = new Random(TUDNI); // 😉 :p
int cuantasLeidas=0;
int cuantasEscritas =0;
ArrayList<Cita> Citas = new ArrayList<Cita>();
System.out.println(«LEEMOS LO QUE HAYA EN C:/Citas.data»);
try{ //RECUPERAMOS TODAS LAS CITAS…
CitaInput entrada;
entrada = new CitaInput();
Cita c;
entrada.Abrir();
c = entrada.leer();
cuantasLeidas+=1;
while (c!=null){
// System.out.println(«Cita leída: «+ c.getFecha().get(Calendar.DAY_OF_MONTH)+»/»+c.getFecha().get(Calendar.MONTH)+»/»+c.getFecha().get(Calendar.YEAR));
Citas.add(c);
c = entrada.leer();
cuantasLeidas+=1;
}

entrada.cerrar();
}
catch (Exception ex){
}
if (cuantasLeidas !=0)
cuantasLeidas -= 1;
System.out.println(«*******************************************************************»);
System.out.println(«Recuperadas «+ cuantasLeidas + » citas. \n»);
System.out.println(«*******************************************************************»);
//Voy a añadir una cita para consulta (casi) todos los días del año.. es algo genérico
for (int m = 1; m<13; m++){
for (int d = 1; d<28; d++){
GregorianCalendar f = new GregorianCalendar (2008,m,d);
int s = (int)(rnd.nextDouble() * 10.0);
Paciente p = new Paciente («NOMBRE»+m*d+m+d, «SIN DETERMINAR»,m*d+m+d);
CitaConsulta cc = new CitaConsulta (f, 12, s, p, «DOCTOR «+m, «ESPECIALIDAD»);
Citas.add(cc);
}
}
//Voy a añadir una cita para pruebas (casi) todos los días del año.. es algo genérico
for (int m = 1; m<13; m++){
for (int d = 1; d<28; d++){
GregorianCalendar f = new GregorianCalendar (2008,m,d);
int s = (int)(rnd.nextDouble() * 10.0);
int ref = (int)(rnd.nextDouble() * 1000.0);
Paciente p = new Paciente («NOMBRE»+d, «SIN DETERMINAR»,m*d+m+d);
Prueba pru = new Prueba (ref,»RESULTADOS SIN DETERMINAR»);
CitaPrueba cc = new CitaPrueba (f, 12, s, p, 0.25 /*horas => 15 minutos*/, pru);
Citas.add(cc);
}
}
//Una vez tendo todos esos datos creados los serializaremos a un fichero…
try{
CitaOutput salida;
salida = new CitaOutput();
salida.Abrir();
for (Cita c: Citas){
// System.out.println(«Cita escrita: «+ c.getFecha().get(Calendar.DAY_OF_MONTH)+»/»+c.getFecha().get(Calendar.MONTH)+»/»+c.getFecha().get(Calendar.YEAR));
salida.escribir(c);
cuantasEscritas +=1;
}
salida.cerrar();
}catch (Exception ex){
ex.getMessage();
}
System.out.println(«*******************************************************************»);
System.out.println(«Guardadas «+ cuantasEscritas + » citas. \n»);
System.out.println(«*******************************************************************»);
System.out.println(«ACLARACIÓN FINAL:»);
System.out.println(«Este programa es una prueba de funcionalidad…»);
System.out.println(«Por comodidad en cada ejecución:»);
System.out.println(«\t 1.- Se rellena un ArrayList<Cita> con lo guardado en la ejecución anterior.»);
System.out.println(«\t 2.- Se crean 324 citas para consulta y 324 citas para pruebas.»);
System.out.println(«\t 3.- Se guardan todas las citas, las leidas y las «+ 2*12*28 + » gerneradas en esta ejecución.»);
System.out.println(«Fin de la optativa 3: TIEMPO DE IMPLEMENTACIÓN: 1:45 h (mas o menos, he reutilizado mucho código)»);
}
}

OS HA SIDO UTIL????

Saludos.

JxXx

PD:

Gracias a todos mis profesores por el material didáctico y las ganas puestas en clase y gracias también a los compañeros que han peleado asignaturas dificiles como Redes, Ingeniería del Software (I), Metodología de la POO Avanzada o Estadística, codo con codo. Suerte con las notas y a seguir palante. Queda dicho.

ANÁLISIS ESTRUCTURADO – INGENIERÍA DEL SOFTWARE

 

1.- EL CLIENTE
2.- ANÁLISIS DE REQUISITOS
3.- DIAGRAMA DE FLUJO DE DATOS
4.- DIAGRAMA DE ENTIDAD RELACIÓN
5.- DICCIONARIO DE DATOS

1.- EL CLIENTE

Nuestro supuesto cliente es una cooperativa de viviendas de Madrid. La cooperativa desea adquirir un sistema de gestión que facilite la comunicación de diversa información entre los propietarios de cada parcela, la junta rectora y la gestoría encargada de la contabilidad.

 

La aplicación deberá:

 

• Recoger tanto los gastos que genere cada propietario como los gastos de la cooperativa y enviárselos a la gestoría que lleva la contabilidad, ésta se encargará del mantenimiento de dichos datos pero serán accesibles por el sistema.

 

• Recoger las incidencias que genere cada propietario así como las de la propia cooperativa (averías, seguridad, etc.), elaborar un parte de incidencias semanal y enviárselo a cada propietario.

 

• Solventar el problema de la elaboración de un orden del día para las asambleas permitiendo que la junta rectora envíe un borrador del orden del día a cada propietario y que éstos a su vez puedan proponer puntos para incluirlos en dicho orden del día. Será el propio sistema el qué elaborará el orden del día definitivo de acuerdo a ciertas reglas pendientes de especificar.

 

• Permitir el envío de cualquier documento previa aceptación de los contenidos por parte de la junta rectora.

 

 

Nota: la junta rectora quiere almacenar toda la información referente a documentos y asambleas que circule por el sistema y hacerla accesible a todos los propietarios.

 

 

2.- ANÁLISIS DE REQUISITOS

 

A partir de los requisitos que nos ha proporcionado el cliente elaboraremos una especificación formal de requisitos del sistema. Para ello, identificaremos la estructura de la funcional del sistema requerido descomponiéndola en subprocesos y entidades.

 

 

 

Del análisis de los requisitos de nuestro cliente sacamos que los terminadores del sistema a desarrollar son la junta rectora, los propietarios y la cooperativa así como de una base de datos externa con datos contables.

 

El sistema lo podemos dividir en tres subsistemas principales que se encargarán de gestionar los gastos, de gestionar las incidencias y de gestionar la documentación. Este último subsistema lo podemos dividir a su vez en dos, puesto que con la documentación referente a puntes del día de asambleas habrá que generar un orden del día definitivo y mantener toda esa información almacenada y con respecto a los documentos habrá que gestionar el almacenamiento y la aceptación por parte de la junta rectora de los mismos.

 

Antes de realizar el DFD haremos un análisis de los flujos generales de entrada y salida del sistema:

 

ENTRADA		SALIDA
FLUJO	PROCEDENCIA	FLUJO	PROCEDENCIA
Gastos	Propietario	Gastos	Propietario
Gastos	Cooperativa	Gastos	Cooperativa
Documentos	Propietario	Documentos	Propietario
Documentos	Junta rectora	Documentos	Junta rectora
Orden Día	Propietario	Orden Día	Propietario
Asamblea	Junta rectora	Asamblea	Junta rectora
F_Incidencia_Coop	Cooperativa	F_Parte_Incidencias	Propietario
F_Incidencia_Prop	Propietario	F_Datos_Contables	Gestoría (BBDD)
F_Datos_Contables	Gestoría (BBDD)

 

* los flujos en negrita son grupos de flujos de datos, el departamento de desarrollo es consciente de este hecho y tendrá especial cuidado en mantener la consistencia entre los distintos niveles de explosión.

3. DIAGRAMA DE FLUJO DE DATOS

Hecho este análisis de requisitos el siguiente paso es elaborar los diagramas de flujo de datos del sistema detallando, desde el nivel de abstracción propio de la fase de análisis, las entidades, flujos de información y procesos del sistema.

3.1 DIAGRAMA DE CONTEXTO (Nivel 0)

3.2 PRIMER NIVEL DE EXPLOSIÓN

3.3 SEGUNDO NIVEL DE EXPLOSIÓN

4.- DIAGRAMA DE ENTIDAD RELACIÓN

5.- DICCIONARIO DE DATOS

• Cooperativa= @nombre + { JuntaRectora } + { Parcela }
• JuntaRectora = @periodo + { Propietario }
• Propietario = @dni+nombreApellidos + { Parcela }
• Parcela= @numParcela + Dirección +Metros
• Incidencia = @ codInc + Descripción
• Documento = @numDoc +Fecha +Tema + Titulo + Autor
• IncidenciaPropietario = @numParcela + @codInc + Fecha +

+ Incidencia

• IncidenciaCooperativa = @codInc + Fecha + Incidencia
• ParteIncidencias = @numParte +
  + {[ IncidenciaPropietario | IncidenciaCooperativa ]}
• DocumentoPropietario = @codProp | + Documento
• DocumentoJR = @periodo + Documento
• Punto_OD = @numPOD + Descripción
• OrdenDia = @CodOD + { Punto_OD }

Almacenes:

• HistóricoAsambleas = @ NumAsamblea + @CodOD + Fecha
• HistóricoDocumentos = @ Título + Autor + @dni + Fecha