05 marzo 2012

Scripts de seguridad: ¿Qué lenguaje elegir?


Surge una necesidad: hay que automatizar una labor para, dada una entrada, procesarla y generar unos resultados. ¿Cómo lo implemento para que sea un ordenador quien lo haga por mí? ¿Qué herramientas puedo utilizar para ello?

Dar una solución a esa necesidad es algo que, después de un rato de meditación, seréis capaces de pre-planificar mentalmente, ayudados de boli y papel si fuese necesario, plasmando el resultado en una pantalla con fondo negro. Ahora bien, ¿qué lenguaje de programación utilizaréis?

Para los lectores de Security By Default que no conozcan RootedCon, decir que es uno de los Congresos de Seguridad más importantes que se llevan a cabo en España, en el que además, este año fuimos ponentes mis compañeros Jose Antonio Guasch, Yago Jesús y el que escribe este artículo.

Entre las diferentes charlas, en las que se presentaban el resultado de investigaciones, herramientas, descubrimientos, etc,… creo que fue Juan Garrido "Silverhack" (al cual tengo en gran estima) quien indicó primeramente que para la codificación de lo que necesitaba, utilizó BATCH y Powershell; Lord Epsylon indicaba que la herramienta XSSer estaba escrita en Python; Raul Siles de Taddong hablaba de Java como lenguaje elegido; Pablo San Emeterio usaba C; y yo, Lorenzo Martínez, me decantaba por Perl y C++ para la realización y ejecución de mis scripts.

Por Twitter, y con el hashtag #rooted2012, encontraréis varias referencias y chistes sobre las preferencias de cada uno, por el lenguaje de scripting más adecuado.

Así pues, me gustaría contaros mi experiencia en los diferentes lenguajes, y cuál elegir en cada ocasión. He de distinguir entre lenguajes de programación y lenguajes de scripting. En mi opinión, un lenguaje adecuado para "scripting" es aquel que es interpretado, mientras que un lenguaje compilado se usa normalmente para el desarrollo de herramientas en los que el rendimiento es vital.  
  • ASM (80x86, Micropics 16F84) -> Si lo que se requiere es un rendimiento insuperable, cuanto más nos acerquemos a lo que "entiende" el procesador, mejor. En algunos procesadores, como los micropics 16F84, cuando los usaba en la Universidad, no había más remedio que hacerlo con el reducido juego de instrucciones soportadas en su ensamblador. Reservadlo para procesos críticos de alto rendimiento.
  • C/C++ -> Yo diría que es el lenguaje que está en el centro de gravedad entre rendimiento/sencillez de programación. Imprescindible para el desarrollo de herramientas que tengan requisitos de velocidad pero que permita entender de un vistazo, el código fuente, a casi cualquiera.
  • Pascal -> De los primeros lenguajes que aprendí en la Universidad. Más sencillo de entender, que C/C++, pero no goza de tanta popularidad.
  • JAVA -> Es un lenguaje híbrido (compilado e interpretado). Como ventaja, es multiplataforma. Como lenguaje pseudo-interpretado, es multiplataforma, aunque requiere precompilación. Como ventaja, hay una amplia comunidad de desarrolladores que ponen a disposición del mundo, librerías multipropósito.
  • Batch/Shell scripting -> Lenguaje interpretado. Dependiente del sistema operativo (Windows / *NIX) Se utilizan desde tiempo inmemorial como complemento para la realización de diferentes tareas, ejecutables por línea de comandos o de forma programada por el propio sistema operativo. Útiles para gestión de ficheros (copia, borrado, cambios de permisos y movimiento a diferentes ubicaciones), llamadas a otros ejecutables, cambios de permisos, etc,… Además provee lo necesario para estructuras condiciononales, bucles, etc,… Bajo mi punto de vista, el límite es que sólo se pueden realizar llamadas a comandos del propio sistema operativo, sin poder reutilizar módulos creados por otras personas, como sucede con otros lenguajes.      
  • Perl -> Lenguaje interpretado, inicialmente diseñado para el procesamiento de ficheros de texto. El propio lenguaje está hecho sobre lenguaje C. Hay una gran variedad de módulos disponibles en la comunidad CPAN. Se puede encontrar de todo: desde módulos .pm que interactúan con un módem, hasta otros que lo hacen con una estación meteorológica, para tratar con la API de Twitter, Facebook, bases de datos, threads, gestión de sockets, implementaciones de algoritmos de cifrado… y un muy muy largo etcétera… Desde hace unos años, es mi elección estrella para el desarrollo de cualquier tipo de script. Las causas sobre todo son su sencillez,  los mínimos requisitos en la sintáxis y porque gracias a posibilitar la creación de scripts en modo "Quick & Dirty", permiten generar un script express con muy pocas líneas de código, para hacer realidad la solución a cualquier problema, con un grado de abstracción y alto nivel que no he visto en otros lenguajes.

