Seguridad de un programa

Iniciado por kub0x, 3 Noviembre 2012, 21:13 PM

0 Miembros y 1 Visitante están viendo este tema.

kub0x

Buenas noches a todos!

Como no sé si esto va en la sección de Ing. Inversa, .NET o seguridad pues me he decantado por la primera.

Estoy preocupado porque programo en .NET y todos sabemos que en nuestros programas, cuando eramos novatillos pues incluiamos información confidencial que no quisieramos que personas ajenas obtuvieran. He probado algun decompilador de .NET (Reflector, DotNet Resolver...) y he podido decompilar todo mi proyecto, ya sean .exe o .dll, ASUSTA! Vengo con los deberes hechos, pues leí algo sobre seguridad aplicada a programas en el blog de Karmany (Packers, métodos alternativos para generación de información sensible..) y lo estudiaré más a fondo cuando tenga que lanzar la aplicación.

Hay plugins para Visual Studio que ofuscan el Source del programa, pero recientemente he encontrado Desofuscadores para distintas versiones conocidas de ofuscadores, por lo que si ofuscase el programa, el código ofuscado lo podría desofuscar y obtendría el original. Es como si cada medida de seguridad tuviera una contramedida :P

Ya pensé en incluir la información confidencial en .dll, ensamblados cargados en la ejecucción del programa, archivos cifrados, pero ¿Cómo sé que un cracker no pueda descifrar el source para luego acceder a dicha info? ¿Qué métodos puedo emplear para aumentar la seguridad de mis programas?

Gracias por vuestra atención,

Saludos!
Viejos siempre viejos,
Ellos tienen el poder,
Y la juventud,
¡En el ataúd! Criaturas Al poder.

Visita mi perfil en ResearchGate


karmany

Es un tema muy importante para desarrolladores.

Actualmente existen en el mercado muchos "obfuscator for .NET platform" que puedes buscar en la red. Es problema es que la protección es diferente de una aplicación nativa como estás comprobando y probando.

Yo también quiero proteger una app mía y siempre la he desofuscado.

A ver si encuentro más info esta semana...


kub0x

La inseguridad se debe a que .NET es interpretado y al generar cualquier aplicación está es traducida a un lenguaje intermedio (MSIL) o bytecode.

Al ejecutar dicha aplicación el CLR, que no es más que un entorno de ejecucción, se encarga de traducir el código intermedio (MSIL) a lenguaje máquina, por lo que nunca tendremos dentro de un ejecutable código máquina sino un lenguaje intermedio lo que hace posible la obtención del Source mediante la interpretación de ese código intermedio.

.NET -> código intermedio -> CLR -> código máquina.

Espero tu respuesta karmany, ya que me preocupa bastante la inseguridad que brindan este tipo de lenguajes.

Saludos!
Viejos siempre viejos,
Ellos tienen el poder,
Y la juventud,
¡En el ataúd! Criaturas Al poder.

Visita mi perfil en ResearchGate


karmany

Si, efectivamente ese es el problema y aunque los ofuscadores lo dejen todo ilegible renombrándolo y lo encripten, pues es posible entender el código.

Existe una protección denominada Control flow obfuscation para prevenir que se pueda decompilar tu código IL en un lenguaje entendible como VB.NET o CSharp como ocurre con Reflector. Se usa para evitar entender qué hace el código. Aunque yo creo que con tiempo se podrá crackear... y sin entender nada...

Yo a lo que me refería antes (no tenía tiempo para escribir) es intentar algo que no he testeado todavía y es convertir tu código NET en nativo directamente. Al igual, como has comentado antes que lo hace el CLR, pues ¿por qué no lo haces tú directamente? además ahorraremos un trabajo y se ejecutará más rápido y entonces tal vez se pueda proteger el código nativo.

Microsoft (y algún otro protector) habla del "Generador de imágenes nativas" (Ngen.exe). Por ejemplo para la versión NET Framework 4.5: http://msdn.microsoft.com/es-es/library/6t9t5wcf%28v=vs.110%29.aspx
Yo no lo he testeado todavía.

También veo alguna desventaja como que no se podrá ejecutar tu programa en Linux. http://es.wikipedia.org/wiki/Proyecto_Mono

