Casi no se ven mucho acerca del desarrollo de malware asi que quiero aportsr compartiendo algunas cositas que voy encontrando. Aqui pienso escribir los conceptos basicos del desarrollo de malware usando el WinAPI. Como por ejemplo el cargado dinamico de funciones, accesando El PEB (Process Environment Block [Bloque de entorno de Processos]) y la ejecucion de funciones en el codigo. Además de la obufscacion y encodificacion de la payload usando cosas como XOR o AES para hacerla más difícil de de detectar. Entre otras :3.

Cargado y Ejecucion Dinámica de una Función[size]

De ejemplo vamos a empezar con algo simple. La función MessageBoxA que simplemente abre una ventanilla para mostrar un mensaje. Esta función es parte de WinAPI. Nuestro código va a ser simple pero veremos cómo montar funciones dinamicamente. Esto es uno de los principios fundamentales para evadir detección.

int main(void) {
MessageBoxA(0, "Holi mundo.", "info", 0);
return 0;
}
 

En Este código estamos llamando la función directamente. Lo que significa que será enlazada estáticamente al momento de la compilación. Esto en resumen significa que su código será incluido en nuestro programa y no se tendrá que cargar al momento de la ejecución.

Ahora esto es muy fácilmente detectado al momento de análisis así que lo llevaremos otro paso. Observemos el siguiente código:

int main(void) {
size_t get_MessageBoxA = (size_t)GetProcAddress( LoadLibraryA("USER32.dll"), "MessageBoxA" );
def_MessageBoxA msgbox_a = (def_MessageBoxA) get_MessageBoxA;
msgbox_a(0, "Holi mundos", "info", 0);
return 0;
}
 

El Codigo hace lo mismo que el anterior la diferencia es que aquí estamos cargando la función dinamicamente mediante GetProcAddress. Esta función (que literalmente se llama "obtén dirección de proceso") en el momento de ejecución irá a USER32.dll y buscará la dirección de MessageBoxA. Para hacer que esto funcione, necesitamos un puntero de función que get_MessageBoxA que coincida con la función MessageBoxA. Usamos está dirección para asignarla al puntero y a travez del puntero accesamos la función.

El usar punteros nos ayuda a obfuscar la funciones que usamos y hacerle más difícil al análisis estático que es lo que estamos haciendo. Considera el siguiente código que son dos funciones que habren ventanillas con un mensaje. Estas funciones serán importadas de un dll:

__declspec(dllexport) void func1() { MessageBoxA(0, "", "Uno", 0); }
__declspec(dllexport) void func2() { MessageBoxA(0, "", "Dos", 0); }
 
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved) {
    if (fdwReason == DLL_PROCESS_ATTACH) {
        // Función gancho para la func1
    }
    return TRUE;
}
 

Esto parece normal, tenemos dos funciones que son importadas de un dll y cada una abre una ventanilla como lo dije. Pero la cosa aquí es que dentro de DllMain podemos cambiar el comportamiento de func1. Esto para dar una impresión inicial de código benigno y después correr el código sospechoso. La cosa es que esto solo ocurrirá al momento de ejecución haciéndolo muy bueno para evitar detección.

El Problema

La vulnerabilidad de una inyeccion SQL surge cuando el programador declara queries dinamicas en la logica de su base de Datos. Aqui hay un ejemplo en PHP de esta vulnerabilidad:

$offset = $_GET['offset'];
$query = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $offset;";
$result = pg_query($conn, $query);
 

 Estas queries son creadas por la concatenacion de strings que el usuario define. Para evitar esta vulnerabilidad El programador tiene dos opciones:

• Dejar de usar queries dinamicas.
• Evitar que el SQL malicioso del usuario afecte la logica de la base de Datos.

Aqui pretendo tratar unas medidas simples que los programadores pueden tomar para evitar o en todo caso reducir el daño de una iSQL. Las tecnicas incluidas aqui son casos generales, y tambien pueden ser aplicadas para defenderse de toros tipos de ataques similares como las inyecciones XPath y XQuery por ejemplo.

La ley del privilegio

Por lo general en la seguridad informatica es Buena idea que las aplicaciones se ejecuten con privilegios bajos, solo con lo necesario. Esto es especialmente verdad cuando se trata de una aplicacion que sera usado remotamente por usuarios en los que no se confia (por lo general es mala idea confiar en el usuario de tu aplicacion). Por eso quiero empezar con este tema, sirve como una Buena practica y mitiga El daño incluso despues de una explotacion exitosa.

La mejor manera para ejecutar esto es tener distintos usuarios de privilegio limitado en tu entorno. El error comun aqui es que muchos programadores toman El Camino facil de darle DBA o admin de base de Datos a las cuentas de su aplicacion. Esto es peligroso y aumenta el daño de una iSQL existosa. Esta bien que todo "funciona Bien" cuando lo haces pero si una aplicacion es comprometida el resto de la base de Datos queda expuesta.