Otros lenguajes de scripting interpretados en los que NO he programado: Los más conocidos son Python o Ruby por ejemplo. Me guste más o menos, por lo que he visto en los últimos años, Python es definitivamente el "lenguaje de scripting de moda". Según tengo entendido (y por lo que he podido ver), es también un lenguaje sencillo de aprender, que permite realizar scripts muy potentes con una alta abstracción. En mi caso, los problemas que he tenido con python han tenido que ver, fundamentalmente, con la compatibilidad hacia atrás entre scripts hechos en Python 2.6 al ejecutarse en CentOS Linux 4.X, con la última versión de python disponible 2.3. Por otra parte, Python tiene ciertos requisitos sintácticos más exigentes que en Perl. Desconozco Ruby absolutamente, por lo que no me pronunciaré al respecto.

Efectivamente, hay muchos más lenguajes, como .NET, PHP, COBOL, Javascript, Visual Basic script, Modula, LUA, LISP, etc, etc,… que o no he tenido oportunidad de utilizar, o sólo me han valido para aplicaciones web, o quedaron olvidados en mis épocas universitarias, por lo que, o tampoco creo poder valorar actualmente con propiedad, o simplemente no puedo considerarlos útiles para scripting.

Al margen de las risas que existieron en la última edición de la Rootecon, respecto a qué lenguaje es mejor, creo que como siempre cabe aplicar la lógica. Si todos estos lenguajes siguen vivos, es porque hay legiones de desarrolladores que siguen utilizándolos de una forma diaria, enriqueciéndolos con módulos compartidos para el uso y disfrute de la Comunidad. Lo que digo aquí no implica que un lenguaje sea mejor que otro, sino que si dominas varios, puedes valorar y elegir cuál utilizar en cada ocasión. 

Dependiendo del problema a solucionar, de las necesidades de rendimiento a satisfacer y de la existencia o no, de módulos y librerías ya hechas, dependencias necesarias, y la no necesidad de matar moscas a cañonazos, puede que resulte más interesante pararse a pensar que lenguaje elegir antes de abrir el editor. 

Si lo que se necesita hacer puede llevarse a cabo en cualquier lenguaje, creo que la decisión ha de ir guiada por el lenguaje en el que nos sintamos más cómodos desarrollando.

En cualquier caso, elijáis el lenguaje que elijáis, no os olvidéis de lo más importante de cualquier script: Los comentarios que expliquen las secciones más complejas, para que otros (e incluso vosotros mismos) podáis entender de una forma rápida su funcionamiento.

Happy scripting!

10 comments :

El Chino Beltramone dijo...

 Y.. de php qué opiniṕn personal tiene?

Jose Selvi Sabater dijo...

Yo las cosas las hago generalmente en Python o Ruby, así que te puedo comentar mi impresión, aunque que conste que el scripting a mi me gusta por la rapidez de desarrollo y por la portabilidad, pero para PROGRAMAR me quedo con C++.

Python me gusta bastante, yo antes lo hacía todo en Perl y pasar a Python fue un paso bastante sencillo. El tema de la tabulación es algo a lo que te tienes que acostumbrar, pero a mi no me ha dado excesivos problemas. A Python le sucede como le sucedía a Perl hace algunos años, como es "el lenguaje de moda", hay librerías para hacer todo lo que quieras.

Ruby lo he usado para programarme cosas en Metasploit, que está hecho en este lenguaje, y aunque en principio debería ser más o menos igual que Python, por algún motivo a mi me resulta menos natural y me cuesta un poco más, aunque imagino que quizá es por el "cambio de contexto" de ir saltando de un lenguaje a otro.

También hay que decir que yo no soy un coder, y que como no programo todos los días y además cambio de lenguaje, me toca tirar de manual o consultar mis scripts anteriores.

Anónimo dijo...

Buenas.

Aunque no soy programador, para automatizar suelo utilizar vbscript, batch y perl dependiendo de la plataforma o la tarea a automatizar.

Vbscript en windows es mi preferido por temas de compatibilidad hacia atrás sí trabajas todavía con w2k, no queda otra para no tener que instalar cosas adicionales.

Perl en linux, lo encuentro rapidísimo y facilita muchas cosas.

Este tema encuentro que es subjetivo a las preferencias y conocimientos de cada uno. sea lo que uses, lo que sí puedo decir es que es necesario aprender como mínimo alguno para resolver problemas y/o automatizar tareas y facilitarte la vida.

blaba dijo...

Perl funciona muy bien tanto en linux/unix como en Windows.

La cantidad de módulos disponibles en cpan.org es impresionante, antes de programar nada siempre conviene pasarse por allí y mirar si alguien ha hecho ya lo que queremos hacer nosostros (para qué reinventar la rueda).

La instalación de módulos es hoy día algo facilísimo gracias a cpanminus o perlbrew. No es que fuera muy difícil antes, pero ahora es incluso más fácil.

Ahora en Windows mucha gente usa powershell. Es desde luego una mejora con respecto a cmd.exe. Me hace mucha gracia ver que su sintaxis se parece mucho a Perl sobre todo cuando la gente se pone a criticar Perl y canta las excelencias de powershell.

Silverhack dijo...