La protección NET no es sencilla.

adastra

Si me permites, te daré mi opinión...
La ocultación o el modelo de la "security by obscurity" es el peor modelo que se pueda emplear en programación segura (y no lo solo lo digo yo, es una de las peores practicas que se pueden emplear), en lugar de preocuparte por esconder lo que hace tu programa, aprende programar bien!
Si crees que ocultar el código fuente de un programa lo hace más seguro, toma como ejemplo Microsoft y su familia de productos Windows, en cada nueva versión siempre se encuentran vulnerabilidades que en ocasiones tardan meses en solucionar, ha servido de algo el hecho de que oculten su código? francamente lo dudo. Ahora... mira sistemas como Debian y sobre todo, su "Contrato Social", ellos no ocultan absolutamente nada, ni siquiera los problemas de seguridad y es por ese motivo que es un sistema robusto y muy seguro, porque mucha gente lo intenta mejorar día a día....


En conclusión, te recomendaria que no te centres en "ocultar" lo que haces, en su lugar, centraté en aprender a programar de forma segura, las pautas son practicamente las mismas para .Not como para cualquier otro lenguaje de programación orientada a objetos como Java, Python o Ruby.
Un Saludo.

MCKSys Argentina

Bueno, como te ha dicho Karmany, si quieres obtener la mejor proteccion en .NET, conviene usar los packers hibridos (los que generan codigo ASM a partir de un .NET).

De esta forma es imposible obtener el source.

Lo que debes tener en cuenta es que sin el source, tambien puede crackearse un soft. Lo que debes hacer, aparte del packer, es realizar una buena rutina para que oculte la informacion que no quieres que se vea...

Saludos!
MCKSys Argentina

"Si piensas que algo está bien sólo porque todo el mundo lo cree, no estás pensando."


kub0x

@karmany: ¿Si aplicase el Control Flow obfuscation no se podria obtener el código MSIL y por lo tanto no se

podria interpretar en su alto nivel (.NET)? Si es así, ¿podrías recomendarme algun escrito sobre como aplicar dicha

protección o en su defecto algun ofuscador que aplique dicha técnica? ¿Se podría desofuscar y obtener el código original?

@MCKSys Argentina -- karmany: Sobre lo que comentabais de traducir directamente el código MSIL a nativo sin tener que depender del CLR suena bastante interesante, ya que si lo tenemos directamente en código nativo la decompilación y el posible descifrado del código serían bastante tediosas y no te cuento si le metemos un par de medidas de seguridad
más. Ya estoy buscando sobre el tema, a ver que tal me va.

@adastra: Estoy de acuerdo contigo en la parte de la implementación de seguridad mediante el código, pues es bien sabido que el mal diseño de un programa puede hacerlo vulnerable. Sin embargo, no me hace ninguna gracia que una plataforma como .NET tenga una pésima seguridad, refiriéndome a la protección de código, ya que puedes decompilar un ejecutable escrito en cualquier lenguaje de dicha plataforma y obtener su código en segundos. Aunque apliques ofuscación al código, éste es fácilmente obtenible por desofuscadores que pueden con casi todo. Realmente Microsoft no hizo los deberes, .NET lo considero un lenguaje inseguro.

Cualquier recomendación que me deis es agradecida.

Saludos!
Viejos siempre viejos,
Ellos tienen el poder,
Y la juventud,
¡En el ataúd! Criaturas Al poder.

Visita mi perfil en ResearchGate


apuromafo CLS

saludos, no suelo comentar en temas, pero debido a que hablan de ofuscacion en .net es bueno que comienzes a ver temas, aqui una tool entre muchas

https://github.com/0xd4d/de4dot/downloads
como veras no son pocos los formatos a desofuscar
https://github.com/0xd4d/de4dot/tree/master/de4dot.code/deobfuscators

en cuanto a herramientas para inspeccionar el codigo de cualquier .net te sugiero el de http://www.ntcore.com/exsuite.php

en cuanto a protectores hay muchisimos en esa web por ejemplo encontraras una llamada http://www.ntcore.com/   Phoenix Protector

si es de haber visto las que mas tardan suelen ser las SMART Assembler o bien  para mas culturizacion del tema de ing inversa mira algun escrito en la web de ricardonarvaja

