Si tuviera que demostrar una . arquitectura remota de .NET Vulnerabilidad con un ataque práctico, ¿cuál elegirías?
He leído J. El informe de Forshaw sobre Rompiendo .NET a través de la serialización (PDF) , buscó en Google a fondo, y ahora quiero implementar un exploit funcional de un servicio .NET Remoting. No importa donde esté alojado el servicio. Puede ser ASP, IIS, servicio de Windows o lo que sea.
Ataques de DoS: dada la naturaleza de tecnología cruzada de estos marcos (C # -VB-C ...) en general, son difíciles de asegurar los "puertos" de conexión. Por lo tanto, si puede enumerar y encontrar los puntos de conexión, a menudo puede inundarlos o simplemente mantenerlos ocupados y crear un ataque DoS al matar de hambre el extremo "receptor" del marco. Por lo general, no es difícil de hacer y, a menos que se haya puesto MUCHO cuidado en la arquitectura y se haya asegurado adecuadamente, entonces esta es una fruta de bajo costo.
Ataques de inanición de recursos:
a. Ataque de recursos de proxy: en general, dados los esquemas de proxy implementados por estos marcos, generalmente hay un proxy de enlace flexible que no se destruye explícitamente cuando los recursos se configuran y se eliminan. Esto permite formas en las que un atacante puede crear secuencias de comandos para hacer explotar los recursos proxy creando escenarios de inanición.
b. Ataques de recursos físicos: los mecanismos de serialización utilizados para inflar / desinflar objetos pueden, en varios puntos, crear ataques de recursos físicos. Puede crear bombas de objetos: objetos grandes que consumen recursos que apagan o mueren de hambre al sistema de forma extensiva; o en el caso de la serialización xml recursiva, puede crear tanto el consumo de recursos de procesador como de memoria teniendo un procesamiento xml que vincule el sistema.
a. Mutación: aquí es donde se muta el código u objetos originales pero se inyecta un código nuevo en ellos. Cada idioma tiene sus propios medios y guardias que superar, pero generalmente se puede hacer.
b. Colateral: aquí es donde se muta o inyecta código en idiomas secundarios, como inyectar nuevo SQL en las interacciones de la base de datos, o expulsar nuevo Javascript en escenarios web.