Lorenzo muy bueno el artículo y agradecerte el gesto de afecto desde tu blog. El sentimiento es mutuo!
Respecto al artículo, claro y didáctico, abordando los pros y contras de muchos lenguajes de scripting.
Respecto a limitaciones, pues BATCH tiene innumerables limitaciones, muchas de las cuales tienen que ver con sockets (Imposibles), o aplicación de cifrado básico (Imposible) a no ser que se utilicen herramientas de terceros de por medio. El chiste rápido de la demo en BATCH (Tanto perl y tanto perl), era intentar explicar que sobre lenguajes de scripting denominados "muy sencillos", también es posible realizar tareas unitarias sin mucha complicación a la hora de planificar-ejecutar.
Decir también que aunque nunca he scripteado en PERL (Asignatura pendiente), tengo que decir en su favor que PERL, utlizando la ingente cantidad de scripts y proyectos desarrollados que existen en internet, los cuales se basan en este motor de scripting,  que tiene el mayor soporte a Windows a través de los grandes repos de CPAN. Afortunada o desafortunadamente, en mi vida laboral suelo scriptear mucho con PowerShell y con Python.
Saludos y lo dicho, gran artículo!

91jcjc dijo...

Gran artículo :)

Yo, personalmente, el scripting lo hago con python.  Aunque como mi experiencia con otros lenguajes (a parte de C++) es prácticamente nula, tampoco es que mi opinión sea demasiado útil :P

En lo que sí que puedo opinar con algo más de fundamento es en la programación de microcontroladores que has mencionado :). Para programar PICs yo no uso ensamblador puro, sino PICC (Un C adaptado por microchip para sus micros), y si alguna parte del código requiere una optimización especial este lenguaje te permite meter "cachos" de ASM. :)

Ah! y una última cosilla por si alguien quiere iniciarse en el mundillo de los PICs... el pic16f84 siempre ha sido el gran clásico de microchip para el aprendizaje, pero hace ya algún tiempo que para esta función se usa el pic16f88. Son prácticamente iguales, pero este último lleva un reloj interno, así que te ahorras el cristal oscilador y los condensadores en el circuito :P

Jose Selvi Sabater dijo...

@f7d0cff771650ed79156de3a02b819eb : A mi el BATCH me parece muy útil para los Test de Intrusión, porque es algo que todos los Windows tienen sí o sí, y con un poco de Command Line Kung-Fu... se pueden hacer cosas más que interesantes.

francisco leon dijo...

Muy buen articulo!
En lo personal e hecho algunas cosas en c y ruby pero a final de cuentas bash es muy optimo por que usualmente para test lo usamos dentro de nuestras maquinas, hasta que a alguien se le ocurre decir "pasamelo", y uno dice, "Bueno", ya nadamas le damos una modificadita en otro lenguaje, no se c en lo personal, pero pues si depende del developer el que le agrade, o el que le acomode al juanking

Lorenzo_Martinez dijo...

@f2a3ceae5029e026fb855f7fa9234fca PHP lo he utilizado para generar contenido web. No lo tengo en cuenta dentro del pool de lenguajes de scripting generalistas que permiten hacer cualquier cosa... Quizá lo tengamos encasillado en que es un lenguaje para páginas web y no le damos la oportunidad que merece

Jose Selvi Sabater Gracias por tu comentario... Tú eres uno de los switchers reconocidos de lenguaje de scripting. Mi duda es, ¿puede simplemente una moda hacer que cambies el lenguaje de scripting utilizado, por otro que es IGUAL de potente? Ya que conoces ambos bien, explícanos las diferencias por favor!

@f7d0cff771650ed79156de3a02b819eb Lo que he remarcado en el post es que si uno se siente cómodo y capaz de hacer un script con el lenguaje que conoce, y tienes claro que va a funcionar con el rendimiento necesario para la tarea que se desea solucionar, ¿para que usar otra cosa? Si tú eres capaz de hacerlo todo con python, powershell y tirar de BATCH cuando te hace falta,... vive feliz! El resto, obviamente son bromas de que si A es mejor que B o B mejor que C....

@ddd0a6d8ebf2231996ae4d74d36697b8 Sobre los micropics, hace unos 12 años que no me pego con uno. Por eso digo que el que usaba era el 16F84. En su día había un "pseudo-C" que permitía hacerlo más sencillo, pero época universitaria había que hacerlo en ASM. De todas formas en un programa C/C++ genérico tu puedes incrustar una sección de código hecha en ASM, no sólo para micropics..
 

Jose Selvi Sabater dijo...

Lorenzo_Martinez Pues... cambiar de lenguaje tiene una gran desventaja, y es que es verdad que cuando ya dominas uno, te toca cambiar y aprender otro (aunque suele ser rápido) ¿Una moda puede hacerte cambiar de lenguaje? Pues tengo que reconocer que en mi caso lo hace, pero no porque "mole" más programar en Python, sino porque el hecho de que mucha gente programe un lenguaje hace que haya más librerías y estén mantenidas más al día.

Yo no soy un gran experto en lenguajes de programación, así que no me atrevería a hacerte una comparación de las ventajas de Python sobre Perl o viceversa. Mi caso ha sido mucho más práctico: Busco una librería para interactuar con Bing, y la primera que me sale en el buscador es una para Python, así que de una forma natural te vas moviendo a Python. Es mi caso al menos.