La implementacion de esta medida varia segun la plataforma que estas usando pero la idea es la misma. Empieza de abajo hacia arriba,  no es recomendable darle todos los privilegios a un usuario de base de Datos e irle quitando los que no necesita. Puedes pasar por alto un privilegio sin darte cuenta pero el 1337 hacker que quiere tus Datos si lo identificara. Es por ESO que debes tomar en cuenta que es lo que necesita tu cuenta y darle solo eso. Una cuenta que solo lee Datos de una tabla solo require privilegios de lectura y solo para la tabla en cuestion. Por ejemplo, en una e-commerce una cuenta que solo arroja productos con su descripcion solo deberias de tener permisos de lectura solo para la tabla de productos y nada mas. El darle otros privilegios Seria una amenaza de seguridad. Si una cuenta solo require partes de una tabla, crea una view que se los da. Y a esta cuenta dale permiso solo para esa view y no para la tabla que hay detras.

Usando queries preparadas

Esta es la forma en que se deberia de enseñar a los programadores a hacer sus queries. En vez de usar un string para la queries, Este las toma en la forma de un parametro. Esto es Algo similar a como algunos lenguajes como perl manejan su funciona de system() precisamente para evitar una inyeccion. Este estilo le permite a tu base de Datos distinguir entre Datos y codigo. Ademas de que es mas facil de leer y te obliga a primero programar tu base de datos y despues pasar los parametros a la formacion de queries. Por ejemplo, si un hacker intenta buscar "juan' or '1'='1" en vez de ser vulnerable a que se ejecuten como codigo, la base de Datos buscara un usuario que se llame "juan' '1'='1".  Aqui una's maneras de hacerlo segun El lenguaje que uses:

• JAVA EE: se usa PreparedStatement() con variables enlazadas
• .NET: Usando queries parameterizadas como SqlCommand() o OleDbCommand().
• PHP: Usa PDO con queries estrocamente declaradas con bindParam().

[lil]Hibernate: Usa parametros nombrados con createQuery().[/li]
[li]SQLite: Usa sqlite3_prepare() para crear un objeto de query.[/li]
[/list]

JAVA:

// Esto tambien deberia ser validado 
String nombreCliente = request.getParameter("nombre");
String query = "SELECT saldo_cuenta FROM datos_usuarii WHERE nombre_cliente = ? ";
PreparedStatement pstmt = connection.prepareStatement( query );
pstmt.setString( 1, nombreCliente);
ResultSet resultados = pstmt.executeQuery( );
 

C# .NET:
 En .net la creacion y ejecucion de una query no cambian, solo pasa los parametros Al query usando Parameters.Add().

String query = "SELECT saldo_cuenta FROM datos_usuario WHERE nombre_usuario = ?";
try {
  OleDbCommand command = new OleDbCommand(query, connection);
  command.Parameters.Add(new OleDbParameter("nombreCliente", CustomerName Name.Text));
  OleDbDataReader reader = command.ExecuteReader();
  // …
} catch (OleDbException se) {
  // En Caso de error
}
 

Practicamente cualquier lenguaje de programacion tiene manera de hacer esto (para mas ejemplos buscar OWASP parameterized query cheat sheet). Incluso las abstracciones de SQL tambien tienen esta capacidad como por ejemplo HQL antes mencionado:

//HQL no seguro usando concatenacion de strings 
Query HQLNoSeguro = SESSION.createQuery("from inventario where productoID='"+parametroUsuario+"'");
//La misma pero en su forma Segura usando parametros nombrados 
Query HQLSeguro = SESSION.createQuery("from Inventorio where productoID=:productoid");
HQLSeguro.setParameter("productoid", parametroUsuario);
 

Una de Las ventajas de usar queries preparadas es que la logica se queda dentro de la aplicacion haciendola independiente de la base de datos.

A mi me ha gustafo mucho Este lenguaje pero Veo que no a muchos. Me gusta la capacidad de poder usar El mismo Codigo y compilar para varias plataformas muy facilmente. Esto principalmente debido a que para nada uso windows y mi entorno de windows es solo una vm con windows 7. Aparte la concurrencia nativa es una belleza. Pero muchos se molestan por su falta de soporte de genericos, lo cual ya tiene pero por algun Motivo nadie esta conforme. De todos modos yo rara vez uso genericos y El Unico uso que Les eh dado es a travez de referencias en perl y void pointers en c pero repito que no Les Veo mucho uso. cuales son sus opiniones sobre los genericos?

Aparte otro Problema que muchos tienen es que su libreria estandard es muy reducidad lo cual tampoco Veo por que es un Problema. A mi se me hace mucho mejor incluir solo lo mas minimi e ir importando lo Demas conforme lo necesite.

Otra cosa, que no va tanto Al tema pero bueno. Recien escuche una platica de defcon que lo recomienda para El desarrollado de malware. Que son sus opiniones respecto a esto?

Tengo mucho material que eh aprendido a lo largo del tiempo y queria saber que tan permitido esta publicar sobre El tema.

Por enemplo si publico Algo sobre obfuscasion y entrega de un spyware pero no el.spyware como tal, esto seria aceptable? O si por ejemplo subo una guia mas a detalle pero solo subo El link a una guia exterior?

De ante Mano gracias y espero aprender mucho con ustedes amiguis :3