http://ricardonarvaja.info/WEB/buscador.php
la palabra CLAVE "NET","calimero

o bien leer temas del pasado como
http://www.mediafire.com/apuromafo#bx1364mg0p4hm

igual hay mucho que se puede comentar de .net, pero no necesariamente digamos que siempre es facil, hay antidebug propio de .net, que bien aveces se ve en tutoriales de CRACKMES.de

por otro lado suerte, si realmente crees tener mas tiempo, hay un foro que son re buenos crackeando .net

http://portal.b-at-s.net/news.php
ejemplo
http://portal.b-at-s.net/download.php?list.9

o bien en foros rusos
http://exelab.ru/f/index.php?action=vthread&forum=1&topic=16650

o bien otros ingleses
http://www.reteam.org/board/forumdisplay.php?f=28
http://tuts4you.com/download.php?view.2701
etc

el tema es que digamos que los que menos se vean, suelen ser los mas cotizados (codeveil, entre otros muchos o cientos http://forum.tuts4you.com/topic/28640-dumbassembly-smartassembly-deobfuscator-net-unpacker/page__hl__dotnet)

uff, bueno sea que uses smartAssembler, pebrowser o el que quieras usar, solo cuida que tengas rutinas suficientes, puedes aveces hasta meterlas dentro de sandbox(como thinstall o bien otras), el tema delicado es que tu programa sea funcional, o demo en caso x

saludos Apuromafo



adastra

Cita de: kub0x en  5 Noviembre 2012, 20:56 PM
Estoy de acuerdo contigo en la parte de la implementación de seguridad mediante el código, pues es bien sabido que el mal diseño de un programa puede hacerlo vulnerable. Sin embargo, no me hace ninguna gracia que una plataforma como .NET tenga una pésima seguridad, refiriéndome a la protección de código, ya que puedes decompilar un ejecutable escrito en cualquier lenguaje de dicha plataforma y obtener su código en segundos. Aunque apliques ofuscación al código, éste es fácilmente obtenible por desofuscadores que pueden con casi todo. Realmente Microsoft no hizo los deberes, .NET lo considero un lenguaje inseguro.

Cualquier recomendación que me deis es agradecida.

Saludos!
Lo mismo ocurre en cualquier plataforma y con cualquier lenguaje de programación, es algo inevitable... esto simplemente reafirma lo que he dicho antes, ocultar el código fuente de un programa es INUTIL, un buen atacante siempre va a encontrar formas de comprometer un programa que este mal escrito, con su código fuente o sin él. Así que nuevamente, recomendación: Aprender buenas practicas de programación en lugar de centrarse en "ofuscar" el código.

kub0x

Gracias apuromafo por tus aportes, pues me he pasado estos días leyendo varios de ellos y j oder que fácil es crackear un ensamblado .NET, esté ofuscado o no.

De vuelta al tema, he probado un Protector para .NET, el "Phoenix Protector" y me ha funcionado a las mil maravillas, ya que aunque lo desofusce con de4dot desofuscator no se ve mas que las clases y métodos que utilizo, pero la parte de las Strings queda protegida y los nombres de las funciones quedan encriptadas. Está claro que no voy a hardcodear nada en el programa, pero aun así me interesa que no se pueda acceder a la parte donde llamo al fichero donde se encuentran las credenciales encriptadas.

He leído que el Ngen.exe (no lo he testeado), que es el programa que traduce el código intermedio MSIL a código nativo, necesita del Framework de .NET en la máquina que ejecute el programa compilado a nativo. Encontré buenas referencias a la suite de Salamander .NET, que incluye herramientas de decompilación, varios tipos de ofuscación, protección de código y compilación a nativo, eso sí es carillo.

A ver si encuentro alguna aplicación para compilar a nativo sin ser dependiente del Framework de .NET (testearé el Ngen.exe) y os cuento, pues suena interesante no depender del compilador Just-in-Time (JIT), además que nuestras aplicaciones ganarían velocidad en su ejecucción.

Saludos!
Viejos siempre viejos,
Ellos tienen el poder,
Y la juventud,
¡En el ataúd! Criaturas Al poder.

Visita mi perfil en ResearchGate