Autor
|
Tema: Seguridad de un programa (Leído 9,747 veces)
|
kub0x
Enlightenment Seeker
Colaborador
Desconectado
Mensajes: 1.486
S3C M4NI4C
|
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 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!
|
|
« Última modificación: 3 Noviembre 2012, 21:56 pm por kub0x »
|
En línea
|
|
|
|
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...
|
|
|
En línea
|
|
|
|
kub0x
Enlightenment Seeker
Colaborador
Desconectado
Mensajes: 1.486
S3C M4NI4C
|
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!
|
|
|
En línea
|
|
|
|
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.aspxYo 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_MonoLa protección NET no es sencilla.
|
|
|
En línea
|
|
|
|
adastra
Endless Learner
Ex-Staff
Desconectado
Mensajes: 885
http://thehackerway.com/
|
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.
|
|
|
En línea
|
|
|
|
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!
|
|
|
En línea
|
MCKSys Argentina "Si piensas que algo está bien sólo porque todo el mundo lo cree, no estás pensando."
|
|
|
kub0x
Enlightenment Seeker
Colaborador
Desconectado
Mensajes: 1.486
S3C M4NI4C
|
@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!
|
|
|
En línea
|
|
|
|
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/downloadscomo veras no son pocos los formatos a desofuscar https://github.com/0xd4d/de4dot/tree/master/de4dot.code/deobfuscatorsen cuanto a herramientas para inspeccionar el codigo de cualquier .net te sugiero el de http://www.ntcore.com/exsuite.phpen 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.phpla palabra CLAVE "NET","calimero o bien leer temas del pasado como http://www.mediafire.com/apuromafo#bx1364mg0p4hmigual 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.phpejemplo http://portal.b-at-s.net/download.php?list.9o bien en foros rusos http://exelab.ru/f/index.php?action=vthread&forum=1&topic=16650o bien otros ingleses http://www.reteam.org/board/forumdisplay.php?f=28http://tuts4you.com/download.php?view.2701etc 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
|
|
|
En línea
|
Apuromafo
|
|
|
adastra
Endless Learner
Ex-Staff
Desconectado
Mensajes: 885
http://thehackerway.com/
|
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.
|
|
|
En línea
|
|
|
|
kub0x
Enlightenment Seeker
Colaborador
Desconectado
Mensajes: 1.486
S3C M4NI4C
|
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!
|
|
|
En línea
|
|
|
|
|
|